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
