What is the best approach?

[Bruno Busco]

Hi,
I am considering to use ofbiz to implement an ecommerce site that sells
exclusively tyres.
Every tyre product has a specific code and some parameters as diameter,
width, height, load code and speed code.

In the site there should be the possibility to filter and list all product
specifing one or more of the above parameters.
I would like to know what is the preferred way to implement this.
Every tyre type must have a specific productId toghether with its parameters
so I do not think this is going to be a configurable product, am I right?

At the moment I have extended the Product entity with those additional
fields, but I am not sure to have done the best think.

Any help will be greatly appreciated.

-Bruno

[Scott Gray]

Sounds like virtual/variant products could be a good fit, you've got a brand
name (category?) model name (virtual product) and then the various sizes
(17x175x45) and codes for the variants.

Regards
Scott

2008/5/18 Bruno Busco <[hidden email]>:

> Hi,
> I am considering to use ofbiz to implement an ecommerce site that sells
> exclusively tyres.
> Every tyre product has a specific code and some parameters as diameter,
> width, height, load code and speed code.
>
> In the site there should be the possibility to filter and list all product
> specifing one or more of the above parameters.
> I would like to know what is the preferred way to implement this.
> Every tyre type must have a specific productId toghether with its
> parameters
> so I do not think this is going to be a configurable product, am I right?
>
> At the moment I have extended the Product entity with those additional
> fields, but I am not sure to have done the best think.
>
> Any help will be greatly appreciated.
>
> -Bruno
>

[Bruno Busco]

Scott,
reading documentation and exploring the catalog manager application I am
actually on the path of defining same feature types and features for
"Diameter", "Height", "Width", "Speed code" and "Load code" and adding them
to my product as "Distinguishing" features.

So doing I get the features printed out in the product details in ecommerce
and a combo for each one of the feature is present in the category search in
ecommerce.

I started defining the features as "standard" but they were not displayed in
the product details in ecommerce.

Now, for the brand, since it would be good to let the customer filter for it
also, should I use another feature or use the "Brand Name" field?

Thanks,
-Bruno

2008/5/18 Scott Gray <[hidden email]>:

> Sounds like virtual/variant products could be a good fit, you've got a
> brand
> name (category?) model name (virtual product) and then the various sizes
> (17x175x45) and codes for the variants.
>
> Regards
> Scott
>
> 2008/5/18 Bruno Busco <[hidden email]>:
>
> > Hi,
> > I am considering to use ofbiz to implement an ecommerce site that sells
> > exclusively tyres.
> > Every tyre product has a specific code and some parameters as diameter,
> > width, height, load code and speed code.
> >
> > In the site there should be the possibility to filter and list all
> product
> > specifing one or more of the above parameters.
> > I would like to know what is the preferred way to implement this.
> > Every tyre type must have a specific productId toghether with its
> > parameters
> > so I do not think this is going to be a configurable product, am I right?
> >
> > At the moment I have extended the Product entity with those additional
> > fields, but I am not sure to have done the best think.
> >
> > Any help will be greatly appreciated.
> >
> > -Bruno
> >
>

[Jacques Le Roux]

Hi Bruno,

Use selectable instead of "standard"

Jacques

From: "Bruno Busco" <[hidden email]>

> Scott,
> reading documentation and exploring the catalog manager application I am
> actually on the path of defining same feature types and features for
> "Diameter", "Height", "Width", "Speed code" and "Load code" and adding them
> to my product as "Distinguishing" features.
>
> So doing I get the features printed out in the product details in ecommerce
> and a combo for each one of the feature is present in the category search in
> ecommerce.
>
> I started defining the features as "standard" but they were not displayed in
> the product details in ecommerce.
>
> Now, for the brand, since it would be good to let the customer filter for it
> also, should I use another feature or use the "Brand Name" field?
>
> Thanks,
> -Bruno
>
> 2008/5/18 Scott Gray <[hidden email]>:
>
>> Sounds like virtual/variant products could be a good fit, you've got a
>> brand
>> name (category?) model name (virtual product) and then the various sizes
>> (17x175x45) and codes for the variants.
>>
>> Regards
>> Scott
>>
>> 2008/5/18 Bruno Busco <[hidden email]>:
>>
>> > Hi,
>> > I am considering to use ofbiz to implement an ecommerce site that sells
>> > exclusively tyres.
>> > Every tyre product has a specific code and some parameters as diameter,
>> > width, height, load code and speed code.
>> >
>> > In the site there should be the possibility to filter and list all
>> product
>> > specifing one or more of the above parameters.
>> > I would like to know what is the preferred way to implement this.
>> > Every tyre type must have a specific productId toghether with its
>> > parameters
>> > so I do not think this is going to be a configurable product, am I right?
>> >
>> > At the moment I have extended the Product entity with those additional
>> > fields, but I am not sure to have done the best think.
>> >
>> > Any help will be greatly appreciated.
>> >
>> > -Bruno
>> >
>>
>

