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]
