RE: Tags more extensible (was: Suggestions for Calendar Popup tag lib?)
I believe your analysis of the issue is correct. Readonly, is a perfect example of the logic which spans from model to view. There are other issues, dates, text size, numbers, which have similar issues. If the only thing the view had to know about the business logic was the property name, then the MVC concept would be perfected (or as close as possible). Edgar -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 19, 2003 7:06 AM To: '[EMAIL PROTECTED]'; '[EMAIL PROTECTED]' Subject: RE: Tags more extensible (was: Suggestions for Calendar Popup tag lib?) Like this http://issues.apache.org/bugzilla/show_bug.cgi?id=21603 ? While this is not an attempt to define general extensibility mechanisms, it does seem to address some of Edgar's and Tero's concerns... I think it is a good example of the kind of extensibility needed. The bug asks for a specific solution to a specific problem, but a general treatment of extensibility might make it very easy. Have fun, Shai. -Original Message- From: David Graham [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 19, 2003 01:00 To: Struts Developers List Subject: RE: Tags more extensible (was: Suggestions for Calendar Popup tag lib?) --- Edgar Dollin [EMAIL PROTECTED] wrote: Exactly some of the problems I have been having with the tags as they currently exist. The best thing to do is to open a bugzilla enhancement request with *specific* tags and methods you need improved. Make sure the suggestions are relevant to the current state of the tags. David Edgar -Original Message- From: Paananen, Tero [mailto:[EMAIL PROTECTED] Sent: Monday, August 18, 2003 5:42 PM To: 'Struts Developers List' Subject: RE: Tags more extensible (was: Suggestions for Calendar Popup tag lib?) Well, this is the thing...how would I know in advance? :) Seriously. I have no idea what kind of requirements are coming up next month. An example of something we've done in the past is extending Struts HTML tags to incorporate access control features (read-only, write, mask sensitive info, etc.) While I wasn't involved with that effort, I'm looking at the source code, and it's done with copy-and-pasteing the old code and sprinkling in the access control checks and changes to rendering the value property. 90% of the code remains unchanged, but we had to copy-and-paste the entire thing. There is no other way to plug-in the access control enhancements in the tags without doing that. And we didn't feel like littering JSP code with logic tags. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --- Confidentiality Notice: This email transmission may contain confidential or legally privileged information that is intended only for the individual or entity named in the e-mail address. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or reliance upon the contents of this e-mail is strictly prohibited. If you have received this e-mail transmission in error, please reply to the sender, so that arrangements can be made for proper delivery, and then please delete the message from your inbox. - 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]
RE: Tags more extensible (was: Suggestions for Calendar Popup tag lib?)
Exactly some of the problems I have been having with the tags as they currently exist. Edgar -Original Message- From: Paananen, Tero [mailto:[EMAIL PROTECTED] Sent: Monday, August 18, 2003 5:42 PM To: 'Struts Developers List' Subject: RE: Tags more extensible (was: Suggestions for Calendar Popup tag lib?) Well, this is the thing...how would I know in advance? :) Seriously. I have no idea what kind of requirements are coming up next month. An example of something we've done in the past is extending Struts HTML tags to incorporate access control features (read-only, write, mask sensitive info, etc.) While I wasn't involved with that effort, I'm looking at the source code, and it's done with copy-and-pasteing the old code and sprinkling in the access control checks and changes to rendering the value property. 90% of the code remains unchanged, but we had to copy-and-paste the entire thing. There is no other way to plug-in the access control enhancements in the tags without doing that. And we didn't feel like littering JSP code with logic tags. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Tags more extensible (was: Suggestions for Calendar Popup tag lib?)
If empty entry point methods were added to all the tags so that you could extend the tag and write code in the entry point. For each attribute of the tag have a 'void pre[Attribute]()', 'void post[Attribute]'() and a 'String process[Attribute](String attributeValue)' method, whose purpose would be for extending the tag. There would be a little processing overhead in running the standard tags through the empty routines, but those of us who would rather write tags than either scriptlets, velocity or JSTL could do so with some flexibility. Thanks Edgar -Original Message- From: David Graham [mailto:[EMAIL PROTECTED] Sent: Monday, August 18, 2003 6:00 PM To: 'Struts Developers List' Subject: RE: Tags more extensible (was: Suggestions for Calendar Popup tag lib?) --- Edgar Dollin [EMAIL PROTECTED] wrote: Exactly some of the problems I have been having with the tags as they currently exist. The best thing to do is to open a bugzilla enhancement request with *specific* tags and methods you need improved. Make sure the suggestions are relevant to the current state of the tags. David Edgar -Original Message- From: Paananen, Tero [mailto:[EMAIL PROTECTED] Sent: Monday, August 18, 2003 5:42 PM To: 'Struts Developers List' Subject: RE: Tags more extensible (was: Suggestions for Calendar Popup tag lib?) Well, this is the thing...how would I know in advance? :) Seriously. I have no idea what kind of requirements are coming up next month. An example of something we've done in the past is extending Struts HTML tags to incorporate access control features (read-only, write, mask sensitive info, etc.) While I wasn't involved with that effort, I'm looking at the source code, and it's done with copy-and-pasteing the old code and sprinkling in the access control checks and changes to rendering the value property. 90% of the code remains unchanged, but we had to copy-and-paste the entire thing. There is no other way to plug-in the access control enhancements in the tags without doing that. And we didn't feel like littering JSP code with logic tags. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com - 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]
RE: When is the next release?
The users of struts can understand 1.2.1 w/o 1.2.0, most of use are also using tomcat as well and most of us skip releases. If it takes extra time for no other benefit than to keep things neet, it is probably not worth the effort. Edgar -Original Message- From: Steve Raeburn [mailto:[EMAIL PROTECTED] Sent: Saturday, August 09, 2003 11:12 PM To: 'Struts Developers List' Subject: RE: When is the next release? -Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED] Sent: August 9, 2003 8:57 PM To: Struts Developers List Subject: Re: When is the next release? That was my understanding as well -- we agreed to switch to the x.y.z style that Apache HTTPD and Tomcat are using, where you post the bits and then call for a vote on stability (alpha/beta/general availability). It's perfectly reasonable to have a series of general availability releases with new features in the 1.2.x series, as long as we continue to maintain backwards compatibility within it. Therefore the first release would be 1.2.1 and we'd keep going from there. I think it would be strange to go directly to a 1.2.1 release, which I suspect is why Ted was talking about a beta. Tomcat has a 4_1_0 tag in CVS, but I don't know if that was released as such. It's not my intention to reopen an old discussion, but I would like to confirm exactly what version this will be. Steve Craig - 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]
RE: Building struts-legacy (was: Re: Nightly build is generating empty binary distribution file)
Yes. All my projects use struts db connection and there was talk about removing it (which I presumed to be from the distribution). I assume it will not change, so building it every day is irrelevant. Thanks Edgar -Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED] Sent: Monday, July 21, 2003 10:56 PM To: 'Struts Developers List'; Edgar Dollin Cc: '[EMAIL PROTECTED]' Subject: RE: Building struts-legacy (was: Re: Nightly build is generating empty binary distribution file) On Mon, 21 Jul 2003, Edgar Dollin wrote: Date: Mon, 21 Jul 2003 20:04:11 -0400 From: Edgar Dollin [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED], [EMAIL PROTECTED] To: 'Struts Developers List' [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: RE: Building struts-legacy (was: Re: Nightly build is generating empty binary distribution file) Does it cost anything to leave in the struts-legacy? If not could you leave it until the 2.0 release? Having struts-legacy as part of Struts 1.x distributions is a different question than having it built automatically as part of the nightly builds and integrated into that release. I presume you are more interested in the former? Thanks Edgar Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Building struts-legacy (was: Re: Nightly build is generating empty binary distribution file)
Does it cost anything to leave in the struts-legacy? If not could you leave it until the 2.0 release? Thanks Edgar -Original Message- From: David Graham [mailto:[EMAIL PROTECTED] Sent: Monday, July 21, 2003 1:55 PM To: 'Struts Developers List' Subject: Re: Building struts-legacy (was: Re: Nightly build is generating empty binary distribution file) --- Martin Cooper [EMAIL PROTECTED] wrote: Craig R. McClanahan [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] On Sun, 20 Jul 2003, Steve Raeburn wrote: Date: Sun, 20 Jul 2003 22:21:16 -0700 From: Steve Raeburn [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED], [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Subject: Nightly build is generating empty binary distribution file I've noticed that the nightly build is not generating the binary distribution. There is an archive created but it's only 45 bytes. http://cvs.apache.org/builds/jakarta-struts/nightly/ As the gump build is working it looks like a configuration problem is preventing the files being copied/archived. Could this be to due to the build version number change from 1.1 to 1.2? I couldn't find any documentation on configuring the nightly build process so I can't confirm or fix the problem. Can someone please take a look and/or point me in the direction of some info on the nightly build config? It's running on my personal desktop (which recently went through a hard disk failure and replacement). Unfortunately, I've only got JDK 1.4.2 installed right now, and compiling struts-legacy requires 1.3 or before to compile :-(. Given that we have struts-legacy on its own release cycle, I think we need to decouple the struts-legacy build from the main Struts build. They were coupled shortly before the 1.1 final release, and that was a big pain when I was creating the release. I should be able to do 'ant clean dist' at the top level and point to an existing struts-legacy release, but I can't do that the way the builds are coupled right now. I could have just gone in and undone the coupling that was done (and I still could ;), but I'd like to understand why they are so tightly coupled before I do that. It seems not only unnecessary, but also highly undesirable, especially when struts-legacy is independently released. Not only that, but struts-legacy was only provided for backwards compatibility with 1.0.2. Now that 1.1 is out we should remove struts-legacy and get out of the DataSource implementation business altogether. I believe that was the original plan anyways. David -- Martin Cooper Thanks Steve Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com - 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]
RE: [ANNOUNCEMENT] Struts 1.1 Final released
Thank you for getting this out the door. It makes it easier to justify use of the software (although, I didn't have many complaints). I have been using the struts db connection. Is there a link for the legacy application in order to continue to use that part of the application. The reason I prefer using the struts connection is to make as few changes to web.xml as possible. Thanks Edgar -Original Message- From: Martin Cooper [mailto:[EMAIL PROTECTED] Sent: Monday, June 30, 2003 2:39 AM To: '[EMAIL PROTECTED]'; '[EMAIL PROTECTED]'; '[EMAIL PROTECTED]' Subject: [ANNOUNCEMENT] Struts 1.1 Final released The Struts team is proud, and extremely pleased, to announce the Final release of Struts 1.1. This release includes significant new functionality, as well as numerous fixes for bugs which were reported against the previous release, and supersedes the earlier 1.0.2 version as the latest official release of Struts from the Apache Software Foundation. The binary distribution is available at: http://www.apache.org/dist/jakarta/struts/binaries/ and the source distribution is available at: http://www.apache.org/dist/jakarta/struts/source/ In addition, the library distribution, which contains updated binaries without the sample applications, is available at: http://www.apache.org/dist/jakarta/struts/library/ Details of the changes in this release are available in the Release Notes, which can be found here: http://jakarta.apache.org/struts/userGuide/release-notes-1.1.html -- Martin Cooper - 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]
Recall: [ANNOUNCEMENT] Struts 1.1 Final released
Edgar Dollin would like to recall the message, [ANNOUNCEMENT] Struts 1.1 Final released. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
digester
I am looking into the various methods of processing xml files and was wondering why digester was used as opposed to jaxb. Thanks in advance. Edgar
RE: Code Submissions
What would be a typical turnaround time, or is no such animal? -Original Message- From: David Graham [mailto:[EMAIL PROTECTED]] Sent: Friday, December 06, 2002 10:39 AM To: [EMAIL PROTECTED] Subject: Re: Code Submissions You post patches in bugzilla. A committer reviews it and/or applies it and will post comments back to bugzilla. David From: Edgar Dollin [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: '[EMAIL PROTECTED]' [EMAIL PROTECTED] Subject: Code Submissions Date: Thu, 5 Dec 2002 16:17:39 -0500 Is there a feedback loop on code submissions? Edgar _ Add photos to your e-mail with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Source Code
As you are aware, there is a lot of good, general purpose, code in struts. I have been taking code and modifying it for my own uses. I thought this would be worth a 1 minute discussion so I understand the issues. My main issue is with clause 2. BTW clause three has a spelling error (acknowlegement is acknowledgement). Thanks in advance. Edgar * 1. Redistributions of source code must retain the above copyright *notice, this list of conditions and the following disclaimer. -- Obvious - leave it in the source code * 2. Redistributions in binary form must reproduce the above copyright *notice, this list of conditions and the following disclaimer in *the documentation and/or other materials provided with the *distribution. -- Not so obvious * 3. The end-user documentation included with the redistribution, if *any, must include the following acknowlegement: * This product includes software developed by the *Apache Software Foundation ( http://www.apache.org/ http://www.apache.org/). *Alternately, this acknowlegement may appear in the software itself, *if and wherever such third-party acknowlegements normally appear. -- OK seems pretty straight forward that somewhere in the documentation that this must be included. My assumption is that I could have a tools page to list any open source development tools I am using. * 4. The names The Jakarta Project, Struts, and Apache Software *Foundation must not be used to endorse or promote products derived *from this software without prior written permission. For written *permission, please contact mailto:[EMAIL PROTECTED] [EMAIL PROTECTED] -- OK * 5. Products derived from this software may not be called Apache *nor may Apache appear in their names without prior written *permission of the Apache Group. -- OK * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE * DISCLAIMED. IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR * ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT * OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE. -- Not clear where this would have to be placed.
FW: Struts 1.0.2, Nested 1.0 and Standard Tags 1.0.2
I posted this on struts-user and there were no takers. I didn't see any bugs like this posted and was wondering if this was truly a bug worth posting since I am not running 1.1b with JSTL. The only workaround I could find was to re-write the c:set as a very simple tag. Thanks Edgar -Original Message- From: Edgar Dollin Sent: Tuesday, November 05, 2002 12:08 PM To: '[EMAIL PROTECTED]' Subject: Struts 1.0.2, Nested 1.0 and Standard Tags 1.0.2 Has anyone gotten JSTL c:set to work with Struts nested:write. I get a null pointer exception in NestedPropertyHelper line 174. Thanks Edgar P. Dollin Blue Moose Software, LLC P/O Box 3865 Union, NJ 07083 908-688-0823 Fax 908-688-0671 [EMAIL PROTECTED] mailto:edgar;blue-moose.net http://www.blue-moose.net
RE: [FRIDAY] Re: Struts taglib
Who said building architecture has deep parallels to computer science anyway ;-)? -Original Message- From: Craig R. McClanahan [mailto:craigmcc;apache.org] Sent: Friday, November 01, 2002 11:52 AM To: Struts Developers List Subject: [FRIDAY] Re: Struts taglib On Fri, 1 Nov 2002, V. Cekvenich wrote: An architect is done not when he has nothing more to add, but when he has nothing left to remove. OK, so lets remove all the restrooms from all the public buildings. That functionality has all been factored out into the commons anyway (i.e. nearly everyone's home already has one), so we don't need them here. Such a conclusion would come as a rude shock to those in need of such facilities, who make the assumption well, it was right through that door yesterday Don't forget about backwards compatibility ... :-) Craig -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
RE: LabelTag
The number of missing attributes in the tag libraries is large enough to consider a change, especially since writing tag libraries is one of the most pleasurable parts of what we do ;-). Edgar. I do highly encourage the Struts committers to use XDoclet for TLD and documentation generation (but I guess if it ain't broke, don't fix it, eh?). Erik -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: LabelTag
My apologies for not understanding this particular issue. There are some liberties that by necessity need to be taken with the tag library definitions, i.e. styleClass for class. I don't understand why someone would care if there are 'excess' tags in the tag library. I would never consider looking at the tag library to determine the availability of a tag and if someone choose to use an attribute that is not supposed to be in the html, html will (is supposed to) ignore it. My apologies in advance to the original struts designers as I assume they had there reasons for the design choices. But, I have issues with the design of the 'html' equivalent struts tags. They are not constructed the way the html specification is designed. For example in html there is one tag for input with multiple types, in struts there are multiple tags (all of which require tld entries). If the struts tags were constructed in a fashion which matched the html spec, then many of the issues with excess tags would go away. -Original Message- From: Martin Cooper [mailto:[EMAIL PROTECTED]] Sent: Tuesday, October 15, 2002 10:43 AM To: 'Struts Developers List' Subject: RE: LabelTag Unfortunately, it's not that simple with the Struts tags. Many of the tags extend a base class which defines a number of common attributes. However, just because the code for an attribute is available does *not* mean that it should be exposed for every tag that extends the base class. A case in point is the HTML taglib. Which attributes are exposed for a particular tag is dependent upon the HTML 4.01 spec. In the implementation, it is very convenient to have several base classes which cover the large majority of attributes. However, there are some tags which extend the base classes, but which do not expose all of the attributes, so that they conform to the spec. Now, if we could get XDoclet to handle that... ;-) -- Martin Cooper -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: LabelTag
I think XDoclet is cool, but the issue here is not extra tags -- it's extra attributes. One of our primary design principles is that Struts tags would only contain attributes that correspond to valid attribute names (for that particular element) in HTML/4.01 -- whether the browser ignores extra ones or not is irrelevant, since our goal is to not emit invalid HTML. Not to be picky, but this is the HTML author inserting extra tags, not struts. Can you provide a specific example of what you mean by constructed in a fashion which matched the HTML spec and how you would suggest improving them? Keep in mind (per my preceding response) that we don't have the ability to modify the syntax of a TLD file, since that is defined by the JSP Specification. All we can possibly do is refactor the underlying base classes. The structure of the HTML spec is an object oriented document and if the elements and attributes were emitted in a similar fashion i.e. !ELEMENT SELECT - - (OPTGROUP|OPTION)+ -- option selector -- !ATTLIST SELECT %attrs; -- %coreattrs, %i18n, %events -- nameCDATA #IMPLIED -- field name -- sizeNUMBER #IMPLIED -- rows visible -- multiple(multiple) #IMPLIED -- default is single selection -- disabled(disabled) #IMPLIED -- unavailable in this context -- tabindexNUMBER #IMPLIED -- position in tabbing order -- onfocus %Script; #IMPLIED -- the element got the focus -- onblur %Script; #IMPLIED -- the element lost the focus -- onchange%Script; #IMPLIED -- the element value was changed -- one might have designed the following objects emitCoreattrs / emitI18n / emitEvents as java objects emitName as a object. In some ways struts takes shortcuts i.e. in the events it just always outputs all the events. In other ways it has too many objects, i.e. TextTag, HiddenTag instead of InputTag with type=text/hidden. Also, IMHO nesting should be an attribute of each base tag rather than a trivial object extending each of the base tags. The result is you end up with large unwieldy and buggy tld's. Of course if this is obsolete, then my apologies for wasting everyone's time :-(. Edgar -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: LabelTag
I guess we have a difference of opinion. I care about the tld's because they take time getting them correct and I have an explosion of entries in my projects. Also, the struts tld's (at least in 1.0.2) are missing attributes. HTML and all the other languages we use are hard enough to learn and get effective with, using consistent syntax much less inconsistent syntax. Yes there are differences and the class would be slightly larger than normal but it wouldn't be unmanageable and with clever syntactic analysis would not be much larger. After all the browser has to be built to handle the input html object. Thanks for your commentary. Edgar -Original Message- From: David Graham [mailto:[EMAIL PROTECTED]] Sent: Tuesday, October 15, 2002 12:50 PM To: [EMAIL PROTECTED] Subject: RE: LabelTag I think your suggestion on having one struts tag that emits any input type (like the html spec) is very flawed. Consider how huge that one tag would be if it knew how to output text, textarea, radio, checkbox, submit, and password fields. Each of the struts input tags have features unique to them and deserve to be separate. Also, the struts tags need attributes for html AND beans, properties, etc. That's why you see attributes like styleClass instead of class. Who cares how many tld entries there are? This is a non-issue, especially in servlet 2.3 where you don't ever have to see the tlds. Even without 2.3, it's trivial to put struts-*.tld files in your /WEB-INF directory. David -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