[Bruno Busco]

Jacques,
I am actually using "Distinguishing" not "Standard".
If I select anything other than "Distinguishing" I do not have the features
visible in the product detals in ecommerce.

What is the difference with "selectable" ?

-Bruno

2008/5/18 Jacques Le Roux <[hidden email]>:

> Hi Bruno,
>
> Use selectable instead of "standard"
>
> Jacques
>
> From: "Bruno Busco" <[hidden email]>
>
>  Scott,
>> reading documentation and exploring the catalog manager application I am
>> actually on the path of defining same feature types and features for
>> "Diameter", "Height", "Width", "Speed code" and "Load code" and adding
>> them
>> to my product as "Distinguishing" features.
>>
>> So doing I get the features printed out in the product details in
>> ecommerce
>> and a combo for each one of the feature is present in the category search
>> in
>> ecommerce.
>>
>> I started defining the features as "standard" but they were not displayed
>> in
>> the product details in ecommerce.
>>
>> Now, for the brand, since it would be good to let the customer filter for
>> it
>> also, should I use another feature or use the "Brand Name" field?
>>
>> Thanks,
>> -Bruno
>>
>> 2008/5/18 Scott Gray <[hidden email]>:
>>
>>  Sounds like virtual/variant products could be a good fit, you've got a
>>> brand
>>> name (category?) model name (virtual product) and then the various sizes
>>> (17x175x45) and codes for the variants.
>>>
>>> Regards
>>> Scott
>>>
>>> 2008/5/18 Bruno Busco <[hidden email]>:
>>>
>>> > Hi,
>>> > I am considering to use ofbiz to implement an ecommerce site that sells
>>> > exclusively tyres.
>>> > Every tyre product has a specific code and some parameters as diameter,
>>> > width, height, load code and speed code.
>>> >
>>> > In the site there should be the possibility to filter and list all
>>> product
>>> > specifing one or more of the above parameters.
>>> > I would like to know what is the preferred way to implement this.
>>> > Every tyre type must have a specific productId toghether with its
>>> > parameters
>>> > so I do not think this is going to be a configurable product, am I
>>> right?
>>> >
>>> > At the moment I have extended the Product entity with those additional
>>> > fields, but I am not sure to have done the best think.
>>> >
>>> > Any help will be greatly appreciated.
>>> >
>>> > -Bruno
>>> >
>>>
>>>
>>

[Jacques Le Roux]

Bruno,

Yes sorry, I read your mail too fast. From the top of my head I have always used selectable (sélectionnable in french, see
ProductSelectable as label). I'm not quite sure of the difference, maybe it's better to use Distinguishing in your case. I suggest
that you look into related java code for this. This is often the quicker way to know specific things in OFBiz ;o)

Jacques

From: "Bruno Busco" <[hidden email]>

