On Feb 8, 2008, at 10:08 AM, David Avendasora wrote:
> The Java Annotation Processing Tool (apt) looks cool, but what I
> need to do is insert a portion of one java file into another. apt
> looks like it would do a fine job of creating entirely new files,
> but I don't see how it can insert into an existing file.
>
> I still need to generate the client-side classes from the model,
> and then insert some more stuff in. What I was hoping to do was
> make Velocity treat a "source" java file similar to how it treats a
> model, and then grab things out of it and put them into the
> "target" java file.
Velocity also (AFAIK) generates an entirely new file. Why not just
add a "generation"?
JBNDEOGenericRecord.java -> __YourEntity.java(from the model) ->
_YourEntity.java(from the APT) -> YourEntity.java (final client side
class).
So _YourEntity.java gets generated from the annotated methods in the
server version of YourEntity.java (assuming that is where you are
writing them).
Chuck
> On Feb 8, 2008, at 12:45 PM, Chuck Hill wrote:
>
>>
>> On Feb 8, 2008, at 9:37 AM, David Avendasora wrote:
>>
>>>
>>> On Feb 8, 2008, at 11:43 AM, Mike Schrag wrote:
>>>
>>>>> Is the Velocity engine in WOLips accessible, possibly via Ant?
>>>>>
>>>>> Here's what I'm trying to do: I am working on a Java Client
>>>>> project where the client-side classes have several methods that
>>>>> are exactly the same as the server-side version (Validation,
>>>>> Defaults, etc) and I don't want to maintain them in two places,
>>>>> and using a common subclass for both is not viable because I
>>>>> have to have the client-side and server-side classes need to
>>>>> extend different superclasses.
>>>>>
>>>>> So that leaves me with either duplicating code (and bugs) and
>>>>> dealing with keeping them in sync, or figuring out a way to
>>>>> have the methods automatically synced. This is where velocity
>>>>> comes in.
>>>>>
>>>>> I'd like to flag each "common" method as needing to be copied
>>>>> to the client-side class and then have a Velocity template that
>>>>> would read them out of the server-side and copy them into the
>>>>> client-side _Entity class. I would want to execute this step
>>>>> following any EOGeneration of my client-side .eotemplate files.
>>>>>
>>>>> Again, the end goal is to maintain "common" methods in one
>>>>> location and have them automatically propagated as part of a
>>>>> build.
>>>> It's not accessible from ant, you'd have to wrap it in an ant
>>>> task or something if you want to do that.
>>>>
>>>> However, you can have multiple .eogen files for a single model
>>>> -- you could maybe create a server.eogen and a client.eogen that
>>>> use different templates to do what it is you're trying to do
>>>> (which I'm not sure I exactly follow). Are these common things
>>>> you're copying generated, or are you writing common methods that
>>>> they share? Do server and client share a single _Parent? Can
>>>> you set this up with inheritance hierarchy like the current
>>>> eogen files do, just introducing a third inheritance level with
>>>> your own custom templates?
>>>
>>> These are not generated methods that I want to copy down to the
>>> client classes, They are ones that I write containing specific
>>> validation code, or setting defaults. Potentially I could set
>>> validation rules and defaults in the UserInfo dictionary and then
>>> generate the validation and defaults methods off that, I'll look
>>> into it.
>>>
>>> I already have server-side and client-side EOGen files for my
>>> project and they work well for most typical EOGenerator-type
>>> functions.
>>>
>>> A common class that they both inherit from won't work as the
>>> client classes have to inherit from the JBND EOGenericRecord
>>> class. Besides, I posted questions regarding this in a different
>>> thread (Possible Feature Request...) a couple days ago with no
>>> response from anyone, so I took that as "Nobody's ever done it
>>> before. You're on your own." I since figured out that a common
>>> class really won't work in the first place.
>>
>> I don't think that Velocity is what you want. It just merges a
>> data (e.g. an EOModel) and templates and produces new files. Take
>> a look at Java's Annotation Processing Tool: http://java.sun.com/
>> j2se/1.5.0/docs/guide/apt/GettingStarted.html
>>
>> I think that putting annotations on the comment methods and
>> getting this tool to extract them into another class for you might
>> be a more productive path to wander down.
>>
>> Chuck
>>
>> --
>>
>> Practical WebObjects - for developers who want to increase their
>> overall knowledge of WebObjects or who are trying to solve
>> specific problems.
>> http://www.global-village.net/products/practical_webobjects
>>
>>
>>
>>
>>
>>
>>
>
>
--Practical WebObjects - for developers who want to increase their overall knowledge of WebObjects or who are trying to solve specific problems. http://www.global-village.net/products/practical_webobjects
This archive was generated by hypermail 2.0.0 : Fri Feb 08 2008 - 13:16:20 EST