Re: Some thoughts on / problems with Struts (mostly tag related)
Hi I support most of the points raised by Matthias, as I encountered the same problems/interrogations. And everyone who have tried to extend Struts tags or implement forms created by designers have surely encountered them... Automatic bean creation ! Multiple select form-tags and nested properties ! name attribute in form tags !! If version 1.0 has to be incompatible with version 0.5, now is the time to take that sort of decision Generating id= in the html output ! form "method=get" will not work in every container styleClass attribute ! (defaults) values in form tags ! I don't apply totally for this one as I don't want to have localised values stored in forms, even initializations. code bloat due to unneccessary extension of BodySupport !! tags that work with collection of presentation things ! I would add that the errors tag can't be used due to bad design. Solutions have been suggested for the past months... Standard HTML attributes !! Matthias Pierre Métras
RE: Some thoughts on / problems with Struts (mostly tag related)
Keep in mind that it is perfectly ok (depending on how you want to design your app) for the user to come in through either the JSP page or through the action url. On that basis, you need to be able to specify and create the form bean in each of those two places, and those two places don't know anything about each other. The JSP page doesn't know about action mapppings, and the mapping doesn't know anything about all the particular JSP pages that may want to use that form. There is not even any stipulation that a form used in a JSP page has to be used in a mapping, e.g. the submit from the form could theoretically go to any URL. The inverse also applies. As to why the bean is automatically created if it doesn't exist, I do agree that there are cases in which you might want to have some sort of error if the bean doesn't already exist, but you can easily do that by having a special member variable in the bean that indicates that it has just been created. On a manual create you would reset that yourself, but on an auto create it would remain set, and the validate method would detect it (or you could check manually). -Original Message- From: Matthias Kerkhoff [mailto:[EMAIL PROTECTED]] Sent: Saturday, November 11, 2000 7:29 AM To: [EMAIL PROTECTED] Subject: Some thoughts on / problems with Struts (mostly tag related) Automatic bean creation --- I've noticed, that both the struts:form tag and the action servlet create the form bean if it doesn't exist. Also, the bean's name and scope can be specified in these two different places ways (in the action mapping and via attributes of the form tag). I am a bit confused, if this is really necessary and would appreciate an example where it makes sense to have both ways.
Re: Some thoughts on / problems with Struts (mostly tag related)
Colin Sampaleanu wrote: Keep in mind that it is perfectly ok (depending on how you want to design your app) for the user to come in through either the JSP page or through the action url. On that basis, you need to be able to specify and create the form bean in each of those two places, and those two places don't know anything about each other. The JSP page doesn't know about action mapppings, and the mapping doesn't know anything about all the particular JSP pages that may want to use that form. There is not even any stipulation that a form used in a JSP page has to be used in a mapping, e.g. the submit from the form could theoretically go to any URL. The inverse also applies. Your reasoning on why it needs to be created in either place is correct. What's still screwed up in the current design is that you have to specify the bean class and scope in two places (the page itself and the configuration file). Ideally the form tag should be smart enough to look up the right action mapping (based on where it's going to submit to) and therefore infer the right bean class and scope if not specified. I just haven't gotten that far yet. As to why the bean is automatically created if it doesn't exist, I do agree that there are cases in which you might want to have some sort of error if the bean doesn't already exist, but you can easily do that by having a special member variable in the bean that indicates that it has just been created. On a manual create you would reset that yourself, but on an auto create it would remain set, and the validate method would detect it (or you could check manually). For testing whether a bean was newly created by the JSP page, a particular feature of the jsp:useBean tag is useful -- the body of this tag is only evaluated when the bean is created. Consider the following: jsp:useBean id="beanname" scope="session" class="com.mycompany.MyBean" jsp:setProperty name="pageCreated" value="true"/ /jsp:useBean In this scenario, setPageCreated(true) will be called if the bean was created by this page. If the "pageCreated" property defaults to false, you now have an easy test. For general purpose detection of existing beans, the new logic tags make this easy: logic:notPresent name="beanname" scope="session" You are a bad boy ... the "beanname" bean is missing! /logic:notPresent Craig McClanahan
RE: Some thoughts on / problems with Struts (mostly tag related)
-Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] Sent: Sunday, November 12, 2000 11:03 PM To: [EMAIL PROTECTED] Subject: Re: Some thoughts on / problems with Struts (mostly tag related) Colin Sampaleanu wrote: Keep in mind that it is perfectly ok (depending on how you want to design your app) for the user to come in through either the JSP page or through the action url. On that basis, you need to be able to specify and create the form bean in each of those two places, and those two places don't know anything about each other. The JSP page doesn't know about action mapppings, and the mapping doesn't know anything about all the particular JSP pages that may want to use that form. There is not even any stipulation that a form used in a JSP page has to be used in a mapping, e.g. the submit from the form could theoretically go to any URL. The inverse also applies. As long as it can still handle the case where the action is not going to any particular mapping at all, and let's you specify the right values... Your reasoning on why it needs to be created in either place is correct. What's still screwed up in the current design is that you have to specify the bean class and scope in two places (the page itself and the configuration file). Ideally the form tag should be smart enough to look up the right action mapping (based on where it's going to submit to) and therefore infer the right bean class and scope if not specified. I just haven't gotten that far yet. As to why the bean is automatically created if it doesn't exist, I do agree that there are cases in which you might want to have some sort of error if the bean doesn't already exist, but you can easily do that by having a special member variable in the bean that indicates that it has just been created. On a manual create you would reset that yourself, but on an auto create it would remain set, and the validate method would detect it (or you could check manually). For testing whether a bean was newly created by the JSP page, a particular feature of the jsp:useBean tag is useful -- the body of this tag is only evaluated when the bean is created. Consider the following: jsp:useBean id="beanname" scope="session" class="com.mycompany.MyBean" jsp:setProperty name="pageCreated" value="true"/ /jsp:useBean In this scenario, setPageCreated(true) will be called if the bean was created by this page. If the "pageCreated" property defaults to false, you now have an easy test. For general purpose detection of existing beans, the new logic tags make this easy: logic:notPresent name="beanname" scope="session" You are a bad boy ... the "beanname" bean is missing! /logic:notPresent I was thinking more on the action handler side, your suggestions are of course easiest for a JSP page...
Some thoughts on / problems with Struts (mostly tag related)
Hello all,
although I'm not really lucky with the subject of this message,
I didn't find anything better. What follows are some thoughts
on and some problems I had/have with Struts.
It's absolutly possible that I'm making some wrong assumptions,
so some of the following points may appear a bit strange, but
it's equally possible, that I'm not the only one stumbling over
these things.
I would appreciate any comments and/or explanations from the more
experienced struts users or developers and hope that everyone
benefits from the discussion.
Thanks in advance
Matthias
Automatic bean creation
---
I've noticed, that both the struts:form tag and the action servlet
create the form bean if it doesn't exist. Also, the bean's name
and scope can be specified in these two different places ways (in
the action mapping and via attributes of the form tag). I am a bit
confused, if this is really necessary and would appreciate an example
where it makes sense to have both ways.
Multiple select
---
The select tag does not fully support multiple selection. As far as I
understand, it's possible to mark it as "multiple", but the select tag
has some references to getScalarProperty that will cause difficulties.
I too don't see, how a select multiple would keep it's selection
state, if the user has made some error elsewhere in the form and
the form get's redisplayed.
form-tags and nested properties
---
The form tags don't support nested or indexed properties by default.
I think, that all required code is already present (in PropertyUtils),
however BeanUtils.populate is implemented in a way, that prevents the
use of nested or indexed properties (by assuming that all property
names are names of simple properties). Why ?
Allowing nested or indexed properties could also lead to cleaner code
with multipage forms. Currently, using validate and reset in multipage
forms is a bit clumsy, because one has to clutter the code with
conditionals (like if(step == STEP_1) {...} else if (step == STEP_2){..}
and so) to implement partial validation and partial reset as needed
usually for multipage forms.
Having nested properties, this could easily be implemented by having
one (nested) bean per step and than just forward the validate or reset
to these nested beans.
Another benefit would be, that the multibox tag would become obsolete,
because the only additional functionality it offers are indexed properties.
name attribute in form tags
---
The name attribute is present in most form tags. The documentation
mentions, that the name attribute (for example in select or in checkbox
can be used to specify a bean, where the property value is query from.
Again, I don't see the reason for this attribute, because the value,
when sent back to the server, will not be set in the bean that served
it originally, but in the form bean.
Furthermore, the (struts) way to use of 'name' is quite confusing.
Most struts attributes names mirror html attribute names, so it's quite
predictable, that the average user will understand this as a general
design principle/naming convention.
However, 'name' completly breaks it and makes it the struts tags quite
difficult to understand (for HTML-designers, and they're usually the
intented users of jsp tags). For example:
- form name=means a bean name, but is also used as
html name attribute;
- select name= means a bean name, but is _not_ used as
html name attribute;
- select property= means a bean's property and _is_ used as html
name attribute;
Although I understand, the technical reasons behind the way _how_ the
struts attributes are used, I would think, that it would be a better
way to choose a different attribute name for concepts not related to
html (like it is done with 'property'). A good solution would be to
name (sic) the attribute 'bean'. That would make it's intention clear
and prevent any confusion with the html name attribute.
Maybe, it would also be a good idea to clearly document _how_ to name
tag attributes that ...
- represent struts-only concepts (like 'forward')
- represent concepts that have a meaning in both struts _and_ the
generated content-type (like locale, id or name)
- have a meaning only in the generated content type (like 'accesskey')
... and the update the tags to follow these hypothetical guidelines.
Generating id= in the html output
-
The struts form tags have no possibility to generate an id= in the
html output. This is one of the W3C's core attributes, ie. one that is
allowed in _every_ HTML tag. I don't understand, why struts doesn't
support it. (see also "Standard HTML attributes" below)
form "method=get" will not work in every container
--
Well, this is just one more of the uncountable WebLogic problems I've
found in the last few weeks. It may
Re: Some thoughts on / problems with Struts (mostly tag related)
What about a filtering solution instead of begin/end? Some sort of Eval clause? - Matthew W. Heinrichs Fax: 1(501)421-7321 cell: (612)749- -Original Message- From:Matthias Kerkhoff [EMAIL PROTECTED] Sent:Sat, 11 Nov 2000 13:28:51 +0100 To: [EMAIL PROTECTED] Subject: Some thoughts on / problems with Struts (mostly tag related) Possible solution: I would propose three additional arguments (start, end, between), with the following meanings: - start optional value where to start iterating a collection. If not present start at the first element. (Probably a better name would be offset, regarding the naming convention of logic:iterator) - end optional value where to end iterating a collection. If not present end at the last element. (An alternative would be to specify the number of iterations like iterator does.) - between Optional attribute, that contains markup that should be inserted between two iterated items. Not inserted before the first and after the last element. ___ Visit http://www.visto.com/info, your free web-based communications center. Visto.com. Life on the Dot.
Re[2]: Some thoughts on / problems with Struts (mostly tag related)
Hi Matt, What about a filtering solution instead of begin/end? Some sort of Eval clause? Of course other solutions would work well also. I just wanted to outline one possible approach. It's probably not the best, but a starting point for the discussion. Another approach instead of offset's would be the use of an iterator (attribute). However, both (the iterator and the filter/eval) need to be initialized somehow (for example with the first and last index :) or a list of matches or whatever. If you want to keep the JSPs clean, you have to create additional tags (struts:filter... or introduce additional attributes (match=), I think. My main point was that it should be possible to define a subset of an collection/array/... for iteration and to have the ability to add custom content between the output of two iterations. -- Matthias(mailto:[EMAIL PROTECTED])
