Dev - About SupplierProduct and related entities

[Jacopo Cappellato]

Hi all,

I'm trying to improve the ui of the SupplierProduct entity in the
catalog manager and I've noticed that the entity is associated to the
following two entities:

SupplierPrefOrder: I guess this represents the order of preference for
the supplier (e.g. primary supplier, etc...)
SupplierRatingType: I guess (but not sure) this represents the type of
rating used to order the suppliers (e.g. QUALITY etc...)

However there are no seed data for these entities.

My first question is: since the two entities simply contain an id and a
description, why not using the Enumeration entity and remove the two?

Second question: should I add a column to the SupplierProduct list to
give the user the ability to sort the records by supplierPrefOrderId?
Shouldn't this be the default sort order (instead of the curent one that
is by partyId)?

Third question: since having both the list form and the add/update form
in that screen is causing a bug (after you update a record, the form is
filled with data and points to the updateSupplierProduct uri so that an
error is generated, "no record found", when the user changes the values
of one of the pk fields), can I move the add/update form to a separate
screen?

Thanks,

Jacopo
 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

[David E. Jones]

Jacopo Cappellato wrote:

> Hi all,
>
> I'm trying to improve the ui of the SupplierProduct entity in the
> catalog manager and I've noticed that the entity is associated to the
> following two entities:
>
> SupplierPrefOrder: I guess this represents the order of preference for
> the supplier (e.g. primary supplier, etc...)
> SupplierRatingType: I guess (but not sure) this represents the type of
> rating used to order the suppliers (e.g. QUALITY etc...)
>
> However there are no seed data for these entities.
>
> My first question is: since the two entities simply contain an id and a
> description, why not using the Enumeration entity and remove the two?

Having separate entities allows addition fields specific to this stuff to be added that couldn't (or at least shouldn't, not ever) be added to the Enumeration entity.

If these will mostly likely stay simple for a long time, they could certainly be changed to Enumeration. I'm not sure what would really be gained by it at this point...

> Second question: should I add a column to the SupplierProduct list to
> give the user the ability to sort the records by supplierPrefOrderId?
> Shouldn't this be the default sort order (instead of the curent one that
> is by partyId)?

I have no opinion on this one...

> Third question: since having both the list form and the add/update form
> in that screen is causing a bug (after you update a record, the form is
> filled with data and points to the updateSupplierProduct uri so that an
> error is generated, "no record found", when the user changes the values
> of one of the pk fields), can I move the add/update form to a separate
> screen?

That would just possibly introduce other problems. Better to find the cause of this problem and fix it. Actually, I don't really like this pattern of having the add form on a page also used for editing. It is confusing (especially since usually poorly done with no labels to tell the user what the heck they are doing), and as you've noticed error prone. It is possible to get it working properly, so either needs to be cleaned up or I guess moved to another screen, though that can be even more confusing to a user so just make sure things are labeled properly and such.

-David

 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

[Jacopo Cappellato]

Hi David,

David E. Jones wrote:
>
> ...
> That would just possibly introduce other problems. Better to find the cause of this problem and fix it. Actually, I don't really like this pattern of having the add form on a page also used for editing. It is confusing (especially since usually poorly done with no labels to tell the user what the heck they are doing), and as you've noticed error prone. It is possible to get it working properly, so either needs to be cleaned up or I guess moved to another screen, though that can be even more confusing to a user so just make sure things are labeled properly and such.
>

I think I've found the cause of the problem.
The following operation (called inside the action section of the
EditSupplierProduct screen):

<entity-one entity-name="SupplierProduct" value-name="supplierProduct"
auto-field-map="true"/>

doesn't retrieve the SupplierProduct record even if the full pk is passed:

productId
partyId
availableFromDate
currencyUomId
minimumOrderQuantity

The problem is the last field, minimumOrderQuantity, that is probably
treated as a string: if I exclude it the record is fetched.

I've tried to set something like this before the call:

<set field="availableFromDate" from-field="parameters.availableFromDate"/>

but without success.

Any hints?

Thanks,

Jacopo




> -David
>
>  
> _______________________________________________
> Dev mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/dev
>

 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

[Jacopo Cappellato]

Some more information about this:

minimumOrderQuantity is passed in this format: "500.0"

if I remove the decimal part to get this format: "500"

everything works fine.

?

Jacopo


Jacopo Cappellato wrote:

> Hi David,
>
> David E. Jones wrote:
>> ...
>> That would just possibly introduce other problems. Better to find the cause of this problem and fix it. Actually, I don't really like this pattern of having the add form on a page also used for editing. It is confusing (especially since usually poorly done with no labels to tell the user what the heck they are doing), and as you've noticed error prone. It is possible to get it working properly, so either needs to be cleaned up or I guess moved to another screen, though that can be even more confusing to a user so just make sure things are labeled properly and such.
>>
>
> I think I've found the cause of the problem.
> The following operation (called inside the action section of the
> EditSupplierProduct screen):
>
> <entity-one entity-name="SupplierProduct" value-name="supplierProduct"
> auto-field-map="true"/>
>
> doesn't retrieve the SupplierProduct record even if the full pk is passed:
>
> productId
> partyId
> availableFromDate
> currencyUomId
> minimumOrderQuantity
>
> The problem is the last field, minimumOrderQuantity, that is probably
> treated as a string: if I exclude it the record is fetched.
>
> I've tried to set something like this before the call:
>
> <set field="availableFromDate" from-field="parameters.availableFromDate"/>
>
> but without success.
>
> Any hints?
>
> Thanks,
>
> Jacopo
>
>
>
>
>> -David
>>
>>  
>> _______________________________________________
>> Dev mailing list
>> [hidden email]
>> http://lists.ofbiz.org/mailman/listinfo/dev
>>
>
>  
> _______________________________________________
> Dev mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/dev
>

 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

[David E. Jones]

Jacopo,

I just traced down into the code and it eventually takes the values coming in and passes them into the GenericEntity.setAllFields method. That method doesn't do any type conversion, so with all of these it is just passing a String back to the JDBC driver if that is what is coming in.

The set trick should work fine, just make sure to specify a type="Double" or whatever to force a type conversion.

We could change this to use the GenericEntity.setString method instead of the set method, and that would probably be best inside the setAllFields method.

Any thoughts/feedback on this from anyone?

-David


Jacopo Cappellato wrote:

> Some more information about this:
>
> minimumOrderQuantity is passed in this format: "500.0"
>
> if I remove the decimal part to get this format: "500"
>
> everything works fine.
>
> ?
>
> Jacopo
>
>
> Jacopo Cappellato wrote:
>> Hi David,
>>
>> David E. Jones wrote:
>>> ...
>>> That would just possibly introduce other problems. Better to find the cause of this problem and fix it. Actually, I don't really like this pattern of having the add form on a page also used for editing. It is confusing (especially since usually poorly done with no labels to tell the user what the heck they are doing), and as you've noticed error prone. It is possible to get it working properly, so either needs to be cleaned up or I guess moved to another screen, though that can be even more confusing to a user so just make sure things are labeled properly and such.
>>>
>> I think I've found the cause of the problem.
>> The following operation (called inside the action section of the
>> EditSupplierProduct screen):
>>
>> <entity-one entity-name="SupplierProduct" value-name="supplierProduct"
>> auto-field-map="true"/>
>>
>> doesn't retrieve the SupplierProduct record even if the full pk is passed:
>>
>> productId
>> partyId
>> availableFromDate
>> currencyUomId
>> minimumOrderQuantity
>>
>> The problem is the last field, minimumOrderQuantity, that is probably
>> treated as a string: if I exclude it the record is fetched.
>>
>> I've tried to set something like this before the call:
>>
>> <set field="availableFromDate" from-field="parameters.availableFromDate"/>
>>
>> but without success.
>>
>> Any hints?
>>
>> Thanks,
>>
>> Jacopo
>>
>>
>>
>>
>>> -David
>>>
>>>  
>>> _______________________________________________
>>> Dev mailing list
>>> [hidden email]
>>> http://lists.ofbiz.org/mailman/listinfo/dev
>>>
>>  
>> _______________________________________________
>> Dev mailing list
>> [hidden email]
>> http://lists.ofbiz.org/mailman/listinfo/dev
>>
>
>  
> _______________________________________________
> Dev mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/dev

 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

[Jacopo Cappellato]

David,

thanks for looking at this; I've tried to set the type to Double and to
Integer but without success:

<set field="minimumOrderQuantity"
from-field="parameters.minimumOrderQuantity" type="Double"/>

Am I missing something?

Jacopo

David E. Jones wrote:

> Jacopo,
>
> I just traced down into the code and it eventually takes the values coming in and passes them into the GenericEntity.setAllFields method. That method doesn't do any type conversion, so with all of these it is just passing a String back to the JDBC driver if that is what is coming in.
>
> The set trick should work fine, just make sure to specify a type="Double" or whatever to force a type conversion.
>
> We could change this to use the GenericEntity.setString method instead of the set method, and that would probably be best inside the setAllFields method.
>
> Any thoughts/feedback on this from anyone?
>
> -David
>
>
> Jacopo Cappellato wrote:
>> Some more information about this:
>>
>> minimumOrderQuantity is passed in this format: "500.0"
>>
>> if I remove the decimal part to get this format: "500"
>>
>> everything works fine.
>>
>> ?
>>
>> Jacopo
>>
>>
>> Jacopo Cappellato wrote:
>>> Hi David,
>>>
>>> David E. Jones wrote:
>>>> ...
>>>> That would just possibly introduce other problems. Better to find the cause of this problem and fix it. Actually, I don't really like this pattern of having the add form on a page also used for editing. It is confusing (especially since usually poorly done with no labels to tell the user what the heck they are doing), and as you've noticed error prone. It is possible to get it working properly, so either needs to be cleaned up or I guess moved to another screen, though that can be even more confusing to a user so just make sure things are labeled properly and such.
>>>>
>>> I think I've found the cause of the problem.
>>> The following operation (called inside the action section of the
>>> EditSupplierProduct screen):
>>>
>>> <entity-one entity-name="SupplierProduct" value-name="supplierProduct"
>>> auto-field-map="true"/>
>>>
>>> doesn't retrieve the SupplierProduct record even if the full pk is passed:
>>>
>>> productId
>>> partyId
>>> availableFromDate
>>> currencyUomId
>>> minimumOrderQuantity
>>>
>>> The problem is the last field, minimumOrderQuantity, that is probably
>>> treated as a string: if I exclude it the record is fetched.
>>>
>>> I've tried to set something like this before the call:
>>>
>>> <set field="availableFromDate" from-field="parameters.availableFromDate"/>
>>>
>>> but without success.
>>>
>>> Any hints?
>>>
>>> Thanks,
>>>
>>> Jacopo
>>>
>>>
>>>
>>>
>>>> -David
>>>>
>>>>  
>>>> _______________________________________________
>>>> Dev mailing list
>>>> [hidden email]
>>>> http://lists.ofbiz.org/mailman/listinfo/dev
>>>>
>>>  
>>> _______________________________________________
>>> Dev mailing list
>>> [hidden email]
>>> http://lists.ofbiz.org/mailman/listinfo/dev
>>>
>>  
>> _______________________________________________
>> Dev mailing list
>> [hidden email]
>> http://lists.ofbiz.org/mailman/listinfo/dev
>  
> _______________________________________________
> Dev mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/dev
>

 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

[Jacopo Cappellato]

David,

based on your feedback now I think I've found the cause of the problem:

I'm running OFBiz with user locale set to en_EN but my operating
system's locale is it_IT.
So the numbers are formatted according to the American formatting
conventions (500 is formatted as "500.0") but then the string is treaded
(when the user locale is not available) by the underlying processes
according to the system locale (it, where "500.0" is parsed as 5000).

Does it make sense?

Jacopo


Jacopo Cappellato wrote:

> David,
>
> thanks for looking at this; I've tried to set the type to Double and to
> Integer but without success:
>
> <set field="minimumOrderQuantity"
> from-field="parameters.minimumOrderQuantity" type="Double"/>
>
> Am I missing something?
>
> Jacopo
>
> David E. Jones wrote:
>> Jacopo,
>>
>> I just traced down into the code and it eventually takes the values coming in and passes them into the GenericEntity.setAllFields method. That method doesn't do any type conversion, so with all of these it is just passing a String back to the JDBC driver if that is what is coming in.
>>
>> The set trick should work fine, just make sure to specify a type="Double" or whatever to force a type conversion.
>>
>> We could change this to use the GenericEntity.setString method instead of the set method, and that would probably be best inside the setAllFields method.
>>
>> Any thoughts/feedback on this from anyone?
>>
>> -David
>>
>>
>> Jacopo Cappellato wrote:
>>> Some more information about this:
>>>
>>> minimumOrderQuantity is passed in this format: "500.0"
>>>
>>> if I remove the decimal part to get this format: "500"
>>>
>>> everything works fine.
>>>
>>> ?
>>>
>>> Jacopo
>>>
>>>
>>> Jacopo Cappellato wrote:
>>>> Hi David,
>>>>
>>>> David E. Jones wrote:
>>>>> ...
>>>>> That would just possibly introduce other problems. Better to find the cause of this problem and fix it. Actually, I don't really like this pattern of having the add form on a page also used for editing. It is confusing (especially since usually poorly done with no labels to tell the user what the heck they are doing), and as you've noticed error prone. It is possible to get it working properly, so either needs to be cleaned up or I guess moved to another screen, though that can be even more confusing to a user so just make sure things are labeled properly and such.
>>>>>
>>>> I think I've found the cause of the problem.
>>>> The following operation (called inside the action section of the
>>>> EditSupplierProduct screen):
>>>>
>>>> <entity-one entity-name="SupplierProduct" value-name="supplierProduct"
>>>> auto-field-map="true"/>
>>>>
>>>> doesn't retrieve the SupplierProduct record even if the full pk is passed:
>>>>
>>>> productId
>>>> partyId
>>>> availableFromDate
>>>> currencyUomId
>>>> minimumOrderQuantity
>>>>
>>>> The problem is the last field, minimumOrderQuantity, that is probably
>>>> treated as a string: if I exclude it the record is fetched.
>>>>
>>>> I've tried to set something like this before the call:
>>>>
>>>> <set field="availableFromDate" from-field="parameters.availableFromDate"/>
>>>>
>>>> but without success.
>>>>
>>>> Any hints?
>>>>
>>>> Thanks,
>>>>
>>>> Jacopo
>>>>
>>>>
>>>>
>>>>
>>>>> -David
>>>>>
>>>>>  
>>>>> _______________________________________________
>>>>> Dev mailing list
>>>>> [hidden email]
>>>>> http://lists.ofbiz.org/mailman/listinfo/dev
>>>>>
>>>>  
>>>> _______________________________________________
>>>> Dev mailing list
>>>> [hidden email]
>>>> http://lists.ofbiz.org/mailman/listinfo/dev
>>>>
>>>  
>>> _______________________________________________
>>> Dev mailing list
>>> [hidden email]
>>> http://lists.ofbiz.org/mailman/listinfo/dev
>>  
>> _______________________________________________
>> Dev mailing list
>> [hidden email]
>> http://lists.ofbiz.org/mailman/listinfo/dev
>>
>
>  
> _______________________________________________
> Dev mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/dev
>

 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

[David E. Jones]

When passing a String back to the JDBC driver you never know how they're going to treat it...

Of course, it only knows about the system locale and not the current user's locale. We could change the GenericEntity.setAllFields method to be locale aware and more intelligently convert types (possibly by extending the GenericEntity.setString method to be locale aware).

For the screen widget set action: I just checked it out and it wasn't using the context locale... So, I've changed that in rev 7780.

-David


Jacopo Cappellato wrote:

