Discussions

News: Article: Building Struts 2 Apps Without XML Gluecode

  1. In "Building Struts 2 Apps Without XML Gluecode," Ted Husted jettisons XML for "convention over configuration," autowiring Struts 2 Actions to search-engine friendly URLs.
    What's XML gluecode? Success breeds success, and successful applications tend to grow larger and more complex over time. Most applications are so large and so complex that we can't think about the entire application at once. To get through the day, we need to focus our attention on one thing at time. One way to simplify complex applications is to separate concerns. We group similar tasks together, so that we can focus on one element of the application at a time. Two concerns that we like to separate are presentation logic and business logic. It's easier to design presentation logic using a page template, and it's easier to design business logic using conventional source code. Each concern is easy to manage on its own, but we need a way to put the concerns back together... Instead of wiring components together with configuration files, another strategy is to use consistent naming conventions, and then make the conventions part of the application framework. Many Struts developers already use naming conventions to track which components go together. We just need to program the framework to observe the same kind of conventions that most of us already use. For example, if a client requests a "hello-world.action", it makes sense for the framework to look for a "HelloWorld.class" and/or a "hello-world.jsp". If the Action class returns "small" as a result code, it makes sense to first look for a "hello-world-small.jsp" (or a "hello-world-small.vm", you prefer Velocity templates). If "hello-world-small.jsp" is not found, then it would also make sense to check for a plain-old "hello-world.jsp".

    Threaded Messages (49)

  2. Welcome to Stripes[ Go to top ]

    Stripes has been doing this for a couple of years now. Check it out at http://stripes.mc4j.org/confluence/display/stripes/Home.
  3. Yep[ Go to top ]

    Yes one of the most useful things about stripes is the classpath scanner. I have been using it in other parts of applications to avoid configuration. Instead I just put whatever @tag I need on the class, scan for it and wire it up. You won't find a single xml file anywhere, everything is auto discovered with annotations & their attributes. The framework auto discovering action beans is just the tip of the iceberg of what you can really do with this thing! Now I'm sure someone is going to pop up and say annotations are bad blah blah. That's fine, they are free to think whatever they want when they get some time away from xml hell.
  4. I can't tell you how boring the comparisons of different frameworks is. Blah Blah Blah. There is a reason everyone says they are better than Struts 1, because it's successful. You can go into a book store and find a book to give to a new developer to learn from. Great new framework X does not have any books, does not have a transition plan from struts 1, does not have a lot of people who we can hire to do development. X does not matter. X is like those concept cars you see at shows that are really cool, get great gas milage, but only seat one person and if you had one you could not get it fixed when it breaks.
  5. I can't tell you how boring the comparisons of different frameworks is. Blah Blah Blah.
    Really ? Then what are you doing here ?? Isn't TSS about flaming and trolling on the latest new shit ??? ;-P
    There is a reason everyone says they are better than Struts 1, because it's successful.
    BS. You can prove it with figures (dev. time, maintenance costs, etc.). Some frameworks are better than others for some given tasks. It's a fact. And btw, before it got successful, Struts obviously started somewhere.
    You can go into a book store and find a book to give to a new developer to learn from.

    Great new framework X does not have any books, does not have a transition plan from struts 1, does not have a lot of people who we can hire to do development.
    So we stick to the old way of doing things ? Because we're too lazy to try out new things, even if they could potentially make our lifes easier later on ? Do you realize that if everybody was thinking your way, there would not be any book ? And any framework at all ? Ya know, that thing called "innovation"...
    X does not matter. X is like those concept cars you see at shows that are really cool, get great gas milage, but only seat one person and if you had one you could not get it fixed when it breaks.
    Well, I'm happy those Suzuki engineers worked their asses off on those crazy things they do... Thanks to all those concept bikes and other experiments, my bike's better than the ones they used to produce 10 years ago. And software moves faster than heavy industry such as car manufacturing. Cheers Remi
  6. I can't tell you how boring the comparisons of different frameworks is. Blah Blah Blah.


    Really ? Then what are you doing here ?? Isn't TSS about flaming and trolling on the latest new shit ???
    ;-P

    It's not that I don't like to hear about new stuff, I do. The problem I have is with the direction of the discussion. Every person seems to have gone out and discovered a great new tool and for brand new development, and it solves some particular itch of theirs.
    And then we go back and forth on the question of if they picked the right itch to scratch.

    There is a reason everyone says they are better than Struts 1, because it's successful.


    BS. You can prove it with figures (dev. time, maintenance costs, etc.). Some frameworks are better than others for some given tasks. It's a fact.
    I didn't see any number in your reply. How much better is framework X over framework Y? But I've got numbers for you. Dice search on struts: 2055, stripes 25. 2 orders of magnitude difference.
    Oh wait, that's not the criteria you wanted success judged on? Better is in the eye of the beholder, and it a lot of the pointy haired boss world, technical excellence is NOT the only one (and sadly not even a primary one sometimes).
    Just because something is technically better, does not make it the right choice. I once had a new manager on a project decide that we were going to use the Jacobson method (perhaps I'm dating myself with that). He wanted us to do robustness analysis completely without regard to the > 5 million lines of code that our system already had.
    Now was the Jacobson method better and far more productive than the methodology we were using at the time? Sure. But without a transition plan and an understanding of the environment as it is, rather than the way you wish it were, it was doomed to failure. I fled and that manager was one of the few people I've ever seen fired for cause at my company.
    And btw, before it got successful, Struts obviously started somewhere.
    Struts started somewhere. It started as the first action framework to allow people to leave the horrible Model 1 JSP applications. You remember those, they had huge 1000 line scriptlets, you could not debug them and you didn't get the syntax errors until you hit the page.
    The level of improvement has to be big enough to get returns on the change. JSP to struts provided such value. And you can't throw out the old stuff. What people don't understand is that there is now enough existing software out there that you can't just ignore it.
    If someone came out with a new OS that "improves" on Linux, now critical would you be? For you to consider using it, there would have to be a transition plan from Linux, vendors to support it etc.
    Consider what would have happened to struts 1 if they had said, it's better than JSP's, but you have to convert all of your JSP's all at once to struts. It would not have taken off. The ability to add the struts servlet and migrate one page at a time served two imporant goals that should be repeated by any new framework:
    1.) It serves to reduce risk. Since you can convert one page at a time, you can have small little changes rather than a big conversion. This is the critical technical point.
    2.) It is sellable to management. Rather than saying "We need to rewrite all of our code." (to which the boss will say, "why should I trust you now, you obviously didn't know what you were saying when you said struts was better than JSPs?") you can say "We have an improved way to do things. It's better than struts in terms of a, b, and c; but they recognize that struts is the best way in the past and they have documented a transition path."



    You can go into a book store and find a book to give to a new developer to learn from.

    Great new framework X does not have any books, does not have a transition plan from struts 1, does not have a lot of people who we can hire to do development.


    So we stick to the old way of doing things ? Because we're too lazy to try out new things, even if they could potentially make our lifes easier later on ?
    Do you realize that if everybody was thinking your way, there would not be any book ? And any framework at all ?

    Ya know, that thing called "innovation"...

    I'm not saying we don't innovate. I'm more railing against the lack of innovation in the framework discussion than the actual framework development. Let's be clear, struts 1 is going to go the way of the dodo bird. My way of thinking is that there will always be innovation, but successful innovation MUST look at the current landscape. Let's take Strips for example. If you go to the Stripes home page, you will see a navation item on the left hand side called "struts vs. stripes". Blah Blah Blah. If you need to convert, you have to come back to the server side for information: http://www.theserverside.com/news/thread.tss?thread_id=41695
    Struts 2 has a migration guide (under Guides).
    There just has to be a transition plan, and I don't see it being done. Or talked about here either.

    X does not matter. X is like those concept cars you see at shows that are really cool, get great gas milage, but only seat one person and if you had one you could not get it fixed when it breaks.


    Well, I'm happy those Suzuki engineers worked their asses off on those crazy things they do... Thanks to all those concept bikes and other experiments, my bike's better than the ones they used to produce 10 years ago.

    And software moves faster than heavy industry such as car manufacturing.

    If someone came out with a new OS that "improves" on Linux, now critical would you be? I bet for you to consider using it, there would have to be a transition plan from Linux, vendors to support it etc.
    Let me be clear, I'm not trying to bash concept cars. I love concept cats. They do wonderful things for other cars. I'm not bashing the concept frameworks being discussed here. But to move from a concept framework to a framework that will replace the struts/spring world that I currently am in will take more than just being technically better or more productive.
    But what I see here is a discussion about comparing a concept car to a Honda Accord.


    Cheers

    Remi
    So I should put my money where my complaining is and talk about a few of the items that concern me and affect my consideration as a struts 1/spring replacement:

    Does it work with portals? (struts 1, struts 2 and Spring all do)
    Can I get my third party packaged struts 1 action to work with it? I've got code from vendors that no longer exist and license that does not allow me to change it. I need a struts 1 co-habitation ability.
    AJAX support is critical to me. I've got DWR code that I don't want to change. Mostly because I've got to get any AJAX solution to work through the really funky Vignette WebConnector and DWR/GWT are the only two frameworks I've got working so far.
    I love convention over configuration, but during conversion time when I'm not matching the convention, can I still get it to work?
    Can we get a real discussion?
  7. I didn't see any number in your reply. How much better is framework X over framework Y?
    C'mon... I meant that productivity and ROI can be better if you choose the right technology.
    But I've got numbers for you. Dice search on struts: 2055, stripes 25. 2 orders
    of magnitude difference.
    What an argument ! We all know Struts is heavily used in many webapps (being the de facto choice for so many), so obviously there is maintenance. Thanks a lot for this awesome info ! Lots of folks are struggling with their struts spaghetti code, and desperately need somebody to fix it. That's all your numbers can prove. Nothing more. The trend might be interesting, but a snapshot of the dice jobs is clearly not showing anything. We're discussing of the advantages of some fwks over others here. Not which one is the most popular. Otherwise we wouldn't even have to choose : we'd be locked into some unique vendor stuff like M$'s back in the days. The "Java Salad", as Sergio calls it, is probably the best thing that happened to our industry.
    excellence is NOT the only one (and sadly not even a primary one sometimes).
    Again, I'm talking about being productive. Not about technical excellence. The web is a pile of crap anyway, so what kind of technical excellence can you find there ? Web frameworks are useful, and can be innovative. They hide the crap. But there clearly isn't excellence in a web MVC. I'm talking about picking the right tool to build software efficiently. And this requires to be aware of what's available, and what are the specificities of each.
    And btw, before it got successful, Struts obviously started somewhere.
    Struts started somewhere. It started as the first action framework to allow people to leave the horrible Model 1 JSP applications.
    Yeah. And you had to twist your mind a little bit to get it to work back in those days. And there were no book. And no solid doco. But still, some people found interest in the approach, and started using it, blogging, writing books... and then it became the de facto Java MVC. What makes you think the story could be different for another framework ? Why killing the innovation by replying stuff like : "you're boring us with your useless new ideas, anyway nobody uses it so I'll stick to the popular stuff unless I have no efforts to migrate" (which is more or less what you said) ?
    You remember those, they had huge 1000 line scriptlets, you could not debug them and you didn't get the syntax errors until you hit the page.
    Well, you can do "nice" things with servlet/JSP, it's just that... you have to write Stripes before :) Seriously, almost everybody already had a home brewn framework back in the servlet days. Struts "standardized" the web MVC in some way, and we owe it a lot for this. It showed a direction that many have followed, themselves opening new tracks.
    The level of improvement has to be big enough to get returns on the change. JSP to struts provided such value. And you can't throw out the old stuff.
    Well, have you tried Stripes ? Don't you think that's an improvement (it's basically Struts without the pain) ? And yes you can throw out the old stuff. Many libraries or frameworks are actually EOLed at some point, and you have no choice but to replace them because you certainly won't rely on unsupported stuff. That's exactly what I meant in my OP : I think Struts' time has passed, and people still using it should consider moving to something more simple and maintaineable. We have dozens of users on the Stripes ML that come from s heavy Struts background. Ask them if they think their productivity has improved. Ask them if they can't throw the old stuff away. Ask old C fellows that switched to Java... and language switch is even harder than fwk switch of course.
    What people don't understand is that there is now enough existing software out there that you can't just ignore it.
    Who talks about ignoring existing stuff ? All frameworks we talk about here leverage the Java platform and rely on several open standards. They even implement recognized patterns. Of course, when you switch a library/fwk, you often have to rewrite parts of your application... But that's our work man ! You can't seriously believe that an application can live forever without developers working on it, and replacing parts or everything with up to date technologies...
    If someone came out with a new OS that "improves" on Linux, now critical would you be?
    Well, if it helps me to produce better quality software faster, then I'll probably buy it. Like I've done for Linux years ago. It was bleeding edge, yeah, but I found it useful, so I switched. I've just done the same move from Linux to Mac a few months ago : I'm more productive and happy on MacOS, so I switched. As simple as that : pick the tools for the tasks I have. And I don't care a lot about popularity, as it's not always related to efficiency.
    For you to consider using it, there would have to be a transition plan from Linux, vendors to support it etc.
    Sure I probably wouldn't use an exotic distro with only 3 users on earth (or maybe for very specific things)... But again, not all frameworks are bleeding edge. Stripes is very stable from a long time now. Really, you have wrong ideas about it. It's not a toy fwk that nobody knows about... Try asking something on the ML for example, and you'll see. I bet you'll have an answer in the day.
    Consider what would have happened to struts 1 if they had said, it's better than JSP's, but you have to convert all of your JSP's all at once to struts. It would not have taken off. The ability to add the struts servlet and migrate one page at a time served two imporant goals
    Well, you ended up rewriting everythin anyway ! Moreover, I don't agree that transition has to be smooth to go for it. It hurts on the moment, but th ebenefit is worth that pain, and in many cases software is completely rewritten, even when meeting customer's expectations ! Don't misunderstand me : I completely agree that migrations should be as smooth as possible in an ideal world, but sometimes you have to break everything (which is not the case in a Struts 2 Stripes migration, you can also do it "page per page"). It's always a tradeoff : the migration cost vs. what you save in maintenance etc. And apparently, the pace of change in every application today seems to indicate that migration is worth the cost : everybody does it. Last, we're not only talking about migration, but also of new projects.
    I'm not saying we don't innovate. I'm more railing against the lack of innovation in the framework discussion than the actual framework development.
    I agree the thread is weird... But once again there's no innovation if you don't let curious and motivated people discuss and try out new ideas. If you prefer to wait that something gets mainstream, then fine. But people like us with new fwks etc., don't. I hate the idea to continue struggling with old, outdated methods and tools and stay at a low productivity level, whereas there are other ways to achieve my goals that are mich more efficient. This is frustrating and it doesn't make good cash. If you look at it, I'm certainly not alone. Java Land is full of projects that started as a "new shit", and turned into an official JSR a few years later ! And I feel it going faster and faster in that direction... So I guess many devs are ready to try out new things before those have reached the top of their hype curve. And they'll probably know if it solves their problems better than what they're currently using.
    Let's be clear, struts 1 is going to go the way of the dodo bird.
    Yep. And this is a good opportunity for starting over on a fresh and solid foundation. I know migration hurts sometimes, but again, it's our job to be agile and adapt to change. Stripes being more productive than Struts2 IMHO (ok, I don't have exact figures but I'd bet that case-based analysis would make me right), the price for migration is really worth to pay, as the ROI in maintenance and new features is huge. So you do the math for your own projects, but really, upgrading your apps is something you won't avoid anyway. Again, it's a good opportunity to take the right decision.
    My way of thinking is that there will always be innovation, but successful innovation MUST look at the current landscape.
    You should really love Stripes then. It builds on rock solid standards and leverages them in a simple fashion, instead of reinventing all possible wheels.
    Let's take Strips for example. If you go to the Stripes home page, you will see a navation item on the left hand side called "struts vs. stripes". Blah Blah Blah. If you need to convert, you have to come back to the server side for information: http://www.theserverside.com/news/thread.tss?thread_id=41695
    Again, come have a closer look to Stripes. You'd be very surprised ! Doc is really several orders of magnitude easier to find and more comprehensive in Stripes than Struts !! And it's not only because there's much less material... It's just because it's focused on one task (MVC) instead of trying to solve various problems (templating and other weird stuff).
    Let me be clear, I'm not trying to bash concept cars. I love concept cats. They do wonderful things for other cars. I'm not bashing the concept frameworks being discussed here.
    Who said they are "concept frameworks" btw ??? I've used Stripes to make quite some money in the past years, and I even tend to enjoy coding those crappy webapps now ;-P The comparison clearly doesn't stand. The equivalent of a concept car in the IT industry would be real research as IA and stuff like this, which by definition doesn't apply directly in frameworks or languages. It takes a few years usually for the industry to start exploitation on such research results. Just like concept cars.
    But to move from a concept framework to a framework that will replace the struts/spring world that I currently am in will take more than just being technically better or more productive.
    What would it take then ??? Isn't productivity our moto ??? I'd be really interested in your reasons to avoid switching to something technically better and more productive ! I can't figure out a single one ! Really !
    But what I see here is a discussion about comparing a concept car to a Honda Accord.
    I don't see it like this. To me you're comparing a 1950 old car to its current equivalent. And IMHO Struts2 is just the 1950 one with a few new parts, and new painting. But it still has this uncomfortable seats, the engine is capricious, it eats lots of gas for a poor top speed... overall it still feels like an old car ! Cheers Remi
  8. C'mon... I meant that productivity and ROI can be better if you choose the right technology.
    Productivity and ROI are not the same thing. When you calculate ROI you have to factor in the cost of conversion and training.
    We're discussing of the advantages of some fwks over others here. Not which one is the most popular. Otherwise we wouldn't even have to choose : we'd be locked into some unique vendor stuff like M$'s back in the days.
    True, we are discussing different frameworks; however, you are not considering different environments.
    I'm talking about picking the right tool to build software efficiently. And this requires to be aware of what's available, and what are the specificities of each.
    Exactlly!!! And the right tool needs a migration plan from current state. Most pepole don't have the option of only doing greenfield development. And most of the "options" I've seen don't have a good migration strategy from struts/spring to their "new and better". Give me the actual URL's if I'm wrong.
    Well, have you tried Stripes ? Don't you think that's an improvement (it's basically Struts without the pain) ?
    Sure I've looked at it. And it is better than Struts. But, and this is critical, is it enough better to start the management fight to get to be able to use it?
    Because, while I can try and technology out I want at home, at work I have to convince people that it's a good idea. No help there.
    Well, you ended up rewriting everythin anyway ! Moreover, I don't agree that transition has to be smooth to go for it. It hurts on the moment, but th ebenefit is worth that pain, and in many cases software is completely rewritten, even when meeting customer's expectations ! Don't misunderstand me : I completely agree that migrations should be as smooth as possible in an ideal world, but sometimes you have to break everything (which is not the case in a Struts 2 Stripes migration, you can also do it "page per page").
    Yes, I did rewrite everyting. But not all at once!
    I looked for the documentation of how to do a page by page stripes conversion and didn't find it. What's the URL of the docs?
    Again, come have a closer look to Stripes. You'd be very surprised ! Doc is really several orders of magnitude easier to find and more comprehensive in Stripes than Struts !!
    Seriously, where is the docs on a page by page migration? There is the interesting looking titles for that, but they are in French. I see a whole bunch of, it's better than struts, but that's it.
  9. Cool ! the discussion begins to make sense...
    Productivity and ROI are not the same thing. When you calculate ROI you have to factor in the cost of conversion and training.
    You're just f.cking the flies here mate, with all due respect ;-P I already said 10 times migration was a tradeoff between the cost (which obviously includes training) of migration and its ROI. Clearly, "I" in ROI stands for "Investment" :)
    True, we are discussing different frameworks; however, you are not considering different environments.
    Because you think my points are not valid in enterprise applications ? Then tell me, what was the migration plan for trashing millions of LOC of C/C++/Ada/COBOL/Whatever to migrate all those heavyweight banking apps to Java in the last 10 years ? Once again I fully receive your argument. But clearly, there are lots of counter examples. I would even tend to think that almost no migrations have such a nice path you describe. That would be really cool, but unfortunately migration reality is blood, sweat and tears... not a pleasant journey ! Thereby, you try to pick some stuff that's gonna last. Standards matters. And here again Stripes is a good investment : it leverages servlet/JSP API with a simple framework that works fine, and is easy to maintain itself.
    Exactlly!!! And the right tool needs a migration plan from current state. Most pepole don't have the option of only doing greenfield development.
    C'mon, please stop thinking that people who use alternative tools are only a bunch of hippies smoking grass and coding toy applications only :-)
    And most of the "options" I've seen don't have a good migration strategy from struts/spring to their "new and better". Give me the actual URL's if I'm wrong.
    Well, this "push button migration" obviously doesn't exist. It's already hard to find stuff from a single vendor that always upgrades smoothly, but when you switch a framework... Of course, hopefully the Struts guys provide a migration from Struts1 to 2, like we'll probably provide for Stripes 1.4.x -> Stripes 1.5. But you can't expect to have the full matrix, this is completely irrealistic. Say I want to move e.g. from PHP to Struts2 ? What's the migration path ? Dare to give me the URL ?? ;-P
    Sure I've looked at it. And it is better than Struts. But, and this is critical, is it enough better to start the management fight to get to be able to use it?
    "Damn the torpedoes. Go Ahead." !!! Management doesn't have a clue of what technology is. You're supposed, as a dev, to be the one who decides. It's only a question of how you present things...
    Because, while I can try and technology out I want at home, at work I have to convince people that it's a good idea. No help there.
    I don't know, when I need to push for some technology, I usually do a POC, demo everything and then explain to managers and marketing where it helps to make cash, not even mentionning the deep tech points. You should try it. From my own experience, it usually works like a charm on any manager :-) Of course, if you come to your Architect or Manager and throw the URL to Stripes at his face without more explanations, you will not probably succeed. Really, good managers can understand good decisions. Otherwise, your manager just sucks !
    Yes, I did rewrite everyting. But not all at once!
    Yep, and again, you can perfectly do this with Struts/Stripes.
    I looked for the documentation of how to do a page by page stripes conversion and didn't find it. What's the URL of the docs?
    http://www.devx.com/Java/Article/31921 That's the second hit when you google for "struts to stripes" ! (please read at least the conclusion as it summarizes our discussion quite well !) I'm beginning to think you're a lazy man : that would even explain why you're so reluctant to framework switching, and fight to keep everything as you know it ! ;-P The first hit is interesting too : http://mc4j.org/confluence/display/stripes/Stripes+vs.+Struts (even if maybe outdated wrt Struts2)
    There is the interesting looking titles for that, but they are in French.
    Folks are working on the Wiki currently so maybe it's a temporary mess... I just went to www.stripesframework.org and you don't have the left tree menu any more... But Google gives excellent hits for Stripes related stuff (probably partly because it doesn't have zillons of related pages). And again, the ML is amazing, you find answers to all your problems over there...
    I see a whole bunch of, it's better than struts, but that's it.
    That's it ? You'll stay with your dinosaur framework even knowing you'd be faster to develop and maintain your applications ?? Sorry, I think I'll never understand this ! Cheers Remi
  10. Seriously, where is the docs on a page by page migration? There is the interesting looking titles for that, but they are in French. I see a whole bunch of, it's better than struts, but that's it.
    Honestly, I don't think there is a document for something this specific. Maybe there should be? I don't know. The reality of it is very simple though. I can speak for Struts to Stripes, but I'd bet the process is very similar even if you replace either framework in that statement with another action framework (converting to or from a component framework, I imagine, would be rather different). When we did it on our project we literally setup Stripes right in the same web application as Struts, and used it at first for building new screens. The two function just fine side by side. Some nav links ended in .do, others in .action. As the whole team got more comfortable we instituted a policy of re-factoring to Stripes any time we made large scale changes to a Struts screen. And when we had about 70-80% Stripes we dedicated a small amount of effort to finishing it off so that we'd be back to one technology. Since conceptually most action frameworks are very similar, the transition of any one screen/action is usually very straightforward -port the action class, port the JSP/view, change over any links (if necessary) and you're done.
  11. I can't tell you how boring the comparisons of different frameworks is. Blah Blah Blah.

    There is a reason everyone says they are better than Struts 1, because it's successful. You can go into a book store and find a book to give to a new developer to learn from.

    Great new framework X does not have any books, does not have a transition plan from struts 1, does not have a lot of people who we can hire to do development. X does not matter. X is like those concept cars you see at shows that are really cool, get great gas milage, but only seat one person and if you had one you could not get it fixed when it breaks.
    there are many books out for struts 2, I am listing just few of them: -Struts 2 in Action -Starting Struts 2 -Practical Apache Struts 2 Web 2.0 Projects -Struts 2.0:The Complete Reference -Struts 2 Design and Programming and many more check out the following for more information: http://www.sourcebeat.com/books/strutsactionlive.html http://www.amazon.com/Struts-Design-Programming-Tutorial/dp/0980331609
  12. Is this really a innovation?[ Go to top ]

    RoR is doing there since 2004. Other frameworks are doing that for some time now. Convention over Configuration is not a feature nowadays. It is a REQUIREMENT. Mentawai provides the best of all worlds. Programmatic configuration, CoC and user-defined conventions. For example, if the user does not configure any consequence for the action /User.add.mtw, then the convention is to forward to /User/add.jsp, no matter the action result. You can also implement the easy ConsequenceProvider interface to design your own conventions. Plus XML nowadays is a dinosaur. I am not talking about annotations. I am talking about programmatic configuration through Java, BeanShell, Groovy, Ruby or DSL. http://www.mentaframework.org/
  13. I forgot to mention. Automatic class scan is cool, but not pratical when you have a jar, although possible. What Mentawai does is very simple: registerPackage("org.myapp.action"); registerPackage("org.myapp.otheractions"); So when you do /HelloAction.mtw it first looks for: org.myapp.action.HelloAction then org.myapp.otheractions.HelloAction This is Mentawai! This is KISS !!!!!!!!!!!!!!!!!!!!!!!!!!!! http://en.wikipedia.org/wiki/Kiss_principle
  14. I forgot to mention. Automatic class scan is cool, but not pratical when you have a jar, although possible.
    I'm not sure what had lead you to think this, but it works extremely well. In our application at work we use the technique to scan Jars all the time, including components that are shared with other applications and teams. In fact, it works so well we started doing the exact same thing to load all of our hibernate/JPA entities.
  15. I said it can be done, but it is a pain in the but to implement. A more simple solution, at least for automatically loading action, is to register the packages the action can belong to. Then you just try to load the action from the registered packages. Pretty simple solution, isn't it? I has a tiny drawback that you have to register a couple of packages in advance.
  16. I said it can be done, but it is a pain in the but to implement.

    A more simple solution, at least for automatically loading action, is to register the packages the action can belong to.

    Then you just try to load the action from the registered packages.

    Pretty simple solution, isn't it? I has a tiny drawback that you have to register a couple of packages in advance.
    Isn't that the point/value of a framework though? To tackle some of the technically challenging things and bundle them up in a reusable package? From a user's standpoint class scanning is nice and if it is implemented by someone else and works, there's no problem at all.
  17. I said it can be done, but it is a pain in the but to implement.

    A more simple solution, at least for automatically loading action, is to register the packages the action can belong to.

    Then you just try to load the action from the registered packages.

    Pretty simple solution, isn't it? I has a tiny drawback that you have to register a couple of packages in advance.

    Isn't that the point/value of a framework though? To tackle some of the technically challenging things and bundle them up in a reusable package? From a user's standpoint class scanning is nice and if it is implemented by someone else and works, there's no problem at all.
    Yes. Registering packages is the solution that Mentawai uses for automatic action discovery. I agree that scanning the whole classpath (even jars) is better. Not sure if it is more efficient, but efficient is not the point here. The point is that both solutions work very well, with the package registration being much more simpler to implement and having a little drawback of having to register the packages that your actions will belong to. I think this drawback is very, very small, because most of the times your actions will be in just one or two packages.
  18. The real web framework[ Go to top ]

    I much prefer the web framework my grandmother wrote. It is truly MVC, uses annotations, and prefers convention over configuration. On the downside, you have to own a sewing needle to use it. Now the one her dog wrote, that's a different story...
  19. RoR is doing there since 2004. Other frameworks are doing that for some time now. Convention over Configuration is not a feature nowadays. It is a REQUIREMENT.
    Yep, fully agreed. Funny to see this feature only now, in one of the oldest web framework on earth :-)
    For example, if the user does not configure any consequence for the action /User.add.mtw, then the convention is to forward to /User/add.jsp, no matter the action result.
    Stripes does this even without writing the action bean. Of course, as a Stripes fan I might be bias, but it looks like Struts is lost somewhere in between the MVC and some kind of "full stack" (or "half stack" I should say) framework with complex templating stuff and weird taglibs, a crappy interception mechanism... really, it's not consistent at all. I think Struts has probably been useful in its time, and it certainly helped to push web frameworks towards something better and better... But hey, face it : today, it's not even part of the MVC competition any more ! Look at the other frameworks out there, they all offer more for less :-) We still talk about Struts because there's many apps in production running on it. If it had been released in say 2005, do you think anybody would even know about it ??? Just like COBOL : do you think there would be a single COBOL coder if it was released today (excepted the guy coding the compiler of course ;-P) ? IMHO, Struts should be EOL-ed. It should be maintained for x years, and dropped. The framework is clearly bloated with legacy heritage stuff, and just gets into you way instead of boosting your productivity. Using it on a new project looks like a weird choice to me, so maybe support should continue for people still using it... but they'll have to migrate to something else sooner or later anyway ! Stripes 1.5 will soon be released. For those who still hesitate, go and check it. It has all Struts can offer and more (clean URLs, binding security, interceptors, Spring integration, extensible components...), but simpler, lighter, and consistent. www.stripesframework.org Enjoy ! Remi
  20. Strictly speaking, I believe that Struts2 is actually Webwork, so I would hesitate to say that Stripes necessarily has everything and more.
  21. Check the "Mentawai in Action" book: http://book.mentaframework.org/ Check what people are saying about Mentawai here: http://forum.mentaframework.org/posts/list/143.page Struts2 cannot even do a simple validation right! XML mixed with Java or a bunch of annotation hell. You choose! Mentawai has ZERO annotations, ZERO XML. Programmatic configuration is the way to go! Forget about annotation hell or xml hell. But most important of all is the HIGH LEVEL OF ABSTRACTION. Forget about the framework salad. We don't need Spring. We need the basic functionality of Spring. http://www.mentaframework.org
  22. Programmatic configuration is the way to go! Forget about annotation hell or xml hell.
    There's no silver bullet. Programmatic config is fine for some given problems, and sometimes other solutions are better. And btw, even if annotations are declarative, they're part of the contract of your objects. They compile, you can reflect on them etc. For instance, I would not want programmatic config in Stripes, because I introspect the action beans to do various things depending on what I find there... How would I do this with a full Java config ??? Here again, Stripes has the best tradeoff between the two IMHO : its usage of annotations is really concise, efficient, and elegant. That's actually a good example of how to use annotations efficiently. Cheers Remi
  23. Programmatic configuration is the way to go! Forget about annotation hell or xml hell.


    There's no silver bullet. Programmatic config is fine for some given problems, and sometimes other solutions are better.

    And btw, even if annotations are declarative, they're part of the contract of your objects. They compile, you can reflect on them etc.

    For instance, I would not want programmatic config in Stripes, because I introspect the action beans to do various things depending on what I find there... How would I do this with a full Java config ???

    Here again, Stripes has the best tradeoff between the two IMHO : its usage of annotations is really concise, efficient, and elegant. That's actually a good example of how to use annotations efficiently.

    Cheers

    Remi
    Stripes does not want PROGRAMMATIC CONFIGURATION because it would become very similar to Mentawai. Mentawai does not want ANNOTATIONS because it would become very similar to Stripes and possibly to some other annotation-based frameworks out there. I think Stripes is a great framework !!! Very similar to Mentawai in its philosophy. I particular do not like annotations and prefer much more programmatic configuration. You can check my reasons here: http://book.mentaframework.org/posts/list/5.page
  24. Stripes does not want PROGRAMMATIC CONFIGURATION because it would become very similar to Mentawai.
    Well, you can actually do everything by code in Stripes (write your action resolver that registers your actions in pure java, write your validation methods in pure java, etc.). It's just that in practice, annotations just shine. Why would we write 10 LOCs when a simple annotation does more (meta data) ?
    Mentawai does not want ANNOTATIONS because it would become very similar to Stripes and possibly to some other annotation-based frameworks out there.
    Well, the big strenght of Stripes is the whole package. It's a collection of simple but very efficient ideas that, all together, form a consistent whole, and really leverages your productivity. Also, Stripes implements the same concepts every MVC does. It *is* very similar to Struts. It's just implemented in a much more simple and clean fashion.
    I think Stripes is a great framework !!! Very similar to Mentawai in its philosophy. I particular do not like annotations and prefer much more programmatic configuration. You can check my reasons here:

    http://book.mentaframework.org/posts/list/5.page
    Precisely. I find your example much more complex than its Stripes equivalent ! You need 3 classes to do stuff that's done in a dead simple action... or am I missing something ? Cheers Remi
  25. Precisely. I find your example much more complex than its Stripes equivalent ! You need 3 classes to do stuff that's done in a dead simple action... or am I missing something ?
    Which example are you talking about? You don't need three classes. You need as much as ONE class: the action or the POJO that will handle the request. In Mentawai you place all configuration, all setup, all wiring, all ioc, etc. inside the ApplicationManager.java file. Instead of having a centralized XML file like struts, it has a centralized PROGRAMMATIC file in Java. Could be BeanShell, Ruby, Groovy, etc. In Stripes you will scatter all the configuration across all the code across a bunch of annotations. Serious, not the worst thing, but I would rather organize this, keep my code decoupled from the framework being used and centralized in the ApplicationManager.java class. Note that any change in an annotation in an action will probably force a full re-deploy of the application JAR/WAR. If you have a separate class for the configuration, then you only need to re-deploy that class. The class can even access some dummy properties for stuff like DB URL Connection, contact emails, and that more static configuration info. The configuration part is important. Some innocent people believe that you can code a serious web project all based on conventions. This is so not true. It is also very limiting. At some point you will have to get your hands dirty and CONFIGURE, SETUP, AUTO-WIRE, etc. However this is not even the most important topic when it comes to web frameworks. XML x Annotations x Java x DSL is not the most important thing. The most important thing is: ABSTRACTION. Don't make me thing about anything and don't direct me to other frameworks. Let's avoid the Java Framework Salad. A single framework for all your needs !!! That's the goal of Mentawai (and also of RoR). It is just not competing with Hibernate, although it offers a simple CRUD ORM solution for those who are using pure JDBC and would take some help in building SQL queries. Hibernate as much as Spring is NOT something that you go learn quickly and come back. Take for example SPRING. Mentawai offers all you need to do IOC and AutoWiring. This is not rocket science and there are many other frameworks out there that do that: Guice, Pico, etc. Instead of telling our users: "Hey, go here and learn Spring, then come back!" we offer them a very easy, efficient and straightforward solution for IOC and auto-wiring. http://www.mentaframework.org/ioc.jsp http://www.mentaframework.org/depinj.jsp

  26. Precisely. I find your example much more complex than its Stripes equivalent ! You need 3 classes to do stuff that's done in a dead simple action... or am I missing something ?


    Which example are you talking about?

    You don't need three classes. You need as much as ONE class: the action or the POJO that will handle the request.

    In Mentawai you place all configuration, all setup, all wiring, all ioc, etc. inside the ApplicationManager.java file. Instead of having a centralized XML file like struts, it has a centralized PROGRAMMATIC file in Java. Could be BeanShell, Ruby, Groovy, etc.

    In Stripes you will scatter all the configuration across all the code across a bunch of annotations. Serious, not the worst thing, but I would rather organize this, keep my code decoupled from the framework being used and centralized in the ApplicationManager.java class.

    Note that any change in an annotation in an action will probably force a full re-deploy of the application JAR/WAR. If you have a separate class for the configuration, then you only need to re-deploy that class. The class can even access some dummy properties for stuff like DB URL Connection, contact emails, and that more static configuration info.

    The configuration part is important. Some innocent people believe that you can code a serious web project all based on conventions. This is so not true. It is also very limiting. At some point you will have to get your hands dirty and CONFIGURE, SETUP, AUTO-WIRE, etc.

    However this is not even the most important topic when it comes to web frameworks. XML x Annotations x Java x DSL is not the most important thing.

    The most important thing is: ABSTRACTION. Don't make me thing about anything and don't direct me to other frameworks. Let's avoid the Java Framework Salad.

    A single framework for all your needs !!! That's the goal of Mentawai (and also of RoR). It is just not competing with Hibernate, although it offers a simple CRUD ORM solution for those who are using pure JDBC and would take some help in building SQL queries. Hibernate as much as Spring is NOT something that you go learn quickly and come back.

    Take for example SPRING. Mentawai offers all you need to do IOC and AutoWiring. This is not rocket science and there are many other frameworks out there that do that: Guice, Pico, etc.

    Instead of telling our users: "Hey, go here and learn Spring, then come back!" we offer them a very easy, efficient and straightforward solution for IOC and auto-wiring.

    http://www.mentaframework.org/ioc.jsp

    http://www.mentaframework.org/depinj.jsp
    The vast majority of Stripes users already know Spring... So, Was the problem? Trying to learn another IoC approach can be a pain in the ass. Another point: Stripes Community already developed plugins for IntelliJ and NetBeans Integration (for an unknow reason anyone developed a Eclipse plugin yet) so you can develop a Stripes Application very quick and easy. Mentawai have IDE integration?
  27. It has a netbeans plugin. Somebody was doing an eclipse plugin. Not IntelliJ yet. But coming back to the main topic... :-) No!!!!! Learning a new IoC approach is not a pain in the butt. It should be as painful as it is to learn a KISS framework like Mentawai or Stripes. In other words this is easy stuff that any Java baby can grasp. If you checked those links you saw that this is very simple stuff. IMHO, you should not assume or require that Stripes users will know Spring. How about authentication? You tell them to go use JAAS? How about senting email? You tell them to go use Jakarta Commons? How about connection pooling? You tell them to go learn C3P0? This is the point of Mentawai. If offers all this stuff in a very simple way and for free. No need for Java Framework Salad anymore... :-)
  28. My last post in this thread[ Go to top ]

    A contradiction?
    No!!!!! Learning a new IoC approach is not a pain in the butt. It should be as painful as it is to learn a KISS framework like Mentawai or Stripes. In other words this is easy stuff that any Java baby can grasp. If you checked those links you saw that this is very simple stuff.
    few post before....
    A single framework for all your needs !!! That's the goal of Mentawai (and also of RoR). It is just not competing with Hibernate, although it offers a simple CRUD ORM solution for those who are using pure JDBC and would take some help in building SQL queries. Hibernate as much as Spring is NOT something that you go learn quickly and come back.
    By the way... Is KISS (great band, but I like more Narnia) writing another IoC/Security/ORM approach/library just for not make a Framework Salad (Salads are healthy)? or Is KISS using that already as proven, works great, have excellent support tool (IDE's, libraries, other frameworks), have zillions and zillions of documentation (blogs, forums, mailing list) and, the most important of all, armies of developers with experience?? I never work with Mentawai, so I can't say if is great or not, but I don't want to learn a new IoC/ORM/ approach. I already past the last year playing with Spring and his friends so if I want to examine some library or framework one of the things that I evaluate is "how well is integrated with Spring?". I don't want to Thrown away my experience with Spring. Sorry if I offend somebody, but I think that this Thread is something like "Mentawai Flame marketing Thread"
  29. Centralized configuration can be good for smaller projects, but as your project grows you will have to think up a way to split the configuration or you will have many people fighting over the same Class/configuration-file as in good old Struts days before sub apps. That said, I personally see limited value in having this kind of configuration centralized. I've done big (and painful) projects with Struts and a big project (around 350 ActionBeans with multiple event handlers) with Stripes, and have so far not missed being able to see all Actions and their result handling in one place. If you miss seeing the big picture, Stripes does provide a Site Structure Tool. It really blows my mind that many frameworks still use String identifiers (and later mapping) to indicate the outcome of an action. For what sake? You loose so much expressive power, when you can only return a String. What if I want to stream JSON back, stream an Image, XML or use some other view technology than JSP. Stripes approach by returning a Resolution instance (such as ForwardResolution, RedirectResolution, StreamingResolution, JavascriptResolution, etc.) works really effectively, expressively, easily extensible and is flexible. Regarding classpath scanning. It works really well and is fairly easy to implement (Stripes, Spring and Hibernate are all capable of doing it) and works well with Jars. We use it for a lot of stuff. Just to clear up what seems to be a misunderstanding. By default Stripes doesn't look for annotations when searching for ActionBeans, it instead looks for classes which implement the ActionBean interface. However, I do see some value in providing more features (like ORM, DI, etc.) without having to learn extra frameworks, but that's not the focus of Stripes. Stripes' focuses on creating the best Action based MVC framework for Java and so far it's looking good. Let other it leaves for frameworks such as Stripernate or our upcoming framework. /Jeppe
  30. There is no contradiction. Mentawai offers you IOC and Auto-wiring, the same way Spring offers you that, Guice offers you that, Pico offers you that, etc. What I was saying is that we don't offer full stack ORM support, so if you have to learn another framework besides Mentawai, I would recomment Hibernate. Or you can just do like me: use pure JDBC + SQL + an sql builder like MentaBeans (that comes with Mentawai) or something else.
    I already past the last year playing with Spring and his friends so if I want to examine some library or framework one of the things that I evaluate is "how well is integrated with Spring?". I don't want to Thrown away my experience with Spring.
    Mentawai has full integration with Spring for people like you, that loves Spring or have spent time learning it: http://www.mentaframework.org/spring.jsp
    Sorry if I offend somebody, but I think that this Thread is something like "Mentawai Flame marketing Thread"
    You did not say the same thing about the Stripes posts, right? I am presenting arguments. Feel free to present yours.

  31. Sorry if I offend somebody, but I think that this Thread is something like "Mentawai Flame marketing Thread"


    You did not say the same thing about the Stripes posts, right? I am presenting arguments. Feel free to present yours.
    Community (a very enthusiastic one): 6 Stripes community members (including the Author, developers and users) making 12 post. Marketing : 1 Author (a very enthusiastic one) making 13 post about his Framework
  32. Marketing : 1 Author (a very enthusiastic one) making 13 post about his Framework
    I don't intend to convince the Stripes community to use something else. I did not say: "Struts dead... long live Stripes, did I? I am presenting solid arguments. Some people are responding with other arguments. Some other people are making fun...
  33. Centralized configuration can be good for smaller projects, but as your project grows you will have to think up a way to split the configuration or you will have many people fighting over the same Class/configuration-file as in good old Struts days before sub apps.
    Mentawai offers you a simple way to break up the ApplicationManager into multiple files. This is call MultiApplicationManager. Plus this is not XML or Annotation. This is POWERFUL and FLEXIBLE code. That's why it is called PROGRAMMATIC CONFIGURATION. You are free to do whatever you want to do with it. Create block, loops, if, methods, inheritance, you name it... Total flexibility!
    It really blows my mind that many frameworks still use String identifiers (and later mapping) to indicate the outcome of an action. For what sake? You loose so much expressive power, when you can only return a String. What if I want to stream JSON back, stream an Image, XML or use some other view technology than JSP. Stripes approach by returning a Resolution instance (such as ForwardResolution, RedirectResolution, StreamingResolution, JavascriptResolution, etc.) works really effectively, expressively, easily extensible and is flexible.
    You missed something here. An action returns a STRING which Mentawai calls RESULT. For each result you can have a different CONSEQUENCE. And you can be damn sure that we have a StreamConsequence, Forward, Redirect, Chain, AjaxConsequence, JasperConsequence, etc. Mentawai has easy integration with Velocity as well... A forward can be to any file, not just to a JSP page, right?
    Regarding classpath scanning. It works really well and is fairly easy to implement (Stripes, Spring and Hibernate are all capable of doing it) and works well with Jars.
    We use it for a lot of stuff.

    Just to clear up what seems to be a misunderstanding. By default Stripes doesn't look for annotations when searching for ActionBeans, it instead looks for classes which implement the ActionBean interface.
    Agree. Scan the whole classpath looking for actions is a way of doing it. I prefer registering the packages where my actions will be and let the controller look and load them in the request-time instead of scanning everything before hand. If you add something new it will have to re-scan everything.
    However, I do see some value in providing more features (like ORM, DI, etc.) without having to learn extra frameworks, but that's not the focus of Stripes.
    Stripes' focuses on creating the best Action based MVC framework for Java and so far it's looking good.
    RoR is doing this. Many people complain about the Java Salad. For newcomers (new people with Java and web development) it is definitely not good. The focus of Stripes is to be the best Action based MVC framework for Java. I agree it is doing a good job. I seriously like Stripes. The focus of Mentawai is to be a very good Action based MVC framework focused totally in SIMPLICITY, JOY and PRODUCTIVITY. With Mentawai, you just get the work done, very fast, with joy and simplicity. Period. :-) You don't need to go learn a bunch of other frameworks. It offers you all the solutions to the repetitive tasks of every web project! How does stripes handle Authorization, Authentication, Sending Email, Connection Pooling, etc? You can just say that: "this is not the focus of stripes" and you will be right! But you must agree that this is basic stuff of every web project!
  34. Stripes does this inside its actions: return new ForwardResolution("/quickstart/index.jsp"); IMHO this is not good. Not the end of the world but definitely not good. Why you hard code the view layer inside your action ??? How easy it is for you to have the same action having two different views ??? For example: One view for testing, one view for production, another view for something else, etc. With Mentawai (and even Struts) you have a total separation of concerns. Isn't that what MVC is about? That's the advantage or returning a RESULT/STRING that will be mapped somewhere else (CENTRALIZED configuration) to the real consequence. Again this does not make Stripes bad or good. This is just minor details. The big picture, the philosophy of Stripes is very good. That is what matters I think.
  35. The interesting difference[ Go to top ]

    Let's for a moment forget about Stripes, Struts1/2, Seam, Mentawai, etc. and the feelings about them (though my samples will be using Stripes, since it's the only Java based MVC framework I know that offers what I need to explain my points). Personally the most interesting part of this discussion, is this key difference in architecture and abstraction. When you settle for only using Strings to determine the outcome of an event/action/handler (each framework calls it something different) in an Action/Controller, then you limit your expressiveness, abstraction and you loose a lot of the flexibility that lies in making the key Domain (Driven) abstraction (we call it Resolution you call it Consequence if I remember correctly). If you only allow Strings as result, then you force people into world view where there the need for the separation of concerns (outcome vs. consequence) is always needed (though it might be automated by convention). In most applications I've worked with this has rarely been needed. Why not? Because most of them only had one client type (browser) and differences between browsers were handled in the view generation. A different view selection, depending on production or test mode, has only been needed in rare circumstances, which certainly doesn't warrant a general solution for a single or a few cases. Having multiple clients (like WAP, cHtml and HTML) for the same Action/Controller might occur, but in my experience the Page flow is often very different between them, typically because of limited screen size, which force you to compose the application flow differently. So here the centralized approach looses it advantage. So if you in most cases have only one view for each outcome, then the best solution to me, is to keep this information local/decentralized. Stripes allows me to do this by using Resolutions, such as return new ForwardResolution("/quickstart/index.jsp"); or return new RedirectResolution("/quickstart/index.do");. The coupling is harder than a centralized approach, but then again if you rarely need to differentiate, then I would say that a decentralized solution has higher coherence (configuration lies with the code, the link between the two is easy to establish). This coupling/coherence measurement of course really depends on what your needs are. What if you suddenly want to change from jsp to say velocity? That happens so rarely, that chances are your work in replacing the views will be much larger than going in and changing your Resolutions. Again if all that's changed is the file extension, you could quickly solve the problem in Stripes using an Interceptor, which should be applied before the Resolution is executed. If you really have the need of multiple clients, then in a framework which abstracts the outcome of an event in an Action/Controller, you have at least two options of solving the problem: - You can either go for a custom resolution like return MultiViewResolution("/quickstart/index"); and then the MultiViewResolution could decide which view it should render depending on the client, such as /quick-start/index-html.jsp, /quick-start/index-xhtml.jsp, /quick-start/index-wap.jsp and so on. Introduce a new client type and given a strong convention, then all you need to change is the MultiViewResolution. This is what I call a meet-in-the-middle solution. - If you really want to centralize configuration, for what ever need you might have that justifies this (again as I wrote in the previous post I've so far only come across few developers that have truly needed this), you could just go with your own MappedResolution, return new MappedResolution("success");, and then leave it up to an interceptor (as mentioned above) to call what ever mapping code you want (like you I prefer mappings like those to be done in code and not XML). In Stripes that's probably more work than in Mentawai (because Stripes doesn't see the need for this and therefore haven't provided a general abstraction to this rare problem), but as I wrote, in my experience that's rarely needed. If you don't need it, then don't force it. If you have the right abstraction for the outcome of an Action/Controller event, then you have more options at hand. That's why having an abstraction is good. A String is a less powerful abstraction than a Resolution. A Resolution allows encapsulation (for instance the Object to be serialized to JSON by a JavascriptResolution), a String doesn't. You can go for the decentralized solution of mapping it in the Action/Controller, the centralized solution of mapping it some central piece of configration code, or you could go for the sweetspot in the middle, where you let the outcome abstraction handle it for you. Choice, flexibility, encapsulation and expressiveness :) /Jeppe
  36. Plus this is not XML or Annotation. This is POWERFUL and FLEXIBLE code. That's why it is called PROGRAMMATIC CONFIGURATION. You are free to do whatever you want to do with it. Create block, loops, if, methods, inheritance, you name it... Total flexibility!
    Well, IMHO, it's even more FLEXIBLE when... you just have NOTHING to do :-)
    You missed something here. An action returns a STRING which Mentawai calls RESULT. For each result you can have a different CONSEQUENCE.
    ... and a config file (be it XML or Java or whatever you want) !
    A forward can be to any file, not just to a JSP page, right
    Hence the Resolution base class. Abstraction, ya know...
    If you add something new it will have to re-scan everything.
    So do you, with Mentawai : you'd need to redeploy for any change in any class. Even a validation constraint. I don't see how you can escape that (unless using hot class reload third party libs), as this isn't implemented by any app server on the market). Oh, and for the 3 classes I was referring to : * the "config" class * the action class * [validation stuff in Java]* So 3 classes at least. 1 action (probably about 30 LOCs) in Stripes. And no config AT ALL !
    Stripes' focuses on creating the best Action based MVC framework for Java and so far it's looking good.
    RoR is doing this.
    Clearly not ! It even has a persistence layer, come on ! RoR includes an MVC, but it is clearly full stack.
    It [Mentawai] offers you all the solutions to the repetitive tasks of every web project!
    C'mon... You can't be serious ??? Ah ! I get it ! All this is a troll !!! ;-P
    How does stripes handle Authorization, Authentication, Sending Email, Connection Pooling, etc? You can just say that: "this is not the focus of stripes" and you will be right! But you must agree that this is basic stuff of every web project!
    Connection pooling in a Web Framework ??? Yeah it's a troll... :-D Now, if you're serious and wanna see more of what a full stack is, check this out : http://woko.wiki.sourceforge.net Stripes-powered :-) Cheers Remi
  37. You make fun instead of being serious. I like to keep some manners, even when I am talking to someone remotely.
    Well, IMHO, it's even more FLEXIBLE when... you just have NOTHING to do :-)
    So why do you need Annotations in stripes? Let's just use CoC for everything, right? Don't be innocent. Here is what I have already said about this: "The configuration part is important. Some innocent people believe that you can code a serious web project all based on conventions. This is so not true. It is also very limiting. At some point you will have to get your hands dirty and CONFIGURE, SETUP, AUTO-WIRE, etc"
    Resolution base class. Abstraction, ya know...
    Resolution base class? I am talking about something else. I am talking about the view is hardcoded inside the action. This has ZERO to do with abstraction or base class.
    So do you, with Mentawai : you'd need to redeploy for any change in any class. Even a validation constraint. I don't see how you can escape that (unless using hot class reload third party libs), as this isn't implemented by any app server on the market).
    Think again: DSL, Groovy, BeanShell, JRuby. Dynamic configuration through a dynamic language. Mentawai supports out-of-the-box BeanShell and Groovy: http://www.mentaframework.org/configuration.jsp
    Oh, and for the 3 classes I was referring to :
    * the "config" class
    * the action class
    * [validation stuff in Java]*

    So 3 classes at least.
    Thanks, but you are mistaken. The config class ApplicationManager.java is just ONE. So you have one config for 1000 actions (centralized config). The validation can be done inside the action again, but through CODE not thru crazy annotations. The action just need to implement Validatable! Check here: http://www.mentaframework.org/validation.jsp How can Stripes apply the same validation for 2 different actions? It can't right? Mentawai offer both things: A filter to do validation, so you can apply the same validation to different actions and the validatable interface for the case that you want to place the validation inside the action.
    Clearly not ! It even has a persistence layer, come on RoR includes an MVC, but it is clearly full stack.


    It [Mentawai] offers you all the solutions to the repetitive tasks of every web project!


    C'mon... You can't be serious ???

    Ah ! I get it ! All this is a troll !!!
    ;-P
    I am not a troll. I usually show respect for other's people work. I hope you are not part of the Stripes team. I am sure the project (which I told many times is very good) would lose respect by having someone making those kind of comments.
    Connection pooling in a Web Framework ???
    Yeah! You definitely missed the point here. This is not another MVC controller. This is a full stack solution. A lot of people are using it. Cheers!
  38. You make fun instead of being serious. I like to keep some manners, even when I am talking to someone remotely.
    So do I. But seriously, you're talking about arguments : I have already given you a lot of them, but it's like talking to a wall... I'll give it a last shot...
    So why do you need Annotations in stripes? Let's just use CoC for everything, right? Don't be innocent.
    Mentawai has a centralized config. Stripes doesn't. Stripes 1 - Mentawai 0
    Resolution base class? I am talking about something else. I am talking about the view is hardcoded inside the action. This has ZERO to do with abstraction or base class.
    One indirection less. All in one place. KISS. And if you need it, you can externalize, but nobody does : in practice, it's useless. Stripes 2 - Mentawai 0
    Think again: DSL, Groovy, BeanShell, JRuby. Dynamic configuration through a dynamic language.
    C'mon... Your actions, validators etc are written in Java ! I'm not talking about changes to the config file only !
    Thanks, but you are mistaken. The config class ApplicationManager.java is just ONE. So you have one config for 1000 actions (centralized config).
    PLEASE !!! Your example has 3 classes where Stripes has only 1. Of course I understood there's only one config class, thanks !


    The validation can be done inside the action again, but through CODE not thru crazy annotations. The action just need to implement Validatable! Check here: http://www.mentaframework.org/validation.jsp
    Man, you must have had a really, really bad experience with annotations ! Why so much hate ??? Look : class MyStripesAction ... { @Validate(required=true,max=50) private String strProp; // + get/set } vs. class MyMentawaiAction implements Validatable { private String strProp; // + get/set // mentawai callback public void validate(...) { if (strProp==null) { // push error message } else if (strProp.length()>50) { // push error message } } } (the link you sent for the validation led me to an empty page with a title only so I don't know about the contract for validatble, but I guess you'll figure out what I mean) What's the most KISS ? Not mentionning the metadate conveyed by the annotation, which is impossible to get with the "code" version. Stripes 3 - Mentawai 0
    How can Stripes apply the same validation for 2 different actions? It can't right? Mentawai offer both things: A filter to do validation, so you can apply the same validation to different actions and the validatable interface for the case that you want to place the validation inside the action.
    That point makes sense. I reckon that this is where annotations start to be painful, and lead to crazy workarounds... We also have the Validatable concept in Stripes (Validation Methods), but I don't know about the filter. So I'd give a draw here : the annotations in Stripes are what you need for a vast majority of cases, and Mentawai doesn't seem to have a simple solution like this. But the filter thing is cool as well...
    I am not a troll. I usually show respect for other's people work. I hope you are not part of the Stripes team. I am sure the project (which I told many times is very good) would lose respect by having someone making those kind of comments.
    I was joking, get boogie woogie a little please ! I never meant you were a troll (even if the idea makes me laugh behind my keyboard to be honest ;-P)... http://en.wikipedia.org/wiki/Internet_troll Yes I am part of the Stripes team. And yes I show respect to other's work. And you see, I'm still here to argue with you, even if you don't even really read my posts, or even worse, try to make me say what I did not say ! So please stop playing the offended guy. You are also very agressive on the comments (the CAPITAL WORDS read like somebody SHOUTING instead of just talking), and you have avoided answering to several technical points I've raised. There's no Mentawai conspiracy, it's just that we Stripers couldn't resist to compare our favourite with its grand pa ! Generation conflict maybe ;-P And it's not because you post your replies LOUDER that we're gonna buy your stuff. Last, I don't see why my babblings on TSS could have any influence on Stripes. Developers are looking for efficient solutions, not for friends. That said, the Stripes ML rocks :-)
    Yeah! You definitely missed the point here. This is not another MVC controller. This is a full stack solution.
    Yeah : it even does the job of an app server !! Amazing ! You should have called it JEE :-) Cheers Remi
  39. I am reading your posts. We just have opposite opinions for some stuff. That does not mean one is right while the other is wrong. We both can be rigth. This is NOT math. I will present my arguments and let the reader choose for himself.
    Mentawai has a centralized config. Stripes doesn't.
    Centralized config is better in my opinion. Scattering the configuration all over the place though annotations is not good in my opinion. Most important than that is how you configure. I and some other people like Martin Fowler believe that programmatic configuration is the way to go. More info about this here: http://book.mentaframework.org/posts/list/5.page
    One indirection less. All in one place. KISS. And if you need it, you can externalize, but nobody does : in practice, it's useless.
    Hardcoding the viewlayer in the action is not good. Maybe because you are scattering the configuration all over the place through annotations you don't care. With Mentawai I can return SUCCESS and go by the conventions. Then I can later on add a new consequence for the SUCCESS, changing the JSP page. Or I can add a global consequence. Filters will return RESULT (String) as well, not the whole object. This is NOT good. This is my opinion. If you don't agree I can respect that.
    Your actions, validators etc are written in Java ! I'm not talking about changes to the config file only!
    Validation has to be written somewhere. Annotations-programming or XML-programming is not the way to go in my opinion: check how simple this is here: http://www.mentaframework.org/validation.jsp (you can code a separate validation filter or have your action implement Validatable, the best of both worlds!)
    Your example has 3 classes where Stripes has only 1.
    You are still missing something. I have only the action. Validation can be done inside the action with an interface. I am missing the other two classes. Don't say it is config because you said you already understood there is only one config.
    Man, you must have had a really, really bad experience with annotations ! Why so much hate ???
    There is no hate. I think is a valid approach, but as with XML it can be abused. You probably know how struts tries to do validation through annotations. That is HELL: http://struts.apache.org/2.x/docs/validation-annotation.html
    (the link you sent for the validation led me to an empty page with a title only so I don't know about the contract for validatble, but I guess you'll figure out what I mean)
    http://www.mentaframework.org/validation.jsp (wait a little bit, it will load the iframe, or check here: http://docs.mentaframework.org/posts/list/7.page Stripes is cool. I like it. It is not because it uses annotations that it will be better or worse than anything. Long live for Mentawai, Struts and Stripes! A lot of people are using Mentawai as a lot of people are using Struts as a lot of people are using Stripes. You can check Mentawai success cases here: http://forum.mentaframework.org/posts/list/143.page And you can start reading Mentawai in Action here: http://book.mentaframework.org/ Keep up the good work with Stripes. The more frameworkw and the more competition, the better it is for the frameworks and for the community!
  40. RE: The interesting difference[ Go to top ]

    A Resolution allows encapsulation (for instance the Object to be serialized to JSON by a JavascriptResolution), a String doesn't
    You are just missing the most important point. Mentawai Architecture: Aciton -> Result (String) -> CONSEQUENCE (Interface) action(HelloAction) .on(SUCCESS, fwd("/hello.jsp")) .on(PDF, stream("application/pdf")) .on(SHOW, chain(showAction, "show")); What you call resolution, in Mentawai is the core interface Consequence. If Resolution in stripes is an Interface (which I see it is, the only different is that it only takes req and res while mentawai takes req and res and the action), then it is very similar to Mentawai, the different being that Stripes returns the whole object, and mentawai return the RESULT that will map to the object. As I said before: "With Mentawai I can return SUCCESS and go by the conventions. Then I can later on add a new consequence for the SUCCESS, changing the JSP page. Or I can add a global consequence. Filters will return RESULT (String) as well, not the whole object. Returning the whole object is not good. This is my opinion. If you don't agree I can respect that." Mentawai, pretty much like Stripes and Struts, I would believe, comes out-of-the box with Forward, Redirect, Chain, Stream, NullConsequence, Ajax, StringConsequence, etc. Plus any Java baby can create its own consequence (only one method!) like other people have done to integrate with Jasper, Lazlo, etc. Again this will not make Stripes or Mentawai or Struts better or worse than anything. I measure success by productivity. Getting work done fast and with quality, even for someone that knows nothing about the framework! If Stripes can provide that, than it is a successful framework!
  41. I realize that you MAP the String result to a Consequence. My point is that when you use a String to indicate mapping from the Action/Controller ONLY allow mapping through a mapping class (centralized), where as a framework that uses an outcome abstraction (Resolution/Consequence) as part of the event handler methods contract, allows you to perform this mapping in the Action/Controller (decentralized), the outcome abstraction(meet in the middle) and in a Mapping class (centralized). The abstraction and the way its used allows you greater flexibility. So instead of public String handleEvent() {} you can use public Resolution handleEvent() {} This also allows you to encapsulate data to be transferred directly in the Resolution object. If you use a String a outcome when you will have to store the value to be transferred elsewhere (ActionBean/Controller if it's a not a singleton, some Context, Request attributes, etc.), which might/might not make sense depending on your needs and design. Again in you sample, how many times to you really have multiple outcomes. Either you have an error (say invalid data) in which case I hope the framework can redisplay the input page or else you perform the success outcome. In that case, there's little point in forcing this error/success mapping into a central mapping class for all sakes. Even though you have conventions that allow you to avoid this in most cases, by main point is that having String as return value from your event handler is a less good design. I wont comment on what conventions or how to access the ActionBean from the Resolution, since this isn't core to the problem I'm talking about. /Jeppe
  42. oh no[ Go to top ]

    [quote]class MyMentawaiAction implements Validatable { private String strProp; // + get/set // mentawai callback public void validate(...) { if (strProp==null) { // push error message } else if (strProp.length()>50) { // push error message } } } [/quote] is that for real??? it may otherwise be a decent framework but that is just straight up bad. This is exactly what annotations were invented for! Use them! A significant side effect of using annotations is runtime reflection, =) gasp!
  43. Re: oh no[ Go to top ]

    [quote]class MyMentawaiAction implements Validatable {

    private String strProp; // + get/set

    // mentawai callback
    public void validate(...) {
    if (strProp==null) {
    // push error message
    } else if (strProp.length()>50) {
    // push error message
    }
    }
    }
    [/quote]

    is that for real??? it may otherwise be a decent framework but that is just straight up bad. This is exactly what annotations were invented for! Use them!

    A significant side effect of using annotations is runtime reflection, =) gasp!
    Don't really know : the link Sergio sent about validation was not displaying anything (I'm running safari maybe it's the problem). But I guess that's hos the validation callback works... and that's what you'd do in a validation method in Stripes... if you didn't have the annotations at hand ! Annotations for simple things, but more power if needed with validation methods... Cheers Remi
  44. Re: oh no[ Go to top ]

    Calm down my friend. This came from his head, not from our framework. Check here: Validation using a interface: http://recipes.mentaframework.org/posts/list/4.page Validation using a separate filter: http://recipes.mentaframework.org/posts/list/3.page Validation using Struts2: (xml-hell: mix Java and XML together) http://struts.apache.org/2.x/docs/validation.html Validation using Struts2: (annotation-hell) http://struts.apache.org/2.x/docs/validation-annotation.html Mentawai was not born yesterday! It has been there for almost 3 years now. Go check the official source and you will be surprised!
  45. It really blows my mind that many frameworks still use String identifiers (and later mapping) to indicate the outcome of an action.
    Yeah ! Especially when the framework's devs. do the "abstraction level" talk ! :-) Anyway. Cheers Remi
  46. It really blows my mind that many frameworks still use String identifiers (and later mapping) to indicate the outcome of an action.


    Yeah ! Especially when the framework's devs. do the "abstraction level" talk !
    :-)

    Anyway.

    Cheers

    Remi Does that mean you are out of arguments? Hopefully the guys behind Stripes will not show this kind of disrespectful behavior. Take it easy my friends. Cheers!
  47. Yeah ! Especially when the framework's devs. do the "abstraction level" talk !
    Does that mean you are out of arguments? Hopefully the guys behind Stripes do not have this kind of disrespectful attitude. Present arguments or please avoid this kind of comments. Take it easy my friends. Cheers!
  48. Strictly speaking, I believe that Struts2 is actually Webwork, so I would hesitate to say that Stripes necessarily has everything and more.
    The article is about the MVC part. And stricly speaking, Stripes beats the hell out of Struts2 (or webwork or whatever the name), hands down ! And when it comes to the over bloated "stuff" that comes around their ugly MVC (e.g. templating, clean URLs and the like), well, it's even worse... There are many "full stack" frameworks out there that are way better and go way beyond that. That's why I said it seems to be lost in between a MVC only and a full stack framework... Cheers Remi
  49. One of my friends suggested me use UrlRewriteFilter, which is a tool just like Apache's mod_rewrite [see the following url:http://tuckey.org/urlrewrite/].I tried it for SEO concern and found it cool. Can it, namely SmartURLs work with UrlRewriteFilter? Thx.
  50. SmartURLs[ Go to top ]

    Hi , I need some help with UrlRewriteFilter for my struts2 app using tiles. ^/test1\.html$ test-2-2.html the above rule works from the ROOT dir of the app with a link like this "< a h r e f="" > test< / a> " but it tails with .action in address bar I need a rule to clean the url http://www.../page_view.action?id=23432 should be like this: http://www.../page/23432 I have this rule : /page/([0-9]+)$ %{context-path}/page_view.action?id=$1 but I don't want the redirect, if I remove the redirect in then Iam getting "HTTP Status 404 -" can you please help me resolve this issue, Thanks