> Jacques,
> I am actually using "Distinguishing" not "Standard".
> If I select anything other than "Distinguishing" I do not have the features
> visible in the product detals in ecommerce.
>
> What is the difference with "selectable" ?
>
> -Bruno
>
> 2008/5/18 Jacques Le Roux <[hidden email]>:
>
>> Hi Bruno,
>>
>> Use selectable instead of "standard"
>>
>> Jacques
>>
>> From: "Bruno Busco" <[hidden email]>
>>
>>  Scott,
>>> reading documentation and exploring the catalog manager application I am
>>> actually on the path of defining same feature types and features for
>>> "Diameter", "Height", "Width", "Speed code" and "Load code" and adding
>>> them
>>> to my product as "Distinguishing" features.
>>>
>>> So doing I get the features printed out in the product details in
>>> ecommerce
>>> and a combo for each one of the feature is present in the category search
>>> in
>>> ecommerce.
>>>
>>> I started defining the features as "standard" but they were not displayed
>>> in
>>> the product details in ecommerce.
>>>
>>> Now, for the brand, since it would be good to let the customer filter for
>>> it
>>> also, should I use another feature or use the "Brand Name" field?
>>>
>>> Thanks,
>>> -Bruno
>>>
>>> 2008/5/18 Scott Gray <[hidden email]>:
>>>
>>>  Sounds like virtual/variant products could be a good fit, you've got a
>>>> brand
>>>> name (category?) model name (virtual product) and then the various sizes
>>>> (17x175x45) and codes for the variants.
>>>>
>>>> Regards
>>>> Scott
>>>>
>>>> 2008/5/18 Bruno Busco <[hidden email]>:
>>>>
>>>> > Hi,
>>>> > I am considering to use ofbiz to implement an ecommerce site that sells
>>>> > exclusively tyres.
>>>> > Every tyre product has a specific code and some parameters as diameter,
>>>> > width, height, load code and speed code.
>>>> >
>>>> > In the site there should be the possibility to filter and list all
>>>> product
>>>> > specifing one or more of the above parameters.
>>>> > I would like to know what is the preferred way to implement this.
>>>> > Every tyre type must have a specific productId toghether with its
>>>> > parameters
>>>> > so I do not think this is going to be a configurable product, am I
>>>> right?
>>>> >
>>>> > At the moment I have extended the Product entity with those additional
>>>> > fields, but I am not sure to have done the best think.
>>>> >
>>>> > Any help will be greatly appreciated.
>>>> >
>>>> > -Bruno
>>>> >
>>>>
>>>>
>>>
>

[David E Jones]

The best matching functionality would be a ProductFeature with the  
different types as you described. These should be associated to  
products as standard features.

Not showing up in ecommerce just means it's not in the productdetail  
(or other product display) template, and you can make changes there as  
desired.

Using product features this way will allow for searching by feature  
using the advanced search page in the ecommerce templates.

Note that there is a good deal of more advanced functionality related  
to this, like associating features with a category so that when you  
search within the category you only see the features to search by that  
are relevant for that category.

As far as the data structures go, the ProductFeature and  
ProductFeatureAppl entities (and ProductFeatureAndAppl view-entity if  
I remember right) are the ones you want to look at, and you can find  
lots of stuff by searching for those around OFBiz.

-David


On May 18, 2008, at 1:54 AM, Bruno Busco wrote:

> Hi,
> I am considering to use ofbiz to implement an ecommerce site that  
> sells
> exclusively tyres.
> Every tyre product has a specific code and some parameters as  
> diameter,
> width, height, load code and speed code.
>
> In the site there should be the possibility to filter and list all  
> product
> specifing one or more of the above parameters.
> I would like to know what is the preferred way to implement this.
> Every tyre type must have a specific productId toghether with its  
> parameters
> so I do not think this is going to be a configurable product, am I  
> right?
>
> At the moment I have extended the Product entity with those additional
> fields, but I am not sure to have done the best think.
>
> Any help will be greatly appreciated.
>
> -Bruno

[David E Jones]

BTW, I forgot to mention about virtual/variant products: these are  
just another way of "organizing" the actual products from an end-user  
perspective, and may be a useful tool for selecting tires (or may not  
be).

If you create your tire products with standard features you could add  
the virtual products later. There are even some tools in the catalog  
manager to do that, ie search for products by features and create a  
virtual product that groups them together. That virtual product will  
have all of the standard features of the variant products associated  
to it as selectable features.

On the standard versus distinguishing feature type: distinguishing  
features are in effect standard features, but with the additional  
constraint that they are also used to distinguish one variant from  
another relative to a virtual product. In other words distinguishing  
is a sub-set of standard. Features can be associated to a product with  
both assoc types.

-David


On May 18, 2008, at 9:50 AM, David E Jones wrote:

