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