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 <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
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>
> > >>>
> > >>
> > >
> >

Reply via email to