>
> The best matching functionality would be a ProductFeature with the  
> different types as you described. These should be associated to  
> products as standard features.
>
> Not showing up in ecommerce just means it's not in the productdetail  
> (or other product display) template, and you can make changes there  
> as desired.
>
> Using product features this way will allow for searching by feature  
> using the advanced search page in the ecommerce templates.
>
> Note that there is a good deal of more advanced functionality  
> related to this, like associating features with a category so that  
> when you search within the category you only see the features to  
> search by that are relevant for that category.
>
> As far as the data structures go, the ProductFeature and  
> ProductFeatureAppl entities (and ProductFeatureAndAppl view-entity  
> if I remember right) are the ones you want to look at, and you can  
> find lots of stuff by searching for those around OFBiz.
>
> -David
>
>
> On May 18, 2008, at 1:54 AM, Bruno Busco wrote:
>
>> Hi,
>> I am considering to use ofbiz to implement an ecommerce site that  
>> sells
>> exclusively tyres.
>> Every tyre product has a specific code and some parameters as  
>> diameter,
>> width, height, load code and speed code.
>>
>> In the site there should be the possibility to filter and list all  
>> product
>> specifing one or more of the above parameters.
>> I would like to know what is the preferred way to implement this.
>> Every tyre type must have a specific productId toghether with its  
>> parameters
>> so I do not think this is going to be a configurable product, am I  
>> right?
>>
>> At the moment I have extended the Product entity with those  
>> additional
>> fields, but I am not sure to have done the best think.
>>
>> Any help will be greatly appreciated.
>>
>> -Bruno
>

[Bruno Busco]

Many many thanks,
your explanation helps a lot.

-Bruno


2008/5/18 David E Jones <[hidden email]>:

>
> BTW, I forgot to mention about virtual/variant products: these are just
> another way of "organizing" the actual products from an end-user
> perspective, and may be a useful tool for selecting tires (or may not be).
>
> If you create your tire products with standard features you could add the
> virtual products later. There are even some tools in the catalog manager to
> do that, ie search for products by features and create a virtual product
> that groups them together. That virtual product will have all of the
> standard features of the variant products associated to it as selectable
> features.
>
> On the standard versus distinguishing feature type: distinguishing features
> are in effect standard features, but with the additional constraint that
> they are also used to distinguish one variant from another relative to a
> virtual product. In other words distinguishing is a sub-set of standard.
> Features can be associated to a product with both assoc types.
>
> -David
>
>
>
> On May 18, 2008, at 9:50 AM, David E Jones wrote:
>
>
>> The best matching functionality would be a ProductFeature with the
>> different types as you described. These should be associated to products as
>> standard features.
>>
>> Not showing up in ecommerce just means it's not in the productdetail (or
>> other product display) template, and you can make changes there as desired.
>>
>> Using product features this way will allow for searching by feature using
>> the advanced search page in the ecommerce templates.
>>
>> Note that there is a good deal of more advanced functionality related to
>> this, like associating features with a category so that when you search
>> within the category you only see the features to search by that are relevant
>> for that category.
>>
>> As far as the data structures go, the ProductFeature and
>> ProductFeatureAppl entities (and ProductFeatureAndAppl view-entity if I
>> remember right) are the ones you want to look at, and you can find lots of
>> stuff by searching for those around OFBiz.
>>
>> -David
>>
>>
>> On May 18, 2008, at 1:54 AM, Bruno Busco wrote:
>>
>>  Hi,
>>> I am considering to use ofbiz to implement an ecommerce site that sells
>>> exclusively tyres.
>>> Every tyre product has a specific code and some parameters as diameter,
>>> width, height, load code and speed code.
>>>
>>> In the site there should be the possibility to filter and list all
>>> product
>>> specifing one or more of the above parameters.
>>> I would like to know what is the preferred way to implement this.
>>> Every tyre type must have a specific productId toghether with its
>>> parameters
>>> so I do not think this is going to be a configurable product, am I right?
>>>
>>> At the moment I have extended the Product entity with those additional
>>> fields, but I am not sure to have done the best think.
>>>
>>> Any help will be greatly appreciated.
>>>
>>> -Bruno
>>>
>>
>>
>