Re: Tag question (JSP organization)

[Erik Weber]

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]