Hi, It should be nice if the lightweight OJB bean could be used directly by the JSP's. (client layer) A possible workaround for the proxy problem : before sending the OJB bean to the client layer 1) replace all non materialized collection proxies by null; 2) replace all materialized collection proxies by a java collection. 3) replace all non materialized reference proxies by null 4) replace all materialized reference proxies by their real subject
Is there an easy way to do this ? Does something like this already exists in Jakarta OJB ? Greetings, Frank Renaers -----Original Message----- From: Max Rydahl Andersen [mailto:[EMAIL PROTECTED]] Sent: vrijdag 11 oktober 2002 10:30 To: OJB Users List Subject: Re: OJB in a model 2 servlet/jsp architecture + proxies Sad, it would have been a very beneficial contribution :( If the code cannot be made available, then how about the "design" ? e.g. how do you describe the graphs and how does the code that uses the "graphing" look like ? /max ----- Original Message ----- From: "Charles Anthony" <[EMAIL PROTECTED]> To: "'OJB Users List'" <[EMAIL PROTECTED]> Sent: Friday, October 11, 2002 9:53 AM Subject: RE: OJB in a model 2 servlet/jsp architecture + proxies > Hi. > > We have a similair architecture, save that we *are* using Value objects to > send to the client, precisely to get over the issue of loading data from the > client (as well as jar dependencies etc). We are calling our Value objects > DTOs (Data Transfer Objects) > > I don't what semi-official "patterns" we are using, but essentially we have > two 'server side' services : > A DTO Graph generator and a DTO Graph persistor. > Given a persitent domain class (i.e. an OJB class that can be persisted) the > graph generator generates a DTO for the given class (and it's relationships, > as specified by a graph-descriptor). > > the Client then modifies an update marker on the DTO (saying whethre they > want to update, or delete the object). > > The DTO Graph persistor essentially synchronises the changes on the DTOs on > the client side with the OJB persistent beans. > > Unfortunately (in the unlikely event that anyone was interested in this) I > won't be able to contribute this code to the project. > > HTH a little bit, > > Cheers, > > Charles. > > >-----Original Message----- > >From: Frank Renaers [mailto:[EMAIL PROTECTED]] > >Sent: 11 October 2002 08:44 > >To: '[EMAIL PROTECTED]'; '[EMAIL PROTECTED]' > >Subject: OJB in a model 2 servlet/jsp architecture + proxies > > > > > >Hi, > > > >I am using a model 2 jsp/servlet architecture. > >Each business service (Facade Pattern) returns one or more > >business objects. > >(i.e. ojb beans). > >I am using here the Value Object Assembler Pattern to return > >the ojb beans. > >Remark : one of the advantages of Jakarta OJB (compared with > >entity beans) > >is that you don't have to create special value objects. > >My view (jsp) will read the necessary values from the ojb beans. > >But suppose that the jsp accesses a proxy collection which is not yet > >materialized. > >This will result in a database call from within my jsp's !!!!! > >Does someone know how to solve this problem ??? > >Which pattern are you using to return 'value objects' to the jsp's ??? > > > >Thanks, > > > >Frank Renaers > > > >-- > >To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > > This email and any attachments are strictly confidential and are intended > solely for the addressee. If you are not the intended recipient you must > not disclose, forward, copy or take any action in reliance on this message > or its attachments. If you have received this email in error please notify > the sender as soon as possible and delete it from your computer systems. > Any views or opinions presented are solely those of the author and do not > necessarily reflect those of HPD Software Limited or its affiliates. > > At present the integrity of email across the internet cannot be guaranteed > and messages sent via this medium are potentially at risk. All liability > is excluded to the extent permitted by law for any claims arising as a re- > sult of the use of this medium to transmit information by or to > HPD Software Limited or its affiliates. > > > > -- > 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]>
