RE: Value object doubt !!!

[JM]

Vic, the zip file I downloaded is password protected.

The other one dated (3/27/2002) is not protected.

Did I get the wrong one?

JM 

> -Original Message-
> From: Struts Newsgroup [mailto:@[EMAIL PROTECTED]]
> Sent: Friday, May 24, 2002 3:25 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Value object doubt !!!
> 






--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Re: Value object doubt !!!

[@Basebeans.com]

Subject: Re: Value object doubt !!!
From: Vic C <[EMAIL PROTECTED]>
 ===
Don't kill the messenger. That's what some of this is about. I do not 
know of any contradictions documents or comments and my and other 
consultants experience is inline with this. See point 95, I think that 
is why there are a few vocal sales people who say the emperor IS wearing 
some clothing.
This is why I did what is says on page 4, 2nd sentence.
The working full realistic example webPIM is Struts specific. However 
the choice I did to implement the dao (DAO has nothing to do with 
Struts. Struts only defines the form Bean and MVC ) is what is says on 
page 4 2nd sentence.

JDO got recently delayed or pulled. You cant do XML joins (as JDO 
implies), and have some of the same EQL issues. On news.strutsplus.com 
there is a newsgroup Castor a leading JDO implementation. I wish there 
was a better place than Struts MVC to talk about the M at length. 
Anyway, my implementation works well at several client's production 
sites and ... I am the only one to share a public realistic full example 
with tiles, validation, master detail, CRUD, model, navigation, options, 
formatting, etc. which I think kind of makes me a bit of a target. Some 
day there will be a better practice to  CRUD Master/Detail applications 
that are better than webPIM. My goal was webPIM as a Struts MVC example, 
but by separating the DAO outside of the bean, people can implement the 
DAO anyway they chose, and not follow my design. Or they can refractor 
and improved DAO and not break the bean.

They only good choice, for people that hire me to advise them or recover 
their project, is to roll your own beans. I had to show a working 
realistic M in webPIM and did so.

Nice thing about open standards is that any potential weakens is 
publicized and criticized and a road to improvements is open, by those 
wiling to implement it. When MS has a weakness, it is "forbade to 
criticize the HQ". Cathedral and the Bazaar book shows why open standard 
will defeat the "Cathedral approach.

Vic



