The problem is that the Struts Mailreader Example does some things just to show people how they would be done if they needed to do them for some good reason. The big fix would be to get back to work on the Struts Examples (plural) application that could demonstrate these type of techniques without trying to put it into the context of a program. Then, the Mailreader example could focus on demonstrating the simplest, best solution to its use cases.

Anyway, if the mapping.name is null, then Struts cannot create an ActionForm object, since it does not know what ActionForm to create.

AFAIK, all the other code and documentation is correct and as intended.

HTH, Ted.

Kirk Wylie wrote:
Ted Husted wrote:

The ActionMapping attribute is the name under which the ActionForm will
be stored in the chosen scope. If the attribute is not specified, then
the form-bean name is used instead. It's fine to specify an attribute
property, it's also fine to use the name property instead. (In the code,
it sets attribute to name if attribute is null.)


The problem is what happens if bean-name is null.

The actual behavior of the RequestProcessor code (under 1.1-final, that is) is that if the bean-name ActionMapping attribute is not specified, then what happens is that:
1) The Form Bean provided to the Action under execute() is always null
2) Nothing is put into the specified scope


(The relevant code is line 757 on o.a.s.util.RequestUtils).

Thus in order for Struts to do anything with the contents of the "attribute" attribute, the bean-name attribute must also be specified, otherwise it's ignored.

The reason why this seems like it does something for the Struts Example application is that the specific Action instances involved do both step 1 and step 2 from manually reading the contents of the attribute ActionMapping configuration attribute, rather than allowing Struts to do it itself: it's almost like a shortcut for doing a custom ActionMapping class with a parameter setter. This made it quite difficult to follow the logic of the Struts Example at first.

With that in mind, one of two things is probably the case:
1) My understanding of the code and its behavior is wrong;

2) The documentation could be improved to indicate the actual state of the code.

Does this seem accurate?

Kirk Wylie
M7 Corporation

HTH, Ted.

Kirk Wylie wrote:
> This is the first time I've raised anything on struts-dev, so please let
> me know if I should turn around and file it into bugzilla for tracking
> instead.
>
> All comments are based on 1.1 release.
>
> I've been making some pretty careful note of the Struts Example
> tutorial, and I'm having some issues with the declaration of the
> /editSubscription and /editRegistration actions. In terms of their
> logic, my understanding is that:
> 1) They're called through action chaining by the /saveRegistration and
> /saveSubscription actions respectively;
> 2) They create and populate into session scope instances of
> SubscriptionForm and RegistrationForm accordingly in the code for the
> action classes;
> 3) Because there is no "name" attribute specified on the action tag for
> each, there will be no automatically created
> This is my understanding from running the system, as well as walking
> through the relevant code in the RequestProcessor phases. Please let me
> know if I'm mistaken.
>
> My concern is in a mismatch with the documentation in the
> struts-config_1_1.dtd (and with the struts-config_1_2.dtd in current
> CVS), which states that the "attribute" XML attribute (isn't THAT
> confusing... :-) is:
>
> "Name of the request-scope or session-scope attribute that
> is used to access our ActionForm bean, if it is other than
> the bean's specified "name". Optional if "name" is specified,
> else not valid."
>
> However, the tutorial isn't doing this: both /editSubscription and
> /saveRegistration are using the "attribute" XML attribute without using
> the "name" XML attribute, which seems to be doing "the right thing"
> w.r.t. the application's semantics, but it doesn't match the
> documentation. It could also be that the example is using undocumented
> features of the system, which is nice, but possibly not well suited to a
> first tutorial of Struts.
>
> It seems from my reading that the correct way that the DTD documentation
> could be rewritten if in fact the documentation is incorrect is:
> "Name of the request-scope or session-scope attribute that is used to
> access our ActionForm bean, if it is other than the bean's specified
> "name". If "name" is not specified, then "attribute" will be disregarded
> by the Request Processor."
>
> This makes it clear that it's legal to specify "attribute", but that
> Struts will just ignore it. At least that's what I think is going on.
>
> Explainations? Comments? Should I file this in Bugzilla?
>
> Kirk Wylie
> M7 Corporation
>
>
> ---------------------------------------------------------------------
> 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]


--------------------------------------------------------------------- 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]



Reply via email to