Thank you so much for having been around in JavaRanch Book Promo and answering the queries.
Its really nice to know about Stripes, a close competitor and expected-to-replace Struts!
I do have few questions after going through the discussions.
As you say here, what exactly the term non-full-stack means here? I don't quite get that.
Again when you say near-to-zero configuration, how exactly Stripes manages the configurable properties,values? If I am right, it should atleast have one configuration file of its own as a minimum requirement.
When you say, Stripes is more-or-less a replacement of Struts (may not be exactly 100% right), does it provide an abstraction over Struts?
Does Stripes have its own customized syntax? To what extent an application developed at present can be easily migrated to an xyz framework in future? I mean to ask about the tight bound nature and dependency of Stripes!
As a successor of Struts, for sure Stripes should follow the MVC pattern. Is there any other design pattern Stripes follows which is worth mentioning for its so called ease of use?
A full-stack framework generally refers to a framework that includes nearly all if not all the bits needed to build. Grails for example is considered full stack because it handles MVC, Transactions, DAO/Services, etc all under the covers by incorporating Spring, SpringMVC, and Hibernate.
With Stripes you get MVC. You can then choose all the other bits.
Again when you say near-to-zero configuration, how exactly Stripes manages the configurable properties,values? If I am right, it should atleast have one configuration file of its own as a minimum requirement.
Aside from the web.xml which every jee application needs there are simply no additional configuration files to worry about. Stripes uses a lot of convention over configuration techniques as well as relying on annotations and interfaces to configure different aspects. Take for example url binding. To configure an action bean with a specific binding you have in mind you would use the @UrlBinding annotation on the class:
It's that simple for most everything.
When you say, Stripes is more-or-less a replacement of Struts (may not be exactly 100% right), does it provide an abstraction over Struts?
Stripes is an MVC action based framework. Struts is an MVC action based framework. Generally you pick one of the two to do the job. That is what is meant by a replacement.
Does Stripes have its own customized syntax? To what extent an application developed at present can be easily migrated to an xyz framework in future? I mean to ask about the tight bound nature and dependency of Stripes!
Stripes is java. So it uses the Java syntax. As far as migration paths, that is up to you to deal with. Sure, your actions are going to be littered with Stripes specific API calls. But your actions, or controllers, should be tied to a framework. Everything else (dao, services, etc) shouldn't.
As you say here, what exactly the term non-full-stack means here? I don't quite get that.
Some frameworks provide not just the web side of the application problem, but also the persistence side. Seam is a "full stack" framework tidying up and tying up everything from JSF to JPA to Session Beans. Stripes simply handles the HTTP layer.
Again when you say near-to-zero configuration, how exactly Stripes manages the configurable properties,values? If I am right, it should atleast have one configuration file of its own as a minimum requirement.
What little configuration there is for Stripes is contained within the web.xml file.
When you say, Stripes is more-or-less a replacement of Struts (may not be exactly 100% right), does it provide an abstraction over Struts?
Stripes and Struts "are the same thing". Struts 1 and Stripes while conceptually similiar (i.e. an Action framework) are quite different in terms of actual execution and use. Struts 2 and Stripes are more the same than different.
Does Stripes have its own customized syntax? To what extent an application developed at present can be easily migrated to an xyz framework in future? I mean to ask about the tight bound nature and dependency of Stripes!
The tightest binding in Stripes is through the use of the Stripes Tag Library and JSP. But, in truth, those are completely optional. While integral to some of the "ease of use" aspects of Stripes, Stripes without the Tag library is still really powerful and very useful.
You're not required to use JSP or the tag libraries, but they are certainly useful and most folks do use them.
# As a successor of Struts, for sure Stripes should follow the MVC pattern. Is there any other design pattern Stripes follows which is worth mentioning for its so called ease of use?
Stripes also implements the "Stay out of my way" pattern, the "Do what I mean" pattern, "My, this certainly is easy" pattern and the "Where have you been all my life" pattern.
Stripes also implements the "Stay out of my way" pattern, the "Do what I mean" pattern, "My, this certainly is easy" pattern and the "Where have you been all my life" pattern.
Thank you very much for the beautiful explanations Gregg and Will.
Stripes also implements the "Stay out of my way" pattern, the "Do what I mean" pattern, "My, this certainly is easy" pattern and the "Where have you been all my life" pattern.
Stripes also implements the "Stay out of my way" pattern, the "Do what I mean" pattern, "My, this certainly is easy" pattern and the "Where have you been all my life" pattern.
Stripes also implements the "Stay out of my way" pattern, the "Do what I mean" pattern, "My, this certainly is easy" pattern and the "Where have you been all my life" pattern.
Nice discussion. Clear most of queries regarding Stripes.
![[Logo]](/templates/default/images/moosefly.gif)
![[Post New]](/templates/default/images/icon_minipost_new.gif){kind=icon}
![[Up]](/templates/default/images/icon_up.gif){kind=icon}
As far as migration paths, that is up to you to deal with. Sure, your actions are going to be littered with Stripes specific API calls. But your actions, or controllers, should be tied to a framework. Everything else (dao, services, etc) shouldn't.
