Thanks Erik!
I'm not very sure that <snip> </snip> but could just understand what you wrote
later. It could be true that the ActionForm was always intended as the target of a
submit, and values are to be retrieved from a VO for display.
I would not totally agree with this either, as too many examples point other
wise. I still beleive VOs must have data that is properly validated and stripped of
all formatting to make it as usable a possible. Neway, thanks for the patience Erik.
Would you let me in on a secret? How could I view the thread on this topic?
-----Original Message-----
From: Erik Weber [mailto:[EMAIL PROTECTED]
Sent: Monday, July 26, 2004 12:26 PM
To: Struts Users Mailing List
Subject: Re: Tag question (JSP organization)
Raghuram, the thread was started by me ;) and was entitled
"Prepopulating forms". It was a long thread and might give you some
ideas. Here is a snip from a reply by Joe Germuska that I thought of
when I read your post:
<snip>
At 12:16 PM -0400 7/12/04, Erik Weber wrote:
> Joe, thanks for your opinion. You and Rick have convinced me to stay
> with one form page for add/update. I did this before in a non-struts
> app, and despite all the conditionals I ended up with, the ensuing
> layout revisions did make it worth it.
>
> So, Joe, I am not using Dyna Forms, just plain old form beans. (I may
> refactor my DTOs/VOs and form beans into some base class because of
> all the shared fields, but for now, I'm getting a lot of use out of a
> bean generator I wrote). Are you agreeing then, that the best approach
> (currently) is to create an action for the view screen (in this case,
> the "update" form page), and in that action, obtain a VO and use the
> values from that to set the properties of the ActionForm? You are
> saying if I do this I need to explicity set a key to the form as a
> request attribute? (Somehow I assumed that the form already would be
> set as an attribute and that all I would need to do is modify the
> values of it).
When Struts calls execute(mapping ,form,request,response), the form that
it passes in is determined by the "name" attribute of the
ActionMapping. The name, of course, must reference a <form-bean>
element, which determines the type.
The ActionForm specified in the ActionMapping is intended as the wrapper
for request parameters, so only in limited cases will it also be of the
correct type for the subsequent view. If the only request parameter
your action needs is the ID of the VO object you'll retrieve for
population, then you could probably get away with specifying the "view
form" (or "output form") in the ActionMapping. It's just important to
note that this isn't how Struts is designed, and that inevitably, you'll
come upon a case where you need to pass in more input data and therefore
really need distinct form-beans for "input" and "output".
I believe in letting consenting adults do what they please, and so if
you understand this, I think you can do it safely. Some people are kind
of purists and insist on having a form bean even for the single ID
parameter which might be coming in to your action.
Getting back to specifics, Struts uses the "name" and "scope" properties
of an action-mapping to pass form beans between the controller and the
view. If your pre-view action and your form-submission action have the
same values then everything should work out (with a possible exception
if you are using "request" scope and use a redirect, which would cause
the "controller request" to go out-of-scope before the view can be drawn
using that data.
In the case when you can't use the same form-bean in your action and in
the subsequent view and yet you want to pre-populate a form in your
view, you simply must ensure that a form-bean of the proper type is
placed in the proper scope under the proper name by your action (or by a
Tiles controller, or by any other logic that can sneak in before the
view is rendered).
Hope that helps!
Joe
</snip>
Raghuram Kanadam wrote:
>I'm not sure I caught the thread. What does
>
> "despite how many Struts developers use the same form bean for both form
> prepopulation and user input processing, the form bean really was only designed for
> the latter"
>
>imply? Does it mean to say that a form is always a target of a submit? And it should
>not be used to retrieve values from and shown on a JSP? Rather values should be
>retrieved from a value Object for display?
>
Not sure if that's what he meant, but I *think* it's what he meant. I'm
not sure he's saying "should not be used", just that it's not what the
authors had in mind . . .
> If yes then whats the point of our html tags.
>
>
>
Well I'm not taking any sides on this matter! I just don't feel
comfortable posturing as any sort of expert on it. Joe would be the
expert, not me. His posts are a little over my head at this point. I
curse and scream until my screens show up with what I want on them, and
then I breathe a big sigh of relief, just like anyone else. ;)
Erik
>
>-----Original Message-----
>From: Erik Weber [mailto:[EMAIL PROTECTED]
>Sent: Monday, July 26, 2004 11:54 AM
>To: Struts Users Mailing List
>Subject: Re: Tag question (JSP organization)
>
>
>Well, during an earlier thread on this topic, one of the Struts
>contributors (I think he was a contributor -- can't remember who it was)
>posted that, despite how many Struts developers use the same form bean
>for both form prepopulation and user input processing, the form bean
>really was only designed for the latter. His argument was that rarely
>will your form bean be completely appropriate for your setup action. He
>suggested a different type of value object for use in prepopulation, if
>I understood him correctly. However, it appears to me that the form bean
>appears to be "appropriate" in the eyes of many developers more often
>than perhaps he would suggest, because many are obviously using the same
>form bean for both setup and input processing actions (including myself).
>
>So, if you are suggesting a change or extension to Struts, my first
>inclination is that the idea might be rejected for the reason I just
>explained. However, more importantly, I wonder if you are having a
>problem with using a setup action to prepopulate your form, altogether?
>So far, it has not been enough of a problem for me that I have had to
>seek another way to do it, but I don't have that much experience with
>Struts, either . . .
>
>I did see mentioned in one book about Struts that some people use the
>"reset" method in the same way you describe this "other" method you are
>suggesting -- for form prepopulation, though I think the Struts
>contributors and purists again would frown on this.
>
>Can you describe how this method you suggest would be easier or more
>efficient than using a "setup" action?
>
>Erik
>
>
>
>Raghuram Kanadam wrote:
>
>
>
>>The purpose of our setup action is that the form must be prepopulated. Is it not?
>>Then why not have a method on the form that wud prepopulate it, and call this with
>>the session/request object whenever it needs to be rendered . The form wud be
>>rendered using html:form so I thought we could as well have a method like this on
>>either the Action Form class, which would be called. This would be similar to
>>calling reset before setting the properties. Have I made myself clear?
>> However there are problems with this approach, the method must be called only
>> the first time a form is created and not the subsequent times for if the form was
>> in session then we would expect it to retain the values when we navigate back to
>> the page containing it.
>>
>>:)
>>
>>-----Original Message-----
>>From: Erik Weber [mailto:[EMAIL PROTECTED]
>>Sent: Monday, July 26, 2004 11:23 AM
>>To: Struts Users Mailing List
>>Subject: Re: Tag question (JSP organization)
>>
>>
>>I'm sorry Raghuram, I'm not able to understand your question. Could you
>>elaborate?
>>
>>Thanks,
>>Erik
>>
>>
>>Raghuram Kanadam wrote:
>>
>>
>>
>>
>>
>>>Erik,
>>> If prepopulation is an issue we are dealing with quit often, why cant we have
>>> a method similar to prepopulate which would be called whenever the html:form is
>>> called?
>>>
>>>
>>>
>>>-----Original Message-----
>>>From: Jim Barrows [mailto:[EMAIL PROTECTED]
>>>Sent: Friday, July 23, 2004 2:17 AM
>>>To: Struts Users Mailing List
>>>Subject: RE: Tag question (JSP organization)
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>>-----Original Message-----
>>>>From: Erik Weber [mailto:[EMAIL PROTECTED]
>>>>Sent: Thursday, July 22, 2004 1:25 PM
>>>>To: Struts Users Mailing List
>>>>Subject: Re: Tag question (JSP organization)
>>>>
>>>>
>>>>Haha! Thanks Jim for your usual wit and insight. I will take
>>>>your advice
>>>>to heart. And thanks for the compliment.
>>>>
>>>>I am gathering that by "fly in the security" you are referring to a
>>>>"need to change something in more than one place" problem,
>>>>rather than a
>>>>"serious hole needs to be addressed" problem. If it's the
>>>>latter, please
>>>>elaborate (tough to tell without actually encountering the
>>>>problem you
>>>>describe). I don't want to fall into the ranks of "corporate"
>>>>development. ;-)
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>Yeah... it's just a pain in the butt type problem that can get ugly if you're not
>>>careful about
>>>how you use wildcards.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>>I might do another example on extension mapping, put the two
>>>>together in
>>>>a nice HTML file, and actually have something to put on a server
>>>>somewhere, behind one of the domain names I bought years ago. ;) I
>>>>wonder if they support webwork? (only kidding)
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>Web work? HERETIC!!!! HERETIC!!!!! :) *LOL*
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>>Erik
>>>>
>>>>PS. Just teasing about corporate development. I love everything about
>>>>this job and am grateful for the Java community at large. I
>>>>think we are
>>>>collectively heading for great things. I just don't want us
>>>>to program
>>>>ourselves out of a job!
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>The trick is to not let anyone know we've done it. Isn't that what remote
>>>development is all about? Madly developing code from the bahamas while getting a
>>>tan and sipping margaritas.. :)
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>>Jim Barrows wrote:
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>-----Original Message-----
>>>>>>From: Erik Weber [mailto:[EMAIL PROTECTED]
>>>>>>Sent: Thursday, July 22, 2004 11:43 AM
>>>>>>To: Struts Users Mailing List
>>>>>>Subject: Re: Tag question (JSP organization)
>>>>>>
>>>>>>
>>>>>>Sure, Raghuram.
>>>>>>
>>>>>>Caution: long post!
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>><snip what="guts of really good article on url arranging"/>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>Finally, restricting access to *.jsp in your
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>web-resource-collection
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>>element of web.xml can force your users to use the controller
>>>>>>Servlet-relative action URIs and prevent them from accessing
>>>>>>JSPs directly.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>I usually assign a role of Developer to the *.jsp
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>collection, that way I can access them directly for debugging
>>>>purposes, even when they're on the production box. It's one
>>>>of those you might use it once a year, but boy is it nice to
>>>>have category.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>Also, I solved the problem that led to this post by putting an
>>>>>>init-param in web.xml called "controllerPath". I set its
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>value as an
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>>application scope attribute in a plug-in class. Now I can create
>>>>>>controller-relative hyperlinks like this, using the JSTL-like tags:
>>>>>>
>>>>>><html:link page="${controllerPath}/vendor/home">home</html:link>
>>>>>>
>>>>>>If someone wants to use extension mapping, I just set
>>>>>>controllerPath to
>>>>>>be the empty String.
>>>>>>
>>>>>>Now, what I want to know is, what flies out the window when I
>>>>>>decide to
>>>>>>learn JSF? I'm afraid to look. ;)
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>JSF is essentially JSP, just a lot of tags you wish you had
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>now, so it will still work.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>The fly that I see is security. Everytime you change your
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>controller servlet mapping, you would have to change these
>>>>mappings. You could do */actor/*, however another servlet
>>>>might be able to be tricked into providing access to the
>>>>forbidden path. It's a minor nit of course... but hey you asked :)
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>By the time I learn JSF,
>>>>>>someone will
>>>>>>have developed a "CRUD IDE" that builds your entire app in
>>>>>>five minutes,
>>>>>>based on actor names and a CSS stylesheet. In a few years, we
>>>>>>will have
>>>>>>highly-paid "stack trace" experts. The average "corporate
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>developer"
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>>will see a stack trace and run for the hills, having always
>>>>>>thought they
>>>>>>were a myth. The manager will have to call in a stack trace
>>>>>>expert, who
>>>>>>will, at the rate of $700 per hour, begin to explain to all the
>>>>>>remaining developers what a "stack" is . . .
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>The problem would be what? That we would be making to much money?
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>But seriously, hope this helps a newbie or two. Criticism is
>>>>>>always welcome!
>>>>>>
>>>>>>Erik
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>---------------------------------------------------------------------
>>>>>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]
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>---------------------------------------------------------------------
>>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]
>
>
>
>
---------------------------------------------------------------------
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]
