Re: SAF2 JSF Support (was Re: Does Struts ...)
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]
Re: SAF2 JSF Support (was Re: Does Struts ...)
On 6/21/06, Alexandru Popescu [EMAIL PROTECTED] wrote: If you think this can be done with the big-package-solves-everything approach, than I am oke with it. Hmmm, you can have both. If people are interested in RoR simplicity, then why not create an Action-on-Rails distribution that configures the framework to support one clearly-defined approach to web development. The AoR distribution might only support one AJAX theme, and one view technology. The distribution could also be bundled with a particular data access technology, so that it would be the complete package. Eventually, you could also bundle AoR with tweaked version of Rainbow, Geronimo, Derby, and Eclipse, and have a single-stop-shop. But, we don't need to dumb-down SAF2 to do that. We just need people to document favorite ways of configuring SAF2, bundling it up as a distribution, and then be willing to support the configuration. Now, what if we want to have an Action-on-JSF distribution? What else do we need to do to SAF2 so that it supports JSF as well as it supports JSP and FreeMarkerr? -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SAF2 JSF Support (was Re: Does Struts ...)
On 6/21/06, Alexandru Popescu [EMAIL PROTECTED] wrote: 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. Because the thread introduced two different topics, which will have separate conclusions. * How can we better support JSF in SAF2? * Can we separate the UI tags from the SAF2 core? The reason there are both Action and Shale frameworks is because we didn't know how to support JSF in Action. We're finally starting to make some headway on that score. Now what do we need to do to finish the job? If the job is finished, then is someone up to showing us the code by driving the Shale MailReader from SAF2? -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SAF2 JSF Support (was Re: Does Struts ...)
Ted, as I was afraid, you are unfortunately, interpretting wrongly my message. RoR is not about dumb-distro, nor my intention/hope to have something very simple in the Java world. As for we can built different distributions and things like this: I would definitely try to be objective: we are doing this for fun, so why do you think I would like to make my life more complex? :-). I think I've exposed my thoughts. From now on, I will listen the majority. BR, ./alex -- .w( the_mindstorm )p. --- (http://themindstorms.blogspot.com) On 6/21/06, Ted Husted [EMAIL PROTECTED] wrote: On 6/21/06, Alexandru Popescu [EMAIL PROTECTED] wrote: If you think this can be done with the big-package-solves-everything approach, than I am oke with it. Hmmm, you can have both. If people are interested in RoR simplicity, then why not create an Action-on-Rails distribution that configures the framework to support one clearly-defined approach to web development. The AoR distribution might only support one AJAX theme, and one view technology. The distribution could also be bundled with a particular data access technology, so that it would be the complete package. Eventually, you could also bundle AoR with tweaked version of Rainbow, Geronimo, Derby, and Eclipse, and have a single-stop-shop. But, we don't need to dumb-down SAF2 to do that. We just need people to document favorite ways of configuring SAF2, bundling it up as a distribution, and then be willing to support the configuration. Now, what if we want to have an Action-on-JSF distribution? What else do we need to do to SAF2 so that it supports JSF as well as it supports JSP and FreeMarkerr? -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]
Re: SAF2 JSF Support (was Re: Does Struts ...)
The reason there are both Action and Shale frameworks is because we didn't know how to support JSF in Action. We're finally starting to make some headway on that score. Now what do we need to do to finish the job? If the job is finished, then is someone up to showing us the code by driving the Shale MailReader from SAF2? -Ted. I think this is a great point. Easy/centraliced way of doing things was the key to original Struts success. I think Action2 must keep that point, and JSF (nor shale nor seam nor no-framework yet) provides a way of doing things. IMHO, the original perform() method and ActionForm was the key of Struts success. Easy and centralized, a single way of doing webapps with Struts. If I do Struts, and I you do Struts, we *surely* talk the same dialect. If I do JSF and you do JSF, I'm 95% sure we won't talk *exactly* the same dialect. I can implement my managed beans in lot's of different ways. I can have events, or actions, centralized or uncentralized actions... a lot of differences between two programmers. The point is, provide an easy way to do things with JSF in a plugable fashion: use it or not, use it our way or not, but if you use it our way, well... there must be any benefit! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SAF2 JSF Support (was Re: Does Struts ...)
On 6/21/06, Juan Ara [EMAIL PROTECTED] wrote: The point is, provide an easy way to do things with JSF in a plugable fashion: use it or not, use it our way or not, but if you use it our way, well... there must be any benefit! Yes, it's always been a technical problem. We accepted Shale as a Struts subproject to give Struts developers a JSF alternative. Now that we have a JSF option for SAF2, with a simple Showcase example, the next step would be to try a coherent application using SAF2 as the controller, and then mixing JSF and maybe AJAX in the view. Such an example would help clarify that notion that SAF2 can be omnibus controller. Just as we can plug PHP and JSP into Apache HTTPD, we should be able to plug JSP, FTL, JSF, PDF, XLST, and whatever else (Tapestry?) into SAF2. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SAF2 JSF Support (was Re: Does Struts ...)
Comparing JSF to JSP, FTL, PDF, XLST is comparing apples and oranges. That is like comparing Struts to PDF. Ridiculous! On 6/21/06, Ted Husted [EMAIL PROTECTED] wrote: On 6/21/06, Juan Ara [EMAIL PROTECTED] wrote: The point is, provide an easy way to do things with JSF in a plugable fashion: use it or not, use it our way or not, but if you use it our way, well... there must be any benefit! Yes, it's always been a technical problem. We accepted Shale as a Struts subproject to give Struts developers a JSF alternative. Now that we have a JSF option for SAF2, with a simple Showcase example, the next step would be to try a coherent application using SAF2 as the controller, and then mixing JSF and maybe AJAX in the view. Such an example would help clarify that notion that SAF2 can be omnibus controller. Just as we can plug PHP and JSP into Apache HTTPD, we should be able to plug JSP, FTL, JSF, PDF, XLST, and whatever else (Tapestry?) into SAF2. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- You can lead a horse to water but you cannot make it float on its back. ~Dakota Jack~ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
