> let me get this straight. With the new Entity Modeler, you can have
> more Contexts than just Server and Client?!? If so, this is exactly
> what I've been dreaming of but figured it would be too much to ask
> and I'm nowhere nearly competent enough yet to take a stab at it
> myself. My issue is that for my D2JC app (which, amazingly enough
> _does work_ under 5.4.1!) I have some extra D2JC-specific code in
> the client _entity.java files, and when I move to Flor's JBND
> framework eventually, I'll need a completely different set of Client
> classes. I'm not sure how I'm going to deal with that, but if your
> talking about what I think you are, then you've built another bridge
> before I even came to it.
Well, not EXACTLY ... This is a "render context", where "rendering" in
this case means "to generate source code," so the EOModel itself is
unchanged, and your view inside of Entity Modeler is the same. But you
CAN create two sets of eogen files that have different generation
parameters, which would allow you to have different templates for
client and server files, for instance. The render context thing gets
attached to the thread by VelocityEOGenerator and changes the behavior
of various methods that are called on the model. The concept is in
place, though, so we could do other things with it, potentially. I
don't know that it fulfills all your hopes and dreams, but file bugs
for the things you need it to do so at least I'm aware of what you're
looking for in case I run up against something else that might be
solvable generically.
> This would also help build "common" classes that both the server and
> client-side classes inherit from as I could generate ".common."
> classes as well as ".server." and ".client."
Yeah ,you could probably make a common.eogen that generates the common
stuff, then in your templates for the client and server eogen, you
would need to change the superclass of the _File to be the name of the
common non-_File or something like that.
>>> There is also some UI ugliness to the EOGen Editor in that the
>>> header for check-boxes is mislabeled as being for the templates,
>>> which is set in the section above. BUT I have just grabbed the
>>> WOLips source via SVN and was going to look into fixing that
>>> myself, as changing some text is a good place to start as a
>>> contributor (at least for THIS contributor). :) Race ya!
>> I was in there, so i went ahead and fixed this ... Sorry to ruin
>> your fun :)
>
> How's a guy to learn when there's no low-hanging fruit?
EOGeneratorFormPage in the org.objectstyle.wolips.eogenerator.ui.
Eclipse needs click-to-open :) I have NO suggestion as to how to find
this on your own, though. You can Show View=>PDE=>Plugin Registry
View and then search for "EOGenerator" That might narrow down things
some. This is one of Eclipse's biggest problems (same complaint
people have about Wonder) -- it's huge and does tons of stuff, but it
can be hard to find what you're looking for (especially when sometimes
you don't exactly know what question you're trying to ask).
ms
This archive was generated by hypermail 2.0.0 : Tue Mar 04 2008 - 14:59:15 EST