Michael Delamere wrote:
> Hi,
> 
> I´ve just read the "EJB_101Damnations.pdf".  Could somebody lead me to an
> article that may contradict the 101Damnations pdf.  If the specified pdf is
> overall correct, what are the alternatives?  JDO??
> 
> Could someone please clarify me on this issue.
> 
> Thanks,
> 
> Michael
> 
> 
> - Original Message -
> From: "Struts Newsgroup" <@[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Friday, May 24, 2002 7:25 PM
> Subject: Re: Value object doubt !!!
> 
> 
> 
>>Subject: Re: Value object doubt !!!
>>From: Vic C <[EMAIL PROTECTED]>
>> ===
>>Fat fingered "do not look at"
>>http://www.softwarereality.com/programming/ejb/EJB_101Damnations.pdf
>>
>>
>>Vic Cekvenich wrote:
>>
>>>STEVE WILKINSON wrote:
>>>2 each his own. I understand you view on EJB's and would apprechiate if
>>>you keep that on your site and don't put that here.
>>>
>>>   Should I say do not look at
>>>   http://www.bad-managers.com/Features*/ejb/i*ndex.shtml ?
>>>   Not sure how to respond to this. EJB's is something I used in the
>>>   model; and now I don't. You don't think people should be exposed as
>>>   to why that is? Certainly new users and new managers should be aware
>>>   that you can do MVC and J2EE without EJB and at least some feel that
>>>   this is better. My guess is EJBs are going to go the way of the
>>>   client side Java, that is to say, they will not be used. I predict
>>>   that the silent majority used to use EJB's and don't use EJB anymore
>>>   and very soon that will be conventional wisdom not to use EJB. I
>>>   would say people that argue EJB is good lose some credibility with
>>>   me (and you could say people that argue EJB are not good lose
>>>   credibility with you. 2 each his own) I do ask for comments on
>>>   http://www.bad-managers.com/Features/ejb/index.shtml here or at
>>>   mvc-programmers.
>>>
>>>
>>>We are using the EJB technology, but we also use DataAccessObjects
>>>(DAO), the problem is that the data in the database is needed by both
>>>web clients and other interfaces, XML/SOAP, and Java Swing Clients. We
>>>are using the transformation process strickly on the web tier to
>>>eliminate some of the manual coding within the Action class. We have
>>>JUnit tests for Form Beans and ValueObjects (DTO) to remind us that when
>>>we update one we need to update the other.
>>>
>>>   :-\ , You can look at a post in the mvc-programmers news gr

Re: Value object doubt !!!

[@Basebeans.com]

Subject: Re: Value object doubt !!!
From: Vic C <[EMAIL PROTECTED]>
 ===
And no need to panic, anyone can build a web app. But a software 
engineer can help you use less resources and effort and make it more 
scalable and maintainable.

Vic C wrote:
> Don't kill the messenger. That's what some of this is about. I do not 
> know of any contradictions documents or comments and my and other 
> consultants experience is inline with this. See point 95, I think that 
> is why there are a few vocal sales people who say the emperor IS wearing 
> some clothing.
> This is why I did what is says on page 4, 2nd sentence.
> The working full realistic example webPIM is Struts specific. However 
> the choice I did to implement the dao (DAO has nothing to do with 
> Struts. Struts only defines the form Bean and MVC ) is what is says on 
> page 4 2nd sentence.
> 
> JDO got recently delayed or pulled. You cant do XML joins (as JDO 
> implies), and have some of the same EQL issues. On news.strutsplus.com 
> there is a newsgroup Castor a leading JDO implementation. I wish there 
> was a better place than Struts MVC to talk about the M at length. 
> Anyway, my implementation works well at several client's production 
> sites and ... I am the only one to share a public realistic full example 
> with tiles, validation, master detail, CRUD, model, navigation, options, 
> formatting, etc. which I think kind of makes me a bit of a target. Some 
> day there will be a better practice to  CRUD Master/Detail applications 
> that are better than webPIM. My goal was webPIM as a Struts MVC example, 
> but by separating the DAO outside of the bean, people can implement the 
> DAO anyway they chose, and not follow my design. Or they can refractor 
> and improved DAO and not break the bean.
> 
> They only good choice, for people that hire me to advise them or recover 
> their project, is to roll your own beans. I had to show a working 
> realistic M in webPIM and did so.
> 
> Nice thing about open standards is that any potential weakens is 
> publicized and criticized and a road to improvements is open, by those 
> wiling to implement it. When MS has a weakness, it is "forbade to 
> criticize the HQ". Cathedral and the Bazaar book shows why open standard 
> will defeat the "Cathedral approach.
> 
> Vic
> 
> 
> 
> Michael Delamere wrote:
> 
>> Hi,
>>
>> I´ve just read the "EJB_101Damnations.pdf".  Could somebody lead me to an
>> article that may contradict the 101Damnations pdf.  If the specified 
>> pdf is
>> overall correct, what are the alternatives?  JDO??
>>
>> Could someone please clarify me on this issue.
>>
>> Thanks,
>>
>> Michael
>>
>>
>> - Original Message -
>> From: "Struts Newsgroup" <@[EMAIL PROTECTED]>
>> To: <[EMAIL PROTECTED]>
>> Sent: Friday, May 24, 2002 7:25 PM
>> Subject: Re: Value object doubt !!!
>>
>>
>>
>>> Subject: Re: Value object doubt !!!
>>> From: Vic C <[EMAIL PROTECTED]>
>>> ===
>>> Fat fingered "do not look at"
>>> http://www.softwarereality.com/programming/ejb/EJB_101Damnations.pdf
>>>
>>>
>>> Vic Cekvenich wrote:
>>>
>>>> STEVE WILKINSON wrote:
>>>> 2 each his own. I understand you view on EJB's and would apprechiate if
>>>> you keep that on your site and don't put that here.
>>>>
>>>>   Should I say do not look at
>>>>   http://www.bad-managers.com/Features*/ejb/i*ndex.shtml ?
>>>>   Not sure how to respond to this. EJB's is something I used in the
>>>>   model; and now I don't. You don't think people should be exposed as
>>>>   to why that is? Certainly new users and new managers should be aware
>>>>   that you can do MVC and J2EE without EJB and at least some feel that
>>>>   this is better. My guess is EJBs are going to go the way of the
>>>>   client side Java, that is to say, they will not be used. I predict
>>>>   that the silent majority used to use EJB's and don't use EJB anymore
>>>>   and very soon that will be conventional wisdom not to use EJB. I
>>>>   would say people that argue EJB is good lose some credibility with
>>>>   me (and you could say people that argue EJB are not good lose
>>>>   credibility with you. 2 each his own) I do ask for comments on
>>>>   http://www.bad-managers.com/Features/ejb/index.shtml here or at
>>>>   mvc-programmers.
>>>>
>>>>
>>>> We are using 

RE: Value object doubt !!!

[Steel, Toby]

>From: Vic C <[EMAIL PROTECTED]>
 ===
>>From: Toby Steel <[EMAIL PROTECTED]>
>> The form bean holds a data value object(DVO)
>> 

>The point of MVC is to "hide" the implementation of the model. The 
>presentation view should know nothing about how the form bean is 
>implemented. So maybe a simpler getter.

What was the purpose in hiding the implementation of the model from the JSP?
If one desired, one can still duplicate all dvo methods in the form bean
and just have them access the wrapped dvo. I wanted to avoid this, so I have
to allow the JSP to access the dvo directly.

>> Any field that does require validating input has a data holder object.
>> These holder objects all take string input and have a validate method
called
>> within the form bean validate method.

>Do you do client side validation using the Struts validator frame work 
>and regular expersions? Or Server side still using struts-validator.xml?
>With the simpler getter, Struts could do validation for you.

We tried this for a while but the amount of maintenance of the validation
xml
was too much we felt. Also, we do not need browser validation, so having
traditional form bean validation was easiest to deal with. Struts validation
might be a refactoring task in the future. It's on the table

>> The form bean's getDvo() method populates the DVO from the holder objects
>> while setDvo() sets the holder objects from the DVO.

>Again very similar at this higher level. I have a populate method that 
>asks DAO to retrieve. You hava a getDVO that :
>-(OK here we differ:)
>holder beans that get data from EJBs, and deal with multi rows master 
>detail CRUD and multi row validation?

We only use the holder beans as intermediary between form input and DVO.
They delay from the time populate() is called on the form bean to when
validate() is.
Only then may the DVO throw its exceptions and only there may typecasting
fail.
Multirows and other data access issues are dealt with as the object model
dictates.

>> we can add to our data model without doing
>> anything other than adding to the CMP mapping 

>CMP is yet another bean that maybe could be eliminated.
>Would you do CMP again?

If I had a robust and efficient persistence layer, I would use that.
Maybe Castor? TopLink? Cocobase? 

>I like SQL better than EQL.

Sure, but EJB-QL is sufficient to load/store DVOs. 

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Value object doubt !!!

[Michael Delamere]

Hi,

I´ve just read the "EJB_101Damnations.pdf".  Could somebody lead me to an
article that may contradict the 101Damnations pdf.  If the specified pdf is
overall correct, what are the alternatives?  JDO??

Could someone please clarify me on this issue.

Thanks,

Michael


- Original Message -
From: "Struts Newsgroup" <@[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, May 24, 2002 7:25 PM
Subject: Re: Value object doubt !!!


> Subject: Re: Value object doubt !!!
> From: Vic C <[EMAIL PROTECTED]>
>  ===
> Fat fingered "do not look at"
> http://www.softwarereality.com/programming/ejb/EJB_101Damnations.pdf
>
>
> Vic Cekvenich wrote:
> > STEVE WILKINSON wrote:
> > 2 each his own. I understand you view on EJB's and would apprechiate if
> > you keep that on your site and don't put that here.
> >
> >Should I say do not look at
> >http://www.bad-managers.com/Features*/ejb/i*ndex.shtml ?
> >Not sure how to respond to this. EJB's is something I used in the
> >model; and now I don't. You don't think people should be exposed as
> >to why that is? Certainly new users and new managers should be aware
> >that you can do MVC and J2EE without EJB and at least some feel that
> >this is better. My guess is EJBs are going to go the way of the
> >client side Java, that is to say, they will not be used. I predict
> >that the silent majority used to use EJB's and don't use EJB anymore
> >and very soon that will be conventional wisdom not to use EJB. I
> >would say people that argue EJB is good lose some credibility with
> >me (and you could say people that argue EJB are not good lose
> >credibility with you. 2 each his own) I do ask for comments on
> >http://www.bad-managers.com/Features/ejb/index.shtml here or at
> >mvc-programmers.
> >
> >
> > We are using the EJB technology, but we also use DataAccessObjects
> > (DAO), the problem is that the data in the database is needed by both
> > web clients and other interfaces, XML/SOAP, and Java Swing Clients. We
> > are using the transformation process strickly on the web tier to
> > eliminate some of the manual coding within the Action class. We have
> > JUnit tests for Form Beans and ValueObjects (DTO) to remind us that when
> > we update one we need to update the other.
> >
> >:-\ , You can look at a post in the mvc-programmers news group on
> >how it is benefitial to have a single model beans for use by SOAP,
> >Swing, etc.
> >
> >
> > I'm just trying to give someone a peek at how we are planning on doing
> > that.
> >
> >
> >It looked like a question.
> >
> >
> >
> >
> > If you have "been there done, done that, got the T-shirt" I would be
> > interested in hearing how you did the conversion from ValueObject (DTO)
> > to FormBean and return.
> >
> >I have a post of the code on the strutsplus.com home page. Again,
> >feel free to comment on the implemented design.
> >
> >
> > To the newbies, you don't want to sub-class a mixed type object within a
> > FormBean because of validation issues that Craig covered in prior posts.
> > If you want to do it automatically in a layered tier, I've described an
> > approach that we are trying.
> >
> >    ??
> >
> >
> >
> >
> > I by not way mean to imply this is the best way or the only way. If you
> > want an option there are plenty on this list to provide it.
> >
> > BTW, it's Friday.
> >
> >I just need not to look at this list on Fridays. ;-)
> >Vic
> >
> >
> >>
> >>
> >>> From: Struts Newsgroup (@Basebeans.com) <[EMAIL PROTECTED]>
> >>> Reply-To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
> >>> To: [EMAIL PROTECTED]
> >>> Subject: Re: Value object doubt !!!
> >>> Date: Fri, 24 May 2002 08:10:02 -0700
> >>>
> >>> Subject: Re: Value object doubt !!!
> >>> From: Vic C <[EMAIL PROTECTED]>
> >>> ===
> >>> Been there done that, got the T-Shirt. I used to do the same thing.
> >>> And I found a simpler, better approach and have a tested production
> >>> designs and fully functional sample code to show! Other designs are
not
> >>> showing fully functional code.
> >>> I do project recovery for a living.
> >>> For your consideration:
> >>>
> >>&g

Re: Value object doubt !!!

[STEVE WILKINSON]

Mutiple java types (java.sql.Date, java.lang.Float, etc.)

>From: "Lalit Pant" <[EMAIL PROTECTED]>
>Reply-To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
>To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
>Subject: Re: Value object doubt !!!
>Date: Fri, 24 May 2002 12:54:34 -0400
>
>Steve,
>
> >
> > To the newbies, you don't want to sub-class a mixed type
> > object within a
> > FormBean because of validation issues that Craig covered
> > in prior posts.
>
>What exactly do you mean by "a mixed type object within a FormBean"?
>
>Thanks,
>- Lalit
>
>
>
>--
>To unsubscribe, e-mail:   
><mailto:[EMAIL PROTECTED]>
>For additional commands, e-mail: 
><mailto:[EMAIL PROTECTED]>
>




_
Join the world’s largest e-mail service with MSN Hotmail. 
http://www.hotmail.com


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Re: Value object doubt !!!

[@Basebeans.com]

Subject: Re: Value object doubt !!!
From: Vic C <[EMAIL PROTECTED]>
 ===
Fat fingered "do not look at" 
http://www.softwarereality.com/programming/ejb/EJB_101Damnations.pdf


Vic Cekvenich wrote:
> STEVE WILKINSON wrote:
> 2 each his own. I understand you view on EJB's and would apprechiate if 
> you keep that on your site and don't put that here.
> 
>Should I say do not look at
>http://www.bad-managers.com/Features*/ejb/i*ndex.shtml ?
>Not sure how to respond to this. EJB's is something I used in the
>model; and now I don't. You don't think people should be exposed as
>to why that is? Certainly new users and new managers should be aware
>that you can do MVC and J2EE without EJB and at least some feel that
>this is better. My guess is EJBs are going to go the way of the
>client side Java, that is to say, they will not be used. I predict
>that the silent majority used to use EJB's and don't use EJB anymore
>and very soon that will be conventional wisdom not to use EJB. I
>would say people that argue EJB is good lose some credibility with
>me (and you could say people that argue EJB are not good lose
>credibility with you. 2 each his own) I do ask for comments on
>http://www.bad-managers.com/Features/ejb/index.shtml here or at
>mvc-programmers.
> 
> 
> We are using the EJB technology, but we also use DataAccessObjects 
> (DAO), the problem is that the data in the database is needed by both 
> web clients and other interfaces, XML/SOAP, and Java Swing Clients. We 
> are using the transformation process strickly on the web tier to 
> eliminate some of the manual coding within the Action class. We have 
> JUnit tests for Form Beans and ValueObjects (DTO) to remind us that when 
> we update one we need to update the other.
> 
>:-\ , You can look at a post in the mvc-programmers news group on
>how it is benefitial to have a single model beans for use by SOAP,
>Swing, etc.
> 
> 
> I'm just trying to give someone a peek at how we are planning on doing 
> that.
> 
> 
>It looked like a question.
> 
> 
> 
> 
> If you have "been there done, done that, got the T-shirt" I would be 
> interested in hearing how you did the conversion from ValueObject (DTO) 
> to FormBean and return.
> 
>I have a post of the code on the strutsplus.com home page. Again,
>feel free to comment on the implemented design.
> 
> 
> To the newbies, you don't want to sub-class a mixed type object within a 
> FormBean because of validation issues that Craig covered in prior posts. 
> If you want to do it automatically in a layered tier, I've described an 
> approach that we are trying.
> 
>??
> 
> 
> 
> 
> I by not way mean to imply this is the best way or the only way. If you 
> want an option there are plenty on this list to provide it.
> 
> BTW, it's Friday.
> 
>I just need not to look at this list on Fridays. ;-)
>    Vic
> 
> 
>>
>>
>>> From: Struts Newsgroup (@Basebeans.com) <[EMAIL PROTECTED]>
>>> Reply-To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
>>> To: [EMAIL PROTECTED]
>>> Subject: Re: Value object doubt !!!
>>> Date: Fri, 24 May 2002 08:10:02 -0700
>>>
>>> Subject: Re: Value object doubt !!!
>>> From: Vic C <[EMAIL PROTECTED]>
>>> ===
>>> Been there done that, got the T-Shirt. I used to do the same thing.
>>> And I found a simpler, better approach and have a tested production
>>> designs and fully functional sample code to show! Other designs are not
>>> showing fully functional code.
>>> I do project recovery for a living.
>>> For your consideration:
>>>
>>> Craig support light weight frameworks MVC I think and not forcing people
>>> to do things one way.(Are you using EJB? How are you addressing some of
>>> the issues in Software Reality EJB 101 that I and others found?)
>>> I hope to persuade Craig and others one way to look at a practical and
>>> simple and light weight alternative for model direction. I think it all
>>> stems from the old discussion of should form beans be a base class or an
>>> interface. (I think one of the reasons for Struts success is that it is
>>> light weight, simple and practical).
>>>
>>> The point of using a framework it to use it, and not build a framework.
>>> Analogy I use it you can wake up in the morning and drive a car, or go
>>> under the car and thinker with the combustion engine and the brakes. No
>>> need to mess w

