• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

When not to use Stripes

 
Ranch Hand
Posts: 91
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Frederic,
As we hear often, there is no one solution which fits all situations. Given the great features of Stripes, where do you think Stripes would not fit on a J2EE web application? Lets assume that all developers are ok with learning a new technology.

Is there some place where you think Wicket or JSF or Spring MVC or Struts or Tapestry might have an edge over stripes?

Also, to get rails/grails like productivity, What other frameworks should I use in combination with Stripes to get it? Or is this impossible in Java?
 
Ranch Hand
Posts: 15304
6
Mac OS X IntelliJ IDE Chrome
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I'm not Freddy but I'd like to answer this question.

As we hear often, there is no one solution which fits all situations.



My opinion on this matter: Best Tool for the Job is a Myth

Given the great features of Stripes, where do you think Stripes would not fit on a J2EE web application?



I've been developing web applications for going on 8 years now and since I've found Stripes I've not found a situation where it didn't fit.

Is there some place where you think Wicket or JSF or Spring MVC or Struts or Tapestry might have an edge over stripes?



Other than SpringMVC which is action based like Stripes if all the devs were more comfortable with component oriented frameworks then the others might be a better option. Not because they are better than Stripes but go with what you know, to a fault.

Also, to get rails/grails like productivity, What other frameworks should I use in combination with Stripes to get it? Or is this impossible in Java?



There is Stripersist which helps with the data access layer. Really though, if you want to develop in the rails/grails paradigm, use rails/grails. If you want choices and options and a super easy yet powerful MVC framework you can't go wrong with Stripes.
 
M Rama
Ranch Hand
Posts: 91
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Gregg,
Thanks for that response. What do you use in your middle tier and data tier along with Stripes? Do you have a single toolset which you prefer on those arenas as well?
 
Gregg Bolinger
Ranch Hand
Posts: 15304
6
Mac OS X IntelliJ IDE Chrome
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by M Rama:
Gregg,
Thanks for that response. What do you use in your middle tier and data tier along with Stripes? Do you have a single toolset which you prefer on those arenas as well?



As a consultant that sometimes gets driven by the client. But generally I use Spring for transaction management and DAO/Service support along with either iBatis or JPA/Hibernate.
 
author
Posts: 71
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by M Rama:
Frederic,
As we hear often, there is no one solution which fits all situations. Given the great features of Stripes, where do you think Stripes would not fit on a J2EE web application? Lets assume that all developers are ok with learning a new technology.



Indeed, there is no silver bullet, but for J2EE web application development, I find that, given the transparency and extensibility of Stripes, you can customize it to suit your needs in the vast majority of situations.

Is there some place where you think Wicket or JSF or Spring MVC or Struts or Tapestry might have an edge over stripes?



I'll divide the frameworks that you listed into two categories: action-based and component-based.

For action-based development (Spring MVC, and Struts), I would choose Stripes over those frameworks because I find that Stripes is easier to use and more productive.

For component-based development (Wicket, JSF, Tapestry), if your development team really wants to develop a web application like they would a Swing application, Wicket or Tapestry may be a good choice.

Personally, if I am asked to develop a web application with a lot of stateful GUI controls (tabs, sortable tables, etc.) I would still rather use Stripes and just add an AJAX framework for the GUI controls, instead of using a component-based framework. Component-based frameworks are more complicated because they have to bridge the gap between the concept of components and the stateless request-response nature of the HTTP protocol.

Also, to get rails/grails like productivity, What other frameworks should I use in combination with Stripes to get it? Or is this impossible in Java?



You can use Stripes-Quickstart http://www.stripesbook.com/blog/index.php?/archives/19-Stripes-Quickstart.html to generate your project. Then, as Gregg mentioned, JPA/Hibernate with Stripersist works nicely for the persistence layer, and Spring or Guice for dependency injection.

You can also use Groovy in a Stripes application. Since Groovy can be compiled to Java bytecode, it's simply a matter of adding the embeddable Groovy JAR file and using the groovyc Ant task to compile your code. You can also use a Groovy IDE plugin.

Cheers,
 
Greenhorn
Posts: 13
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
My opinion is basically that Component Frameworks are an intermediate step that will eventually cede to "pure Ajax". The point of the component frameworks is to shoe horn the square peg that is the component/event model into the stateless transaction oriented round hole of HTTP.

The issues with server side state are legion when it comes to scalability and complexity, and the component models go to great length to hide those concerns from the developer, but that doesn't mean the concerns don't exist. The complexity is there, but it's like sharks circling below the water -- unobtrusive and ignored until one of them rises up and bites off your leg, then you look under the waves and go "OMG! It's filled with sharks!".

"We're going to need a bigger boat."

And that boat is the modern, powerful "thick client" Javacript browser.

So, over time as the browsers race each other and the older ones drop off the face of the planet, the component frameworks will go the wayside as the browsers take over their role.

Mind, this is specifically in reference to mostly back office applications with really complicated user interfaces, etc. Not "web sites", that is those sites dedicated to content distribution.

So, what happens when you get a rich client is that the server basically becomes a pure service host, and web clients prefer that "REST" style of communication. Here, any action framework will handily do the job, and Stripes is well suited to being a good backend for these kind of systems with its new URL support, JSON support, etc.
 
Sheriff
Posts: 67746
173
Mac Mac OS X IntelliJ IDE jQuery TypeScript Java iOS
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Will Hartung:
My opinion is basically that Component Frameworks are an intermediate step ...


+5 Insightful

Originally posted by Frederic Daoud:
Component-based frameworks are more complicated because they have to bridge the gap between the concept of components and the stateless request-response nature of the HTTP protocol.


Which is why I avoid them like the plague.

Until we hit the next big browser paradigm shift, I like the simplicity, flexibility and "nativeness" of the action-based approach.
 
Ranch Hand
Posts: 230
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Will Hartung:

the component frameworks will go the wayside as the browsers take over their role.



That certainly would make things easier.
 
Greenhorn
Posts: 19
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

M Rama wrote:What do you use in your middle tier and data tier along with Stripes? Do you have a single toolset which you prefer on those arenas as well?



With Stripes, we use Spring and JPA. They also let you use annotations to wire things up automagically. Here's how you can use them with Stripes.
 
Don't get me started about those stupid light bulbs.
reply
    Bookmark Topic Watch Topic
  • New Topic