> 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).
all sounds good. one small point - I would argue the post-method doesn't have the data object as an attribute. I might have a look at this in the next few days. cheesr dim > > 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