Re: Value object doubt !!!

[Vic Cekvenich]

STEVE WILKINSON wrote:
2 each his own. I understand you view on EJB's and would apprechiate if 
you keep that on your site and don't put that here.

Should I say do not look at
http://www.bad-managers.com/Features*/ejb/i*ndex.shtml ?
Not sure how to respond to this. EJB's is something I used in the
model; and now I don't. You don't think people should be exposed as
to why that is? Certainly new users and new managers should be aware
that you can do MVC and J2EE without EJB and at least some feel that
this is better. My guess is EJBs are going to go the way of the
client side Java, that is to say, they will not be used. I predict
that the silent majority used to use EJB's and don't use EJB anymore
and very soon that will be conventional wisdom not to use EJB. I
would say people that argue EJB is good lose some credibility with
me (and you could say people that argue EJB are not good lose
credibility with you. 2 each his own) I do ask for comments on
http://www.bad-managers.com/Features/ejb/index.shtml here or at
mvc-programmers.


We are using the EJB technology, but we also use DataAccessObjects 
(DAO), the problem is that the data in the database is needed by both 
web clients and other interfaces, XML/SOAP, and Java Swing Clients. We 
are using the transformation process strickly on the web tier to 
eliminate some of the manual coding within the Action class. We have 
JUnit tests for Form Beans and ValueObjects (DTO) to remind us that when 
we update one we need to update the other.

