I really hoped that S2 was going to be the RoR competitor Java developers need. However, after working with S2 for the past several months <yeah, I was experimenting before it was GA> it is either a mess, or simply too big with no instructions on how the pieces fit together. Sure, there are a few trivial examples and plenty of source code to pour over, but who wants to learn a framework buy reading source code? Getting things to work as expected is largely trial and error. It's so different from S1 (OGNL, DI, DoJo) that it's almost a hindrance for those who are deep into S1 apps. I have a big application running in S1 using Tiles, validation framework, hibernate... the works! I have yet to figure out how to get this application to work in S2. In fact, reading the threads has me wondering if Tiles is even supported in S2.
There is also much confusion across the board regarding WW and S2. Are they the same? Is support dead for S1? Unless you have had your nose pressed up to the incubator for the past year, It really is confusing. What about publishing a Cook Book or bolster up the guides and tutorials to reveal more than snippets of experimental code. What about a "book" on the framework? I love the motivation behind this effort, but I actually wonder if S2 was released prematurely. Thanks, Scott On 3/9/07, Michael Jouravlev <[EMAIL PROTECTED]> wrote:
Another blog, another comment: http://www.oreillynet.com/onjava/blog/2007/02/apache_struts_2_ga_release.html#comment-506880 "struts2 missed the boat. It has a nice "vintage" feeling to it, and it may be able to ride the marketing clout that goes with the name, but the technology feels like a "blast from the past". If you are on jdk5 and want an action-oriented framework, go with stripes." On 3/9/07, Vinny <[EMAIL PROTECTED]> wrote: > I'm just happy your post didn't conclude with > "... and that is why I'm switching to Flex..." > It's Friday, > Vinny > > On 3/9/07, Ted Husted <[EMAIL PROTECTED]> wrote: > > > > Just some rambling ruminations from my blog ... > > > > As might be expected, the Struts 2 GA announcement had its share of > > comments on The Server Side last week. [1] > > > > One subtopic was push versus pull. As with many terms, I think we > > sometimes use "push" and "pull" to mean different things. Sometimes we > > mean it to contrast component versus action paradigms [2]. Other > > times, we mean to contrast creating a custom context (or API) for each > > page that exposes only what that page is suppose to know (push), or > > whether we should create a global context (or API) that can be exposed > > to every page, so each page can pick and choose (pull) whatever it > > wants. [3] > > > > Another use of the "push/pull" term is to contrast "merge" templates, > > like Velocity and FreeMarker, with "scriptlet" templates, like ASP, > > JSP, and PHP. In this usage, the point is whether it is better to push > > out to the page a prepared context, or whether the page should use > > scriplets to pull values from the platform's shared context. > > > > One benefit of push is that it easier to use the technology outside of > > the environment, since we can create a prepared context independent of > > the target platform. One benefit of pull is that its easier to share > > values with other application resources, since the context is shared. > > > > Struts 1 tends to muddle this kind of push and pull. ActionForms are > > push, but we also provide a lot of servlet attributes which pages need > > to pull from one of the platform's scopes (page, servlet, > > application). The Velocity support for Struts uses a chained context > > to provide access to a Velocity context as well as the platform > > contexts. > > > > Struts 2 creates its own context that includes references to the > > servlet scopes (as plain-old Maps). In this way, S2 provides the > > benefits of both push and pull. For testing, it's easy to create our > > own action context, and at runtime, we can access the usual servlet > > resources. Another benefit of wrapping pull-within-push is that we can > > provide "first class" tag support for JSP, FreeMarker and Velocity. > > > > Personally, I'm a fan of the template approach. The Struts 1 tags > > mitigated the damage JSP scriplets were causing back in the day [4]; > > before JSTL, stock JSPs were a ugly, inelegant mess. (And before > > Velocity people got involved in JSTL, the JSTL was a mess too.) > > > > If there is a single reason why Struts 1 was so successful, it was > > because we provided a JSP taglib when everyone else (Barracuda, > > JPublish, Maverick, Tapestry, Turbine, among others) was focused on > > templates and other alternative solutions. > > > > Over the years, I've consulted with some large concerns that > > standardized on templates pre-y2k. The technology worked well, but my > > clients eventually replaced the templates with Struts and JSPs. Not > > because JSP was "better", but because JSP worker drones are easy to > > hire. As Craig said [5], project managers tend to choose "mainstream" > > technologies, regardless. We already have a hammer, so every problem > > must be a nail. > > > > Ironically, Struts 2 "levels the playing field", so that "alternative" > > technologies like Velocity, Freemarker, and AJAX are on equal footing > > with "mainstream" technologies like JSP, JSF, and, well, AJAX. :) > > > > - Ted. > > * http://www.husted.com/ted/blog/ > > > > > > [1] http://www.theserverside.com/news/thread.tss?thread_id=44429 > > > > [2] http://www.theserverside.com/news/thread.tss?thread_id=44429#228491 > > > > [3] http://jakarta.apache.org/turbine/turbine/turbine-2.3.2/pullmodel.html > > > > [4] http://www.servlets.com/soapbox/problems-jsp.html > > > > [5] http://www.servlets.com/soapbox/problems-jsp-reaction.html > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > -- > Ghetto Java: http://www.ghettojava.com > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- Scott [EMAIL PROTECTED]
