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