Re: JSP 2.0 and taglibs (was Custom tags referencing struts tags)

[Laurie Harper <la...@holoweb.net>]

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!

L.


---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org

Re: JSP 2.0 and taglibs (was Custom tags referencing struts tags)

[Rahul Akolkar <ra...@gmail.com>]

Two email responses consolidated in one below:

On 11/19/05, Craig McClanahan <cr...@apache.org> wrote:
> On 11/19/05, Laurie Harper <la...@holoweb.net> 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 <la...@holoweb.net> 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: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org

Re: JSP 2.0 and taglibs (was Custom tags referencing struts tags)

[Laurie Harper <la...@holoweb.net>]

Craig McClanahan wrote:
> On 11/19/05, Laurie Harper <la...@holoweb.net> 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).

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 ;-)

L.


---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org

Re: JSP 2.0 and taglibs (was Custom tags referencing struts tags)

[Craig McClanahan <cr...@apache.org>]

On 11/19/05, Laurie Harper <la...@holoweb.net> 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).

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 :-).

Craig