Guten Morgen mate, did you intend to send the message to Struts ML? ;)
Alles gute, -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Thu, Jan 26, 2012 at 12:24 PM, Christian Grobmeier <grobme...@gmail.com> 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? 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 > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
