Ideally yes! That would be awesome!
The old (Rubicode) EOModeler had parameters like clientClassName and
such and it looks like Velocity EOGenerator has _some_ like
$entity.clientClassName too, but it would be much more transparent if
the "-javaclient" parameter was checked that it would automatically
just use the EOModel's Client Class property instead - and use the
$EOGenericRecord if null.
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.
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!
Dave
On Mar 4, 2008, at 1:23 PM, Mike Schrag wrote:
>>> Let me also add that this fully qualified class name needs to be
>>> for the client-side class when binding is another Entity from the
>>> EOModel and the -javaclient parameter is passed (Java Client is
>>> checked in the .eogen editor).
>> I don't think velocity eogenerator does anything with -javaclient
>> right now.
> So is it the case that ANYTHING that refers to entity class name
> should be the client class name when -javaclient is set?
>
> ms
>
>
>
This archive was generated by hypermail 2.0.0 : Tue Mar 04 2008 - 13:57:25 EST