OK, so your formBean would be called via <use bean. And the form bean would have some method to do the rest of persistence or populating?
OK. That is kid of what I was driving to. One deals with beans. Beans have technology designs (patters) ... but they are there to do bus. requirements (your problem/bus domain patterns/solutions) .V (of course Model 2 is better) [EMAIL PROTECTED] wrote: > > > Model 1? I assume you're referring to the practice of posting directly to a > jsp page instead of through an Action servlet - the "model 1" that was > proposed in the original JSP 0.92 spec. > > (For those who haven't reviewed it, the JSP 0.92 specificiation was the > first place I believe the terms 'Model 1' and 'Model 2' originated. At > least that's the earliest I remember seeing it. Here's a link to an old > copy of it: http://www.kirkdorffer.com/jspspecs/jsp092.html . It still > provides one of the best explanations of the difference between Model 1 and > Model 2 that I've come across.). > > Not sure. I'd suppose you'd create a bean (and access it using a classic > jsp:usebean) that is essentially your 'Model' component. This would have to > be the equivalent of the 'Form Bean'. > > You set all the properties on this 'form bean' (using a scriptlet > potentially) and then execute some method on it that would invoke this > whole back-end process. (there are other potential ways of doing it - this > is just one.) The facade and the other statements would be invoked from > your bean. Once this processing was done, you could either extract > properties from the same bean to populate the 'View', or you could extract > another bean (that was a Value Object) from the first bean and drive the > display results from it. > > This actually demonstrates the strength of Struts - the model 1 solution is > more complex lends itself to embedding scriptlets faster. Also, a big > problem is what do you do when things go wrong communicating to the back > end? In Model 1, you have to trap the error and do a jsp:forward or just > put conditional processing in the JSP directly - using Struts you simply > catch the exception and forward to a different ActionForward. > > Kevin > > > > > > > > > > "V. Cekvenich" <[EMAIL PROTECTED]>@main.gmane.org> on 10/15/2002 > 08:43:46 AM > > Please respond to "Struts Users Mailing List" > <[EMAIL PROTECTED]> > > Sent by: news <[EMAIL PROTECTED]> > > > To: [EMAIL PROTECTED] > cc: (bcc: Kevin Bedell/Systems/USHO/SunLife) > Subject: Re: DAO or ... ? [Scanned for known viruses] > > > Q: How would you re-use this in Model 1? > > .V > > > > [EMAIL PROTECTED] wrote: > >> >> >>James - >> >>I've attached a few files from my upcoming book Struts Kick Start that >>provide a basic design pattern that sounds like it may be similar to what >>your describing. >> >>What I do is: >> >> - Create a Value Object that encapsulates data communicated with the > > Model > >>component. >> >> - Create a facade class that accepts and returns value objects through >>'business methods'. By defining the facade to work at a 'business method' >>level, it helps keep any code related to a particular persistence layer > > or > >>back-end system out of the Action class. This also addresses the issues > > you > >>described of 'designing to test' - the clean seperation between the > > Action > >>class and the Model components that the Facade provides simplifies > > testing. > >> - Create the form bean to provide set/get methods that also accept and >>return value objects - this greatly simplifies the Action class and >>isolates it from changes. >> >>The Action class (a bit simplified - I've taken out detailed comments and >>exception handling) goes something like: >> >> // cast the form bean >> CustomerForm cf = (CustomerForm) form; >> >> // Create a facade to interface to the back-end system >> CustomerWSFacade facade = new CustomerWSFacade(); >> >> // Extract the value object from the form bean >> CustomerValueObject cvo = cf.getValueObject(); >> >> // Pass the value object to the facade. It returns an update value > > object > >> cvo = facade.addressChange( cvo ); >> >> // Use the returned value object to update the values in the form > > bean. > >> cf.setValueObject(cvo); >> >>These particular classes come from the chapter on providing integration >>with Axis for Web Services. Another chapter uses the identical set of >>classes to communicate with JBoss using a Session Bean - all I did was >>write a different facade class. The point of this was to demonstrate a >>design that made it very simple to perform maintenance or changes on the >>back-end or persistence layer. >> >> >> >>Regarding testing - I'd recommend you take a look at the StrutsTestCase >>project at sourceforge - it provides some great templates for both JUnit >>and Cactus tests that are designed for Struts. Makes JUnit/Cactus testing >>pretty straightforward. A copy of this and detailed directions also come >>with the book. >> >> http://strutstestcase.sourceforge.net/ >> >> >>Best of luck - >>Kevin >> >> >>Author, Struts Kick Start >> >>(See attached file: customer.zip) >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >>"Couball, James" <[EMAIL PROTECTED]> on 10/14/2002 01:19:16 > > PM > >>Please respond to "Struts Users Mailing List" >> <[EMAIL PROTECTED]> >> >>To: "'Struts Users Mailing List'" <[EMAIL PROTECTED]> >>cc: (bcc: Kevin Bedell/Systems/USHO/SunLife) >>Subject: RE: DAO or ... ? >> >> >>I recommend taking a look at the Session Façade pattern in the Java Blue >>Prints. No matter if you use EJBs or not, this pattern encapsulates the >>ideas that Simon was mentioning. >> >>Does anyone know the name of the more general pattern that doesn't > > involve > >>Session Beans specifically? >> >>One of my general concerns is "design to test". I like to be able to > > test > >>the (business/persistence) layer that the actions will call independently >>of >>struts, actions, etc. Encapsulating that layer in an API (or wrapping > > with > >>a session bean) makes this possible. >> >>Sincerely, >>James. >> >> >> >>>-----Original Message----- >>>From: Andrew Hill [mailto:[EMAIL PROTECTED]] >>>Sent: Monday, October 14, 2002 8:16 AM >>>To: Struts Users Mailing List >>>Subject: RE: DAO or ... ? >>> >>>But you still call the API from the action right - is this not invoking >>>the >>>functionality that persists your data? >>> >>>Seems a bit like semantic juggling to me... (after all the persistance >>>layer >>>is just an abstraction API on top of writing to db/disk/punchcard >>>itself...) >>>;-) >>> >>>I would however agree that there ought to be some sort of abstracting >>>layer >>>between the view and the implementation specific details of the p-tier... >>> >>>-----Original Message----- >>>From: Chappell, Simon P [mailto:[EMAIL PROTECTED]] >>>Sent: Monday, October 14, 2002 23:04 >>>To: Struts Users Mailing List; [EMAIL PROTECTED] >>>Subject: RE: DAO or ... ? >>> >>> >>>You invoke your persistence code in the same place that you would invoke >>>any >>>other code ... not in the Action! >>> >>>Write all your core application code (business rules, persistence, >>>communications etc) in a way that has no connection to the view portion >> >>of >> >> >>>your system and then create a API to it. This way you can have any client >>>you like call into your core code and your core code doesn't need to >> >>worry >> >> >>>about what calls it, only about acting upon requests. >>> >>>Then use the actions to call into the API and pass the API return values >>>to >>>the JSPs. Works great. >>> >>>/------\ /---\ /----\ >>>|Client|--> |API|-->|Core| >>>|Code | | | |Code| >>>\------/ \---/ \----/ >>> >>>The API is now your fire break. Nothing on the Core Code side has to >> >>worry >> >> >>>about displaying anything and nothing in the Client Code has to worry >>>about >>>calculating anything. >>> >>>Simon >>> >>>----------------------------------------------------------------- >>>Simon P. Chappell [EMAIL PROTECTED] >>>Java Programming Specialist www.landsend.com >>>Lands' End, Inc. (608) 935-4526 >>> >>> >>> >>> >>>>-----Original Message----- >>>>From: Andrew Hill [mailto:[EMAIL PROTECTED]] >>>>Sent: Monday, October 14, 2002 9:57 AM >>>>To: Struts Users Mailing List >>>>Subject: RE: DAO or ... ? >>>> >>>> >>>>So where should one invoke the persistance layer? >>>> >>>>-----Original Message----- >>>>From: Lacerda, Wellington (AFIS) [mailto:[EMAIL PROTECTED]] >>>>Sent: Monday, October 14, 2002 22:51 >>>>To: 'Struts Users Mailing List' >>>>Subject: RE: DAO or ... ? >>>>Importance: High >>>> >>>> >>>>Hi Kevin >>>> >>>>Avoid persistence in Action code as much as you can. >>>> >>>>This is the general recommendation. >>>> >>>>Wellington Silva >>>>Author of "JSP and Tag Libraries for Web Development" >>>>FAO of the UN - Consultant >>>> >>>>-----Original Message----- >>>>From: Kevin Viet [mailto:[EMAIL PROTECTED]] >>>>Sent: Monday, October 14, 2002 4:45 PM >>>>To: struts-user >>>>Subject: DAO or ... ? >>>> >>>> >>>>My question is a web app design question. >>>>What pattern you guys follow when you want to save a domain object in >>>>the database ?: >>>> >>>>- use the DAO pattern of java blueprint (persistence layer is called >>>>into classes) >>>>- call to persistence statements into action code : >>>> >>>> // store example >>>> try { >>>> PeristenceLayer pl = getPerstitenceLayer(); >>>> pl.save(domainObject); >>>> } >>>> catch (Exception >>>> >>>> >>>>-- >>>>Kevin Viet <[EMAIL PROTECTED]> >>>>ActiVia Networks >>>> >>>> >>>> >>>> >>>>-- >>>>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]> >>> >>> >>>-- >>>To unsubscribe, e-mail: >>><mailto:[EMAIL PROTECTED]> >>>For additional commands, e-mail: >>><mailto:[EMAIL PROTECTED]> >>> >>> >>>-- >>>To unsubscribe, e-mail: <mailto:struts-user- >>>[EMAIL PROTECTED]> >>>For additional commands, e-mail: <mailto:struts-user- >>>[EMAIL PROTECTED]> >> >> >>-- >>To unsubscribe, e-mail: < >>mailto:[EMAIL PROTECTED]> >>For additional commands, e-mail: < >>mailto:[EMAIL PROTECTED]> >> >> >> >> >> >> >> >> > --------------------------------------------------------------------------- > >>This e-mail message (including attachments, if any) is intended for the > > use > >>of the individual or entity to which it is addressed and may contain >>information that is privileged, proprietary , confidential and exempt > > from > >>disclosure. If you are not the intended recipient, you are notified that >>any dissemination, distribution or copying of this communication is >>strictly prohibited. If you have received this communication in error, >>please notify the sender and erase this e-mail message immediately. >> > > --------------------------------------------------------------------------- > >> >>------------------------------------------------------------------------ >> >>-- >>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]> > > > > > --------------------------------------------------------------------------- > This e-mail message (including attachments, if any) is intended for the use > of the individual or entity to which it is addressed and may contain > information that is privileged, proprietary , confidential and exempt from > disclosure. If you are not the intended recipient, you are notified that > any dissemination, distribution or copying of this communication is > strictly prohibited. If you have received this communication in error, > please notify the sender and erase this e-mail message immediately. > --------------------------------------------------------------------------- -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