:-\ , You can look at a post in the mvc-programmers news group on
how it is benefitial to have a single model beans for use by SOAP,
Swing, etc.


I'm just trying to give someone a peek at how we are planning on doing 
that.


It looked like a question.




If you have "been there done, done that, got the T-shirt" I would be 
interested in hearing how you did the conversion from ValueObject (DTO) 
to FormBean and return.

I have a post of the code on the strutsplus.com home page. Again,
feel free to comment on the implemented design.


To the newbies, you don't want to sub-class a mixed type object within a 
FormBean because of validation issues that Craig covered in prior posts. 
If you want to do it automatically in a layered tier, I've described an 
approach that we are trying.

??




I by not way mean to imply this is the best way or the only way. If you 
want an option there are plenty on this list to provide it.

BTW, it's Friday.

I just need not to look at this list on Fridays. ;-)
Vic


>
>
>> From: Struts Newsgroup (@Basebeans.com) <[EMAIL PROTECTED]>
>> Reply-To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
>> To: [EMAIL PROTECTED]
>> Subject: Re: Value object doubt !!!
>> Date: Fri, 24 May 2002 08:10:02 -0700
>>
>> Subject: Re: Value object doubt !!!
>> From: Vic C <[EMAIL PROTECTED]>
>> ===
>> Been there done that, got the T-Shirt. I used to do the same thing.
>> And I found a simpler, better approach and have a tested production
>> designs and fully functional sample code to show! Other designs are not
>> showing fully functional code.
>> I do project recovery for a living.
>> For your consideration:
>>
>> Craig support light weight frameworks MVC I think and not forcing people
>> to do things one way.(Are you using EJB? How are you addressing some of
>> the issues in Software Reality EJB 101 that I and others found?)
>> I hope to persuade Craig and others one way to look at a practical and
>> simple and light weight alternative for model direction. I think it all
>> stems from the old discussion of should form beans be a base class or an
>> interface. (I think one of the reasons for Struts success is that it is
>> light weight, simple and practical).
>>
>> The point of using a framework it to use it, and not build a framework.
>> Analogy I use it you can wake up in the morning and drive a car, or go
>> under the car and thinker with the combustion engine and the brakes. No
>> need to mess with the technology. Use the force Luke, to make your
>> project more productive.
>>
>> The larger the project the more the risk, so use Struts and don't do
>> technology. ValueObject are just another bean. Transformation helper?
>> You will get lost in the woods.
>>
>> Based on WebPIM from home page of StrutsPlus.com:
>> Here is a repost on an alterntative design for your consideration,
>> repost from news.strutsplus.com:
>>
>> [EMAIL PROTECTED]
>> > Inline:
>> >
>> > > Rick Reumann wrote:
>> > > I'm still new to trying to comprehend the v

Re: Value object doubt !!!

[Lalit Pant]

Steve,

> 
> To the newbies, you don't want to sub-class a mixed type 
> object within a 
> FormBean because of validation issues that Craig covered 
> in prior posts.  

What exactly do you mean by "a mixed type object within a FormBean"?

Thanks,
- Lalit



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Value object doubt !!!

[STEVE WILKINSON]

