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? If yes then whats the point of our html
tags.
-----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]