> David,
>
> based on your feedback now I think I've found the cause of the problem:
>
> I'm running OFBiz with user locale set to en_EN but my operating
> system's locale is it_IT.
> So the numbers are formatted according to the American formatting
> conventions (500 is formatted as "500.0") but then the string is treaded
> (when the user locale is not available) by the underlying processes
> according to the system locale (it, where "500.0" is parsed as 5000).
>
> Does it make sense?
>
> Jacopo
>
>
> Jacopo Cappellato wrote:
>> David,
>>
>> thanks for looking at this; I've tried to set the type to Double and to
>> Integer but without success:
>>
>> <set field="minimumOrderQuantity"
>> from-field="parameters.minimumOrderQuantity" type="Double"/>
>>
>> Am I missing something?
>>
>> Jacopo
>>
>> David E. Jones wrote:
>>> Jacopo,
>>>
>>> I just traced down into the code and it eventually takes the values coming in and passes them into the GenericEntity.setAllFields method. That method doesn't do any type conversion, so with all of these it is just passing a String back to the JDBC driver if that is what is coming in.
>>>
>>> The set trick should work fine, just make sure to specify a type="Double" or whatever to force a type conversion.
>>>
>>> We could change this to use the GenericEntity.setString method instead of the set method, and that would probably be best inside the setAllFields method.
>>>
>>> Any thoughts/feedback on this from anyone?
>>>
>>> -David
>>>
>>>
>>> Jacopo Cappellato wrote:
>>>> Some more information about this:
>>>>
>>>> minimumOrderQuantity is passed in this format: "500.0"
>>>>
>>>> if I remove the decimal part to get this format: "500"
>>>>
>>>> everything works fine.
>>>>
>>>> ?
>>>>
>>>> Jacopo
>>>>
>>>>
>>>> Jacopo Cappellato wrote:
>>>>> Hi David,
>>>>>
>>>>> David E. Jones wrote:
>>>>>> ...
>>>>>> That would just possibly introduce other problems. Better to find the cause of this problem and fix it. Actually, I don't really like this pattern of having the add form on a page also used for editing. It is confusing (especially since usually poorly done with no labels to tell the user what the heck they are doing), and as you've noticed error prone. It is possible to get it working properly, so either needs to be cleaned up or I guess moved to another screen, though that can be even more confusing to a user so just make sure things are labeled properly and such.
>>>>>>
>>>>> I think I've found the cause of the problem.
>>>>> The following operation (called inside the action section of the
>>>>> EditSupplierProduct screen):
>>>>>
>>>>> <entity-one entity-name="SupplierProduct" value-name="supplierProduct"
>>>>> auto-field-map="true"/>
>>>>>
>>>>> doesn't retrieve the SupplierProduct record even if the full pk is passed:
>>>>>
>>>>> productId
>>>>> partyId
>>>>> availableFromDate
>>>>> currencyUomId
>>>>> minimumOrderQuantity
>>>>>
>>>>> The problem is the last field, minimumOrderQuantity, that is probably
>>>>> treated as a string: if I exclude it the record is fetched.
>>>>>
>>>>> I've tried to set something like this before the call:
>>>>>
>>>>> <set field="availableFromDate" from-field="parameters.availableFromDate"/>
>>>>>
>>>>> but without success.
>>>>>
>>>>> Any hints?
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Jacopo
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> -David
>>>>>>
>>>>>>  
>>>>>> _______________________________________________
>>>>>> Dev mailing list
>>>>>> [hidden email]
>>>>>> http://lists.ofbiz.org/mailman/listinfo/dev
>>>>>>
>>>>>  
>>>>> _______________________________________________
>>>>> Dev mailing list
>>>>> [hidden email]
>>>>> http://lists.ofbiz.org/mailman/listinfo/dev
>>>>>
>>>>  
>>>> _______________________________________________
>>>> Dev mailing list
>>>> [hidden email]
>>>> http://lists.ofbiz.org/mailman/listinfo/dev
>>>  
>>> _______________________________________________
>>> Dev mailing list
>>> [hidden email]
>>> http://lists.ofbiz.org/mailman/listinfo/dev
>>>
>>  
>> _______________________________________________
>> Dev mailing list
>> [hidden email]
>> http://lists.ofbiz.org/mailman/listinfo/dev
>>
>
>  
> _______________________________________________
> Dev mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/dev

 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

[Jacopo Cappellato]

David,

thanks for your help, now I'm very close to the solution of this issue.
The last problem I'm facing is that it seems that the
"ListSupplierProducts" form doesn't consider the context locale when it
renders the 'edit' links.
I mean that the field definition:

<field name="updateLink" title="" widget-style="buttontext">
   <hyperlink
target="EditProductSuppliers?productId=${productId}&amp;partyId=${partyId}&amp;currencyUomId=${currencyUomId}&amp;minimumOrderQuantity=${minimumOrderQuantity}&amp;availableFromDate=${availableFromDate}"/>
</field>

always renders the ${minimumOrderQuantity} ignoring the context locale;
could you help me to fix this?

Thanks,

Jacopo

David E. Jones wrote:
> When passing a String back to the JDBC driver you never know how they're going to treat it...
>
> Of course, it only knows about the system locale and not the current user's locale. We could change the GenericEntity.setAllFields method to be locale aware and more intelligently convert types (possibly by extending the GenericEntity.setString method to be locale aware).
>
> For the screen widget set action: I just checked it out and it wasn't using the context locale... So, I've changed that in rev 7780.
>
> -David
>

 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

[David E. Jones]

Hmm... That's a bit of a different issue. Do we really want locale specific information in URLs? It kind of messes up passing them around between users and opens up other potential problems, especially since URL information in non  ASCII text is very unreliable (browsers, proxies, app servers, all sorts of things have problems with it).

We should probably just make sure it is generated in a specific format regardless of the locale, and one that the other side will parse just fine (without an explicit conversion using set being required).

