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) <[email protected]>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 <[email protected]>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 <[email protected] >>> >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 >>>>> >>>>> >>>>> >>>> >> >
