Two email responses consolidated in one below: On 11/19/05, Craig McClanahan <[EMAIL PROTECTED]> wrote: > On 11/19/05, Laurie Harper <[EMAIL PROTECTED]> wrote: > > > > Rahul Akolkar wrote: > > > Yes, that was more of a post-33064 comment. > > > > > > Getting the the Struts tags to be 2.0-ready is something I'd be > > > interested in too. Given the origin of those tags way before 2.0, > > > backward compatibility issues will take precedence. I wonder if > > > there's a better way. > > > > Yeah, backwards compatibility dictates that we introduce any change in > > behaviour as a configurable option somehow -- possibly with a 'this will > > become the default behaviour in the next release' type warning. > > > > If you have any ideas on 'a better way' I'd love to hear them. One > > possibility would be to refactor the tags so that we can produce a set > > of JSP 2.0 tag files and have the tags and tag fils share a common > > implementation class. Actually, that might be a better way to go than > > what I've been working on in 33064! > > > If you guys are *really* serious about this kind of rewrite, a better > approach might just be to create a completely new alternative library with > its own URI, based on SimpleTag (JSP 2.0) instead of Tag, with a deliberate > goal of making the implementation classes extensible in the required manner. > That way, strict backwards compatibility wouldn't be required (although > you'd have to continue to maintain the old set for existing apps of course). > <snip/>
Oh, I'm serious, I wouldn't just lob it out there. I'm not even thinking about SimpleTag vs. Tag, that bit I'm not necessarily fascinated by. I'm thinking what Struts tags gain by moving beyond 33064, and what is needed today to make that happen. To that end, I'm willing to devote some of my spare time if there is consensus about the approach. I'm thinking about the unification of the programming model for authoring and instantiation of JSP tags, something that JSP 2.0 doesn't receive enough credit for, IMO. There is really nothing at the technology level that holds us back today for *easily* enabling Struts tags to be aggregated together and composed into reusable chunks of larger functionality. If 90% of the login screen's today look the same, give and take a stylesheet, one should be able to easily create a reusable asset: <my:login ... /> that contains one <html:text>, one <html:password>, one <html:submit> and a <html:cancel> with other view layer frills, which may further allow packaging that <login> tag implementation, a stub for an ActionForm, an Action and other helpers as necessary, with the struts-config bits and beyond that, create libraries of such "components" for different verticals. I'm not saying composition is trivial -- configuration of composites, the correct granularity of assets etc. -- are all mitigating factors. But, it should be possible to do this without copying rendering code or playing container. Lets just use the composability that JSP 2.0 gives us at the .tag file level by getting the Struts tags to co-operate. This is a step towards pure JSP based reusable "asset libraries" or "view layer frameworks" that use vanilla Struts (an example of that is [1]). > > On the other hand, lots of the things you might want to do with new tags can > already be done with JSF components, even in a Struts based app (with the > struts-faces library :-). > <snap/> While I indeed agree, and I've been spending some of my "play" time in JSF and Shale land, this really was a statement about vanilla Struts, and those who want to use vanilla Struts. IMO, its about Struts evolving hand-in-hand with JSP technology. Every n days, we get a post from someone saying how a given unit of work was done in lesser time using some other technology of choice. This opens up a new dimension of reuse for Struts applications, and therefore, has potential to decrease development time and effort. That alone, in my mind, is quite a laudable goal. > > Craig > > On 11/19/05, Laurie Harper <[EMAIL PROTECTED]> wrote: <snip/> > > I'm not sure that a rewrite delivers enough benefit to justify having > two parallel implementations to maintain -- especially since these > taglibs don't get a lot of maintenance anyway... > > > On the other hand, lots of the things you might want to do with new tags can > > already be done with JSF components, even in a Struts based app (with the > > struts-faces library :-). > > Yeah, I'm beginning to see that ;-) <snap/> Hey now, don't go astray on me like that ;-) Anyway, I plan on coming back to this bug report after the long weekend, lets see what the options are. -Rahul [1] http://jakarta.apache.org/taglibs/doc/rdc-doc/intro.html > > L. > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
