Stripes 1.4 Released

Discussions

News: Stripes 1.4 Released

  1. Stripes 1.4 Released (42 messages)

    Stripes 1.4 has been released. Stripes is a web application framework configured by annotations and using auto-discovery mechanisms where applicable. Major changes in this release include: • Improved handling of alternative character set encodings for non-default locales • Support for advanced generic type information in property binding, including nested generics declarations (e.g. Maps of Maps of Lists), type variables and wildcard types • Full support for including ActionBeans (in addition to requesting and forwarding) • File upload/multipart parsing code is now pluggable with the choices of a COS and a Commons File Upload implementation shipped with Stripes • Improved Spring integration: Stripes can now inject beans using field access and can additionally inject using non-public methods and fields if desired • Removal of the dependency on OGNL The removal of OGNL has significant benefits for users. Most obviously Stripes has one fewer dependency, which means easier installs and upgrades. In addition the re-implementation of the (small) subset of OGNL features used internally by Stripes has led to significant performance improvements. But perhaps most compelling is the fact that Stripes can now handle situations that were awkward at best and impossible at worst with OGNL including significantly better handling of Java 1.5 generics. The release also includes a number of smaller enhancements and bug fixes. The full list of changes is available in the JIRA Change Log. You can read more about Stripes and pick up the new release on the Stripes Website. Message was edited by: joeo@enigmastation.com

    Threaded Messages (42)

  2. It's simple to use. It IS intuitive, what you think will work most likely does. It's flexible, and simply stays out of your way. I was quite impressed at how quickly the framework itself melted away once you get up to speed on it, at least for my simple application. Finally, it's a classic web application action framework. It's not square pegging components into the round hole of the HTTP web app model. The component frameworks are popular, and powerful. But they are very complex and intricate. There's a lot of stuff to understand from action processing to rendering etc. Rather, Stripes handles the request processing cleanly and elegantly. It relies on simple annotations and defaults for configuring and helping bind requests to actions. And it relies on whatever presentation layer you want to use, and happens to work quite well with JSP and JSTL. If you're considering Struts for a new project, I'd strongly suggest looking at Stripes first. It's simply more modern, with less baggage, and much easier to use. Thanx Tim!
  3. If you're considering Struts for a new project, I'd strongly suggest looking at Stripes first. It's simply more modern, with less baggage, and much easier to use.
    Good luck with maintenance of such project when it grows. The component frameworks are here not because someone though it would be cool to have them, but because they address real issues and solve real problems.

  4. If you're considering Struts for a new project, I'd strongly suggest looking at Stripes first. It's simply more modern, with less baggage, and much easier to use.

    Good luck with maintenance of such project when it grows. The component frameworks are here not because someone though it would be cool to have them, but because they address real issues and solve real problems.
    I guess all of us who are building and maintaining large sites based on action frameworks are just wrong, huh? Silly us. Obviously the plethora of huge sites and applications built on JSF has proven us woefully ignorant.
  5. I guess all of us who are building and maintaining large sites based on action frameworks are just wrong, huh? Silly us. Obviously the plethora of huge sites and applications built on JSF has proven us woefully ignorant.
    Just as 'wrong' as all the applications written in Cobol :)
  6. Just as 'wrong' as all the applications written in Cobol :)
    You mean the one your bank relies on to manage your money at the time you post ? ;-P IMHO, and many people tend to forget this, the web is *simple*. Applications I use on a daily basis in my browser all have a *simple* User Interface, that even my mom can understand... They're not about "Open the Java perspective" and such stuff we also use every day, which obviously can't be done in the browser yet (please don't !). Well, that's why Stripes is cool : it's *simple*, and it works. And people understand it, which IMHO is a better productivity factor than the most technically advanced framework. Have fun, Remi
  7. Well, that's why Stripes is cool : it's *simple*, and it works. And people understand it, which IMHO is a better productivity factor than the most technically advanced framework.
    Ya know, I can't say whether Stripes or any other framework can "scale" to some unknown enormous web application or not. But I can say that not every application needs to be enormous or scalable. A simple example. At some point if you're writing a simple application, you're going to decide whether to use pure Model 1 JSP or go to Model 2. I think many would agree that, as much as it's panned in the Community, the JSTL SQL tags have a place in JSP development for "simple applications" in the Model 1 style. But there is a burden to adopting Model 2, and the gains of the advantages of using a Model 2 architecture need to be greater than the burden of using it in the first place, particularly if you're inexperienced with platform. Simply put, the the price to pay for using a Model 2 architecture using Stripes is VERY low. Cut and Paste some simple config XML to setup the container, toss in 2 jar files in to your WEB-INF/lib (3 if you want file upload), and then write your Action as a POJO, and boom -- you're off and running. You don't even need to annotate it for default behaviors. The hardest part is learning to name your class, and it's not a real leap. It's not a home run framework, trying to cover all the bases of web app development, it's just a simple engine that easily manages getting data in to and out of HTTP Requests.
  8. IMHO, and many people tend to forget this, the web is *simple*. Applications I use on a daily basis in my browser all have a *simple* User Interface, that even my mom can understand...
    I would love to see your mom log on to my intranet with a browser and create a new workflow for routing merchandise between warehouses. The web stopped being about simple application with simple interfaces a long time ago, wake up.
  9. I would love to see your mom log on to my intranet with a browser and create a new workflow for routing merchandise between warehouses.
    I'd love that too... I bet she'd find bugs :-)
    The web stopped being about simple application with simple interfaces a long time ago, wake up.
    Sure. Look at what sales. Frightening UIs that nobody knows how to use. Google... MySpace... Web2.0 crap... IMHO (and I have a pretty good idea of what you talk about, I've coded several in-browser intranet stuff myself), when you have too many interactions and too complex screens, views, popups, menus, etc... nothing can beat a good old windowed app ! Would you use a JavaScript-powered eclipse ? Do you even think about it ? Ever tried FCK or such bullshit ? Do you also turn off "Rich editing" ? ... Sure, you can build a house with matches and glu. It's just longer and more painful than building it with stone. Have fun, Remi
  10. Frightening UIs that nobody knows how to use. Google... MySpace... Web2.0 crap...
    You really think that's crap? Google (Gmail, the calendar, the spreadsheet, maps), Flickr, LastFm etc. I just love them! Btw, they're still not close to the kind of complexity I was talking about.
  11. You really think that's crap? Google (Gmail, the calendar, the spreadsheet, maps), Flickr, LastFm etc. I just love them! Btw, they're still not close to the kind of complexity I was talking about.
    No no mate, I was ironic, I precisely mean that these apps *are* sucessful in part *because* they are simple ! Have fun, Remi
  12. You mean the one your bank relies on to manage your money at the time you post ?
    ;-P

    Exactly! There are probably an amazing number of famous web sites, written in the most horrible inbred languages and frameworks, that just work. I've worked for quite a few financial institutions myself, including banks, and I can definitively confirm you better leave the guts of many of the systems employed there unexposed. But it works. Not exactly an argument in a software development discussion though, unless the alternatives don't work.
    IMHO, and many people tend to forget this, the web is *simple*. Applications I use on a daily basis in my browser all have a *simple* User Interface, that even my mom can understand...
    I only wish I could agree with that. To a certain degree you are right if you only consider the public facing apps. Public facing sites however, are just a small fraction of the number of web applications developed/ employed today; there's a whole (hidden?) world of applications used by companies internally, or exposed to only registered users (schools, doctors, government bodies). It's the standard to develop systems for an browser interface nowadays. And I can only tell from my own experience and of the people and projects I know, but a lot of such applications have pretty complex user interfaces. Probably because they work on a more complex data model, often are rewrites of older systems that were desktop apps, etc. The main reason I had to look for an alternative framework to model 2 (and I was involved in one some time ago, so I was actually going against my own stakes) was because we couldn't handle the complexity of the user interfaces well enough with them. In the end we managed for those projects, using hack-on-hack, but at the cost of ending up with a very inflexible end-result that cost much more to develop than if it would have been e.g. a Swing application.
    it's *simple*, and it works.
    That's the best recommendation for any framework, whether the internals are gory and complex or simple too. Simplicity for end users - at least for simple problems - is something all frameworks strife for obviously :)
  13. Exactly! There are probably an amazing number of famous web sites,
    TSS is a actually perl CGI... OK, it's working, but see how it's slooow ;-P
    I only wish I could agree with that. To a certain degree you are right if you only consider the public facing apps. [...]
    I can't agree with you there. The Web *is* all about "public facing" apps, that's its history !! The thing is that, corrupted by marketing and I-don't-know-which-ggand-of-gurus, *all* the client/server world has been assimilated to HTTP and HTML in a few years ! Honestly, the environment (HTTP, browser etc.) is probably the worst basis for client/server developement, which AFAIK is what you talk about (intranets etc.). All that shit because of port 80, what a pity from a technlological point of view (on the marketing side everything's much better of course). You know, I sweared myself that I'd never develop any intranet stuff in the browser excepted if I have no choice. Regular desktop programming (e.g. WebStart / EJBs) is much better there.
    The main reason I had to look for an alternative framework to model 2 (and I was involved in one some time ago, so I was actually going against my own stakes) was because we couldn't handle the complexity of the user interfaces well enough with them.
    I surely don't want to flame or offense, it's a real question : why didn't you go for a RCP / WebStart solution instead ?
    at the cost of ending up with a very inflexible end-result that cost much more to develop than if it would have been e.g. a Swing application.
    That's exactly the feeling I'm trying to express ;-P This is how I see things : * "Professional" users (like us with our IDE or "Mr Salesman" with his intranet, or "My Mom" with MS Word) have no problems in using complex interfaces since they do it by necessity, so they can afford learning a complex desktop app ; * "Internet users" use public facing applications that are simple and friendly to use, where you don't have to read any doc in order to get started (or worst : get trained !). I really think that using the right tool for the right job is wise. Have fun, Remi
  14. TSS is a actually perl CGI... OK, it's working, but see how it's slooow ;-P
    Erm... wasn't it built with Tapestry? Anyway, there are many reasons why a site can be (perceived) slow. In my experience, it's usually not due to the framework employed, though the language might make the difference if not properly optimized for.
  15. Erm... wasn't it built with Tapestry? [...]
    LOL ! I was joking, once again :-) Have fun, Remi
  16. The thing is that, corrupted by marketing and I-don't-know-which-ggand-of-gurus, *all* the client/server world has been assimilated to HTTP and HTML in a few years !

    Honestly, the environment (HTTP, browser etc.) is probably the worst basis for client/server developement, which AFAIK is what you talk about (intranets etc.).

    All that shit because of port 80, what a pity from a technlological point of view (on the marketing side everything's much better of course).
    There are some excellent technical reasons for such intranet apps though. Companies got tired of the maintenance burden of desktop apps. An intranet app is immediately available for any new employee/ visitor/ whatever to right away. It's far easier to build cooperating applications (like when you try to accomplish chain integration) using internet technology. Etc. It's not just marketing, really.
    This is how I see things :
    * "Professional" users (like us with our IDE or "Mr Salesman" with his intranet, or "My Mom" with MS Word) have no problems in using complex interfaces since they do it by necessity, so they can afford learning a complex desktop app ;
    * "Internet users" use public facing applications that are simple and friendly to use, where you don't have to read any doc in order to get started (or worst : get trained !).

    I really think that using the right tool for the right job is wise.

    Have fun,

    Remi
    Yeah. It always is. As an example, I worked on a project that provided general practitioners (doctors) a web interface on their client's administration, giving access to vital information like the history of medication, previous diagnoses, etc. Usually such practices are relatively small, e.g. 4 people. It was an actual problem for them to deal with the burden of maintenance. Their desktop system's provided support, but not nearly as direct (worst case meant a guy having to step in his car to fix some PC problem at the practice). Using a web interface fixed most of their problems. It also enabled them to share their information more easily with medicine providers and they could authorize other practices (who were sometimes using competing systems) to take over theirs while being on a vacation etc. I don't think an example like this is typical marketing BS.
  17. Re: Desktop vs Browser... again[ Go to top ]

    Companies got tired of the maintenance burden of desktop apps. An intranet app is immediately available for any new employee/ visitor/ whatever to right away. It's far easier to build cooperating applications (like when you try to accomplish chain integration) using internet technology.
    Hmmm, I still think that a solution using web start is a much better choice in these situations. You get all the advantages that you mention, and you really get a great UI experience. With JDK 1.6, you even get good integration with common desktop services.
  18. Maintenance[ Go to top ]

    We're really getting OT, but anyway...
    There are some excellent technical reasons for such intranet apps though. Companies got tired of the maintenance burden of desktop apps. An intranet app is immediately available for any new employee/ visitor/ whatever to right away. [...]
    Erf. I see what you mean, I remember an old C/S banking app with people travelling the whole France to install the stuff on... 8000 computers !!! Then, you pray that you did not left a big anywhere... pretty far from today's agile tendency ;-) But good news, deployment and upgrade is not a trouble any more in modern UI tools. Take WebStart for example, or other similar stuff. They have the advantages of what we use to call "fat client" (using the PC's power on the client side, limitating interactions with remote stuff, providing responsive and powerful UIs, etc) without the inconvenients (deployment and run-time dependencies mainly. Honestly, which one is the best VM in your opinion ? A JRE, or Firefox ? Have fun, Remi
  19. Re: Maintenance[ Go to top ]

    We're really getting OT, but anyway...

    Yeah. I'll try to make this my famous last post :) Sorry for hijacking the thread Tim!
    Take WebStart for example, or other similar stuff. They have the advantages of what we use to call "fat client" (using the PC's power on the client side, limitating interactions with remote stuff, providing responsive and powerful UIs, etc) without the inconvenients (deployment and run-time dependencies mainly.

    Honestly, which one is the best VM in your opinion ?
    A JRE, or Firefox ?

    Have fun,

    Remi
    Of course, a JRE. You just don't always have that choice. The project I'm working on now has a too great variety of systems it has to work on to be decently supported even with java web start (windows 95, older mac version, several unix variants). And as it will have tens of thousands of users, the fact that web start will fail more often than web browsers (because that's just a fact), is enough reason not to choose for that, even though everyone on the project would have preferred that if that were a feasible option.
  20. Platform issues...[ Go to top ]

    Of course, a JRE. You just don't always have that choice. The project I'm working on now has a too great variety of systems it has to work on to be decently supported even with java web start (windows 95, older mac version, several unix variants). And as it will have tens of thousands of users, the fact that web start will fail more often than web browsers (because that's just a fact), is enough reason not to choose for that, even though everyone on the project would have preferred that if that were a feasible option.
    That makes sense, yep. Once again, it remembers painful souvenirs. I have a few WebStarted apps running here and there and faced the JRE version/availability as well... even in intranets, sometimes you don't have control over the target platform. And anyway, there's no real solution : the crap is there, so we have to deal with it anyway... and to get back to the point : Stripes just makes that crap smell better :-) Have fun Remi
  21. I surely don't want to flame or offense, it's a real question : why didn't you go for a RCP / WebStart solution instead ?
    I would have loved to. Unfortunately, there would have been too many problems with users using old PCs/ OSses, Java installations going bad too often (that's just from experience), etc. So even though it would still have been an improvement compared to the old desktop application, the web application option was the best choice for our client.
  22. I don't think it's an action vs component framework issue. One thing I particularily like about RIFE and WebWork is that the configuration file gives you one central place for a roadmap to the web app. Nice thing to have when you're taking on a project that was written by others. I understand some people's talk of configuration hell but I do find that aspect to be necessary and useful for large projects. Question: does Stripes have way to see such an overview of the flow of the web app without having to go see in every source file what happens next? Congrats on the release and keep up the good work :-) Frederic
  23. I don't think it's an action vs component framework issue. One thing I particularily like about RIFE and WebWork is that the configuration file gives you one central place for a roadmap to the web app. Nice thing to have when you're taking on a project that was written by others. I understand some people's talk of configuration hell but I do find that aspect to be necessary and useful for large projects.

    Question: does Stripes have way to see such an overview of the flow of the web app without having to go see in every source file what happens next?
    As far as I know, this option has been added to Stripes a while ago. But this is not the point. The point is that there should be no "roadmap". The concept of "roadmap" or "flow" is foreign to the concept of free browsing. Trying to manage a strict flow for a web application is "square pegging" at larger scale than building a stateful webapp. Yes, there are some limited cases when strict flow is necessary, but in general, an application must be able to handle a user who jumps all around, using browser's address bar for direct navigation. A well-written flow limits user's ability to jump around, a bad-written flow simply crashes and buries the application. So in regards to your "the configuration file gives you one central place for a roadmap to the web app" my opinion is the following: there should be no "roadmap". There should be independent actions that visualize themselves by means of JSP pages or other view technology. So the only dependency in Model 2 framework should be a dependency of a view from its host action. Actions should not depend on each other, as well as views should not depend on each other. This gives you flexibility in building an application, and it gives a user freedom to browse around. Since actions are independent, you don't really need a "roadmap" in config file. Also, considering that Strips allows navigating to a view directly instead of going through an action, the "roadmap" in config file will not give you much unless it lists views as entry points too.
  24. Trying to manage a strict flow for a web application is "square pegging" at larger scale than building a stateful webapp
    ~michael++ If you want to do workflow apps, use a decent BPM tool/ framework, not just some half-baked user interface 'flow' solution. For the parts where strict flow is necessary, your user interface should be subject to that engine, not the other way around.
  25. sigh[ Go to top ]

    As far as I know, this option has been added to Stripes a while ago. But this is not the point. The point is that there should be no "roadmap".
    Why is it that when a person asks a simple question, so often a bunch of Wicket people invade the thread to give everything except the answer to the question? Where "everything" is a long-winded discussion about how wrong it is to ask that question? OK, OK, before you completely flame me, please, take a deep breath :-) Think about it for a second before you hit the "torch him!" button, because you're only going to prove my point further.
  26. Re: sigh[ Go to top ]

    As far as I know, this option has been added to Stripes a while ago. But this is not the point. The point is that there should be no "roadmap".


    Why is it that when a person asks a simple question, so often a bunch of Wicket people invade the thread to give everything except the answer to the question? Where "everything" is a long-winded discussion about how wrong it is to ask that question?

    OK, OK, before you completely flame me, please, take a deep breath :-) Think about it for a second before you hit the "torch him!" button, because you're only going to prove my point further.
    Let's count the threads where we actually did that. Probably three or four this year. Your name pops up quite a bit in threads where you - in a very decent fashion admitted - usually propose people should check out a framework different from the one the thread is about. Which is fine. Let's not get uptight about this. We never bitched about Wicket threads being hijacked, and in fact have quite open discussions now and then on the lists. Open development. Open discussion. The bitching we can do without, but everyone can have a grumpy mood now and then (Matej, were you grumpy yesterday?) :)
  27. Re: sigh[ Go to top ]

    The bitching we can do without, but everyone can have a grumpy mood now and then (Matej, were you grumpy yesterday?) :)
    Sometime ago on tss someone said that becoming a wicket user improved their sex life. Well, being a wicket committer has quiet the opposite effect :(
  28. Re: sigh[ Go to top ]

    The bitching we can do without, but everyone can have a grumpy mood now and then (Matej, were you grumpy yesterday?) :)


    Sometime ago on tss someone said that becoming a wicket user improved their sex life. Well, being a wicket committer has quiet the opposite effect :(
    I met my girlfriend on JavaOne, doing a presentation on Wicket :)
  29. Re: sigh[ Go to top ]

    Your name pops up quite a bit in threads where you - in a very decent fashion admitted - usually propose people should check out a framework different from the one the thread is about.<</blockquote> Now I'm hurt unless you tell me you've got the wrong person. Because you're implying that I spend my time going around telling people to use a different framework than what the thread is about, when in fact I'm against doing that. In fact, if you have a look at my last several posts, they are mostly encouraging words for the developers of the framework in question. The only time I remember questioning a framework was SLF4J, because I wasn't sure what the author was trying to do. And I asked the question nicely. You'll also notice in my posts that I've had some kinds words to say about your being helpful, Eelco. But if I'm wrong please correct me by giving me a (supposedly long) list of threads where I went in there and told people to use something else.
    Additionally, Michael is not a 'Wicket person' (though he's wicked alright), and in fact competes with his own framework. And his argument was a technical one, which hopefully didn't upset anyone.
    I never said that he was. I don't have anything against technical arguments, but I do become exasperated when everytime someone asks a question, the answer is don't ask that question because here's an essay on why it's wrong to want that feature. And, often, not always, but often, that kind of defensive attitude has come from someone of the Wicket community (not you). Anyway, I never did get an answer to my original question.. ;)
  30. Re: sigh[ Go to top ]

    Now I'm hurt unless you tell me you've got the wrong person.
    Sorry, I *did* get the wrong person. Should've checked that before I made that statement. Someone out there always shows up on threads promoting Rife. Which for the sake of clarity I think is fine: he always does that in a decent fashion rather than: 'this framework sucks, that one is much better'. If you recommend a framework as a reaction on issues people discuss in a thread, imo there is nothing to be upset about.
    Anyway, I never did get an answer to my original question.. ;)
    That was about whether Stripes supports externalized flow, right? It was OT to post about that I don't believe that's a must to have for web frameworks. I actually intended to defend Stripes in case it didn't. Unnecessary it seems :)
  31. Re: sigh[ Go to top ]

    Someone out there always shows up on threads promoting Rife. Which for the sake of clarity I think is fine: he always does that in a decent fashion rather than: 'this framework sucks, that one is much better'. If you recommend a framework as a reaction on issues people discuss in a thread, imo there is nothing to be upset about.
    Eelco, Frederic didn't even promote anything, he was just inquiring how Stripes handles centralized flow declaration. The examples he gave for clarity were indeed WebWork and RIFE.
  32. Re: sigh[ Go to top ]

    Someone out there always shows up on threads promoting Rife. Which for the sake of clarity I think is fine: he always does that in a decent fashion rather than: 'this framework sucks, that one is much better'. If you recommend a framework as a reaction on issues people discuss in a thread, imo there is nothing to be upset about.

    Eelco, Frederic didn't even promote anything, he was just inquiring how Stripes handles centralized flow declaration. The examples he gave for clarity were indeed WebWork and RIFE.
    Yeah, sorry about that. Damn, I have to say sorry at least once every TSS thread I participate in. I should try harder to resist even joining them :)
  33. Re: sigh[ Go to top ]

    And, often, not always, but often, that kind of defensive attitude has come from someone of the Wicket community (not you).

    Anyway, I never did get an answer to my original question.. ;)
    We (Wicket's committers) are a passionate bunch. :) We feel there is a lot to 'battle' about and seriously regret the state some areas of JEE is in. The EJB problem is 'fixed' with the advent of Spring, Hibernate, JDO etc (hurray for 'just java programming'). Now if only more people would see 'the light' concerning web app development ;)
  34. Re: sigh[ Go to top ]

    As far as I know, this option has been added to Stripes a while ago. But this is not the point. The point is that there should be no "roadmap".


    Why is it that when a person asks a simple question, so often a bunch of Wicket people invade the thread to give everything except the answer to the question? Where "everything" is a long-winded discussion about how wrong it is to ask that question?

    OK, OK, before you completely flame me, please, take a deep breath :-) Think about it for a second before you hit the "torch him!" button, because you're only going to prove my point further.
    Additionally, Michael is not a 'Wicket person' (though he's wicked alright), and in fact competes with his own framework. And his argument was a technical one, which hopefully didn't upset anyone.
  35. The concept of "roadmap" or "flow" is foreign to the concept of free browsing.
    Michael, I wonder how you come up with a statement like that? Who says that data and logic flow declaration means that intermediate pages are inaccessible and can't be visited directly? Actually, imho independent declaration of the flow makes free browsing a lot easier since you get total control over your URL space and can really tailor it to reflect what you want it to look like, totally independent from the actual implementation of any logic. Making actions totally independent from anything is not possible unless you create a static, unparametrized application. Something has to trigger or drive the logic in your actions, either some parameter, event, URL, ... Having this externalized in data flow makes your logic more decoupled and more reusable since you can simply rewire and reuse.
  36. I don't think it's an action vs component framework issue. One thing I particularily like about RIFE and WebWork is that the configuration file gives you one central place for a roadmap to the web app. Nice thing to have when you're taking on a project that was written by others. I understand some people's talk of configuration hell but I do find that aspect to be necessary and useful for large projects.

    Question: does Stripes have way to see such an overview of the flow of the web app without having to go see in every source file what happens next?

    Congrats on the release and keep up the good work :-)

    Frederic
    couldn't resist :) My opinion: thinking 'flow of a webapp' is something that should be externalized is one of the worst ideas of the Java community. How many more ways can we find to work with Java in a procedural fashion? ;)
  37. couldn't resist :)
    Eelco, I am sure that you know that it *is* possible to develop stateful, component-oriented, "flowless" applications with a Model 2 framework. Even with Struts. I am not saying that it is cool and Swing-alike and toolable, but it is possible with little effort. The problem is inertia of many users and of some committers as well who got used to the way things have been done. I guess this was one of the reasons why Tim started Stripes project instead of joining Struts, to create a rounder peg ;-)
  38. couldn't resist :)
    Eelco, I am sure that you know that it *is* possible to develop stateful, component-oriented, "flowless" applications with a Model 2 framework. Even with Struts. I am not saying that it is cool and Swing-alike and toolable, but it is possible with little effort.
    Sure. My rant was aimed against the very common conception 'web flow' has to be declarative. Which is something I completely disagree with.
    The problem is inertia of many users and of some committers as well who got used to the way things have been done. I guess this was one of the reasons why Tim started Stripes project instead of joining Struts, to create a rounder peg ;-)
    Yeah. And I think his decision to go on his own was right, even though many people bitch about there being too many frameworks available. If he would've joined Struts, the best thing he probably would have accomplished would be just a few of his ideas incorporated in some future version. Now users have Stripes, and Struts has an extra reason to work harder ;)
  39. it's a classic web application action framework. It's not square pegging components into the round hole of the HTTP web app model
    Let's be honest with ourselves. Anyone creating stateful applications on top of HTTP is already a professional 'square pegger'. It is a little late to start worrying about that! I am still a little torn on the component vs action argument. I have developed application using Tapestry and Wicket as well as Struts and Spring MVC. For me, the jury is still out. I will take a look at Stripes though :).
  40. it's a classic web application action framework. It's not square pegging components into the round hole of the HTTP web app model
    Let's be honest with ourselves. Anyone creating stateful applications on top of HTTP is already a professional 'square pegger'.
    Ditto.
    I am still a little torn on the component vs action argument.
    It *is* possible to use components in Model 2 frameworks (a.k.a. action frameworks). It is even possible to use components in Model 1 applications, those that are built with JSP only. Well, these components might be different from JSF components, but they are components nevertheless.
    I will take a look at Stripes though.
    Please do. This is a great Model 2 framework that utilizes new features of Java 5, making development simpler and faster and making the app code more compact and observable.
  41. it's a classic web application action framework. It's not square pegging components into the round hole of the HTTP web app model


    Let's be honest with ourselves. Anyone creating stateful applications on top of HTTP is already a professional 'square pegger'. It is a little late to start worrying about that!

    I am still a little torn on the component vs action argument. I have developed application using Tapestry and Wicket as well as Struts and Spring MVC. For me, the jury is still out.

    I will take a look at Stripes though :).
    Not more than anyone trying to put objects on top of the relational model would be. ORM doesn't work for everyone, but a lot of people found that - even though there are some problems due to the impedance mismatch - it greatly increased their productivity not to mention joy in work. It's the same with a component oriented framework like Wicket. For different problems, different solutions work, but in general it increased my productivity greatly, while the scalability problems people are afraid of when employing a stateful framework have so far not been a problem at all (and if it ever is, it will be fixable/ tweakable, as Wicket has stateless pages and deferred session creation nowadays). Also, it's a misconception you're not working with state when you're using a stateless framework. One of Wicket's early core developers literally had it as his day job to fix applications created with Struts that were relying on ad-hoc session storage all over the place to fix their UI problems. First thing people say when I say that is 'oh, those programmers just suck'. Well, either way, it's my experience that that's a common thing for such frameworks too, and when we started comparing our first Wicket projects with some of the older (model 2) projects we did, we surprisingly found out that the model 2 projects used more session memory (and leaked too) and bandwidth on top of being harder to maintain, having an awkward programming model, being not able to reuse, etc. If you're more comfortable with a model 2 framework, to me Stripes definitively seems like the best choice. The good thing about stripes is that it at least brings you closer to a decent programming model, employing a less disconnected approach compared to other model 2 frameworks.
  42. I am still a little torn on the component vs action argument. I have developed application using Tapestry and Wicket as well as Struts and Spring MVC. For me, the jury is still out.

    I will take a look at Stripes though :).
    I think you should definitively look at Stripes. To me, Stripes provides a much nicer programming model than e.g. Struts. As for the action vs component argument. I think the more complex your projects are in terms of UI complexity, team size, data model, etc, the more you'll be able to reap the benefits of component based frameworks. On the other hand, if you're comfortable with action oriented frameworks, and you develop apps that are less complex, or you use e.g. Ajax to handle some of the naster UI problems, using such a framework is just fine. IMO much like I'd prefer to use SQL over ORM sometimes. SQL just works, always, while ORM can get you in bloody battles with the internals of the ORM framework to optimize/ fix bugs/ etc.
  43. Re: Stripes 1.4 Released[ Go to top ]

    In addition the re-implementation of the (small) subset of OGNL features used internally by Stripes has led to significant performance improvements.
    Congrats Tim. I can second the OGNL thing; getting rid of that was a major performance improvement for Wicket, even though we didn't depend on it that much.