> Baby? Congrats!
>
> Do you think this piece is easy enough that someone without experience
> with the internals could take it on?
It's a bit of a loaded problem. Because we maintain a separate
EOModel stack (previously for legal reasons, although that part has
MOSTLY been worked out now) and at the moment because our
implementation is tweaked for IDE's and has lots of code that depends
on these new tweaked behaviors, it turns out that one of the things
that never got written was EOQualifier clones. Currently Entity
Modeler actually uses Cayenne Expressions internally, which are MOSTLY
EOQualifiers, but not exactly. To provide Velocity support for binding
variables for fetch specs, you need to be able to relatively easily
traverse the variables of a fetch spec, but I really didn't want to
write all of that continuing to build in dependencies on Expressions
-- the code is great for it, but it's just not EOQ, and the more EM
grows, the trickier it will be to have that slight mismatch.
Additionally, the Expression API is mostly generated code, and it's a
little hard to navigate (for me, at least) in Velocity. Recently I
write EOQ's for modeler, though it's not hooked into the mainline
(fears of breaking models until I test it more) ... This was step one
to providing easier support for exposing binding variables. If it
works out, which it is looking pretty good so far, then I will switch
EM over to this API (which peers pretty well against the real EOQ) at
which point it should be pretty easy to hook into Velocity to do what
you guys want to do. So anyway, it's a loaded problem because what
you ACTUALLY want (i.e. the final result) is pretty easy, but there's
a bit of a pile of junk in the middle to wade through to get there.
On the plus side, it's almost entirely a model-level problem as the UI
currently interacts with these API's essentially as strings (because
EM is crappy for qualifier editing -- yay for crappiness).
ms
This archive was generated by hypermail 2.0.0 : Fri Dec 21 2007 - 15:23:19 EST