On Thu, Jan 26, 2012 at 3:34 AM, Christian Grobmeier
<[email protected]> wrote:
> Last mail for today :-)
>
> Today there is a discussion on going, Tapestry vs Struts (on
> tapestry-users list). Of course people are convinced of Tapestry, and
> actually it is a great framework with huge benefits. And it is pretty
> modern. People now say (and not only there) Struts is a dinosaur.
>
> Well, what I really liked on Wicket was the idea on components. I
> think Wicket failed with it. But Tapestry did something similar, and
> there it is working. Then there is Vaading, another great framework
> supporting components.
>
> I look at Struts. I see, we can use different presentation layers here
> too. I am just not sure what other than jsp is really working. Are we
> sure JavaTemplates work? We support Sitemesh2, which is pretty
> outdated too.
>
> These days people go to Components. I have thought a while about it...
> shouldn't it be possible to use components in STruts too?
The classical distinction between styles of web frameworks is
action-oriented versus component-oriented. The two take different
approaches to the problem of building web apps, and each has its
place, depending on the goals and constraints of the app. Some people
pick one and try to use it for everything; others will pick the
appropriate tool for each job.
Since its very beginnings, Struts has been an action-oriented
framework. Over time, people have attempted to morph it into something
more component-oriented, or tried to build a component layer on top of
it. To me, that's a bit like trying to improve upon a screwdriver by
turning it into a hammer.
If you look back at the early history of JSF, you'll find the
beginnings of Apache Shale, which started out as a Struts subproject
to explore some component-oriented ideas in a Struts world. Shale was
split off from Struts because of the divergent perspectives of
action-oriented versus component-oriented developers. The project was
retired about 2 years ago, in part because many of the good ideas from
Shale were being adopted into JSF, and in part because of the
realisation that trying to morph an action-oriented framework into a
component-oriented one was an unnatural act. It made (and makes) more
sense, if you wanted a component-oriented framework, to focus on just
that, rather than bending another tool to needs for which it wasn't
designed.
Now, of course, that's not to say that there aren't ideas that might
be interesting for some people to explore, as a kind of Shale2 on top
of Struts2 (conceptually speaking). I'd just encourage you to think
carefully about why you would want to do that, rather than use an
existing component-oriented framework in a situation that warrants
that style. I'd also encourage you to think about why tens of
thousands of developers have chosen Struts as an action-oriented
framework when they too could have chosen a component-oriented
alternative if it fit their needs.
--
Martin Cooper
> We have DI
> in place, which is a good backbone for that.
>
> For example, look at this:
>
> class MyAction {
> @Inject
> MyComponent blub; // Implements StrutsComponent
> }
>
> <body>
> <s2:component id="blub" />
> </body>
>
> Components might be able to return html. They can calculate. They can
> be used with JSP. Looking at this:
> http://tapestry.apache.org/component-reference.html
>
> We can learn a bit from Tapestry here. Probably we are able to reuse
> some of the components from them.
>
> I begin to think a good frontend layer would bring benefits. Otherwise
> it might happen S2 is more and more going into the direction "service
> layer", and for that it might not fit very well.
>
> What do you think?
>
> Cheers
> Christian
>
> --
> http://www.grobmeier.de
> https://www.timeandbill.de
>
>
> --
> http://www.grobmeier.de
> https://www.timeandbill.de
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
