Re: about entity engine
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 or 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 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) : > > > 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) > > > 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 > >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
Re: about entity engine
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 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) : > > 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) > > 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 >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 b
Re: about entity engine
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 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 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: In order to enrich the definition (metadata) with more information, I am considering to put more tags (please find elements surrounded with !), like: ! ->
Re: about entity engine
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) : > 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) > 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 >> 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 >>> >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 >>
Re: about entity engine
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) 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 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 >> >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: >> >> > package-name="org.ofbiz.order.order" >> never-cache="true" >> title="Order Header Entity"> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >
Re: about entity engine
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 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 > >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: > > package-name="org.ofbiz.order.order" > never-cache="true" > title="Order Header Entity"> > > > > > > > > > > > > > > > > > > > > > > > > > > > rel-entity-name="OrderType"> > > > rel-entity-name="Enumeration"> > > > rel-entity-name="Facility"> > rel-field-name="facilityId"/> > > > > > rel-entity-name="BillingAccount"> > > > rel-entity-name="ProductStore"> > > > rel-entity-name="ShoppingList"> > rel-field-name="shoppingListId"/> > > rel-entity-name="UserLogin"> >
Re: about entity engine
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 >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: title="SalesChannel" rel-entity-name="Enumeration"> name="enumId"/> title="AutoOrder" rel-entity-name="ShoppingList"> name="Uom"> name="OrderItemAndShipGroupAssoc"> In order to enrich the definition (metadata) with more information, I am considering to put more tags (please find elements surrounded with !), like: We can use "visiblity" tag to tell system when to show this field in UI layer. -> ! -> title="SalesChannel" rel-entity-name="Enumeration"> name="enumId"/> title="AutoOrder" rel-entity-name="ShoppingList"> name="Uom"> name="OrderItemAndShipGroupAssoc"> 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. -> Note: Though visibility is definded above with another condition. However, in this group (Scenario), externalID will always be visible. -> !!!-> Such an idea to make entity definition as a single point of configuration/customization might make system easier to maintain/customize.
Re: about entity engine
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 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: >>> >>> >> package-name="org.ofbiz.order.order" >>> never-cache="true" >>> title="Order Header Entity"> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >> rel-entity-name="OrderType"> >>> >>> >>> >> rel-entity-name="Enumeration"> >>> >>> >>> >> rel-entity-name="Facility"> >>> >> rel-field-name="facilityId"/> >>> >>> >>> >>> >>> >> rel-entity-name="BillingAccount"> >>> >>> >>> >> rel-entity-name="ProductStore"> >>> >>> >>> >> rel-entity-name="ShoppingList"> >>> >> rel-field-name="shoppingListId"/> >>> >>> >> rel-entity-name="UserLogin"> >>> >>> >>> >> rel-entity-name="StatusItem"> >>> >>> >>> >> rel-entity-name="StatusItem"> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> In order to enrich the definition (metadata) with more information, I am >>> considering to put more tags (please find elements surrounded with >>> !), like: >>> >>> >> package-name="org.ofbiz.order.order" >>> never-cache="true" >>> title="Order Header Entity"> >>> >>> >>> >>> >>> >>> >> >>> >> We can use "visiblity" tag to tell system when to show this >>> field in UI layer. >>> -> >>> >>> >> implementation="org.ofbiz.core.condition.NonEmptyField"/> >>> >>> >>> >>> >>> >>> ! -> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >> rel-entity-name="OrderType"> >>> >>> >>> >> rel-entity-name="Enumeration"> >>> >>> >>> >> rel-entity-name="Facility"> >>> >> rel-field-name="facilityId"/> >>> >>> >>> >>> >>> >> rel-entity-name="BillingAccount"> >>> >>> >>> >> rel-entity-name="ProductStore"> >>> >>> >>> >> rel-entity-name="ShoppingList"> >>> >> rel-field-name="shoppingListId"/> >>> >>> >> rel-entity-name="UserLogin"> >>> >>> >>> >> rel-entity-name="StatusItem"> >>> >>> >>> >> rel-entity-name="StatusItem"> >>> >>> >>> >>>
Re: about entity engine
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: title="SalesChannel" rel-entity-name="Enumeration"> name="enumId"/> name="facilityId"/> title="AutoOrder" rel-entity-name="ShoppingList"> name="Uom"> name="OrderItemAndShipGroupAssoc"> In order to enrich the definition (metadata) with more information, I am considering to put more tags (please find elements surrounded with !), like: We can use "visiblity" tag to tell system when to show this field in UI layer. -> ! -> title="SalesChannel" rel-entity-name="Enumeration"> name="enumId"/> name="facilityId"/> title="AutoOrder" rel-entity-name="ShoppingList"> name="Uom"> name="OrderItemAndShipGroupAssoc"> 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. -> Note: Though visibility is definded above with another condition. However, in this group (Scenario), externalID will always be visible. -> !!!-> 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 Description: S/MIME cryptographic signature
Re: about entity engine
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: > > package-name="org.ofbiz.order.order" > never-cache="true" > title="Order Header Entity"> > > > > > > > > > > > > > > > > > > > > > > > > > > >rel-entity-name="OrderType"> > > >rel-entity-name="Enumeration"> > > >rel-entity-name="Facility"> > > > > > >rel-entity-name="BillingAccount"> > > >rel-entity-name="ProductStore"> > > >rel-entity-name="ShoppingList"> > rel-field-name="shoppingListId"/> > >rel-entity-name="UserLogin"> > > >rel-entity-name="StatusItem"> > > >rel-entity-name="StatusItem"> > > > > > > > > > > > > > > > > > In order to enrich the definition (metadata) with more information, I am > considering to put more tags (please find elements surrounded with > !), like: > > package-name="org.ofbiz.order.order" > never-cache="true" > title="Order Header Entity"> > > > > > > > We can use "visiblity" tag to tell system when to show this > field in UI layer. > -> > > implementation="org.ofbiz.core.condition.NonEmptyField"/> > > > > > > ! -> > > > > > > > > > > > > > > > > > > > > > > > > > >rel-entity-name="OrderType"> > > >rel-entity-name="Enumeration"> > > >rel-entity-name="Facility"> > > > > > >rel-entity-name="BillingAccount"> > > >rel-entity-name="ProductStore"> > > >rel-entity-name="ShoppingList"> > rel-field-name="shoppingListId"/> > >rel-entity-name="UserLogin"> > > >rel-entity-name="StatusItem"> > > >rel-entity-name="StatusItem"> > > > > > > > > > > > > > > > > >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. >-> > > > > > > > > > > > >Note: Though visibility is definded above with another > condition. However, in this group > (Scenario), externalID will always be visible. > -> > > > > !!!-> > > > 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
about entity engine
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: In order to enrich the definition (metadata) with more information, I am considering to put more tags (please find elements surrounded with !), like: ! -> !!!-> 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
Re: Beginner Question about Entity Engine
I found what I needed in synchronous services and the ECA's. Amazing what you learn in the nth reading of something. Thanks! On Mon, Dec 8, 2008 at 11:22 AM, cjhorton <[EMAIL PROTECTED]> wrote: > > Hi Everyone, > > I have a beginner's conceptual question regarding the entity engine and > related entities. > > Do the key-map fields of the related entities get automatically populated > when a CRUD(well not the R) event occurs on the parent entity? > > Or do I have to code those all in in my services? > > Thank you for your time. > -- > View this message in context: > http://www.nabble.com/Beginner-Question-about-Entity-Engine-tp20899618p20899618.html > Sent from the OFBiz - User mailing list archive at Nabble.com. > >
Beginner Question about Entity Engine
Hi Everyone, I have a beginner's conceptual question regarding the entity engine and related entities. Do the key-map fields of the related entities get automatically populated when a CRUD(well not the R) event occurs on the parent entity? Or do I have to code those all in in my services? Thank you for your time. -- View this message in context: http://www.nabble.com/Beginner-Question-about-Entity-Engine-tp20899618p20899618.html Sent from the OFBiz - User mailing list archive at Nabble.com.
