I use a utility called a ValueTreeBuilder to handle part of this 
problem - converting a local interface to a value object graph -
see the attached file - it allows you to specify the branches/leaves
of a tree (graph) of Value objects that are then populated by the
tree builder from a Local interface.

Have a look at the comments in the class for a description of how
to use it.

There are 3 patterns you have to follow to use it :

1. All entities (local interfaces) must have a 'getValueObject()'
   method declared which returns a value object containing all non-CMR
   fields for that entity.

2. You must have an XDoclet Value object defined that includes all
   CMP and CMR fields (or at least all the ones you ever plan to use
   from the tree builder).

   For a bean named XXXBean this value object must be named XXXValue.

   I'm not sure if putting match="*" on your Value object definition
   does this (or is supposed to do this) - the version of XDoclet I'm
   currently working with seems to only create a "light" value object
   when I use match="*" (no CMR fields), so I explicitly tag all fields
   with match="all"...

3. You must have a single primary key field called "id" for the entity.

If you can live with these limitations its quite a handy utility.

Cheers,
Gavin.


-----Original Message-----
From: Marcus Brito [mailto:pazu@;animegaiden.com.br] 
Sent: Tuesday, 12 November 2002 12:35 PM
To: Lista XDoclet-User
Subject: Re: [Xdoclet-user] [v 1.1.2] data-object mixed with localinterfaces?


Em Seg, 2002-11-11 �s 17:12, [EMAIL PROTECTED] escreveu:

> Hello!
> 
> I've just started our migration from home-grown persistence to JBoss 
> CMP, and I've decided to use XDoclet. I'm very impressed and happy, 
> and would like to congratulate everyone on a very nice piece of work!

Thank you :) I hope many people also find xdoclet as nice and useful as you do :)

> I am using Data Transfer Objects (DTOs) (from "Marinescu, EJB Design 
> Patterns"). They are a data-bundle, extending java.lang.Object 
> (usually), and completely stand-alone. Is this the same as a Value 
> Object on this list, or is that another type of entity in XDoclet?

Yes, it's the same concept. We're just using the nomenclature found in "Core J2EE 
Patterns".

> When my DTOs are created, any Container Managed Relationships (CMRs) 
> added to the class use the EJB Local interface in the getter/setters. 
> Doesn't this add an EJB dependency on the DTO objects I would rather 
> not have? Shouldn't the DTO objects be self-standing generic objects? 
> If so, how do I convert the Local interface references to the 
> corresponding DTO reference?

Using xdoclet's VO tags you generate graphs of value objects -- you don't get EJB 
references in value objects. Well, I think it's time to post my small VO-HOWTO to 
public review :)

> Also, I would like to have a Factory class that takes a DTO object and 
> converts it to a Local object, and vice versa, and contains methods 
> for all DTOs in my system. Is there now a way to have this static 
> final Factory class generated by XDoclet? Would this be a good thing?

This isn't currently possible with the bundled templates. Of course, you could write 
your own templates to generate this. That's the True Power of XDoclet. ^_^

As a side note, we're currently discussing the generation of value objects through a 
Value Object Factory -- the same pattern exposed in "Core J2EE Patterns". I'm 
particularly interested is tackling this is some not-too-distant future -- I just need 
to breath a little at work.

-- 
Pazu <[EMAIL PROTECTED]>

Anime Gaiden - de fãs para fãs, sempre. http://www.animegaiden.com.br

Attachment: ValueTreeBuilder.java
Description: ValueTreeBuilder.java

Reply via email to