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 |
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 |
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 > smime.p7s (4K) Download Attachment |
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 <[hidden email]>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 >> >> > |
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 <[hidden email] > >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 >>> >>> >> smime.p7s (4K) Download Attachment |
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 <[hidden email]>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 <[hidden email] >> >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 >>>> >>>> >>>> >>> > |
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) <[hidden email]>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 <[hidden email]>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 <[hidden email] >>> >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 >>>>> >>>>> >>>>> >>>> >> > |
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) <[hidden email]>: > 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) > <[hidden email]>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 <[hidden email]>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 <[hidden email] >>>> >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 >>>>>> >>>>>> >>>>>> >>>>> >>> >> > |
In reply to this post by Michael Xu (xudong)
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 <[hidden email]>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 <[hidden email] >>> >>>> 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/ |
In reply to this post by Bruno Busco
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 <[hidden email]> 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) <[hidden email]>: > > 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) > > <[hidden email]>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 <[hidden email] > >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 < > [hidden email] > >>>> >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 > >>>>>> > >>>>>> > >>>>>> > >>>>> > >>> > >> > > > |
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 <[hidden email]> 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) <[hidden email]>: > > > 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) > > > <[hidden email]>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 <[hidden email] > > >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 < > > [hidden email] > > >>>> >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 > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>> > > >>> > > >> > > > > > |
Free forum by Nabble | Edit this page |