You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@ofbiz.apache.org by "Michael Xu (xudong)" <do...@wizitsoft.com> on 2009/10/15 23:16:53 UTC
about entity engine
hi all,
We can define entities in XML files. However, only database specific
semantics could be defined there. For those application level semantics
(like trigger, visiblity, validation) has to be defined in different places.
The lack of a single place to define such metadata makes ofbiz hard to
maintain. (Correct me if I am wrong)
Let's take OrderHeader as an example. I copy the latest entity definition as
below:
<entity entity-name="OrderHeader"
package-name="org.ofbiz.order.order"
never-cache="true"
title="Order Header Entity">
<field name="orderId" type="id-ne"></field>
<field name="orderTypeId" type="id"></field>
<field name="orderName" type="name"></field>
<field name="externalId" type="id"></field>
<field name="salesChannelEnumId" type="id"></field>
<field name="orderDate" type="date-time"></field>
<field name="entryDate" type="date-time"></field>
<field name="visitId" type="id"></field>
<field name="statusId" type="id"></field>
<field name="createdBy" type="id-vlong"></field>
<field name="firstAttemptOrderId" type="id"></field>
<field name="currencyUom" type="id"></field>
<field name="syncStatusId" type="id"></field>
<field name="billingAccountId" type="id"></field>
<field name="originFacilityId" type="id"></field>
<field name="webSiteId" type="id"></field>
<field name="productStoreId" type="id"></field>
<field name="terminalId" type="id-long"></field>
<field name="transactionId" type="id-long"></field>
<field name="autoOrderShoppingListId" type="id"></field>
<field name="needsInventoryIssuance" type="indicator"></field>
<field name="isRushOrder" type="indicator"></field>
<field name="internalCode" type="id-long"></field>
<field name="remainingSubTotal" type="currency-amount"></field>
<field name="grandTotal" type="currency-amount"></field>
<prim-key field="orderId"/>
<relation type="one" fk-name="ORDER_HDR_TYPE"
rel-entity-name="OrderType">
<key-map field-name="orderTypeId"/>
</relation>
<relation type="one" fk-name="ORDER_HDR_SCENUM" title="SalesChannel"
rel-entity-name="Enumeration">
<key-map field-name="salesChannelEnumId" rel-field-name="enumId"/>
</relation>
<relation type="one" fk-name="ORDER_HDR_OFAC" title="Origin"
rel-entity-name="Facility">
<key-map field-name="originFacilityId" rel-field-name="facilityId"/>
</relation>
<relation type="many" rel-entity-name="OrderTypeAttr">
<key-map field-name="orderTypeId"/>
</relation>
<relation type="one" fk-name="ORDER_HDR_BACCT"
rel-entity-name="BillingAccount">
<key-map field-name="billingAccountId"/>
</relation>
<relation type="one" fk-name="ORDER_HDR_PDSTR"
rel-entity-name="ProductStore">
<key-map field-name="productStoreId"/>
</relation>
<relation type="one" fk-name="ORDER_HDR_AOSHLST" title="AutoOrder"
rel-entity-name="ShoppingList">
<key-map field-name="autoOrderShoppingListId"
rel-field-name="shoppingListId"/>
</relation>
<relation type="one" fk-name="ORDER_HDR_CBUL" title="CreatedBy"
rel-entity-name="UserLogin">
<key-map field-name="createdBy" rel-field-name="userLoginId"/>
</relation>
<relation type="one" fk-name="ORDER_HDR_STTS"
rel-entity-name="StatusItem">
<key-map field-name="statusId"/>
</relation>
<relation type="one" fk-name="ORDER_HDR_SYST" title="Sync"
rel-entity-name="StatusItem">
<key-map field-name="syncStatusId" rel-field-name="statusId"/>
</relation>
<relation type="one" fk-name="ORDER_HDR_CUOM" rel-entity-name="Uom">
<key-map field-name="currencyUom" rel-field-name="uomId"/>
</relation>
<relation type="many" rel-entity-name="OrderHeaderNoteView">
<key-map field-name="orderId"/>
</relation>
<relation type="many" rel-entity-name="OrderItemAndShipGroupAssoc">
<key-map field-name="orderId"/>
</relation>
<index name="ORDEREXT_ID_IDX">
<index-field name="externalId"/>
</index>
</entity>
In order to enrich the definition (metadata) with more information, I am
considering to put more tags (please find elements surrounded with
!!!!!!!!!!!!!!!!!!!!!), like:
<entity entity-name="OrderHeader"
package-name="org.ofbiz.order.order"
never-cache="true"
title="Order Header Entity">
<field name="orderId" type="id-ne"></field>
<field name="orderTypeId" type="id"></field>
<field name="orderName" type="name"></field>
<!- !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
<field name="externalId" type="id">
<!-
We can use "visiblity" tag to tell system when to show this
field in UI layer.
->
<visbility>
<condition
implementation="org.ofbiz.core.condition.NonEmptyField"/>
</visbility>
<validity type="clientSide">
<condition notEqual="111"/>
</validity>
</field>
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! ->
<field name="salesChannelEnumId" type="id"></field>
<field name="orderDate" type="date-time"></field>
<field name="entryDate" type="date-time"></field>
<field name="visitId" type="id"></field>
<field name="statusId" type="id"></field>
<field name="createdBy" type="id-vlong"></field>
<field name="firstAttemptOrderId" type="id"></field>
<field name="currencyUom" type="id"></field>
<field name="syncStatusId" type="id"></field>
<field name="billingAccountId" type="id"></field>
<field name="originFacilityId" type="id"></field>
<field name="webSiteId" type="id"></field>
<field name="productStoreId" type="id"></field>
<field name="terminalId" type="id-long"></field>
<field name="transactionId" type="id-long"></field>
<field name="autoOrderShoppingListId" type="id"></field>
<field name="needsInventoryIssuance" type="indicator"></field>
<field name="isRushOrder" type="indicator"></field>
<field name="internalCode" type="id-long"></field>
<field name="remainingSubTotal" type="currency-amount"></field>
<field name="grandTotal" type="currency-amount"></field>
<prim-key field="orderId"/>
<relation type="one" fk-name="ORDER_HDR_TYPE"
rel-entity-name="OrderType">
<key-map field-name="orderTypeId"/>
</relation>
<relation type="one" fk-name="ORDER_HDR_SCENUM" title="SalesChannel"
rel-entity-name="Enumeration">
<key-map field-name="salesChannelEnumId" rel-field-name="enumId"/>
</relation>
<relation type="one" fk-name="ORDER_HDR_OFAC" title="Origin"
rel-entity-name="Facility">
<key-map field-name="originFacilityId" rel-field-name="facilityId"/>
</relation>
<relation type="many" rel-entity-name="OrderTypeAttr">
<key-map field-name="orderTypeId"/>
</relation>
<relation type="one" fk-name="ORDER_HDR_BACCT"
rel-entity-name="BillingAccount">
<key-map field-name="billingAccountId"/>
</relation>
<relation type="one" fk-name="ORDER_HDR_PDSTR"
rel-entity-name="ProductStore">
<key-map field-name="productStoreId"/>
</relation>
<relation type="one" fk-name="ORDER_HDR_AOSHLST" title="AutoOrder"
rel-entity-name="ShoppingList">
<key-map field-name="autoOrderShoppingListId"
rel-field-name="shoppingListId"/>
</relation>
<relation type="one" fk-name="ORDER_HDR_CBUL" title="CreatedBy"
rel-entity-name="UserLogin">
<key-map field-name="createdBy" rel-field-name="userLoginId"/>
</relation>
<relation type="one" fk-name="ORDER_HDR_STTS"
rel-entity-name="StatusItem">
<key-map field-name="statusId"/>
</relation>
<relation type="one" fk-name="ORDER_HDR_SYST" title="Sync"
rel-entity-name="StatusItem">
<key-map field-name="syncStatusId" rel-field-name="statusId"/>
</relation>
<relation type="one" fk-name="ORDER_HDR_CUOM" rel-entity-name="Uom">
<key-map field-name="currencyUom" rel-field-name="uomId"/>
</relation>
<relation type="many" rel-entity-name="OrderHeaderNoteView">
<key-map field-name="orderId"/>
</relation>
<relation type="many" rel-entity-name="OrderItemAndShipGroupAssoc">
<key-map field-name="orderId"/>
</relation>
<index name="ORDEREXT_ID_IDX">
<index-field name="externalId"/>
</index>
<!- !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
<!-
In different context, maybe different set of fields need to show.
So my idea
here is to use "group" to group fields for different scenario. And
then in UI
level, we can define a jsp tag or something to only show fields
within this group.
->
<group name="summary">
<field name="orderId" rank="1"/>
<field name="orderTypeId" rank="10"/>
<field name="orderName" rank="11"/>
</group>
<group name="details">
<field name="orderId" rank="1"/>
<field name="orderTypeId" rank="10"/>
<field name="orderName" rank="11"/>
<field name="externalId" rank="20">
<!-
!!!!Note: Though visibility is definded above with another
condition. However, in this group
(Scenario), externalID will always be visible.
->
<visbility value="true"/>
<field>
</group>
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!->
</entity>
Such an idea to make entity definition as a single point of
configuration/customization might make system easier to maintain/customize.
Am I right? If yes, anybody could suggest me how to implement it.
(BTW: we are going to use ofbiz entity engine for our products just like
what JIRA did. It would be great if such enhancement could be done direct
under apache. Otherwise, we might have to maintain a customized ofbiz entity
engine by ourselves.)
--
Regards,
Michael Xu (xudong)
www.wizitsoft.com | Office: (8610) 6267 0615 ext 806 | Mobile: (86) 135 0135
9807 | Fax: (8610) 62670096
Re: about entity engine
Posted by Raul Sieberath <of...@sieberath.com>.
Hi Michael,
The idea is great and I also agree that UI should not mix with data.
Maybe your idea can go in another place. For example, a
<extension-entity> or <ui-entity> tag place in another file. The widgets
could use the extension information if available.
I have had the necessity to use this kind of configuration in past
projects and the idea should not be throw away.
My half cent.
Regards,
Raul
On Fri, 2009-10-16 at 17:28 +0800, Michael Xu (xudong) wrote:
> hi Bruno,
>
> Thanks for your explanation.
>
> Really look forward to the XML driven widgets.
>
> --
> Regards,
> Michael Xu (xudong)
> www.wizitsoft.com | Office: (8610) 6267 0615 ext 806 | Mobile: (86) 135 0135
> 9807 | Fax: (8610) 62670096
>
>
> On Fri, Oct 16, 2009 at 3:13 PM, Bruno Busco <br...@gmail.com> wrote:
>
> > Hi Michael,
> > actually OFBiz offers the possibility of designing UI without knowing
> > the java language.
> > There are powerfull widgets that are being developed further day by
> > day to let you design UI using XML.
> > There is a minilanguage that lets you collect and prepare de data to
> > be presented using XML.
> >
> > Very often it is necessary to group in a single screen data coming
> > from different entities and this would be even more difficult to be
> > described in the entity itself.
> >
> > More generally the model you propose puts toghether the database layer
> > and the presentation layer that we always try to keep separated.
> >
> > My two cents,
> > Bruno
> >
> > 2009/10/16 Michael Xu (xudong) <do...@wizitsoft.com>:
> > > BTW, I think My idea can be implemented in a backword compatible way. So
> > at
> > > least that will be another choice to implement new ofbiz applications.
> > >
> > > --
> > > Regards,
> > > Michael Xu (xudong)
> > > www.wizitsoft.com | Office: (8610) 6267 0615 ext 806 | Mobile: (86) 135
> > 0135
> > > 9807 | Fax: (8610) 62670096
> > >
> > >
> > > On Fri, Oct 16, 2009 at 2:42 PM, Michael Xu (xudong)
> > > <do...@wizitsoft.com>wrote:
> > >
> > >> hi Scott,
> > >>
> > >> Thanks. Please see my inline comments.
> > >>
> > >> --
> > >> Regards,
> > >> Michael Xu (xudong)
> > >> www.wizitsoft.com | Office: (8610) 6267 0615 ext 806 | Mobile: (86) 135
> > >> 0135 9807 | Fax: (8610) 62670096
> > >>
> > >>
> > >> On Fri, Oct 16, 2009 at 2:14 PM, Scott Gray <scott.gray@hotwaxmedia.com
> > >wrote:
> > >>
> > >>> The problem is that with a generic data model many entities are used in
> > >>> many different places and in different contexts,
> > >>
> > >>
> > >> My idea is to use different GROUPs for different contexts.
> > >>
> > >>
> > >>> if you tried to encapsulate all of those differences within a single
> > >>> entity definition you are very quickly going to end up with a very
> > messy
> > >>> entity model.
> > >>
> > >>
> > >> Yes, you are right. Can we split a big entity definition file into many?
> > >> Does it help?
> > >>
> > >>
> > >>> IMO separation of concerns is a good thing, you're complaining about
> > >>> having to make changes in many places, but at least you know what
> > effect
> > >>> each change is having, in your model I would need to check everywhere
> > that
> > >>> an entity is used before making a change to be sure of what effect a
> > >>> seemingly minor adjustment would have.
> > >>>
> > >>> I think GROUP is a way to control such affects, because GROUP will be
> > used
> > >> in UI in my idea.
> > >>
> > >> The pain point with current design is that the developer (for some
> > >> customers, we even cannot assume they have a java developer) has to
> > >> understand the overall infrastructure for such minor customization.
> > >>
> > >> But if we put them in one place using xml format, even a business guy
> > can
> > >> implement such customization without any java knowledge.
> > >>
> > >> For senior ofbiz developers, like you, the current design is very
> > flexible.
> > >> But it might be another story for other people.
> > >>
> > >>
> > >>> Regards
> > >>> Scott
> > >>>
> > >>>
> > >>> On 16/10/2009, at 6:58 PM, Michael Xu (xudong) wrote:
> > >>>
> > >>> hi Scott,
> > >>>>
> > >>>> I got your points. Actually, form widgets are still required to show
> > the
> > >>>> GROUP with a set of predefined fields. But such form widget will be
> > very
> > >>>> generic, which is just show the group in the way defined in the entity
> > >>>> model. And as such the benefits are:
> > >>>> 1) a single point to define entity behavior (not just data structure)
> > >>>> 2) UI gets configurable directly in the single point (no need to
> > change
> > >>>> form
> > >>>> widgets or ftl in many places)
> > >>>> 3) less java codes and widgets are required.
> > >>>>
> > >>>> In a summary, bringing more power to entity definition.
> > >>>>
> > >>>> --
> > >>>> Regards,
> > >>>> Michael Xu (xudong)
> > >>>> www.wizitsoft.com | Office: (8610) 6267 0615 ext 806 | Mobile: (86)
> > 135
> > >>>> 0135
> > >>>> 9807 | Fax: (8610) 62670096
> > >>>>
> > >>>>
> > >>>> On Fri, Oct 16, 2009 at 1:39 PM, Scott Gray <
> > scott.gray@hotwaxmedia.com
> > >>>> >wrote:
> > >>>>
> > >>>> I think to be able to generate a reasonably functional UI from
> > something
> > >>>>> like this you'd end up with so much complexity in your entity model
> > that
> > >>>>> someone would come up with a new idea to solve that problem and
> > they'd
> > >>>>> call
> > >>>>> it the form widget.
> > >>>>>
> > >>>>> Regards
> > >>>>> Scott
> > >>>>>
> > >>>>> HotWax Media
> > >>>>> http://www.hotwaxmedia.com
> > >>>>>
> > >>>>>
> > >>>>> On 16/10/2009, at 5:22 PM, Hans Bakker wrote:
> > >>>>>
> > >>>>> In general, this looks like a pretty good idea.
> > >>>>>
> > >>>>>>
> > >>>>>> The visibility tag would be nice if the widgets took advantage of
> > >>>>>> that.
> > >>>>>> then i would be easy to let a field disappear in the whole system
> > when
> > >>>>>> a
> > >>>>>> if a simple 'true/false' would be possible.
> > >>>>>>
> > >>>>>> More complicated ones like the ones mentioned below could also be
> > >>>>>> interesting but the integration in the widgets is a must. ftl's will
> > me
> > >>>>>> more difficult (macros), jsp, not sure if we should support that.
> > >>>>>>
> > >>>>>> trigger and validation will be more complex but sure we could look
> > at
> > >>>>>> that.
> > >>>>>>
> > >>>>>> In general a good idea
> > >>>>>>
> > >>>>>> Regards,
> > >>>>>> Hans
> > >>>>>>
> > >>>>>>
> > >>>>>> On Fri, 2009-10-16 at 05:16 +0800, Michael Xu (xudong) wrote:
> > >>>>>>
> > >>>>>> hi all,
> > >>>>>>>
> > >>>>>>> We can define entities in XML files. However, only database
> > specific
> > >>>>>>> semantics could be defined there. For those application level
> > >>>>>>> semantics
> > >>>>>>> (like trigger, visiblity, validation) has to be defined in
> > different
> > >>>>>>> places.
> > >>>>>>> The lack of a single place to define such metadata makes ofbiz hard
> > to
> > >>>>>>> maintain. (Correct me if I am wrong)
> > >>>>>>>
> > >>>>>>> Let's take OrderHeader as an example. I copy the latest entity
> > >>>>>>> definition
> > >>>>>>> as
> > >>>>>>> below:
> > >>>>>>>
> > >>>>>>> <entity entity-name="OrderHeader"
> > >>>>>>> package-name="org.ofbiz.order.order"
> > >>>>>>> never-cache="true"
> > >>>>>>> title="Order Header Entity">
> > >>>>>>> <field name="orderId" type="id-ne"></field>
> > >>>>>>> <field name="orderTypeId" type="id"></field>
> > >>>>>>> <field name="orderName" type="name"></field>
> > >>>>>>> <field name="externalId" type="id"></field>
> > >>>>>>> <field name="salesChannelEnumId" type="id"></field>
> > >>>>>>> <field name="orderDate" type="date-time"></field>
> > >>>>>>> <field name="entryDate" type="date-time"></field>
> > >>>>>>> <field name="visitId" type="id"></field>
> > >>>>>>> <field name="statusId" type="id"></field>
> > >>>>>>> <field name="createdBy" type="id-vlong"></field>
> > >>>>>>> <field name="firstAttemptOrderId" type="id"></field>
> > >>>>>>> <field name="currencyUom" type="id"></field>
> > >>>>>>> <field name="syncStatusId" type="id"></field>
> > >>>>>>> <field name="billingAccountId" type="id"></field>
> > >>>>>>> <field name="originFacilityId" type="id"></field>
> > >>>>>>> <field name="webSiteId" type="id"></field>
> > >>>>>>> <field name="productStoreId" type="id"></field>
> > >>>>>>> <field name="terminalId" type="id-long"></field>
> > >>>>>>> <field name="transactionId" type="id-long"></field>
> > >>>>>>> <field name="autoOrderShoppingListId" type="id"></field>
> > >>>>>>> <field name="needsInventoryIssuance" type="indicator"></field>
> > >>>>>>> <field name="isRushOrder" type="indicator"></field>
> > >>>>>>> <field name="internalCode" type="id-long"></field>
> > >>>>>>> <field name="remainingSubTotal" type="currency-amount"></field>
> > >>>>>>> <field name="grandTotal" type="currency-amount"></field>
> > >>>>>>> <prim-key field="orderId"/>
> > >>>>>>> <relation type="one" fk-name="ORDER_HDR_TYPE"
> > >>>>>>> rel-entity-name="OrderType">
> > >>>>>>> <key-map field-name="orderTypeId"/>
> > >>>>>>> </relation>
> > >>>>>>> <relation type="one" fk-name="ORDER_HDR_SCENUM"
> > title="SalesChannel"
> > >>>>>>> rel-entity-name="Enumeration">
> > >>>>>>> <key-map field-name="salesChannelEnumId"
> > rel-field-name="enumId"/>
> > >>>>>>> </relation>
> > >>>>>>> <relation type="one" fk-name="ORDER_HDR_OFAC" title="Origin"
> > >>>>>>> rel-entity-name="Facility">
> > >>>>>>> <key-map field-name="originFacilityId"
> > >>>>>>> rel-field-name="facilityId"/>
> > >>>>>>> </relation>
> > >>>>>>> <relation type="many" rel-entity-name="OrderTypeAttr">
> > >>>>>>> <key-map field-name="orderTypeId"/>
> > >>>>>>> </relation>
> > >>>>>>> <relation type="one" fk-name="ORDER_HDR_BACCT"
> > >>>>>>> rel-entity-name="BillingAccount">
> > >>>>>>> <key-map field-name="billingAccountId"/>
> > >>>>>>> </relation>
> > >>>>>>> <relation type="one" fk-name="ORDER_HDR_PDSTR"
> > >>>>>>> rel-entity-name="ProductStore">
> > >>>>>>> <key-map field-name="productStoreId"/>
> > >>>>>>> </relation>
> > >>>>>>> <relation type="one" fk-name="ORDER_HDR_AOSHLST"
> > title="AutoOrder"
> > >>>>>>> rel-entity-name="ShoppingList">
> > >>>>>>> <key-map field-name="autoOrderShoppingListId"
> > >>>>>>> rel-field-name="shoppingListId"/>
> > >>>>>>> </relation>
> > >>>>>>> <relation type="one" fk-name="ORDER_HDR_CBUL" title="CreatedBy"
> > >>>>>>> rel-entity-name="UserLogin">
> > >>>>>>> <key-map field-name="createdBy" rel-field-name="userLoginId"/>
> > >>>>>>> </relation>
> > >>>>>>> <relation type="one" fk-name="ORDER_HDR_STTS"
> > >>>>>>> rel-entity-name="StatusItem">
> > >>>>>>> <key-map field-name="statusId"/>
> > >>>>>>> </relation>
> > >>>>>>> <relation type="one" fk-name="ORDER_HDR_SYST" title="Sync"
> > >>>>>>> rel-entity-name="StatusItem">
> > >>>>>>> <key-map field-name="syncStatusId" rel-field-name="statusId"/>
> > >>>>>>> </relation>
> > >>>>>>> <relation type="one" fk-name="ORDER_HDR_CUOM"
> > rel-entity-name="Uom">
> > >>>>>>> <key-map field-name="currencyUom" rel-field-name="uomId"/>
> > >>>>>>> </relation>
> > >>>>>>> <relation type="many" rel-entity-name="OrderHeaderNoteView">
> > >>>>>>> <key-map field-name="orderId"/>
> > >>>>>>> </relation>
> > >>>>>>> <relation type="many"
> > rel-entity-name="OrderItemAndShipGroupAssoc">
> > >>>>>>> <key-map field-name="orderId"/>
> > >>>>>>> </relation>
> > >>>>>>> <index name="ORDEREXT_ID_IDX">
> > >>>>>>> <index-field name="externalId"/>
> > >>>>>>> </index>
> > >>>>>>> </entity>
> > >>>>>>>
> > >>>>>>> In order to enrich the definition (metadata) with more information,
> > I
> > >>>>>>> am
> > >>>>>>> considering to put more tags (please find elements surrounded with
> > >>>>>>> !!!!!!!!!!!!!!!!!!!!!), like:
> > >>>>>>>
> > >>>>>>> <entity entity-name="OrderHeader"
> > >>>>>>> package-name="org.ofbiz.order.order"
> > >>>>>>> never-cache="true"
> > >>>>>>> title="Order Header Entity">
> > >>>>>>> <field name="orderId" type="id-ne"></field>
> > >>>>>>> <field name="orderTypeId" type="id"></field>
> > >>>>>>> <field name="orderName" type="name"></field>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>> <!- !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
> > >>>>>>> <field name="externalId" type="id">
> > >>>>>>> <!-
> > >>>>>>> We can use "visiblity" tag to tell system when to show
> > >>>>>>> this
> > >>>>>>> field in UI layer.
> > >>>>>>> ->
> > >>>>>>> <visbility>
> > >>>>>>> <condition
> > >>>>>>> implementation="org.ofbiz.core.condition.NonEmptyField"/>
> > >>>>>>> </visbility>
> > >>>>>>> <validity type="clientSide">
> > >>>>>>> <condition notEqual="111"/>
> > >>>>>>> </validity>
> > >>>>>>> </field>
> > >>>>>>> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! ->
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>> <field name="salesChannelEnumId" type="id"></field>
> > >>>>>>> <field name="orderDate" type="date-time"></field>
> > >>>>>>> <field name="entryDate" type="date-time"></field>
> > >>>>>>> <field name="visitId" type="id"></field>
> > >>>>>>> <field name="statusId" type="id"></field>
> > >>>>>>> <field name="createdBy" type="id-vlong"></field>
> > >>>>>>> <field name="firstAttemptOrderId" type="id"></field>
> > >>>>>>> <field name="currencyUom" type="id"></field>
> > >>>>>>> <field name="syncStatusId" type="id"></field>
> > >>>>>>> <field name="billingAccountId" type="id"></field>
> > >>>>>>> <field name="originFacilityId" type="id"></field>
> > >>>>>>> <field name="webSiteId" type="id"></field>
> > >>>>>>> <field name="productStoreId" type="id"></field>
> > >>>>>>> <field name="terminalId" type="id-long"></field>
> > >>>>>>> <field name="transactionId" type="id-long"></field>
> > >>>>>>> <field name="autoOrderShoppingListId" type="id"></field>
> > >>>>>>> <field name="needsInventoryIssuance" type="indicator"></field>
> > >>>>>>> <field name="isRushOrder" type="indicator"></field>
> > >>>>>>> <field name="internalCode" type="id-long"></field>
> > >>>>>>> <field name="remainingSubTotal" type="currency-amount"></field>
> > >>>>>>> <field name="grandTotal" type="currency-amount"></field>
> > >>>>>>> <prim-key field="orderId"/>
> > >>>>>>> <relation type="one" fk-name="ORDER_HDR_TYPE"
> > >>>>>>> rel-entity-name="OrderType">
> > >>>>>>> <key-map field-name="orderTypeId"/>
> > >>>>>>> </relation>
> > >>>>>>> <relation type="one" fk-name="ORDER_HDR_SCENUM"
> > title="SalesChannel"
> > >>>>>>> rel-entity-name="Enumeration">
> > >>>>>>> <key-map field-name="salesChannelEnumId"
> > rel-field-name="enumId"/>
> > >>>>>>> </relation>
> > >>>>>>> <relation type="one" fk-name="ORDER_HDR_OFAC" title="Origin"
> > >>>>>>> rel-entity-name="Facility">
> > >>>>>>> <key-map field-name="originFacilityId"
> > >>>>>>> rel-field-name="facilityId"/>
> > >>>>>>> </relation>
> > >>>>>>> <relation type="many" rel-entity-name="OrderTypeAttr">
> > >>>>>>> <key-map field-name="orderTypeId"/>
> > >>>>>>> </relation>
> > >>>>>>> <relation type="one" fk-name="ORDER_HDR_BACCT"
> > >>>>>>> rel-entity-name="BillingAccount">
> > >>>>>>> <key-map field-name="billingAccountId"/>
> > >>>>>>> </relation>
> > >>>>>>> <relation type="one" fk-name="ORDER_HDR_PDSTR"
> > >>>>>>> rel-entity-name="ProductStore">
> > >>>>>>> <key-map field-name="productStoreId"/>
> > >>>>>>> </relation>
> > >>>>>>> <relation type="one" fk-name="ORDER_HDR_AOSHLST"
> > title="AutoOrder"
> > >>>>>>> rel-entity-name="ShoppingList">
> > >>>>>>> <key-map field-name="autoOrderShoppingListId"
> > >>>>>>> rel-field-name="shoppingListId"/>
> > >>>>>>> </relation>
> > >>>>>>> <relation type="one" fk-name="ORDER_HDR_CBUL" title="CreatedBy"
> > >>>>>>> rel-entity-name="UserLogin">
> > >>>>>>> <key-map field-name="createdBy" rel-field-name="userLoginId"/>
> > >>>>>>> </relation>
> > >>>>>>> <relation type="one" fk-name="ORDER_HDR_STTS"
> > >>>>>>> rel-entity-name="StatusItem">
> > >>>>>>> <key-map field-name="statusId"/>
> > >>>>>>> </relation>
> > >>>>>>> <relation type="one" fk-name="ORDER_HDR_SYST" title="Sync"
> > >>>>>>> rel-entity-name="StatusItem">
> > >>>>>>> <key-map field-name="syncStatusId" rel-field-name="statusId"/>
> > >>>>>>> </relation>
> > >>>>>>> <relation type="one" fk-name="ORDER_HDR_CUOM"
> > rel-entity-name="Uom">
> > >>>>>>> <key-map field-name="currencyUom" rel-field-name="uomId"/>
> > >>>>>>> </relation>
> > >>>>>>> <relation type="many" rel-entity-name="OrderHeaderNoteView">
> > >>>>>>> <key-map field-name="orderId"/>
> > >>>>>>> </relation>
> > >>>>>>> <relation type="many"
> > rel-entity-name="OrderItemAndShipGroupAssoc">
> > >>>>>>> <key-map field-name="orderId"/>
> > >>>>>>> </relation>
> > >>>>>>> <index name="ORDEREXT_ID_IDX">
> > >>>>>>> <index-field name="externalId"/>
> > >>>>>>> </index>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>> <!- !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
> > >>>>>>> <!-
> > >>>>>>> In different context, maybe different set of fields need to
> > show.
> > >>>>>>> So my idea
> > >>>>>>> here is to use "group" to group fields for different scenario.
> > >>>>>>> And
> > >>>>>>> then in UI
> > >>>>>>> level, we can define a jsp tag or something to only show
> > fields
> > >>>>>>> within this group.
> > >>>>>>> ->
> > >>>>>>> <group name="summary">
> > >>>>>>> <field name="orderId" rank="1"/>
> > >>>>>>> <field name="orderTypeId" rank="10"/>
> > >>>>>>> <field name="orderName" rank="11"/>
> > >>>>>>> </group>
> > >>>>>>>
> > >>>>>>> <group name="details">
> > >>>>>>> <field name="orderId" rank="1"/>
> > >>>>>>> <field name="orderTypeId" rank="10"/>
> > >>>>>>> <field name="orderName" rank="11"/>
> > >>>>>>> <field name="externalId" rank="20">
> > >>>>>>> <!-
> > >>>>>>> !!!!Note: Though visibility is definded above with
> > >>>>>>> another
> > >>>>>>> condition. However, in this group
> > >>>>>>> (Scenario), externalID will always be
> > >>>>>>> visible.
> > >>>>>>> ->
> > >>>>>>> <visbility value="true"/>
> > >>>>>>> <field>
> > >>>>>>> </group>
> > >>>>>>> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!->
> > >>>>>>> </entity>
> > >>>>>>>
> > >>>>>>> Such an idea to make entity definition as a single point of
> > >>>>>>> configuration/customization might make system easier to
> > >>>>>>> maintain/customize.
> > >>>>>>> Am I right? If yes, anybody could suggest me how to implement it.
> > >>>>>>>
> > >>>>>>> (BTW: we are going to use ofbiz entity engine for our products just
> > >>>>>>> like
> > >>>>>>> what JIRA did. It would be great if such enhancement could be done
> > >>>>>>> direct
> > >>>>>>> under apache. Otherwise, we might have to maintain a customized
> > ofbiz
> > >>>>>>> entity
> > >>>>>>> engine by ourselves.)
> > >>>>>>>
> > >>>>>>> --
> > >>>>>>> Regards,
> > >>>>>>> Michael Xu (xudong)
> > >>>>>>> www.wizitsoft.com | Office: (8610) 6267 0615 ext 806 | Mobile:
> > (86)
> > >>>>>>> 135
> > >>>>>>> 0135
> > >>>>>>> 9807 | Fax: (8610) 62670096
> > >>>>>>>
> > >>>>>>> --
> > >>>>>> Antwebsystems.com: Quality OFBiz services for competitive rates
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>
> > >>>
> > >>
> > >
> >
Re: about entity engine
Posted by "Michael Xu (xudong)" <do...@wizitsoft.com>.
hi Bruno,
Thanks for your explanation.
Really look forward to the XML driven widgets.
--
Regards,
Michael Xu (xudong)
www.wizitsoft.com | Office: (8610) 6267 0615 ext 806 | Mobile: (86) 135 0135
9807 | Fax: (8610) 62670096
On Fri, Oct 16, 2009 at 3:13 PM, Bruno Busco <br...@gmail.com> wrote:
> Hi Michael,
> actually OFBiz offers the possibility of designing UI without knowing
> the java language.
> There are powerfull widgets that are being developed further day by
> day to let you design UI using XML.
> There is a minilanguage that lets you collect and prepare de data to
> be presented using XML.
>
> Very often it is necessary to group in a single screen data coming
> from different entities and this would be even more difficult to be
> described in the entity itself.
>
> More generally the model you propose puts toghether the database layer
> and the presentation layer that we always try to keep separated.
>
> My two cents,
> Bruno
>
> 2009/10/16 Michael Xu (xudong) <do...@wizitsoft.com>:
> > BTW, I think My idea can be implemented in a backword compatible way. So
> at
> > least that will be another choice to implement new ofbiz applications.
> >
> > --
> > Regards,
> > Michael Xu (xudong)
> > www.wizitsoft.com | Office: (8610) 6267 0615 ext 806 | Mobile: (86) 135
> 0135
> > 9807 | Fax: (8610) 62670096
> >
> >
> > On Fri, Oct 16, 2009 at 2:42 PM, Michael Xu (xudong)
> > <do...@wizitsoft.com>wrote:
> >
> >> hi Scott,
> >>
> >> Thanks. Please see my inline comments.
> >>
> >> --
> >> Regards,
> >> Michael Xu (xudong)
> >> www.wizitsoft.com | Office: (8610) 6267 0615 ext 806 | Mobile: (86) 135
> >> 0135 9807 | Fax: (8610) 62670096
> >>
> >>
> >> On Fri, Oct 16, 2009 at 2:14 PM, Scott Gray <scott.gray@hotwaxmedia.com
> >wrote:
> >>
> >>> The problem is that with a generic data model many entities are used in
> >>> many different places and in different contexts,
> >>
> >>
> >> My idea is to use different GROUPs for different contexts.
> >>
> >>
> >>> if you tried to encapsulate all of those differences within a single
> >>> entity definition you are very quickly going to end up with a very
> messy
> >>> entity model.
> >>
> >>
> >> Yes, you are right. Can we split a big entity definition file into many?
> >> Does it help?
> >>
> >>
> >>> IMO separation of concerns is a good thing, you're complaining about
> >>> having to make changes in many places, but at least you know what
> effect
> >>> each change is having, in your model I would need to check everywhere
> that
> >>> an entity is used before making a change to be sure of what effect a
> >>> seemingly minor adjustment would have.
> >>>
> >>> I think GROUP is a way to control such affects, because GROUP will be
> used
> >> in UI in my idea.
> >>
> >> The pain point with current design is that the developer (for some
> >> customers, we even cannot assume they have a java developer) has to
> >> understand the overall infrastructure for such minor customization.
> >>
> >> But if we put them in one place using xml format, even a business guy
> can
> >> implement such customization without any java knowledge.
> >>
> >> For senior ofbiz developers, like you, the current design is very
> flexible.
> >> But it might be another story for other people.
> >>
> >>
> >>> Regards
> >>> Scott
> >>>
> >>>
> >>> On 16/10/2009, at 6:58 PM, Michael Xu (xudong) wrote:
> >>>
> >>> hi Scott,
> >>>>
> >>>> I got your points. Actually, form widgets are still required to show
> the
> >>>> GROUP with a set of predefined fields. But such form widget will be
> very
> >>>> generic, which is just show the group in the way defined in the entity
> >>>> model. And as such the benefits are:
> >>>> 1) a single point to define entity behavior (not just data structure)
> >>>> 2) UI gets configurable directly in the single point (no need to
> change
> >>>> form
> >>>> widgets or ftl in many places)
> >>>> 3) less java codes and widgets are required.
> >>>>
> >>>> In a summary, bringing more power to entity definition.
> >>>>
> >>>> --
> >>>> Regards,
> >>>> Michael Xu (xudong)
> >>>> www.wizitsoft.com | Office: (8610) 6267 0615 ext 806 | Mobile: (86)
> 135
> >>>> 0135
> >>>> 9807 | Fax: (8610) 62670096
> >>>>
> >>>>
> >>>> On Fri, Oct 16, 2009 at 1:39 PM, Scott Gray <
> scott.gray@hotwaxmedia.com
> >>>> >wrote:
> >>>>
> >>>> I think to be able to generate a reasonably functional UI from
> something
> >>>>> like this you'd end up with so much complexity in your entity model
> that
> >>>>> someone would come up with a new idea to solve that problem and
> they'd
> >>>>> call
> >>>>> it the form widget.
> >>>>>
> >>>>> Regards
> >>>>> Scott
> >>>>>
> >>>>> HotWax Media
> >>>>> http://www.hotwaxmedia.com
> >>>>>
> >>>>>
> >>>>> On 16/10/2009, at 5:22 PM, Hans Bakker wrote:
> >>>>>
> >>>>> In general, this looks like a pretty good idea.
> >>>>>
> >>>>>>
> >>>>>> The visibility tag would be nice if the widgets took advantage of
> >>>>>> that.
> >>>>>> then i would be easy to let a field disappear in the whole system
> when
> >>>>>> a
> >>>>>> if a simple 'true/false' would be possible.
> >>>>>>
> >>>>>> More complicated ones like the ones mentioned below could also be
> >>>>>> interesting but the integration in the widgets is a must. ftl's will
> me
> >>>>>> more difficult (macros), jsp, not sure if we should support that.
> >>>>>>
> >>>>>> trigger and validation will be more complex but sure we could look
> at
> >>>>>> that.
> >>>>>>
> >>>>>> In general a good idea
> >>>>>>
> >>>>>> Regards,
> >>>>>> Hans
> >>>>>>
> >>>>>>
> >>>>>> On Fri, 2009-10-16 at 05:16 +0800, Michael Xu (xudong) wrote:
> >>>>>>
> >>>>>> hi all,
> >>>>>>>
> >>>>>>> We can define entities in XML files. However, only database
> specific
> >>>>>>> semantics could be defined there. For those application level
> >>>>>>> semantics
> >>>>>>> (like trigger, visiblity, validation) has to be defined in
> different
> >>>>>>> places.
> >>>>>>> The lack of a single place to define such metadata makes ofbiz hard
> to
> >>>>>>> maintain. (Correct me if I am wrong)
> >>>>>>>
> >>>>>>> Let's take OrderHeader as an example. I copy the latest entity
> >>>>>>> definition
> >>>>>>> as
> >>>>>>> below:
> >>>>>>>
> >>>>>>> <entity entity-name="OrderHeader"
> >>>>>>> package-name="org.ofbiz.order.order"
> >>>>>>> never-cache="true"
> >>>>>>> title="Order Header Entity">
> >>>>>>> <field name="orderId" type="id-ne"></field>
> >>>>>>> <field name="orderTypeId" type="id"></field>
> >>>>>>> <field name="orderName" type="name"></field>
> >>>>>>> <field name="externalId" type="id"></field>
> >>>>>>> <field name="salesChannelEnumId" type="id"></field>
> >>>>>>> <field name="orderDate" type="date-time"></field>
> >>>>>>> <field name="entryDate" type="date-time"></field>
> >>>>>>> <field name="visitId" type="id"></field>
> >>>>>>> <field name="statusId" type="id"></field>
> >>>>>>> <field name="createdBy" type="id-vlong"></field>
> >>>>>>> <field name="firstAttemptOrderId" type="id"></field>
> >>>>>>> <field name="currencyUom" type="id"></field>
> >>>>>>> <field name="syncStatusId" type="id"></field>
> >>>>>>> <field name="billingAccountId" type="id"></field>
> >>>>>>> <field name="originFacilityId" type="id"></field>
> >>>>>>> <field name="webSiteId" type="id"></field>
> >>>>>>> <field name="productStoreId" type="id"></field>
> >>>>>>> <field name="terminalId" type="id-long"></field>
> >>>>>>> <field name="transactionId" type="id-long"></field>
> >>>>>>> <field name="autoOrderShoppingListId" type="id"></field>
> >>>>>>> <field name="needsInventoryIssuance" type="indicator"></field>
> >>>>>>> <field name="isRushOrder" type="indicator"></field>
> >>>>>>> <field name="internalCode" type="id-long"></field>
> >>>>>>> <field name="remainingSubTotal" type="currency-amount"></field>
> >>>>>>> <field name="grandTotal" type="currency-amount"></field>
> >>>>>>> <prim-key field="orderId"/>
> >>>>>>> <relation type="one" fk-name="ORDER_HDR_TYPE"
> >>>>>>> rel-entity-name="OrderType">
> >>>>>>> <key-map field-name="orderTypeId"/>
> >>>>>>> </relation>
> >>>>>>> <relation type="one" fk-name="ORDER_HDR_SCENUM"
> title="SalesChannel"
> >>>>>>> rel-entity-name="Enumeration">
> >>>>>>> <key-map field-name="salesChannelEnumId"
> rel-field-name="enumId"/>
> >>>>>>> </relation>
> >>>>>>> <relation type="one" fk-name="ORDER_HDR_OFAC" title="Origin"
> >>>>>>> rel-entity-name="Facility">
> >>>>>>> <key-map field-name="originFacilityId"
> >>>>>>> rel-field-name="facilityId"/>
> >>>>>>> </relation>
> >>>>>>> <relation type="many" rel-entity-name="OrderTypeAttr">
> >>>>>>> <key-map field-name="orderTypeId"/>
> >>>>>>> </relation>
> >>>>>>> <relation type="one" fk-name="ORDER_HDR_BACCT"
> >>>>>>> rel-entity-name="BillingAccount">
> >>>>>>> <key-map field-name="billingAccountId"/>
> >>>>>>> </relation>
> >>>>>>> <relation type="one" fk-name="ORDER_HDR_PDSTR"
> >>>>>>> rel-entity-name="ProductStore">
> >>>>>>> <key-map field-name="productStoreId"/>
> >>>>>>> </relation>
> >>>>>>> <relation type="one" fk-name="ORDER_HDR_AOSHLST"
> title="AutoOrder"
> >>>>>>> rel-entity-name="ShoppingList">
> >>>>>>> <key-map field-name="autoOrderShoppingListId"
> >>>>>>> rel-field-name="shoppingListId"/>
> >>>>>>> </relation>
> >>>>>>> <relation type="one" fk-name="ORDER_HDR_CBUL" title="CreatedBy"
> >>>>>>> rel-entity-name="UserLogin">
> >>>>>>> <key-map field-name="createdBy" rel-field-name="userLoginId"/>
> >>>>>>> </relation>
> >>>>>>> <relation type="one" fk-name="ORDER_HDR_STTS"
> >>>>>>> rel-entity-name="StatusItem">
> >>>>>>> <key-map field-name="statusId"/>
> >>>>>>> </relation>
> >>>>>>> <relation type="one" fk-name="ORDER_HDR_SYST" title="Sync"
> >>>>>>> rel-entity-name="StatusItem">
> >>>>>>> <key-map field-name="syncStatusId" rel-field-name="statusId"/>
> >>>>>>> </relation>
> >>>>>>> <relation type="one" fk-name="ORDER_HDR_CUOM"
> rel-entity-name="Uom">
> >>>>>>> <key-map field-name="currencyUom" rel-field-name="uomId"/>
> >>>>>>> </relation>
> >>>>>>> <relation type="many" rel-entity-name="OrderHeaderNoteView">
> >>>>>>> <key-map field-name="orderId"/>
> >>>>>>> </relation>
> >>>>>>> <relation type="many"
> rel-entity-name="OrderItemAndShipGroupAssoc">
> >>>>>>> <key-map field-name="orderId"/>
> >>>>>>> </relation>
> >>>>>>> <index name="ORDEREXT_ID_IDX">
> >>>>>>> <index-field name="externalId"/>
> >>>>>>> </index>
> >>>>>>> </entity>
> >>>>>>>
> >>>>>>> In order to enrich the definition (metadata) with more information,
> I
> >>>>>>> am
> >>>>>>> considering to put more tags (please find elements surrounded with
> >>>>>>> !!!!!!!!!!!!!!!!!!!!!), like:
> >>>>>>>
> >>>>>>> <entity entity-name="OrderHeader"
> >>>>>>> package-name="org.ofbiz.order.order"
> >>>>>>> never-cache="true"
> >>>>>>> title="Order Header Entity">
> >>>>>>> <field name="orderId" type="id-ne"></field>
> >>>>>>> <field name="orderTypeId" type="id"></field>
> >>>>>>> <field name="orderName" type="name"></field>
> >>>>>>>
> >>>>>>>
> >>>>>>> <!- !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
> >>>>>>> <field name="externalId" type="id">
> >>>>>>> <!-
> >>>>>>> We can use "visiblity" tag to tell system when to show
> >>>>>>> this
> >>>>>>> field in UI layer.
> >>>>>>> ->
> >>>>>>> <visbility>
> >>>>>>> <condition
> >>>>>>> implementation="org.ofbiz.core.condition.NonEmptyField"/>
> >>>>>>> </visbility>
> >>>>>>> <validity type="clientSide">
> >>>>>>> <condition notEqual="111"/>
> >>>>>>> </validity>
> >>>>>>> </field>
> >>>>>>> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! ->
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> <field name="salesChannelEnumId" type="id"></field>
> >>>>>>> <field name="orderDate" type="date-time"></field>
> >>>>>>> <field name="entryDate" type="date-time"></field>
> >>>>>>> <field name="visitId" type="id"></field>
> >>>>>>> <field name="statusId" type="id"></field>
> >>>>>>> <field name="createdBy" type="id-vlong"></field>
> >>>>>>> <field name="firstAttemptOrderId" type="id"></field>
> >>>>>>> <field name="currencyUom" type="id"></field>
> >>>>>>> <field name="syncStatusId" type="id"></field>
> >>>>>>> <field name="billingAccountId" type="id"></field>
> >>>>>>> <field name="originFacilityId" type="id"></field>
> >>>>>>> <field name="webSiteId" type="id"></field>
> >>>>>>> <field name="productStoreId" type="id"></field>
> >>>>>>> <field name="terminalId" type="id-long"></field>
> >>>>>>> <field name="transactionId" type="id-long"></field>
> >>>>>>> <field name="autoOrderShoppingListId" type="id"></field>
> >>>>>>> <field name="needsInventoryIssuance" type="indicator"></field>
> >>>>>>> <field name="isRushOrder" type="indicator"></field>
> >>>>>>> <field name="internalCode" type="id-long"></field>
> >>>>>>> <field name="remainingSubTotal" type="currency-amount"></field>
> >>>>>>> <field name="grandTotal" type="currency-amount"></field>
> >>>>>>> <prim-key field="orderId"/>
> >>>>>>> <relation type="one" fk-name="ORDER_HDR_TYPE"
> >>>>>>> rel-entity-name="OrderType">
> >>>>>>> <key-map field-name="orderTypeId"/>
> >>>>>>> </relation>
> >>>>>>> <relation type="one" fk-name="ORDER_HDR_SCENUM"
> title="SalesChannel"
> >>>>>>> rel-entity-name="Enumeration">
> >>>>>>> <key-map field-name="salesChannelEnumId"
> rel-field-name="enumId"/>
> >>>>>>> </relation>
> >>>>>>> <relation type="one" fk-name="ORDER_HDR_OFAC" title="Origin"
> >>>>>>> rel-entity-name="Facility">
> >>>>>>> <key-map field-name="originFacilityId"
> >>>>>>> rel-field-name="facilityId"/>
> >>>>>>> </relation>
> >>>>>>> <relation type="many" rel-entity-name="OrderTypeAttr">
> >>>>>>> <key-map field-name="orderTypeId"/>
> >>>>>>> </relation>
> >>>>>>> <relation type="one" fk-name="ORDER_HDR_BACCT"
> >>>>>>> rel-entity-name="BillingAccount">
> >>>>>>> <key-map field-name="billingAccountId"/>
> >>>>>>> </relation>
> >>>>>>> <relation type="one" fk-name="ORDER_HDR_PDSTR"
> >>>>>>> rel-entity-name="ProductStore">
> >>>>>>> <key-map field-name="productStoreId"/>
> >>>>>>> </relation>
> >>>>>>> <relation type="one" fk-name="ORDER_HDR_AOSHLST"
> title="AutoOrder"
> >>>>>>> rel-entity-name="ShoppingList">
> >>>>>>> <key-map field-name="autoOrderShoppingListId"
> >>>>>>> rel-field-name="shoppingListId"/>
> >>>>>>> </relation>
> >>>>>>> <relation type="one" fk-name="ORDER_HDR_CBUL" title="CreatedBy"
> >>>>>>> rel-entity-name="UserLogin">
> >>>>>>> <key-map field-name="createdBy" rel-field-name="userLoginId"/>
> >>>>>>> </relation>
> >>>>>>> <relation type="one" fk-name="ORDER_HDR_STTS"
> >>>>>>> rel-entity-name="StatusItem">
> >>>>>>> <key-map field-name="statusId"/>
> >>>>>>> </relation>
> >>>>>>> <relation type="one" fk-name="ORDER_HDR_SYST" title="Sync"
> >>>>>>> rel-entity-name="StatusItem">
> >>>>>>> <key-map field-name="syncStatusId" rel-field-name="statusId"/>
> >>>>>>> </relation>
> >>>>>>> <relation type="one" fk-name="ORDER_HDR_CUOM"
> rel-entity-name="Uom">
> >>>>>>> <key-map field-name="currencyUom" rel-field-name="uomId"/>
> >>>>>>> </relation>
> >>>>>>> <relation type="many" rel-entity-name="OrderHeaderNoteView">
> >>>>>>> <key-map field-name="orderId"/>
> >>>>>>> </relation>
> >>>>>>> <relation type="many"
> rel-entity-name="OrderItemAndShipGroupAssoc">
> >>>>>>> <key-map field-name="orderId"/>
> >>>>>>> </relation>
> >>>>>>> <index name="ORDEREXT_ID_IDX">
> >>>>>>> <index-field name="externalId"/>
> >>>>>>> </index>
> >>>>>>>
> >>>>>>>
> >>>>>>> <!- !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
> >>>>>>> <!-
> >>>>>>> In different context, maybe different set of fields need to
> show.
> >>>>>>> So my idea
> >>>>>>> here is to use "group" to group fields for different scenario.
> >>>>>>> And
> >>>>>>> then in UI
> >>>>>>> level, we can define a jsp tag or something to only show
> fields
> >>>>>>> within this group.
> >>>>>>> ->
> >>>>>>> <group name="summary">
> >>>>>>> <field name="orderId" rank="1"/>
> >>>>>>> <field name="orderTypeId" rank="10"/>
> >>>>>>> <field name="orderName" rank="11"/>
> >>>>>>> </group>
> >>>>>>>
> >>>>>>> <group name="details">
> >>>>>>> <field name="orderId" rank="1"/>
> >>>>>>> <field name="orderTypeId" rank="10"/>
> >>>>>>> <field name="orderName" rank="11"/>
> >>>>>>> <field name="externalId" rank="20">
> >>>>>>> <!-
> >>>>>>> !!!!Note: Though visibility is definded above with
> >>>>>>> another
> >>>>>>> condition. However, in this group
> >>>>>>> (Scenario), externalID will always be
> >>>>>>> visible.
> >>>>>>> ->
> >>>>>>> <visbility value="true"/>
> >>>>>>> <field>
> >>>>>>> </group>
> >>>>>>> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!->
> >>>>>>> </entity>
> >>>>>>>
> >>>>>>> Such an idea to make entity definition as a single point of
> >>>>>>> configuration/customization might make system easier to
> >>>>>>> maintain/customize.
> >>>>>>> Am I right? If yes, anybody could suggest me how to implement it.
> >>>>>>>
> >>>>>>> (BTW: we are going to use ofbiz entity engine for our products just
> >>>>>>> like
> >>>>>>> what JIRA did. It would be great if such enhancement could be done
> >>>>>>> direct
> >>>>>>> under apache. Otherwise, we might have to maintain a customized
> ofbiz
> >>>>>>> entity
> >>>>>>> engine by ourselves.)
> >>>>>>>
> >>>>>>> --
> >>>>>>> Regards,
> >>>>>>> Michael Xu (xudong)
> >>>>>>> www.wizitsoft.com | Office: (8610) 6267 0615 ext 806 | Mobile:
> (86)
> >>>>>>> 135
> >>>>>>> 0135
> >>>>>>> 9807 | Fax: (8610) 62670096
> >>>>>>>
> >>>>>>> --
> >>>>>> Antwebsystems.com: Quality OFBiz services for competitive rates
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>
> >>
> >
>
Re: about entity engine
Posted by Bruno Busco <br...@gmail.com>.
Hi Michael,
actually OFBiz offers the possibility of designing UI without knowing
the java language.
There are powerfull widgets that are being developed further day by
day to let you design UI using XML.
There is a minilanguage that lets you collect and prepare de data to
be presented using XML.
Very often it is necessary to group in a single screen data coming
from different entities and this would be even more difficult to be
described in the entity itself.
More generally the model you propose puts toghether the database layer
and the presentation layer that we always try to keep separated.
My two cents,
Bruno
2009/10/16 Michael Xu (xudong) <do...@wizitsoft.com>:
> BTW, I think My idea can be implemented in a backword compatible way. So at
> least that will be another choice to implement new ofbiz applications.
>
> --
> Regards,
> Michael Xu (xudong)
> www.wizitsoft.com | Office: (8610) 6267 0615 ext 806 | Mobile: (86) 135 0135
> 9807 | Fax: (8610) 62670096
>
>
> On Fri, Oct 16, 2009 at 2:42 PM, Michael Xu (xudong)
> <do...@wizitsoft.com>wrote:
>
>> hi Scott,
>>
>> Thanks. Please see my inline comments.
>>
>> --
>> Regards,
>> Michael Xu (xudong)
>> www.wizitsoft.com | Office: (8610) 6267 0615 ext 806 | Mobile: (86) 135
>> 0135 9807 | Fax: (8610) 62670096
>>
>>
>> On Fri, Oct 16, 2009 at 2:14 PM, Scott Gray <sc...@hotwaxmedia.com>wrote:
>>
>>> The problem is that with a generic data model many entities are used in
>>> many different places and in different contexts,
>>
>>
>> My idea is to use different GROUPs for different contexts.
>>
>>
>>> if you tried to encapsulate all of those differences within a single
>>> entity definition you are very quickly going to end up with a very messy
>>> entity model.
>>
>>
>> Yes, you are right. Can we split a big entity definition file into many?
>> Does it help?
>>
>>
>>> IMO separation of concerns is a good thing, you're complaining about
>>> having to make changes in many places, but at least you know what effect
>>> each change is having, Â in your model I would need to check everywhere that
>>> an entity is used before making a change to be sure of what effect a
>>> seemingly minor adjustment would have.
>>>
>>> I think GROUP is a way to control such affects, because GROUP will be used
>> in UI in my idea.
>>
>> The pain point with current design is that the developer (for some
>> customers, we even cannot assume they have a java developer) has to
>> understand the overall infrastructure for such minor customization.
>>
>> But if we put them in one place using xml format, even a business guy can
>> implement such customization without any java knowledge.
>>
>> For senior ofbiz developers, like you, the current design is very flexible.
>> But it might be another story for other people.
>>
>>
>>> Regards
>>> Scott
>>>
>>>
>>> On 16/10/2009, at 6:58 PM, Michael Xu (xudong) wrote:
>>>
>>> Â hi Scott,
>>>>
>>>> I got your points. Actually, form widgets are still required to show the
>>>> GROUP with a set of predefined fields. But such form widget will be very
>>>> generic, which is just show the group in the way defined in the entity
>>>> model. And as such the benefits are:
>>>> 1) a single point to define entity behavior (not just data structure)
>>>> 2) UI gets configurable directly in the single point (no need to change
>>>> form
>>>> widgets or ftl in many places)
>>>> 3) less java codes and widgets are required.
>>>>
>>>> In a summary, bringing more power to entity definition.
>>>>
>>>> --
>>>> Regards,
>>>> Michael Xu (xudong)
>>>> www.wizitsoft.com | Office: (8610) 6267 0615 ext 806 | Mobile: (86) 135
>>>> 0135
>>>> 9807 | Fax: (8610) 62670096
>>>>
>>>>
>>>> On Fri, Oct 16, 2009 at 1:39 PM, Scott Gray <scott.gray@hotwaxmedia.com
>>>> >wrote:
>>>>
>>>> Â I think to be able to generate a reasonably functional UI from something
>>>>> like this you'd end up with so much complexity in your entity model that
>>>>> someone would come up with a new idea to solve that problem and they'd
>>>>> call
>>>>> it the form widget.
>>>>>
>>>>> Regards
>>>>> Scott
>>>>>
>>>>> HotWax Media
>>>>> http://www.hotwaxmedia.com
>>>>>
>>>>>
>>>>> On 16/10/2009, at 5:22 PM, Hans Bakker wrote:
>>>>>
>>>>> In general, this looks like a pretty good idea.
>>>>>
>>>>>>
>>>>>> The visibility tag  would be nice if the widgets took advantage of
>>>>>> that.
>>>>>> then i would be easy to let a field disappear in the whole system when
>>>>>> a
>>>>>> if a simple 'true/false' would be possible.
>>>>>>
>>>>>> More complicated ones like the ones mentioned below could also be
>>>>>> interesting but the integration in the widgets is a must. ftl's will me
>>>>>> more difficult (macros), jsp, not sure if we should support that.
>>>>>>
>>>>>> trigger and validation will be more complex but sure we could look at
>>>>>> that.
>>>>>>
>>>>>> In general a good idea
>>>>>>
>>>>>> Regards,
>>>>>> Hans
>>>>>>
>>>>>>
>>>>>> On Fri, 2009-10-16 at 05:16 +0800, Michael Xu (xudong) wrote:
>>>>>>
>>>>>> Â hi all,
>>>>>>>
>>>>>>> We can define entities in XML files. However, only database specific
>>>>>>> semantics could be defined there. For those application level
>>>>>>> semantics
>>>>>>> (like trigger, visiblity, validation) has to be defined in different
>>>>>>> places.
>>>>>>> The lack of a single place to define such metadata makes ofbiz hard to
>>>>>>> maintain. (Correct me if I am wrong)
>>>>>>>
>>>>>>> Let's take OrderHeader as an example. I copy the latest entity
>>>>>>> definition
>>>>>>> as
>>>>>>> below:
>>>>>>>
>>>>>>> Â <entity entity-name="OrderHeader"
>>>>>>> Â Â Â Â package-name="org.ofbiz.order.order"
>>>>>>> Â Â Â Â never-cache="true"
>>>>>>> Â Â Â Â title="Order Header Entity">
>>>>>>> Â <field name="orderId" type="id-ne"></field>
>>>>>>> Â <field name="orderTypeId" type="id"></field>
>>>>>>> Â <field name="orderName" type="name"></field>
>>>>>>> Â <field name="externalId" type="id"></field>
>>>>>>> Â <field name="salesChannelEnumId" type="id"></field>
>>>>>>> Â <field name="orderDate" type="date-time"></field>
>>>>>>> Â <field name="entryDate" type="date-time"></field>
>>>>>>> Â <field name="visitId" type="id"></field>
>>>>>>> Â <field name="statusId" type="id"></field>
>>>>>>> Â <field name="createdBy" type="id-vlong"></field>
>>>>>>> Â <field name="firstAttemptOrderId" type="id"></field>
>>>>>>> Â <field name="currencyUom" type="id"></field>
>>>>>>> Â <field name="syncStatusId" type="id"></field>
>>>>>>> Â <field name="billingAccountId" type="id"></field>
>>>>>>> Â <field name="originFacilityId" type="id"></field>
>>>>>>> Â <field name="webSiteId" type="id"></field>
>>>>>>> Â <field name="productStoreId" type="id"></field>
>>>>>>> Â <field name="terminalId" type="id-long"></field>
>>>>>>> Â <field name="transactionId" type="id-long"></field>
>>>>>>> Â <field name="autoOrderShoppingListId" type="id"></field>
>>>>>>> Â <field name="needsInventoryIssuance" type="indicator"></field>
>>>>>>> Â <field name="isRushOrder" type="indicator"></field>
>>>>>>> Â <field name="internalCode" type="id-long"></field>
>>>>>>> Â <field name="remainingSubTotal" type="currency-amount"></field>
>>>>>>> Â <field name="grandTotal" type="currency-amount"></field>
>>>>>>> Â <prim-key field="orderId"/>
>>>>>>> Â <relation type="one" fk-name="ORDER_HDR_TYPE"
>>>>>>> rel-entity-name="OrderType">
>>>>>>> Â Â <key-map field-name="orderTypeId"/>
>>>>>>> Â </relation>
>>>>>>> Â <relation type="one" fk-name="ORDER_HDR_SCENUM" title="SalesChannel"
>>>>>>> rel-entity-name="Enumeration">
>>>>>>> Â Â <key-map field-name="salesChannelEnumId" rel-field-name="enumId"/>
>>>>>>> Â </relation>
>>>>>>> Â <relation type="one" fk-name="ORDER_HDR_OFAC" title="Origin"
>>>>>>> rel-entity-name="Facility">
>>>>>>> Â Â <key-map field-name="originFacilityId"
>>>>>>> rel-field-name="facilityId"/>
>>>>>>> Â </relation>
>>>>>>> Â <relation type="many" rel-entity-name="OrderTypeAttr">
>>>>>>> Â Â <key-map field-name="orderTypeId"/>
>>>>>>> Â </relation>
>>>>>>> Â <relation type="one" fk-name="ORDER_HDR_BACCT"
>>>>>>> rel-entity-name="BillingAccount">
>>>>>>> Â Â <key-map field-name="billingAccountId"/>
>>>>>>> Â </relation>
>>>>>>> Â <relation type="one" fk-name="ORDER_HDR_PDSTR"
>>>>>>> rel-entity-name="ProductStore">
>>>>>>> Â Â <key-map field-name="productStoreId"/>
>>>>>>> Â </relation>
>>>>>>> Â <relation type="one" fk-name="ORDER_HDR_AOSHLST" title="AutoOrder"
>>>>>>> rel-entity-name="ShoppingList">
>>>>>>> Â Â <key-map field-name="autoOrderShoppingListId"
>>>>>>> rel-field-name="shoppingListId"/>
>>>>>>> Â </relation>
>>>>>>> Â <relation type="one" fk-name="ORDER_HDR_CBUL" title="CreatedBy"
>>>>>>> rel-entity-name="UserLogin">
>>>>>>> Â Â <key-map field-name="createdBy" rel-field-name="userLoginId"/>
>>>>>>> Â </relation>
>>>>>>> Â <relation type="one" fk-name="ORDER_HDR_STTS"
>>>>>>> rel-entity-name="StatusItem">
>>>>>>> Â Â <key-map field-name="statusId"/>
>>>>>>> Â </relation>
>>>>>>> Â <relation type="one" fk-name="ORDER_HDR_SYST" title="Sync"
>>>>>>> rel-entity-name="StatusItem">
>>>>>>> Â Â <key-map field-name="syncStatusId" rel-field-name="statusId"/>
>>>>>>> Â </relation>
>>>>>>> Â <relation type="one" fk-name="ORDER_HDR_CUOM" rel-entity-name="Uom">
>>>>>>> Â Â <key-map field-name="currencyUom" rel-field-name="uomId"/>
>>>>>>> Â </relation>
>>>>>>> Â <relation type="many" rel-entity-name="OrderHeaderNoteView">
>>>>>>> Â Â <key-map field-name="orderId"/>
>>>>>>> Â </relation>
>>>>>>> Â <relation type="many" rel-entity-name="OrderItemAndShipGroupAssoc">
>>>>>>> Â Â <key-map field-name="orderId"/>
>>>>>>> Â </relation>
>>>>>>> Â <index name="ORDEREXT_ID_IDX">
>>>>>>> Â Â <index-field name="externalId"/>
>>>>>>> Â </index>
>>>>>>> Â </entity>
>>>>>>>
>>>>>>> In order to enrich the definition (metadata) with more information, I
>>>>>>> am
>>>>>>> considering to put more tags (please find elements surrounded with
>>>>>>> !!!!!!!!!!!!!!!!!!!!!), like:
>>>>>>>
>>>>>>> Â <entity entity-name="OrderHeader"
>>>>>>> Â Â Â Â package-name="org.ofbiz.order.order"
>>>>>>> Â Â Â Â never-cache="true"
>>>>>>> Â Â Â Â title="Order Header Entity">
>>>>>>> Â <field name="orderId" type="id-ne"></field>
>>>>>>> Â <field name="orderTypeId" type="id"></field>
>>>>>>> Â <field name="orderName" type="name"></field>
>>>>>>>
>>>>>>>
>>>>>>> Â <!- !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
>>>>>>> Â <field name="externalId" type="id">
>>>>>>> Â Â Â Â <!-
>>>>>>> Â Â Â Â Â Â We can use "visiblity" tag to tell system when to show
>>>>>>> this
>>>>>>> field in UI layer.
>>>>>>> Â Â Â Â ->
>>>>>>> Â Â Â Â <visbility>
>>>>>>> Â Â Â Â Â Â <condition
>>>>>>> implementation="org.ofbiz.core.condition.NonEmptyField"/>
>>>>>>> Â Â Â Â </visbility>
>>>>>>> Â Â Â Â <validity type="clientSide">
>>>>>>> Â Â Â Â Â Â <condition notEqual="111"/>
>>>>>>> Â Â Â Â </validity>
>>>>>>> Â </field>
>>>>>>> Â !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! ->
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Â <field name="salesChannelEnumId" type="id"></field>
>>>>>>> Â <field name="orderDate" type="date-time"></field>
>>>>>>> Â <field name="entryDate" type="date-time"></field>
>>>>>>> Â <field name="visitId" type="id"></field>
>>>>>>> Â <field name="statusId" type="id"></field>
>>>>>>> Â <field name="createdBy" type="id-vlong"></field>
>>>>>>> Â <field name="firstAttemptOrderId" type="id"></field>
>>>>>>> Â <field name="currencyUom" type="id"></field>
>>>>>>> Â <field name="syncStatusId" type="id"></field>
>>>>>>> Â <field name="billingAccountId" type="id"></field>
>>>>>>> Â <field name="originFacilityId" type="id"></field>
>>>>>>> Â <field name="webSiteId" type="id"></field>
>>>>>>> Â <field name="productStoreId" type="id"></field>
>>>>>>> Â <field name="terminalId" type="id-long"></field>
>>>>>>> Â <field name="transactionId" type="id-long"></field>
>>>>>>> Â <field name="autoOrderShoppingListId" type="id"></field>
>>>>>>> Â <field name="needsInventoryIssuance" type="indicator"></field>
>>>>>>> Â <field name="isRushOrder" type="indicator"></field>
>>>>>>> Â <field name="internalCode" type="id-long"></field>
>>>>>>> Â <field name="remainingSubTotal" type="currency-amount"></field>
>>>>>>> Â <field name="grandTotal" type="currency-amount"></field>
>>>>>>> Â <prim-key field="orderId"/>
>>>>>>> Â <relation type="one" fk-name="ORDER_HDR_TYPE"
>>>>>>> rel-entity-name="OrderType">
>>>>>>> Â Â <key-map field-name="orderTypeId"/>
>>>>>>> Â </relation>
>>>>>>> Â <relation type="one" fk-name="ORDER_HDR_SCENUM" title="SalesChannel"
>>>>>>> rel-entity-name="Enumeration">
>>>>>>> Â Â <key-map field-name="salesChannelEnumId" rel-field-name="enumId"/>
>>>>>>> Â </relation>
>>>>>>> Â <relation type="one" fk-name="ORDER_HDR_OFAC" title="Origin"
>>>>>>> rel-entity-name="Facility">
>>>>>>> Â Â <key-map field-name="originFacilityId"
>>>>>>> rel-field-name="facilityId"/>
>>>>>>> Â </relation>
>>>>>>> Â <relation type="many" rel-entity-name="OrderTypeAttr">
>>>>>>> Â Â <key-map field-name="orderTypeId"/>
>>>>>>> Â </relation>
>>>>>>> Â <relation type="one" fk-name="ORDER_HDR_BACCT"
>>>>>>> rel-entity-name="BillingAccount">
>>>>>>> Â Â <key-map field-name="billingAccountId"/>
>>>>>>> Â </relation>
>>>>>>> Â <relation type="one" fk-name="ORDER_HDR_PDSTR"
>>>>>>> rel-entity-name="ProductStore">
>>>>>>> Â Â <key-map field-name="productStoreId"/>
>>>>>>> Â </relation>
>>>>>>> Â <relation type="one" fk-name="ORDER_HDR_AOSHLST" title="AutoOrder"
>>>>>>> rel-entity-name="ShoppingList">
>>>>>>> Â Â <key-map field-name="autoOrderShoppingListId"
>>>>>>> rel-field-name="shoppingListId"/>
>>>>>>> Â </relation>
>>>>>>> Â <relation type="one" fk-name="ORDER_HDR_CBUL" title="CreatedBy"
>>>>>>> rel-entity-name="UserLogin">
>>>>>>> Â Â <key-map field-name="createdBy" rel-field-name="userLoginId"/>
>>>>>>> Â </relation>
>>>>>>> Â <relation type="one" fk-name="ORDER_HDR_STTS"
>>>>>>> rel-entity-name="StatusItem">
>>>>>>> Â Â <key-map field-name="statusId"/>
>>>>>>> Â </relation>
>>>>>>> Â <relation type="one" fk-name="ORDER_HDR_SYST" title="Sync"
>>>>>>> rel-entity-name="StatusItem">
>>>>>>> Â Â <key-map field-name="syncStatusId" rel-field-name="statusId"/>
>>>>>>> Â </relation>
>>>>>>> Â <relation type="one" fk-name="ORDER_HDR_CUOM" rel-entity-name="Uom">
>>>>>>> Â Â <key-map field-name="currencyUom" rel-field-name="uomId"/>
>>>>>>> Â </relation>
>>>>>>> Â <relation type="many" rel-entity-name="OrderHeaderNoteView">
>>>>>>> Â Â <key-map field-name="orderId"/>
>>>>>>> Â </relation>
>>>>>>> Â <relation type="many" rel-entity-name="OrderItemAndShipGroupAssoc">
>>>>>>> Â Â <key-map field-name="orderId"/>
>>>>>>> Â </relation>
>>>>>>> Â <index name="ORDEREXT_ID_IDX">
>>>>>>> Â Â <index-field name="externalId"/>
>>>>>>> Â </index>
>>>>>>>
>>>>>>>
>>>>>>> Â <!- !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
>>>>>>> Â <!-
>>>>>>> Â Â Â In different context, maybe different set of fields need to show.
>>>>>>> So my idea
>>>>>>> Â Â Â here is to use "group" to group fields for different scenario.
>>>>>>> And
>>>>>>> then in UI
>>>>>>> Â Â Â level, we can define a jsp tag or something to only show fields
>>>>>>> within this group.
>>>>>>> Â Â ->
>>>>>>> Â <group name="summary">
>>>>>>> Â Â Â Â <field name="orderId" rank="1"/>
>>>>>>> Â Â Â <field name="orderTypeId" rank="10"/>
>>>>>>> Â Â Â <field name="orderName" rank="11"/>
>>>>>>> Â </group>
>>>>>>>
>>>>>>> Â <group name="details">
>>>>>>> Â Â Â <field name="orderId" rank="1"/>
>>>>>>> Â Â Â <field name="orderTypeId" rank="10"/>
>>>>>>> Â Â Â <field name="orderName" rank="11"/>
>>>>>>> Â Â Â <field name="externalId" rank="20">
>>>>>>> Â Â Â Â Â <!-
>>>>>>> Â Â Â Â Â Â Â !!!!Note: Though visibility is definded above with
>>>>>>> another
>>>>>>> condition. However, in this group
>>>>>>> Â Â Â Â Â Â Â Â Â Â Â Â Â (Scenario), externalID will always be
>>>>>>> visible.
>>>>>>> Â Â Â Â Â ->
>>>>>>> Â Â Â Â Â <visbility value="true"/>
>>>>>>> Â Â Â <field>
>>>>>>> Â </group>
>>>>>>> Â !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!->
>>>>>>> Â </entity>
>>>>>>>
>>>>>>> Such an idea to make entity definition as a single point of
>>>>>>> configuration/customization might make system easier to
>>>>>>> maintain/customize.
>>>>>>> Am I right? If yes, anybody could suggest me how to implement it.
>>>>>>>
>>>>>>> (BTW: we are going to use ofbiz entity engine for our products just
>>>>>>> like
>>>>>>> what JIRA did. It would be great if such enhancement could be done
>>>>>>> direct
>>>>>>> under apache. Otherwise, we might have to maintain a customized ofbiz
>>>>>>> entity
>>>>>>> engine by ourselves.)
>>>>>>>
>>>>>>> --
>>>>>>> Regards,
>>>>>>> Michael Xu (xudong)
>>>>>>> www.wizitsoft.com | Office: (8610) 6267 0615 ext 806 | Mobile: (86)
>>>>>>> 135
>>>>>>> 0135
>>>>>>> 9807 | Fax: (8610) 62670096
>>>>>>>
>>>>>>> Â --
>>>>>> Antwebsystems.com: Quality OFBiz services for competitive rates
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>
>>
>
Re: about entity engine
Posted by "Michael Xu (xudong)" <do...@wizitsoft.com>.
BTW, I think My idea can be implemented in a backword compatible way. So at
least that will be another choice to implement new ofbiz applications.
--
Regards,
Michael Xu (xudong)
www.wizitsoft.com | Office: (8610) 6267 0615 ext 806 | Mobile: (86) 135 0135
9807 | Fax: (8610) 62670096
On Fri, Oct 16, 2009 at 2:42 PM, Michael Xu (xudong)
<do...@wizitsoft.com>wrote:
> hi Scott,
>
> Thanks. Please see my inline comments.
>
> --
> Regards,
> Michael Xu (xudong)
> www.wizitsoft.com | Office: (8610) 6267 0615 ext 806 | Mobile: (86) 135
> 0135 9807 | Fax: (8610) 62670096
>
>
> On Fri, Oct 16, 2009 at 2:14 PM, Scott Gray <sc...@hotwaxmedia.com>wrote:
>
>> The problem is that with a generic data model many entities are used in
>> many different places and in different contexts,
>
>
> My idea is to use different GROUPs for different contexts.
>
>
>> if you tried to encapsulate all of those differences within a single
>> entity definition you are very quickly going to end up with a very messy
>> entity model.
>
>
> Yes, you are right. Can we split a big entity definition file into many?
> Does it help?
>
>
>> IMO separation of concerns is a good thing, you're complaining about
>> having to make changes in many places, but at least you know what effect
>> each change is having, in your model I would need to check everywhere that
>> an entity is used before making a change to be sure of what effect a
>> seemingly minor adjustment would have.
>>
>> I think GROUP is a way to control such affects, because GROUP will be used
> in UI in my idea.
>
> The pain point with current design is that the developer (for some
> customers, we even cannot assume they have a java developer) has to
> understand the overall infrastructure for such minor customization.
>
> But if we put them in one place using xml format, even a business guy can
> implement such customization without any java knowledge.
>
> For senior ofbiz developers, like you, the current design is very flexible.
> But it might be another story for other people.
>
>
>> Regards
>> Scott
>>
>>
>> On 16/10/2009, at 6:58 PM, Michael Xu (xudong) wrote:
>>
>> hi Scott,
>>>
>>> I got your points. Actually, form widgets are still required to show the
>>> GROUP with a set of predefined fields. But such form widget will be very
>>> generic, which is just show the group in the way defined in the entity
>>> model. And as such the benefits are:
>>> 1) a single point to define entity behavior (not just data structure)
>>> 2) UI gets configurable directly in the single point (no need to change
>>> form
>>> widgets or ftl in many places)
>>> 3) less java codes and widgets are required.
>>>
>>> In a summary, bringing more power to entity definition.
>>>
>>> --
>>> Regards,
>>> Michael Xu (xudong)
>>> www.wizitsoft.com | Office: (8610) 6267 0615 ext 806 | Mobile: (86) 135
>>> 0135
>>> 9807 | Fax: (8610) 62670096
>>>
>>>
>>> On Fri, Oct 16, 2009 at 1:39 PM, Scott Gray <scott.gray@hotwaxmedia.com
>>> >wrote:
>>>
>>> I think to be able to generate a reasonably functional UI from something
>>>> like this you'd end up with so much complexity in your entity model that
>>>> someone would come up with a new idea to solve that problem and they'd
>>>> call
>>>> it the form widget.
>>>>
>>>> Regards
>>>> Scott
>>>>
>>>> HotWax Media
>>>> http://www.hotwaxmedia.com
>>>>
>>>>
>>>> On 16/10/2009, at 5:22 PM, Hans Bakker wrote:
>>>>
>>>> In general, this looks like a pretty good idea.
>>>>
>>>>>
>>>>> The visibility tag would be nice if the widgets took advantage of
>>>>> that.
>>>>> then i would be easy to let a field disappear in the whole system when
>>>>> a
>>>>> if a simple 'true/false' would be possible.
>>>>>
>>>>> More complicated ones like the ones mentioned below could also be
>>>>> interesting but the integration in the widgets is a must. ftl's will me
>>>>> more difficult (macros), jsp, not sure if we should support that.
>>>>>
>>>>> trigger and validation will be more complex but sure we could look at
>>>>> that.
>>>>>
>>>>> In general a good idea
>>>>>
>>>>> Regards,
>>>>> Hans
>>>>>
>>>>>
>>>>> On Fri, 2009-10-16 at 05:16 +0800, Michael Xu (xudong) wrote:
>>>>>
>>>>> hi all,
>>>>>>
>>>>>> We can define entities in XML files. However, only database specific
>>>>>> semantics could be defined there. For those application level
>>>>>> semantics
>>>>>> (like trigger, visiblity, validation) has to be defined in different
>>>>>> places.
>>>>>> The lack of a single place to define such metadata makes ofbiz hard to
>>>>>> maintain. (Correct me if I am wrong)
>>>>>>
>>>>>> Let's take OrderHeader as an example. I copy the latest entity
>>>>>> definition
>>>>>> as
>>>>>> below:
>>>>>>
>>>>>> <entity entity-name="OrderHeader"
>>>>>> package-name="org.ofbiz.order.order"
>>>>>> never-cache="true"
>>>>>> title="Order Header Entity">
>>>>>> <field name="orderId" type="id-ne"></field>
>>>>>> <field name="orderTypeId" type="id"></field>
>>>>>> <field name="orderName" type="name"></field>
>>>>>> <field name="externalId" type="id"></field>
>>>>>> <field name="salesChannelEnumId" type="id"></field>
>>>>>> <field name="orderDate" type="date-time"></field>
>>>>>> <field name="entryDate" type="date-time"></field>
>>>>>> <field name="visitId" type="id"></field>
>>>>>> <field name="statusId" type="id"></field>
>>>>>> <field name="createdBy" type="id-vlong"></field>
>>>>>> <field name="firstAttemptOrderId" type="id"></field>
>>>>>> <field name="currencyUom" type="id"></field>
>>>>>> <field name="syncStatusId" type="id"></field>
>>>>>> <field name="billingAccountId" type="id"></field>
>>>>>> <field name="originFacilityId" type="id"></field>
>>>>>> <field name="webSiteId" type="id"></field>
>>>>>> <field name="productStoreId" type="id"></field>
>>>>>> <field name="terminalId" type="id-long"></field>
>>>>>> <field name="transactionId" type="id-long"></field>
>>>>>> <field name="autoOrderShoppingListId" type="id"></field>
>>>>>> <field name="needsInventoryIssuance" type="indicator"></field>
>>>>>> <field name="isRushOrder" type="indicator"></field>
>>>>>> <field name="internalCode" type="id-long"></field>
>>>>>> <field name="remainingSubTotal" type="currency-amount"></field>
>>>>>> <field name="grandTotal" type="currency-amount"></field>
>>>>>> <prim-key field="orderId"/>
>>>>>> <relation type="one" fk-name="ORDER_HDR_TYPE"
>>>>>> rel-entity-name="OrderType">
>>>>>> <key-map field-name="orderTypeId"/>
>>>>>> </relation>
>>>>>> <relation type="one" fk-name="ORDER_HDR_SCENUM" title="SalesChannel"
>>>>>> rel-entity-name="Enumeration">
>>>>>> <key-map field-name="salesChannelEnumId" rel-field-name="enumId"/>
>>>>>> </relation>
>>>>>> <relation type="one" fk-name="ORDER_HDR_OFAC" title="Origin"
>>>>>> rel-entity-name="Facility">
>>>>>> <key-map field-name="originFacilityId"
>>>>>> rel-field-name="facilityId"/>
>>>>>> </relation>
>>>>>> <relation type="many" rel-entity-name="OrderTypeAttr">
>>>>>> <key-map field-name="orderTypeId"/>
>>>>>> </relation>
>>>>>> <relation type="one" fk-name="ORDER_HDR_BACCT"
>>>>>> rel-entity-name="BillingAccount">
>>>>>> <key-map field-name="billingAccountId"/>
>>>>>> </relation>
>>>>>> <relation type="one" fk-name="ORDER_HDR_PDSTR"
>>>>>> rel-entity-name="ProductStore">
>>>>>> <key-map field-name="productStoreId"/>
>>>>>> </relation>
>>>>>> <relation type="one" fk-name="ORDER_HDR_AOSHLST" title="AutoOrder"
>>>>>> rel-entity-name="ShoppingList">
>>>>>> <key-map field-name="autoOrderShoppingListId"
>>>>>> rel-field-name="shoppingListId"/>
>>>>>> </relation>
>>>>>> <relation type="one" fk-name="ORDER_HDR_CBUL" title="CreatedBy"
>>>>>> rel-entity-name="UserLogin">
>>>>>> <key-map field-name="createdBy" rel-field-name="userLoginId"/>
>>>>>> </relation>
>>>>>> <relation type="one" fk-name="ORDER_HDR_STTS"
>>>>>> rel-entity-name="StatusItem">
>>>>>> <key-map field-name="statusId"/>
>>>>>> </relation>
>>>>>> <relation type="one" fk-name="ORDER_HDR_SYST" title="Sync"
>>>>>> rel-entity-name="StatusItem">
>>>>>> <key-map field-name="syncStatusId" rel-field-name="statusId"/>
>>>>>> </relation>
>>>>>> <relation type="one" fk-name="ORDER_HDR_CUOM" rel-entity-name="Uom">
>>>>>> <key-map field-name="currencyUom" rel-field-name="uomId"/>
>>>>>> </relation>
>>>>>> <relation type="many" rel-entity-name="OrderHeaderNoteView">
>>>>>> <key-map field-name="orderId"/>
>>>>>> </relation>
>>>>>> <relation type="many" rel-entity-name="OrderItemAndShipGroupAssoc">
>>>>>> <key-map field-name="orderId"/>
>>>>>> </relation>
>>>>>> <index name="ORDEREXT_ID_IDX">
>>>>>> <index-field name="externalId"/>
>>>>>> </index>
>>>>>> </entity>
>>>>>>
>>>>>> In order to enrich the definition (metadata) with more information, I
>>>>>> am
>>>>>> considering to put more tags (please find elements surrounded with
>>>>>> !!!!!!!!!!!!!!!!!!!!!), like:
>>>>>>
>>>>>> <entity entity-name="OrderHeader"
>>>>>> package-name="org.ofbiz.order.order"
>>>>>> never-cache="true"
>>>>>> title="Order Header Entity">
>>>>>> <field name="orderId" type="id-ne"></field>
>>>>>> <field name="orderTypeId" type="id"></field>
>>>>>> <field name="orderName" type="name"></field>
>>>>>>
>>>>>>
>>>>>> <!- !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
>>>>>> <field name="externalId" type="id">
>>>>>> <!-
>>>>>> We can use "visiblity" tag to tell system when to show
>>>>>> this
>>>>>> field in UI layer.
>>>>>> ->
>>>>>> <visbility>
>>>>>> <condition
>>>>>> implementation="org.ofbiz.core.condition.NonEmptyField"/>
>>>>>> </visbility>
>>>>>> <validity type="clientSide">
>>>>>> <condition notEqual="111"/>
>>>>>> </validity>
>>>>>> </field>
>>>>>> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! ->
>>>>>>
>>>>>>
>>>>>>
>>>>>> <field name="salesChannelEnumId" type="id"></field>
>>>>>> <field name="orderDate" type="date-time"></field>
>>>>>> <field name="entryDate" type="date-time"></field>
>>>>>> <field name="visitId" type="id"></field>
>>>>>> <field name="statusId" type="id"></field>
>>>>>> <field name="createdBy" type="id-vlong"></field>
>>>>>> <field name="firstAttemptOrderId" type="id"></field>
>>>>>> <field name="currencyUom" type="id"></field>
>>>>>> <field name="syncStatusId" type="id"></field>
>>>>>> <field name="billingAccountId" type="id"></field>
>>>>>> <field name="originFacilityId" type="id"></field>
>>>>>> <field name="webSiteId" type="id"></field>
>>>>>> <field name="productStoreId" type="id"></field>
>>>>>> <field name="terminalId" type="id-long"></field>
>>>>>> <field name="transactionId" type="id-long"></field>
>>>>>> <field name="autoOrderShoppingListId" type="id"></field>
>>>>>> <field name="needsInventoryIssuance" type="indicator"></field>
>>>>>> <field name="isRushOrder" type="indicator"></field>
>>>>>> <field name="internalCode" type="id-long"></field>
>>>>>> <field name="remainingSubTotal" type="currency-amount"></field>
>>>>>> <field name="grandTotal" type="currency-amount"></field>
>>>>>> <prim-key field="orderId"/>
>>>>>> <relation type="one" fk-name="ORDER_HDR_TYPE"
>>>>>> rel-entity-name="OrderType">
>>>>>> <key-map field-name="orderTypeId"/>
>>>>>> </relation>
>>>>>> <relation type="one" fk-name="ORDER_HDR_SCENUM" title="SalesChannel"
>>>>>> rel-entity-name="Enumeration">
>>>>>> <key-map field-name="salesChannelEnumId" rel-field-name="enumId"/>
>>>>>> </relation>
>>>>>> <relation type="one" fk-name="ORDER_HDR_OFAC" title="Origin"
>>>>>> rel-entity-name="Facility">
>>>>>> <key-map field-name="originFacilityId"
>>>>>> rel-field-name="facilityId"/>
>>>>>> </relation>
>>>>>> <relation type="many" rel-entity-name="OrderTypeAttr">
>>>>>> <key-map field-name="orderTypeId"/>
>>>>>> </relation>
>>>>>> <relation type="one" fk-name="ORDER_HDR_BACCT"
>>>>>> rel-entity-name="BillingAccount">
>>>>>> <key-map field-name="billingAccountId"/>
>>>>>> </relation>
>>>>>> <relation type="one" fk-name="ORDER_HDR_PDSTR"
>>>>>> rel-entity-name="ProductStore">
>>>>>> <key-map field-name="productStoreId"/>
>>>>>> </relation>
>>>>>> <relation type="one" fk-name="ORDER_HDR_AOSHLST" title="AutoOrder"
>>>>>> rel-entity-name="ShoppingList">
>>>>>> <key-map field-name="autoOrderShoppingListId"
>>>>>> rel-field-name="shoppingListId"/>
>>>>>> </relation>
>>>>>> <relation type="one" fk-name="ORDER_HDR_CBUL" title="CreatedBy"
>>>>>> rel-entity-name="UserLogin">
>>>>>> <key-map field-name="createdBy" rel-field-name="userLoginId"/>
>>>>>> </relation>
>>>>>> <relation type="one" fk-name="ORDER_HDR_STTS"
>>>>>> rel-entity-name="StatusItem">
>>>>>> <key-map field-name="statusId"/>
>>>>>> </relation>
>>>>>> <relation type="one" fk-name="ORDER_HDR_SYST" title="Sync"
>>>>>> rel-entity-name="StatusItem">
>>>>>> <key-map field-name="syncStatusId" rel-field-name="statusId"/>
>>>>>> </relation>
>>>>>> <relation type="one" fk-name="ORDER_HDR_CUOM" rel-entity-name="Uom">
>>>>>> <key-map field-name="currencyUom" rel-field-name="uomId"/>
>>>>>> </relation>
>>>>>> <relation type="many" rel-entity-name="OrderHeaderNoteView">
>>>>>> <key-map field-name="orderId"/>
>>>>>> </relation>
>>>>>> <relation type="many" rel-entity-name="OrderItemAndShipGroupAssoc">
>>>>>> <key-map field-name="orderId"/>
>>>>>> </relation>
>>>>>> <index name="ORDEREXT_ID_IDX">
>>>>>> <index-field name="externalId"/>
>>>>>> </index>
>>>>>>
>>>>>>
>>>>>> <!- !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
>>>>>> <!-
>>>>>> In different context, maybe different set of fields need to show.
>>>>>> So my idea
>>>>>> here is to use "group" to group fields for different scenario.
>>>>>> And
>>>>>> then in UI
>>>>>> level, we can define a jsp tag or something to only show fields
>>>>>> within this group.
>>>>>> ->
>>>>>> <group name="summary">
>>>>>> <field name="orderId" rank="1"/>
>>>>>> <field name="orderTypeId" rank="10"/>
>>>>>> <field name="orderName" rank="11"/>
>>>>>> </group>
>>>>>>
>>>>>> <group name="details">
>>>>>> <field name="orderId" rank="1"/>
>>>>>> <field name="orderTypeId" rank="10"/>
>>>>>> <field name="orderName" rank="11"/>
>>>>>> <field name="externalId" rank="20">
>>>>>> <!-
>>>>>> !!!!Note: Though visibility is definded above with
>>>>>> another
>>>>>> condition. However, in this group
>>>>>> (Scenario), externalID will always be
>>>>>> visible.
>>>>>> ->
>>>>>> <visbility value="true"/>
>>>>>> <field>
>>>>>> </group>
>>>>>> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!->
>>>>>> </entity>
>>>>>>
>>>>>> Such an idea to make entity definition as a single point of
>>>>>> configuration/customization might make system easier to
>>>>>> maintain/customize.
>>>>>> Am I right? If yes, anybody could suggest me how to implement it.
>>>>>>
>>>>>> (BTW: we are going to use ofbiz entity engine for our products just
>>>>>> like
>>>>>> what JIRA did. It would be great if such enhancement could be done
>>>>>> direct
>>>>>> under apache. Otherwise, we might have to maintain a customized ofbiz
>>>>>> entity
>>>>>> engine by ourselves.)
>>>>>>
>>>>>> --
>>>>>> Regards,
>>>>>> Michael Xu (xudong)
>>>>>> www.wizitsoft.com | Office: (8610) 6267 0615 ext 806 | Mobile: (86)
>>>>>> 135
>>>>>> 0135
>>>>>> 9807 | Fax: (8610) 62670096
>>>>>>
>>>>>> --
>>>>> Antwebsystems.com: Quality OFBiz services for competitive rates
>>>>>
>>>>>
>>>>>
>>>>
>>
>
Re: about entity engine
Posted by Malin Nicolas <ma...@librenberry.net>.
Hi Michael,
I'm surprise by your enchancement. In ERP structure it's dangerous to
mix the data layer with information use by UI layer. I understand your
purpose, but I think that isn't the good solution to do that.
In Neogia, we rebuild all generation structure to use entity model as
MDA schema but all UI tag as your visibility element are contains in
specific file for don't touch the OFBiz principle.
Nicolas
Michael Xu (xudong) a écrit :
> hi Scott,
>
> Thanks. Please see my inline comments.
>
> --
> Regards,
> Michael Xu (xudong)
> www.wizitsoft.com | Office: (8610) 6267 0615 ext 806 | Mobile: (86) 135 0135
> 9807 | Fax: (8610) 62670096
>
>
> On Fri, Oct 16, 2009 at 2:14 PM, Scott Gray <sc...@hotwaxmedia.com>wrote:
>
>
>> The problem is that with a generic data model many entities are used in
>> many different places and in different contexts,
>>
>
>
> My idea is to use different GROUPs for different contexts.
>
>
>
>> if you tried to encapsulate all of those differences within a single entity
>> definition you are very quickly going to end up with a very messy entity
>> model.
>>
>
>
> Yes, you are right. Can we split a big entity definition file into many?
> Does it help?
>
>
>
>> IMO separation of concerns is a good thing, you're complaining about having
>> to make changes in many places, but at least you know what effect each
>> change is having, in your model I would need to check everywhere that an
>> entity is used before making a change to be sure of what effect a seemingly
>> minor adjustment would have.
>>
>> I think GROUP is a way to control such affects, because GROUP will be used
>>
> in UI in my idea.
>
> The pain point with current design is that the developer (for some
> customers, we even cannot assume they have a java developer) has to
> understand the overall infrastructure for such minor customization.
>
> But if we put them in one place using xml format, even a business guy can
> implement such customization without any java knowledge.
>
> For senior ofbiz developers, like you, the current design is very flexible.
> But it might be another story for other people.
>
>
>
>> Regards
>> Scott
>>
>>
>> On 16/10/2009, at 6:58 PM, Michael Xu (xudong) wrote:
>>
>> hi Scott,
>>
>>> I got your points. Actually, form widgets are still required to show the
>>> GROUP with a set of predefined fields. But such form widget will be very
>>> generic, which is just show the group in the way defined in the entity
>>> model. And as such the benefits are:
>>> 1) a single point to define entity behavior (not just data structure)
>>> 2) UI gets configurable directly in the single point (no need to change
>>> form
>>> widgets or ftl in many places)
>>> 3) less java codes and widgets are required.
>>>
>>> In a summary, bringing more power to entity definition.
>>>
>>> --
>>> Regards,
>>> Michael Xu (xudong)
>>> www.wizitsoft.com | Office: (8610) 6267 0615 ext 806 | Mobile: (86) 135
>>> 0135
>>> 9807 | Fax: (8610) 62670096
>>>
>>>
>>> On Fri, Oct 16, 2009 at 1:39 PM, Scott Gray <scott.gray@hotwaxmedia.com
>>>
>>>> wrote:
>>>>
>>> I think to be able to generate a reasonably functional UI from something
>>>
>>>> like this you'd end up with so much complexity in your entity model that
>>>> someone would come up with a new idea to solve that problem and they'd
>>>> call
>>>> it the form widget.
>>>>
>>>> Regards
>>>> Scott
>>>>
>>>> HotWax Media
>>>> http://www.hotwaxmedia.com
>>>>
>>>>
>>>> On 16/10/2009, at 5:22 PM, Hans Bakker wrote:
>>>>
>>>> In general, this looks like a pretty good idea.
>>>>
>>>>
>>>>> The visibility tag would be nice if the widgets took advantage of that.
>>>>> then i would be easy to let a field disappear in the whole system when a
>>>>> if a simple 'true/false' would be possible.
>>>>>
>>>>> More complicated ones like the ones mentioned below could also be
>>>>> interesting but the integration in the widgets is a must. ftl's will me
>>>>> more difficult (macros), jsp, not sure if we should support that.
>>>>>
>>>>> trigger and validation will be more complex but sure we could look at
>>>>> that.
>>>>>
>>>>> In general a good idea
>>>>>
>>>>> Regards,
>>>>> Hans
>>>>>
>>>>>
>>>>> On Fri, 2009-10-16 at 05:16 +0800, Michael Xu (xudong) wrote:
>>>>>
>>>>> hi all,
>>>>>
>>>>>> We can define entities in XML files. However, only database specific
>>>>>> semantics could be defined there. For those application level semantics
>>>>>> (like trigger, visiblity, validation) has to be defined in different
>>>>>> places.
>>>>>> The lack of a single place to define such metadata makes ofbiz hard to
>>>>>> maintain. (Correct me if I am wrong)
>>>>>>
>>>>>> Let's take OrderHeader as an example. I copy the latest entity
>>>>>> definition
>>>>>> as
>>>>>> below:
>>>>>>
>>>>>> <entity entity-name="OrderHeader"
>>>>>> package-name="org.ofbiz.order.order"
>>>>>> never-cache="true"
>>>>>> title="Order Header Entity">
>>>>>> <field name="orderId" type="id-ne"></field>
>>>>>> <field name="orderTypeId" type="id"></field>
>>>>>> <field name="orderName" type="name"></field>
>>>>>> <field name="externalId" type="id"></field>
>>>>>> <field name="salesChannelEnumId" type="id"></field>
>>>>>> <field name="orderDate" type="date-time"></field>
>>>>>> <field name="entryDate" type="date-time"></field>
>>>>>> <field name="visitId" type="id"></field>
>>>>>> <field name="statusId" type="id"></field>
>>>>>> <field name="createdBy" type="id-vlong"></field>
>>>>>> <field name="firstAttemptOrderId" type="id"></field>
>>>>>> <field name="currencyUom" type="id"></field>
>>>>>> <field name="syncStatusId" type="id"></field>
>>>>>> <field name="billingAccountId" type="id"></field>
>>>>>> <field name="originFacilityId" type="id"></field>
>>>>>> <field name="webSiteId" type="id"></field>
>>>>>> <field name="productStoreId" type="id"></field>
>>>>>> <field name="terminalId" type="id-long"></field>
>>>>>> <field name="transactionId" type="id-long"></field>
>>>>>> <field name="autoOrderShoppingListId" type="id"></field>
>>>>>> <field name="needsInventoryIssuance" type="indicator"></field>
>>>>>> <field name="isRushOrder" type="indicator"></field>
>>>>>> <field name="internalCode" type="id-long"></field>
>>>>>> <field name="remainingSubTotal" type="currency-amount"></field>
>>>>>> <field name="grandTotal" type="currency-amount"></field>
>>>>>> <prim-key field="orderId"/>
>>>>>> <relation type="one" fk-name="ORDER_HDR_TYPE"
>>>>>> rel-entity-name="OrderType">
>>>>>> <key-map field-name="orderTypeId"/>
>>>>>> </relation>
>>>>>> <relation type="one" fk-name="ORDER_HDR_SCENUM" title="SalesChannel"
>>>>>> rel-entity-name="Enumeration">
>>>>>> <key-map field-name="salesChannelEnumId" rel-field-name="enumId"/>
>>>>>> </relation>
>>>>>> <relation type="one" fk-name="ORDER_HDR_OFAC" title="Origin"
>>>>>> rel-entity-name="Facility">
>>>>>> <key-map field-name="originFacilityId"
>>>>>> rel-field-name="facilityId"/>
>>>>>> </relation>
>>>>>> <relation type="many" rel-entity-name="OrderTypeAttr">
>>>>>> <key-map field-name="orderTypeId"/>
>>>>>> </relation>
>>>>>> <relation type="one" fk-name="ORDER_HDR_BACCT"
>>>>>> rel-entity-name="BillingAccount">
>>>>>> <key-map field-name="billingAccountId"/>
>>>>>> </relation>
>>>>>> <relation type="one" fk-name="ORDER_HDR_PDSTR"
>>>>>> rel-entity-name="ProductStore">
>>>>>> <key-map field-name="productStoreId"/>
>>>>>> </relation>
>>>>>> <relation type="one" fk-name="ORDER_HDR_AOSHLST" title="AutoOrder"
>>>>>> rel-entity-name="ShoppingList">
>>>>>> <key-map field-name="autoOrderShoppingListId"
>>>>>> rel-field-name="shoppingListId"/>
>>>>>> </relation>
>>>>>> <relation type="one" fk-name="ORDER_HDR_CBUL" title="CreatedBy"
>>>>>> rel-entity-name="UserLogin">
>>>>>> <key-map field-name="createdBy" rel-field-name="userLoginId"/>
>>>>>> </relation>
>>>>>> <relation type="one" fk-name="ORDER_HDR_STTS"
>>>>>> rel-entity-name="StatusItem">
>>>>>> <key-map field-name="statusId"/>
>>>>>> </relation>
>>>>>> <relation type="one" fk-name="ORDER_HDR_SYST" title="Sync"
>>>>>> rel-entity-name="StatusItem">
>>>>>> <key-map field-name="syncStatusId" rel-field-name="statusId"/>
>>>>>> </relation>
>>>>>> <relation type="one" fk-name="ORDER_HDR_CUOM" rel-entity-name="Uom">
>>>>>> <key-map field-name="currencyUom" rel-field-name="uomId"/>
>>>>>> </relation>
>>>>>> <relation type="many" rel-entity-name="OrderHeaderNoteView">
>>>>>> <key-map field-name="orderId"/>
>>>>>> </relation>
>>>>>> <relation type="many" rel-entity-name="OrderItemAndShipGroupAssoc">
>>>>>> <key-map field-name="orderId"/>
>>>>>> </relation>
>>>>>> <index name="ORDEREXT_ID_IDX">
>>>>>> <index-field name="externalId"/>
>>>>>> </index>
>>>>>> </entity>
>>>>>>
>>>>>> In order to enrich the definition (metadata) with more information, I
>>>>>> am
>>>>>> considering to put more tags (please find elements surrounded with
>>>>>> !!!!!!!!!!!!!!!!!!!!!), like:
>>>>>>
>>>>>> <entity entity-name="OrderHeader"
>>>>>> package-name="org.ofbiz.order.order"
>>>>>> never-cache="true"
>>>>>> title="Order Header Entity">
>>>>>> <field name="orderId" type="id-ne"></field>
>>>>>> <field name="orderTypeId" type="id"></field>
>>>>>> <field name="orderName" type="name"></field>
>>>>>>
>>>>>>
>>>>>> <!- !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
>>>>>> <field name="externalId" type="id">
>>>>>> <!-
>>>>>> We can use "visiblity" tag to tell system when to show this
>>>>>> field in UI layer.
>>>>>> ->
>>>>>> <visbility>
>>>>>> <condition
>>>>>> implementation="org.ofbiz.core.condition.NonEmptyField"/>
>>>>>> </visbility>
>>>>>> <validity type="clientSide">
>>>>>> <condition notEqual="111"/>
>>>>>> </validity>
>>>>>> </field>
>>>>>> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! ->
>>>>>>
>>>>>>
>>>>>>
>>>>>> <field name="salesChannelEnumId" type="id"></field>
>>>>>> <field name="orderDate" type="date-time"></field>
>>>>>> <field name="entryDate" type="date-time"></field>
>>>>>> <field name="visitId" type="id"></field>
>>>>>> <field name="statusId" type="id"></field>
>>>>>> <field name="createdBy" type="id-vlong"></field>
>>>>>> <field name="firstAttemptOrderId" type="id"></field>
>>>>>> <field name="currencyUom" type="id"></field>
>>>>>> <field name="syncStatusId" type="id"></field>
>>>>>> <field name="billingAccountId" type="id"></field>
>>>>>> <field name="originFacilityId" type="id"></field>
>>>>>> <field name="webSiteId" type="id"></field>
>>>>>> <field name="productStoreId" type="id"></field>
>>>>>> <field name="terminalId" type="id-long"></field>
>>>>>> <field name="transactionId" type="id-long"></field>
>>>>>> <field name="autoOrderShoppingListId" type="id"></field>
>>>>>> <field name="needsInventoryIssuance" type="indicator"></field>
>>>>>> <field name="isRushOrder" type="indicator"></field>
>>>>>> <field name="internalCode" type="id-long"></field>
>>>>>> <field name="remainingSubTotal" type="currency-amount"></field>
>>>>>> <field name="grandTotal" type="currency-amount"></field>
>>>>>> <prim-key field="orderId"/>
>>>>>> <relation type="one" fk-name="ORDER_HDR_TYPE"
>>>>>> rel-entity-name="OrderType">
>>>>>> <key-map field-name="orderTypeId"/>
>>>>>> </relation>
>>>>>> <relation type="one" fk-name="ORDER_HDR_SCENUM" title="SalesChannel"
>>>>>> rel-entity-name="Enumeration">
>>>>>> <key-map field-name="salesChannelEnumId" rel-field-name="enumId"/>
>>>>>> </relation>
>>>>>> <relation type="one" fk-name="ORDER_HDR_OFAC" title="Origin"
>>>>>> rel-entity-name="Facility">
>>>>>> <key-map field-name="originFacilityId"
>>>>>> rel-field-name="facilityId"/>
>>>>>> </relation>
>>>>>> <relation type="many" rel-entity-name="OrderTypeAttr">
>>>>>> <key-map field-name="orderTypeId"/>
>>>>>> </relation>
>>>>>> <relation type="one" fk-name="ORDER_HDR_BACCT"
>>>>>> rel-entity-name="BillingAccount">
>>>>>> <key-map field-name="billingAccountId"/>
>>>>>> </relation>
>>>>>> <relation type="one" fk-name="ORDER_HDR_PDSTR"
>>>>>> rel-entity-name="ProductStore">
>>>>>> <key-map field-name="productStoreId"/>
>>>>>> </relation>
>>>>>> <relation type="one" fk-name="ORDER_HDR_AOSHLST" title="AutoOrder"
>>>>>> rel-entity-name="ShoppingList">
>>>>>> <key-map field-name="autoOrderShoppingListId"
>>>>>> rel-field-name="shoppingListId"/>
>>>>>> </relation>
>>>>>> <relation type="one" fk-name="ORDER_HDR_CBUL" title="CreatedBy"
>>>>>> rel-entity-name="UserLogin">
>>>>>> <key-map field-name="createdBy" rel-field-name="userLoginId"/>
>>>>>> </relation>
>>>>>> <relation type="one" fk-name="ORDER_HDR_STTS"
>>>>>> rel-entity-name="StatusItem">
>>>>>> <key-map field-name="statusId"/>
>>>>>> </relation>
>>>>>> <relation type="one" fk-name="ORDER_HDR_SYST" title="Sync"
>>>>>> rel-entity-name="StatusItem">
>>>>>> <key-map field-name="syncStatusId" rel-field-name="statusId"/>
>>>>>> </relation>
>>>>>> <relation type="one" fk-name="ORDER_HDR_CUOM" rel-entity-name="Uom">
>>>>>> <key-map field-name="currencyUom" rel-field-name="uomId"/>
>>>>>> </relation>
>>>>>> <relation type="many" rel-entity-name="OrderHeaderNoteView">
>>>>>> <key-map field-name="orderId"/>
>>>>>> </relation>
>>>>>> <relation type="many" rel-entity-name="OrderItemAndShipGroupAssoc">
>>>>>> <key-map field-name="orderId"/>
>>>>>> </relation>
>>>>>> <index name="ORDEREXT_ID_IDX">
>>>>>> <index-field name="externalId"/>
>>>>>> </index>
>>>>>>
>>>>>>
>>>>>> <!- !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
>>>>>> <!-
>>>>>> In different context, maybe different set of fields need to show.
>>>>>> So my idea
>>>>>> here is to use "group" to group fields for different scenario. And
>>>>>> then in UI
>>>>>> level, we can define a jsp tag or something to only show fields
>>>>>> within this group.
>>>>>> ->
>>>>>> <group name="summary">
>>>>>> <field name="orderId" rank="1"/>
>>>>>> <field name="orderTypeId" rank="10"/>
>>>>>> <field name="orderName" rank="11"/>
>>>>>> </group>
>>>>>>
>>>>>> <group name="details">
>>>>>> <field name="orderId" rank="1"/>
>>>>>> <field name="orderTypeId" rank="10"/>
>>>>>> <field name="orderName" rank="11"/>
>>>>>> <field name="externalId" rank="20">
>>>>>> <!-
>>>>>> !!!!Note: Though visibility is definded above with another
>>>>>> condition. However, in this group
>>>>>> (Scenario), externalID will always be
>>>>>> visible.
>>>>>> ->
>>>>>> <visbility value="true"/>
>>>>>> <field>
>>>>>> </group>
>>>>>> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!->
>>>>>> </entity>
>>>>>>
>>>>>> Such an idea to make entity definition as a single point of
>>>>>> configuration/customization might make system easier to
>>>>>> maintain/customize.
>>>>>> Am I right? If yes, anybody could suggest me how to implement it.
>>>>>>
>>>>>> (BTW: we are going to use ofbiz entity engine for our products just
>>>>>> like
>>>>>> what JIRA did. It would be great if such enhancement could be done
>>>>>> direct
>>>>>> under apache. Otherwise, we might have to maintain a customized ofbiz
>>>>>> entity
>>>>>> engine by ourselves.)
>>>>>>
>>>>>> --
>>>>>> Regards,
>>>>>> Michael Xu (xudong)
>>>>>> www.wizitsoft.com | Office: (8610) 6267 0615 ext 806 | Mobile: (86)
>>>>>> 135
>>>>>> 0135
>>>>>> 9807 | Fax: (8610) 62670096
>>>>>>
>>>>>> --
>>>>>>
>>>>> Antwebsystems.com: Quality OFBiz services for competitive rates
>>>>>
>>>>>
>>>>>
>>>>>
>
>
--
Nicolas MALIN
Consultant
Tél : 06.17.66.40.06
Site projet : http://www.neogia.org/
-------
Société LibrenBerry
Tél : 02.48.02.56.12
Site : http://www.librenberry.net/
Re: about entity engine
Posted by "Michael Xu (xudong)" <do...@wizitsoft.com>.
hi Scott,
Thanks. Please see my inline comments.
--
Regards,
Michael Xu (xudong)
www.wizitsoft.com | Office: (8610) 6267 0615 ext 806 | Mobile: (86) 135 0135
9807 | Fax: (8610) 62670096
On Fri, Oct 16, 2009 at 2:14 PM, Scott Gray <sc...@hotwaxmedia.com>wrote:
> The problem is that with a generic data model many entities are used in
> many different places and in different contexts,
My idea is to use different GROUPs for different contexts.
> if you tried to encapsulate all of those differences within a single entity
> definition you are very quickly going to end up with a very messy entity
> model.
Yes, you are right. Can we split a big entity definition file into many?
Does it help?
> IMO separation of concerns is a good thing, you're complaining about having
> to make changes in many places, but at least you know what effect each
> change is having, in your model I would need to check everywhere that an
> entity is used before making a change to be sure of what effect a seemingly
> minor adjustment would have.
>
> I think GROUP is a way to control such affects, because GROUP will be used
in UI in my idea.
The pain point with current design is that the developer (for some
customers, we even cannot assume they have a java developer) has to
understand the overall infrastructure for such minor customization.
But if we put them in one place using xml format, even a business guy can
implement such customization without any java knowledge.
For senior ofbiz developers, like you, the current design is very flexible.
But it might be another story for other people.
> Regards
> Scott
>
>
> On 16/10/2009, at 6:58 PM, Michael Xu (xudong) wrote:
>
> hi Scott,
>>
>> I got your points. Actually, form widgets are still required to show the
>> GROUP with a set of predefined fields. But such form widget will be very
>> generic, which is just show the group in the way defined in the entity
>> model. And as such the benefits are:
>> 1) a single point to define entity behavior (not just data structure)
>> 2) UI gets configurable directly in the single point (no need to change
>> form
>> widgets or ftl in many places)
>> 3) less java codes and widgets are required.
>>
>> In a summary, bringing more power to entity definition.
>>
>> --
>> Regards,
>> Michael Xu (xudong)
>> www.wizitsoft.com | Office: (8610) 6267 0615 ext 806 | Mobile: (86) 135
>> 0135
>> 9807 | Fax: (8610) 62670096
>>
>>
>> On Fri, Oct 16, 2009 at 1:39 PM, Scott Gray <scott.gray@hotwaxmedia.com
>> >wrote:
>>
>> I think to be able to generate a reasonably functional UI from something
>>> like this you'd end up with so much complexity in your entity model that
>>> someone would come up with a new idea to solve that problem and they'd
>>> call
>>> it the form widget.
>>>
>>> Regards
>>> Scott
>>>
>>> HotWax Media
>>> http://www.hotwaxmedia.com
>>>
>>>
>>> On 16/10/2009, at 5:22 PM, Hans Bakker wrote:
>>>
>>> In general, this looks like a pretty good idea.
>>>
>>>>
>>>> The visibility tag would be nice if the widgets took advantage of that.
>>>> then i would be easy to let a field disappear in the whole system when a
>>>> if a simple 'true/false' would be possible.
>>>>
>>>> More complicated ones like the ones mentioned below could also be
>>>> interesting but the integration in the widgets is a must. ftl's will me
>>>> more difficult (macros), jsp, not sure if we should support that.
>>>>
>>>> trigger and validation will be more complex but sure we could look at
>>>> that.
>>>>
>>>> In general a good idea
>>>>
>>>> Regards,
>>>> Hans
>>>>
>>>>
>>>> On Fri, 2009-10-16 at 05:16 +0800, Michael Xu (xudong) wrote:
>>>>
>>>> hi all,
>>>>>
>>>>> We can define entities in XML files. However, only database specific
>>>>> semantics could be defined there. For those application level semantics
>>>>> (like trigger, visiblity, validation) has to be defined in different
>>>>> places.
>>>>> The lack of a single place to define such metadata makes ofbiz hard to
>>>>> maintain. (Correct me if I am wrong)
>>>>>
>>>>> Let's take OrderHeader as an example. I copy the latest entity
>>>>> definition
>>>>> as
>>>>> below:
>>>>>
>>>>> <entity entity-name="OrderHeader"
>>>>> package-name="org.ofbiz.order.order"
>>>>> never-cache="true"
>>>>> title="Order Header Entity">
>>>>> <field name="orderId" type="id-ne"></field>
>>>>> <field name="orderTypeId" type="id"></field>
>>>>> <field name="orderName" type="name"></field>
>>>>> <field name="externalId" type="id"></field>
>>>>> <field name="salesChannelEnumId" type="id"></field>
>>>>> <field name="orderDate" type="date-time"></field>
>>>>> <field name="entryDate" type="date-time"></field>
>>>>> <field name="visitId" type="id"></field>
>>>>> <field name="statusId" type="id"></field>
>>>>> <field name="createdBy" type="id-vlong"></field>
>>>>> <field name="firstAttemptOrderId" type="id"></field>
>>>>> <field name="currencyUom" type="id"></field>
>>>>> <field name="syncStatusId" type="id"></field>
>>>>> <field name="billingAccountId" type="id"></field>
>>>>> <field name="originFacilityId" type="id"></field>
>>>>> <field name="webSiteId" type="id"></field>
>>>>> <field name="productStoreId" type="id"></field>
>>>>> <field name="terminalId" type="id-long"></field>
>>>>> <field name="transactionId" type="id-long"></field>
>>>>> <field name="autoOrderShoppingListId" type="id"></field>
>>>>> <field name="needsInventoryIssuance" type="indicator"></field>
>>>>> <field name="isRushOrder" type="indicator"></field>
>>>>> <field name="internalCode" type="id-long"></field>
>>>>> <field name="remainingSubTotal" type="currency-amount"></field>
>>>>> <field name="grandTotal" type="currency-amount"></field>
>>>>> <prim-key field="orderId"/>
>>>>> <relation type="one" fk-name="ORDER_HDR_TYPE"
>>>>> rel-entity-name="OrderType">
>>>>> <key-map field-name="orderTypeId"/>
>>>>> </relation>
>>>>> <relation type="one" fk-name="ORDER_HDR_SCENUM" title="SalesChannel"
>>>>> rel-entity-name="Enumeration">
>>>>> <key-map field-name="salesChannelEnumId" rel-field-name="enumId"/>
>>>>> </relation>
>>>>> <relation type="one" fk-name="ORDER_HDR_OFAC" title="Origin"
>>>>> rel-entity-name="Facility">
>>>>> <key-map field-name="originFacilityId"
>>>>> rel-field-name="facilityId"/>
>>>>> </relation>
>>>>> <relation type="many" rel-entity-name="OrderTypeAttr">
>>>>> <key-map field-name="orderTypeId"/>
>>>>> </relation>
>>>>> <relation type="one" fk-name="ORDER_HDR_BACCT"
>>>>> rel-entity-name="BillingAccount">
>>>>> <key-map field-name="billingAccountId"/>
>>>>> </relation>
>>>>> <relation type="one" fk-name="ORDER_HDR_PDSTR"
>>>>> rel-entity-name="ProductStore">
>>>>> <key-map field-name="productStoreId"/>
>>>>> </relation>
>>>>> <relation type="one" fk-name="ORDER_HDR_AOSHLST" title="AutoOrder"
>>>>> rel-entity-name="ShoppingList">
>>>>> <key-map field-name="autoOrderShoppingListId"
>>>>> rel-field-name="shoppingListId"/>
>>>>> </relation>
>>>>> <relation type="one" fk-name="ORDER_HDR_CBUL" title="CreatedBy"
>>>>> rel-entity-name="UserLogin">
>>>>> <key-map field-name="createdBy" rel-field-name="userLoginId"/>
>>>>> </relation>
>>>>> <relation type="one" fk-name="ORDER_HDR_STTS"
>>>>> rel-entity-name="StatusItem">
>>>>> <key-map field-name="statusId"/>
>>>>> </relation>
>>>>> <relation type="one" fk-name="ORDER_HDR_SYST" title="Sync"
>>>>> rel-entity-name="StatusItem">
>>>>> <key-map field-name="syncStatusId" rel-field-name="statusId"/>
>>>>> </relation>
>>>>> <relation type="one" fk-name="ORDER_HDR_CUOM" rel-entity-name="Uom">
>>>>> <key-map field-name="currencyUom" rel-field-name="uomId"/>
>>>>> </relation>
>>>>> <relation type="many" rel-entity-name="OrderHeaderNoteView">
>>>>> <key-map field-name="orderId"/>
>>>>> </relation>
>>>>> <relation type="many" rel-entity-name="OrderItemAndShipGroupAssoc">
>>>>> <key-map field-name="orderId"/>
>>>>> </relation>
>>>>> <index name="ORDEREXT_ID_IDX">
>>>>> <index-field name="externalId"/>
>>>>> </index>
>>>>> </entity>
>>>>>
>>>>> In order to enrich the definition (metadata) with more information, I
>>>>> am
>>>>> considering to put more tags (please find elements surrounded with
>>>>> !!!!!!!!!!!!!!!!!!!!!), like:
>>>>>
>>>>> <entity entity-name="OrderHeader"
>>>>> package-name="org.ofbiz.order.order"
>>>>> never-cache="true"
>>>>> title="Order Header Entity">
>>>>> <field name="orderId" type="id-ne"></field>
>>>>> <field name="orderTypeId" type="id"></field>
>>>>> <field name="orderName" type="name"></field>
>>>>>
>>>>>
>>>>> <!- !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
>>>>> <field name="externalId" type="id">
>>>>> <!-
>>>>> We can use "visiblity" tag to tell system when to show this
>>>>> field in UI layer.
>>>>> ->
>>>>> <visbility>
>>>>> <condition
>>>>> implementation="org.ofbiz.core.condition.NonEmptyField"/>
>>>>> </visbility>
>>>>> <validity type="clientSide">
>>>>> <condition notEqual="111"/>
>>>>> </validity>
>>>>> </field>
>>>>> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! ->
>>>>>
>>>>>
>>>>>
>>>>> <field name="salesChannelEnumId" type="id"></field>
>>>>> <field name="orderDate" type="date-time"></field>
>>>>> <field name="entryDate" type="date-time"></field>
>>>>> <field name="visitId" type="id"></field>
>>>>> <field name="statusId" type="id"></field>
>>>>> <field name="createdBy" type="id-vlong"></field>
>>>>> <field name="firstAttemptOrderId" type="id"></field>
>>>>> <field name="currencyUom" type="id"></field>
>>>>> <field name="syncStatusId" type="id"></field>
>>>>> <field name="billingAccountId" type="id"></field>
>>>>> <field name="originFacilityId" type="id"></field>
>>>>> <field name="webSiteId" type="id"></field>
>>>>> <field name="productStoreId" type="id"></field>
>>>>> <field name="terminalId" type="id-long"></field>
>>>>> <field name="transactionId" type="id-long"></field>
>>>>> <field name="autoOrderShoppingListId" type="id"></field>
>>>>> <field name="needsInventoryIssuance" type="indicator"></field>
>>>>> <field name="isRushOrder" type="indicator"></field>
>>>>> <field name="internalCode" type="id-long"></field>
>>>>> <field name="remainingSubTotal" type="currency-amount"></field>
>>>>> <field name="grandTotal" type="currency-amount"></field>
>>>>> <prim-key field="orderId"/>
>>>>> <relation type="one" fk-name="ORDER_HDR_TYPE"
>>>>> rel-entity-name="OrderType">
>>>>> <key-map field-name="orderTypeId"/>
>>>>> </relation>
>>>>> <relation type="one" fk-name="ORDER_HDR_SCENUM" title="SalesChannel"
>>>>> rel-entity-name="Enumeration">
>>>>> <key-map field-name="salesChannelEnumId" rel-field-name="enumId"/>
>>>>> </relation>
>>>>> <relation type="one" fk-name="ORDER_HDR_OFAC" title="Origin"
>>>>> rel-entity-name="Facility">
>>>>> <key-map field-name="originFacilityId"
>>>>> rel-field-name="facilityId"/>
>>>>> </relation>
>>>>> <relation type="many" rel-entity-name="OrderTypeAttr">
>>>>> <key-map field-name="orderTypeId"/>
>>>>> </relation>
>>>>> <relation type="one" fk-name="ORDER_HDR_BACCT"
>>>>> rel-entity-name="BillingAccount">
>>>>> <key-map field-name="billingAccountId"/>
>>>>> </relation>
>>>>> <relation type="one" fk-name="ORDER_HDR_PDSTR"
>>>>> rel-entity-name="ProductStore">
>>>>> <key-map field-name="productStoreId"/>
>>>>> </relation>
>>>>> <relation type="one" fk-name="ORDER_HDR_AOSHLST" title="AutoOrder"
>>>>> rel-entity-name="ShoppingList">
>>>>> <key-map field-name="autoOrderShoppingListId"
>>>>> rel-field-name="shoppingListId"/>
>>>>> </relation>
>>>>> <relation type="one" fk-name="ORDER_HDR_CBUL" title="CreatedBy"
>>>>> rel-entity-name="UserLogin">
>>>>> <key-map field-name="createdBy" rel-field-name="userLoginId"/>
>>>>> </relation>
>>>>> <relation type="one" fk-name="ORDER_HDR_STTS"
>>>>> rel-entity-name="StatusItem">
>>>>> <key-map field-name="statusId"/>
>>>>> </relation>
>>>>> <relation type="one" fk-name="ORDER_HDR_SYST" title="Sync"
>>>>> rel-entity-name="StatusItem">
>>>>> <key-map field-name="syncStatusId" rel-field-name="statusId"/>
>>>>> </relation>
>>>>> <relation type="one" fk-name="ORDER_HDR_CUOM" rel-entity-name="Uom">
>>>>> <key-map field-name="currencyUom" rel-field-name="uomId"/>
>>>>> </relation>
>>>>> <relation type="many" rel-entity-name="OrderHeaderNoteView">
>>>>> <key-map field-name="orderId"/>
>>>>> </relation>
>>>>> <relation type="many" rel-entity-name="OrderItemAndShipGroupAssoc">
>>>>> <key-map field-name="orderId"/>
>>>>> </relation>
>>>>> <index name="ORDEREXT_ID_IDX">
>>>>> <index-field name="externalId"/>
>>>>> </index>
>>>>>
>>>>>
>>>>> <!- !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
>>>>> <!-
>>>>> In different context, maybe different set of fields need to show.
>>>>> So my idea
>>>>> here is to use "group" to group fields for different scenario. And
>>>>> then in UI
>>>>> level, we can define a jsp tag or something to only show fields
>>>>> within this group.
>>>>> ->
>>>>> <group name="summary">
>>>>> <field name="orderId" rank="1"/>
>>>>> <field name="orderTypeId" rank="10"/>
>>>>> <field name="orderName" rank="11"/>
>>>>> </group>
>>>>>
>>>>> <group name="details">
>>>>> <field name="orderId" rank="1"/>
>>>>> <field name="orderTypeId" rank="10"/>
>>>>> <field name="orderName" rank="11"/>
>>>>> <field name="externalId" rank="20">
>>>>> <!-
>>>>> !!!!Note: Though visibility is definded above with another
>>>>> condition. However, in this group
>>>>> (Scenario), externalID will always be
>>>>> visible.
>>>>> ->
>>>>> <visbility value="true"/>
>>>>> <field>
>>>>> </group>
>>>>> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!->
>>>>> </entity>
>>>>>
>>>>> Such an idea to make entity definition as a single point of
>>>>> configuration/customization might make system easier to
>>>>> maintain/customize.
>>>>> Am I right? If yes, anybody could suggest me how to implement it.
>>>>>
>>>>> (BTW: we are going to use ofbiz entity engine for our products just
>>>>> like
>>>>> what JIRA did. It would be great if such enhancement could be done
>>>>> direct
>>>>> under apache. Otherwise, we might have to maintain a customized ofbiz
>>>>> entity
>>>>> engine by ourselves.)
>>>>>
>>>>> --
>>>>> Regards,
>>>>> Michael Xu (xudong)
>>>>> www.wizitsoft.com | Office: (8610) 6267 0615 ext 806 | Mobile: (86)
>>>>> 135
>>>>> 0135
>>>>> 9807 | Fax: (8610) 62670096
>>>>>
>>>>> --
>>>> Antwebsystems.com: Quality OFBiz services for competitive rates
>>>>
>>>>
>>>>
>>>
>
Re: about entity engine
Posted by Scott Gray <sc...@hotwaxmedia.com>.
The problem is that with a generic data model many entities are used
in many different places and in different contexts, if you tried to
encapsulate all of those differences within a single entity definition
you are very quickly going to end up with a very messy entity model.
IMO separation of concerns is a good thing, you're complaining about
having to make changes in many places, but at least you know what
effect each change is having, in your model I would need to check
everywhere that an entity is used before making a change to be sure of
what effect a seemingly minor adjustment would have.
Regards
Scott
On 16/10/2009, at 6:58 PM, Michael Xu (xudong) wrote:
> hi Scott,
>
> I got your points. Actually, form widgets are still required to show
> the
> GROUP with a set of predefined fields. But such form widget will be
> very
> generic, which is just show the group in the way defined in the entity
> model. And as such the benefits are:
> 1) a single point to define entity behavior (not just data structure)
> 2) UI gets configurable directly in the single point (no need to
> change form
> widgets or ftl in many places)
> 3) less java codes and widgets are required.
>
> In a summary, bringing more power to entity definition.
>
> --
> Regards,
> Michael Xu (xudong)
> www.wizitsoft.com | Office: (8610) 6267 0615 ext 806 | Mobile: (86)
> 135 0135
> 9807 | Fax: (8610) 62670096
>
>
> On Fri, Oct 16, 2009 at 1:39 PM, Scott Gray <scott.gray@hotwaxmedia.com
> >wrote:
>
>> I think to be able to generate a reasonably functional UI from
>> something
>> like this you'd end up with so much complexity in your entity model
>> that
>> someone would come up with a new idea to solve that problem and
>> they'd call
>> it the form widget.
>>
>> Regards
>> Scott
>>
>> HotWax Media
>> http://www.hotwaxmedia.com
>>
>>
>> On 16/10/2009, at 5:22 PM, Hans Bakker wrote:
>>
>> In general, this looks like a pretty good idea.
>>>
>>> The visibility tag would be nice if the widgets took advantage of
>>> that.
>>> then i would be easy to let a field disappear in the whole system
>>> when a
>>> if a simple 'true/false' would be possible.
>>>
>>> More complicated ones like the ones mentioned below could also be
>>> interesting but the integration in the widgets is a must. ftl's
>>> will me
>>> more difficult (macros), jsp, not sure if we should support that.
>>>
>>> trigger and validation will be more complex but sure we could look
>>> at
>>> that.
>>>
>>> In general a good idea
>>>
>>> Regards,
>>> Hans
>>>
>>>
>>> On Fri, 2009-10-16 at 05:16 +0800, Michael Xu (xudong) wrote:
>>>
>>>> hi all,
>>>>
>>>> We can define entities in XML files. However, only database
>>>> specific
>>>> semantics could be defined there. For those application level
>>>> semantics
>>>> (like trigger, visiblity, validation) has to be defined in
>>>> different
>>>> places.
>>>> The lack of a single place to define such metadata makes ofbiz
>>>> hard to
>>>> maintain. (Correct me if I am wrong)
>>>>
>>>> Let's take OrderHeader as an example. I copy the latest entity
>>>> definition
>>>> as
>>>> below:
>>>>
>>>> <entity entity-name="OrderHeader"
>>>> package-name="org.ofbiz.order.order"
>>>> never-cache="true"
>>>> title="Order Header Entity">
>>>> <field name="orderId" type="id-ne"></field>
>>>> <field name="orderTypeId" type="id"></field>
>>>> <field name="orderName" type="name"></field>
>>>> <field name="externalId" type="id"></field>
>>>> <field name="salesChannelEnumId" type="id"></field>
>>>> <field name="orderDate" type="date-time"></field>
>>>> <field name="entryDate" type="date-time"></field>
>>>> <field name="visitId" type="id"></field>
>>>> <field name="statusId" type="id"></field>
>>>> <field name="createdBy" type="id-vlong"></field>
>>>> <field name="firstAttemptOrderId" type="id"></field>
>>>> <field name="currencyUom" type="id"></field>
>>>> <field name="syncStatusId" type="id"></field>
>>>> <field name="billingAccountId" type="id"></field>
>>>> <field name="originFacilityId" type="id"></field>
>>>> <field name="webSiteId" type="id"></field>
>>>> <field name="productStoreId" type="id"></field>
>>>> <field name="terminalId" type="id-long"></field>
>>>> <field name="transactionId" type="id-long"></field>
>>>> <field name="autoOrderShoppingListId" type="id"></field>
>>>> <field name="needsInventoryIssuance" type="indicator"></field>
>>>> <field name="isRushOrder" type="indicator"></field>
>>>> <field name="internalCode" type="id-long"></field>
>>>> <field name="remainingSubTotal" type="currency-amount"></field>
>>>> <field name="grandTotal" type="currency-amount"></field>
>>>> <prim-key field="orderId"/>
>>>> <relation type="one" fk-name="ORDER_HDR_TYPE"
>>>> rel-entity-name="OrderType">
>>>> <key-map field-name="orderTypeId"/>
>>>> </relation>
>>>> <relation type="one" fk-name="ORDER_HDR_SCENUM"
>>>> title="SalesChannel"
>>>> rel-entity-name="Enumeration">
>>>> <key-map field-name="salesChannelEnumId" rel-field-
>>>> name="enumId"/>
>>>> </relation>
>>>> <relation type="one" fk-name="ORDER_HDR_OFAC" title="Origin"
>>>> rel-entity-name="Facility">
>>>> <key-map field-name="originFacilityId"
>>>> rel-field-name="facilityId"/>
>>>> </relation>
>>>> <relation type="many" rel-entity-name="OrderTypeAttr">
>>>> <key-map field-name="orderTypeId"/>
>>>> </relation>
>>>> <relation type="one" fk-name="ORDER_HDR_BACCT"
>>>> rel-entity-name="BillingAccount">
>>>> <key-map field-name="billingAccountId"/>
>>>> </relation>
>>>> <relation type="one" fk-name="ORDER_HDR_PDSTR"
>>>> rel-entity-name="ProductStore">
>>>> <key-map field-name="productStoreId"/>
>>>> </relation>
>>>> <relation type="one" fk-name="ORDER_HDR_AOSHLST"
>>>> title="AutoOrder"
>>>> rel-entity-name="ShoppingList">
>>>> <key-map field-name="autoOrderShoppingListId"
>>>> rel-field-name="shoppingListId"/>
>>>> </relation>
>>>> <relation type="one" fk-name="ORDER_HDR_CBUL" title="CreatedBy"
>>>> rel-entity-name="UserLogin">
>>>> <key-map field-name="createdBy" rel-field-name="userLoginId"/>
>>>> </relation>
>>>> <relation type="one" fk-name="ORDER_HDR_STTS"
>>>> rel-entity-name="StatusItem">
>>>> <key-map field-name="statusId"/>
>>>> </relation>
>>>> <relation type="one" fk-name="ORDER_HDR_SYST" title="Sync"
>>>> rel-entity-name="StatusItem">
>>>> <key-map field-name="syncStatusId" rel-field-name="statusId"/>
>>>> </relation>
>>>> <relation type="one" fk-name="ORDER_HDR_CUOM" rel-entity-
>>>> name="Uom">
>>>> <key-map field-name="currencyUom" rel-field-name="uomId"/>
>>>> </relation>
>>>> <relation type="many" rel-entity-name="OrderHeaderNoteView">
>>>> <key-map field-name="orderId"/>
>>>> </relation>
>>>> <relation type="many" rel-entity-
>>>> name="OrderItemAndShipGroupAssoc">
>>>> <key-map field-name="orderId"/>
>>>> </relation>
>>>> <index name="ORDEREXT_ID_IDX">
>>>> <index-field name="externalId"/>
>>>> </index>
>>>> </entity>
>>>>
>>>> In order to enrich the definition (metadata) with more
>>>> information, I am
>>>> considering to put more tags (please find elements surrounded with
>>>> !!!!!!!!!!!!!!!!!!!!!), like:
>>>>
>>>> <entity entity-name="OrderHeader"
>>>> package-name="org.ofbiz.order.order"
>>>> never-cache="true"
>>>> title="Order Header Entity">
>>>> <field name="orderId" type="id-ne"></field>
>>>> <field name="orderTypeId" type="id"></field>
>>>> <field name="orderName" type="name"></field>
>>>>
>>>>
>>>> <!- !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
>>>> <field name="externalId" type="id">
>>>> <!-
>>>> We can use "visiblity" tag to tell system when to
>>>> show this
>>>> field in UI layer.
>>>> ->
>>>> <visbility>
>>>> <condition
>>>> implementation="org.ofbiz.core.condition.NonEmptyField"/>
>>>> </visbility>
>>>> <validity type="clientSide">
>>>> <condition notEqual="111"/>
>>>> </validity>
>>>> </field>
>>>> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! ->
>>>>
>>>>
>>>>
>>>> <field name="salesChannelEnumId" type="id"></field>
>>>> <field name="orderDate" type="date-time"></field>
>>>> <field name="entryDate" type="date-time"></field>
>>>> <field name="visitId" type="id"></field>
>>>> <field name="statusId" type="id"></field>
>>>> <field name="createdBy" type="id-vlong"></field>
>>>> <field name="firstAttemptOrderId" type="id"></field>
>>>> <field name="currencyUom" type="id"></field>
>>>> <field name="syncStatusId" type="id"></field>
>>>> <field name="billingAccountId" type="id"></field>
>>>> <field name="originFacilityId" type="id"></field>
>>>> <field name="webSiteId" type="id"></field>
>>>> <field name="productStoreId" type="id"></field>
>>>> <field name="terminalId" type="id-long"></field>
>>>> <field name="transactionId" type="id-long"></field>
>>>> <field name="autoOrderShoppingListId" type="id"></field>
>>>> <field name="needsInventoryIssuance" type="indicator"></field>
>>>> <field name="isRushOrder" type="indicator"></field>
>>>> <field name="internalCode" type="id-long"></field>
>>>> <field name="remainingSubTotal" type="currency-amount"></field>
>>>> <field name="grandTotal" type="currency-amount"></field>
>>>> <prim-key field="orderId"/>
>>>> <relation type="one" fk-name="ORDER_HDR_TYPE"
>>>> rel-entity-name="OrderType">
>>>> <key-map field-name="orderTypeId"/>
>>>> </relation>
>>>> <relation type="one" fk-name="ORDER_HDR_SCENUM"
>>>> title="SalesChannel"
>>>> rel-entity-name="Enumeration">
>>>> <key-map field-name="salesChannelEnumId" rel-field-
>>>> name="enumId"/>
>>>> </relation>
>>>> <relation type="one" fk-name="ORDER_HDR_OFAC" title="Origin"
>>>> rel-entity-name="Facility">
>>>> <key-map field-name="originFacilityId"
>>>> rel-field-name="facilityId"/>
>>>> </relation>
>>>> <relation type="many" rel-entity-name="OrderTypeAttr">
>>>> <key-map field-name="orderTypeId"/>
>>>> </relation>
>>>> <relation type="one" fk-name="ORDER_HDR_BACCT"
>>>> rel-entity-name="BillingAccount">
>>>> <key-map field-name="billingAccountId"/>
>>>> </relation>
>>>> <relation type="one" fk-name="ORDER_HDR_PDSTR"
>>>> rel-entity-name="ProductStore">
>>>> <key-map field-name="productStoreId"/>
>>>> </relation>
>>>> <relation type="one" fk-name="ORDER_HDR_AOSHLST"
>>>> title="AutoOrder"
>>>> rel-entity-name="ShoppingList">
>>>> <key-map field-name="autoOrderShoppingListId"
>>>> rel-field-name="shoppingListId"/>
>>>> </relation>
>>>> <relation type="one" fk-name="ORDER_HDR_CBUL" title="CreatedBy"
>>>> rel-entity-name="UserLogin">
>>>> <key-map field-name="createdBy" rel-field-name="userLoginId"/>
>>>> </relation>
>>>> <relation type="one" fk-name="ORDER_HDR_STTS"
>>>> rel-entity-name="StatusItem">
>>>> <key-map field-name="statusId"/>
>>>> </relation>
>>>> <relation type="one" fk-name="ORDER_HDR_SYST" title="Sync"
>>>> rel-entity-name="StatusItem">
>>>> <key-map field-name="syncStatusId" rel-field-name="statusId"/>
>>>> </relation>
>>>> <relation type="one" fk-name="ORDER_HDR_CUOM" rel-entity-
>>>> name="Uom">
>>>> <key-map field-name="currencyUom" rel-field-name="uomId"/>
>>>> </relation>
>>>> <relation type="many" rel-entity-name="OrderHeaderNoteView">
>>>> <key-map field-name="orderId"/>
>>>> </relation>
>>>> <relation type="many" rel-entity-
>>>> name="OrderItemAndShipGroupAssoc">
>>>> <key-map field-name="orderId"/>
>>>> </relation>
>>>> <index name="ORDEREXT_ID_IDX">
>>>> <index-field name="externalId"/>
>>>> </index>
>>>>
>>>>
>>>> <!- !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
>>>> <!-
>>>> In different context, maybe different set of fields need to
>>>> show.
>>>> So my idea
>>>> here is to use "group" to group fields for different
>>>> scenario. And
>>>> then in UI
>>>> level, we can define a jsp tag or something to only show
>>>> fields
>>>> within this group.
>>>> ->
>>>> <group name="summary">
>>>> <field name="orderId" rank="1"/>
>>>> <field name="orderTypeId" rank="10"/>
>>>> <field name="orderName" rank="11"/>
>>>> </group>
>>>>
>>>> <group name="details">
>>>> <field name="orderId" rank="1"/>
>>>> <field name="orderTypeId" rank="10"/>
>>>> <field name="orderName" rank="11"/>
>>>> <field name="externalId" rank="20">
>>>> <!-
>>>> !!!!Note: Though visibility is definded above with
>>>> another
>>>> condition. However, in this group
>>>> (Scenario), externalID will always be
>>>> visible.
>>>> ->
>>>> <visbility value="true"/>
>>>> <field>
>>>> </group>
>>>> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!->
>>>> </entity>
>>>>
>>>> Such an idea to make entity definition as a single point of
>>>> configuration/customization might make system easier to
>>>> maintain/customize.
>>>> Am I right? If yes, anybody could suggest me how to implement it.
>>>>
>>>> (BTW: we are going to use ofbiz entity engine for our products
>>>> just like
>>>> what JIRA did. It would be great if such enhancement could be
>>>> done direct
>>>> under apache. Otherwise, we might have to maintain a customized
>>>> ofbiz
>>>> entity
>>>> engine by ourselves.)
>>>>
>>>> --
>>>> Regards,
>>>> Michael Xu (xudong)
>>>> www.wizitsoft.com | Office: (8610) 6267 0615 ext 806 | Mobile:
>>>> (86) 135
>>>> 0135
>>>> 9807 | Fax: (8610) 62670096
>>>>
>>> --
>>> Antwebsystems.com: Quality OFBiz services for competitive rates
>>>
>>>
>>
Re: about entity engine
Posted by "Michael Xu (xudong)" <do...@wizitsoft.com>.
hi Scott,
I got your points. Actually, form widgets are still required to show the
GROUP with a set of predefined fields. But such form widget will be very
generic, which is just show the group in the way defined in the entity
model. And as such the benefits are:
1) a single point to define entity behavior (not just data structure)
2) UI gets configurable directly in the single point (no need to change form
widgets or ftl in many places)
3) less java codes and widgets are required.
In a summary, bringing more power to entity definition.
--
Regards,
Michael Xu (xudong)
www.wizitsoft.com | Office: (8610) 6267 0615 ext 806 | Mobile: (86) 135 0135
9807 | Fax: (8610) 62670096
On Fri, Oct 16, 2009 at 1:39 PM, Scott Gray <sc...@hotwaxmedia.com>wrote:
> I think to be able to generate a reasonably functional UI from something
> like this you'd end up with so much complexity in your entity model that
> someone would come up with a new idea to solve that problem and they'd call
> it the form widget.
>
> Regards
> Scott
>
> HotWax Media
> http://www.hotwaxmedia.com
>
>
> On 16/10/2009, at 5:22 PM, Hans Bakker wrote:
>
> In general, this looks like a pretty good idea.
>>
>> The visibility tag would be nice if the widgets took advantage of that.
>> then i would be easy to let a field disappear in the whole system when a
>> if a simple 'true/false' would be possible.
>>
>> More complicated ones like the ones mentioned below could also be
>> interesting but the integration in the widgets is a must. ftl's will me
>> more difficult (macros), jsp, not sure if we should support that.
>>
>> trigger and validation will be more complex but sure we could look at
>> that.
>>
>> In general a good idea
>>
>> Regards,
>> Hans
>>
>>
>> On Fri, 2009-10-16 at 05:16 +0800, Michael Xu (xudong) wrote:
>>
>>> hi all,
>>>
>>> We can define entities in XML files. However, only database specific
>>> semantics could be defined there. For those application level semantics
>>> (like trigger, visiblity, validation) has to be defined in different
>>> places.
>>> The lack of a single place to define such metadata makes ofbiz hard to
>>> maintain. (Correct me if I am wrong)
>>>
>>> Let's take OrderHeader as an example. I copy the latest entity definition
>>> as
>>> below:
>>>
>>> <entity entity-name="OrderHeader"
>>> package-name="org.ofbiz.order.order"
>>> never-cache="true"
>>> title="Order Header Entity">
>>> <field name="orderId" type="id-ne"></field>
>>> <field name="orderTypeId" type="id"></field>
>>> <field name="orderName" type="name"></field>
>>> <field name="externalId" type="id"></field>
>>> <field name="salesChannelEnumId" type="id"></field>
>>> <field name="orderDate" type="date-time"></field>
>>> <field name="entryDate" type="date-time"></field>
>>> <field name="visitId" type="id"></field>
>>> <field name="statusId" type="id"></field>
>>> <field name="createdBy" type="id-vlong"></field>
>>> <field name="firstAttemptOrderId" type="id"></field>
>>> <field name="currencyUom" type="id"></field>
>>> <field name="syncStatusId" type="id"></field>
>>> <field name="billingAccountId" type="id"></field>
>>> <field name="originFacilityId" type="id"></field>
>>> <field name="webSiteId" type="id"></field>
>>> <field name="productStoreId" type="id"></field>
>>> <field name="terminalId" type="id-long"></field>
>>> <field name="transactionId" type="id-long"></field>
>>> <field name="autoOrderShoppingListId" type="id"></field>
>>> <field name="needsInventoryIssuance" type="indicator"></field>
>>> <field name="isRushOrder" type="indicator"></field>
>>> <field name="internalCode" type="id-long"></field>
>>> <field name="remainingSubTotal" type="currency-amount"></field>
>>> <field name="grandTotal" type="currency-amount"></field>
>>> <prim-key field="orderId"/>
>>> <relation type="one" fk-name="ORDER_HDR_TYPE"
>>> rel-entity-name="OrderType">
>>> <key-map field-name="orderTypeId"/>
>>> </relation>
>>> <relation type="one" fk-name="ORDER_HDR_SCENUM" title="SalesChannel"
>>> rel-entity-name="Enumeration">
>>> <key-map field-name="salesChannelEnumId" rel-field-name="enumId"/>
>>> </relation>
>>> <relation type="one" fk-name="ORDER_HDR_OFAC" title="Origin"
>>> rel-entity-name="Facility">
>>> <key-map field-name="originFacilityId"
>>> rel-field-name="facilityId"/>
>>> </relation>
>>> <relation type="many" rel-entity-name="OrderTypeAttr">
>>> <key-map field-name="orderTypeId"/>
>>> </relation>
>>> <relation type="one" fk-name="ORDER_HDR_BACCT"
>>> rel-entity-name="BillingAccount">
>>> <key-map field-name="billingAccountId"/>
>>> </relation>
>>> <relation type="one" fk-name="ORDER_HDR_PDSTR"
>>> rel-entity-name="ProductStore">
>>> <key-map field-name="productStoreId"/>
>>> </relation>
>>> <relation type="one" fk-name="ORDER_HDR_AOSHLST" title="AutoOrder"
>>> rel-entity-name="ShoppingList">
>>> <key-map field-name="autoOrderShoppingListId"
>>> rel-field-name="shoppingListId"/>
>>> </relation>
>>> <relation type="one" fk-name="ORDER_HDR_CBUL" title="CreatedBy"
>>> rel-entity-name="UserLogin">
>>> <key-map field-name="createdBy" rel-field-name="userLoginId"/>
>>> </relation>
>>> <relation type="one" fk-name="ORDER_HDR_STTS"
>>> rel-entity-name="StatusItem">
>>> <key-map field-name="statusId"/>
>>> </relation>
>>> <relation type="one" fk-name="ORDER_HDR_SYST" title="Sync"
>>> rel-entity-name="StatusItem">
>>> <key-map field-name="syncStatusId" rel-field-name="statusId"/>
>>> </relation>
>>> <relation type="one" fk-name="ORDER_HDR_CUOM" rel-entity-name="Uom">
>>> <key-map field-name="currencyUom" rel-field-name="uomId"/>
>>> </relation>
>>> <relation type="many" rel-entity-name="OrderHeaderNoteView">
>>> <key-map field-name="orderId"/>
>>> </relation>
>>> <relation type="many" rel-entity-name="OrderItemAndShipGroupAssoc">
>>> <key-map field-name="orderId"/>
>>> </relation>
>>> <index name="ORDEREXT_ID_IDX">
>>> <index-field name="externalId"/>
>>> </index>
>>> </entity>
>>>
>>> In order to enrich the definition (metadata) with more information, I am
>>> considering to put more tags (please find elements surrounded with
>>> !!!!!!!!!!!!!!!!!!!!!), like:
>>>
>>> <entity entity-name="OrderHeader"
>>> package-name="org.ofbiz.order.order"
>>> never-cache="true"
>>> title="Order Header Entity">
>>> <field name="orderId" type="id-ne"></field>
>>> <field name="orderTypeId" type="id"></field>
>>> <field name="orderName" type="name"></field>
>>>
>>>
>>> <!- !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
>>> <field name="externalId" type="id">
>>> <!-
>>> We can use "visiblity" tag to tell system when to show this
>>> field in UI layer.
>>> ->
>>> <visbility>
>>> <condition
>>> implementation="org.ofbiz.core.condition.NonEmptyField"/>
>>> </visbility>
>>> <validity type="clientSide">
>>> <condition notEqual="111"/>
>>> </validity>
>>> </field>
>>> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! ->
>>>
>>>
>>>
>>> <field name="salesChannelEnumId" type="id"></field>
>>> <field name="orderDate" type="date-time"></field>
>>> <field name="entryDate" type="date-time"></field>
>>> <field name="visitId" type="id"></field>
>>> <field name="statusId" type="id"></field>
>>> <field name="createdBy" type="id-vlong"></field>
>>> <field name="firstAttemptOrderId" type="id"></field>
>>> <field name="currencyUom" type="id"></field>
>>> <field name="syncStatusId" type="id"></field>
>>> <field name="billingAccountId" type="id"></field>
>>> <field name="originFacilityId" type="id"></field>
>>> <field name="webSiteId" type="id"></field>
>>> <field name="productStoreId" type="id"></field>
>>> <field name="terminalId" type="id-long"></field>
>>> <field name="transactionId" type="id-long"></field>
>>> <field name="autoOrderShoppingListId" type="id"></field>
>>> <field name="needsInventoryIssuance" type="indicator"></field>
>>> <field name="isRushOrder" type="indicator"></field>
>>> <field name="internalCode" type="id-long"></field>
>>> <field name="remainingSubTotal" type="currency-amount"></field>
>>> <field name="grandTotal" type="currency-amount"></field>
>>> <prim-key field="orderId"/>
>>> <relation type="one" fk-name="ORDER_HDR_TYPE"
>>> rel-entity-name="OrderType">
>>> <key-map field-name="orderTypeId"/>
>>> </relation>
>>> <relation type="one" fk-name="ORDER_HDR_SCENUM" title="SalesChannel"
>>> rel-entity-name="Enumeration">
>>> <key-map field-name="salesChannelEnumId" rel-field-name="enumId"/>
>>> </relation>
>>> <relation type="one" fk-name="ORDER_HDR_OFAC" title="Origin"
>>> rel-entity-name="Facility">
>>> <key-map field-name="originFacilityId"
>>> rel-field-name="facilityId"/>
>>> </relation>
>>> <relation type="many" rel-entity-name="OrderTypeAttr">
>>> <key-map field-name="orderTypeId"/>
>>> </relation>
>>> <relation type="one" fk-name="ORDER_HDR_BACCT"
>>> rel-entity-name="BillingAccount">
>>> <key-map field-name="billingAccountId"/>
>>> </relation>
>>> <relation type="one" fk-name="ORDER_HDR_PDSTR"
>>> rel-entity-name="ProductStore">
>>> <key-map field-name="productStoreId"/>
>>> </relation>
>>> <relation type="one" fk-name="ORDER_HDR_AOSHLST" title="AutoOrder"
>>> rel-entity-name="ShoppingList">
>>> <key-map field-name="autoOrderShoppingListId"
>>> rel-field-name="shoppingListId"/>
>>> </relation>
>>> <relation type="one" fk-name="ORDER_HDR_CBUL" title="CreatedBy"
>>> rel-entity-name="UserLogin">
>>> <key-map field-name="createdBy" rel-field-name="userLoginId"/>
>>> </relation>
>>> <relation type="one" fk-name="ORDER_HDR_STTS"
>>> rel-entity-name="StatusItem">
>>> <key-map field-name="statusId"/>
>>> </relation>
>>> <relation type="one" fk-name="ORDER_HDR_SYST" title="Sync"
>>> rel-entity-name="StatusItem">
>>> <key-map field-name="syncStatusId" rel-field-name="statusId"/>
>>> </relation>
>>> <relation type="one" fk-name="ORDER_HDR_CUOM" rel-entity-name="Uom">
>>> <key-map field-name="currencyUom" rel-field-name="uomId"/>
>>> </relation>
>>> <relation type="many" rel-entity-name="OrderHeaderNoteView">
>>> <key-map field-name="orderId"/>
>>> </relation>
>>> <relation type="many" rel-entity-name="OrderItemAndShipGroupAssoc">
>>> <key-map field-name="orderId"/>
>>> </relation>
>>> <index name="ORDEREXT_ID_IDX">
>>> <index-field name="externalId"/>
>>> </index>
>>>
>>>
>>> <!- !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
>>> <!-
>>> In different context, maybe different set of fields need to show.
>>> So my idea
>>> here is to use "group" to group fields for different scenario. And
>>> then in UI
>>> level, we can define a jsp tag or something to only show fields
>>> within this group.
>>> ->
>>> <group name="summary">
>>> <field name="orderId" rank="1"/>
>>> <field name="orderTypeId" rank="10"/>
>>> <field name="orderName" rank="11"/>
>>> </group>
>>>
>>> <group name="details">
>>> <field name="orderId" rank="1"/>
>>> <field name="orderTypeId" rank="10"/>
>>> <field name="orderName" rank="11"/>
>>> <field name="externalId" rank="20">
>>> <!-
>>> !!!!Note: Though visibility is definded above with another
>>> condition. However, in this group
>>> (Scenario), externalID will always be
>>> visible.
>>> ->
>>> <visbility value="true"/>
>>> <field>
>>> </group>
>>> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!->
>>> </entity>
>>>
>>> Such an idea to make entity definition as a single point of
>>> configuration/customization might make system easier to
>>> maintain/customize.
>>> Am I right? If yes, anybody could suggest me how to implement it.
>>>
>>> (BTW: we are going to use ofbiz entity engine for our products just like
>>> what JIRA did. It would be great if such enhancement could be done direct
>>> under apache. Otherwise, we might have to maintain a customized ofbiz
>>> entity
>>> engine by ourselves.)
>>>
>>> --
>>> Regards,
>>> Michael Xu (xudong)
>>> www.wizitsoft.com | Office: (8610) 6267 0615 ext 806 | Mobile: (86) 135
>>> 0135
>>> 9807 | Fax: (8610) 62670096
>>>
>> --
>> Antwebsystems.com: Quality OFBiz services for competitive rates
>>
>>
>
Re: about entity engine
Posted by Scott Gray <sc...@hotwaxmedia.com>.
I think to be able to generate a reasonably functional UI from
something like this you'd end up with so much complexity in your
entity model that someone would come up with a new idea to solve that
problem and they'd call it the form widget.
Regards
Scott
HotWax Media
http://www.hotwaxmedia.com
On 16/10/2009, at 5:22 PM, Hans Bakker wrote:
> In general, this looks like a pretty good idea.
>
> The visibility tag would be nice if the widgets took advantage of
> that.
> then i would be easy to let a field disappear in the whole system
> when a
> if a simple 'true/false' would be possible.
>
> More complicated ones like the ones mentioned below could also be
> interesting but the integration in the widgets is a must. ftl's will
> me
> more difficult (macros), jsp, not sure if we should support that.
>
> trigger and validation will be more complex but sure we could look at
> that.
>
> In general a good idea
>
> Regards,
> Hans
>
>
> On Fri, 2009-10-16 at 05:16 +0800, Michael Xu (xudong) wrote:
>> hi all,
>>
>> We can define entities in XML files. However, only database specific
>> semantics could be defined there. For those application level
>> semantics
>> (like trigger, visiblity, validation) has to be defined in
>> different places.
>> The lack of a single place to define such metadata makes ofbiz hard
>> to
>> maintain. (Correct me if I am wrong)
>>
>> Let's take OrderHeader as an example. I copy the latest entity
>> definition as
>> below:
>>
>> <entity entity-name="OrderHeader"
>> package-name="org.ofbiz.order.order"
>> never-cache="true"
>> title="Order Header Entity">
>> <field name="orderId" type="id-ne"></field>
>> <field name="orderTypeId" type="id"></field>
>> <field name="orderName" type="name"></field>
>> <field name="externalId" type="id"></field>
>> <field name="salesChannelEnumId" type="id"></field>
>> <field name="orderDate" type="date-time"></field>
>> <field name="entryDate" type="date-time"></field>
>> <field name="visitId" type="id"></field>
>> <field name="statusId" type="id"></field>
>> <field name="createdBy" type="id-vlong"></field>
>> <field name="firstAttemptOrderId" type="id"></field>
>> <field name="currencyUom" type="id"></field>
>> <field name="syncStatusId" type="id"></field>
>> <field name="billingAccountId" type="id"></field>
>> <field name="originFacilityId" type="id"></field>
>> <field name="webSiteId" type="id"></field>
>> <field name="productStoreId" type="id"></field>
>> <field name="terminalId" type="id-long"></field>
>> <field name="transactionId" type="id-long"></field>
>> <field name="autoOrderShoppingListId" type="id"></field>
>> <field name="needsInventoryIssuance" type="indicator"></field>
>> <field name="isRushOrder" type="indicator"></field>
>> <field name="internalCode" type="id-long"></field>
>> <field name="remainingSubTotal" type="currency-amount"></field>
>> <field name="grandTotal" type="currency-amount"></field>
>> <prim-key field="orderId"/>
>> <relation type="one" fk-name="ORDER_HDR_TYPE"
>> rel-entity-name="OrderType">
>> <key-map field-name="orderTypeId"/>
>> </relation>
>> <relation type="one" fk-name="ORDER_HDR_SCENUM"
>> title="SalesChannel"
>> rel-entity-name="Enumeration">
>> <key-map field-name="salesChannelEnumId" rel-field-
>> name="enumId"/>
>> </relation>
>> <relation type="one" fk-name="ORDER_HDR_OFAC" title="Origin"
>> rel-entity-name="Facility">
>> <key-map field-name="originFacilityId" rel-field-
>> name="facilityId"/>
>> </relation>
>> <relation type="many" rel-entity-name="OrderTypeAttr">
>> <key-map field-name="orderTypeId"/>
>> </relation>
>> <relation type="one" fk-name="ORDER_HDR_BACCT"
>> rel-entity-name="BillingAccount">
>> <key-map field-name="billingAccountId"/>
>> </relation>
>> <relation type="one" fk-name="ORDER_HDR_PDSTR"
>> rel-entity-name="ProductStore">
>> <key-map field-name="productStoreId"/>
>> </relation>
>> <relation type="one" fk-name="ORDER_HDR_AOSHLST"
>> title="AutoOrder"
>> rel-entity-name="ShoppingList">
>> <key-map field-name="autoOrderShoppingListId"
>> rel-field-name="shoppingListId"/>
>> </relation>
>> <relation type="one" fk-name="ORDER_HDR_CBUL" title="CreatedBy"
>> rel-entity-name="UserLogin">
>> <key-map field-name="createdBy" rel-field-name="userLoginId"/>
>> </relation>
>> <relation type="one" fk-name="ORDER_HDR_STTS"
>> rel-entity-name="StatusItem">
>> <key-map field-name="statusId"/>
>> </relation>
>> <relation type="one" fk-name="ORDER_HDR_SYST" title="Sync"
>> rel-entity-name="StatusItem">
>> <key-map field-name="syncStatusId" rel-field-name="statusId"/>
>> </relation>
>> <relation type="one" fk-name="ORDER_HDR_CUOM" rel-entity-
>> name="Uom">
>> <key-map field-name="currencyUom" rel-field-name="uomId"/>
>> </relation>
>> <relation type="many" rel-entity-name="OrderHeaderNoteView">
>> <key-map field-name="orderId"/>
>> </relation>
>> <relation type="many" rel-entity-
>> name="OrderItemAndShipGroupAssoc">
>> <key-map field-name="orderId"/>
>> </relation>
>> <index name="ORDEREXT_ID_IDX">
>> <index-field name="externalId"/>
>> </index>
>> </entity>
>>
>> In order to enrich the definition (metadata) with more information,
>> I am
>> considering to put more tags (please find elements surrounded with
>> !!!!!!!!!!!!!!!!!!!!!), like:
>>
>> <entity entity-name="OrderHeader"
>> package-name="org.ofbiz.order.order"
>> never-cache="true"
>> title="Order Header Entity">
>> <field name="orderId" type="id-ne"></field>
>> <field name="orderTypeId" type="id"></field>
>> <field name="orderName" type="name"></field>
>>
>>
>> <!- !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
>> <field name="externalId" type="id">
>> <!-
>> We can use "visiblity" tag to tell system when to
>> show this
>> field in UI layer.
>> ->
>> <visbility>
>> <condition
>> implementation="org.ofbiz.core.condition.NonEmptyField"/>
>> </visbility>
>> <validity type="clientSide">
>> <condition notEqual="111"/>
>> </validity>
>> </field>
>> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! ->
>>
>>
>>
>> <field name="salesChannelEnumId" type="id"></field>
>> <field name="orderDate" type="date-time"></field>
>> <field name="entryDate" type="date-time"></field>
>> <field name="visitId" type="id"></field>
>> <field name="statusId" type="id"></field>
>> <field name="createdBy" type="id-vlong"></field>
>> <field name="firstAttemptOrderId" type="id"></field>
>> <field name="currencyUom" type="id"></field>
>> <field name="syncStatusId" type="id"></field>
>> <field name="billingAccountId" type="id"></field>
>> <field name="originFacilityId" type="id"></field>
>> <field name="webSiteId" type="id"></field>
>> <field name="productStoreId" type="id"></field>
>> <field name="terminalId" type="id-long"></field>
>> <field name="transactionId" type="id-long"></field>
>> <field name="autoOrderShoppingListId" type="id"></field>
>> <field name="needsInventoryIssuance" type="indicator"></field>
>> <field name="isRushOrder" type="indicator"></field>
>> <field name="internalCode" type="id-long"></field>
>> <field name="remainingSubTotal" type="currency-amount"></field>
>> <field name="grandTotal" type="currency-amount"></field>
>> <prim-key field="orderId"/>
>> <relation type="one" fk-name="ORDER_HDR_TYPE"
>> rel-entity-name="OrderType">
>> <key-map field-name="orderTypeId"/>
>> </relation>
>> <relation type="one" fk-name="ORDER_HDR_SCENUM"
>> title="SalesChannel"
>> rel-entity-name="Enumeration">
>> <key-map field-name="salesChannelEnumId" rel-field-
>> name="enumId"/>
>> </relation>
>> <relation type="one" fk-name="ORDER_HDR_OFAC" title="Origin"
>> rel-entity-name="Facility">
>> <key-map field-name="originFacilityId" rel-field-
>> name="facilityId"/>
>> </relation>
>> <relation type="many" rel-entity-name="OrderTypeAttr">
>> <key-map field-name="orderTypeId"/>
>> </relation>
>> <relation type="one" fk-name="ORDER_HDR_BACCT"
>> rel-entity-name="BillingAccount">
>> <key-map field-name="billingAccountId"/>
>> </relation>
>> <relation type="one" fk-name="ORDER_HDR_PDSTR"
>> rel-entity-name="ProductStore">
>> <key-map field-name="productStoreId"/>
>> </relation>
>> <relation type="one" fk-name="ORDER_HDR_AOSHLST"
>> title="AutoOrder"
>> rel-entity-name="ShoppingList">
>> <key-map field-name="autoOrderShoppingListId"
>> rel-field-name="shoppingListId"/>
>> </relation>
>> <relation type="one" fk-name="ORDER_HDR_CBUL" title="CreatedBy"
>> rel-entity-name="UserLogin">
>> <key-map field-name="createdBy" rel-field-name="userLoginId"/>
>> </relation>
>> <relation type="one" fk-name="ORDER_HDR_STTS"
>> rel-entity-name="StatusItem">
>> <key-map field-name="statusId"/>
>> </relation>
>> <relation type="one" fk-name="ORDER_HDR_SYST" title="Sync"
>> rel-entity-name="StatusItem">
>> <key-map field-name="syncStatusId" rel-field-name="statusId"/>
>> </relation>
>> <relation type="one" fk-name="ORDER_HDR_CUOM" rel-entity-
>> name="Uom">
>> <key-map field-name="currencyUom" rel-field-name="uomId"/>
>> </relation>
>> <relation type="many" rel-entity-name="OrderHeaderNoteView">
>> <key-map field-name="orderId"/>
>> </relation>
>> <relation type="many" rel-entity-
>> name="OrderItemAndShipGroupAssoc">
>> <key-map field-name="orderId"/>
>> </relation>
>> <index name="ORDEREXT_ID_IDX">
>> <index-field name="externalId"/>
>> </index>
>>
>>
>> <!- !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
>> <!-
>> In different context, maybe different set of fields need to
>> show.
>> So my idea
>> here is to use "group" to group fields for different
>> scenario. And
>> then in UI
>> level, we can define a jsp tag or something to only show
>> fields
>> within this group.
>> ->
>> <group name="summary">
>> <field name="orderId" rank="1"/>
>> <field name="orderTypeId" rank="10"/>
>> <field name="orderName" rank="11"/>
>> </group>
>>
>> <group name="details">
>> <field name="orderId" rank="1"/>
>> <field name="orderTypeId" rank="10"/>
>> <field name="orderName" rank="11"/>
>> <field name="externalId" rank="20">
>> <!-
>> !!!!Note: Though visibility is definded above with
>> another
>> condition. However, in this group
>> (Scenario), externalID will always be
>> visible.
>> ->
>> <visbility value="true"/>
>> <field>
>> </group>
>> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!->
>> </entity>
>>
>> Such an idea to make entity definition as a single point of
>> configuration/customization might make system easier to maintain/
>> customize.
>> Am I right? If yes, anybody could suggest me how to implement it.
>>
>> (BTW: we are going to use ofbiz entity engine for our products just
>> like
>> what JIRA did. It would be great if such enhancement could be done
>> direct
>> under apache. Otherwise, we might have to maintain a customized
>> ofbiz entity
>> engine by ourselves.)
>>
>> --
>> Regards,
>> Michael Xu (xudong)
>> www.wizitsoft.com | Office: (8610) 6267 0615 ext 806 | Mobile: (86)
>> 135 0135
>> 9807 | Fax: (8610) 62670096
> --
> Antwebsystems.com: Quality OFBiz services for competitive rates
>
Re: about entity engine
Posted by Hans Bakker <ma...@antwebsystems.com>.
In general, this looks like a pretty good idea.
The visibility tag would be nice if the widgets took advantage of that.
then i would be easy to let a field disappear in the whole system when a
if a simple 'true/false' would be possible.
More complicated ones like the ones mentioned below could also be
interesting but the integration in the widgets is a must. ftl's will me
more difficult (macros), jsp, not sure if we should support that.
trigger and validation will be more complex but sure we could look at
that.
In general a good idea
Regards,
Hans
On Fri, 2009-10-16 at 05:16 +0800, Michael Xu (xudong) wrote:
> hi all,
>
> We can define entities in XML files. However, only database specific
> semantics could be defined there. For those application level semantics
> (like trigger, visiblity, validation) has to be defined in different places.
> The lack of a single place to define such metadata makes ofbiz hard to
> maintain. (Correct me if I am wrong)
>
> Let's take OrderHeader as an example. I copy the latest entity definition as
> below:
>
> <entity entity-name="OrderHeader"
> package-name="org.ofbiz.order.order"
> never-cache="true"
> title="Order Header Entity">
> <field name="orderId" type="id-ne"></field>
> <field name="orderTypeId" type="id"></field>
> <field name="orderName" type="name"></field>
> <field name="externalId" type="id"></field>
> <field name="salesChannelEnumId" type="id"></field>
> <field name="orderDate" type="date-time"></field>
> <field name="entryDate" type="date-time"></field>
> <field name="visitId" type="id"></field>
> <field name="statusId" type="id"></field>
> <field name="createdBy" type="id-vlong"></field>
> <field name="firstAttemptOrderId" type="id"></field>
> <field name="currencyUom" type="id"></field>
> <field name="syncStatusId" type="id"></field>
> <field name="billingAccountId" type="id"></field>
> <field name="originFacilityId" type="id"></field>
> <field name="webSiteId" type="id"></field>
> <field name="productStoreId" type="id"></field>
> <field name="terminalId" type="id-long"></field>
> <field name="transactionId" type="id-long"></field>
> <field name="autoOrderShoppingListId" type="id"></field>
> <field name="needsInventoryIssuance" type="indicator"></field>
> <field name="isRushOrder" type="indicator"></field>
> <field name="internalCode" type="id-long"></field>
> <field name="remainingSubTotal" type="currency-amount"></field>
> <field name="grandTotal" type="currency-amount"></field>
> <prim-key field="orderId"/>
> <relation type="one" fk-name="ORDER_HDR_TYPE"
> rel-entity-name="OrderType">
> <key-map field-name="orderTypeId"/>
> </relation>
> <relation type="one" fk-name="ORDER_HDR_SCENUM" title="SalesChannel"
> rel-entity-name="Enumeration">
> <key-map field-name="salesChannelEnumId" rel-field-name="enumId"/>
> </relation>
> <relation type="one" fk-name="ORDER_HDR_OFAC" title="Origin"
> rel-entity-name="Facility">
> <key-map field-name="originFacilityId" rel-field-name="facilityId"/>
> </relation>
> <relation type="many" rel-entity-name="OrderTypeAttr">
> <key-map field-name="orderTypeId"/>
> </relation>
> <relation type="one" fk-name="ORDER_HDR_BACCT"
> rel-entity-name="BillingAccount">
> <key-map field-name="billingAccountId"/>
> </relation>
> <relation type="one" fk-name="ORDER_HDR_PDSTR"
> rel-entity-name="ProductStore">
> <key-map field-name="productStoreId"/>
> </relation>
> <relation type="one" fk-name="ORDER_HDR_AOSHLST" title="AutoOrder"
> rel-entity-name="ShoppingList">
> <key-map field-name="autoOrderShoppingListId"
> rel-field-name="shoppingListId"/>
> </relation>
> <relation type="one" fk-name="ORDER_HDR_CBUL" title="CreatedBy"
> rel-entity-name="UserLogin">
> <key-map field-name="createdBy" rel-field-name="userLoginId"/>
> </relation>
> <relation type="one" fk-name="ORDER_HDR_STTS"
> rel-entity-name="StatusItem">
> <key-map field-name="statusId"/>
> </relation>
> <relation type="one" fk-name="ORDER_HDR_SYST" title="Sync"
> rel-entity-name="StatusItem">
> <key-map field-name="syncStatusId" rel-field-name="statusId"/>
> </relation>
> <relation type="one" fk-name="ORDER_HDR_CUOM" rel-entity-name="Uom">
> <key-map field-name="currencyUom" rel-field-name="uomId"/>
> </relation>
> <relation type="many" rel-entity-name="OrderHeaderNoteView">
> <key-map field-name="orderId"/>
> </relation>
> <relation type="many" rel-entity-name="OrderItemAndShipGroupAssoc">
> <key-map field-name="orderId"/>
> </relation>
> <index name="ORDEREXT_ID_IDX">
> <index-field name="externalId"/>
> </index>
> </entity>
>
> In order to enrich the definition (metadata) with more information, I am
> considering to put more tags (please find elements surrounded with
> !!!!!!!!!!!!!!!!!!!!!), like:
>
> <entity entity-name="OrderHeader"
> package-name="org.ofbiz.order.order"
> never-cache="true"
> title="Order Header Entity">
> <field name="orderId" type="id-ne"></field>
> <field name="orderTypeId" type="id"></field>
> <field name="orderName" type="name"></field>
>
>
> <!- !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
> <field name="externalId" type="id">
> <!-
> We can use "visiblity" tag to tell system when to show this
> field in UI layer.
> ->
> <visbility>
> <condition
> implementation="org.ofbiz.core.condition.NonEmptyField"/>
> </visbility>
> <validity type="clientSide">
> <condition notEqual="111"/>
> </validity>
> </field>
> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! ->
>
>
>
> <field name="salesChannelEnumId" type="id"></field>
> <field name="orderDate" type="date-time"></field>
> <field name="entryDate" type="date-time"></field>
> <field name="visitId" type="id"></field>
> <field name="statusId" type="id"></field>
> <field name="createdBy" type="id-vlong"></field>
> <field name="firstAttemptOrderId" type="id"></field>
> <field name="currencyUom" type="id"></field>
> <field name="syncStatusId" type="id"></field>
> <field name="billingAccountId" type="id"></field>
> <field name="originFacilityId" type="id"></field>
> <field name="webSiteId" type="id"></field>
> <field name="productStoreId" type="id"></field>
> <field name="terminalId" type="id-long"></field>
> <field name="transactionId" type="id-long"></field>
> <field name="autoOrderShoppingListId" type="id"></field>
> <field name="needsInventoryIssuance" type="indicator"></field>
> <field name="isRushOrder" type="indicator"></field>
> <field name="internalCode" type="id-long"></field>
> <field name="remainingSubTotal" type="currency-amount"></field>
> <field name="grandTotal" type="currency-amount"></field>
> <prim-key field="orderId"/>
> <relation type="one" fk-name="ORDER_HDR_TYPE"
> rel-entity-name="OrderType">
> <key-map field-name="orderTypeId"/>
> </relation>
> <relation type="one" fk-name="ORDER_HDR_SCENUM" title="SalesChannel"
> rel-entity-name="Enumeration">
> <key-map field-name="salesChannelEnumId" rel-field-name="enumId"/>
> </relation>
> <relation type="one" fk-name="ORDER_HDR_OFAC" title="Origin"
> rel-entity-name="Facility">
> <key-map field-name="originFacilityId" rel-field-name="facilityId"/>
> </relation>
> <relation type="many" rel-entity-name="OrderTypeAttr">
> <key-map field-name="orderTypeId"/>
> </relation>
> <relation type="one" fk-name="ORDER_HDR_BACCT"
> rel-entity-name="BillingAccount">
> <key-map field-name="billingAccountId"/>
> </relation>
> <relation type="one" fk-name="ORDER_HDR_PDSTR"
> rel-entity-name="ProductStore">
> <key-map field-name="productStoreId"/>
> </relation>
> <relation type="one" fk-name="ORDER_HDR_AOSHLST" title="AutoOrder"
> rel-entity-name="ShoppingList">
> <key-map field-name="autoOrderShoppingListId"
> rel-field-name="shoppingListId"/>
> </relation>
> <relation type="one" fk-name="ORDER_HDR_CBUL" title="CreatedBy"
> rel-entity-name="UserLogin">
> <key-map field-name="createdBy" rel-field-name="userLoginId"/>
> </relation>
> <relation type="one" fk-name="ORDER_HDR_STTS"
> rel-entity-name="StatusItem">
> <key-map field-name="statusId"/>
> </relation>
> <relation type="one" fk-name="ORDER_HDR_SYST" title="Sync"
> rel-entity-name="StatusItem">
> <key-map field-name="syncStatusId" rel-field-name="statusId"/>
> </relation>
> <relation type="one" fk-name="ORDER_HDR_CUOM" rel-entity-name="Uom">
> <key-map field-name="currencyUom" rel-field-name="uomId"/>
> </relation>
> <relation type="many" rel-entity-name="OrderHeaderNoteView">
> <key-map field-name="orderId"/>
> </relation>
> <relation type="many" rel-entity-name="OrderItemAndShipGroupAssoc">
> <key-map field-name="orderId"/>
> </relation>
> <index name="ORDEREXT_ID_IDX">
> <index-field name="externalId"/>
> </index>
>
>
> <!- !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
> <!-
> In different context, maybe different set of fields need to show.
> So my idea
> here is to use "group" to group fields for different scenario. And
> then in UI
> level, we can define a jsp tag or something to only show fields
> within this group.
> ->
> <group name="summary">
> <field name="orderId" rank="1"/>
> <field name="orderTypeId" rank="10"/>
> <field name="orderName" rank="11"/>
> </group>
>
> <group name="details">
> <field name="orderId" rank="1"/>
> <field name="orderTypeId" rank="10"/>
> <field name="orderName" rank="11"/>
> <field name="externalId" rank="20">
> <!-
> !!!!Note: Though visibility is definded above with another
> condition. However, in this group
> (Scenario), externalID will always be visible.
> ->
> <visbility value="true"/>
> <field>
> </group>
> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!->
> </entity>
>
> Such an idea to make entity definition as a single point of
> configuration/customization might make system easier to maintain/customize.
> Am I right? If yes, anybody could suggest me how to implement it.
>
> (BTW: we are going to use ofbiz entity engine for our products just like
> what JIRA did. It would be great if such enhancement could be done direct
> under apache. Otherwise, we might have to maintain a customized ofbiz entity
> engine by ourselves.)
>
> --
> Regards,
> Michael Xu (xudong)
> www.wizitsoft.com | Office: (8610) 6267 0615 ext 806 | Mobile: (86) 135 0135
> 9807 | Fax: (8610) 62670096
--
Antwebsystems.com: Quality OFBiz services for competitive rates