On Mon, April 18, 2005 11:33 am, Hubert Rabago said: > No problemo. As far as the extension itself is concerned, I'd still > be interested in it, but like I mentioned earlier, only as a plugin > that doesn't change the base tags.
I thought that was a fair point at the time, and still do. I haven't had time to look into it yet, but I wouldn't mind re-implementing what I've done as the EL tags are, as you pointed out, just an extension. I have some questions on how to actually do it, but the idea I think is sound. > The reasons are many and they are > mentioned in the dev thread you started. My main concern is > implementation lock-in. Another message in this thread already > illustrates that there could be several approaches to adding this > functionality. I wouldn't want to limit how everyone else applies the > technology. Absolutely. I was trying to provide an easy way for people to get started with AJAX techniques while still using the tags they are already familiar with, that was my underlying thought. But the objections raised where perfectly valid. I do think the extension approach addresses those concerns, and hopefully I'll have some time to go that route. > As Martin said, if an implementation is built into > Struts, it should support whatever client-side library the developer > would want to use ( > http://marc.theaimsgroup.com/?l=struts-dev&m=111284722931074&w=2 ). A > separate plugin wouldn't have to have that burden. I was actually a bit perplexed by Martin's reply... I still am I guess... when we talk about supporting "whatever client-side library the developer wants to use", what are we really talking about? I've always thought that if you use the Struts tags, you have in effect choosen what client-side library you are using. If you were to use JSF or whatever else you could name, wouldn't you be using a whole different set of tags, that may or may not have AJAX functionality? I guess I'd like to hear that point clarified... what does everyone think it actually means to support a client-side library? Perhaps starting with really defining what a client-side library is would be a good starting point :) > A separated plugin would result in code duplication, true, but in my > view it's worth it. In some aspects, the ajax-aware tags you propose > are in a better position than the EL tags. You only need to override > some methods, whose implementation can be moved to a util-type class. > EL had to add duplicate fields, getters, and setters. Just take a > look at the source of some of those tags, like ELCheckboxTag and > ELRadioTag. I do agree, for my initial simple pass, that is a better way to go. I didn't do that mainly because of what you say: code duplication. But, that probably is ultimately a better answer. Like I said, there are some questions in my mind how you mechanically go about it, but the idea is sound I think. -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
