First of all I am not sure why so many thread forked from the initial discussion. This will make a lot more difficult to figure out what was already said, and towards what conclusion we are moving.
For your comments my answer is simple: that's exactly the opposite of what and how RoR has gain its popularity. In RoR you simply write: scaffold :category and here it goes: you already have a draft screen for your Category (or even better using the generate script you get a full generated draft to start working on). Than you just start the embedded Mongrel server and here it goes again: is alive! (all this is taking about 1 minute) (WebWork has already introduced something similar for the last parts). In Struts: you will have to decide what theme to use, configure what theme to use, determine what dependencies are needed and than start building everything from scratch. Can we agree which approach is simpler? ./alex -- .w( the_mindstorm )p. On 6/21/06, Ted Husted <[EMAIL PROTECTED]> wrote:
On 6/21/06, Alexandru Popescu <[EMAIL PROTECTED]> wrote: > WebWork has tried to adapt to this new approach proposed by RoR. And > it was nice to see it. We may have a few more ideas to make it even > simpler in the near future. But this will not work with the > big-solve-all approach. I think what Don is suggesting continues the WebWork approach. In WW2, whatever could be pushed back to XWork was pushed back to XWork, making WW itself as light as it can be. Instead of building an expression language, XW and WW adopt and adapt OGNL. Instead of building a templating system, WW first adopted Velocity and then FreeMarker. Instead of building in something like Tiles, WW recommends SiteMesh. Right now, the UI tags are not like XWork, or OGNL, or FreeMarker, or SiteMesh, they are part-and-parcel of WW. So Don is suggesting we start to make them standalone, like Tiles, so that, eventually, they could be used by another framework, like, say, Spring MVC. Meanwhile, to better solve AJAX, we are talking about multiple AJAX themes. I believe Don is suggesting that we approach JSF integration like we are approach AJAX integration. Make it something like a theme, that an application could elect to use with WW, the way an application might elect to use AJAX. Once SAF2 is able to front JSF components as easily as it can front AJAX compents or the UI Tags, then applications would have the option of mixing and matching view technologies, or just sticking with one. Even now, we have the option of using UI tags with JSP or FreeMarker, and mixing technologies in the same application. The question is whether we can make JSF more of the same. -Ted. --------------------------------------------------------------------- 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]
