You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@turbine.apache.org by Robert Jenks <rj...@animefest.org> on 2001/11/30 04:04:57 UTC
Question about OM classes
Hi, newbee here :-) I went back 3 months of list archives and couldn't find
a mention of this, but I'll apologize in advance if it's been discussed
before.
Playing around with Torque (cool stuff dudes!) and have a question about
the OM generated classes. I prefer to keep my auto-generated and human
generated source files in separate directory trees, therefore I modified the
om/Control.vm template and commented out the calls to ExtensionObject and
ExtensionPeer so that the skeleton sub-classes don't get generated. I'll
simply write them myself in a separate directory tree and compile both
directory trees together.
All is fine and dandy until I find that the Base classes won't compile
without the sub-classes. Is there a reason that BaseFooEntity has multiple
references to it's sub-class (FooEntity) or is this a template bug? This
seems to be true of all the Base classes. They all depend on their skeleton
sub-classes.
Thanks,
-Robert
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Question about OM classes
Posted by John McNally <jm...@collab.net>.
The way i consider it the two classes make up one object. Not perfect
oo design, but if you think of BaseFoo.java as just a place to store
methods available for use in Foo.class, maybe it is more tolerable?
john mcnally
Robert Jenks wrote:
>
> > The BaseFoo and Foo classes are designed so that they both have to be
> > present. The BaseFoo class is contains code that can be regenerated and
> > any modifications should be made to Foo. One case for referencing Foo
> > in BaseFoo is when instantiating a new Foo as happens in the copy
> > method. BaseFoo is abstract as there should not be any instances of
> > BaseFoo.
> >
> > If you want to create a separate package, just extend from Foo in the
> > new package. Though I do not see the reason for doing so.
> >
> > john mcnally
>
> I'm not actually going to extend it in another package, just in another
> directory tree so that my auto-generated Java classes are kept separate from
> my editable classes. It just seems like a violation of OO principals for a
> base class to depend on it's sub class, that's all. Typically if a base
> class needs to manipulate sub-classes it does so using factory methods and
> not direct references. Again, I'm not suggesting that this is horribly
> evil, just that it seems odd and maybe isn't necessary.
>
> -Robert
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Question about OM classes
Posted by Eric Dobbs <er...@dobbse.net>.
On Friday, November 30, 2001, at 08:25 PM, Robert Jenks wrote:
>> If you want to create a separate package, just extend from Foo in the
>> new package. Though I do not see the reason for doing so.
>>
>> john mcnally
>
> I'm not actually going to extend it in another package, just in another
> directory tree so that my auto-generated Java classes are kept separate
> from
> my editable classes.
I think that Scarab (http://scarab.tigris.org) stores the
BaseFoo in separate directories from the Foo. I glanced
through the source and it looks like that his handled
with ant in the build.xml files. After the object model
is generated there's a filter to copy the Base*.java files
to a different directory.
Probably easier than rewriting the subclasses from scratch
and would probably solve your compiling problems.
-Eric
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Question about OM classes
Posted by Robert Jenks <rj...@cvsroot.org>.
> The BaseFoo and Foo classes are designed so that they both have to be
> present. The BaseFoo class is contains code that can be regenerated and
> any modifications should be made to Foo. One case for referencing Foo
> in BaseFoo is when instantiating a new Foo as happens in the copy
> method. BaseFoo is abstract as there should not be any instances of
> BaseFoo.
>
> If you want to create a separate package, just extend from Foo in the
> new package. Though I do not see the reason for doing so.
>
> john mcnally
I'm not actually going to extend it in another package, just in another
directory tree so that my auto-generated Java classes are kept separate from
my editable classes. It just seems like a violation of OO principals for a
base class to depend on it's sub class, that's all. Typically if a base
class needs to manipulate sub-classes it does so using factory methods and
not direct references. Again, I'm not suggesting that this is horribly
evil, just that it seems odd and maybe isn't necessary.
-Robert
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Question about OM classes
Posted by John McNally <jm...@collab.net>.
The BaseFoo and Foo classes are designed so that they both have to be
present. The BaseFoo class is contains code that can be regenerated and
any modifications should be made to Foo. One case for referencing Foo
in BaseFoo is when instantiating a new Foo as happens in the copy
method. BaseFoo is abstract as there should not be any instances of
BaseFoo.
If you want to create a separate package, just extend from Foo in the
new package. Though I do not see the reason for doing so.
john mcnally
Robert Jenks wrote:
>
> Hi, newbee here :-) I went back 3 months of list archives and couldn't find
> a mention of this, but I'll apologize in advance if it's been discussed
> before.
>
> Playing around with Torque (cool stuff dudes!) and have a question about
> the OM generated classes. I prefer to keep my auto-generated and human
> generated source files in separate directory trees, therefore I modified the
> om/Control.vm template and commented out the calls to ExtensionObject and
> ExtensionPeer so that the skeleton sub-classes don't get generated. I'll
> simply write them myself in a separate directory tree and compile both
> directory trees together.
>
> All is fine and dandy until I find that the Base classes won't compile
> without the sub-classes. Is there a reason that BaseFooEntity has multiple
> references to it's sub-class (FooEntity) or is this a template bug? This
> seems to be true of all the Base classes. They all depend on their skeleton
> sub-classes.
>
> Thanks,
> -Robert
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>