Is the current SVN in a state where this can be tested?

-David


Jacopo Cappellato wrote:

> David,
>
> thanks for your help, now I'm very close to the solution of this issue.
> The last problem I'm facing is that it seems that the
> "ListSupplierProducts" form doesn't consider the context locale when it
> renders the 'edit' links.
> I mean that the field definition:
>
> <field name="updateLink" title="" widget-style="buttontext">
>    <hyperlink
> target="EditProductSuppliers?productId=${productId}&amp;partyId=${partyId}&amp;currencyUomId=${currencyUomId}&amp;minimumOrderQuantity=${minimumOrderQuantity}&amp;availableFromDate=${availableFromDate}"/>
> </field>
>
> always renders the ${minimumOrderQuantity} ignoring the context locale;
> could you help me to fix this?
>
> Thanks,
>
> Jacopo
>
> David E. Jones wrote:
>> When passing a String back to the JDBC driver you never know how they're going to treat it...
>>
>> Of course, it only knows about the system locale and not the current user's locale. We could change the GenericEntity.setAllFields method to be locale aware and more intelligently convert types (possibly by extending the GenericEntity.setString method to be locale aware).
>>
>> For the screen widget set action: I just checked it out and it wasn't using the context locale... So, I've changed that in rev 7780.
>>
>> -David
>>
>
>  
> _______________________________________________
> Dev mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/dev

 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

[Jacopo Cappellato]

David,

I perfectly understand your remarks.
Yes, you can easily test what I see:

1) switch the user's locale to "Italian" (for example)
2) go to the product's Supplier subscreen:

https://localhost:8443/catalog/control/EditProductSuppliers?productId=WG-1111

3) click on the "Update" link of the first record (BKWG-1111)

You'll notice that the SupplierProduct cannot be selected because the
url used is the following one:

https://localhost:8443/catalog/control/EditProductSuppliers?productId=WG-1111&partyId=BigSupplier&currencyUomId=USD&minimumOrderQuantity=500.0&availableFromDate=2005-01-01%2000:00:00.0

(notice the format of the minimumOrderQuantity parameter, 500.0)

If you manually change the  minimumOrderQuantity parameter from 500.0 to
500,0 the record will be selected.

If you switch back to English everything works fine.

Please, help me to find a solution... :-(

Jacopo


David E. Jones wrote:

> Hmm... That's a bit of a different issue. Do we really want locale specific information in URLs? It kind of messes up passing them around between users and opens up other potential problems, especially since URL information in non  ASCII text is very unreliable (browsers, proxies, app servers, all sorts of things have problems with it).
>
> We should probably just make sure it is generated in a specific format regardless of the locale, and one that the other side will parse just fine (without an explicit conversion using set being required).
>
> Is the current SVN in a state where this can be tested?
>
> -David
>
>
> Jacopo Cappellato wrote:
>> David,
>>
>> thanks for your help, now I'm very close to the solution of this issue.
>> The last problem I'm facing is that it seems that the
>> "ListSupplierProducts" form doesn't consider the context locale when it
>> renders the 'edit' links.
>> I mean that the field definition:
>>
>> <field name="updateLink" title="" widget-style="buttontext">
>>    <hyperlink
>> target="EditProductSuppliers?productId=${productId}&amp;partyId=${partyId}&amp;currencyUomId=${currencyUomId}&amp;minimumOrderQuantity=${minimumOrderQuantity}&amp;availableFromDate=${availableFromDate}"/>
>> </field>
>>
>> always renders the ${minimumOrderQuantity} ignoring the context locale;
>> could you help me to fix this?
>>
>> Thanks,
>>
>> Jacopo
>>
>> David E. Jones wrote:
>>> When passing a String back to the JDBC driver you never know how they're going to treat it...
>>>
>>> Of course, it only knows about the system locale and not the current user's locale. We could change the GenericEntity.setAllFields method to be locale aware and more intelligently convert types (possibly by extending the GenericEntity.setString method to be locale aware).
>>>
>>> For the screen widget set action: I just checked it out and it wasn't using the context locale... So, I've changed that in rev 7780.
>>>
>>> -David
>>>
>>  
>> _______________________________________________
>> Dev mailing list
>> [hidden email]
>> http://lists.ofbiz.org/mailman/listinfo/dev
>  
> _______________________________________________
> Dev mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/dev
>

 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev