Re: about entity engine

Thu, 15 Oct 2009 23:14:49 -0700

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.g...@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

Attachment: smime.p7s
Description: S/MIME cryptographic signature

Reply via email to