We statically generate all the classes during build as you mentioned. We have
a new ant target 'entity-gen' that runs after framework base util entity have
been compiled. It is a custom container that reads the entity model, puts
stuff into a context, then uses an ftl for the template of each the classes.
This generates two artifacts:
- a class for each entity and view-entity in the system.
- a .properties file used by GenericValue.create() to instantiate the correct
class for the entity.
Since our current implementation runs after the entity is loaded, all extending
is done already. Anticipating the next question, as it reads the entire model
and all extends and relations, it will generate a single global map and linking
for entities. (Entity model is global to all applications)
We just use List as a convention, debated just using 's' (like
order.getOrderItems()) which feels normal. We don't worry about the namespace
collision of field X and relation to entity X using the same getX() gettor,
haven't observed it.
So, if you create entity X in your hot-deploy application, it will see X and
generate it along with the base entities... any relations to and from X to base
entities will result in regenerating X and the base entities (not a good thing).
You'd really like to generate the decorator in each application area where the
entities are defined.... so application X would see a class X with
getter/setters and relations as it was defined.
Application Y extends entity X, means that it should see Y's version... likely
could be done with a classpath search order, but behind the scenes, you can
only create a single class X for entity named "X", no matter what application
is using it!
We've side stepped this issue by living with the global generation issue.
NB. Extending means entity-extend AND adding a relation to/from that entity
since gettors will be generated for the getRelated.
Marc Morin
Emforium Group Inc.
ALL-IN Software
519-772-6824 ext 201
mmo...@emforium.com
----- Original Message -----
> Marc Morin wrote:
> > Now it's pretty obvious that many are reading the incorrectly
> > renamed O->R mapping subject and saying it's counter to OFBiz entity
> > model, core philosophy, discussed before... go away you Object
> > lovin' Java developer... ;-)
> >
> > I don't want to repeat the topic, but it is a getter/setter
> > decorator around the Entity/Delegator API that you all love. Not
> > hibernate, not OO persistence...
> >
> > I don't know how anyone can say that the following code is "nicer",
> > "safer", easier to maintain
> >
> > GenericValue order = delegator.findOne("OrderHeader",
> > UtilMisc.toList("orderId", orderId), true);
> > Timestamp entryDate = order.getTimestamp("entryDate");
> > List<GenericValue> orderItems = order.getRelated("OrderItem");
> >
> > vs (evil Object facade, what a Java developer would expect to see,
> > IDE auto-completion, type safety)
> >
> > OrderHeader order = OrderHeader.findOne(delegator,orderId);
> > Timestamp entryDate = order.getEntryDate();
> > List<OrderItem> orderItems = order.getOrderItemList();
>
> Only one suggestion on the api. getOrderItemList should not have a
> list suffix on the method. The type return is defined by the entity
> definition(in this case, 'many'). Plus, once removing the list
> suffix, OrderItem could conflict by name with a field named the same.
> So, in such cases, remove the get prefix. order.OrderItem().
>
> Have you extended the base-line non-typed get() method to support
> relation fetching? So, in groovy, I could do order.entryDate(which is
> possible now), or order.OrderItem(because the first char is capital,
> it would do a relation fetch).
>
> As for those of us that have been resisting, I don't want to be one of
> those. Ofbiz is for a community, and if people want this, then we
> shouldn't really say no. I have moved back and forth several times
> over the years about this.
>
> The interface wouldn't be hard to write. At build type, something
> similar to javacc/jjtree would be run, that would auto-generate a java
> class, based on any entity.
>
> Er, oops, I just found a problem with your idea. How do you handle
> <extend-entity>?
