Menu
▾
▴
AW: [Andromda-devel] changes for hibernate entity inheritance
|
From: <inf...@mb...> - 2003-12-15 11:01:06
|
Hi Brian,
there must be a misunderstanding here. The ScriptHelper is the object that
you access in a Velocity script as "$transform" - it sits between the
Velocity template and the JMI-based API for the UML metamodel, just like a
business object sits between the GUI and the database access classes,
right?
The ScriptHelper has nothing to do with objects like 'date', 'model', and
'str' - these are only registered in the Velocity context which is nothing
but a smarter HashMap. When you write
"$transform.findSuperclass($class).name", Velocity expands this to
context.get("transform").findSuperclass(context.get("class")).getName()
So, it would make sense to define a method
Classifier findSuperclass(Classifier) {
// navigate using Generalization...
// return a PClassifier object
}
in your own ScriptHelper class. This need not be in the ScriptHelper
interface because Velocity uses reflection to call the methods on Java
objects.
Cheers...
Matthias
--- Urspr=FCngliche Nachricht ---
Datum: 15.12.2003 04:21
Von: "Brian Topping" <to...@bi...>
An: "Matthias Bohlen" <inf...@mb...>
Betreff: RE: [Andromda-devel] changes for hibernate entity inheritance
> Hmm, okay, taking a closer look at this now since I am adding some more
> features.
>
> I like the idea of this, but it falls a bit short in practice. If the
> calculation of the superclass is going to happen in the ScriptHelper,
it
> needs to know what the modelElement is. As best I can tell, it does
not, it
> just simply knows the model.
>
> It seems like 'date', 'model', and 'str' are static and therefore
better
> candidates to go into the ScriptHelper, but doing so would make the
templates
> more verbose than necessary. It may also be that the ScriptHelper
should
> have access to get the current modelElement.
>
> It would be nice to structure the code in a way that AndroMDAGenTask
doesn't
> require changes when the velocity context is augmented. Maybe the
individual
> helpers should be responsible for setting up the context by moving the
> context setup code into the ScriptHelper interface. As well, by making
the
> ScriptHelper responsible for the context setup, it could cache the
current
> modelElement if appropriate.
>
> -b
>
> > -----Original Message-----
> > From: Matthias Bohlen [mailto:inf...@mb...]
> > Sent: Friday, December 12, 2003 9:57 AM
> > To: Brian Topping; and...@li...
> > Subject: RE: [Andromda-devel] changes for hibernate entity
inheritance
> >
> >
> > Hi Brian,
> >
> > > Smells like a gross hack to me...
> >
> > Yes, indeed, it's a hack. :-) A "clean" way to do it is to add
another
> > method findSuperclass(Classifier) to SimpleOOHelper. Inside
> > the Velocity
> > script, you could then write: $transform.findSuperclass($class).
> >
> > Sounds better, doesn't it? :-)
> >
> > In AndroMDA 3.x with metamodel decorators, you will simply write:
> > $class.superclass - that's it.
> >
> > Cheers...
> > Matthias
> >
> > > -----Original Message-----
> > > From: and...@li...
> > > [mailto:and...@li...] On Behalf
> > > Of Brian Topping
> > > Sent: Thursday, December 11, 2003 11:33 PM
> > > To: and...@li...
> > > Subject: [Andromda-devel] changes for hibernate entity inheritance
> > >
> > >
> > > I'm working with hibernate and have been wanting to have
> > > AndroMDA generate classes of the form:
> > >
> > > // the superclass does not use @hibernate.class
> > > public abstract Superclass {
> > > /** @hibernate.id ... */
> > > ....
> > > }
> > >
> > > /** @hibernate.class */
> > > public Subclass extends Superclass {
> > > // id is inherited from superclass
> > > ....
> > > }
> > >
> > > This works great for Hibernate and XDoclet, but AndroMDA
> > > 2.1.1 doesn't deal with inheritance. So I added the
> > following code to
> > > AndroMDAGenTask.processModelElementWithOneTemplate():
> > >
> > > ...
> > > velocityContext.put("class", modelElement);
> > > // new code
> > > if (modelElement instanceof Classifier) {
> > > String superTypes =3D null;
> > > for (Iterator it =3D ((Classifier)
> > > modelElement).getGeneralization().iterator();
> > > it.hasNext();) {
> > > Generalization g =3D (Generalization) it.next();
> > > if (superTypes =3D=3D null) {
> > > superTypes =3D g.getParent().getName();
> > > } else {
> > > // this should never get hit with a class. Does
> > > Classifier map to a Java
> > > // class, or is it a super of both interface and class?
> > > superTypes +=3D ","+g.getParent().getName();
> > > }
> > > }
> > > velocityContext.put("supertypes", superTypes);
> > > }
> > > ...
> > >
> > > Smells like a gross hack to me (the Velocity context would
> > > get pretty cluttered pretty quick), but maybe I'm being too
> > > hard on myself. Any Velocity pros want to comment?
> > >
> > > Anyway, I have these additions if anyone is interested, there
> > > may be more to come.
> > >
> > > thanks,
> > >
> > > -b
> > >
> > >
> > > -------------------------------------------------------
> > > This SF.net email is sponsored by: SF.net Giveback Program.
> > > Does SourceForge.net help you be more productive? Does it
> > > help you create better code? SHARE THE LOVE, and help us
> > > help YOU! Click Here: http://sourceforge.net/donate/
> > > _______________________________________________
> > > Andromda-devel mailing list And...@li...
> > > https://lists.sourceforge.net/lists/listinfo/andromda-devel
> > >
> > >
> >
> >
> >
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive? Does it
> help you create better code? SHARE THE LOVE, and help us help
> YOU! Click Here: http://sourceforge.net/donate/
> _______________________________________________
> Andromda-devel mailing list
> And...@li...
> https://lists.sourceforge.net/lists/listinfo/andromda-devel
>
>
|