RE: Using struts forms as Value Objects: your opinion?
Hi friends, After a long discussion about the above subject - I found a related article, which was very interesting for me (as new to Struts) and I would like to forward it to you and will be happy to read your comments to it. It's called "Struts Live Chapter: Nested POJOs" and you can find it in: http://www.theserverside.com/articles/article.tss?l=StrutsLiveCh10 Rivka ** The contents of this email and any attachments are confidential. They are intended for the named recipient(s) only. If you have received this email in error please notify the system manager or the sender immediately and do not disclose the contents to anyone or make copies. ** eSafe scanned this email for viruses, vandals and malicious content. ** **
Re: Using struts forms as Value Objects: your opinion?
Laurie Harper wrote the following on 7/12/2005 8:25 PM:
Rick Reumann wrote:
(By the way I pass in an optional default format in my constructor as
shown above, but my converters have a setFormatPattern(..) method that
can change the format at any time)
Don't you end up with thread safety issues calling setFormatPattern()
though? I would want to call setFormat (or setLocale() or something) on
a per-request basis to cater to the individual user.
I probably would:) I just haven't thought about it that far in advance
since currently I don't have to deal with it. I'd be curious how others
use BeanUtils in circumstances where the Date formats would differ.
My wimpy way out would be to simply do something to what Larry does (I
think this is what he suggested)... put the ValueObject as a property in
the form bean and have String properties in the form bean that set the
different data types in the ValueObject. Then, I wouldn't even need to
use BeanUtils. Actually I'm thinking about adopting that pattern anyway
since it seems like less work. It's sort of annoying as it is to have to
write custom converters to handle situations where a blank or null field
comes across and ends up setting my numeric wrappers to 0 vs null.
So instead I'd have maybe some properties in my form like:
stringBirthDate;
public void setStringBirthDate( Sring bDate ) {
//Convert string here to Date based on Locale!
//this is unique per user so no problems
valueObjec.setBirthDate( date );
}
public String getStringBirthDate() {
//convert valueObject Date to proper String format
}
I'd probably create this fields for only the properties that aren't
Strings in the ValueObject. Then you don't need to use BeanUtils at all.
--
Rick
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using struts forms as Value Objects: your opinion?
Rick Reumann wrote: (By the way I pass in an optional default format in my constructor as shown above, but my converters have a setFormatPattern(..) method that can change the format at any time) Don't you end up with thread safety issues calling setFormatPattern() though? I would want to call setFormat (or setLocale() or something) on a per-request basis to cater to the individual user. Does BeanUtils ensure a new ConvertUtilsBean is instantiated each time? If so, I really like the idea of setting up all my common converters once on startup instead of in each request :-) L. -- Laurie, Open Source advocate, Java geek and novice blogger: http://www.holoweb.net/~laurie/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using struts forms as Value Objects: your opinion?
Rick Reumann wrote:
Borislav Sabev wrote the following on 7/12/2005 3:20 AM:
In fact I'm a bit confused what exactly is the recommended design
pattern in this case ...
My conclusion is really to use Strings,
Yes, you should use Strings in your ActionForms. Then you have your
business object POJO with the correct Data types declared and use
BeanUtils to make the conversion (unless you are one of the big Map
proponents then you don't even have to worry about using a value
object, but I digress):
//copying form bean properties into your value object
BeanUtils.copyProperties( yourValueObject, yourForm );
This I use the same way.
and if you pull back data from the db and need to enter it in the form
(typically for providing edit functioality) you do the reverse:
BeanUtils.copyProperties( yourForm, yourValueObject);
Please take a look to other email that I sent earlier - there i shared
my experince with some special "mediator" objects that are responsible
to move the data between Forms and BO.
If you register your own converters, BeanUtils will use those
converters if need be. (By the way, you mentioned you are having to
convert twice - once in the converter and again on the front end -
this shouldn't be the case.)
If it helps I can show you two of my converters.. not sure I'm doing
it that best way but it works. I have a
"CustomValueToSringConverter" Which is used by BeanUtils to look for
certain types like java.util.Date and java.sql.Date and formats them
into the correct String format that I need.
and then I have
"CustomStringToUtilDateConverter" and "CustomStringToSQLDateConverter"
that do the reverse ( take Strings and covert them to appropriate Dates )
Both are registered on Server startup so that I don't have to register
these a bunch of times. This is done in a ServletContextListener...
public void contextInitialized(ServletContextEvent contextEvent) {
ServletContext context = contextEvent.getServletContext();
try {
ConvertUtils.register(new CustomValueToStringConverter("MM/dd/"),
String.class);
ConvertUtils.register(new
CustomStringToSqlDateConverter("MM/dd/"), java.sql.Date.class);
...
(By the way I pass in an optional default format in my constructor as
shown above, but my converters have a setFormatPattern(..) method that
can change the format at any time)
I do the same - inittialization part is in plugin so it's done only once
on the load of the application.
All my emails are with a bit bitter tone because I just expected much
more from ActionForms, and now I'm a bit disapointed, especially about
data conversions and populations ...
But JSF is on the horizon ...
Regards
Borislav
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using struts forms as Value Objects: your opinion?
Rivka Shisman wrote the following on 7/12/2005 3:22 AM: I understand that you did not follow this thread from the beginning. As I mentioned before - when working with int, short, byte types - my app works fine. I don't get any runtime exception! I don't think you tried what Craig proposed. Your app probably only workds fine because either a) You aren't using a text field and the number types are definitely numbers (BeanUtils will convert them just fine). OR b) In your text fields you are always typing in the number in proper format (a true number type). Like craig said use a text field of type int in your ActionForm and then input "1233abcd" and see what happens. -- Rick - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using struts forms as Value Objects: your opinion?
Durham David R Jr Ctr 805 CSPTS/SCE wrote the following on 7/12/2005 10:09 AM: Is it crucial for the Action Form to have String properties? Five years of history with Struts (and I should know, since I created it originally) says "yes" :-) I think it's reasonable to have a numeric type for select-box. I often do this myself, but it's because I shoudn't. The reason being is what if later on you needed to provide the field as a input type="text" - possibly that will never happen, but it could, in which case it really should be a String as previously mentioned. -- Rick - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using struts forms as Value Objects: your opinion?
Borislav Sabev wrote the following on 7/12/2005 3:20 AM:
In fact I'm a bit confused what exactly is the recommended design
pattern in this case ...
My conclusion is really to use Strings,
Yes, you should use Strings in your ActionForms. Then you have your
business object POJO with the correct Data types declared and use
BeanUtils to make the conversion (unless you are one of the big Map
proponents then you don't even have to worry about using a value object,
but I digress):
//copying form bean properties into your value object
BeanUtils.copyProperties( yourValueObject, yourForm );
and if you pull back data from the db and need to enter it in the form
(typically for providing edit functioality) you do the reverse:
BeanUtils.copyProperties( yourForm, yourValueObject);
If you register your own converters, BeanUtils will use those converters
if need be. (By the way, you mentioned you are having to convert twice -
once in the converter and again on the front end - this shouldn't be the
case.)
If it helps I can show you two of my converters.. not sure I'm doing it
that best way but it works. I have a
"CustomValueToSringConverter" Which is used by BeanUtils to look for
certain types like java.util.Date and java.sql.Date and formats them
into the correct String format that I need.
and then I have
"CustomStringToUtilDateConverter" and "CustomStringToSQLDateConverter"
that do the reverse ( take Strings and covert them to appropriate Dates )
Both are registered on Server startup so that I don't have to register
these a bunch of times. This is done in a ServletContextListener...
public void contextInitialized(ServletContextEvent contextEvent) {
ServletContext context = contextEvent.getServletContext();
try {
ConvertUtils.register(new CustomValueToStringConverter("MM/dd/"),
String.class);
ConvertUtils.register(new CustomStringToSqlDateConverter("MM/dd/"),
java.sql.Date.class);
...
(By the way I pass in an optional default format in my constructor as
shown above, but my converters have a setFormatPattern(..) method that
can change the format at any time)
--
Rick
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using struts forms as Value Objects: your opinion?
Michael Jouravlev wrote:
/**
* Flag that demo mode is on
*/
private boolean isDemo;
public boolean getIsDemo() { ... }
public setIsDemo(boolean isDemo) { ... }
... and my methods *would be commented in javadoc* too, it would be
much better than current approach with lots of lines and comments for
each getter/setter. Three properties commented in current approved
Java style, and you already lost in the code. This sucks.
Funny, I used to be *sure* you could do something like that, and just
yesterday went looking through the Javadoc tool documentation trying to
figure it out. Don't know where I got the idea you could do this from...
It would be so nice if there was a 'Properties' section in Javadoc, along
with Fields and Methods, that skipped getters / setters unless explicitly
documented and just described each property with 'readable' and 'writeable'
flags, using standard JavaBeans conventions to identify properties.
Of course, there's no reliable place to store the Javadoc since properties
may or may not have associated fields... :-(
--
Laurie, Open Source advocate, Java geek and novice blogger:
http://www.holoweb.net/~laurie/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Using struts forms as Value Objects: your opinion?
> > Is it crucial for the Action Form to have String properties? > > > > Five years of history with Struts (and I should know, since I > created it originally) says "yes" :-) I think it's reasonable to have a numeric type for select-box. - Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using struts forms as Value Objects: your opinion?
Ted Husted wrote: In my experience, there's at least two best practices for every problem. Sometimes you waterfall, and sometimes you agile. Sometimes you hibernate, sometimes you ibatis. Sometimes, you property, and sometimes you map. One-size-fits-all is the pointy-hair grail :) Excellent written! And the wisdom is to know which one to apply where and how, together with the advantages/disadvantages. (my favorite technical author is Martin Fowler who always write very, very clear what the problem is, what are the solutions and leaves you to decide what to choose) IMHO this comes only with experience ... Regards Borislav - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using struts forms as Value Objects: your opinion?
On 7/11/05, netsql <[EMAIL PROTECTED]> wrote: > Good theory that I used to beleive. > In practice, that is why I went from Beans to Maps. 10% of get/sets on a > project tend to be deprecated either becuase of model changes or becuase > of view changes. > W/ a Map: > - you don't have VO/DTO classes, but still have layer, 0 code, 0 bugs > - It's dynamic, when DAO SQL string changes... so does your > jxTable/Displaytag. > > I removed an entire layer and still have the layer. Ditto :) > Developers are so pasionate... that's what makes them good. +1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using struts forms as Value Objects: your opinion?
In my experience, maps can be better when the database is driving. When the purpose of the application is to expose the database, then most of the map attributes can correspond directly to database fields. You can also use the same tokens. If the database calls the fact birth_date, then the fact is birth_date, and everybody knows that, because the database says so. The type safety afforded by properties can be helpful, but it doesn't come close to solving the problem. Even after you have a date, there's the question of whether it's in the correct range. So, we end up declaring the type as a property and again as part of the input validation. I do understand the value of type safety, but I also understand the value of not repeating yourself. :) When using maps, you can document the attributes through a static class of constants. To use code completion, you can just start typing the name of the static class. With a modern IDE, like IDEA or Resharper, It's also quite easy to find every place an attribute is used, and it's just as easy to refactor the attribute name. The data type, including any constraints, should also already be documented as part of the data schema. Even without referring to the data schema, most basic types, like dates, can be communicated through naming conventions that any sane database should already be using anyway. Of course, if you are not using a well-documented database with online documentation (we use Confluence), then don't try this at home. If the database is not driving, or the database blows baby chunks, then, yes, it's a much better idea to create your own property-based model within the application. In my experience, there's at least two best practices for every problem. Sometimes you waterfall, and sometimes you agile. Sometimes you hibernate, sometimes you ibatis. Sometimes, you property, and sometimes you map. One-size-fits-all is the pointy-hair grail :) -Ted On 7/11/05, Frank W. Zammetti <[EMAIL PROTECTED]> wrote: > It's ironic to me that I had this same discussion with someone at work > just last week :) > > I *was* in the "Maps are better" camp until a few months back when I > changed my mind, and it comes down to one thing: > > Self-documenting code is better. > > A bean is self-documenting in that you can immediately tell what its > attributes are and what types they are. I'm not even talking about > generating javadoc from the source either, but that's certainly a very > nice by-product. > > Developers HATE documenting. I'm sure there are exceptions, but by and > large that is a very fair generalization in my experience. If you trust > a developer to document what is going into a Map, your asking for > trouble, generally-speaking. > > I don't personally use an IDE, but I think Rick's point about > auto-completion and the like is important because many people *DO* use > IDEs, and if you give them a bean they can be more effective faster than > if you give them a map with some documentation on what they may find in > it at various points in time, and that's even assuming the documentation > is accurate :) > > Especially in a team environment, I would always go with a real bean now > over a Map-based design, even though I agree with may of the points made > on why Maps are good. But in this world of trade-offs, I think you gain > more by using a bean than you do by using a Map, again, generally-speaking. > > Frank - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using struts forms as Value Objects: your opinion?
In JDNC, it's all native... (collections in my case) ...and what JDNC is? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using struts forms as Value Objects: your opinion?
Rivka Shisman wrote:
Is it crucial for the Action Form to have String properties?
Yes.
Http/html is a String protocol. A user types in a string in your forms
(unless it's a callendar tag for dates)
rambles on:
Only exception is if you have R/O, only getters, that you would not even
need to declare in Struts.config as formbean. Then it can be "native" type.
If you use same bean for both a R/O and a R/W form, you might have:
int getRamount(){}
String getAmmount(){}
setAmont(String a){}
A duplicate getter ;-}
In JDNC, it's all native... (collections in my case)
.V
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using struts forms as Value Objects: your opinion?
Craig McClanahan wrote: Blame backwards compatibility. By the time this issue was raised, there were huge numbers of applications already dependent on the previous behavior, which would have been broken by a change. However, this shouldn't have *any* impact on "incorrect values in forms". If you are following the recommended design pattern of using String fields in your form beans, it shouldn't trouble you. In fact I'm a bit confused what exactly is the recommended design pattern in this case ... My conclusion is really to use Strings, or even mapped forms. If you want a default Date or some other default than provide that before going to your form...or if after it submits and you see a null, then provide the default. You could of course register your own converter to provide a default for when a Date is null- but I would NOT do this. I thought about such variant but I don't find it good as well, but may be this is the less harmful or let's say less painful. Dates and Times and Timestamps were *deliberately* omitted from the default set of conversions performed by BeanUtils. The reason is simple ... such conversions are Locale specific, and BeanUtils has not This is clear for me, but at least default locale can be covered. But I think this is not for this thread, it's out of Struts mailing list scope. Sorry if this writings sound as complain - this the last think I want to make. Just after reading a lot of "advices" I found let's say my own way to work with Struts, and IMHO this is a sign of mature framework (because there is no only one way, it gives choices and I have to decide which trade-offs to take. concept (in its standard APIs at least) of what a "Locale" is. You can use the converters in "org.apache.beanutils.locale" for dealing with this sort of thing, but that came later than the basic Struts architecture. Craig Regards Borislav - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using struts forms as Value Objects: your opinion?
Frank W. Zammetti wrote: It's ironic to me that I had this same discussion with someone at work just last week :) I *was* in the "Maps are better" camp until a few months back when I changed my mind, and it comes down to one thing: Self-documenting code is better. A bean is self-documenting in that you can immediately tell what its attributes are and what types they are. I'm not even talking about generating javadoc from the source either, but that's certainly a very nice by-product. Developers HATE documenting. I'm sure there are exceptions, but by and large that is a very fair generalization in my experience. If you trust a developer to document what is going into a Map, your asking for trouble, generally-speaking. I don't personally use an IDE, but I think Rick's point about auto-completion and the like is important because many people *DO* use IDEs, and if you give them a bean they can be more effective faster than if you give them a map with some documentation on what they may find in it at various points in time, and that's even assuming the documentation is accurate :) Especially in a team environment, I would always go with a real bean now over a Map-based design, even though I agree with may of the points made on why Maps are good. But in this world of trade-offs, I think you gain more by using a bean than you do by using a Map, again, generally-speaking. Frank I personally use map in early stages of development when the bean properties (and their respective form properties) change very often. This gives me flexibility to change easy and fast the jsp-s and to show them to the end user (because most of the time they don't understand abstract models, but they understand screens and forms). When we are ready with such "prototyping" I reafactor the code and start to use "normal" form beans and eventually the validator. The other trade-off with mapped forms is that the errors you can catch only runtime, which is not true if you use form beans.(excluding the errors in jsp, unless you can pre-compile them before the deployment) Btw, I'm evangelist about self-documenting code :-) . Regards Borislav - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using struts forms as Value Objects: your opinion?
On 7/12/05, Rivka Shisman <[EMAIL PROTECTED]> wrote: > Hi Craig > > I understand that you did not follow this thread from the beginning. > As I mentioned before - when working with int, short, byte types - my > app works fine. I don't get any runtime exception! > If you are not getting an exception in this case (an ActionForm of type "int", bound to a text field on the input form, and the user types "1a3"), then you must be doing something other than the simple description I provided. Or, you must be violating another important principle (if the user types "1a3" in an integer field, you should redisplay the page with an appropriate error message *and* the "1a3" should be there for the user to fix. > Is it crucial for the Action Form to have String properties? > Five years of history with Struts (and I should know, since I created it originally) says "yes" :-) > Rivka Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using struts forms as Value Objects: your opinion? BeanUtil C onverter
Nitish Kumar wrote:
"This is a HUGE problem with BeanUtils and why I end up having to
register custom converters:("
good point, but where do I register my custom converters? I dont want to do
it in my action classes, and writing a plugin just to register my converters
would be a big overhead.
Writing a plugin is quite easy and takes not more than 10 minutes. So
don't affraid and try it :-) , if you'd like I can share some code here.
I have only one plugin which I use only for this purpose - to init some
special libraries like BeanUitils converter, Hibernate Session Factory etc.
It's very usefull, becuase I don't like the usual practice to make
inizializations in static scope of the clases (because the sequence of
these static initializations can vary run time)
Why cant we have declative registration through struts-config.xml, just like
other components and struts should take care of registering my converters
with ConvertUtil? (If its not already done yet!)
This would actually give me flexibility to have my custom types as well in
the form bean.
Lets say, for some application I want all java.util.Long types to be
appended with "$" symbol, it becomes much easier with a converter.
what do you say?
this is good point, as I saw Craig McClanahan also likes the idea ...
probably the development team will embrace it.
Regards
Borsilav
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Using struts forms as Value Objects: your opinion?
Hi Craig I understand that you did not follow this thread from the beginning. As I mentioned before - when working with int, short, byte types - my app works fine. I don't get any runtime exception! Is it crucial for the Action Form to have String properties? Rivka -Original Message- From: Craig McClanahan [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 12, 2005 8:06 AM To: Struts Users Mailing List Subject: Re: Using struts forms as Value Objects: your opinion? On 7/11/05, Rivka Shisman <[EMAIL PROTECTED]> wrote: > Hi guys, > > Borislav - thank you for the time you spent debugging this issue :-) > > So now I wonder - is it o.k. to use typed properties in my Action Forms? > Or is there an important reason why I should Strings only? > To answer this question for yourself, please build a trivial Struts based application like this: * Build a form bean that has a property of type "int". * Build a JSP page with a form that binds this property to a text input field. * Deploy the application, and type "1a3" instead of "123" into that field. If you like the result (a runtime exception), then by all means go ahead and make your action form properties be typed. Otherwise, if you're going to use Struts you should listen to all the tutorials and books and articles and mailing list messages that tell you to make your form bean properties be strings :-). Craig McClanahan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] ** The contents of this email and any attachments are confidential. They are intended for the named recipient(s) only. If you have received this email in error please notify the system manager or the sender immediately and do not disclose the contents to anyone or make copies. ** eSafe scanned this email for viruses, vandals and malicious content. ** ** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using struts forms as Value Objects: your opinion?
On 7/11/05, Borislav Sabev <[EMAIL PROTECTED]> wrote: > Rick Reumann wrote: > > > > > You shouldn't want a "default" at all provided by BeanUtils for cases > > where it can be null! You are using the anomoly of the way Integer is > > working and wanting to propogate that poor solution. null should be > > null.. it shouldn't be 0 or some default Date if null is provided. > > > Yes, this is the strange point. So null value doesn't have the same > semantic for Integer, Double etc. and Date, so I find this a bit > confusing ...this means at least different approach in handling the > incorrect values in forms. Blame backwards compatibility. By the time this issue was raised, there were huge numbers of applications already dependent on the previous behavior, which would have been broken by a change. However, this shouldn't have *any* impact on "incorrect values in forms". If you are following the recommended design pattern of using String fields in your form beans, it shouldn't trouble you. > > > If you want a default Date or some other default than provide that > > before going to your form...or if after it submits and you see a null, > > then provide the default. You could of course register your own > > converter to provide a default for when a Date is null- but I would > > NOT do this. > > I thought about such variant but I don't find it good as well, but may > be this is the less harmful or let's say less painful. > Dates and Times and Timestamps were *deliberately* omitted from the default set of conversions performed by BeanUtils. The reason is simple ... such conversions are Locale specific, and BeanUtils has not concept (in its standard APIs at least) of what a "Locale" is. You can use the converters in "org.apache.beanutils.locale" for dealing with this sort of thing, but that came later than the basic Struts architecture. Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using struts forms as Value Objects: your opinion?
Rick Reumann wrote: You shouldn't want a "default" at all provided by BeanUtils for cases where it can be null! You are using the anomoly of the way Integer is working and wanting to propogate that poor solution. null should be null.. it shouldn't be 0 or some default Date if null is provided. Yes, this is the strange point. So null value doesn't have the same semantic for Integer, Double etc. and Date, so I find this a bit confusing ...this means at least different approach in handling the incorrect values in forms. If you want a default Date or some other default than provide that before going to your form...or if after it submits and you see a null, then provide the default. You could of course register your own converter to provide a default for when a Date is null- but I would NOT do this. I thought about such variant but I don't find it good as well, but may be this is the less harmful or let's say less painful. Actually, in regards to a Date, in case you didn't already realize, you'll have to provide your own converter anyway if you plan to use java.util.Date since BeanUtils doesn't provide that by default.. it only provides conversion for java.sql.Date. If you need help with the converters I can post some code or search the struts archives for "java.util.Date converter" I found this as well, which was other surpise. (that java.sql.Date is not supported directly). Other confusing is that if you use ConvertUtils to convert back from Date to String (so you can show it in the jsp) it doesn't use the format that is loaded by the converter. This problem again force me to have the format string at least in 2 places: once in the converter that I register in ConvertUtils, and once in my formatter that I use to display the date values. Thus, you are encouraged to use the forms primary as input forms, not as output (but there is a survey among Struts developers how they use the forms, and more than 50% use them for input and output) IMHO this a "inconsistency" and force us to make a lot of additional workarounds and tricks... Regards Borislav - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using struts forms as Value Objects: your opinion?
On 7/11/05, Rivka Shisman <[EMAIL PROTECTED]> wrote: > Hi guys, > > Borislav - thank you for the time you spent debugging this issue :-) > > So now I wonder - is it o.k. to use typed properties in my Action Forms? > Or is there an important reason why I should Strings only? > To answer this question for yourself, please build a trivial Struts based application like this: * Build a form bean that has a property of type "int". * Build a JSP page with a form that binds this property to a text input field. * Deploy the application, and type "1a3" instead of "123" into that field. If you like the result (a runtime exception), then by all means go ahead and make your action form properties be typed. Otherwise, if you're going to use Struts you should listen to all the tutorials and books and articles and mailing list messages that tell you to make your form bean properties be strings :-). Craig McClanahan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using struts forms as Value Objects: your opinion? BeanUtil C onverter
On 7/11/05, Nitish Kumar <[EMAIL PROTECTED]> wrote:
>
> "This is a HUGE problem with BeanUtils and why I end up having to
> register custom converters:("
>
> good point, but where do I register my custom converters? I dont want to do
> it in my action classes, and writing a plugin just to register my converters
> would be a big overhead.
>
I guess I have a pretty hard time understanding why this is a "big
overhead". Writing a Struts plugin is about the same amount of effort
as writing a ServletContextListener implementation to do the same
thing (which is the better approach if you're on a Servlet 2.3 or
later container).
But, the key point is that either way it's a pretty simple method
declaration, plus one line of code for each converter you want to
register.
> Why cant we have declative registration through struts-config.xml, just like
> other components and struts should take care of registering my converters
> with ConvertUtil? (If its not already done yet!)
>
> This would actually give me flexibility to have my custom types as well in
> the form bean.
>
> Lets say, for some application I want all java.util.Long types to be
> appended with "$" symbol, it becomes much easier with a converter.
>
> what do you say?
>
That's certainly possible to implement ... and I'm sure the Struts
developer community would consider an RFE plus a patch to make it
possible. But, to me personally, this isn't the highest possible
return you can get from using a framework, so it wouldn't surprise me
if the Struts developers focused on different areas first.
In the mean time, if you want to get any attention to this issue, the
starting point would be to file an RFE in the issue tracking system
.
> Thanks and Regards,
> Nitish Kumar
>
Craig
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Using struts forms as Value Objects: your opinion?
Hi guys,
Borislav - thank you for the time you spent debugging this issue :-)
So now I wonder - is it o.k. to use typed properties in my Action Forms?
Or is there an important reason why I should Strings only?
I don't add my Action Form properties to the Struts config file. Is it
o.k. - or am I missing something here?
Thanks
Rivka
-Original Message-
From: Borislav Sabev [mailto:[EMAIL PROTECTED]
Sent: Monday, July 11, 2005 7:38 PM
To: Struts Users Mailing List
Subject: Re: Using struts forms as Value Objects: your opinion?
Nitish Kumar wrote:
>I think raghavendra is right.
>Rivka, your code is working because you are using primitive type int
and not
>the wrapper type Integer.
>In case of primitive type in case of any exception, it gives you a
default
>value.
>
>
>Thanks and Regards,
>Nitish Kumar
>
>
>
>
So after small debugging session I found why it works for Integers and
not for dates (at least in my case)
all classes that implment Convertors interface in BeanUtils, have
something like this as implementation of convert() method:
public Object convert(Class type, Object value) {
if (value == null) {
if (useDefault) {
return (defaultValue);
} else {
throw new ConversionException("No value specified");
}
}
if (value instanceof Date) {
return (value);
}
try {
return (Date.valueOf(value.toString()));
} catch (Exception e) {
if (useDefault) {
return (defaultValue);
} else {
throw new ConversionException(e);
}
}
}
In case of the Integer there is pre-load default value and EVEN if
conversion fails during the population phase, it just use is the dafault
value (and you think it's parsed correctly). In the previous example its
a coincidence that Rivka have 0 as default value (it's just the same
value as init value of IntegerConverter).
The strange point is that I didn't find how can I set a default date
value ... if someone knows it, please share this knowledge here.
For sure this is not a big discovery, but I spent a lot of hours to
udnerstand it and I though that this should be described somewhere at
some public place ... that's why I was a bit bitter in my previuos posts
Regards
Borislav
**
The contents of this email and any attachments are confidential.
They are intended for the named recipient(s) only.
If you have received this email in error please notify the system manager or
the
sender immediately and do not disclose the contents to anyone or make copies.
** eSafe scanned this email for viruses, vandals and malicious content. **
**
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using struts forms as Value Objects: your opinion? BeanUtil C onverter
"This is a HUGE problem with BeanUtils and why I end up having to
register custom converters:("
good point, but where do I register my custom converters? I dont want to do
it in my action classes, and writing a plugin just to register my converters
would be a big overhead.
Why cant we have declative registration through struts-config.xml, just like
other components and struts should take care of registering my converters
with ConvertUtil? (If its not already done yet!)
This would actually give me flexibility to have my custom types as well in
the form bean.
Lets say, for some application I want all java.util.Long types to be
appended with "$" symbol, it becomes much easier with a converter.
what do you say?
Thanks and Regards,
Nitish Kumar
-Original Message-
From: Rick Reumann [mailto:[EMAIL PROTECTED]
Sent: Monday, July 11, 2005 11:17 PM
To: Struts Users Mailing List
Subject: Re: Using struts forms as Value Objects: your opinion?
Borislav Sabev wrote the following on 7/11/2005 1:37 PM:
> In case of the Integer there is pre-load default value and EVEN if
> conversion fails during the population phase, it just use is the dafault
> value (and you think it's parsed correctly). In the previous example its
> a coincidence that Rivka have 0 as default value (it's just the same
> value as init value of IntegerConverter).
Bingo:) Sorry saw this thread late and could have helped out much
sooner. This is a HUGE problem with BeanUtils and why I end up having to
register custom converters:(
BeanUtils (at least it always has done this, maybe in a recent version
it's hopefully changed?), will end up converting null values to 0!!
Stupid, stupid if you ask me (null means null not 0!) Goes the same for
the other numeric wrappers as well. (I think their argument was for
backwards compatibility with apps that expect that behavior).
In regard to you point...
> The strange point is that I didn't find how can I set a default date
> value ... if someone knows it, please share this knowledge here.
You shouldn't want a "default" at all provided by BeanUtils for cases
where it can be null! You are using the anomoly of the way Integer is
working and wanting to propogate that poor solution. null should be
null.. it shouldn't be 0 or some default Date if null is provided.
If you want a default Date or some other default than provide that
before going to your form...or if after it submits and you see a null,
then provide the default. You could of course register your own
converter to provide a default for when a Date is null- but I would NOT
do this.
Actually, in regards to a Date, in case you didn't already realize,
you'll have to provide your own converter anyway if you plan to use
java.util.Date since BeanUtils doesn't provide that by default.. it only
provides conversion for java.sql.Date. If you need help with the
converters I can post some code or search the struts archives for
"java.util.Date converter"
--
Rick
-
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]
Re: Using struts forms as Value Objects: your opinion?
On 7/11/05, Laurie Harper <[EMAIL PROTECTED]> wrote: > > Most of my validation is handled by the Validator framework right now > which, admitedly, ties things to Struts to some extent (though there's no > reason I couldn't pull Validator 'down' a level and use it under some other > presentation technology if it didn't provide an equivalent. > Indeed, making this possible was a primary reason for separating validator out of Struts and moving it to Jakarta Commons in the first place. This has enabled lots of folks to use Commons Validator for enforcing rules in the business tier (as opposed to the view tier) -- to say nothing of allowing Shale to leverage the client side validation capabilities without depending on Struts 1.x code. > L. Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using struts forms as Value Objects: your opinion?
Michael Jouravlev wrote: On 7/7/05, Laurie Harper <[EMAIL PROTECTED]> wrote: Is not it easier to have one nested VO/BO with string properties, than to copy properties back and forth from action form to VO? I use web framework only to expose my real objects to the outer world. If you don't mind your VOs/BOs being untyped then sure, I guess it's easier. Personally I'd rather use strongly typed interfaces as far as possible. 2) value objects should use typed interfaces to ensure marshaling to and from presentation format (string types) is pushed as far up the application stack as possible. This also enables other, potentially type-aware, presentation / client tiers to be built on top of the same value objects (e.g. for a web-services interface). I think I do not agree with this one. Let's take it as a design requirement that application that we build is a webapp. It potentially can have different interfaces. This would mean, that: * input data is stingified because of HTTP * Struts is not the only front end Just because the transport protocol is HTTP doesn't mean you're only dealing with string data though. If I add a web services layer, I'll want ot talk in terms of domain types. If I want to add some other RPC mechanism the same will be true. Therefore, it is much easier to create BO/VO with dual string/typed interface or with string interface only. It would do validation and conversion to native datatype internally instead of doing it in validate() method. I believen that this is more flexible approach. What are you going to do with your validation code, if you are told to move from Struts to WebWork or Tapestry? I don't see the difference between having dual string/typed properites and having the same thing split between two classes, other than making the one class more confusing and error prone to use. Most of my validation is handled by the Validator framework right now which, admitedly, ties things to Struts to some extent (though there's no reason I couldn't pull Validator 'down' a level and use it under some other presentation technology if it didn't provide an equivalent. L. On 7/8/05, Craig McClanahan <[EMAIL PROTECTED]> wrote: Form beans are part of the *view* tier, not the model ... their purpose in life is to represent the server side state of the HTML elements on a form, even if that state is invalid (i.e. not currently passing all the validations). That way, you can reproduce what the user typed so he or she can fix it, rather than presenting them with a completely blank screen. (This is why you generally use string fields in a form bean). This is one way to look at things. Another way is to use VO/BO for input/output directly. When I use existing data, I load it into BO and display it. When I modify it, I update BO using its string properties. If I decide to cancel updates, I siply remove the BO from memory, no database changes needed. If I create a new object, I create a new BO and fill it in. Until I persist it, it hangs in the session. If I decide to cancel, then I remove it, and database would not even know that I was about to insert an object. In a component oriented framework like JSF or Tapestry, you don't need to worry about keeping track of this state information ... the components do it for you. JSF still differentiates "real" object (whatever it might be, a real business object or a VO) from visual component data, which I don't like. From my point of view, it is much easier to have an object with an ID, to view/edit it, or to delete it. Therefore, I do not need viewstate for UI components. I only need to store my object somewhere like in session while I work with it. I want my widgets and my view to be as dumb as possible. All data and state that I need is in real objects, I do not need artificial viewstate to duplicate it. I can understand why JSF or ASP.NET went this route with UI objects and viewstate: to abstract from the model/business layer. They do not want to establish a firm contract with business/persistence layer. They do not want to require a certain BO lifecycle or the datatype limitations. But I as a developer find this inconvenient. Web frameworks designers focus on their framework, while I as an application designer, focus on business data, business process and business state. Take ActiveX. There is a contract, there are interfaces, methods and datatypes defined. Just build an object according to the protocol, and you will be able to have design-time interface, runtime interface, everything. Web frameworks do not want to have strict contracts with data layer probabaly to be more flexible. I would take contract over flexibily anytime. Presuming that this is a flexible contract ;-) Michael. -- Laurie, Open Source advocate, Java geek and novice blogger: http://www.holoweb.net/~laurie/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional com
Re: Using struts forms as Value Objects: your opinion?
I don't see how enabling BO/VO to read stringified data makes them dependant on Struts packages. On 7/8/05, Bill Schneider <[EMAIL PROTECTED]> wrote: > Well put. To expand on #2, it's good to confine dependencies on the > org.apache.struts packages to the presentation layer, and not build a > Struts dependency into business logic. > > > Personally I prefer to keep form beans and value objects seperate, for > > two key reasons: > > > > 1) form beans generally should consist of String data to facilitate > > round-tripping of invalid inputs. I like to constrain them to a clearly > > defined role of marshaling data 'into' and 'out of' the presentation > > layer, i.e. across the boundary between presentation and application. > > > > 2) value objects should use typed interfaces to ensure marshaling to and > > from presentation format (string types) is pushed as far up the > > application stack as possible. This also enables other, potentially > > type-aware, presentation / client tiers to be built on top of the same > > value objects (e.g. for a web-services interface). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using struts forms as Value Objects: your opinion?
Yeah, that's a fair point, it is a bit more documenting than it probably
could be... then again, all modern IDEs will do it for you, right? And
I even have my UltraEdit macros to do it. Still, fair point.
Having not looked into it very much, does annotations in 1.5 help at all
in this regard I wonder?
Frank
Michael Jouravlev wrote:
On 7/11/05, Frank W. Zammetti <[EMAIL PROTECTED]> wrote:
A bean is self-documenting in that you can immediately tell what its
attributes are and what types they are. I'm not even talking about
generating javadoc from the source either, but that's certainly a very
nice by-product.
If I could have a property in Delphi or C# style... Or if I could at
least write something like that:
/**
* Flag that demo mode is on
*/
private boolean isDemo;
public boolean getIsDemo() { ... }
public setIsDemo(boolean isDemo) { ... }
... and my methods *would be commented in javadoc* too, it would be
much better than current approach with lots of lines and comments for
each getter/setter. Three properties commented in current approved
Java style, and you already lost in the code. This sucks.
Michael.
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Re: Using struts forms as Value Objects: your opinion?
> W/ a Map:
> - you don't have VO/DTO classes, but still have layer, 0 code, 0 bugs
> - It's dynamic, when DAO SQL string changes... so does your
> jxTable/Displaytag.
>
> I removed an entire layer and still have the layer.
>
> Developers are so pasionate... that's what makes them good.
I'm with you on this one. I see DTO's being misused in the Struts
world. The pattern originally solved the overhead associated with
invoking getters/setters over a network. In the world of web browser
sends/requests data from a single application server, where does the DTO
fit in? I don't see it.
That said, a form object is kind of like a DTO in that it serves as a
staging area for the users data and generally has a more fine grained
view of the data (not a 1 to 1 mapping with business domain objects).
Jumping right in, my Actions pass DynaBeans to a service layer. The
service layer processes the DynaBean. Here's an example from a service
interface:
public interface PersonnelService {
/**
* Stores an employee.
*
* id - Long - required for update, null or 0 for create
* first - String
* middle - String (optional)
* last - String
* email - String
* phone - String (optional)
*
* @param employeeBean the bean containing the employee properties
* @return the resultant employee
*/
public Employee storeEmployee(DynaBean employeeBean);
/**
* Gets the employee with the given id.
* @param id id of employee
* @return the employee
*/
public Employee findEmployeeById(long id);
}
Here's an Action that serves as a client for this service:
public class EmployeeAction extends BaseMappingAction {
public ActionForward save(ActionMapping mapping,
ActionForm form, HttpServletRequest
request,
HttpServletResponse response)
throws Exception {
DynaBean employeeBean = (DynaBean) form;
try {
service.storeEmployee(employeeBean);
} catch (...) {
// handle various errors
}
return mapping.findForward("personnel");
}
}
Here's a unit test that serves as a client for this service:
public void testAddEmployee() throws Exception {
DynaBean employeeBean = new LazyDynaBean();
employeeBean.set("first", "Sam");
employeeBean.set("middle", "G");
employeeBean.set("last", "Kroner");
employeeBean.set("email", "[EMAIL PROTECTED]");
employeeBean.set("phone", "(210) 555-7632");
Employee employee = service.storeEmployee(employeeBean);
...
}
Here's an abbreviated implementation of the PersonnelService
storeEmployee method:
public Employee storeEmployee(DynaBean employeeBean) {
Employee employee = new Employee();
// do the work of creating an Employee object based on the bean
...
employeeDAO.store(employee);
return employee;
}
I'm guessing that the coupling police will start screaming... Yes,
there is some documentation overhead in the PersonnelService interface,
but I don't want Actions doing any business logic. Actions simply pass
the data from client, put things in the various scopes, and direct to
the proper view.
The Map camp would probably say that no Employee class is needed at all,
putting me somewhere in between the Map camp and the Bean camp. I use
Hibernate, so beans are the best option on the backend. Apparently
iBatis works very well with maps.
- Dave
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using struts forms as Value Objects: your opinion?
Rick Reumann wrote: Call me stupid but I don't even know what p-langs are (languages I can urinate on?:) lol. PHP (Friendster tried J2EE, went to PHP). Part of LAMP stack, conisdered most effective. Try Tiki-Wiki or Drupal when you get a project, you are 80% done. Python (used by Google) Plone (use on Spring home page) .V - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using struts forms as Value Objects: your opinion?
netsql wrote the following on 7/11/2005 4:20 PM: Realy Rick, please try Groovy... it's the answer that's looking for you. I am sure you have read some of the Rails press. Actually, Groovy is one of the things I do want to take a look at. Hopefully one of these days I'll get to it:) -- Rick - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using struts forms as Value Objects: your opinion?
Rick Reumann wrote:
They have to look at a database model in order to figure
out how to get back a dateOfBirth field?
Yup. Each develolper has a 24" poster of the data model. DBA is in
charge, Model Driven. Just like client server days.
Now
they want to iterate over this list and display some properties.
I use JXTable that needs a tableModel.
I wrote a class that extends tableModel that takes init(List)
In Struts, you can pass the List to DisplayTag, but you know that.
they'll have to look up the database model.
Yup. Each develolper has a 24" poster of the data model. DBA is in
charge, Model Driven. Just like client server days. Did you bring that
up again?
I'm just glad I don't have to
work on projects where I have to go to the datamodel to figure out the
names of my properties to use as a key in order to get out a property
from a Map.
what if you had...
if ( someCondition ) {
Integer age = (Integer)employee.get("DOB");
//other stuff
}
We almost never see class cast exception in practice.
> How does the developer know what "type"
was used for the value? I can look at a bean and see...
No type. Look, lots of developers are using dynamic langs.
I suggest you try Groovy one time, just play w/ it. Its
Better/Faster/Ligher J2EE.
Realy Rick, please try Groovy... it's the answer that's looking for you.
I am sure you have read some of the Rails press.
Double price; but I have not idea what type of value
shippingOrder.get("price") is. The developer just has to guess or where
does he look? The datamodel?
OK... I see your main point is that one has to memorize the data model.
In order to write good fast scalaeable querries you have to know the
model.
DBA is resposible for the data model. They tend to be VERY experienced
w/ production issues. So I leverage their experience over java
developers, most Java people tend to have less than 10 years prof. exp.
> Sure
if only one person has to deal with the code, it 'might' be faster since
he might simply remember all the types etc, but what happens when the
code is inherited? Pity on that developer.
Good theory that I used to beleive.
In practice, that is why I went from Beans to Maps. 10% of get/sets on a
project tend to be deprecated either becuase of model changes or becuase
of view changes.
W/ a Map:
- you don't have VO/DTO classes, but still have layer, 0 code, 0 bugs
- It's dynamic, when DAO SQL string changes... so does your
jxTable/Displaytag.
I removed an entire layer and still have the layer.
Developers are so pasionate... that's what makes them good.
.V
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[FRIDAY] Re: Using struts forms as Value Objects: your opinion?
Frank W. Zammetti wrote the following on 7/11/2005 4:00 PM: Ditto :) (That's my Patrick Swayze moment for the day) awhhh shucks, I thought you were a Rush Ditto-head for a moment:) See I labeled this thread [FRIDAY] - I didn't want the sruts-list users police showing up (just messin around guys, point taken on cutting down on OT posts..yada.. yada.. yada:) -- Rick - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using struts forms as Value Objects: your opinion?
On 7/11/05, Frank W. Zammetti <[EMAIL PROTECTED]> wrote:
> A bean is self-documenting in that you can immediately tell what its
> attributes are and what types they are. I'm not even talking about
> generating javadoc from the source either, but that's certainly a very
> nice by-product.
If I could have a property in Delphi or C# style... Or if I could at
least write something like that:
/**
* Flag that demo mode is on
*/
private boolean isDemo;
public boolean getIsDemo() { ... }
public setIsDemo(boolean isDemo) { ... }
... and my methods *would be commented in javadoc* too, it would be
much better than current approach with lots of lines and comments for
each getter/setter. Three properties commented in current approved
Java style, and you already lost in the code. This sucks.
Michael.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using struts forms as Value Objects: your opinion?
netsql wrote the following on 7/11/2005 3:36 PM: Most of the sucessfull p-langs are dynamic. In flash, array and map are same class even. I envy their sucess. For example, the home page of Spring is done in Plone. Vic, I love you man, but coming back with what Flash or some other XML/kitchenSink/FlavorOfTheMonth/SOAP/MOMMA/EJB/hibernate-ibatis/JAX/DNC/GOP/ACLU/EPA/DEA language does isn't germane to the situation. Call me stupid but I don't even know what p-langs are (languages I can urinate on?:) -- Rick - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using struts forms as Value Objects: your opinion?
Rick Reumann wrote: But also remember it's not just about how nice it is to find out the types and names of the properties. Using Maps can introduce a lot of hidden bugs that are difficult to track down (mentioned just a few in last e-mail) Ditto :) (That's my Patrick Swayze moment for the day) -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using struts forms as Value Objects: your opinion?
-1 for maps after how strongly typed is an object???
+1 for Value Objects If you follow the axiom from Floyd Marinescu
Design custom value objects that wrap arbitrary sets of data as needed by
the client, completely decoupled from the layout of the domain model on the
serverDesign custom value objects that wrap arbitrary sets of data as needed
by the client, completely decoupled from the layout of the domain model on
the serverDesign custom value objects that wrap arbitrary sets of data as
needed by the client, completely decoupled from the layout of the domain
model on the serverDesign custom value objects that wrap arbitrary sets of
data as needed by the client
completely decouple from the layout of the domain model of the server
excerpted from this analysis of ValueObjects,VO Factory available from the
birthplace of HAL at University of Illinois Urbana
http://72.14.207.104/search?q=cache:AgD8-5ccZJ4J:jerry.cs.uiuc.edu/~plop/plop2001/accepted_submissions/PLoP2001/fmarinescu0/PLoP2001_fmarinescu0_0.pdf+%22ValueObject%22+AND+%22Map%22&hl=en
HTH,
Martin-
Design custom value objects that wrap arbitrary sets of data as needed by
the client, completely decoupled from the layout of the domain model on the
server- Original Message -
From: "Rick Reumann" <[EMAIL PROTECTED]>
To: "Struts Users Mailing List"
Sent: Monday, July 11, 2005 2:56 PM
Subject: Re: Using struts forms as Value Objects: your opinion?
netsql wrote the following on 7/11/2005 2:15 PM:
I think it vastly simplifies to use Maps in places where I used to use
beans. (I even got rid of baseBeans domain how much I loved maps)
Vic I think you sleep with the Map API under your pillow at night or use
it as a Teddy Bear when you sleep:)
I agree Maps will work fine for rapid development, but I like the type
safety of using typed properties in my VOs.
Just as an example, I know we both use iBATIS, under your Map idea, you
could end up with the crap out occuring at the DB level whereas if you use
a typed POJO you'll find the error much sooner. What if in your scenario
you pass in some mangled up String represntation of a Date as your value
in your map and the backend then needs to process that as Date in the DB?
You'll end up with a DB exception. Using normally typed POJOs you won't
have this problem since you'll catch it much sooner when trying to do the
conversion of your String to Date.
The other aspect is just the pure functionality of using a typed VO vs a
Map. For example if you are using a Map to represent an Employee how do
you know what to name the keys? Someone can put in map.put("firstName",
name ).. someone else might put map.put("fName", name ) ? even using
Constants is messy (map.put(Constants.NAME, name).. granted that's better
but now you have to maintain a constants class as well as you Map in place
of a standard POJO?
How do you deal with these issues? How does a developer working on your
code know how to even get the properties out of your Map? I guess he has
to look at some API contract saying put date of birth in the Map as "dob"
not "dateOfBirth." Also, the rapid development using Maps will sure end
up being a drawback when you end up having to work with the Maps. In my
IDE I can get dot completion to work easily but that's not gonig to work
with your Map approach. If I need firstName from employee I can just do
employee(dot)=[pop up of methods]... you're going to get .. employee.
[ get, put, etc Map methods !]
-
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]
Re: Using struts forms as Value Objects: your opinion?
Frank W. Zammetti wrote the following on 7/11/2005 3:48 PM: A bean is self-documenting in that you can immediately tell what its attributes are and what types they are. I'm not even talking about generating javadoc from the source either, but that's certainly a very nice by-product. amen:) But also remember it's not just about how nice it is to find out the types and names of the properties. Using Maps can introduce a lot of hidden bugs that are difficult to track down (mentioned just a few in last e-mail) -- Rick - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using struts forms as Value Objects: your opinion?
netsql wrote the following on 7/11/2005 3:25 PM:
Rick Reumann wrote:
How does a developer working on your
code know how to even get the properties out of your Map? I guess he
has to look at some API contract saying put date of birth in the Map
as "dob" not "dateOfBirth."
As in iBatis, name of the map property is in my case the field name in
the table, and I do not have to map it, it compes that way.
But my point is users using your API, how do they know what they are
getting back? They have to look at a database model in order to figure
out how to get back a dateOfBirth field? That's crazy imo. Someone is
coding and they call List employees = mapHappyVic.getEmpoyees(); Now
they want to iterate over this list and display some properties. Tell me
how they figure out what the fields are to pull from the Map? Using
regular POJOS and an IDE or even the java docs (for the vi users:)
they'll be able to figure out what to call, for your List of Maps of
employees they'll have to look up the database model.
Some people don't get dynamic langs yet... just like some people took a
long time to get OO. It's much less code.
Come on! what kind of comparison is that - comparing the use of Maps to
coming around to understanding OO? Anyway, use your Maps, I'm not saying
they are a poor choice in all cases, but I think it's an unwise decision
in most cases for model layer objects. I'm just glad I don't have to
work on projects where I have to go to the datamodel to figure out the
names of my properties to use as a key in order to get out a property
from a Map. Not only that, you have no type safety plus think of all the
stupid time wasted debugging because using that approach you'll no
compile time checks. I can type employee.getDOB() if it's
employee.getDateOfBirth, but you certainly won't have a compilation
problem with employee.get("DOB") Also, think of the potential for bugs
to not creep up until odd times... what if you had...
if ( someCondition ) {
Integer age = (Integer)employee.get("DOB");
//other stuff
}
if DOB should be dateOfBirth you might not even find about the error
until "somceCondition" is met. On top of that, look at the other
situation, math operations How does the developer know what "type"
was used for the value? I can look at a bean and see...
Double price; but I have not idea what type of value
shippingOrder.get("price") is. The developer just has to guess or where
does he look? The datamodel? Some other docs? Pain in the butt if you
ask me. I swear using Maps will cost a lot of time in the long run. Sure
if only one person has to deal with the code, it 'might' be faster since
he might simply remember all the types etc, but what happens when the
code is inherited? Pity on that developer.
--
Rick
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using struts forms as Value Objects: your opinion?
It's ironic to me that I had this same discussion with someone at work just last week :) I *was* in the "Maps are better" camp until a few months back when I changed my mind, and it comes down to one thing: Self-documenting code is better. A bean is self-documenting in that you can immediately tell what its attributes are and what types they are. I'm not even talking about generating javadoc from the source either, but that's certainly a very nice by-product. Developers HATE documenting. I'm sure there are exceptions, but by and large that is a very fair generalization in my experience. If you trust a developer to document what is going into a Map, your asking for trouble, generally-speaking. I don't personally use an IDE, but I think Rick's point about auto-completion and the like is important because many people *DO* use IDEs, and if you give them a bean they can be more effective faster than if you give them a map with some documentation on what they may find in it at various points in time, and that's even assuming the documentation is accurate :) Especially in a team environment, I would always go with a real bean now over a Map-based design, even though I agree with may of the points made on why Maps are good. But in this world of trade-offs, I think you gain more by using a bean than you do by using a Map, again, generally-speaking. Frank netsql wrote: Larry Meadors wrote: Hmm, of course, who needs things like refactoring, and compile time name and type checking? That's why you have users, eh? They'll find the bugs eventually. ;-) Larry Get/Set, Get/Set Half the time I have no idea what the db date will come back as. Look, I think some of you will belive me that I know well the benefits of beans and that I have done at least several deployed projects w/ beans. It was a best aproach for the time. Now I have an alternative. It does not change jUnit testing in anyway, I fire a populate/CRUDs and assert. So using maps does not make me insane. :-P Compile time type checking? Like in dynamic langs? Most of the sucessfull p-langs are dynamic. In flash, array and map are same class even. I envy their sucess. For example, the home page of Spring is done in Plone. So I just duplicate their aproach to get their Cost of Operation. .V - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using struts forms as Value Objects: your opinion?
Larry Meadors wrote: Hmm, of course, who needs things like refactoring, and compile time name and type checking? That's why you have users, eh? They'll find the bugs eventually. ;-) Larry Get/Set, Get/Set Half the time I have no idea what the db date will come back as. Look, I think some of you will belive me that I know well the benefits of beans and that I have done at least several deployed projects w/ beans. It was a best aproach for the time. Now I have an alternative. It does not change jUnit testing in anyway, I fire a populate/CRUDs and assert. So using maps does not make me insane. :-P Compile time type checking? Like in dynamic langs? Most of the sucessfull p-langs are dynamic. In flash, array and map are same class even. I envy their sucess. For example, the home page of Spring is done in Plone. So I just duplicate their aproach to get their Cost of Operation. .V - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using struts forms as Value Objects: your opinion?
Rick Reumann wrote: How does a developer working on your code know how to even get the properties out of your Map? I guess he has to look at some API contract saying put date of birth in the Map as "dob" not "dateOfBirth." As in iBatis, name of the map property is in my case the field name in the table, and I do not have to map it, it compes that way. Think how rarely you get class cast exceptions! Very rare. Forget you CS 101. > In my IDE I can get dot completion to work easily but that's not gonig to work with your Map approach. If I need firstName from employee I can just do employee(dot)=[pop up of methods]... you're going to get .. employee. [ get, put, etc Map methods !] I have been using Flash, CoR and Groovy and got used to the dynamic nature and maps (CoR Context is a map too, I use it as a sort of a vararg). Also, w/ XML. Imagine a XML used for SoA you knid of have to know what you are getting so you can show a jTable. I just have a XML DAO (ibatis) and a model that only has a populate/crud methods, no gets/sets. On a large project, the fact that there are thousands of classes not in a project is a huge maitanace improvment. Anytime my developer would think bean use a map instead. See post by Jeff Butler on "Map over Bean" in iBatis list. Before that multiple developers develop a similar "CutomerBean" and as the front end or back end would change, they had CRUFT geters/setters. (on 1up.com project) With a Map... there are 0 such clases. Some people don't get dynamic langs yet... just like some people took a long time to get OO. It's much less code. You can use validator w/ map, DynaMaps... It's diferent. Anywho... that what my team does on this JDNC project. .V ps/ot: Did you say IDE dot completion? ;-) I don't need no stinking badges. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using struts forms as Value Objects: your opinion?
Hmm, of course, who needs things like refactoring, and compile time name and type checking? That's why you have users, eh? They'll find the bugs eventually. ;-) Larry On 7/11/05, netsql <[EMAIL PROTECTED]> wrote: > of course... I use Collections (Maps and Lists) as VO/DTO. > You can wrap them w/ DynaMaps, you can validate a map, you don't have to > maintain deprecated gets/sets, it reduces duplication... your dao > can return a map/collection/list... > > I think it vastly simplifies to use Maps in places where I used to use > beans. (I even got rid of baseBeans domain how much I loved maps) > > .V > > > - > 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]
Re: Using struts forms as Value Objects: your opinion?
netsql wrote the following on 7/11/2005 2:15 PM:
I think it vastly simplifies to use Maps in places where I used to use
beans. (I even got rid of baseBeans domain how much I loved maps)
Vic I think you sleep with the Map API under your pillow at night or use
it as a Teddy Bear when you sleep:)
I agree Maps will work fine for rapid development, but I like the type
safety of using typed properties in my VOs.
Just as an example, I know we both use iBATIS, under your Map idea, you
could end up with the crap out occuring at the DB level whereas if you
use a typed POJO you'll find the error much sooner. What if in your
scenario you pass in some mangled up String represntation of a Date as
your value in your map and the backend then needs to process that as
Date in the DB? You'll end up with a DB exception. Using normally typed
POJOs you won't have this problem since you'll catch it much sooner when
trying to do the conversion of your String to Date.
The other aspect is just the pure functionality of using a typed VO vs a
Map. For example if you are using a Map to represent an Employee how do
you know what to name the keys? Someone can put in map.put("firstName",
name ).. someone else might put map.put("fName", name ) ? even using
Constants is messy (map.put(Constants.NAME, name).. granted that's
better but now you have to maintain a constants class as well as you Map
in place of a standard POJO?
How do you deal with these issues? How does a developer working on your
code know how to even get the properties out of your Map? I guess he has
to look at some API contract saying put date of birth in the Map as
"dob" not "dateOfBirth." Also, the rapid development using Maps will
sure end up being a drawback when you end up having to work with the
Maps. In my IDE I can get dot completion to work easily but that's not
gonig to work with your Map approach. If I need firstName from employee
I can just do employee(dot)=[pop up of methods]... you're going to get
.. employee. [ get, put, etc Map methods !]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using struts forms as Value Objects: your opinion?
of course... I use Collections (Maps and Lists) as VO/DTO. You can wrap them w/ DynaMaps, you can validate a map, you don't have to maintain deprecated gets/sets, it reduces duplication... your dao can return a map/collection/list... I think it vastly simplifies to use Maps in places where I used to use beans. (I even got rid of baseBeans domain how much I loved maps) .V - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using struts forms as Value Objects: your opinion?
Borislav Sabev wrote the following on 7/11/2005 1:37 PM: In case of the Integer there is pre-load default value and EVEN if conversion fails during the population phase, it just use is the dafault value (and you think it's parsed correctly). In the previous example its a coincidence that Rivka have 0 as default value (it's just the same value as init value of IntegerConverter). Bingo:) Sorry saw this thread late and could have helped out much sooner. This is a HUGE problem with BeanUtils and why I end up having to register custom converters:( BeanUtils (at least it always has done this, maybe in a recent version it's hopefully changed?), will end up converting null values to 0!! Stupid, stupid if you ask me (null means null not 0!) Goes the same for the other numeric wrappers as well. (I think their argument was for backwards compatibility with apps that expect that behavior). In regard to you point... The strange point is that I didn't find how can I set a default date value ... if someone knows it, please share this knowledge here. You shouldn't want a "default" at all provided by BeanUtils for cases where it can be null! You are using the anomoly of the way Integer is working and wanting to propogate that poor solution. null should be null.. it shouldn't be 0 or some default Date if null is provided. If you want a default Date or some other default than provide that before going to your form...or if after it submits and you see a null, then provide the default. You could of course register your own converter to provide a default for when a Date is null- but I would NOT do this. Actually, in regards to a Date, in case you didn't already realize, you'll have to provide your own converter anyway if you plan to use java.util.Date since BeanUtils doesn't provide that by default.. it only provides conversion for java.sql.Date. If you need help with the converters I can post some code or search the struts archives for "java.util.Date converter" -- Rick - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using struts forms as Value Objects: your opinion?
Nitish Kumar wrote:
I think raghavendra is right.
Rivka, your code is working because you are using primitive type int and not
the wrapper type Integer.
In case of primitive type in case of any exception, it gives you a default
value.
Thanks and Regards,
Nitish Kumar
So after small debugging session I found why it works for Integers and
not for dates (at least in my case)
all classes that implment Convertors interface in BeanUtils, have
something like this as implementation of convert() method:
public Object convert(Class type, Object value) {
if (value == null) {
if (useDefault) {
return (defaultValue);
} else {
throw new ConversionException("No value specified");
}
}
if (value instanceof Date) {
return (value);
}
try {
return (Date.valueOf(value.toString()));
} catch (Exception e) {
if (useDefault) {
return (defaultValue);
} else {
throw new ConversionException(e);
}
}
}
In case of the Integer there is pre-load default value and EVEN if
conversion fails during the population phase, it just use is the dafault
value (and you think it's parsed correctly). In the previous example its
a coincidence that Rivka have 0 as default value (it's just the same
value as init value of IntegerConverter).
The strange point is that I didn't find how can I set a default date
value ... if someone knows it, please share this knowledge here.
For sure this is not a big discovery, but I spent a lot of hours to
udnerstand it and I though that this should be described somewhere at
some public place ... that's why I was a bit bitter in my previuos posts
Regards
Borislav
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using struts forms as Value Objects: your opinion?
On 7/11/05, Michael Jouravlev <[EMAIL PROTECTED]> wrote: > JSF still differentiates "real" object (whatever it might be, a real > business object or a VO) from visual component data, which I don't > like. From my point of view, it is much easier to have an object with > an ID, to view/edit it, or to delete it. Therefore, I do not need > viewstate for UI components. I only need to store my object somewhere > like in session while I work with it. I want my widgets and my view to > be as dumb as possible. All data and state that I need is in real > objects, I do not need artificial viewstate to duplicate it. Before anyone corrects me, I want to say that I went a little overboard ;) There are selection lists, treeviews and other objects which do not have direct representation in the domain model. These objects should be maintained by web framework. I was talking primarily about input/output panels and about item lists. Well, item list may be also considered as pure view object, consisting of business objects... Whatever. In this case I was talking about input/output panels only ;-) Michael. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using struts forms as Value Objects: your opinion?
There's probably something to that, Leon. Of course, there's nothing new here, except maybe the metaphor. Using the layers pattern in enteprise applications is well known. I believe Bushman describes it in POSA. Here's another online treatment: * http://www.stevenblack.com/PTN-Layers.asp -Ted. On 7/11/05, Leon Rosenberg <[EMAIL PROTECTED]> wrote: > Some time ago I tried to postulate an enterprise application as a > row of mvc patterns each using the previous one as the model, and everyone > laughed at me :-) > > Now this is the same, with a nicer metaphor :-) > > Leon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using struts forms as Value Objects: your opinion?
On 7/7/05, Laurie Harper <[EMAIL PROTECTED]> wrote: > Personally I prefer to keep form beans and value objects seperate, for two > key reasons: > > 1) form beans generally should consist of String data to facilitate > round-tripping of invalid inputs. I like to constrain them to a clearly > defined role of marshaling data 'into' and 'out of' the presentation layer, > i.e. across the boundary between presentation and application. Is not it easier to have one nested VO/BO with string properties, than to copy properties back and forth from action form to VO? I use web framework only to expose my real objects to the outer world. > 2) value objects should use typed interfaces to ensure marshaling to and > from presentation format (string types) is pushed as far up the application > stack as possible. This also enables other, potentially type-aware, > presentation / client tiers to be built on top of the same value objects > (e.g. for a web-services interface). I think I do not agree with this one. Let's take it as a design requirement that application that we build is a webapp. It potentially can have different interfaces. This would mean, that: * input data is stingified because of HTTP * Struts is not the only front end Therefore, it is much easier to create BO/VO with dual string/typed interface or with string interface only. It would do validation and conversion to native datatype internally instead of doing it in validate() method. I believen that this is more flexible approach. What are you going to do with your validation code, if you are told to move from Struts to WebWork or Tapestry? On 7/8/05, Craig McClanahan <[EMAIL PROTECTED]> wrote: > Form beans are part of the *view* tier, not the model ... their > purpose in life is to represent the server side state of the HTML > elements on a form, even if that state is invalid (i.e. not currently > passing all the validations). That way, you can reproduce what the > user typed so he or she can fix it, rather than presenting them with a > completely blank screen. (This is why you generally use string fields > in a form bean). This is one way to look at things. Another way is to use VO/BO for input/output directly. When I use existing data, I load it into BO and display it. When I modify it, I update BO using its string properties. If I decide to cancel updates, I siply remove the BO from memory, no database changes needed. If I create a new object, I create a new BO and fill it in. Until I persist it, it hangs in the session. If I decide to cancel, then I remove it, and database would not even know that I was about to insert an object. > In a component oriented framework like JSF or Tapestry, you don't need > to worry about keeping track of this state information ... the > components do it for you. JSF still differentiates "real" object (whatever it might be, a real business object or a VO) from visual component data, which I don't like. From my point of view, it is much easier to have an object with an ID, to view/edit it, or to delete it. Therefore, I do not need viewstate for UI components. I only need to store my object somewhere like in session while I work with it. I want my widgets and my view to be as dumb as possible. All data and state that I need is in real objects, I do not need artificial viewstate to duplicate it. I can understand why JSF or ASP.NET went this route with UI objects and viewstate: to abstract from the model/business layer. They do not want to establish a firm contract with business/persistence layer. They do not want to require a certain BO lifecycle or the datatype limitations. But I as a developer find this inconvenient. Web frameworks designers focus on their framework, while I as an application designer, focus on business data, business process and business state. Take ActiveX. There is a contract, there are interfaces, methods and datatypes defined. Just build an object according to the protocol, and you will be able to have design-time interface, runtime interface, everything. Web frameworks do not want to have strict contracts with data layer probabaly to be more flexible. I would take contract over flexibily anytime. Presuming that this is a flexible contract ;-) Michael. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using struts forms as Value Objects: your opinion?
Some time ago I tried to postulate an enterprise application as a row of mvc patterns each using the previous one as the model, and everyone laughed at me :-) Now this is the same, with a nicer metaphor :-) Leon > -Ursprüngliche Nachricht- > Von: news [mailto:[EMAIL PROTECTED] Im Auftrag von Laurie Harper > Gesendet: Montag, 11. Juli 2005 18:31 > An: user@struts.apache.org > Betreff: Re: Using struts forms as Value Objects: your opinion? > > Ted Husted wrote: > > In my own work, I tend to think of an enterprise-grade > application as > > a set of overlapping rings, like the Olympics logo. > > > > * http://www.olympic.org/ > > > > In the Blue ring... > > Nice analogy! :-) > > -- > Laurie, Open Source advocate, Java geek and novice blogger: > http://www.holoweb.net/~laurie/ > > > - > 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]
Re: Using struts forms as Value Objects: your opinion?
Some time ago I tried to postulate an enterprise application as a row of mvc patterns each using the previous one as the model, and everyone laughed at me :-) Now this is the same, with a nicer metaphor :-) Leon > -Ursprüngliche Nachricht- > Von: news [mailto:[EMAIL PROTECTED] Im Auftrag von Laurie Harper > Gesendet: Montag, 11. Juli 2005 18:31 > An: user@struts.apache.org > Betreff: Re: Using struts forms as Value Objects: your opinion? > > Ted Husted wrote: > > In my own work, I tend to think of an enterprise-grade > application as > > a set of overlapping rings, like the Olympics logo. > > > > * http://www.olympic.org/ > > > > In the Blue ring... > > Nice analogy! :-) > > -- > Laurie, Open Source advocate, Java geek and novice blogger: > http://www.holoweb.net/~laurie/ > > > - > 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]
Re: Using struts forms as Value Objects: your opinion?
Ted Husted wrote: In my own work, I tend to think of an enterprise-grade application as a set of overlapping rings, like the Olympics logo. * http://www.olympic.org/ In the Blue ring... Nice analogy! :-) -- Laurie, Open Source advocate, Java geek and novice blogger: http://www.holoweb.net/~laurie/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using struts forms as Value Objects: your opinion?
Nitish Kumar wrote: I think raghavendra is right. Rivka, your code is working because you are using primitive type int and not the wrapper type Integer. In case of primitive type in case of any exception, it gives you a default value. Thanks and Regards, Nitish Kumar I don't think because it's int and not Integer - even with Integer it's the same, because the "problem" is in BeanUtils, not in struts exactly. I hope today or tommorow I'll have a bit more time to investigate it ... borislav - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using struts forms as Value Objects: your opinion?
On 7/8/05, Craig McClanahan <[EMAIL PROTECTED]> wrote: > +1 as well, and this matches the historical reason that form beans > were invented in the first place. > > Form beans are part of the *view* tier, not the model ... their > purpose in life is to represent the server side state of the HTML > elements on a form, even if that state is invalid (i.e. not currently > passing all the validations). That way, you can reproduce what the > user typed so he or she can fix it, rather than presenting them with a > completely blank screen. (This is why you generally use string fields > in a form bean). > > In a component oriented framework like JSF or Tapestry, you don't need > to worry about keeping track of this state information ... the > components do it for you. But in Struts it is the application > developer's responsibility to understand the correct design patterns > -- and this is one of the most fundamental principles of how Struts > was designed. Yes, compared to component-based frameworks, one feature ActionForms provide is to act as an input buffer. Component controls have a built-in string field, but since the Struts tags are not designed as components, we need the ActionForms to provide the missing buffer. Of course, ActionForms also provide for input validation, so they are also more than a simple component buffer. One of the things that confuse people about ActionForms is that they have a complex life cycle, and serve different roles at different times. Of course, there are many ways to reduce the ActionForm maintenance burden. One strategy is to use a coarsely-grained ActionForm that represents several (or all) of the input fields in your application, and then subclass the base form to provide for different validations (if needed). Another technique is to use a flavor of DynaActionForm. In my own work, I tend to think of an enterprise-grade application as a set of overlapping rings, like the Olympics logo. * http://www.olympic.org/ In the Blue ring live the view members, like custom tags or UI components, and the HTTP request and response objects. This is the layer where our appliction interacts with the rest of the world. Some of the Blue ring members also interact with the presentation controller components that live in the Gold ring, like the Struts Actions, ActionForms, and JSF backing beans. This is the layer that "interprets user gestures" to decide which view to display next, and may also convert or format data as needed. In turn, Gold ring components interact with your own business objects, which live in the Black ring. The business compnents could also be chains of commands, representing services, rather than conventional object representing domain entities. This layer often acts as a "liaison" between the view-centric Blue and Gold rings, and the data-centric Green and Red rings. To be useful, most business objects need to access persistent data. Rather than talk to the native database API, most of us use data access objects, that live in the Green ring. Here we find components like iBATIS or Hibernate, JDO, or just plain JDBC. This layer links specific business methods to general-purpose persistence methods. Finally, in the Red ring, we find our dragon -- the physical database. In some applications, the database is a deep crimson that represents our solution to the domain's problems. Other times, the domain logic lives in the black ring, and the red ring is a pale pink shoebox. In some applications, the rings are separated by framework or package lines, like Struts and iBATIS. In other applications, the rings may exist as separate classes in the same package, or even different methods on the same class. But, eventually, in my experience, any long-lived, well-factored application will find itself using all five rings, or all five separations of concern, in one way or the other. Of course, in a conventional MVC application, the Black and Blue rings intersect, forming a triad, and the Green and Red rings are not described. Though, I expect, the other rings did still exist, but were simply hidden behind the event horizon of MVC's Black ring. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Using struts forms as Value Objects: your opinion?
I think raghavendra is right.
Rivka, your code is working because you are using primitive type int and not
the wrapper type Integer.
In case of primitive type in case of any exception, it gives you a default
value.
Thanks and Regards,
Nitish Kumar
-Original Message-
From: Rivka Shisman [mailto:[EMAIL PROTECTED]
Sent: Monday, July 11, 2005 5:13 PM
To: Struts Users Mailing List
Subject: RE: Using struts forms as Value Objects: your opinion?
Hi Borislav
I did the test and it works fine -
In my form I have:
private int question_no;
public void setQuestion_no(int i) {
this.question_no = i;
}
public int getQuestion_no() {
return question_no;
}
public ActionErrors validate(ActionMapping mapping,
HttpServletRequest request) {
ActionErrors errors = new ActionErrors();
if (action.equals("create")){
if (question_no <= 0) {
errors.add("question_no", new
ActionMessage("error.field.positive_num","מספר שאלה"));
}
}
}
I don’t have anything regarding this field in struts-config (should i?)
When I insert "abc" in the html:text field that is related to that integer
property - I get the error message I expected to get - " the value in
question_no field must be positive"
-Original Message-
From: Borislav Sabev [mailto:[EMAIL PROTECTED]
Sent: Monday, July 11, 2005 11:27 AM
To: Struts Users Mailing List
Subject: Re: Using struts forms as Value Objects: your opinion?
Rivka Shisman wrote:
>Hi again
>
>When you say that validation doesn't work when inserting "ABC" in an
>integer field - do you mean when using struts Validator?
>I'm not using the Validator - I just add "if myInteger < 1 " in method
>validate().
>
>If I define myInteger as String - how do I check that it's a valid
>number in the validate() method (without using Validator)?
>
>
>
Doesn't matter if you use validation or not, if you define a form
property as Integer for example (in the form class and in struts-config)
and then if you write "abc" in this field, you will get a
ConversionException because the first step that Struts makes in the
RequestProcesor is to "populate" the form bean i.e. to match the
parameters that are comming with the request and "transform" them to the
form proiperties.
After that the validation works, but even if you don't validate the
forms with the Validator, the populations you can't avoid or change.
Thus you are forced to define your form properties as String (because in
the http request anyway they ARE strings, just Struts during the
population tries to convert them to the types defined in struts-config).
Just make a little test and you will udnerstand the problem ...
Borislav
**
The contents of this email and any attachments are confidential.
They are intended for the named recipient(s) only.
If you have received this email in error please notify the system manager or
the
sender immediately and do not disclose the contents to anyone or make
copies.
** eSafe scanned this email for viruses, vandals and malicious content. **
**
-
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]
Re: Using struts forms as Value Objects: your opinion?
Rivka Shisman wrote:
Hi Borislav
I did the test and it works fine -
In my form I have:
private int question_no;
public void setQuestion_no(int i) {
this.question_no = i;
}
public int getQuestion_no() {
return question_no;
}
public ActionErrors validate(ActionMapping mapping,
HttpServletRequest request) {
ActionErrors errors = new ActionErrors();
if (action.equals("create")){
if (question_no <= 0) {
errors.add("question_no", new
ActionMessage("error.field.positive_num","מספר שאלה"));
}
}
}
I don’t have anything regarding this field in struts-config (should i?)
When I insert "abc" in the html:text field that is related to that integer property - I
get the error message I expected to get - " the value in question_no field must be
positive"
Hm, interesting, I didn't try to leave the struts-config empty. The key
is in the source code of struts ... I'll debug it a bit ... because such
behaviour for me is a bit strange ...
--
Mit freundlichen Grüßen
Borislav Sabev
eventsoft GmbH
Max-Planck-Str. 3
85716 Unterschleißheim
Tel: 089 - 35 89 03 21
Fax: 089 - 35 89 03 70
[EMAIL PROTECTED]
www.eventsoft.de
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Using struts forms as Value Objects: your opinion?
Hi Borislav
I did the test and it works fine -
In my form I have:
private int question_no;
public void setQuestion_no(int i) {
this.question_no = i;
}
public int getQuestion_no() {
return question_no;
}
public ActionErrors validate(ActionMapping mapping,
HttpServletRequest request) {
ActionErrors errors = new ActionErrors();
if (action.equals("create")){
if (question_no <= 0) {
errors.add("question_no", new
ActionMessage("error.field.positive_num","מספר שאלה"));
}
}
}
I don’t have anything regarding this field in struts-config (should i?)
When I insert "abc" in the html:text field that is related to that integer
property - I get the error message I expected to get - " the value in
question_no field must be positive"
-Original Message-
From: Borislav Sabev [mailto:[EMAIL PROTECTED]
Sent: Monday, July 11, 2005 11:27 AM
To: Struts Users Mailing List
Subject: Re: Using struts forms as Value Objects: your opinion?
Rivka Shisman wrote:
>Hi again
>
>When you say that validation doesn't work when inserting "ABC" in an
>integer field - do you mean when using struts Validator?
>I'm not using the Validator - I just add "if myInteger < 1 " in method
>validate().
>
>If I define myInteger as String - how do I check that it's a valid
>number in the validate() method (without using Validator)?
>
>
>
Doesn't matter if you use validation or not, if you define a form
property as Integer for example (in the form class and in struts-config)
and then if you write "abc" in this field, you will get a
ConversionException because the first step that Struts makes in the
RequestProcesor is to "populate" the form bean i.e. to match the
parameters that are comming with the request and "transform" them to the
form proiperties.
After that the validation works, but even if you don't validate the
forms with the Validator, the populations you can't avoid or change.
Thus you are forced to define your form properties as String (because in
the http request anyway they ARE strings, just Struts during the
population tries to convert them to the types defined in struts-config).
Just make a little test and you will udnerstand the problem ...
Borislav
**
The contents of this email and any attachments are confidential.
They are intended for the named recipient(s) only.
If you have received this email in error please notify the system manager or
the
sender immediately and do not disclose the contents to anyone or make copies.
** eSafe scanned this email for viruses, vandals and malicious content. **
**
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Using struts forms as Value Objects: your opinion?
HI
If u can use struts Validator or not here this is not matter.
In Struts all in put text values takes Strings only. At the time of
populating Action Form use the class org.apache.struts.util.RequestUtils
class.
In Struts all input values are String type, see the following code how
to assign int variables.
int int_test;
this is u r declared integer variable in form so this is class level
variable is default value 0 at the time of running app in text field 0
will be displays.
Out put:
in case u enter 'ABC' this field Struts populate like this
names = request.getParameterNames();
try{
while (names.hasMoreElements()) {
String name = (String) names.nextElement();
.
.
.
}
}catch(Exc e){
}
in case any Exception raised it d't assign input value so the default
value int_test=0 as it is
- I just add "if myInteger < 1 " in method
validate().
Ok its works fine
If I define myInteger as String - how do I check that it's a valid
number in the validate() method (without using Validator)?
Private void setMyInteger(String s){
Try{
This.Int_test_my_validation=Integer.parseInt(s);
}catch(NumberFormatException nfe){
}
in case int declared form
Private void setInt_test(int i){
This.int_test=i; //if input value is 'ABC' int_test=0 assigned
}
U no need wary about that validation that is done automatically Struts
in case u declared as int.
Regards
Raghavendra.E
--
Programmer Analyst
-Original Message-
From: Rivka Shisman [mailto:[EMAIL PROTECTED]
Sent: Monday, July 11, 2005 3:36 PM
To: Struts Users Mailing List
Subject: RE: Using struts forms as Value Objects: your opinion?
Hi again
When you say that validation doesn't work when inserting "ABC" in an
integer field - do you mean when using struts Validator?
I'm not using the Validator - I just add "if myInteger < 1 " in method
validate().
If I define myInteger as String - how do I check that it's a valid
number in the validate() method (without using Validator)?
Thanks
Rivka
**
The contents of this email and any attachments are confidential.
They are intended for the named recipient(s) only.
If you have received this email in error please notify the system
manager or the
sender immediately and do not disclose the contents to anyone or make
copies.
** eSafe scanned this email for viruses, vandals and malicious content.
**
**
-
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]
RE: Using struts forms as Value Objects: your opinion?
Hi again When you say that validation doesn't work when inserting "ABC" in an integer field - do you mean when using struts Validator? I'm not using the Validator - I just add "if myInteger < 1 " in method validate(). If I define myInteger as String - how do I check that it's a valid number in the validate() method (without using Validator)? Thanks Rivka ** The contents of this email and any attachments are confidential. They are intended for the named recipient(s) only. If you have received this email in error please notify the system manager or the sender immediately and do not disclose the contents to anyone or make copies. ** eSafe scanned this email for viruses, vandals and malicious content. ** ** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using struts forms as Value Objects: your opinion?
Rivka Shisman wrote: Hi again When you say that validation doesn't work when inserting "ABC" in an integer field - do you mean when using struts Validator? I'm not using the Validator - I just add "if myInteger < 1 " in method validate(). If I define myInteger as String - how do I check that it's a valid number in the validate() method (without using Validator)? Doesn't matter if you use validation or not, if you define a form property as Integer for example (in the form class and in struts-config) and then if you write "abc" in this field, you will get a ConversionException because the first step that Struts makes in the RequestProcesor is to "populate" the form bean i.e. to match the parameters that are comming with the request and "transform" them to the form proiperties. After that the validation works, but even if you don't validate the forms with the Validator, the populations you can't avoid or change. Thus you are forced to define your form properties as String (because in the http request anyway they ARE strings, just Struts during the population tries to convert them to the types defined in struts-config). Just make a little test and you will udnerstand the problem ... Borislav - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Using struts forms as Value Objects: your opinion?
Hi again When you say that validation doesn't work when inserting "ABC" in an integer field - do you mean when using struts Validator? I'm not using the Validator - I just add "if myInteger < 1 " in method validate(). If I define myInteger as String - how do I check that it's a valid number in the validate() method (without using Validator)? Thanks Rivka ** The contents of this email and any attachments are confidential. They are intended for the named recipient(s) only. If you have received this email in error please notify the system manager or the sender immediately and do not disclose the contents to anyone or make copies. ** eSafe scanned this email for viruses, vandals and malicious content. ** ** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using struts forms as Value Objects: your opinion?
Rivka Shisman wrote: Hi Erik You said - " My form class fields are always Strings (because of HTTP)" - I'm not sure I anderstand the meaning of this - why do the fields are Strings? I have recently started working with struts and my forms contain int, short, boolean and so on, and it works fine. Is there a problem with that? Did you try to put a string (for example "afkjsdhfk") in the form fields that have to accept only numbers or dates for example? Try and then you'll understand where is the problem. The conversion nor valdation works if you use other types than String in the forms. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using struts forms as Value Objects: your opinion?
From: "Rivka Shisman" <[EMAIL PROTECTED]> I have recently started working with struts and my forms contain int, short, boolean and so on, and it works fine. So far... but what happens when you display a text field asking for an integer, and your user types 'ABC'? It may not be a problem in your app, for example if all your input fields are select lists, checkboxes and drop-downs. (Though someone could always construct a URL manually, or modify a local copy of the form and submit it.) -- Wendy Smoak - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Using struts forms as Value Objects: your opinion?
Hi Erik You said - " My form class fields are always Strings (because of HTTP)" - I'm not sure I anderstand the meaning of this - why do the fields are Strings? I have recently started working with struts and my forms contain int, short, boolean and so on, and it works fine. Is there a problem with that? Rivka -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Friday, July 08, 2005 1:33 AM To: Struts Users Mailing List Subject: Re: Using struts forms as Value Objects: your opinion? An alternative would be to have your form class extend your value object class. However, this approach doesn't work for me. My form class fields are always Strings (because of HTTP), while my value object fields are whatever types make sense (such as Date). I always have value object classes that look very similar to my forms, but the types vary. It doesn't bother me. Check out Jakarta BeanUtils for auto-conversion of field data between form class and value object class. Erik -Original Message- From: Vincent <[EMAIL PROTECTED]> Sent: Jul 7, 2005 7:15 PM To: user@struts.apache.org Subject: Using struts forms as Value Objects: your opinion? Hi, I'm currently designing and developping an enterprise J2EE application based on Struts. In this application there's a layer of Data Access Object which abstract the underlying persistent storage. For populating my struts' *Form I've imagined first a transfert between forms and DAO based on Value Object, associated with helper classes for translating from one type to another. And I realized that struts Form can be in some situations quite good transfert objects, and by doing so we economize development of both helper classes and VO classes. What do you thing about using forms as VO? Do you think it's a dirty solution? Forms are often mirrors of the database's table. Thank you for your opinion. Vincent. - 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] ** The contents of this email and any attachments are confidential. They are intended for the named recipient(s) only. If you have received this email in error please notify the system manager or the sender immediately and do not disclose the contents to anyone or make copies. ** eSafe scanned this email for viruses, vandals and malicious content. ** ** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using struts forms as Value Objects: your opinion?
On 7/7/05, Laurie Harper <[EMAIL PROTECTED]> wrote: > Vincent wrote: > > > > What do you thing about using forms as VO? Do you think it's a dirty > > solution? Forms are often mirrors of the database's table. > > Personally I prefer to keep form beans and value objects seperate, for two > key reasons: > +1 as well, and this matches the historical reason that form beans were invented in the first place. Form beans are part of the *view* tier, not the model ... their purpose in life is to represent the server side state of the HTML elements on a form, even if that state is invalid (i.e. not currently passing all the validations). That way, you can reproduce what the user typed so he or she can fix it, rather than presenting them with a completely blank screen. (This is why you generally use string fields in a form bean). In a component oriented framework like JSF or Tapestry, you don't need to worry about keeping track of this state information ... the components do it for you. But in Struts it is the application developer's responsibility to understand the correct design patterns -- and this is one of the most fundamental principles of how Struts was designed. Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using struts forms as Value Objects: your opinion?
Well put. To expand on #2, it's good to confine dependencies on the org.apache.struts packages to the presentation layer, and not build a Struts dependency into business logic. Personally I prefer to keep form beans and value objects seperate, for two key reasons: 1) form beans generally should consist of String data to facilitate round-tripping of invalid inputs. I like to constrain them to a clearly defined role of marshaling data 'into' and 'out of' the presentation layer, i.e. across the boundary between presentation and application. 2) value objects should use typed interfaces to ensure marshaling to and from presentation format (string types) is pushed as far up the application stack as possible. This also enables other, potentially type-aware, presentation / client tiers to be built on top of the same value objects (e.g. for a web-services interface). -- Bill Schneider Chief Architect Vecna Technologies 5004 Lehigh Rd. College Park, MD 20740 [EMAIL PROTECTED] t: 301-864-7253 x1140 f: 301-699-3180 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using struts forms as Value Objects: your opinion?
On 7/8/05, Laurie Harper <[EMAIL PROTECTED]> wrote: > Personally I prefer to keep form beans and value objects seperate, for two > key reasons: +1 == me too. -T. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Using struts forms as Value Objects: your opinion?
> 1) form beans generally should consist of String data to facilitate > round-tripping of invalid inputs. I like to constrain them to a clearly > defined role of marshaling data 'into' and 'out of' the > presentation layer, > i.e. across the boundary between presentation and application. This i would agree with. Fields in BO/VOs have various types. ActionForms should only get/set strings. > > 2) value objects should use typed interfaces to ensure marshaling to and > from presentation format (string types) is pushed as far up the > application > stack as possible. This also enables other, potentially type-aware, > presentation / client tiers to be built on top of the same value objects > (e.g. for a web-services interface). > > To address Micheal's question (why not just make value objects > and business > objects the same thing?), I'd point out that it can be valuable to > distinguish between business rules and application logic. I find my > business objects often have functionality I don't want called > directly from > the presentatin layer, particularly when using a mediation layer between > the two. > > Essentially, though, it comes down to the complexity of the > problem vs. the > complexity of the solution. The more complex the application, the more it > makes sense to partition responsibilities. For very simple > applications it > makes sense to collapse layers together. I tend to merge BO,VO,and DAO all into one bean. I made a self-persistable base bean (using OJB), and then just add fields with getters/setters. All works nicely. Add any simple logic into the beans. Stick complex logic in managers/helpers/services. I tend to pass these beans straight up to jsps for pure displaying of stuff, but then use actionforms to edit/submit data. A big timesaver can be to write a constructor for an action form that accepts a BO and fills itself from that. Daniel. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using struts forms as Value Objects: your opinion?
Vincent wrote: I'm currently designing and developping an enterprise J2EE application based on Struts. In this application there's a layer of Data Access Object which abstract the underlying persistent storage. For populating my struts' *Form I've imagined first a transfert between forms and DAO based on Value Object, associated with helper classes for translating from one type to another. And I realized that struts Form can be in some situations quite good transfert objects, and by doing so we economize development of both helper classes and VO classes. What do you thing about using forms as VO? Do you think it's a dirty solution? Forms are often mirrors of the database's table. Personally I prefer to keep form beans and value objects seperate, for two key reasons: 1) form beans generally should consist of String data to facilitate round-tripping of invalid inputs. I like to constrain them to a clearly defined role of marshaling data 'into' and 'out of' the presentation layer, i.e. across the boundary between presentation and application. 2) value objects should use typed interfaces to ensure marshaling to and from presentation format (string types) is pushed as far up the application stack as possible. This also enables other, potentially type-aware, presentation / client tiers to be built on top of the same value objects (e.g. for a web-services interface). To address Micheal's question (why not just make value objects and business objects the same thing?), I'd point out that it can be valuable to distinguish between business rules and application logic. I find my business objects often have functionality I don't want called directly from the presentatin layer, particularly when using a mediation layer between the two. Essentially, though, it comes down to the complexity of the problem vs. the complexity of the solution. The more complex the application, the more it makes sense to partition responsibilities. For very simple applications it makes sense to collapse layers together. L. -- Laurie, Open Source advocate, Java geek and novice blogger: http://www.holoweb.net/~laurie/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using struts forms as Value Objects: your opinion?
Hubert Rabago wrote the following on 7/8/2005 12:24 AM:
There are several
reasons why you shouldn't use VOs as your form beans and vice versa
(as other msgs in this thread explain).
Actually in this thread so far I haven't heard anyone explain why they
are a 'bad' idea. The only way I see it being 'sort of' bad would be if...
1) You insist upon using the validation framework by having validation
take place by setting validation="true" in your struts-config mappings.
(I like to call validation manually in my Actions so this isn't really a
problem - it's like an extra line or two of code).
2) Sometimes you have some odd non-VO type properties that you want to
send to your Action. If you insist these needed to be captured by some
kind of bean/ActionForm than yea I guess that's a minor problem... but
what's the big deal about using an occasional request.getParameter("")
or since you are using Struts you still 'have' to use an ActionForm just
add the VO as a property and you can still a few other misc fields if
you so desire.
ActionForm == "The Black Sheep of Struts" :)
--
Rick
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using struts forms as Value Objects: your opinion?
Vincent, Before you go this route, check out FormDef plugin first. http://formdef.dev.java.net It will register Struts forms based on your VOs. There are several reasons why you shouldn't use VOs as your form beans and vice versa (as other msgs in this thread explain). FormDef would allow you the development savings you mention and also has functionality to translate from one to the other. Hubert On 7/7/05, Vincent <[EMAIL PROTECTED]> wrote: > Hi, > > I'm currently designing and developping an enterprise J2EE application > based on Struts. > In this application there's a layer of Data Access Object which abstract > the underlying persistent storage. > For populating my struts' *Form I've imagined first a transfert between > forms and DAO based on Value Object, associated with helper classes for > translating from one type to another. > And I realized that struts Form can be in some situations quite good > transfert objects, and by doing so we economize development of both > helper classes and VO classes. > > What do you thing about using forms as VO? Do you think it's a dirty > solution? Forms are often mirrors of the database's table. > > Thank you for your opinion. > > Vincent. > > > - > 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]
Fw: Re: Using struts forms as Value Objects: your opinion?
Sorry, Michael, I accidentally sent this directly to you . . . I'm not sure why you say "save a call to the backend" unless by "backend" you mean anything outside of the web tier. In my applications, it would typically save a call to the manager layer, which I consider the middle, not the backend. It would not typically save a call to the persistence layer -- the backend -- as managers usually don't need to access a persistent store to perform manager-layer validation (I suppose there are exceptions). So, different layer, as you say, but same VM usually. For a much-distributed application, I could see the argument about saving the call to any other layer, but, I would need another solution for that problem, such as a local manager. I don't typically have any classes that resemble what you are describing as a "business object". I typically have managers, value objects, helper objects (mini-managers if you will), and data access objects. Value objects are the only ones that cross tier boundaries, and they are completely dumb. This creates weak coupling, which I prefer. I don't recall having any business object classes that had the same fields as value objects plus business logic. I suppose back when I was writing entity beans there might have been some. Now, I have managers which operate on the other object types. Business logic is in the managers. Data is elsewhere (generally). Erik -Original Message- From: Michael Jouravlev <[EMAIL PROTECTED]> Sent: Jul 7, 2005 8:16 PM To: Struts Users Mailing List , [EMAIL PROTECTED] Subject: Re: Using struts forms as Value Objects: your opinion? On 7/7/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > An alternative would be to have your form class extend > your value object class. However, this approach doesn't > work for me. My form class fields are always Strings > (because of HTTP), while my value object fields are > whatever types make sense (such as Date). I always have > value object classes that look very similar to my forms, > but the types vary. It doesn't bother me. What is the point of having strong typed VOs? They are neither BOs (no behavior), nor actionforms. Why not to use BOs directly? Someone is going to check for business rules, why not to do it while data is still on web layer? Can save on call to backend. It seem to be a religious argument, and different approaches are good for different situations, but *generally* I would think that using BOs directly is easier and faster. One can say that app can evolve. BOs can evolve one way, and UI another way. Well, then create another BO instead of creating another VO. What is the difference? I will have several BOs working with more or less same data. How bad is that? Oh, right, I have to update web layer. As if one does not have to update web layer, when one modifies VOs. Ultimately all goes to database anyway. Michael. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using struts forms as Value Objects: your opinion?
I usually build my ActionForm classes with the VO on it as a property. The String properties can be just refered to as bean.property on the jsp. Any non-string properties I map to the bean in the action form, with the translation - so if there is a date, for instance, the property on the action form might be someDate, and in it's setter, i store the string, parse it using a dateformat object, and store it into the bean if it is a valid format. If the format is bad, i keep the string for display back to the user. That way, by the time the action gets the form the bean has all the properties and the types are correct. Larry On 7/7/05, Vincent <[EMAIL PROTECTED]> wrote: > Hi, > > I'm currently designing and developping an enterprise J2EE application > based on Struts. > In this application there's a layer of Data Access Object which abstract > the underlying persistent storage. > For populating my struts' *Form I've imagined first a transfert between > forms and DAO based on Value Object, associated with helper classes for > translating from one type to another. > And I realized that struts Form can be in some situations quite good > transfert objects, and by doing so we economize development of both > helper classes and VO classes. > > What do you thing about using forms as VO? Do you think it's a dirty > solution? Forms are often mirrors of the database's table. > > Thank you for your opinion. > > Vincent. > > > - > 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]
Re: Using struts forms as Value Objects: your opinion?
On 7/7/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > An alternative would be to have your form class extend > your value object class. However, this approach doesn't > work for me. My form class fields are always Strings > (because of HTTP), while my value object fields are > whatever types make sense (such as Date). I always have > value object classes that look very similar to my forms, > but the types vary. It doesn't bother me. What is the point of having strong typed VOs? They are neither BOs (no behavior), nor actionforms. Why not to use BOs directly? Someone is going to check for business rules, why not to do it while data is still on web layer? Can save on call to backend. It seem to be a religious argument, and different approaches are good for different situations, but *generally* I would think that using BOs directly is easier and faster. One can say that app can evolve. BOs can evolve one way, and UI another way. Well, then create another BO instead of creating another VO. What is the difference? I will have several BOs working with more or less same data. How bad is that? Oh, right, I have to update web layer. As if one does not have to update web layer, when one modifies VOs. Ultimately all goes to database anyway. Michael. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using struts forms as Value Objects: your opinion?
Also you could "economize" your development by using Struts Dyna-flavored forms (generated from xml) instead of writing your own form classes. Instead, I use a class I wrote that scans a properties file which has a comma-separated list of fields and their types, and some other data such as desired class name, default access modifier, etc. The class produces source files with typed fields (or an all-String version if I'm making a form class) and all the getters and setters. Saves all that unnecessary typing. All I do is write a properties file for each form and/or value object class I want. You can go a step further and create value object classes based on database metadata . . . Erik -Original Message- From: [EMAIL PROTECTED] Sent: Jul 7, 2005 7:33 PM To: Struts Users Mailing List Subject: Re: Using struts forms as Value Objects: your opinion? An alternative would be to have your form class extend your value object class. However, this approach doesn't work for me. My form class fields are always Strings (because of HTTP), while my value object fields are whatever types make sense (such as Date). I always have value object classes that look very similar to my forms, but the types vary. It doesn't bother me. Check out Jakarta BeanUtils for auto-conversion of field data between form class and value object class. Erik -Original Message- From: Vincent <[EMAIL PROTECTED]> Sent: Jul 7, 2005 7:15 PM To: user@struts.apache.org Subject: Using struts forms as Value Objects: your opinion? Hi, I'm currently designing and developping an enterprise J2EE application based on Struts. In this application there's a layer of Data Access Object which abstract the underlying persistent storage. For populating my struts' *Form I've imagined first a transfert between forms and DAO based on Value Object, associated with helper classes for translating from one type to another. And I realized that struts Form can be in some situations quite good transfert objects, and by doing so we economize development of both helper classes and VO classes. What do you thing about using forms as VO? Do you think it's a dirty solution? Forms are often mirrors of the database's table. Thank you for your opinion. Vincent. - 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]
Re: Using struts forms as Value Objects: your opinion?
An alternative would be to have your form class extend your value object class. However, this approach doesn't work for me. My form class fields are always Strings (because of HTTP), while my value object fields are whatever types make sense (such as Date). I always have value object classes that look very similar to my forms, but the types vary. It doesn't bother me. Check out Jakarta BeanUtils for auto-conversion of field data between form class and value object class. Erik -Original Message- From: Vincent <[EMAIL PROTECTED]> Sent: Jul 7, 2005 7:15 PM To: user@struts.apache.org Subject: Using struts forms as Value Objects: your opinion? Hi, I'm currently designing and developping an enterprise J2EE application based on Struts. In this application there's a layer of Data Access Object which abstract the underlying persistent storage. For populating my struts' *Form I've imagined first a transfert between forms and DAO based on Value Object, associated with helper classes for translating from one type to another. And I realized that struts Form can be in some situations quite good transfert objects, and by doing so we economize development of both helper classes and VO classes. What do you thing about using forms as VO? Do you think it's a dirty solution? Forms are often mirrors of the database's table. Thank you for your opinion. Vincent. - 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]
Re: Using struts forms as Value Objects: your opinion?
You said it would be an enterprise j2ee application, right? So there is a chance it would be distributed once? In this case using ActionForms as VO is an absolute NO GO ! Besides, if you want a clear architectural separation of layers its a NO GO also! The VO Objects are parts of your business logic interface (I hope you have one) and ActionForm have nothing to do with business logic or, even worse, DAOs. A typical enterprise architecture is 3 layered: Presentation with Actions / ActionForms / jsps Business with business interfaces and VOs or DTOs (name it as you like it) Persistence with DAOs And, from practical experience, your Forms may seem to be mirrors of the database at the beginning, but this will change as soon as your application start to live (Think about collections for drop-downs for example). Regards Leon > -Ursprüngliche Nachricht- > Von: news [mailto:[EMAIL PROTECTED] Im Auftrag von Vincent > Gesendet: Freitag, 8. Juli 2005 01:15 > An: user@struts.apache.org > Betreff: Using struts forms as Value Objects: your opinion? > > Hi, > > I'm currently designing and developping an enterprise J2EE > application based on Struts. > In this application there's a layer of Data Access Object > which abstract the underlying persistent storage. > For populating my struts' *Form I've imagined first a > transfert between forms and DAO based on Value Object, > associated with helper classes for translating from one type > to another. > And I realized that struts Form can be in some situations > quite good transfert objects, and by doing so we economize > development of both helper classes and VO classes. > > What do you thing about using forms as VO? Do you think it's > a dirty solution? Forms are often mirrors of the database's table. > > Thank you for your opinion. > > Vincent. > > > - > 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]
Re: Using struts forms as Value Objects: your opinion?
You said it would be an enterprise j2ee application, right? So there is a chance it would be distributed once? In this case using ActionForms as VO is an absolute NO GO ! Besides, if you want a clear architectural separation of layers its a NO GO also! The VO Objects are parts of your business logic interface (I hope you have one) and ActionForm have nothing to do with business logic or, even worse, DAOs. A typical enterprise architecture is 3 layered: Presentation with Actions / ActionForms / jsps Business with business interfaces and VOs or DTOs (name it as you like it) Persistence with DAOs And, from practical experience, your Forms may seem to be mirrors of the database at the beginning, but this will change as soon as your application start to live (Think about collections for drop-downs for example). Regards Leon > -Ursprüngliche Nachricht- > Von: news [mailto:[EMAIL PROTECTED] Im Auftrag von Vincent > Gesendet: Freitag, 8. Juli 2005 01:15 > An: user@struts.apache.org > Betreff: Using struts forms as Value Objects: your opinion? > > Hi, > > I'm currently designing and developping an enterprise J2EE > application based on Struts. > In this application there's a layer of Data Access Object > which abstract the underlying persistent storage. > For populating my struts' *Form I've imagined first a > transfert between forms and DAO based on Value Object, > associated with helper classes for translating from one type > to another. > And I realized that struts Form can be in some situations > quite good transfert objects, and by doing so we economize > development of both helper classes and VO classes. > > What do you thing about using forms as VO? Do you think it's > a dirty solution? Forms are often mirrors of the database's table. > > Thank you for your opinion. > > Vincent. > > > - > 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]
Using struts forms as Value Objects: your opinion?
Hi, I'm currently designing and developping an enterprise J2EE application based on Struts. In this application there's a layer of Data Access Object which abstract the underlying persistent storage. For populating my struts' *Form I've imagined first a transfert between forms and DAO based on Value Object, associated with helper classes for translating from one type to another. And I realized that struts Form can be in some situations quite good transfert objects, and by doing so we economize development of both helper classes and VO classes. What do you thing about using forms as VO? Do you think it's a dirty solution? Forms are often mirrors of the database's table. Thank you for your opinion. Vincent. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
