Re: svn commit: r597000 - /ofbiz/trunk/applications/product/entitydef/entitymodel.xml

[Jacopo Cappellato]

David,

there was actually a reason for using the id type for the
customPriceCalcService field: the field should contain an id for the
CustomMethod entity and the actual service name should go there.
This is the pattern I've used for custom formulae in other places
(production run time/cost formulae), I'm not completely sure I
completely like it, but it has some pros: you can display a nice
description instead of the service name and you can create drop down
boxes (I think that we should adopt the same approach for the
store->payment gateway services).

What do you think?

Jacopo



[hidden email] wrote:

> Author: jonesde
> Date: Wed Nov 21 01:19:25 2007
> New Revision: 597000
>
> URL: http://svn.apache.org/viewvc?rev=597000&view=rev
> Log:
> Changed customPriceCalcService type from id to long-varchar to accommodate more common service names, didn't see any reason why this mmon service names, didn't see any reason why the field should be so short so shouldn't be any side effects to this change
>
> Modified:
>     ofbiz/trunk/applications/product/entitydef/entitymodel.xml
>
> Modified: ofbiz/trunk/applications/product/entitydef/entitymodel.xml
> URL: http://svn.apache.org/viewvc/ofbiz/trunk/applications/product/entitydef/entitymodel.xml?rev=597000&r1=596999&r2=597000&view=diff
> ==============================================================================
> --- ofbiz/trunk/applications/product/entitydef/entitymodel.xml (original)
> +++ ofbiz/trunk/applications/product/entitydef/entitymodel.xml Wed Nov 21 01:19:25 2007
> @@ -1724,8 +1724,8 @@
>        <field name="fromDate" type="date-time"></field>
>        <field name="thruDate" type="date-time"></field>
>        <field name="price" type="currency-precise"></field>
> -      <field name="termUomId" type="id"><description>mainly used for recurring and usage prices to specify a time/freq measure, or a usage unit measure (bits, minutes, etc)</description></field>
> -      <field name="customPriceCalcService" type="id"><description>used to specify an external service for the calculation of the unit price of the product</description></field>
> +      <field name="termUomId" type="id"><description>Mainly used for recurring and usage prices to specify a time/freq measure, or a usage unit measure (bits, minutes, etc)</description></field>
> +      <field name="customPriceCalcService" type="long-varchar"><description>Used to specify an external service for the calculation of the unit price of the product</description></field>
>        <field name="createdDate" type="date-time"></field>
>        <field name="createdByUserLogin" type="id-vlong"></field>
>        <field name="lastModifiedDate" type="date-time"></field>
>

[David E Jones]

Thanks for the heads up Jacopo. I've changed that back and added/
changed comments to clarify how this works and note the misleading  
field name.

As for the general pattern, it may come in useful at some point if we  
want to configure additional things related to these service calls or  
other methods. For the human description, why not just use the one on  
the service def itself?

-David


On Nov 21, 2007, at 2:44 AM, Jacopo Cappellato wrote:

> David,
>
> there was actually a reason for using the id type for the  
> customPriceCalcService field: the field should contain an id for the  
> CustomMethod entity and the actual service name should go there.
> This is the pattern I've used for custom formulae in other places  
> (production run time/cost formulae), I'm not completely sure I  
> completely like it, but it has some pros: you can display a nice  
> description instead of the service name and you can create drop down  
> boxes (I think that we should adopt the same approach for the store-
> >payment gateway services).
>
> What do you think?
>
> Jacopo
>
>
>
> [hidden email] wrote:
>> Author: jonesde
>> Date: Wed Nov 21 01:19:25 2007
>> New Revision: 597000
>> URL: http://svn.apache.org/viewvc?rev=597000&view=rev
>> Log:
>> Changed customPriceCalcService type from id to long-varchar to  
>> accommodate more common service names, didn't see any reason why  
>> this mmon service names, didn't see any reason why the field should  
>> be so short so shouldn't be any side effects to this change
>> Modified:
>>    ofbiz/trunk/applications/product/entitydef/entitymodel.xml
>> Modified: ofbiz/trunk/applications/product/entitydef/entitymodel.xml
>> URL: http://svn.apache.org/viewvc/ofbiz/trunk/applications/product/entitydef/entitymodel.xml?rev=597000&r1=596999&r2=597000&view=diff
>> =
>> =
>> =
>> =
>> =
>> =
>> =
>> =
>> =
>> =====================================================================
>> --- ofbiz/trunk/applications/product/entitydef/entitymodel.xml  
>> (original)
>> +++ ofbiz/trunk/applications/product/entitydef/entitymodel.xml Wed  
>> Nov 21 01:19:25 2007
>> @@ -1724,8 +1724,8 @@
>>       <field name="fromDate" type="date-time"></field>
>>       <field name="thruDate" type="date-time"></field>
>>       <field name="price" type="currency-precise"></field>
>> -      <field name="termUomId" type="id"><description>mainly used  
>> for recurring and usage prices to specify a time/freq measure, or a  
>> usage unit measure (bits, minutes, etc)</description></field>
>> -      <field name="customPriceCalcService"  
>> type="id"><description>used to specify an external service for the  
>> calculation of the unit price of the product</description></field>
>> +      <field name="termUomId" type="id"><description>Mainly used  
>> for recurring and usage prices to specify a time/freq measure, or a  
>> usage unit measure (bits, minutes, etc)</description></field>
>> +      <field name="customPriceCalcService" type="long-
>> varchar"><description>Used to specify an external service for the  
>> calculation of the unit price of the product</description></field>
>>       <field name="createdDate" type="date-time"></field>
>>       <field name="createdByUserLogin" type="id-vlong"></field>
>>       <field name="lastModifiedDate" type="date-time"></field>
>

[Jacopo Cappellato]

Thanks David,

the name is actually misleading.
About the description: yes, using the one of the service would be ideal,
but there are two aspects we should consider:

1) I don't know if there is an easy way to retrieve it in forms (e.g.
using the <display-*/> element)
2) localization: storing the description in an entity field makes it
easier to translate it in different languages

Maybe we could use the following convention: if the
CustomMethod.description is empty, then retrieve it from the service.

Jacopo


David E Jones wrote:

>
> Thanks for the heads up Jacopo. I've changed that back and added/changed
> comments to clarify how this works and note the misleading field name.
>
> As for the general pattern, it may come in useful at some point if we
> want to configure additional things related to these service calls or
> other methods. For the human description, why not just use the one on
> the service def itself?
>
> -David
>
>
>