Did you use EJB1.1 or EJB2.0?  I know that 2.0 is fairly new, but we are in 
the elaboration phase of our project and believe we can use CMP in EJB2.0.  
I'm not on the EJB side, so I don't know the gritty details.

We had serious discussions about bulk accessors etc, but decided to have 
strongly typed Data Value Objects since our product will need other 
interfaces than HTML.  Thanks for the feedback.  I've done what you are 
talking about on smaller projects, but this one is so large it seems to fit 
better with a layered solution to reduce coupling and provide 
DataValueObject access in mixed type mode.


>From: "Steel, Toby" <[EMAIL PROTECTED]>
>Reply-To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
>To: "'Struts Users Mailing List'" <[EMAIL PROTECTED]>
>Subject: RE: Value object doubt !!!
>Date: Fri, 24 May 2002 11:56:14 -0400
>
>We do things a little differently to avoid code so much duplication
>between form bean and value object. There is no data conversion as
>a value object is always the vehicle for data delivery.
>
>The form bean holds a data value object(DVO), and every String field of the
>DVO
>(no validation of input in setter method) is accessed directly on populate
>via an accessor to the DVO, getDvo().
>
>Any field that does require validating input (integers, dates, postalCodes,
>more
>complex objects) has a data holder object in the form bean, along with
>get/set for the holder.
>
>These holder objects all take string input and have a validate method 
>called
>within
>the form bean validate method.
>The form bean's getDvo() method populates the DVO from the holder objects
>while setDvo() sets the holder objects from the DVO.
>
>This works very well, and we can add to our data model without doing
>anything
>other than adding to the CMP mapping and the JSP inputs. [Unless we need to
>add
>a holder object to the form bean.]
>
>Result: No translation of beans and value objects, only intermediate help 
>on
>those
>fields that throw exceptions in their setters or require non-String input.
>
>
>
>Toby Steel
>
>
>-Original Message-
>From: STEVE WILKINSON [mailto:[EMAIL PROTECTED]]
>Sent: Friday, May 24, 2002 10:23 AM
>To: [EMAIL PROTECTED]
>Subject: Re: Value object doubt !!!
>
>
>Given the comments from Craig on not using Value Objects as form beans our
>project is taking the following approach.
>
>We are creating a "helper" class to transform our ValueObject (Data 
>Transfer
>
>Object as we call it) into a form bean (Strings, Boolean, and boolean types
>only) and the reverse.>
> >
> >Radhika Nadkarni wrote:
> > >
> > > hi,
> > > Im having an action Form. Im using Value object for data conversions.
> > > Now my problem is i have two scenarios for implementing the same : -
> > > 1)  Value object will be separate
> > > 2)  Value object will be composed within the Form Bean.
> > > Can anyone tell me which is the best strategy out of the two ?
> > >
> > > _
> > > Get your FREE download of MSN Explorer at
> >http://explorer.msn.com/intl.asp.
> > >
> > > --
> > > To unsubscribe, e-mail:
> ><mailto:[EMAIL PROTECTED]>
> > > For additional commands, e-mail:
> ><mailto:[EMAIL PROTECTED]>
> >
> >--
> >To unsubscribe, e-mail:
> ><mailto:[EMAIL PROTECTED]>
> >For additional commands, e-mail:
> ><mailto:[EMAIL PROTECTED]>
> >
>
>
>_
>Chat with friends online, try MSN Messenger: http://messenger.msn.com
>
>
>--
>To unsubscribe, e-mail:
><mailto:[EMAIL PROTECTED]>
>For additional commands, e-mail:
><mailto:[EMAIL PROTECTED]>
>
>--
>To unsubscribe, e-mail:   
><mailto:[EMAIL PROTECTED]>
>For additional commands, e-mail: 
><mailto:[EMAIL PROTECTED]>




_
Send and receive Hotmail on your mobile device: http://mobile.msn.com


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Re: Value object doubt !!!

[STEVE WILKINSON]

Vic,

2 each his own.  I understand you view on EJB's and would apprechiate if you 
keep that on your site and don't put that here.

We are using the EJB technology, but we also use DataAccessObjects (DAO), 
the problem is that the data in the database is needed by both web clients 
and other interfaces, XML/SOAP, and Java Swing Clients.  We are using the 
transformation process strickly on the web tier to eliminate some of the 
manual coding within the Action class.  We have JUnit tests for Form Beans 
and ValueObjects (DTO) to remind us that when we update one we need to 
update the other.

I'm just trying to give someone a peek at how we are planning on doing that.

If you have "been there done, done that, got the T-shirt" I would be 
interested in hearing how you did the conversion from ValueObject (DTO) to 
FormBean and return.

To the newbies, you don't want to sub-class a mixed type object within a 
FormBean because of validation issues that Craig covered in prior posts.  If 
you want to do it automatically in a layered tier, I've described an 
approach that we are trying.  I by not way mean to imply this is the best 
way or the only way.  If you want an option there are plenty on this list to 
provide it.

BTW, it's Friday.


>From: Struts Newsgroup (@Basebeans.com) <[EMAIL PROTECTED]>
>Reply-To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
>To: [EMAIL PROTECTED]
>Subject: Re: Value object doubt !!!
>Date: Fri, 24 May 2002 08:10:02 -0700
>
>Subject: Re: Value object doubt !!!
>From: Vic C <[EMAIL PROTECTED]>
>  ===
>Been there done that, got the T-Shirt. I used to do the same thing.
>And I found a simpler, better approach and have a tested production
>designs and fully functional sample code to show! Other designs are not
>showing fully functional code.
>I do project recovery for a living.
>For your consideration:
>
>Craig support light weight frameworks MVC I think and not forcing people
>to do things one way.(Are you using EJB? How are you addressing some of
>the issues in Software Reality EJB 101 that I and others found?)
>I hope to persuade Craig and others one way to look at a practical and
>simple and light weight alternative for model direction. I think it all
>stems from the old discussion of should form beans be a base class or an
>interface. (I think one of the reasons for Struts success is that it is
>light weight, simple and practical).
>
>The point of using a framework it to use it, and not build a framework.
>Analogy I use it you can wake up in the morning and drive a car, or go
>under the car and thinker with the combustion engine and the brakes.  No
>need to mess with the technology. Use the force Luke, to make your
>project more productive.
>
>The larger the project the more the risk, so use Struts and don't do
>technology. ValueObject are just another bean. Transformation helper?
>You will get lost in the woods.
>
>Based on WebPIM from home page of StrutsPlus.com:
>Here is a repost on an alterntative design for your consideration,
>repost from news.strutsplus.com:
>
>[EMAIL PROTECTED]
>  > Inline:
>  >
>  >  > Rick Reumann wrote:
>  >  > I'm still new to trying to comprehend the various ways the Model 
>layer
>  >  > can be implemented in a J2EE app, so I want to make sure I'm
>  >  > understanding a few things in relation to the webPIM sample app at
>  >  > www.basebeans.com.
>  >
>  > It is possible to use J2EE without EJB and it is possible and desirable
>  > to use MVC with a less complexity. (No need for Business objects or
>  > Value Objects in some cases, if they do nothing for you if only a DAO
>  > would do). Doing things right means more scalability and faster to
>  > develop with less effort.
>  >
>  >  > 1) I was under the impression that you want to have your Data 
>Transfer
>  >  > Objects (or Value Objects) to be as reusable as possible. It looks
>  >  > like in the case of the webPIM app that a typical bean (ie 
>NameLstBean
>  >  > ) is tightly coupled with the table columns found in the DAO that 
>the
>  >  > bean has as a member.
>  >
>  > Nope. This is a form bean; it should reflect the page properties, not
>  > the physical data model. The bean is bound to the presentation. How the
>  > physical DB does not matter to the public interface of the bean.
>  > Idea here is that a requriment or html page would be the spec. You 
>would
>  > create a bean that follows it logicaly, with getters and setters
>  > matching page properties.
>  > (What confused you is the physical data model design, which a good
>  > design follows the outputs and uses of the w

Re: Value object doubt !!!

[@Basebeans.com]

Subject: Re: Value object doubt !!!
From: Vic C <[EMAIL PROTECTED]>
 ===
Steel, Toby wrote:
> We do things a little differently to avoid code so much duplication
> between form bean and value object. There is no data conversion as
> a value object is always the vehicle for data delivery.
> 
> The form bean holds a data value object(DVO), and every String field of the
> DVO 

Similar design. My aproach was FormBean that has a DAO in the example, 
you have a form bean that has a DVO.


> (no validation of input in setter method) is accessed directly on populate
> via an accessor to the DVO, getDvo().
> 

The point of MVC is to "hide" the implementation of the model. The 
presentation view should know nothing about how the form bean is 
implemented. So maybe a simpler getter.

> Any field that does require validating input (integers, dates, postalCodes,
> more
> complex objects) has a data holder object in the form bean, along with
> get/set for the holder.
> 
> These holder objects all take string input and have a validate method called
> within
> the form bean validate method.

Do you do client side validation using the Struts validator frame work 
and regular expersions? Or Server side still using struts-validator.xml?
With the simpler getter, Struts could do validation for you.


> The form bean's getDvo() method populates the DVO from the holder objects
> while setDvo() sets the holder objects from the DVO.
> 

Again very similar at this higher level. I have a populate method that 
asks DAO to retrieve. You hava a getDVO that :
-(OK here we differ:)
holder beans that get data from EJBs, and deal with multi rows master 
detail CRUD and multi row validation?


> This works very well, and we can add to our data model without doing
> anything
> other than adding to the CMP mapping 

One day someone should tell me how they dealt with CMP issues listed at 
softwarereality.com becuase I just gave up trying and wasting clients 
money ( I could have kept billing the client by prologing the pain but 
that is not what I do)
CMP is yet another bean that maybe could be eliminated.
Would you do CMP again?
I like SQL better than EQL.


> and the JSP inputs. [Unless we need to
> add
> a holder object to the form bean.] 
> 
> Result: No translation of beans and value objects, only intermediate help on
> those
> fields that throw exceptions in their setters or require non-String input.
> 
> 
> 
> Toby Steel
> 
> 
> -Original Message-----
> From: STEVE WILKINSON [mailto:[EMAIL PROTECTED]]
> Sent: Friday, May 24, 2002 10:23 AM
> To: [EMAIL PROTECTED]
> Subject: Re: Value object doubt !!!
> 
> 
> Given the comments from Craig on not using Value Objects as form beans our 
> project is taking the following approach.
> 
> We are creating a "helper" class to transform our ValueObject (Data Transfer
> 
> Object as we call it) into a form bean (Strings, Boolean, and boolean types 
> only) and the reverse.>
> 
>>Radhika Nadkarni wrote:
>>
>>>hi,
>>>Im having an action Form. Im using Value object for data conversions.
>>>Now my problem is i have two scenarios for implementing the same : -
>>>1)  Value object will be separate
>>>2)  Value object will be composed within the Form Bean.
>>>Can anyone tell me which is the best strategy out of the two ?
>>>
>>>_
>>>Get your FREE download of MSN Explorer at 
>>
>>http://explorer.msn.com/intl.asp.
>>
>>>--
>>>To unsubscribe, e-mail:   
>>
>><mailto:[EMAIL PROTECTED]>
>>
>>>For additional commands, e-mail: 
>>
>><mailto:[EMAIL PROTECTED]>
>>
>>--
>>To unsubscribe, e-mail:   
>><mailto:[EMAIL PROTECTED]>
>>For additional commands, e-mail: 
>><mailto:[EMAIL PROTECTED]>
>>
> 
> 
> _
> Chat with friends online, try MSN Messenger: http://messenger.msn.com
> 
> 
> --
> To unsubscribe, e-mail:
> <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
> <mailto:[EMAIL PROTECTED]>
> 
> --
> To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
> 


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

RE: Value object doubt !!!

[Steel, Toby]

We do things a little differently to avoid code so much duplication
between form bean and value object. There is no data conversion as
a value object is always the vehicle for data delivery.

The form bean holds a data value object(DVO), and every String field of the
DVO 
(no validation of input in setter method) is accessed directly on populate
via an accessor to the DVO, getDvo().

Any field that does require validating input (integers, dates, postalCodes,
more
complex objects) has a data holder object in the form bean, along with
get/set for the holder.

