On 3/20/06, Frank W. Zammetti <[EMAIL PROTECTED]> wrote: > > You know, I was looking at the Struts front page a few minutes ago, > specifically the "Extensions", which are the seven dwarfs IIRC. The one > that sticks out for me as a "problem", if that's the right word, is the > JSP Taglib.
I suspect that Struts users who abhor JSP, but like things like Velocity, would not agree with you :-). Indeed, if you're using Struts as the server end of AJAX transactions, you don't need this library even if you do happen to use JSP for the human user interface portion of your application (perhaps using a different framework). I think it's fair to say that the majority of Struts developers consider > the Struts tags to be intrinsically part of the Struts Action Framework > (SAF). Except for me who rarely uses them! :) > > The analogy I would use us the component kit you use in a JSF app... > *can* you build a JSF app with no component kit at all? You bet you can. I would guess > yes... but how many people *would* ever do that? I would guess very > few. I think the same is true of the Struts tags. Just as an example use case, if you like using the expression evaluation and managed beans portion of JSF, but don't like the UI component architecture, you can do exactly that. In fact, this makes a really nice back end for AJAX type interactions. Come to think of it ... there's even a 40kb standalone jar file ( shale-remoting.jar) that does exactly this kind of thing, with no dependencies on the UI components part of JSF, or even on the rest of Shale :-). I think everything else, Tiles, Flow, EL, etc., really do seem to me to > be true "extensions", and as such it makes sense for them to develop on > their own, be packaged on their own, and be downloaded separately as > needed. My only concern there is simply to document well what > version(s) of a given extension can be used with a given version of SAF. > I think this information should always be front and center and easy to > find quickly. > > But, the JSP Taglib, that one I think really does make more sense to go > along with the core itself. I'm not saying it can't be its own JAR... > that's just a matter of the final build artifact. I'd probably opt to > include it in the Struts JAR, but that's really a minor point IMO. What > is more important is that I think the taglib should share the same > version number, release cycle, etc., as the core, and in fact should > just simply BE part of the core. > > I guess I'm saying I would propose amending Don's proposal to only apply > to the Struts taglibs :) > > > Craig > > Frank Craig
