I'd suggest in the case where frameworks are unable to support a feature it
should be clearly documented and the plugins tld doesn't include the tag.
By having the two classes my aim is that users can rely on ajax plugins
included in the core to have a basic level of functionality as opposed to
ending up with multiple ajax plugins in the core distribution each of which
uses different tag names for the same concept and users asking why they need
to change their tags from <ajax:x...> to <ajax:y...> to do the same thing
when they've changed plugin.
Al.
----- Original Message -----
From: "Musachy Barroso" <[EMAIL PROTECTED]>
To: "Struts Developers List" <dev@struts.apache.org>
Sent: Thursday, February 21, 2008 6:45 PM
Subject: Re: [s2] Let's get out Struts 2.1.1
>
I'd suggest that Class 1 comes from all the tags which were in S2.0 core
and
moved out to the plugin in S2.1, this would give S2.0 users a smoother
migration path knowing that they can chop and change ajax plugins to
find
one they like without the risk of wasting time on a plugin that doesn't
deliver what they need.
The problem with this approach is that sometimes the widgets are way
tot different between frameworks.
musachy
---------------------------------------------------------------------
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]
