Dev - default values for isVirtual and isVariant fields

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Dev - default values for isVirtual and isVariant fields

Jacopo Cappellato
Hi all,

what do you think about always setting a value in the isVirtual and
isVariant fields in the Product entity?
At the moment the fields can contain the following values: null, "Y", "N".
I think that null and "N" have the same meaning here but it is sometime
difficult to filter the records: for example in a products' lookup form
(that uses the performFind service) I'd like to show only the products
that are NOT variants.
I'd like to add something like this to the find form definition:

<field name="isVariant"><hidden value="N"/></field>

but then I'll exclude all the products with the isVariant field set to null.

So, can me patch the createProduct service to always fill the two fields
with Y or N (default)?

Jacopo



 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev
Reply | Threaded
Open this post in threaded view
|

Re: Dev - default values for isVirtual and isVariant fields

Si Chen-2
I think that's a good idea.  Si

Jacopo Cappellato wrote:

>Hi all,
>
>what do you think about always setting a value in the isVirtual and
>isVariant fields in the Product entity?
>At the moment the fields can contain the following values: null, "Y", "N".
>I think that null and "N" have the same meaning here but it is sometime
>difficult to filter the records: for example in a products' lookup form
>(that uses the performFind service) I'd like to show only the products
>that are NOT variants.
>I'd like to add something like this to the find form definition:
>
><field name="isVariant"><hidden value="N"/></field>
>
>but then I'll exclude all the products with the isVariant field set to null.
>
>So, can me patch the createProduct service to always fill the two fields
>with Y or N (default)?
>
>Jacopo
>
>
>
>
>_______________________________________________
>Dev mailing list
>[hidden email]
>http://lists.ofbiz.org/mailman/listinfo/dev
>
>  
>
 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev
Reply | Threaded
Open this post in threaded view
|

Re: Dev - default values for isVirtual and isVariant fields

David E. Jones

I think it's a good idea too. Still, for critical code it should always handle the null case since there isn't really any way to force this...

-David


Si Chen wrote:

> I think that's a good idea.  Si
>
> Jacopo Cappellato wrote:
>
>> Hi all,
>>
>> what do you think about always setting a value in the isVirtual and
>> isVariant fields in the Product entity?
>> At the moment the fields can contain the following values: null, "Y", "N".
>> I think that null and "N" have the same meaning here but it is sometime
>> difficult to filter the records: for example in a products' lookup form
>> (that uses the performFind service) I'd like to show only the products
>> that are NOT variants.
>> I'd like to add something like this to the find form definition:
>>
>> <field name="isVariant"><hidden value="N"/></field>
>>
>> but then I'll exclude all the products with the isVariant field set to null.
>>
>> So, can me patch the createProduct service to always fill the two fields
>> with Y or N (default)?
>>
>> Jacopo
>>
>>
>>
>>
>> _______________________________________________
>> 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
Reply | Threaded
Open this post in threaded view
|

Re: Dev - default values for isVirtual and isVariant fields

Jacopo Cappellato
It's fine, I'll go for it!

Thanks,

Jacopo

David E. Jones wrote:
> I think it's a good idea too. Still, for critical code it should always handle the null case since there isn't really any way to force this...
>
> -David
>

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