On Mar 4, 2008, at 2:23 PM, Mike Schrag wrote:
>> Ideally yes! That would be awesome!
> OK ... Committed. There's a new construct called an
> EOModelRenderContext that can be attached to the thread to control
> what EOModels will hand you when you query their various formatting
> methods for class names. entity.className will always be the raw
> value, but any of the format-centric (classNameWithDefault,
> classNameWithoutPackage, classNameWithOptionalPackage, etc) will
> hand back context-specific class names. I think I tracked down all
> the various calls to make sure they were going through the correct
> path and not querying className() directly (which they should have
> been doing anyway). Building now ... Check it in 15.
Seriously Mike. I owe you HUGELY.
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.
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."
>
>
>> The old EOGenerator didn't handle Fetch Spec parameters on the
>> client-side either, so I was left with doing a search-and-replace
>> on the client classes to replace ".server." anywhere in the classes
>> with ".client.". It worked, but I had to do it EVERY TIME
>> EOGenerator ran. A real PITA.
> You may already be doing this, but I expect that you would have two
> eogen files. One server.eogen and one client.eogen? You can then
> set the flag in one and not in the other (if that's necessary).
> Both should run on build.
Yes, I have two separate EOGen files as there are _many_ client-side
things that a normal template file won't work for. EOUtilities isn't
even on the client-side so calling FetchSpecifications has to be
handled in a much different way than what most templates account for.
I also have two separate custom EOGenericRecord files, one for server,
one for client side.
>
>
>> 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?
I'd still like to know where the code is. Can you give me a pointer?
Dave
This archive was generated by hypermail 2.0.0 : Tue Mar 04 2008 - 14:41:14 EST