You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Michael Westbay <we...@seaple.icc.ne.jp> on 2000/12/26 09:02:59 UTC
form:image tld
Hi, all,
There appears to be an inconsistancy with the script attributes for the
form:image TDL. The generated struts-form.tld uses:
onBlur
onChange
onClick
etc.
whereas all other tags are defined as:
onblur
onchange
onclick
etc.
This is just a small detail, but should probably be corrected before 1.0 ships.
--
Michael Westbay
Work: Beacon-IT http://www.beacon-it.co.jp/
Home: http://www.seaple.icc.ne.jp/~westbay
Commentary: http://www.japanesebaseball.com/
Re: HTML tag library
Posted by Johan Compagner <jc...@j-com.nl>.
Do it before the 1.0 release.
Because after that is will be much more difficult.
johan
----- Original Message -----
From: "Ted Husted" <ne...@husted.com>
To: "Struts List" <st...@jakarta.apache.org>
Sent: Monday, January 08, 2001 12:04 PM
Subject: HTML tag library
> Did we decide to rename the FORM tag library as the HTML tag library in
> a 1.0 timeframe?
>
> I agree it makes sense, the library has outgrown just forms, but it
> seems to break my existing late-model JSPs. Worked on the third, now
> not.
>
> We've been assuring people for several weeks that the code-breaking
> changes were complete.
>
> Or, is there a top-level way we can get the JSP's to use the HTML lib
> instead without editing them all?
>
> The change is not mentioned in the release notes, and I didn't see
> anything here; at first I thought it was a new library that would hold
> additional non-form tags.
>
> If we have some other non-form tags in mind (image, et cetera), I would
> suggest we leave the form library as it is, and introduce a new HTML
> library (since the form library is big enough), where both libraries
> would support the :html, :base, :link tags, and tags on an interim
> basis.
>
> I would also consider moving the bean:message, logic:interate, and
> logic:redirect tags to a HTML library. Of course, this becomes a
> discussion of procedural versus functional cohesion, and reasonable
> people can disagree.
>
> In any event, seperate HTML and Form libraries does seem to have higher
> cohesion to me, since some people might want to use the HTML tags
> without the rest of it.
>
> Incidentally, I note the JAR has jumped in size a bit this week. Was
> that the addition of the bean property options, or something else?
>
>
>
Re: HTML tag library
Posted by Ted Husted <ne...@husted.com>.
On 1/8/2001 at 10:56 AM Craig R. McClanahan wrote:
> You've made the "code breaking" claim in about five messages now, but
with no evidence. What breaks because of this change?
My mistake. It didn't seem to work the first time I tried it, but I
just tried again and it was fine. So, I'll shut up now .-)
-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Custom Software ~ Technical Services.
-- Tel 716 425-0252; Fax 716 223-2506.
-- http://www.husted.com/
Re: HTML tag library
Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
Ted Husted wrote:
> Did we decide to rename the FORM tag library as the HTML tag library in
> a 1.0 timeframe?
>
Yes.
>
> I agree it makes sense, the library has outgrown just forms, but it
> seems to break my existing late-model JSPs. Worked on the third, now
> not.
>
> We've been assuring people for several weeks that the code-breaking
> changes were complete.
>
You've made the "code breaking" claim in about five messages now, but with no
evidence. What breaks because of this change?
(NOTE: the "struts-form.tld" TLD *will* be included in 1.0, so you can migrate
your pages to "struts-html.tld" at your leisure).
>
> Or, is there a top-level way we can get the JSP's to use the HTML lib
> instead without editing them all?
>
> The change is not mentioned in the release notes, and I didn't see
> anything here; at first I thought it was a new library that would hold
> additional non-form tags.
>
Release notes have not yet been brought up to date ... that's part of "doc
updates" :-)
>
> If we have some other non-form tags in mind (image, et cetera), I would
> suggest we leave the form library as it is, and introduce a new HTML
> library (since the form library is big enough), where both libraries
> would support the :html, :base, :link tags, and tags on an interim
> basis.
>
The cost of splitting the "form versus non-form" tags into two libraries
include:
* Absolute guaranteed breakage of old JSP pages (since these
have always been in one library (struts-form.tld).
* Forcing essentially 100% of JSP page developers to have to use
one more taglib declaration than they currently need.
>
> I would also consider moving the bean:message, logic:interate, and
> logic:redirect tags to a HTML library. Of course, this becomes a
> discussion of procedural versus functional cohesion, and reasonable
> people can disagree.
What does <logic:iterate> have to do with rendering HTML? Nothing. Likewise
for <bean:message>. Such general purpose tags are needed no matter what kind of
output you are producing.
<logic:redirect> does not render any output either -- it relies only on the fact
that you're running over an HTTP protocol. If you add it to the HTML tag lib,
you're going to need to add a copy of it for XHTML, for WML, for ..... because
you need the functionality anyway.
>
> In any event, seperate HTML and Form libraries does seem to have higher
> cohesion to me, since some people might want to use the HTML tags
> without the rest of it.
>
That's guaranteed to break backwards compatibility (because the tags have always
been in a single TLD).
>
> Incidentally, I note the JAR has jumped in size a bit this week. Was
> that the addition of the bean property options, or something else?
Yes -- the org.apache.struts.taglib.html package was added (haven't yet removed
the org.apache.struts.taglib.form package which is now redundant).
Craig
Re: [PROPOSAL] Tag library cohesion
Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
Ted Husted wrote:
>
> HTML
> [snip]
> message [was Bean]
> - Render an internationalized message string to the response.
>
-1
<bean:message> is a general purpose output tag, and has nothing to do with
whether you are rendering HTML, XHTML, WML, XML, or whatever. It does not
belong here.
Craig
Re[2]: [PROPOSAL] Tag library cohesion
Posted by Oleg V Alexeev <go...@penza.net>.
Hello Craig,
CRM> Agreed, especially now that the ActionErrors class lets you record errors in that
CRM> fashion.
I think errors tag has one disadvantage - if you work with it, then
you must add same markup strings to every error message... And this
tag renders error messages in flat style - you can not place
properties names as delimiters between different blocks of errors for
different properties.
For my mind this tag must be more intelligent with task of errors
rendering - use flexible model to build complete errors list. 'Flexible
model' means - define all markup in resources and render error
messages group by group - for every property.
--
Best regards,
Oleg mailto:gonza@penza.net
Re[2]: [PROPOSAL] Tag library cohesion
Posted by Oleg V Alexeev <go...@penza.net>.
Hello Craig,
CRM> Agreed, especially now that the ActionErrors class lets you record errors in that
CRM> fashion.
I think errors tag has one disadvantage - if you work with it, then
you must add same markup strings to every error message... And this
tag renders error messages in flat style - you can not place
properties names as delimiters between different blocks of errors for
different properties.
For my mind this tag must be more intelligent with task of errors
rendering - use flexible model to build complete errors list. 'Flexible
model' means - define all markup in resources and render error
messages group by group - for every property.
--
Best regards,
Oleg mailto:gonza@penza.net
Re: [PROPOSAL] Tag library cohesion
Posted by Johan Compagner <jc...@j-com.nl>.
> > Yes, but the form lib should have an error tag. (not errors tag)
> > like this: <form:error property="myproperty"/>
> >
>
> While there is a lot of merit to this idea (except that it would now be called
> <html:error property="myproperty"/> instead :-), the challenge is to define what
> this tag should actually do. Anyone have ideas in that regard?
I don't know what the exact idee is at this time. Will we keep a form tag lib or will all go to the html?
if we keep a form tag lib then i would place the error in the form lib because that error is specifiek to
the form bean and a property where i want the error for.
I have made my own class ErrorTag tag copied the exact behaviour of the ErrorsTag but then
for one property.
If there are multiply errors for one property i separte then at this time with a comma because
the error must be on the same line, what i could do is place the 'and' between them.
But you are right about global errors that aren't attached to any property.
Maybe a GlobalErrorsTag that does the same thing as ErrorsTag but then only for the non property's?
johan
Re: [PROPOSAL] Tag library cohesion
Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
Johan Compagner wrote:
> > related to what craig mentions in a later message, the errors tag
> > should not be generating HTML output -- it should merely be aiding
> > in outputting the contents of ActionErrors found in the Request. The
> > formatting should be left up to the user. In light of this, i would
> > suggest that the errors tag (or its replacement) find a more appropriate
> > home under the bean library. the form library isn't appropriate
> > either since errors are only tangentially related to forms in that
> > validation can generate them.
>
> Yes, but the form lib should have an error tag. (not errors tag)
> like this: <form:error property="myproperty"/>
>
While there is a lot of merit to this idea (except that it would now be called
<html:error property="myproperty"/> instead :-), the challenge is to define what
this tag should actually do. Anyone have ideas in that regard?
Note also that there can be more than one error for a particular property, plus a
set of zero or more "global" error messages that the application did not attach to a
particular property.
>
> Because i personally can't believe that users use the errors tag
> because i find errors right after the place where there error is is much better.
>
Agreed, especially now that the ActionErrors class lets you record errors in that
fashion.
>
> johan
Craig
Re: [PROPOSAL] Tag library cohesion -WITHDRAWN
Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
Ted Husted wrote:
> If possible, I would like withdraw this "proposal" as ill-considered.
>
> Since renaming form to html doesn't actually break JSP code (my
> mistake), making any other changes to the libraries doesn't seem
> worthwhile now.
>
> The next step might be to see what JSR-052 comes up with.
>
FYI: I'm planning on submitting the Struts tags to the JSR-052 expert group for
their consideration, once we get to 1.0. (I'm also in that group as well, in
coordination with the other spec leads).
>
> -- Ted Husted, Husted dot Com, Fairport NY USA.
> -- Custom Software ~ Technical Services.
> -- Tel 716 425-0252; Fax 716 223-2506.
> -- http://www.husted.com/
Craig
Re: [PROPOSAL] Tag library cohesion -WITHDRAWN
Posted by Ted Husted <ne...@husted.com>.
If possible, I would like withdraw this "proposal" as ill-considered.
Since renaming form to html doesn't actually break JSP code (my
mistake), making any other changes to the libraries doesn't seem
worthwhile now.
The next step might be to see what JSR-052 comes up with.
-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Custom Software ~ Technical Services.
-- Tel 716 425-0252; Fax 716 223-2506.
-- http://www.husted.com/
Re: [PROPOSAL] Tag library cohesion
Posted by Johan Compagner <jc...@j-com.nl>.
> related to what craig mentions in a later message, the errors tag
> should not be generating HTML output -- it should merely be aiding
> in outputting the contents of ActionErrors found in the Request. The
> formatting should be left up to the user. In light of this, i would
> suggest that the errors tag (or its replacement) find a more appropriate
> home under the bean library. the form library isn't appropriate
> either since errors are only tangentially related to forms in that
> validation can generate them.
Yes, but the form lib should have an error tag. (not errors tag)
like this: <form:error property="myproperty"/>
Because i personally can't believe that users use the errors tag
because i find errors right after the place where there error is is much better.
johan
Re: [PROPOSAL] Tag library cohesion
Posted by Elod Horvath <el...@itfais.com>.
Ted Husted wrote:
>
> HTML
> ...
> errors
> - Conditionally display a set of accumulated error messages.
-1
related to what craig mentions in a later message, the errors tag
should not be generating HTML output -- it should merely be aiding
in outputting the contents of ActionErrors found in the Request. The
formatting should be left up to the user. In light of this, i would
suggest that the errors tag (or its replacement) find a more appropriate
home under the bean library. the form library isn't appropriate
either since errors are only tangentially related to forms in that
validation can generate them.
e
"Craig R. McClanahan" wrote:
>
> Ted Husted wrote:
>
> >
> > HTML
> > [snip]
> > message [was Bean]
> > - Render an internationalized message string to the response.
> >
>
> -1
>
> <bean:message> is a general purpose output tag, and has nothing to do with
> whether you are rendering HTML, XHTML, WML, XML, or whatever. It does not
> belong here.
>
--
_______________________________________________________________________
Elod Horvath ('e') / ITFAIS Records (http://www.itfais.com/)
Re: [PROPOSAL] Tag library cohesion
Posted by Ted Husted <ne...@husted.com>.
> But to keep it to a minimum: All the form specifiek stuff will be
left where it is at this time.
Only transfer the html specifiek stuf <form:html> <form:lin> ect to a
new html tag lib.
+1
I'd also consider the same approach for a HTTP tag lib, and get that
over with too.
This approach would then make these tags DEPRECATED from 1.0 to 1.1
FORM
base, errors, html, link, rewrite.
BEAN
cookie, header, message.
LOGIC
forward, iterate, redirect.
In favor of
HTML
base, errors, html, link, message.
HTTP
cookie, forward, header, redirect, rewrite.
Re: [PROPOSAL] Tag library cohesion
Posted by Johan Compagner <jc...@j-com.nl>.
Change it there will not be another time if struts 1.0 is released.
But to keep it to a minimum:
All the form specifiek stuff will be left where it is at this time.
Only transfer the html specifiek stuf <form:html> <form:lin> ect
to a new html tag lib.
Users don't get confused anymore if that was the case.
johan
----- Original Message -----
From: "Ted Husted" <ne...@husted.com>
To: <st...@jakarta.apache.org>
Sent: Monday, January 08, 2001 1:18 PM
Subject: [PROPOSAL] Tag library cohesion
> As a quick followup to myself, I thought I would specify how I might
> arrange the library tags. Of couse, when it comes to cohesion,
> reasonable minds can disagree!
>
> And if anything like this were to be done (in whichever time frame), I
> would volunteer to make the requisite changes to code and
> documentation. Of course, while suggesting this, I strongly believe
> that the 1.0 tag library must have full backward compatibility with the
> December 2000 builds of Struts, even if it means redundant code.
>
> HTML
>
> base
> - Render an HTML <base> Element
> errors
> - Conditionally display a set of accumulated error messages.
> html
> - Render an HTML <html> Element
> image
> - Renders an input of type "image"
> link
> - Render an HTML anchor or hyperlink
> message [was Bean]
> - Render an internationalized message string to the response.
> redirect
> - Perform an HTTP redirect to the specified URL.
> rewrite
> - Render an URI
>
> Form
>
> button
> - Render A Button Input Field
> cancel
> - Render a Cancel Button
> checkbox
> - Render A Checkbox Input Field
> file
> - Render A File Select Input Field
> form
> - Define An Input Form
> hidden
> - Render A Checkbox Input Field
> multibox
> - Render A Checkbox Input Field
> option
> - Render A Select Option
> options
> - Render a Collection of Select Options
> password
> - Render A Password Input Field
> radio
> - Render A Radio Button Input Field
> reset
> - Render A Reset Button Input Field
> select
> - Render A Select Element
> submit
> - Render A Submit Button
> text
> - Render An Input Field of Type text
> textarea
> - Render A Textarea
>
> [DEPRECATE for HTML]
> base
> errors
> html
> image
> link
> rewrite
>
> Bean
>
> cookie
> - Define a scripting variable based on the value(s) of the specified
> request cookie.
> header
> - Define a scripting variable based on the value(s) of the specified
> request header.
> include
> - Load the response from a dynamic application request and make it
> available as a bean.
> define
> - Define a scripting variable based on the value(s) of the specified
> bean property.
> page
> - Expose a specified item from the page context as a bean.
> parameter
> - Define a scripting variable based on the value(s) of the specified
> request parameter.
> resource
> - Load a web application resource and make it available as a bean.
> struts
> - Expose a named Struts internal configuration object as a bean.
> write
> - Render the value of the specified bean property to the current
> JspWriter.
> [DEPRECATE for HTML] message
>
> Now, I don't know what the working status of JSR-052 is, but I would
> guess an organizational consideration might be how a future XML tag
> library might fit into a tag library scheme (unless that's a
> non-sequitor), or how these libraries might work with another protocol
> or (conceptually) with another presentation platform. So, it might also
> be reasonable to have a HTTP library with
>
> HTTP
> cookie [was Bean]
> - Define a scripting variable based on the value(s) of the specified
> request cookie.
> forward [was Logic]
> - Forward control to the page specified by the specified
> ActionForward entry.
> header [was Bean]
> - Define a scripting variable based on the value(s) of the specified
> request header.
> redirect [was Logic]
> - Perform an HTTP redirect to the specified URL.
> rewrite [was Form]
> - Render an URI
>
> which might give us
>
> Bean - define, page, include, iterate, parameter, resource,
> struts, write.
>
> HTML - base, errors, html, image, link, message.
>
> HTTP - cookie, forward, header, redirect, rewrite.
>
> Form - button, cancel, checkbox, file, form, hidden, multibox,
> option, options, password, radio, reset, select, submit, text,
> textarea.
>
> Logic - equal, greaterEqual, greaterThan, lessEqual,
> lessThan, match, notEqual, notMatch, notPresent, present.
>
> Note that I sneaked iterate from logic to bean, since there are many
> ways to use iterate without ever touching a logic tag; in practice it
> really seems like a bean-thing to me (write on steriods).
>
> Again, I would strongly recommend that any change in the 1.0 timeframe
> provide full backward compatability with the December 2000 builds, even
> if it means redundant code.
>
>
>
Re[2]: [PROPOSAL] Tag library cohesion
Posted by Matthias Kerkhoff <ma...@BESToffers.de>.
> IMHO, now is the time to do the cleanup, and get rid of as much cruft as
> possible before 1.0 is deemed complete. Nightly builds come with the caveat
> that things are likely to change. I'd rather see the change happen now, so
> that 1.0 doesn't have to include all the stuff we wish it really didn't
> have. If that breaks a few things in the short term, so be it. After all,
> the goal is a framework that we hope many real applications will be built
> upon. Wouldn't we rather see them built on a clean foundation?
+1:
Re: [PROPOSAL] Tag library cohesion
Posted by Elod Horvath <el...@itfais.com>.
Martin Cooper wrote:
>
> IMHO, now is the time to do the cleanup, and get rid of as much cruft as
> possible before 1.0 is deemed complete. Nightly builds come with the caveat
> that things are likely to change. I'd rather see the change happen now, so
> that 1.0 doesn't have to include all the stuff we wish it really didn't
> have. If that breaks a few things in the short term, so be it. After all,
> the goal is a framework that we hope many real applications will be built
> upon. Wouldn't we rather see them built on a clean foundation?
>
> --
> Martin Cooper
> Tumbleweed Communications
>
+1
--
_______________________________________________________________________
Elod Horvath ('e') / ITFAIS Records (http://www.itfais.com/)
Re: [PROPOSAL] Tag library cohesion
Posted by Martin Cooper <ma...@tumbleweed.com>.
IMHO, now is the time to do the cleanup, and get rid of as much cruft as
possible before 1.0 is deemed complete. Nightly builds come with the caveat
that things are likely to change. I'd rather see the change happen now, so
that 1.0 doesn't have to include all the stuff we wish it really didn't
have. If that breaks a few things in the short term, so be it. After all,
the goal is a framework that we hope many real applications will be built
upon. Wouldn't we rather see them built on a clean foundation?
--
Martin Cooper
Tumbleweed Communications
----- Original Message -----
From: "Michael Westbay" <we...@seaple.icc.ne.jp>
To: <st...@jakarta.apache.org>
Subject: Re: [PROPOSAL] Tag library cohesion
> > Again, I would strongly recommend that any change in the 1.0 timeframe
> > provide full backward compatability with the December 2000 builds, even
> > if it means redundant code.
>
> Wouldn't you rather have a cleaner 1.0 version, without all of that
> deprication? Of course, you probably have more code committed to the
> December builds, so I can understand why you'd prefer the backward
> compatibility.
Re: [PROPOSAL] Tag library cohesion
Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
Ted Husted wrote:
> On 1/8/2001 at 9:48 PM Michael Westbay wrote:
> > Of course, you probably have more code committed to the December
> builds, so I can understand why you'd prefer the backward
> compatibility.
>
> Me and anyone that used a JSP form tag through (at least) 03-JAN-2001.
> The current build breaks most any useful Struts JSP ever written.
>
How so? The struts-form.tld TLD file is still there, and it still works fine
(the classnames point at the new classes). You can migrate your JSP pages to
struts-html.tld at your leisure.
Craig
Re: [PROPOSAL] Tag library cohesion
Posted by Ted Husted <ne...@husted.com>.
On 1/8/2001 at 9:48 PM Michael Westbay wrote:
> Of course, you probably have more code committed to the December
builds, so I can understand why you'd prefer the backward
compatibility.
Me and anyone that used a JSP form tag through (at least) 03-JAN-2001.
The current build breaks most any useful Struts JSP ever written.
> Wouldn't you rather have a cleaner 1.0 version, without all of that
deprication?
My position would be that
1 - Renaming Form to HTML is not a difference that makes a difference.
2 - JSP is code, and we said in November that we were past
code-breaking in a 1.0 timeframe.
If there were a Real Good Reason (like proposed JSP-052 compatability)
to rename Form, then fine, let's get it over with, and announce it in
LARGE LETTERS to the user list. But if it's just stylistic, people can
always use a HTML prefix if that makes more sense to them.
> image should be in FORM, not HTML. And "img" tag should be in the
HTML section - when created.
+1 = I was thinking of an HTML <IMAGE> tag, as has been mentioned now
and again. Which would be another good reason to have seperate Form and
HTML libraries.
It might be a good rule for everything in the Form library nested in
<form:form> , and everything in HTML nested in html:html, at least
logically.
-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Custom Software ~ Technical Services.
-- Tel 716 425-0252; Fax 716 223-2506.
-- http://www.husted.com/
Re: [PROPOSAL] Tag library cohesion
Posted by Michael Westbay <we...@seaple.icc.ne.jp>.
Husted-san wrote:
> HTML
>
> [...]
> image
> - Renders an input of type "image"
image should be in FORM, not HTML. And "img" tag should be in
the HTML section - when created.
> [...]
> HTML - base, errors, html, image, link, message.
Remove image.
> [...]
> Form - button, cancel, checkbox, file, form, hidden, multibox,
> option, options, password, radio, reset, select, submit, text,
> textarea.
Add image.
> Again, I would strongly recommend that any change in the 1.0 timeframe
> provide full backward compatability with the December 2000 builds, even
> if it means redundant code.
Wouldn't you rather have a cleaner 1.0 version, without all of that
deprication? Of course, you probably have more code committed to the
December builds, so I can understand why you'd prefer the backward
compatibility.
--
Michael Westbay
Work: Beacon-IT http://www.beacon-it.co.jp/
Home: http://www.seaple.icc.ne.jp/~westbay
Commentary: http://www.japanesebaseball.com/
[PROPOSAL] Tag library cohesion
Posted by Ted Husted <ne...@husted.com>.
As a quick followup to myself, I thought I would specify how I might
arrange the library tags. Of couse, when it comes to cohesion,
reasonable minds can disagree!
And if anything like this were to be done (in whichever time frame), I
would volunteer to make the requisite changes to code and
documentation. Of course, while suggesting this, I strongly believe
that the 1.0 tag library must have full backward compatibility with the
December 2000 builds of Struts, even if it means redundant code.
HTML
base
- Render an HTML <base> Element
errors
- Conditionally display a set of accumulated error messages.
html
- Render an HTML <html> Element
image
- Renders an input of type "image"
link
- Render an HTML anchor or hyperlink
message [was Bean]
- Render an internationalized message string to the response.
redirect
- Perform an HTTP redirect to the specified URL.
rewrite
- Render an URI
Form
button
- Render A Button Input Field
cancel
- Render a Cancel Button
checkbox
- Render A Checkbox Input Field
file
- Render A File Select Input Field
form
- Define An Input Form
hidden
- Render A Checkbox Input Field
multibox
- Render A Checkbox Input Field
option
- Render A Select Option
options
- Render a Collection of Select Options
password
- Render A Password Input Field
radio
- Render A Radio Button Input Field
reset
- Render A Reset Button Input Field
select
- Render A Select Element
submit
- Render A Submit Button
text
- Render An Input Field of Type text
textarea
- Render A Textarea
[DEPRECATE for HTML]
base
errors
html
image
link
rewrite
Bean
cookie
- Define a scripting variable based on the value(s) of the specified
request cookie.
header
- Define a scripting variable based on the value(s) of the specified
request header.
include
- Load the response from a dynamic application request and make it
available as a bean.
define
- Define a scripting variable based on the value(s) of the specified
bean property.
page
- Expose a specified item from the page context as a bean.
parameter
- Define a scripting variable based on the value(s) of the specified
request parameter.
resource
- Load a web application resource and make it available as a bean.
struts
- Expose a named Struts internal configuration object as a bean.
write
- Render the value of the specified bean property to the current
JspWriter.
[DEPRECATE for HTML] message
Now, I don't know what the working status of JSR-052 is, but I would
guess an organizational consideration might be how a future XML tag
library might fit into a tag library scheme (unless that's a
non-sequitor), or how these libraries might work with another protocol
or (conceptually) with another presentation platform. So, it might also
be reasonable to have a HTTP library with
HTTP
cookie [was Bean]
- Define a scripting variable based on the value(s) of the specified
request cookie.
forward [was Logic]
- Forward control to the page specified by the specified
ActionForward entry.
header [was Bean]
- Define a scripting variable based on the value(s) of the specified
request header.
redirect [was Logic]
- Perform an HTTP redirect to the specified URL.
rewrite [was Form]
- Render an URI
which might give us
Bean - define, page, include, iterate, parameter, resource,
struts, write.
HTML - base, errors, html, image, link, message.
HTTP - cookie, forward, header, redirect, rewrite.
Form - button, cancel, checkbox, file, form, hidden, multibox,
option, options, password, radio, reset, select, submit, text,
textarea.
Logic - equal, greaterEqual, greaterThan, lessEqual,
lessThan, match, notEqual, notMatch, notPresent, present.
Note that I sneaked iterate from logic to bean, since there are many
ways to use iterate without ever touching a logic tag; in practice it
really seems like a bean-thing to me (write on steriods).
Again, I would strongly recommend that any change in the 1.0 timeframe
provide full backward compatability with the December 2000 builds, even
if it means redundant code.
HTML tag library
Posted by Ted Husted <ne...@husted.com>.
Did we decide to rename the FORM tag library as the HTML tag library in
a 1.0 timeframe?
I agree it makes sense, the library has outgrown just forms, but it
seems to break my existing late-model JSPs. Worked on the third, now
not.
We've been assuring people for several weeks that the code-breaking
changes were complete.
Or, is there a top-level way we can get the JSP's to use the HTML lib
instead without editing them all?
The change is not mentioned in the release notes, and I didn't see
anything here; at first I thought it was a new library that would hold
additional non-form tags.
If we have some other non-form tags in mind (image, et cetera), I would
suggest we leave the form library as it is, and introduce a new HTML
library (since the form library is big enough), where both libraries
would support the :html, :base, :link tags, and tags on an interim
basis.
I would also consider moving the bean:message, logic:interate, and
logic:redirect tags to a HTML library. Of course, this becomes a
discussion of procedural versus functional cohesion, and reasonable
people can disagree.
In any event, seperate HTML and Form libraries does seem to have higher
cohesion to me, since some people might want to use the HTML tags
without the rest of it.
Incidentally, I note the JAR has jumped in size a bit this week. Was
that the addition of the bean property options, or something else?