These holder objects all take string input and have a validate method called
within
the form bean validate method.
The form bean's getDvo() method populates the DVO from the holder objects
while setDvo() sets the holder objects from the DVO.

This works very well, and we can add to our data model without doing
anything
other than adding to the CMP mapping and the JSP inputs. [Unless we need to
add
a holder object to the form bean.] 

Result: No translation of beans and value objects, only intermediate help on
those
fields that throw exceptions in their setters or require non-String input.



Toby Steel


-Original Message-
From: STEVE WILKINSON [mailto:[EMAIL PROTECTED]]
Sent: Friday, May 24, 2002 10:23 AM
To: [EMAIL PROTECTED]
Subject: Re: Value object doubt !!!


Given the comments from Craig on not using Value Objects as form beans our 
project is taking the following approach.

We are creating a "helper" class to transform our ValueObject (Data Transfer

Object as we call it) into a form bean (Strings, Boolean, and boolean types 
only) and the reverse.>
>
>Radhika Nadkarni wrote:
> >
> > hi,
> > Im having an action Form. Im using Value object for data conversions.
> > Now my problem is i have two scenarios for implementing the same : -
> > 1)  Value object will be separate
> > 2)  Value object will be composed within the Form Bean.
> > Can anyone tell me which is the best strategy out of the two ?
> >
> > _
> > Get your FREE download of MSN Explorer at 
>http://explorer.msn.com/intl.asp.
> >
> > --
> > To unsubscribe, e-mail:   
><mailto:[EMAIL PROTECTED]>
> > For additional commands, e-mail: 
><mailto:[EMAIL PROTECTED]>
>
>--
>To unsubscribe, e-mail:   
><mailto:[EMAIL PROTECTED]>
>For additional commands, e-mail: 
><mailto:[EMAIL PROTECTED]>
>


_
Chat with friends online, try MSN Messenger: http://messenger.msn.com


--
To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>

--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Re: Value object doubt !!!

[Lalit Pant]

Radhika,

I'm also kinda a struts newbie, so don't take this as the word of an expert!

In a recent project that I did, I used FormBeans as wrappers over Value
Objects. I found some strong points to this kinda design:

- Separation of view related and biz logic issues
-- The Action class calls into the Session Layer, gets a DTO/VO, Inits a
FormBean.
-- The Action class retrieves an updated DTO from a FormBean, and calls into
the Session Layer to update the Biz layer

- Separation of 'Presentation' level validation (is a field blank, does it
contain a valid float etc.) from Biz level validation (is field1*field2 <
field3/1.5 etc)
-- Essentially, the FormBean does the Presentation level validation, and
then delegates to the DTO, which could do lightweight Biz validation.
-- The ActionErrors stuff is all taken care of within the FormBean. For
Presentation level validation errors, the FormBean has control anyways. For
Biz level validation errors, The DTO can throw a ValidationException which
the FormBean catches and takes care of by adding to ActionErrors.

I'm waiting for Chapter 7 of Chuck's book (On theServerSide.com) to read up
more on this ;)

Hope this helps,
- Lalit

- Original Message -
From: "Radhika Nadkarni" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, May 24, 2002 2:35 AM
Subject: Value object doubt !!!


> hi,
> Im having an action Form. Im using Value object for data conversions.
> Now my problem is i have two scenarios for implementing the same : -
> 1)  Value object will be separate
> 2)  Value object will be composed within the Form Bean.
> Can anyone tell me which is the best strategy out of the two ?
>
>
>
> _
> Get your FREE download of MSN Explorer at
http://explorer.msn.com/intl.asp.
>
>
> --
> To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>



--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Re: Value object doubt !!!

[@Basebeans.com]

Subject: Re: Value object doubt !!!
From: Vic C <[EMAIL PROTECTED]>
 ===
Been there done that, got the T-Shirt. I used to do the same thing.
And I found a simpler, better approach and have a tested production 
designs and fully functional sample code to show! Other designs are not 
showing fully functional code.
I do project recovery for a living.
For your consideration:

Craig support light weight frameworks MVC I think and not forcing people 
to do things one way.(Are you using EJB? How are you addressing some of 
the issues in Software Reality EJB 101 that I and others found?)
I hope to persuade Craig and others one way to look at a practical and 
simple and light weight alternative for model direction. I think it all 
stems from the old discussion of should form beans be a base class or an 
interface. (I think one of the reasons for Struts success is that it is 
light weight, simple and practical).

The point of using a framework it to use it, and not build a framework. 
Analogy I use it you can wake up in the morning and drive a car, or go 
under the car and thinker with the combustion engine and the brakes.  No 
need to mess with the technology. Use the force Luke, to make your 
project more productive.

The larger the project the more the risk, so use Struts and don't do 
technology. ValueObject are just another bean. Transformation helper? 
You will get lost in the woods.

Based on WebPIM from home page of StrutsPlus.com:
Here is a repost on an alterntative design for your consideration, 
repost from news.strutsplus.com:

