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 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
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 scott.g...@hotwaxmedia.comwrote: 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
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) dong...@wizitsoft.comwrote: 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.comwrote: 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
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) 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.comwrote: 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.comwrote: 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
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 scott.g...@hotwaxmedia.comwrote: 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
Re: Feedbacks on Bluelight theme
I like the bluelight theme. It has a fresh and bright feel... As such I find it more appealing than flatgray. However, the font size is to large for my taste. And I would rather like to see that I could go straight from the toplevel to a sub menu in 'applications' via some cascading of menu-items and sub menus. Further more if functionality is not supposed to be shown it should not be seen (e.g. competitors in the SFA menu), but I guess that has less to do with the style sheet. My 2 cents. Regards, Pierre 2009/10/15 Bruno Busco bruno.bu...@gmail.com Hi users! I would like to have your feedback on the Bluelight theme. - Do you find it is usable? - Do you find it is user friendly? - How would you like it to be improved? Please fill free to report any issue. Thank you very much, Bruno
Re: Recurrence Info Id
Gavin Mabie wrote: Hi All What is the Recurrence Info Id in Invoice Header represent? Thanks Gavin Hi Gavin, You may find out it here https://issues.apache.org/jira/browse/OFBIZ-1796 Bilgin
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 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.comwrote: 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:
Re: Feedbacks on Bluelight theme
Hi Ryan, Bruno: I couldn't have said it better myself. This is a great start and Ryan's comments are spot-on! Regards, Ruth Ryan Foster wrote: Bruno, I love the concept of the breadcrumb navigation. It is innovative, compact, and informative - once you figure out how to use it. I think in its current implementation, it is not very intuitive. It looks like a breadcrumb, and acts like a nav, but since it is a multi-functional element, it should look like a multi-functional element. It needs to look like a breadcrumb and it needs to look like navigation. Some of Yahoo!'s properties like Yahoo! Food and Yahoo! TV are good examples of this concept done right. I would love to see something like this in the BlueLight theme: Just my 2 cents. I like what you have done so, I just think it needs a little love... *Ryan Foster* HotWax Media 801.671.0769 ryan.fos...@hotwaxmedia.com mailto:ryan.fos...@hotwaxmedia.com On Oct 15, 2009, at 8:36 AM, Jacques Le Roux wrote: Hi Bruno, Actually I use more, in that order, Flat Grey and Business Time. There are no real reasons. I will try to use it a bit more and will give you a feedbak then. Cheers Jacques From: Bruno Busco bruno.bu...@gmail.com mailto:bruno.bu...@gmail.com Hi users! I would like to have your feedback on the Bluelight theme. - Do you find it is usable? - Do you find it is user friendly? - How would you like it to be improved? Please fill free to report any issue. Thank you very much, Bruno
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 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.comwrote: 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
Re: Digital Products
Hi Ruth, thanks for your reply! I will try the desribed steps. But actually I'm really confused... There's a link in the Back-Office on a Product-Detail-Page saying Content There I can add content with the type digital download. But obviously this does nothing ?!? Even the digital gizmo in the demo application does not offer a download after ordering in the frontend... (and that's in the demo application) Perhaps I'm too stupid - but shouldn't I get a download-Link in the order history in the front-end after ordering a digital gizmo??? Otherwise I cannot see the sense of the content-type digital-download... could PLEASE anyone explain what I'm doing wrong? Thanx Alexander Ruth Hoffman-2 wrote: Hi Alexander: I will repeat some instructions I posted before: One way to do this: Use the Content Manager application to create a Data Resource for each file. OFBiz Data Resources are similar to meta-data descriptions for files or other electronic media used by OFBiz. Use the Content Manager application to create a Content record for each file. Content records point to Data Resources. Use the Catalog Manager application to create a Product for each file that is associated with the Content record created above. Using the Prepare Content link as suggested before has not worked for me in the past. Perhaps it has been fixed. I haven't had time to check, however I just tried using it to add a file to an existing PRODUCT and was not successful. If you want more information about how to use the Catalog Manager, please consider purchasing my new book: Getting Started w/Apache OFBiz The Catalog Manager. See: http://www.myofbiz.com for more specifics. Regards, Ruth Alexander1893 wrote: Hi, thanks for the reply - but actually I'm not too sure I understood it right. I'm using that normal functionality in the catalog-manager: picking a from-Date with the date-selector and I get the error... Shouldn't this work with the standard? Thanks Best regards Alexander S K Pradeep kumar wrote: just parameter(fromDate) type is need to cast to Timestamp With regards, S K Pradeep kumar, On Sun, Oct 11, 2009 at 6:55 PM, Alexander1893 alexan...@familie-schweizer.net wrote: Hi all, I now found that there's some problem saving the content to the database: exception report -- =-=-=-=-=-=-=-=-= Database type warning GenericEntity.set =-=-=-=-=-=-=-=-= In e ntity field [ProductContent.fromDate] set the value passed in [java.lang.String] is not compatible with the Java type of the field [java.sql.Timestamp] Exception: java.lang.Exception Message: Location of database type warning stack trace --- Alexander1893 wrote: Can anyone help? Thanks and kind regards Alexander Hi all, can anyone tell me how I can associate a file with a digital product? As far as I understood a customer can download the digital product after the buying process - but I don't know how I can define the file that is the product. Thanx in advance! Cheers Alexander -- View this message in context: http://www.nabble.com/Digital-Products-tp25809620p25843429.html Sent from the OFBiz - User mailing list archive at Nabble.com. -- View this message in context: http://n4.nabble.com/Digital-Products-tp141422p252977.html Sent from the OFBiz - User mailing list archive at Nabble.com.
Extending id fields to more than 20 chars
Product identifiers in our industry are commonly longer than 20 characters. id and id-ne fields are defined as 20 character fields for all the databases I have looked at, and there seems to be some tight binding to the 20 character length in forms and screen templates. We are wondering how much work we would need to do, in order to change Product id's to id-longs. That sounds pretty big at first glance, since there is so much going on with Product in so many applications. Another option would be to standardize some kind of SKU and cross reference that to a domain-specific product ID but that would be much less convenient for the users. Please advise. -- James McGill Phoenix AZ
Re: Extending id fields to more than 20 chars
Hi James: I don't think the product id field was ever intended to be used interchangeably with such identifiers as SKUs. My understanding of the data model is that the product id is to uniquely identify the product within the OFBiz domain only. That is how I have always used it. When I needed to associate SKUs or other identifiers (for example I use ISBNs), I use the ID's tab within the Catalog Manager. Maybe someone who did the original data modeling could comment. Regards, Ruth James McGill wrote: Product identifiers in our industry are commonly longer than 20 characters. id and id-ne fields are defined as 20 character fields for all the databases I have looked at, and there seems to be some tight binding to the 20 character length in forms and screen templates. We are wondering how much work we would need to do, in order to change Product id's to id-longs. That sounds pretty big at first glance, since there is so much going on with Product in so many applications. Another option would be to standardize some kind of SKU and cross reference that to a domain-specific product ID but that would be much less convenient for the users. Please advise.
Re: Extending id fields to more than 20 chars
Some people like to use the product ID for SKUs - so you are not along in this request. here's you can do it easily: in framework/entity/fieldtype/fieldtype*.xml files -field-type-def type=id sql-type=VARCHAR(20) java- type=String/field-type-def +field-type-def type=id sql-type=VARCHAR(40) java- type=String/field-type-def That works like a charm if you choose to go this route. Cheers, Ruppert -- Tim Ruppert HotWax Media http://www.hotwaxmedia.com o:801.649.6594 f:801.649.6595 On Oct 16, 2009, at 2:40 PM, Ruth Hoffman wrote: Hi James: I don't think the product id field was ever intended to be used interchangeably with such identifiers as SKUs. My understanding of the data model is that the product id is to uniquely identify the product within the OFBiz domain only. That is how I have always used it. When I needed to associate SKUs or other identifiers (for example I use ISBNs), I use the ID's tab within the Catalog Manager. Maybe someone who did the original data modeling could comment. Regards, Ruth James McGill wrote: Product identifiers in our industry are commonly longer than 20 characters. id and id-ne fields are defined as 20 character fields for all the databases I have looked at, and there seems to be some tight binding to the 20 character length in forms and screen templates. We are wondering how much work we would need to do, in order to change Product id's to id- longs. That sounds pretty big at first glance, since there is so much going on with Product in so many applications. Another option would be to standardize some kind of SKU and cross reference that to a domain-specific product ID but that would be much less convenient for the users. Please advise. smime.p7s Description: S/MIME cryptographic signature
Re: Extending id fields to more than 20 chars
data model book uses Good Ident to define product Ids see page 75 of volume I Product Identification codes. also note that ofbiz uses product.internaName VARCHAR(255) for display and searches. this leave the productID free to just be internally for Database relationships. Note ProductID is part of the primary key so there are limitations to the index for certain databases. One of the reasons not to change it. You will find Data Model Handbook vol I invaluable to the Data modeling of ofbiz, even though some liberties have been taken. I also recommend vol II James McGill sent the following on 10/16/2009 1:18 PM: Product identifiers in our industry are commonly longer than 20 characters. id and id-ne fields are defined as 20 character fields for all the databases I have looked at, and there seems to be some tight binding to the 20 character length in forms and screen templates. We are wondering how much work we would need to do, in order to change Product id's to id-longs. That sounds pretty big at first glance, since there is so much going on with Product in so many applications. Another option would be to standardize some kind of SKU and cross reference that to a domain-specific product ID but that would be much less convenient for the users. Please advise. -- BJ Freeman http://www.businessesnetwork.com/automation http://bjfreeman.elance.com http://www.linkedin.com/profile?viewProfile=key=1237480locale=en_UStrk=tab_pro Systems Integrator.
inventory problem
Hello, When i try to add inventory to a specific inventoryitem, i receive the following error. The Following Errors Occurred: Error calling event: org.ofbiz.webapp.event.EventHandlerException: Service invocation error (Could not commit transaction for service [createPhysicalInventoryAndVariance] call: Roll back error, could not commit transaction, was rolled back instead because of: Service [createAcctgTransAndEntries] threw an unexpected exception/errororg.ofbiz.service.ServiceValidationException: The following required parameter is missing: [OUT] [createAcctgTransAndEntries.acctgTransId] (The following required parameter is missing: [OUT] [createAcctgTransAndEntries.acctgTransId])) Has anyone a solution to it? Thanks, Heidi Olagos team
Re: Extending id fields to more than 20 chars
On Fri, Oct 16, 2009 at 2:37 PM, Tim Ruppert tim.rupp...@hotwaxmedia.comwrote: Some people like to use the product ID for SKUs - so you are not along in this request. here's you can do it easily: in framework/entity/fieldtype/fieldtype*.xml files -field-type-def type=id sql-type=VARCHAR(20) java-type=String/field-type-def +field-type-def type=id sql-type=VARCHAR(40) java-type=String/field-type-def That works like a charm if you choose to go this route. However, 20 chars is hardcoded into forms. That's what scared me away from changing fieldtype. -- James McGill Phoenix AZ
Re: Extending id fields to more than 20 chars
Please note that what Ruth and BJ are mentioning here James is likely the preferred way to do this. The Good Identifiers is the way I'd push the client nowadays, but they do like this info in their IDs, so no need to push. Cheers, Ruppert -- Tim Ruppert HotWax Media http://www.hotwaxmedia.com o:801.649.6594 f:801.649.6595 On Oct 16, 2009, at 3:56 PM, BJ Freeman wrote: data model book uses Good Ident to define product Ids see page 75 of volume I Product Identification codes. also note that ofbiz uses product.internaName VARCHAR(255) for display and searches. this leave the productID free to just be internally for Database relationships. Note ProductID is part of the primary key so there are limitations to the index for certain databases. One of the reasons not to change it. You will find Data Model Handbook vol I invaluable to the Data modeling of ofbiz, even though some liberties have been taken. I also recommend vol II James McGill sent the following on 10/16/2009 1:18 PM: Product identifiers in our industry are commonly longer than 20 characters. id and id-ne fields are defined as 20 character fields for all the databases I have looked at, and there seems to be some tight binding to the 20 character length in forms and screen templates. We are wondering how much work we would need to do, in order to change Product id's to id- longs. That sounds pretty big at first glance, since there is so much going on with Product in so many applications. Another option would be to standardize some kind of SKU and cross reference that to a domain-specific product ID but that would be much less convenient for the users. Please advise. -- BJ Freeman http://www.businessesnetwork.com/automation http://bjfreeman.elance.com http://www.linkedin.com/profile?viewProfile=key=1237480locale=en_UStrk=tab_pro Systems Integrator. smime.p7s Description: S/MIME cryptographic signature
Re: inventory problem
Hi Heidi, I don't have an answer for you, but I'm pretty sure people have encountered it before so I would suggest checking the archives in nabble or markmail for a cause/solution. Also I'd encourage you file a bug report if you are able to reproduce the problem from a fresh checkout of your version of OFBiz. Even if the cause turns out to be an incorrect data setup on your end I think the error message could be improved. Regards Scott HotWax Media http://www.hotwaxmedia.com On 17/10/2009, at 10:59 AM, Heidi Dehaes wrote: Hello, When i try to add inventory to a specific inventoryitem, i receive the following error. The Following Errors Occurred: Error calling event: org.ofbiz.webapp.event.EventHandlerException: Service invocation error (Could not commit transaction for service [createPhysicalInventoryAndVariance] call: Roll back error, could not commit transaction, was rolled back instead because of: Service [createAcctgTransAndEntries] threw an unexpected exception/errororg.ofbiz.service.ServiceValidationException: The following required parameter is missing: [OUT] [createAcctgTransAndEntries.acctgTransId] (The following required parameter is missing: [OUT] [createAcctgTransAndEntries.acctgTransId])) Has anyone a solution to it? Thanks, Heidi Olagos team smime.p7s Description: S/MIME cryptographic signature
