Well, I was slowly working on this one. As always the quicker the better. So I do not plan to have something working before 2 weeks. So if you plan to do this in a nearest future, I leave it to you and move to quicker stuffs. Vincent.
> -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]] On Behalf > Of Andreas Schaefer > Sent: dimanche 3 f�vrier 2002 3:40 > To: Ara Abrahamian; [EMAIL PROTECTED] > Subject: Re: [Xdoclet-devel] Extended Entity.setData() method > > > Hi Ara > > I like all of the ideas but I would suggest the following > small changes because a user can try to validate the code > before the data is set but maybe want to change or perform > something after the data is set. Therefore I would like to > change the "validate-method" to a: > - method call before the data is set > - method call after the data is set > example: > /** > * ejb:dataobject pre-method="setDataValidation" > * ejb:dataobject post-method="calculateStatistics" > **/ > Both methods must be defined in the Entity Bean and contain > one attribute (the data object). > > Andy > > > No need for validate-exceptions, setData is defined abstract by the > > user in bean impl class with all the required exceptions in > its throws > > statement. The overridden setData will also throw those exceptions. > > Great ! > > > Another options is to allow putting ejb:dataobject in the setData > > method: > > > > /** > > * ejb:dataobject validate-method="setDataValidation" > > */ > > public abstract void setData( MyDataObject d ) throws > > ValidationException; > > > > But here comes an interesting question: why not make > ejb:dataobject a > > method level tag instead of a class level tag? Let user define it > > right there before the getData/setData. This makes it > possible to have > > multiple dataobjects too (or different fine-grained > dataobject classes > > and get/sets): > > > > /** > > * ejb:dataobject validate-method="setDataValidation" > > */ > > public abstract void setData( MyDataObject d ) throws > > ValidationException; > > > > /** > > * ejb:dataobject > > */ > > public abstract TheOtherDataObject getTheOtherDO(); > > public abstract void setTheOtherDO(TheOtherDataObject d ); > > > > xdoclet will then try to guess the dataobject class name > from return > > type of getter or argument of setter. Existing > class/pattern/package > > are still valid (of course in method level context) but will be > > optional, you may only want to use them in cases where you are > > overriding from another bean and another get/setdata which requires > > you to return the dataobject type of the parent method. > > > > Note that the above scenario doesn't mean we'll break compatibility > > with older versions, class level ejb:dataobject will remain as is. > > > > And about "fine-grained dataobject classes", obviously you should > > designate which field belongs to which dataobject class. > This can be > > done with a ejb:dataobject-field tag for the field's getter method: > > > > /** > > * @ejb:persistent-field ... > > * @ejb:dataobject-field name="DataObject1" > > * @ejb:dataobject-field name="DataObject2" > > */ > > public abstract int getId(); > > > > /** > > * ejb:dataobject name="DataObject1" > > */ > > public abstract DataObject1 getDO1(); > > public abstract void setDO1( DataObject1 d ); > > > > /** > > * ejb:dataobject name="DataObject2" > > */ > > public abstract TheOtherDataObject getTheOtherDO(); > > public abstract void setTheOtherDO(TheOtherDataObject d ); > > > > By default all fields are members of all dataobjects but as soon as > > you define one @ejb:dataobject-field you have to specify explicitly. > > I think all of the ideas are great. > > > I think now that you want to enhance it it's good to do it > correctly, > > at least I think it's correct this way ;-) > > I totally aggree. > > > This proposal covers your feature request and also another > request to > > support fine-grained dataobjects, but we can indeed handle > it step by > > setp. > > You always amazes me. > > Andy > > > > > _______________________________________________ > Xdoclet-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/xdoclet-devel > > _______________________________________________ Xdoclet-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xdoclet-devel
