On Sat, May 13, 2000 at 11:08:57PM -0500, dave bryson wrote:
> I've started some work on an extension of the GenerateMapBuilderTask
> to build not only the MapBuilder classes but also the Peers and
> Business classes.
Nice one Dave - this is exactly the kind of thing I was thinking of.
Much nicer than the collection of Perl scripts I've got.
> - A Data Object template that contains all the fixed/duplicated code
> that you normally have in a class that extends BaseObject and
> talks to the Peer. This class would include a method such as save().
And get/set methods for the attributes, no?
> For example - public class Project extends ProjectDO
>
> This way, if your schema changes, you can re-generate the Database files
> ( MapBuilders, Peers, and DOs) and not lose that business specific code
> you may have written in the Project class.
> Anyone have any thoughts on this part ?
Yeah - I was thinking of doing it this way as well. The disadvantage is that
the interface onto your business object is split across two classes, making
it harder to consult as a reference. Mind you generate the javadoc and the
DO class is just a click away :)
As my perl scripts are a total hack anyway I've gone for patching the
autogenerated files with context diffs of my business specific additions. But
on balance I think you've chosen the cleaner approach.
> I'm about a 1/4 of the way into this now. But, I wanted to ping the
> group and see if there's anything that I may be missing.
Do you have any plans to handle relations in the generated business objects?
Either along the lines that Jeff mentions (simulating a join in the business
object) or by providing a getXXX method for any associated classes. E.g. to
take another scarab example, can you say something like
Vector components = issue.getComponents();
Where issue is of class IssueDO or a subclass.
Sean
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
