Since what version have the tags been separate? I just looked in my 1.2.4 struts.jar I have deployed in production and all the tag classes are there (well, the couple I looked for anyway, including BaseHandlerTag and ButtonTag). Are you saying that they are in fact separate NOW but all RELEASED versions of Struts actually still includes them? Just trying to understand :)
In any case, I think your assessment is correct in that I myself view this as just an extension to the tags. But, with the caveat that its the BaseHandlerTag class that is altered, so it's not an extension you can just ADD to an app, you'll have to REPLACE something (whether a full jar or a single class or however else you might want to do it). Doing it by extension instead is an interesting idea, and as long as I could make it work without having to duplicate a bunch of code from the existing BaseHandlerTag class, I'd be OK with that, and then it would be suitable for struts.sf.net. Knowing how it works now, it's not clear to me how to pull that off, but it's worth exploring. -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com On Thu, April 7, 2005 9:44 am, Hubert Rabago said: > My understanding of your initial email is that the Ajax-aware tags > were really just extensions to the tags. Was I wrong? > > While I was reading it, I kept thinking they were going to be like > what the EL tags are now. If you want the classic tags, use this tag > library, if you want the Ajax tags, use this other one. The classes > in the Ajax-aware tags would extend those in the taglib project. > > In any case, this wouldn't require a new struts.jar because the tags > are in their own jar. It looks to me as a very good fit for an > optional jar. People not interested in Ajax, or those wishing to use > another Ajax solution, won't have to carry the Ajax-aware tag jar. > Those who want to use it will just need to add an additional jar and > use this other tag declaration. > > Hubert > > > On Apr 7, 2005 8:31 AM, Frank W. Zammetti <[EMAIL PROTECTED]> wrote: >> I think the problem I see with that is that if you are making changes to >> existing code in the Struts distribution it means that people have to >> make >> a conscious choice to go down a potentially incompatible path. >> >> I think struts.sf.net works fine for things that truly are extensions, >> i.e., things that don't require an updated struts.jar for instance... >> But, anything that would require that, like these Ajax-aware tags >> requires >> one existing class be altered, makes it more difficult... >> >> If I were to finish this up and post it on struts.sf.net (or the Wiki, >> same argument) and then people decide to use it, they won't be able to >> move to 1.3... well, *theoretically* they couldn't, in this case they >> actually probably could, but for something like my setupItems a while >> back >> for instance, they couldn't. They would be relying on ME to upgrade it >> for each new Struts version (or prior versions maybe even) or they would >> have to do it themselves. >> >> But, if it was accepted into the Struts project proper, then it would be >> dealt with as part of the project, and while I myself still might be >> responsible for making sure it works with the next version, I am then >> doing so in the context of the larger project. >> >> -- >> Frank W. Zammetti >> Founder and Chief Software Architect >> Omnytex Technologies >> http://www.omnytex.com >> >> On Thu, April 7, 2005 2:01 am, Don Brown said: >> > I haven't really been following closely, but what is wrong with using >> > struts.sf.net for distributing struts-related extensions? I've been >> > using that site for years with good results. Some ideas became struts >> > subprojects and others didn't go anywhere. We've been very accepting >> of >> > new projects over there and I believe Martin or Ted have already >> > suggested it. struts.sf.net gets tons of hits and is a very good way >> to >> > get your project out there and known. >> > >> > Don >> > > > --------------------------------------------------------------------- > 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]
