struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Taylor, Jason" <jtay...@cobaltgroup.com>
Subject RE: struts 2.0 naming conventions?
Date Fri, 27 Sep 2002 22:10:19 GMT
what about objects from the session or context that you'd like to expose via
form beans (which you can do currently)?  Do *you* see a disconnect there?
;)

-----Original Message-----
From: Bartley, Chris P [PCS] [mailto:cbartl03@sprintspectrum.com]
Sent: Friday, September 27, 2002 12:56 PM
To: 'Struts Users Mailing List'
Subject: RE: struts 2.0 naming conventions?


> I'll agree to disagree if you will ;-)

I won't give up that easily!  :D  Seriously, my complaint stems from the
fact that it's just as valid to do the following to populate a (so-called)
"form" bean (that has setBar() and setBaz() methods):

   <a href="/foo.do?bar=1&baz=2">Click me</a>

Where's your "form" now?  ;)  You don't see a disconnect there?

See, my whole point is that the primary purpose of these beans is to
encapsulate parameters sent via an HTTP GET or POST request.  And we all
(hopefully) know that an HTML <form> isn't the only way to make such a
request.

So, with that, i'm done, and happy to agree to disagree.  :)

chris

> -----Original Message-----
> From: Eddie Bush [mailto:ekbush@swbell.net]
> Sent: Friday, September 27, 2002 2:30 PM
> To: Struts Users Mailing List
> Subject: Re: struts 2.0 naming conventions?
> 
> 
> Calling it "RequestParameterBean" causes a disconnect too.  
> Call it what 
> it is - we are OO folks after-all - a FormBean.  It *is* 
> intended to be 
> used with <html:form> - though you may find it handy for other things.
> 
> Sorry :-) Let's not start a religious debate over expected 
> convention. 
>  I name things deliberately by their expected context.  
> Following this 
> convention "FormBean" is not only an acceptable name, but a very 
> descriptive one.  It states that it is a bean which models a 
> form.  Is 
> this not why we have them?  Good OO tells us to name things 
> after their 
> real-world counterparts to avoid a disconnect - thus Form is a good 
> name.  Java convention for naming beans is to append Bean to the name 
> (so the name is indicative of it's attributes).  Putting the two 
> together ... well, I'm beating a dead horse ... :-)
> 
> I thought your complaint was that there were too many Action* 
> classes ...
> 
> I really think the conventions I state are sound.  You can't 
> expect to 
> be able to determine a classes full function just by looking at it's 
> name -- that is why we have javadocs, etc ... I know people 
> gripe about 
> the quality of documentation, but I seriously wonder how many of the 
> have truly taken the time to actually *look* at the javadocs.
> 
> I'll agree to disagree if you will ;-)  
> 
> Bartley, Chris P [PCS] wrote:
> 
> >No, my point is that any use of the word "form" in the name 
> of the class is
> >potentially confusing because apparently sometimes people 
> mistakenly think
> >"Oh, i have to use a <form>...</form> in the page that calls 
> this action".
> >
> >>Then, the name of the class goes well with what people call 
> it.  You 
> >>don't have a disconnect.
> >>
> >
> >Well, i think that people casually refer to it as a "form 
> bean" because it's
> >currently named "ActionForm".  If the class had been named
> >"RequestParametersBean" from the start, i doubt very much 
> that today people
> >would be calling it a "form bean".  I think it's the word 
> "form" in there
> >that's causing so much confusion for newbies (and at least 
> part of the
> >reason why there are so many questions that read something 
> like "how can i
> >call my action from a link and still have my form bean populated?").
> >
> >chris
> >
> 
> -- 
> Eddie Bush
> 
> 
> 
> 
> --
> To unsubscribe, e-mail:   
<mailto:struts-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail:
<mailto:struts-user-help@jakarta.apache.org>

--
To unsubscribe, e-mail:
<mailto:struts-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail:
<mailto:struts-user-help@jakarta.apache.org>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message