Hi, All
In my project, there are many protocols to set up. For every protocol, it has many attributes. All these protocols have been divided into several types according to their usage. For example A type has attributes: ChlUrl, SupportedCharsets, ServerID B type has attributes: InClientPull C type has attributes: ChlUrl, SMRCustomerType, GMDChargingCurrency, SupportedCharsets, ServerID <form name="A" type="single" target="createProtocolAttribute?protocolid=${id}"> <field name="ChlUrl"><text/></field> <field name="SupportedCharsets"><text/></field> <field name="ServerID"><text/></field> <field name="submitButton" title="Add Protocol"> <submit button-type="button"/> </field> </form> <form name="B" type="single" target="createProtocolAttribute?protocolid=${id}"> <field name="InClientPull"><text/></field> <field name="submitButton" title="Add Protocol"> <submit button-type="button"/> </field> </form> <form name="C" type="single" target="createProtocolAttribute?protocolid=${id}"> <field name="ChlUrl"><text/></field> <field name="SMRCustomerType"><text/></field> <field name="GMDChargingCurrency"><text/></field> <field name="SupportedCharsets"><text/></field> <field name="ServerID"><text/></field> <field name="submitButton" title="Add Protocol"> <submit button-type="button"/> </field> </form> When setting up a protocol in a web page, first choose a type from drop-down list, the web page show attributes relating to its type. After filling in the attributes' value, submit the form and save all these attribute-value pairs in the table protocolAttribute below. services.xml <service name=" createProtocolAttribute " engine="java" location="com.xian.cmb.CmbServices" invoke="createProtocolAttribute"> <attribute name="ChlUrl" mode="IN" type="String" optional="true" /> <attribute name="SupportedCharsets" mode="IN" type="String" optional="true" /> <attribute name="ServerID" mode="IN" type="String" optional="true" /> <attribute name="InClientPull" mode="IN" type="String" optional="true" /> <attribute name="SMRCustomerType" mode="IN" type="String" optional="true" /> <attribute name="GMDChargingCurrency" mode="IN" type="String" optional="true" /> </service> Tables: protocol: protocolid, protocolName. protocolAttribute: id, protocolid, attribute, value. With the progress of technology, the number of every protocol's attributes is increasing. So we need to modify the forms in the screens to add new fields and services.xml file to add mode IN attributes, and java code to save newly added attribute-value pairs. Can OFBiz have solutions to deal with the CHANGE and When adding an attribute, we needn't modify the form, services.xml and java source code? Best Regards, Jack Liu |
Yes. Look at the entities, services, and forms in the Example application (and in fact most in OFBiz). The pattern we usually use is that services are derived from entities (both defs and implementation), and forms (ie form fields) are derived from services. So, if you add a field to the entity it will show up in the service and the form. If you haven't already, you should check out the framework introduction videos, which explain this and other patterns: http://docs.ofbiz.org/display/OFBTECH/Framework+Introduction+Videos+and+Diagrams -David On Feb 16, 2009, at 6:29 PM, Jack Liu wrote: > Hi, All > In my project, there are many protocols to set up. > For every protocol, it has many attributes. > All these protocols have been divided into several types according to > their usage. > > For example > A type has attributes: ChlUrl, SupportedCharsets, ServerID > B type has attributes: InClientPull > C type has attributes: ChlUrl, SMRCustomerType, GMDChargingCurrency, > SupportedCharsets, ServerID > > <form name="A" type="single" > target="createProtocolAttribute?protocolid=${id}"> > <field name="ChlUrl"><text/></field> > <field name="SupportedCharsets"><text/></field> > <field name="ServerID"><text/></field> > <field name="submitButton" title="Add Protocol"> > <submit button-type="button"/> > </field> > </form> > <form name="B" type="single" > target="createProtocolAttribute?protocolid=${id}"> > <field name="InClientPull"><text/></field> > <field name="submitButton" title="Add Protocol"> > <submit button-type="button"/> > </field> > </form> > <form name="C" type="single" > target="createProtocolAttribute?protocolid=${id}"> > <field name="ChlUrl"><text/></field> > <field name="SMRCustomerType"><text/></field> > <field name="GMDChargingCurrency"><text/></field> > <field name="SupportedCharsets"><text/></field> > <field name="ServerID"><text/></field> > <field name="submitButton" title="Add Protocol"> > <submit button-type="button"/> > </field> > </form> > > When setting up a protocol in a web page, first choose a type from > drop-down list, the web page show attributes relating to its type. > After filling in the attributes' value, submit the form and save all > these attribute-value pairs in the table protocolAttribute below. > > services.xml > <service name=" createProtocolAttribute " engine="java" > location="com.xian.cmb.CmbServices" invoke="createProtocolAttribute"> > <attribute name="ChlUrl" mode="IN" type="String" > optional="true" /> > <attribute name="SupportedCharsets" mode="IN" > type="String" optional="true" /> > <attribute name="ServerID" mode="IN" type="String" > optional="true" /> > <attribute name="InClientPull" mode="IN" type="String" > optional="true" /> > <attribute name="SMRCustomerType" mode="IN" > type="String" optional="true" /> > <attribute name="GMDChargingCurrency" mode="IN" > type="String" optional="true" /> > </service> > > > Tables: > protocol: protocolid, protocolName. > protocolAttribute: id, protocolid, attribute, value. > > > With the progress of technology, the number of every protocol's > attributes is increasing. > So we need to modify the forms in the screens to add new fields and > services.xml file to add mode IN attributes, and java code to save > newly > added attribute-value pairs. > Can OFBiz have solutions to deal with the CHANGE and When adding an > attribute, we needn't modify the form, services.xml and java source > code? > > > > > Best Regards, > > Jack Liu > |
Maybe I didn't make myself clear.
We know, if we add a field in the entity, it will show up in the service and the form automatically. But in my projects, we add NOT a field in the entity, but a VALUE. From the view of database, we just add a record in the table, not a field. It's totally different. -----Original Message----- From: David E Jones [mailto:[hidden email]] Sent: 2009年2月17日 9:39 To: [hidden email] Subject: Re: Tricky! About fields in the form Yes. Look at the entities, services, and forms in the Example application (and in fact most in OFBiz). The pattern we usually use is that services are derived from entities (both defs and implementation), and forms (ie form fields) are derived from services. So, if you add a field to the entity it will show up in the service and the form. If you haven't already, you should check out the framework introduction videos, which explain this and other patterns: http://docs.ofbiz.org/display/OFBTECH/Framework+Introduction+Videos+and+Diagrams -David On Feb 16, 2009, at 6:29 PM, Jack Liu wrote: > Hi, All > In my project, there are many protocols to set up. > For every protocol, it has many attributes. > All these protocols have been divided into several types according to > their usage. > > For example > A type has attributes: ChlUrl, SupportedCharsets, ServerID > B type has attributes: InClientPull > C type has attributes: ChlUrl, SMRCustomerType, GMDChargingCurrency, > SupportedCharsets, ServerID > > <form name="A" type="single" > target="createProtocolAttribute?protocolid=${id}"> > <field name="ChlUrl"><text/></field> > <field name="SupportedCharsets"><text/></field> > <field name="ServerID"><text/></field> > <field name="submitButton" title="Add Protocol"> > <submit button-type="button"/> > </field> > </form> > <form name="B" type="single" > target="createProtocolAttribute?protocolid=${id}"> > <field name="InClientPull"><text/></field> > <field name="submitButton" title="Add Protocol"> > <submit button-type="button"/> > </field> > </form> > <form name="C" type="single" > target="createProtocolAttribute?protocolid=${id}"> > <field name="ChlUrl"><text/></field> > <field name="SMRCustomerType"><text/></field> > <field name="GMDChargingCurrency"><text/></field> > <field name="SupportedCharsets"><text/></field> > <field name="ServerID"><text/></field> > <field name="submitButton" title="Add Protocol"> > <submit button-type="button"/> > </field> > </form> > > When setting up a protocol in a web page, first choose a type from > drop-down list, the web page show attributes relating to its type. > After filling in the attributes' value, submit the form and save all > these attribute-value pairs in the table protocolAttribute below. > > services.xml > <service name=" createProtocolAttribute " engine="java" > location="com.xian.cmb.CmbServices" invoke="createProtocolAttribute"> > <attribute name="ChlUrl" mode="IN" type="String" > optional="true" /> > <attribute name="SupportedCharsets" mode="IN" > type="String" optional="true" /> > <attribute name="ServerID" mode="IN" type="String" > optional="true" /> > <attribute name="InClientPull" mode="IN" type="String" > optional="true" /> > <attribute name="SMRCustomerType" mode="IN" > type="String" optional="true" /> > <attribute name="GMDChargingCurrency" mode="IN" > type="String" optional="true" /> > </service> > > > Tables: > protocol: protocolid, protocolName. > protocolAttribute: id, protocolid, attribute, value. > > > With the progress of technology, the number of every protocol's > attributes is increasing. > So we need to modify the forms in the screens to add new fields and > services.xml file to add mode IN attributes, and java code to save > newly > added attribute-value pairs. > Can OFBiz have solutions to deal with the CHANGE and When adding an > attribute, we needn't modify the form, services.xml and java source > code? > > > > > Best Regards, > > Jack Liu > |
In the table protocolAttribute, records show below
id, protocolid, attribute, value 1 1 ChlUrl 192.168.77.22/abc 2 1 ServerID DWAI 3 2 ChlUrl 192.168.77.22/abc 4 2 SupportedCharsets gbk,UTF8 -----Original Message----- From: Jack Liu [mailto:[hidden email]] Sent: 2009年2月17日 9:55 To: [hidden email] Subject: RE: Tricky! About fields in the form Maybe I didn't make myself clear. We know, if we add a field in the entity, it will show up in the service and the form automatically. But in my projects, we add NOT a field in the entity, but a VALUE. From the view of database, we just add a record in the table, not a field. It's totally different. -----Original Message----- From: David E Jones [mailto:[hidden email]] Sent: 2009年2月17日 9:39 To: [hidden email] Subject: Re: Tricky! About fields in the form Yes. Look at the entities, services, and forms in the Example application (and in fact most in OFBiz). The pattern we usually use is that services are derived from entities (both defs and implementation), and forms (ie form fields) are derived from services. So, if you add a field to the entity it will show up in the service and the form. If you haven't already, you should check out the framework introduction videos, which explain this and other patterns: http://docs.ofbiz.org/display/OFBTECH/Framework+Introduction+Videos+and+Diagrams -David On Feb 16, 2009, at 6:29 PM, Jack Liu wrote: > Hi, All > In my project, there are many protocols to set up. > For every protocol, it has many attributes. > All these protocols have been divided into several types according to > their usage. > > For example > A type has attributes: ChlUrl, SupportedCharsets, ServerID > B type has attributes: InClientPull > C type has attributes: ChlUrl, SMRCustomerType, GMDChargingCurrency, > SupportedCharsets, ServerID > > <form name="A" type="single" > target="createProtocolAttribute?protocolid=${id}"> > <field name="ChlUrl"><text/></field> > <field name="SupportedCharsets"><text/></field> > <field name="ServerID"><text/></field> > <field name="submitButton" title="Add Protocol"> > <submit button-type="button"/> > </field> > </form> > <form name="B" type="single" > target="createProtocolAttribute?protocolid=${id}"> > <field name="InClientPull"><text/></field> > <field name="submitButton" title="Add Protocol"> > <submit button-type="button"/> > </field> > </form> > <form name="C" type="single" > target="createProtocolAttribute?protocolid=${id}"> > <field name="ChlUrl"><text/></field> > <field name="SMRCustomerType"><text/></field> > <field name="GMDChargingCurrency"><text/></field> > <field name="SupportedCharsets"><text/></field> > <field name="ServerID"><text/></field> > <field name="submitButton" title="Add Protocol"> > <submit button-type="button"/> > </field> > </form> > > When setting up a protocol in a web page, first choose a type from > drop-down list, the web page show attributes relating to its type. > After filling in the attributes' value, submit the form and save all > these attribute-value pairs in the table protocolAttribute below. > > services.xml > <service name=" createProtocolAttribute " engine="java" > location="com.xian.cmb.CmbServices" invoke="createProtocolAttribute"> > <attribute name="ChlUrl" mode="IN" type="String" > optional="true" /> > <attribute name="SupportedCharsets" mode="IN" > type="String" optional="true" /> > <attribute name="ServerID" mode="IN" type="String" > optional="true" /> > <attribute name="InClientPull" mode="IN" type="String" > optional="true" /> > <attribute name="SMRCustomerType" mode="IN" > type="String" optional="true" /> > <attribute name="GMDChargingCurrency" mode="IN" > type="String" optional="true" /> > </service> > > > Tables: > protocol: protocolid, protocolName. > protocolAttribute: id, protocolid, attribute, value. > > > With the progress of technology, the number of every protocol's > attributes is increasing. > So we need to modify the forms in the screens to add new fields and > services.xml file to add mode IN attributes, and java code to save > newly > added attribute-value pairs. > Can OFBiz have solutions to deal with the CHANGE and When adding an > attribute, we needn't modify the form, services.xml and java source > code? > > > > > Best Regards, > > Jack Liu > |
In reply to this post by Jack Liu-2
Why not use entity fields instead of attribute/value pairs? -David On Feb 16, 2009, at 6:54 PM, Jack Liu wrote: > Maybe I didn't make myself clear. > We know, if we add a field in the entity, it will show up in the > service and the form automatically. > But in my projects, we add NOT a field in the entity, but a VALUE. > From the view of database, we just add a record in the table, not a > field. > > It's totally different. > > -----Original Message----- > From: David E Jones [mailto:[hidden email]] > Sent: 2009年2月17日 9:39 > To: [hidden email] > Subject: Re: Tricky! About fields in the form > > > Yes. Look at the entities, services, and forms in the Example > application (and in fact most in OFBiz). > > The pattern we usually use is that services are derived from entities > (both defs and implementation), and forms (ie form fields) are derived > from services. So, if you add a field to the entity it will show up in > the service and the form. > > If you haven't already, you should check out the framework > introduction videos, which explain this and other patterns: > > http://docs.ofbiz.org/display/OFBTECH/Framework+Introduction+Videos+and+Diagrams > > -David > > > On Feb 16, 2009, at 6:29 PM, Jack Liu wrote: > >> Hi, All >> In my project, there are many protocols to set up. >> For every protocol, it has many attributes. >> All these protocols have been divided into several types according to >> their usage. >> >> For example >> A type has attributes: ChlUrl, SupportedCharsets, ServerID >> B type has attributes: InClientPull >> C type has attributes: ChlUrl, SMRCustomerType, GMDChargingCurrency, >> SupportedCharsets, ServerID >> >> <form name="A" type="single" >> target="createProtocolAttribute?protocolid=${id}"> >> <field name="ChlUrl"><text/></field> >> <field name="SupportedCharsets"><text/></field> >> <field name="ServerID"><text/></field> >> <field name="submitButton" title="Add Protocol"> >> <submit button-type="button"/> >> </field> >> </form> >> <form name="B" type="single" >> target="createProtocolAttribute?protocolid=${id}"> >> <field name="InClientPull"><text/></field> >> <field name="submitButton" title="Add Protocol"> >> <submit button-type="button"/> >> </field> >> </form> >> <form name="C" type="single" >> target="createProtocolAttribute?protocolid=${id}"> >> <field name="ChlUrl"><text/></field> >> <field name="SMRCustomerType"><text/></field> >> <field name="GMDChargingCurrency"><text/></field> >> <field name="SupportedCharsets"><text/></field> >> <field name="ServerID"><text/></field> >> <field name="submitButton" title="Add Protocol"> >> <submit button-type="button"/> >> </field> >> </form> >> >> When setting up a protocol in a web page, first choose a type from >> drop-down list, the web page show attributes relating to its type. >> After filling in the attributes' value, submit the form and save all >> these attribute-value pairs in the table protocolAttribute below. >> >> services.xml >> <service name=" createProtocolAttribute " engine="java" >> location="com.xian.cmb.CmbServices" invoke="createProtocolAttribute"> >> <attribute name="ChlUrl" mode="IN" type="String" >> optional="true" /> >> <attribute name="SupportedCharsets" mode="IN" >> type="String" optional="true" /> >> <attribute name="ServerID" mode="IN" type="String" >> optional="true" /> >> <attribute name="InClientPull" mode="IN" type="String" >> optional="true" /> >> <attribute name="SMRCustomerType" mode="IN" >> type="String" optional="true" /> >> <attribute name="GMDChargingCurrency" mode="IN" >> type="String" optional="true" /> >> </service> >> >> >> Tables: >> protocol: protocolid, protocolName. >> protocolAttribute: id, protocolid, attribute, value. >> >> >> With the progress of technology, the number of every protocol's >> attributes is increasing. >> So we need to modify the forms in the screens to add new fields and >> services.xml file to add mode IN attributes, and java code to save >> newly >> added attribute-value pairs. >> Can OFBiz have solutions to deal with the CHANGE and When adding an >> attribute, we needn't modify the form, services.xml and java source >> code? >> >> >> >> >> Best Regards, >> >> Jack Liu >> > |
Because there are about several hundrends attributes.
-----Original Message----- From: David E Jones [mailto:[hidden email]] Sent: 2009年2月17日 10:05 To: [hidden email] Subject: Re: Tricky! About fields in the form Why not use entity fields instead of attribute/value pairs? -David On Feb 16, 2009, at 6:54 PM, Jack Liu wrote: > Maybe I didn't make myself clear. > We know, if we add a field in the entity, it will show up in the > service and the form automatically. > But in my projects, we add NOT a field in the entity, but a VALUE. > From the view of database, we just add a record in the table, not a > field. > > It's totally different. > > -----Original Message----- > From: David E Jones [mailto:[hidden email]] > Sent: 2009年2月17日 9:39 > To: [hidden email] > Subject: Re: Tricky! About fields in the form > > > Yes. Look at the entities, services, and forms in the Example > application (and in fact most in OFBiz). > > The pattern we usually use is that services are derived from entities > (both defs and implementation), and forms (ie form fields) are derived > from services. So, if you add a field to the entity it will show up in > the service and the form. > > If you haven't already, you should check out the framework > introduction videos, which explain this and other patterns: > > http://docs.ofbiz.org/display/OFBTECH/Framework+Introduction+Videos+and+Diagrams > > -David > > > On Feb 16, 2009, at 6:29 PM, Jack Liu wrote: > >> Hi, All >> In my project, there are many protocols to set up. >> For every protocol, it has many attributes. >> All these protocols have been divided into several types according to >> their usage. >> >> For example >> A type has attributes: ChlUrl, SupportedCharsets, ServerID >> B type has attributes: InClientPull >> C type has attributes: ChlUrl, SMRCustomerType, GMDChargingCurrency, >> SupportedCharsets, ServerID >> >> <form name="A" type="single" >> target="createProtocolAttribute?protocolid=${id}"> >> <field name="ChlUrl"><text/></field> >> <field name="SupportedCharsets"><text/></field> >> <field name="ServerID"><text/></field> >> <field name="submitButton" title="Add Protocol"> >> <submit button-type="button"/> >> </field> >> </form> >> <form name="B" type="single" >> target="createProtocolAttribute?protocolid=${id}"> >> <field name="InClientPull"><text/></field> >> <field name="submitButton" title="Add Protocol"> >> <submit button-type="button"/> >> </field> >> </form> >> <form name="C" type="single" >> target="createProtocolAttribute?protocolid=${id}"> >> <field name="ChlUrl"><text/></field> >> <field name="SMRCustomerType"><text/></field> >> <field name="GMDChargingCurrency"><text/></field> >> <field name="SupportedCharsets"><text/></field> >> <field name="ServerID"><text/></field> >> <field name="submitButton" title="Add Protocol"> >> <submit button-type="button"/> >> </field> >> </form> >> >> When setting up a protocol in a web page, first choose a type from >> drop-down list, the web page show attributes relating to its type. >> After filling in the attributes' value, submit the form and save all >> these attribute-value pairs in the table protocolAttribute below. >> >> services.xml >> <service name=" createProtocolAttribute " engine="java" >> location="com.xian.cmb.CmbServices" invoke="createProtocolAttribute"> >> <attribute name="ChlUrl" mode="IN" type="String" >> optional="true" /> >> <attribute name="SupportedCharsets" mode="IN" >> type="String" optional="true" /> >> <attribute name="ServerID" mode="IN" type="String" >> optional="true" /> >> <attribute name="InClientPull" mode="IN" type="String" >> optional="true" /> >> <attribute name="SMRCustomerType" mode="IN" >> type="String" optional="true" /> >> <attribute name="GMDChargingCurrency" mode="IN" >> type="String" optional="true" /> >> </service> >> >> >> Tables: >> protocol: protocolid, protocolName. >> protocolAttribute: id, protocolid, attribute, value. >> >> >> With the progress of technology, the number of every protocol's >> attributes is increasing. >> So we need to modify the forms in the screens to add new fields and >> services.xml file to add mode IN attributes, and java code to save >> newly >> added attribute-value pairs. >> Can OFBiz have solutions to deal with the CHANGE and When adding an >> attribute, we needn't modify the form, services.xml and java source >> code? >> >> >> >> >> Best Regards, >> >> Jack Liu >> > |
In reply to this post by Jack Liu-2
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1 seems you duplicating the load entities from web tools. Jack Liu sent the following on 2/16/2009 5:54 PM: > Maybe I didn't make myself clear. > We know, if we add a field in the entity, it will show up in the service and the form automatically. > But in my projects, we add NOT a field in the entity, but a VALUE. >>From the view of database, we just add a record in the table, not a field. > > It's totally different. > > -----Original Message----- > From: David E Jones [mailto:[hidden email]] > Sent: 2009年2月17日 9:39 > To: [hidden email] > Subject: Re: Tricky! About fields in the form > > > Yes. Look at the entities, services, and forms in the Example > application (and in fact most in OFBiz). > > The pattern we usually use is that services are derived from entities > (both defs and implementation), and forms (ie form fields) are derived > from services. So, if you add a field to the entity it will show up in > the service and the form. > > If you haven't already, you should check out the framework > introduction videos, which explain this and other patterns: > > http://docs.ofbiz.org/display/OFBTECH/Framework+Introduction+Videos+and+Diagrams > > -David > > > On Feb 16, 2009, at 6:29 PM, Jack Liu wrote: > >> Hi, All >> In my project, there are many protocols to set up. >> For every protocol, it has many attributes. >> All these protocols have been divided into several types according to >> their usage. >> >> For example >> A type has attributes: ChlUrl, SupportedCharsets, ServerID >> B type has attributes: InClientPull >> C type has attributes: ChlUrl, SMRCustomerType, GMDChargingCurrency, >> SupportedCharsets, ServerID >> >> <form name="A" type="single" >> target="createProtocolAttribute?protocolid=${id}"> >> <field name="ChlUrl"><text/></field> >> <field name="SupportedCharsets"><text/></field> >> <field name="ServerID"><text/></field> >> <field name="submitButton" title="Add Protocol"> >> <submit button-type="button"/> >> </field> >> </form> >> <form name="B" type="single" >> target="createProtocolAttribute?protocolid=${id}"> >> <field name="InClientPull"><text/></field> >> <field name="submitButton" title="Add Protocol"> >> <submit button-type="button"/> >> </field> >> </form> >> <form name="C" type="single" >> target="createProtocolAttribute?protocolid=${id}"> >> <field name="ChlUrl"><text/></field> >> <field name="SMRCustomerType"><text/></field> >> <field name="GMDChargingCurrency"><text/></field> >> <field name="SupportedCharsets"><text/></field> >> <field name="ServerID"><text/></field> >> <field name="submitButton" title="Add Protocol"> >> <submit button-type="button"/> >> </field> >> </form> >> >> When setting up a protocol in a web page, first choose a type from >> drop-down list, the web page show attributes relating to its type. >> After filling in the attributes' value, submit the form and save all >> these attribute-value pairs in the table protocolAttribute below. >> >> services.xml >> <service name=" createProtocolAttribute " engine="java" >> location="com.xian.cmb.CmbServices" invoke="createProtocolAttribute"> >> <attribute name="ChlUrl" mode="IN" type="String" >> optional="true" /> >> <attribute name="SupportedCharsets" mode="IN" >> type="String" optional="true" /> >> <attribute name="ServerID" mode="IN" type="String" >> optional="true" /> >> <attribute name="InClientPull" mode="IN" type="String" >> optional="true" /> >> <attribute name="SMRCustomerType" mode="IN" >> type="String" optional="true" /> >> <attribute name="GMDChargingCurrency" mode="IN" >> type="String" optional="true" /> >> </service> >> >> >> Tables: >> protocol: protocolid, protocolName. >> protocolAttribute: id, protocolid, attribute, value. >> >> >> With the progress of technology, the number of every protocol's >> attributes is increasing. >> So we need to modify the forms in the screens to add new fields and >> services.xml file to add mode IN attributes, and java code to save >> newly >> added attribute-value pairs. >> Can OFBiz have solutions to deal with the CHANGE and When adding an >> attribute, we needn't modify the form, services.xml and java source >> code? >> >> >> >> >> Best Regards, >> >> Jack Liu >> > > > Version: GnuPG v1.4.6 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJmjM3rP3NbaWWqE4RAnAoAJ0aTQS1FpqEozW+Dp2LWziwJKp5NwCcCQn1 RW2dV4sNkKK1bajuR5a/m6c= =GWNB -----END PGP SIGNATURE----- |
It seems that what you said has nothing with my problem.
Hi,all I know it's very difficult to implement this feature even with other frameworks such as struts, jsf and spring. Any solutions in OFBiz? -----Original Message----- From: BJ Freeman [mailto:[hidden email]] Sent: 2009年2月17日 11:47 To: [hidden email] Subject: Re: Tricky! About fields in the form -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 seems you duplicating the load entities from web tools. Jack Liu sent the following on 2/16/2009 5:54 PM: > Maybe I didn't make myself clear. > We know, if we add a field in the entity, it will show up in the service and the form automatically. > But in my projects, we add NOT a field in the entity, but a VALUE. >>From the view of database, we just add a record in the table, not a field. > > It's totally different. > > -----Original Message----- > From: David E Jones [mailto:[hidden email]] > Sent: 2009年2月17日 9:39 > To: [hidden email] > Subject: Re: Tricky! About fields in the form > > > Yes. Look at the entities, services, and forms in the Example > application (and in fact most in OFBiz). > > The pattern we usually use is that services are derived from entities > (both defs and implementation), and forms (ie form fields) are derived > from services. So, if you add a field to the entity it will show up in > the service and the form. > > If you haven't already, you should check out the framework > introduction videos, which explain this and other patterns: > > http://docs.ofbiz.org/display/OFBTECH/Framework+Introduction+Videos+and+Diagrams > > -David > > > On Feb 16, 2009, at 6:29 PM, Jack Liu wrote: > >> Hi, All >> In my project, there are many protocols to set up. >> For every protocol, it has many attributes. >> All these protocols have been divided into several types according to >> their usage. >> >> For example >> A type has attributes: ChlUrl, SupportedCharsets, ServerID >> B type has attributes: InClientPull >> C type has attributes: ChlUrl, SMRCustomerType, GMDChargingCurrency, >> SupportedCharsets, ServerID >> >> <form name="A" type="single" >> target="createProtocolAttribute?protocolid=${id}"> >> <field name="ChlUrl"><text/></field> >> <field name="SupportedCharsets"><text/></field> >> <field name="ServerID"><text/></field> >> <field name="submitButton" title="Add Protocol"> >> <submit button-type="button"/> >> </field> >> </form> >> <form name="B" type="single" >> target="createProtocolAttribute?protocolid=${id}"> >> <field name="InClientPull"><text/></field> >> <field name="submitButton" title="Add Protocol"> >> <submit button-type="button"/> >> </field> >> </form> >> <form name="C" type="single" >> target="createProtocolAttribute?protocolid=${id}"> >> <field name="ChlUrl"><text/></field> >> <field name="SMRCustomerType"><text/></field> >> <field name="GMDChargingCurrency"><text/></field> >> <field name="SupportedCharsets"><text/></field> >> <field name="ServerID"><text/></field> >> <field name="submitButton" title="Add Protocol"> >> <submit button-type="button"/> >> </field> >> </form> >> >> When setting up a protocol in a web page, first choose a type from >> drop-down list, the web page show attributes relating to its type. >> After filling in the attributes' value, submit the form and save all >> these attribute-value pairs in the table protocolAttribute below. >> >> services.xml >> <service name=" createProtocolAttribute " engine="java" >> location="com.xian.cmb.CmbServices" invoke="createProtocolAttribute"> >> <attribute name="ChlUrl" mode="IN" type="String" >> optional="true" /> >> <attribute name="SupportedCharsets" mode="IN" >> type="String" optional="true" /> >> <attribute name="ServerID" mode="IN" type="String" >> optional="true" /> >> <attribute name="InClientPull" mode="IN" type="String" >> optional="true" /> >> <attribute name="SMRCustomerType" mode="IN" >> type="String" optional="true" /> >> <attribute name="GMDChargingCurrency" mode="IN" >> type="String" optional="true" /> >> </service> >> >> >> Tables: >> protocol: protocolid, protocolName. >> protocolAttribute: id, protocolid, attribute, value. >> >> >> With the progress of technology, the number of every protocol's >> attributes is increasing. >> So we need to modify the forms in the screens to add new fields and >> services.xml file to add mode IN attributes, and java code to save >> newly >> added attribute-value pairs. >> Can OFBiz have solutions to deal with the CHANGE and When adding an >> attribute, we needn't modify the form, services.xml and java source >> code? >> >> >> >> >> Best Regards, >> >> Jack Liu >> > > > Version: GnuPG v1.4.6 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJmjM3rP3NbaWWqE4RAnAoAJ0aTQS1FpqEozW+Dp2LWziwJKp5NwCcCQn1 RW2dV4sNkKK1bajuR5a/m6c= =GWNB -----END PGP SIGNATURE----- |
In reply to this post by Jack Liu-2
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1 A table in a database is an entity in entity form you would have 4 fields <entity entity-name="protocolAttribute" field name="id" type="id-ne"></field> <field name="protocolid" type="id"></field> <field name="attribute" type="long-varchar"></field> <field name="value" type="long-varchar"></field> <prim-key field="protocolid"/> </entity> your attribute would be enumerations BTW you can do an export of entities and it will build the Entity from the table you put in. Jack Liu sent the following on 2/16/2009 6:03 PM: > In the table protocolAttribute, records show below > id, protocolid, attribute, value > 1 1 ChlUrl 192.168.77.22/abc > 2 1 ServerID DWAI > 3 2 ChlUrl 192.168.77.22/abc > 4 2 SupportedCharsets gbk,UTF8 > > > -----Original Message----- > From: Jack Liu [mailto:[hidden email]] > Sent: 2009年2月17日 9:55 > To: [hidden email] > Subject: RE: Tricky! About fields in the form > > Maybe I didn't make myself clear. > We know, if we add a field in the entity, it will show up in the service and the form automatically. > But in my projects, we add NOT a field in the entity, but a VALUE. >>From the view of database, we just add a record in the table, not a field. > > It's totally different. > > -----Original Message----- > From: David E Jones [mailto:[hidden email]] > Sent: 2009年2月17日 9:39 > To: [hidden email] > Subject: Re: Tricky! About fields in the form > > > Yes. Look at the entities, services, and forms in the Example > application (and in fact most in OFBiz). > > The pattern we usually use is that services are derived from entities > (both defs and implementation), and forms (ie form fields) are derived > from services. So, if you add a field to the entity it will show up in > the service and the form. > > If you haven't already, you should check out the framework > introduction videos, which explain this and other patterns: > > http://docs.ofbiz.org/display/OFBTECH/Framework+Introduction+Videos+and+Diagrams > > -David > > > On Feb 16, 2009, at 6:29 PM, Jack Liu wrote: > >> Hi, All >> In my project, there are many protocols to set up. >> For every protocol, it has many attributes. >> All these protocols have been divided into several types according to >> their usage. >> >> For example >> A type has attributes: ChlUrl, SupportedCharsets, ServerID >> B type has attributes: InClientPull >> C type has attributes: ChlUrl, SMRCustomerType, GMDChargingCurrency, >> SupportedCharsets, ServerID >> >> <form name="A" type="single" >> target="createProtocolAttribute?protocolid=${id}"> >> <field name="ChlUrl"><text/></field> >> <field name="SupportedCharsets"><text/></field> >> <field name="ServerID"><text/></field> >> <field name="submitButton" title="Add Protocol"> >> <submit button-type="button"/> >> </field> >> </form> >> <form name="B" type="single" >> target="createProtocolAttribute?protocolid=${id}"> >> <field name="InClientPull"><text/></field> >> <field name="submitButton" title="Add Protocol"> >> <submit button-type="button"/> >> </field> >> </form> >> <form name="C" type="single" >> target="createProtocolAttribute?protocolid=${id}"> >> <field name="ChlUrl"><text/></field> >> <field name="SMRCustomerType"><text/></field> >> <field name="GMDChargingCurrency"><text/></field> >> <field name="SupportedCharsets"><text/></field> >> <field name="ServerID"><text/></field> >> <field name="submitButton" title="Add Protocol"> >> <submit button-type="button"/> >> </field> >> </form> >> >> When setting up a protocol in a web page, first choose a type from >> drop-down list, the web page show attributes relating to its type. >> After filling in the attributes' value, submit the form and save all >> these attribute-value pairs in the table protocolAttribute below. >> >> services.xml >> <service name=" createProtocolAttribute " engine="java" >> location="com.xian.cmb.CmbServices" invoke="createProtocolAttribute"> >> <attribute name="ChlUrl" mode="IN" type="String" >> optional="true" /> >> <attribute name="SupportedCharsets" mode="IN" >> type="String" optional="true" /> >> <attribute name="ServerID" mode="IN" type="String" >> optional="true" /> >> <attribute name="InClientPull" mode="IN" type="String" >> optional="true" /> >> <attribute name="SMRCustomerType" mode="IN" >> type="String" optional="true" /> >> <attribute name="GMDChargingCurrency" mode="IN" >> type="String" optional="true" /> >> </service> >> >> >> Tables: >> protocol: protocolid, protocolName. >> protocolAttribute: id, protocolid, attribute, value. >> >> >> With the progress of technology, the number of every protocol's >> attributes is increasing. >> So we need to modify the forms in the screens to add new fields and >> services.xml file to add mode IN attributes, and java code to save >> newly >> added attribute-value pairs. >> Can OFBiz have solutions to deal with the CHANGE and When adding an >> attribute, we needn't modify the form, services.xml and java source >> code? >> >> >> >> >> Best Regards, >> >> Jack Liu >> > > > Version: GnuPG v1.4.6 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJmkZFrP3NbaWWqE4RAqrzAJ9I1cV5BZpA2vnOfIAma5k73F0llgCfYke2 BAUh33LWm53UtGpk0LVjiRs= =tOki -----END PGP SIGNATURE----- |
Why would my attribute be enumerations?
You mean attribute references an enumeration below? <entity entity-name="protocolAttribute" <field name="id" type="id-ne"></field> <field name="protocolid" type="id"></field> <field name="attribute" type="long-varchar"></field> <field name="value" type="long-varchar"></field> <prim-key field="protocolid"/> <relation type="one" fk-name="ATTRIBUTE_ENUM" rel-entity-name="Enumeration"> <key-map field-name="attribute" rel-field-name="enumId"/> </relation> </entity> If a field is from an enumeration, in the page it will show a drop-down list. It's now what I want. What I want shows like below: <form name="A" type="single" target="createProtocolAttribute?protocolid=${id}"> <field name="ChlUrl"><text/></field> <field name="SupportedCharsets"><text/></field> <field name="ServerID"><text/></field> <field name="submitButton" title="Add Protocol"> <submit button-type="button"/> </field> </form> -----Original Message----- From: BJ Freeman [mailto:[hidden email]] Sent: 2009年2月17日 13:08 To: [hidden email] Subject: Re: Tricky! About fields in the form -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 A table in a database is an entity in entity form you would have 4 fields <entity entity-name="protocolAttribute" field name="id" type="id-ne"></field> <field name="protocolid" type="id"></field> <field name="attribute" type="long-varchar"></field> <field name="value" type="long-varchar"></field> <prim-key field="protocolid"/> </entity> your attribute would be enumerations BTW you can do an export of entities and it will build the Entity from the table you put in. Jack Liu sent the following on 2/16/2009 6:03 PM: > In the table protocolAttribute, records show below > id, protocolid, attribute, value > 1 1 ChlUrl 192.168.77.22/abc > 2 1 ServerID DWAI > 3 2 ChlUrl 192.168.77.22/abc > 4 2 SupportedCharsets gbk,UTF8 > > > -----Original Message----- > From: Jack Liu [mailto:[hidden email]] > Sent: 2009年2月17日 9:55 > To: [hidden email] > Subject: RE: Tricky! About fields in the form > > Maybe I didn't make myself clear. > We know, if we add a field in the entity, it will show up in the service and the form automatically. > But in my projects, we add NOT a field in the entity, but a VALUE. >>From the view of database, we just add a record in the table, not a field. > > It's totally different. > > -----Original Message----- > From: David E Jones [mailto:[hidden email]] > Sent: 2009年2月17日 9:39 > To: [hidden email] > Subject: Re: Tricky! About fields in the form > > > Yes. Look at the entities, services, and forms in the Example > application (and in fact most in OFBiz). > > The pattern we usually use is that services are derived from entities > (both defs and implementation), and forms (ie form fields) are derived > from services. So, if you add a field to the entity it will show up in > the service and the form. > > If you haven't already, you should check out the framework > introduction videos, which explain this and other patterns: > > http://docs.ofbiz.org/display/OFBTECH/Framework+Introduction+Videos+and+Diagrams > > -David > > > On Feb 16, 2009, at 6:29 PM, Jack Liu wrote: > >> Hi, All >> In my project, there are many protocols to set up. >> For every protocol, it has many attributes. >> All these protocols have been divided into several types according to >> their usage. >> >> For example >> A type has attributes: ChlUrl, SupportedCharsets, ServerID >> B type has attributes: InClientPull >> C type has attributes: ChlUrl, SMRCustomerType, GMDChargingCurrency, >> SupportedCharsets, ServerID >> >> <form name="A" type="single" >> target="createProtocolAttribute?protocolid=${id}"> >> <field name="ChlUrl"><text/></field> >> <field name="SupportedCharsets"><text/></field> >> <field name="ServerID"><text/></field> >> <field name="submitButton" title="Add Protocol"> >> <submit button-type="button"/> >> </field> >> </form> >> <form name="B" type="single" >> target="createProtocolAttribute?protocolid=${id}"> >> <field name="InClientPull"><text/></field> >> <field name="submitButton" title="Add Protocol"> >> <submit button-type="button"/> >> </field> >> </form> >> <form name="C" type="single" >> target="createProtocolAttribute?protocolid=${id}"> >> <field name="ChlUrl"><text/></field> >> <field name="SMRCustomerType"><text/></field> >> <field name="GMDChargingCurrency"><text/></field> >> <field name="SupportedCharsets"><text/></field> >> <field name="ServerID"><text/></field> >> <field name="submitButton" title="Add Protocol"> >> <submit button-type="button"/> >> </field> >> </form> >> >> When setting up a protocol in a web page, first choose a type from >> drop-down list, the web page show attributes relating to its type. >> After filling in the attributes' value, submit the form and save all >> these attribute-value pairs in the table protocolAttribute below. >> >> services.xml >> <service name=" createProtocolAttribute " engine="java" >> location="com.xian.cmb.CmbServices" invoke="createProtocolAttribute"> >> <attribute name="ChlUrl" mode="IN" type="String" >> optional="true" /> >> <attribute name="SupportedCharsets" mode="IN" >> type="String" optional="true" /> >> <attribute name="ServerID" mode="IN" type="String" >> optional="true" /> >> <attribute name="InClientPull" mode="IN" type="String" >> optional="true" /> >> <attribute name="SMRCustomerType" mode="IN" >> type="String" optional="true" /> >> <attribute name="GMDChargingCurrency" mode="IN" >> type="String" optional="true" /> >> </service> >> >> >> Tables: >> protocol: protocolid, protocolName. >> protocolAttribute: id, protocolid, attribute, value. >> >> >> With the progress of technology, the number of every protocol's >> attributes is increasing. >> So we need to modify the forms in the screens to add new fields and >> services.xml file to add mode IN attributes, and java code to save >> newly >> added attribute-value pairs. >> Can OFBiz have solutions to deal with the CHANGE and When adding an >> attribute, we needn't modify the form, services.xml and java source >> code? >> >> >> >> >> Best Regards, >> >> Jack Liu >> > > > Version: GnuPG v1.4.6 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJmkZFrP3NbaWWqE4RAqrzAJ9I1cV5BZpA2vnOfIAma5k73F0llgCfYke2 BAUh33LWm53UtGpk0LVjiRs= =tOki -----END PGP SIGNATURE----- |
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1 find a page that has a drop down and look at the code. preferably widget. also look up views that use the org.ofbiz.common.enum entity there are examples in code. My comments are how ofbiz sees things. it takes a while for a datbase centric person to see things the way ofbiz does it. I speak from experience. If you step back and let go of the Table Columnnames, it helps. Jack Liu sent the following on 2/16/2009 9:36 PM: > Why would my attribute be enumerations? > You mean attribute references an enumeration below? > > <entity entity-name="protocolAttribute" > <field name="id" type="id-ne"></field> > <field name="protocolid" type="id"></field> > <field name="attribute" type="long-varchar"></field> > <field name="value" type="long-varchar"></field> > <prim-key field="protocolid"/> > <relation type="one" fk-name="ATTRIBUTE_ENUM" rel-entity-name="Enumeration"> > <key-map field-name="attribute" rel-field-name="enumId"/> > </relation> > </entity> > > If a field is from an enumeration, in the page it will show a drop-down list. > It's now what I want. What I want shows like below: > > <form name="A" type="single" > target="createProtocolAttribute?protocolid=${id}"> > <field name="ChlUrl"><text/></field> > <field name="SupportedCharsets"><text/></field> > <field name="ServerID"><text/></field> > <field name="submitButton" title="Add Protocol"> > <submit button-type="button"/> > </field> > </form> > > -----Original Message----- > From: BJ Freeman [mailto:[hidden email]] > Sent: 2009年2月17日 13:08 > To: [hidden email] > Subject: Re: Tricky! About fields in the form > > A table in a database is an entity > in entity form you would have 4 fields > <entity entity-name="protocolAttribute" > field name="id" type="id-ne"></field> > <field name="protocolid" type="id"></field> > <field name="attribute" type="long-varchar"></field> > <field name="value" type="long-varchar"></field> > <prim-key field="protocolid"/> > </entity> > your attribute would be enumerations > > BTW you can do an export of entities and it will build the Entity from > the table you put in. > > > Jack Liu sent the following on 2/16/2009 6:03 PM: >> In the table protocolAttribute, records show below >> id, protocolid, attribute, value >> 1 1 ChlUrl 192.168.77.22/abc >> 2 1 ServerID DWAI >> 3 2 ChlUrl 192.168.77.22/abc >> 4 2 SupportedCharsets gbk,UTF8 > > >> -----Original Message----- >> From: Jack Liu [mailto:[hidden email]] >> Sent: 2009t217 Version: GnuPG v1.4.6 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJmrLLrP3NbaWWqE4RApBBAJ4874sQawsLHj4UAR0o2gXJ9LioNwCfVbfb 779UzmDOBgw4oKsAKc9p0S4= =oFaO -----END PGP SIGNATURE----- |
Could you give me an example in OFBiz?
I think it's very easy for you to find an example? -----Original Message----- From: BJ Freeman [mailto:[hidden email]] Sent: 2009年2月17日 20:51 To: [hidden email] Subject: Re: Tricky! About fields in the form -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 find a page that has a drop down and look at the code. preferably widget. also look up views that use the org.ofbiz.common.enum entity there are examples in code. My comments are how ofbiz sees things. it takes a while for a datbase centric person to see things the way ofbiz does it. I speak from experience. If you step back and let go of the Table Columnnames, it helps. Jack Liu sent the following on 2/16/2009 9:36 PM: > Why would my attribute be enumerations? > You mean attribute references an enumeration below? > > <entity entity-name="protocolAttribute" > <field name="id" type="id-ne"></field> > <field name="protocolid" type="id"></field> > <field name="attribute" type="long-varchar"></field> > <field name="value" type="long-varchar"></field> > <prim-key field="protocolid"/> > <relation type="one" fk-name="ATTRIBUTE_ENUM" rel-entity-name="Enumeration"> > <key-map field-name="attribute" rel-field-name="enumId"/> > </relation> > </entity> > > If a field is from an enumeration, in the page it will show a drop-down list. > It's now what I want. What I want shows like below: > > <form name="A" type="single" > target="createProtocolAttribute?protocolid=${id}"> > <field name="ChlUrl"><text/></field> > <field name="SupportedCharsets"><text/></field> > <field name="ServerID"><text/></field> > <field name="submitButton" title="Add Protocol"> > <submit button-type="button"/> > </field> > </form> > > -----Original Message----- > From: BJ Freeman [mailto:[hidden email]] > Sent: 2009年2月17日 13:08 > To: [hidden email] > Subject: Re: Tricky! About fields in the form > > A table in a database is an entity > in entity form you would have 4 fields > <entity entity-name="protocolAttribute" > field name="id" type="id-ne"></field> > <field name="protocolid" type="id"></field> > <field name="attribute" type="long-varchar"></field> > <field name="value" type="long-varchar"></field> > <prim-key field="protocolid"/> > </entity> > your attribute would be enumerations > > BTW you can do an export of entities and it will build the Entity from > the table you put in. > > > Jack Liu sent the following on 2/16/2009 6:03 PM: >> In the table protocolAttribute, records show below >> id, protocolid, attribute, value >> 1 1 ChlUrl 192.168.77.22/abc >> 2 1 ServerID DWAI >> 3 2 ChlUrl 192.168.77.22/abc >> 4 2 SupportedCharsets gbk,UTF8 > > >> -----Original Message----- >> From: Jack Liu [mailto:[hidden email]] >> Sent: 2009t217 Version: GnuPG v1.4.6 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJmrLLrP3NbaWWqE4RApBBAJ4874sQawsLHj4UAR0o2gXJ9LioNwCfVbfb 779UzmDOBgw4oKsAKc9p0S4= =oFaO -----END PGP SIGNATURE----- |
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1 On the list I point people to places they can learn. however if you want personal help I will be glad to consult with you for a fee. Jack Liu sent the following on 2/17/2009 5:13 AM: > Could you give me an example in OFBiz? > I think it's very easy for you to find an example? > > > -----Original Message----- > From: BJ Freeman [mailto:[hidden email]] > Sent: 2009年2月17日 20:51 > To: [hidden email] > Subject: Re: Tricky! About fields in the form > > find a page that has a drop down and look at the code. > preferably widget. > also look up views that use the org.ofbiz.common.enum entity > there are examples in code. > My comments are how ofbiz sees things. > it takes a while for a datbase centric person to see things the way > ofbiz does it. I speak from experience. > If you step back and let go of the Table Columnnames, it helps. > > > > Jack Liu sent the following on 2/16/2009 9:36 PM: >> Why would my attribute be enumerations? >> You mean attribute references an enumeration below? > >> <entity entity-name="protocolAttribute" >> <field name="id" type="id-ne"></field> >> <field name="protocolid" type="id"></field> >> <field name="attribute" type="long-varchar"></field> >> <field name="value" type="long-varchar"></field> >> <prim-key field="protocolid"/> >> <relation type="one" fk-name="ATTRIBUTE_ENUM" rel-entity-name="Enumeration"> >> <key-map field-name="attribute" rel-field-name="enumId"/> >> </relation> >> </entity> > >> If a field is from an enumeration, in the page it will show a drop-down list. >> It's now what I want. What I want shows like below: > >> <form name="A" type="single" >> target="createProtocolAttribute?protocolid=${id}"> >> <field name="ChlUrl"><text/></field> >> <field name="SupportedCharsets"><text/></field> >> <field name="ServerID"><text/></field> >> <field name="submitButton" title="Add Protocol"> >> <submit button-type="button"/> >> </field> >> </form> > >> -----Original Message----- >> From: BJ Freeman [mailto:[hidden email]] >> Sent: 2009t217 Version: GnuPG v1.4.6 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJmrlprP3NbaWWqE4RApi9AKCMLp29GUOlHpReAiEI6pON3Z0RfACgkdMg q1tPBF8EF5l1wOaQdz0fRY4= =OcS9 -----END PGP SIGNATURE----- |
Are you sure what I want and you have a good solution?
Again: What I want is not drop-down list In table attributetype: Id attribute type 1 ChUrl A 2 SupportedCharsets A 3 ServerID A 4 ServerID B While in form, we can get all the attributes of type A. <form name="xxxxxx" type="single" target="createProtocolAttribute?protocolid=${id}"> <field name="ChlUrl"><text/></field> <field name="SupportedCharsets"><text/></field> <field name="ServerID"><text/></field> <field name="submitButton" title="Add Protocol"> <submit button-type="button"/> </field> </form> Three fields ChlUrl, SupportedCharsets, ServerID are all fetched from table, not written by hand. Of course, the form maybe looks different, but can reach the same effect as above. Are you sure you can do it? If you can do it, money is not a problem, I think. -----Original Message----- From: BJ Freeman [mailto:[hidden email]] Sent: 2009年2月17日 21:20 To: [hidden email] Subject: Re: Tricky! About fields in the form -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On the list I point people to places they can learn. however if you want personal help I will be glad to consult with you for a fee. Jack Liu sent the following on 2/17/2009 5:13 AM: > Could you give me an example in OFBiz? > I think it's very easy for you to find an example? > > > -----Original Message----- > From: BJ Freeman [mailto:[hidden email]] > Sent: 2009年2月17日 20:51 > To: [hidden email] > Subject: Re: Tricky! About fields in the form > > find a page that has a drop down and look at the code. > preferably widget. > also look up views that use the org.ofbiz.common.enum entity > there are examples in code. > My comments are how ofbiz sees things. > it takes a while for a datbase centric person to see things the way > ofbiz does it. I speak from experience. > If you step back and let go of the Table Columnnames, it helps. > > > > Jack Liu sent the following on 2/16/2009 9:36 PM: >> Why would my attribute be enumerations? >> You mean attribute references an enumeration below? > >> <entity entity-name="protocolAttribute" >> <field name="id" type="id-ne"></field> >> <field name="protocolid" type="id"></field> >> <field name="attribute" type="long-varchar"></field> >> <field name="value" type="long-varchar"></field> >> <prim-key field="protocolid"/> >> <relation type="one" fk-name="ATTRIBUTE_ENUM" rel-entity-name="Enumeration"> >> <key-map field-name="attribute" rel-field-name="enumId"/> >> </relation> >> </entity> > >> If a field is from an enumeration, in the page it will show a drop-down list. >> It's now what I want. What I want shows like below: > >> <form name="A" type="single" >> target="createProtocolAttribute?protocolid=${id}"> >> <field name="ChlUrl"><text/></field> >> <field name="SupportedCharsets"><text/></field> >> <field name="ServerID"><text/></field> >> <field name="submitButton" title="Add Protocol"> >> <submit button-type="button"/> >> </field> >> </form> > >> -----Original Message----- >> From: BJ Freeman [mailto:[hidden email]] >> Sent: 2009t217 Version: GnuPG v1.4.6 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJmrlprP3NbaWWqE4RApi9AKCMLp29GUOlHpReAiEI6pON3Z0RfACgkdMg q1tPBF8EF5l1wOaQdz0fRY4= =OcS9 -----END PGP SIGNATURE----- |
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1 field types are gotten from the framework\entity\fieldtype folder for your specific db. look at the Type for how to define in ofbiz like type="short-varchar" there is no text type. if the db is connected to ofbiz now, and an entity is defined you can use the web tools to see what would be pulled from the table go to https://localhost:8443/webtools/control/entitymaint find your entity protocolAttribute click on Fnd you can put an "A" in the "type" field and see what comes up. you can do this with the other entities to see the results. the code that does this is part of the code you will need but written differently. The rest of the form is how you want it laid out. Please contact me directly. I can only respond to mailing list concern here. Jack Liu sent the following on 2/17/2009 5:46 AM: > Are you sure what I want and you have a good solution? > Again: > What I want is not drop-down list > > In table attributetype: > Id attribute type > 1 ChUrl A > 2 SupportedCharsets A > 3 ServerID A > 4 ServerID B > > > While in form, we can get all the attributes of type A. > > <form name="xxxxxx" type="single" > target="createProtocolAttribute?protocolid=${id}"> > <field name="ChlUrl"><text/></field> > <field name="SupportedCharsets"><text/></field> > <field name="ServerID"><text/></field> > <field name="submitButton" title="Add Protocol"> > <submit button-type="button"/> > </field> > </form> > > Three fields ChlUrl, SupportedCharsets, ServerID are all fetched from table, not written by hand. Of course, the form maybe looks different, but can reach the same effect as above. > > Are you sure you can do it? If you can do it, money is not a problem, I think. > > -----Original Message----- > From: BJ Freeman [mailto:[hidden email]] > Sent: 2009年2月17日 21:20 > To: [hidden email] > Subject: Re: Tricky! About fields in the form > > On the list I point people to places they can learn. > however if you want personal help I will be glad to consult with you for > a fee. > > Jack Liu sent the following on 2/17/2009 5:13 AM: >> Could you give me an example in OFBiz? >> I think it's very easy for you to find an example? > > >> -----Original Message----- >> From: BJ Freeman [mailto:[hidden email]] >> Sent: 2009t217 Version: GnuPG v1.4.6 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJmwAVrP3NbaWWqE4RAthZAJ9VaOPZYck0knKhkWonlTQVM/atVACgw9L9 kuK7hmiWYs0m6TtyH4tZLUw= =84jD -----END PGP SIGNATURE----- |
In reply to this post by Jack Liu-2
Jack, I suggested configuring these through entity fields instead of in the database because that is what is supported right now. If you want something that adds fields to a Form Widget form based on data in the database that would have to be written as it currently only feeds from the form definition XML files. That wouldn't be too hard to do (ie add functionality to add fields based on the database). We decided early on that we wanted these things configured from XML files instead of being more database driven (like Compiere and certain other frameworks are) because it is easier to revision control and manage in a large-scale environment (especially for updates and collaboration when multiple people are working on the applications). So yes, it could certainly be developed as an extension to the current Form Widget, but does not exist now. -David On Feb 17, 2009, at 6:46 AM, Jack Liu wrote: > Are you sure what I want and you have a good solution? > Again: > What I want is not drop-down list > > In table attributetype: > Id attribute type > 1 ChUrl A > 2 SupportedCharsets A > 3 ServerID A > 4 ServerID B > > > While in form, we can get all the attributes of type A. > > <form name="xxxxxx" type="single" > target="createProtocolAttribute?protocolid=${id}"> > <field name="ChlUrl"><text/></field> > <field name="SupportedCharsets"><text/></field> > <field name="ServerID"><text/></field> > <field name="submitButton" title="Add Protocol"> > <submit button-type="button"/> > </field> > </form> > > Three fields ChlUrl, SupportedCharsets, ServerID are all fetched > from table, not written by hand. Of course, the form maybe looks > different, but can reach the same effect as above. > > Are you sure you can do it? If you can do it, money is not a > problem, I think. > > -----Original Message----- > From: BJ Freeman [mailto:[hidden email]] > Sent: 2009年2月17日 21:20 > To: [hidden email] > Subject: Re: Tricky! About fields in the form > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On the list I point people to places they can learn. > however if you want personal help I will be glad to consult with you > for > a fee. > > Jack Liu sent the following on 2/17/2009 5:13 AM: >> Could you give me an example in OFBiz? >> I think it's very easy for you to find an example? >> >> >> -----Original Message----- >> From: BJ Freeman [mailto:[hidden email]] >> Sent: 2009年2月17日 20:51 >> To: [hidden email] >> Subject: Re: Tricky! About fields in the form >> >> find a page that has a drop down and look at the code. >> preferably widget. >> also look up views that use the org.ofbiz.common.enum entity >> there are examples in code. >> My comments are how ofbiz sees things. >> it takes a while for a datbase centric person to see things the way >> ofbiz does it. I speak from experience. >> If you step back and let go of the Table Columnnames, it helps. >> >> >> >> Jack Liu sent the following on 2/16/2009 9:36 PM: >>> Why would my attribute be enumerations? >>> You mean attribute references an enumeration below? >> >>> <entity entity-name="protocolAttribute" >>> <field name="id" type="id-ne"></field> >>> <field name="protocolid" type="id"></field> >>> <field name="attribute" type="long-varchar"></field> >>> <field name="value" type="long-varchar"></field> >>> <prim-key field="protocolid"/> >>> <relation type="one" fk-name="ATTRIBUTE_ENUM" rel-entity- >>> name="Enumeration"> >>> <key-map field-name="attribute" rel-field-name="enumId"/> >>> </relation> >>> </entity> >> >>> If a field is from an enumeration, in the page it will show a drop- >>> down list. >>> It's now what I want. What I want shows like below: >> >>> <form name="A" type="single" >>> target="createProtocolAttribute?protocolid=${id}"> >>> <field name="ChlUrl"><text/></field> >>> <field name="SupportedCharsets"><text/></field> >>> <field name="ServerID"><text/></field> >>> <field name="submitButton" title="Add Protocol"> >>> <submit button-type="button"/> >>> </field> >>> </form> >> >>> -----Original Message----- >>> From: BJ Freeman [mailto:[hidden email]] >>> Sent: 2009t217 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.6 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iD8DBQFJmrlprP3NbaWWqE4RApi9AKCMLp29GUOlHpReAiEI6pON3Z0RfACgkdMg > q1tPBF8EF5l1wOaQdz0fRY4= > =OcS9 > -----END PGP SIGNATURE----- |
If I want it through xml file, then how should I do?
The xml file maybe seems like this: <fields> <field attribute='ChUrl' type='A' /> <field attribute= SupportedCharsets' type='A' /> <field attribute=' ServerID' type='A' /> <field attribute='ServerID' type='B' /> </fields> While in form, we can get all the attributes of type A. <form name="xxxxxx" type="single" target="createProtocolAttribute?protocolid=${id}"> <field name="ChlUrl"><text/></field> <field name="SupportedCharsets"><text/></field> <field name="ServerID"><text/></field> <field name="submitButton" title="Add Protocol"> <submit button-type="button"/> </field> </form> -----Original Message----- From: David E Jones [mailto:[hidden email]] Sent: 2009年2月18日 2:28 To: [hidden email] Subject: Re: Tricky! About fields in the form Jack, I suggested configuring these through entity fields instead of in the database because that is what is supported right now. If you want something that adds fields to a Form Widget form based on data in the database that would have to be written as it currently only feeds from the form definition XML files. That wouldn't be too hard to do (ie add functionality to add fields based on the database). We decided early on that we wanted these things configured from XML files instead of being more database driven (like Compiere and certain other frameworks are) because it is easier to revision control and manage in a large-scale environment (especially for updates and collaboration when multiple people are working on the applications). So yes, it could certainly be developed as an extension to the current Form Widget, but does not exist now. -David On Feb 17, 2009, at 6:46 AM, Jack Liu wrote: > Are you sure what I want and you have a good solution? > Again: > What I want is not drop-down list > > In table attributetype: > Id attribute type > 1 ChUrl A > 2 SupportedCharsets A > 3 ServerID A > 4 ServerID B > > > While in form, we can get all the attributes of type A. > > <form name="xxxxxx" type="single" > target="createProtocolAttribute?protocolid=${id}"> > <field name="ChlUrl"><text/></field> > <field name="SupportedCharsets"><text/></field> > <field name="ServerID"><text/></field> > <field name="submitButton" title="Add Protocol"> > <submit button-type="button"/> > </field> > </form> > > Three fields ChlUrl, SupportedCharsets, ServerID are all fetched > from table, not written by hand. Of course, the form maybe looks > different, but can reach the same effect as above. > > Are you sure you can do it? If you can do it, money is not a > problem, I think. > > -----Original Message----- > From: BJ Freeman [mailto:[hidden email]] > Sent: 2009年2月17日 21:20 > To: [hidden email] > Subject: Re: Tricky! About fields in the form > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On the list I point people to places they can learn. > however if you want personal help I will be glad to consult with you > for > a fee. > > Jack Liu sent the following on 2/17/2009 5:13 AM: >> Could you give me an example in OFBiz? >> I think it's very easy for you to find an example? >> >> >> -----Original Message----- >> From: BJ Freeman [mailto:[hidden email]] >> Sent: 2009年2月17日 20:51 >> To: [hidden email] >> Subject: Re: Tricky! About fields in the form >> >> find a page that has a drop down and look at the code. >> preferably widget. >> also look up views that use the org.ofbiz.common.enum entity >> there are examples in code. >> My comments are how ofbiz sees things. >> it takes a while for a datbase centric person to see things the way >> ofbiz does it. I speak from experience. >> If you step back and let go of the Table Columnnames, it helps. >> >> >> >> Jack Liu sent the following on 2/16/2009 9:36 PM: >>> Why would my attribute be enumerations? >>> You mean attribute references an enumeration below? >> >>> <entity entity-name="protocolAttribute" >>> <field name="id" type="id-ne"></field> >>> <field name="protocolid" type="id"></field> >>> <field name="attribute" type="long-varchar"></field> >>> <field name="value" type="long-varchar"></field> >>> <prim-key field="protocolid"/> >>> <relation type="one" fk-name="ATTRIBUTE_ENUM" rel-entity- >>> name="Enumeration"> >>> <key-map field-name="attribute" rel-field-name="enumId"/> >>> </relation> >>> </entity> >> >>> If a field is from an enumeration, in the page it will show a drop- >>> down list. >>> It's now what I want. What I want shows like below: >> >>> <form name="A" type="single" >>> target="createProtocolAttribute?protocolid=${id}"> >>> <field name="ChlUrl"><text/></field> >>> <field name="SupportedCharsets"><text/></field> >>> <field name="ServerID"><text/></field> >>> <field name="submitButton" title="Add Protocol"> >>> <submit button-type="button"/> >>> </field> >>> </form> >> >>> -----Original Message----- >>> From: BJ Freeman [mailto:[hidden email]] >>> Sent: 2009t217 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.6 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iD8DBQFJmrlprP3NbaWWqE4RApi9AKCMLp29GUOlHpReAiEI6pON3Z0RfACgkdMg > q1tPBF8EF5l1wOaQdz0fRY4= > =OcS9 > -----END PGP SIGNATURE----- |
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1 how you define an entity is in framework\entity\dtd\entitymodel.xsd and is like I gave you an example previous. tables are entity names (well almost) and columns are field names. your attribute would be an Enumeration your type would be EnumerationType. you would use a view-entity to see all this in one row. using the webtool import you would 1) load the EnumerationType https://demo.hotwaxmedia.com/webtools/control/FindGeneric?entityName=EnumerationType&find=true&VIEW_SIZE=50&VIEW_INDEX=0 2) load the Enumeration with what you attributes https://demo.hotwaxmedia.com/webtools/control/FindGeneric?entityName=Enumeration&find=true&VIEW_SIZE=50&VIEW_INDEX=0 you can find data entity and form examples by doing a search on the application folders for Enumeration Jack Liu sent the following on 2/19/2009 2:24 AM: > If I want it through xml file, then how should I do? > > The xml file maybe seems like this: > <fields> > <field attribute='ChUrl' type='A' /> > <field attribute= SupportedCharsets' type='A' /> > <field attribute=' ServerID' type='A' /> > <field attribute='ServerID' type='B' /> > </fields> > > While in form, we can get all the attributes of type A. > > <form name="xxxxxx" type="single" > target="createProtocolAttribute?protocolid=${id}"> > <field name="ChlUrl"><text/></field> > <field name="SupportedCharsets"><text/></field> > <field name="ServerID"><text/></field> > <field name="submitButton" title="Add Protocol"> > <submit button-type="button"/> > </field> > </form> > > -----Original Message----- > From: David E Jones [mailto:[hidden email]] > Sent: 2009年2月18日 2:28 > To: [hidden email] > Subject: Re: Tricky! About fields in the form > > > Jack, > > I suggested configuring these through entity fields instead of in the > database because that is what is supported right now. > > If you want something that adds fields to a Form Widget form based on > data in the database that would have to be written as it currently > only feeds from the form definition XML files. That wouldn't be too > hard to do (ie add functionality to add fields based on the database). > We decided early on that we wanted these things configured from XML > files instead of being more database driven (like Compiere and certain > other frameworks are) because it is easier to revision control and > manage in a large-scale environment (especially for updates and > collaboration when multiple people are working on the applications). > > So yes, it could certainly be developed as an extension to the current > Form Widget, but does not exist now. > > -David > > > On Feb 17, 2009, at 6:46 AM, Jack Liu wrote: > >> Are you sure what I want and you have a good solution? >> Again: >> What I want is not drop-down list >> >> In table attributetype: >> Id attribute type >> 1 ChUrl A >> 2 SupportedCharsets A >> 3 ServerID A >> 4 ServerID B >> >> >> While in form, we can get all the attributes of type A. >> >> <form name="xxxxxx" type="single" >> target="createProtocolAttribute?protocolid=${id}"> >> <field name="ChlUrl"><text/></field> >> <field name="SupportedCharsets"><text/></field> >> <field name="ServerID"><text/></field> >> <field name="submitButton" title="Add Protocol"> >> <submit button-type="button"/> >> </field> >> </form> >> >> Three fields ChlUrl, SupportedCharsets, ServerID are all fetched >> from table, not written by hand. Of course, the form maybe looks >> different, but can reach the same effect as above. >> >> Are you sure you can do it? If you can do it, money is not a >> problem, I think. >> >> -----Original Message----- >> From: BJ Freeman [mailto:[hidden email]] >> Sent: 2009年2月17日 21:20 >> To: [hidden email] >> Subject: Re: Tricky! About fields in the form >> > On the list I point people to places they can learn. > however if you want personal help I will be glad to consult with you > for > a fee. > > Jack Liu sent the following on 2/17/2009 5:13 AM: >>>> Could you give me an example in OFBiz? >>>> I think it's very easy for you to find an example? >>>> >>>> >>>> -----Original Message----- >>>> From: BJ Freeman [mailto:[hidden email]] >>>> Sent: 2009t217 Version: GnuPG v1.4.6 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJnTyhrP3NbaWWqE4RAuyhAJ94+Qx/5PuzZGvlvaQfJciaxaVAxgCgir++ es56A7pXTtOEi+3kKidfxTw= =Heja -----END PGP SIGNATURE----- |
I know how to define an entity and an enumeration in OFBiz.
I also know how to use them in OFBiz: <field name="taxFormId"> <drop-down> <entity-options entity-name="Enumeration" description="${description}" key-field-name="enumId"> <entity-constraint name="enumTypeId" operator="equals" value="TAX_FORMS"/> <entity-order-by field-name="description"/> </entity-options> </drop-down> </field> <field name="orderSequenceEnumId" use-when="partyAcctgPreference!=null"><display-entity entity-name="Enumeration" key-field-name="enumId"/> </field> But what I want to do is not to view them. Exactly speaking, what I want to do is how to make these attributes turn into fields in the form automatically through OFBiz. Your examples just show how to view them. -----Original Message----- From: BJ Freeman [mailto:[hidden email]] Sent: 2009年2月19日 19:04 To: [hidden email] Subject: Re: Tricky! About fields in the form -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 how you define an entity is in framework\entity\dtd\entitymodel.xsd and is like I gave you an example previous. tables are entity names (well almost) and columns are field names. your attribute would be an Enumeration your type would be EnumerationType. you would use a view-entity to see all this in one row. using the webtool import you would 1) load the EnumerationType https://demo.hotwaxmedia.com/webtools/control/FindGeneric?entityName=EnumerationType&find=true&VIEW_SIZE=50&VIEW_INDEX=0 2) load the Enumeration with what you attributes https://demo.hotwaxmedia.com/webtools/control/FindGeneric?entityName=Enumeration&find=true&VIEW_SIZE=50&VIEW_INDEX=0 you can find data entity and form examples by doing a search on the application folders for Enumeration Jack Liu sent the following on 2/19/2009 2:24 AM: > If I want it through xml file, then how should I do? > > The xml file maybe seems like this: > <fields> > <field attribute='ChUrl' type='A' /> > <field attribute= SupportedCharsets' type='A' /> > <field attribute=' ServerID' type='A' /> > <field attribute='ServerID' type='B' /> > </fields> > > While in form, we can get all the attributes of type A. > > <form name="xxxxxx" type="single" > target="createProtocolAttribute?protocolid=${id}"> > <field name="ChlUrl"><text/></field> > <field name="SupportedCharsets"><text/></field> > <field name="ServerID"><text/></field> > <field name="submitButton" title="Add Protocol"> > <submit button-type="button"/> > </field> > </form> > > -----Original Message----- > From: David E Jones [mailto:[hidden email]] > Sent: 2009年2月18日 2:28 > To: [hidden email] > Subject: Re: Tricky! About fields in the form > > > Jack, > > I suggested configuring these through entity fields instead of in the > database because that is what is supported right now. > > If you want something that adds fields to a Form Widget form based on > data in the database that would have to be written as it currently > only feeds from the form definition XML files. That wouldn't be too > hard to do (ie add functionality to add fields based on the database). > We decided early on that we wanted these things configured from XML > files instead of being more database driven (like Compiere and certain > other frameworks are) because it is easier to revision control and > manage in a large-scale environment (especially for updates and > collaboration when multiple people are working on the applications). > > So yes, it could certainly be developed as an extension to the current > Form Widget, but does not exist now. > > -David > > > On Feb 17, 2009, at 6:46 AM, Jack Liu wrote: > >> Are you sure what I want and you have a good solution? >> Again: >> What I want is not drop-down list >> >> In table attributetype: >> Id attribute type >> 1 ChUrl A >> 2 SupportedCharsets A >> 3 ServerID A >> 4 ServerID B >> >> >> While in form, we can get all the attributes of type A. >> >> <form name="xxxxxx" type="single" >> target="createProtocolAttribute?protocolid=${id}"> >> <field name="ChlUrl"><text/></field> >> <field name="SupportedCharsets"><text/></field> >> <field name="ServerID"><text/></field> >> <field name="submitButton" title="Add Protocol"> >> <submit button-type="button"/> >> </field> >> </form> >> >> Three fields ChlUrl, SupportedCharsets, ServerID are all fetched >> from table, not written by hand. Of course, the form maybe looks >> different, but can reach the same effect as above. >> >> Are you sure you can do it? If you can do it, money is not a >> problem, I think. >> >> -----Original Message----- >> From: BJ Freeman [mailto:[hidden email]] >> Sent: 2009年2月17日 21:20 >> To: [hidden email] >> Subject: Re: Tricky! About fields in the form >> > On the list I point people to places they can learn. > however if you want personal help I will be glad to consult with you > for > a fee. > > Jack Liu sent the following on 2/17/2009 5:13 AM: >>>> Could you give me an example in OFBiz? >>>> I think it's very easy for you to find an example? >>>> >>>> >>>> -----Original Message----- >>>> From: BJ Freeman [mailto:[hidden email]] >>>> Sent: 2009t217 Version: GnuPG v1.4.6 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJnTyhrP3NbaWWqE4RAuyhAJ94+Qx/5PuzZGvlvaQfJciaxaVAxgCgir++ es56A7pXTtOEi+3kKidfxTw= =Heja -----END PGP SIGNATURE----- |
In reply to this post by Jack Liu-2
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1 this was your first post. this is what I have been trying to answer it seems ever-time I answer you change directions and or requirements. this does not show you understood ofbiz. at this point I bow out. Jack Liu sent the following on 2/16/2009 5:29 PM: > Hi, All > In my project, there are many protocols to set up. > For every protocol, it has many attributes. > All these protocols have been divided into several types according to > their usage. > > For example > A type has attributes: ChlUrl, SupportedCharsets, ServerID > B type has attributes: InClientPull > C type has attributes: ChlUrl, SMRCustomerType, GMDChargingCurrency, > SupportedCharsets, ServerID > > <form name="A" type="single" > target="createProtocolAttribute?protocolid=${id}"> > <field name="ChlUrl"><text/></field> > <field name="SupportedCharsets"><text/></field> > <field name="ServerID"><text/></field> > <field name="submitButton" title="Add Protocol"> > <submit button-type="button"/> > </field> > </form> > <form name="B" type="single" > target="createProtocolAttribute?protocolid=${id}"> > <field name="InClientPull"><text/></field> > <field name="submitButton" title="Add Protocol"> > <submit button-type="button"/> > </field> > </form> > <form name="C" type="single" > target="createProtocolAttribute?protocolid=${id}"> > <field name="ChlUrl"><text/></field> > <field name="SMRCustomerType"><text/></field> > <field name="GMDChargingCurrency"><text/></field> > <field name="SupportedCharsets"><text/></field> > <field name="ServerID"><text/></field> > <field name="submitButton" title="Add Protocol"> > <submit button-type="button"/> > </field> > </form> > > When setting up a protocol in a web page, first choose a type from > drop-down list, the web page show attributes relating to its type. > After filling in the attributes' value, submit the form and save all > these attribute-value pairs in the table protocolAttribute below. > > services.xml > <service name=" createProtocolAttribute " engine="java" > location="com.xian.cmb.CmbServices" invoke="createProtocolAttribute"> > <attribute name="ChlUrl" mode="IN" type="String" > optional="true" /> > <attribute name="SupportedCharsets" mode="IN" > type="String" optional="true" /> > <attribute name="ServerID" mode="IN" type="String" > optional="true" /> > <attribute name="InClientPull" mode="IN" type="String" > optional="true" /> > <attribute name="SMRCustomerType" mode="IN" > type="String" optional="true" /> > <attribute name="GMDChargingCurrency" mode="IN" > type="String" optional="true" /> > </service> > > > Tables: > protocol: protocolid, protocolName. > protocolAttribute: id, protocolid, attribute, value. > > > With the progress of technology, the number of every protocol's > attributes is increasing. > So we need to modify the forms in the screens to add new fields and > services.xml file to add mode IN attributes, and java code to save newly > added attribute-value pairs. > Can OFBiz have solutions to deal with the CHANGE and When adding an > attribute, we needn't modify the form, services.xml and java source > code? > > > > > Best Regards, > > Jack Liu > > Version: GnuPG v1.4.6 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJnj9DrP3NbaWWqE4RAr4FAKDDyVBSeyPZBilW5jLkd/UZ6BlzigCgg8ok w0oqq2j55zS4Fc8ftciYRB8= =no5+ -----END PGP SIGNATURE----- |
Free forum by Nabble | Edit this page |