[EMAIL PROTECTED]
 > Inline:
 >
 >  > Rick Reumann wrote:
 >  > I'm still new to trying to comprehend the various ways the Model layer
 >  > can be implemented in a J2EE app, so I want to make sure I'm
 >  > understanding a few things in relation to the webPIM sample app at
 >  > www.basebeans.com.
 >
 > It is possible to use J2EE without EJB and it is possible and desirable
 > to use MVC with a less complexity. (No need for Business objects or
 > Value Objects in some cases, if they do nothing for you if only a DAO
 > would do). Doing things right means more scalability and faster to
 > develop with less effort.
 >
 >  > 1) I was under the impression that you want to have your Data Transfer
 >  > Objects (or Value Objects) to be as reusable as possible. It looks
 >  > like in the case of the webPIM app that a typical bean (ie NameLstBean
 >  > ) is tightly coupled with the table columns found in the DAO that the
 >  > bean has as a member.
 >
 > Nope. This is a form bean; it should reflect the page properties, not
 > the physical data model. The bean is bound to the presentation. How the
 > physical DB does not matter to the public interface of the bean.
 > Idea here is that a requriment or html page would be the spec. You would
 > create a bean that follows it logicaly, with getters and setters
 > matching page properties.
 > (What confused you is the physical data model design, which a good
 > design follows the outputs and uses of the web app.)
 > So: Bean maps to the page logically. It hides the physical
 > implementation inside of it. Changes to the data model do affect the
 > implementation but not the "use" of the bean.
 > (Complex example: A bean getter could call another beans getter or
 > setter so you can have a bean that contains other beans for a complex 
page)
 >
 >
 >  > The design seems to be: call a populate method
 >  > on a particular bean which in turn will return a DAO to the bean that
 >  > contains a cached rowset of the columns returned from the query. Then
 >  > in order to get back say a First Name the bean will actually get a
 >  > handle to the DAO stored in the bean and then call a method like
 >  > nameLstDAO.getCRString("first_name"). (Forgive me Vic if I explained
 >  > that all wrong ).
 >
 > You got it. Very simple delegation. You can unit test the beans CRUD,
 > and properties  before you ever use it. And you can later make the beans
 > soapy.
 >
 >
 >  > So my question is under this model it seems like if
 >  > the underlying implementation changes, such as the column names in a
 >  > table change, you end up having to fix all your beans plus all of your
 >  > DAOs (as opposed to only having to change it one place if the DAOs are
 >  > used to directly populate the beans).
 >
 > The public interface of the bean stays the same. So the users of the
 > data model layer are not affected. The whole point of separating the
 > data layer is that if it changes, the other 2 layers are unaffected.
 > You would only fix the implementation of the bean or the dao that has
 > the changed table. Of course once you have data in the DB, you would
 > with the changed db have t

Re: Value object doubt !!!

[STEVE WILKINSON]

Given the comments from Craig on not using Value Objects as form beans our 
project is taking the following approach.

We are creating a "helper" class to transform our ValueObject (Data Transfer 
Object as we call it) into a form bean (Strings, Boolean, and boolean types 
only) and the reverse.  I started this effort by looking at the code within 
the beanutil package that is part of commons.  Unfortunately, object 
composition is not supported (User object contains an Address object) within 
the commons code base.  So, I've taken to writing our own transformation 
helper and take advantage reflection and the convertion utilities provided 
in the commons package.  Granted this is not an approach that a small 
project should take, but ours is a fairly large project and we wanted to 
create a "Helper class" to assist in transforming the data between tiers.  
The idea is that each interface (Struts being the HTTP interface) will have 
it's own helper class to assist in this.  I will reduce a little coding, but 
provide easy tranformation of the data between tiers.

Currently, the transformation helper class is dependent on our own package 
structure. :-(  I'm hoping to be able to refactor this so that it's 
configurable like the ConvertUtils does and I'll offer it up if people are
interested.   Also, since we are only prototyping right now, I don't provide 
support for Collections, but I do provide support for Object Array types 
(e.g. User[] user).  The intent is to provide Collection support in the 
future, but I must utilize a "type safe" collection that is initalized with 
"type" or it's class that will be stored at initialization in the target 
object so the transformation utility knows what class to create when 
transforming an object from one collection to the other.  We are using the 
same names for our attributes and classes, it's just different data types.  
The DTO (VO) contains mixed type, java.sql.Date, java.lang.Float, etc.  The 
FormBean
currently only has String, Boolean and boolean types.

Hope this helps give an idea on another approach.

Steve



>From: Ted Husted <[EMAIL PROTECTED]>
>Reply-To: [EMAIL PROTECTED]
>To: Struts Users Mailing List <[EMAIL PROTECTED]>
>Subject: Re: Value object doubt !!!
>Date: Fri, 24 May 2002 08:47:27 -0400
>
>The best stategy will depend on what else is going on with your
>application.
>
>The ActionForm is really part of the control layer and so can interact
>with objects on both the presentation and business layers.
>
>A generally useful approach is to put a factory method on the ActionForm
>that returns your value object.
>
>This neatly encapsulates the data transfer. All the Action has to do is
>call the method and pass along the result.
>
>Which I guess is your #2.
>
>-- Ted Husted, Husted dot Com, Fairport NY US
>-- Developing Java Web Applications with Struts
>-- Tel: +1 585 737-3463
>-- Web: http://husted.com/about/services
>
>
>Radhika Nadkarni wrote:
> >
> > hi,
> > Im having an action Form. Im using Value object for data conversions.
> > Now my problem is i have two scenarios for implementing the same : -
> > 1)  Value object will be separate
> > 2)  Value object will be composed within the Form Bean.
> > Can anyone tell me which is the best strategy out of the two ?
> >
> > _
> > Get your FREE download of MSN Explorer at 
>http://explorer.msn.com/intl.asp.
> >
> > --
> > To unsubscribe, e-mail:   
><mailto:[EMAIL PROTECTED]>
> > For additional commands, e-mail: 
><mailto:[EMAIL PROTECTED]>
>
>--
>To unsubscribe, e-mail:   
><mailto:[EMAIL PROTECTED]>
>For additional commands, e-mail: 
><mailto:[EMAIL PROTECTED]>
>


_
Chat with friends online, try MSN Messenger: http://messenger.msn.com


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Re: Value object doubt !!!

[Ted Husted]

The best stategy will depend on what else is going on with your
application. 

The ActionForm is really part of the control layer and so can interact
with objects on both the presentation and business layers. 

A generally useful approach is to put a factory method on the ActionForm
that returns your value object. 

This neatly encapsulates the data transfer. All the Action has to do is
call the method and pass along the result. 

Which I guess is your #2.

-- Ted Husted, Husted dot Com, Fairport NY US
-- Developing Java Web Applications with Struts
-- Tel: +1 585 737-3463
-- Web: http://husted.com/about/services


Radhika Nadkarni wrote:
> 
> hi,
> Im having an action Form. Im using Value object for data conversions.
> Now my problem is i have two scenarios for implementing the same : -
> 1)  Value object will be separate
> 2)  Value object will be composed within the Form Bean.
> Can anyone tell me which is the best strategy out of the two ?
> 
> _
> Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp.
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Value object doubt !!!

[Radhika Nadkarni]

hi,
Im having an action Form. Im using Value object for data conversions.
Now my problem is i have two scenarios for implementing the same : -
1)  Value object will be separate
2)  Value object will be composed within the Form Bean.
Can anyone tell me which is the best strategy out of the two ?



_
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp.


--
To unsubscribe, e-mail:   
For additional commands, e-mail: