OFBiz › OFBiz - User

Tricky! About fields in the form

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

25 messages Options

Jack Liu-2

Tricky! About fields in the form

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

David E Jones-3

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
>

Jack Liu-2

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:

Jack Liu-2

RE: Tricky! About fields in the form

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:

David E Jones-3

Re: Tricky! About fields in the form

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

Jack Liu-2

RE: Tricky! About fields in the form

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:

BJ Freeman

Re: Tricky! About fields in the form

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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFJmjM3rP3NbaWWqE4RAnAoAJ0aTQS1FpqEozW+Dp2LWziwJKp5NwCcCQn1
RW2dV4sNkKK1bajuR5a/m6c=
=GWNB
-----END PGP SIGNATURE-----

Jack Liu-2

RE: Tricky! About fields in the form

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:

BJ Freeman

Re: Tricky! About fields in the form

In reply to this post by Jack Liu-2

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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFJmkZFrP3NbaWWqE4RAqrzAJ9I1cV5BZpA2vnOfIAma5k73F0llgCfYke2
BAUh33LWm53UtGpk0LVjiRs=
=tOki
-----END PGP SIGNATURE-----

Jack Liu-2

RE: Tricky! About fields in the form

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:

BJ Freeman

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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFJmrLLrP3NbaWWqE4RApBBAJ4874sQawsLHj4UAR0o2gXJ9LioNwCfVbfb
779UzmDOBgw4oKsAKc9p0S4=
=oFaO
-----END PGP SIGNATURE-----

Jack Liu-2

RE: Tricky! About fields in the form

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:

BJ Freeman

Re: Tricky! About fields in the form

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

Jack Liu-2

RE: Tricky! About fields in the form

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:

BJ Freeman

Re: Tricky! About fields in the form

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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFJmwAVrP3NbaWWqE4RAthZAJ9VaOPZYck0knKhkWonlTQVM/atVACgw9L9
kuK7hmiWYs0m6TtyH4tZLUw=
=84jD
-----END PGP SIGNATURE-----

David E Jones-3

Re: Tricky! About fields in the form

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

Jack Liu-2

RE: Tricky! About fields in the form

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:

BJ Freeman

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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFJnTyhrP3NbaWWqE4RAuyhAJ94+Qx/5PuzZGvlvaQfJciaxaVAxgCgir++
es56A7pXTtOEi+3kKidfxTw=
=Heja
-----END PGP SIGNATURE-----

Jack Liu-2

RE: Tricky! About fields in the form

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:

BJ Freeman

Re: Tricky! About fields in the form

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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFJnj9DrP3NbaWWqE4RAr4FAKDDyVBSeyPZBilW5jLkd/UZ6BlzigCgg8ok
w0oqq2j55zS4Fc8ftciYRB8=
=no5+
-----END PGP SIGNATURE-----