I think the rule of thumb here should be if you require any additional
tag attributes, then the tag should be in its own tag library. If
followed fully, this would put our xhtml theme in its own tag library,
which if we could ignore backward compatibility, I'd do in a heartbeat.
I think the theme concept is still handy, just overused.
Don
Ian Roughley wrote:
I think I am missing something here - how will the tags be invoked?
It will need to be a new tld with a new name space, right? Something
like <dojo:select ... /> rather than <s:select theme="ajax" ... /> -
so there will be a compatibility issue, but all the functionality will
be moved forward.
/Ian
David H. DeWolf wrote:
Ted Husted wrote:
Don mentioned a separate tag library, so that would indicate another
prefix, but there'd be no reason why the internal tag syntax would
change.
To keep the codebase manageable, I believe we do need to make this
change, and I'd rather make it now while we are in our first beta
series than after the first Struts 2 GA. The plugin model might also
open the door to other AJAX implementations of the same tags.
I agree. I like it, but just wanted to make sure we think through
the compatibility changes before we make a decision.
In essence we're saying that this change is more important than
backwards compat of this one tag and we're willing to live with those
repercussions. I'm on board with that.
-T.
On 12/27/06, David H. DeWolf <[EMAIL PROTECTED]> wrote:
Ok, as long as we keep the tag prefixes and tag names once they are
abstracted from the plugin.
At one point we talked about having a simple version which is extended
by the dojo version and added additional (dojo-specific) featuers. It
seems like the current names would be more likely be used for the core
tags - not the dojo-enhanced ones.
Ted Husted wrote:
> A struts-dojo plugin shouldn't change the tag syntax. It should just
> be a matter of adding the JAR, as we do for Spring, and
JasperReports,
> and Tiles, so forth.
>
> On 12/27/06, David H. DeWolf <[EMAIL PROTECTED]> wrote:
>> Nope, that's the one I'm talking about. I got the impression we
were
>> going to keep it as is and thus break backwards compatibility in
2.0.2
>> -- and then mess with it again it when we create the plugin. . .
>>
>> David
---------------------------------------------------------------------
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]
---------------------------------------------------------------------
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]
