Virtuals & variants
Locked
 
|
Hi All,
I'm just a bit curious about why we allow more than one variant product to be attached to the same set of feature combinations of a virtual. If all variants are exactly the same but only differentiated by the selectable features of the virtual then how can two variants with the same features not be the same product? Any thoughts or possible use cases would be appreciated. Thanks Scott |
|
|
Scott,
This is a complete guess, could it be to do with inventory etc? i.e. 2 variants (different products), but with the same features. - Andrew On Mon, 2006-06-26 at 21:38 +1200, Scott Gray wrote: > Hi All, > > I'm just a bit curious about why we allow more than one variant product > to be attached to the same set of feature combinations of a virtual. If > all variants are exactly the same but only differentiated by the > selectable features of the virtual then how can two variants with the > same features not be the same product? > > Any thoughts or possible use cases would be appreciated. > > Thanks > Scott > > > Kind Regards Andrew Sykes <[hidden email]> Sykes Development Ltd http://www.sykesdevelopment.com |
|
|
In reply to this post by Scott Gray
I agree that the virtual/variant associations can be improved and
cleaned-up. However, I think that before we can think of adding constraints to the number of allowed variants, we should cope with the following other issues as well, for example: how should we treat a variant product that has more standard features (types) than the selectable features of its virtual? Jacopo Scott Gray wrote: > Hi All, > > I'm just a bit curious about why we allow more than one variant product > to be attached to the same set of feature combinations of a virtual. If > all variants are exactly the same but only differentiated by the > selectable features of the virtual then how can two variants with the > same features not be the same product? > > Any thoughts or possible use cases would be appreciated. > > Thanks > Scott > > > > |
|
|
or...
can a product be a variant product of more than one virtual products? Jacopo Jacopo Cappellato wrote: > I agree that the virtual/variant associations can be improved and > cleaned-up. > However, I think that before we can think of adding constraints to the > number of allowed variants, we should cope with the following other > issues as well, for example: > > how should we treat a variant product that has more standard features > (types) than the selectable features of its virtual? > > Jacopo > > > Scott Gray wrote: >> Hi All, >> >> I'm just a bit curious about why we allow more than one variant >> product to be attached to the same set of feature combinations of a >> virtual. If all variants are exactly the same but only differentiated >> by the selectable features of the virtual then how can two variants >> with the same features not be the same product? >> >> Any thoughts or possible use cases would be appreciated. >> >> Thanks >> Scott >> >> >> >> > > |
|
|
or...
can a product be a virtual variant? :-) I did some experiments in the past with this configuration; this can be used to implement a complex, multi-screens/steps product configuration. Jacopo Jacopo Cappellato wrote: > or... > > can a product be a variant product of more than one virtual products? > > Jacopo > > Jacopo Cappellato wrote: >> I agree that the virtual/variant associations can be improved and >> cleaned-up. >> However, I think that before we can think of adding constraints to the >> number of allowed variants, we should cope with the following other >> issues as well, for example: >> >> how should we treat a variant product that has more standard features >> (types) than the selectable features of its virtual? >> >> Jacopo >> >> >> Scott Gray wrote: >>> Hi All, >>> >>> I'm just a bit curious about why we allow more than one variant >>> product to be attached to the same set of feature combinations of a >>> virtual. If all variants are exactly the same but only >>> differentiated by the selectable features of the virtual then how can >>> two variants with the same features not be the same product? >>> >>> Any thoughts or possible use cases would be appreciated. >>> >>> Thanks >>> Scott >>> >>> >>> >>> >> >> > |
|
|
In reply to this post by Jacopo Cappellato
Jacopo,
I think the answer to both of these should be yes. Imagine you had a VERY complex set of variants for a specific trade, you may want to create a simplified version of your site for the public. So you may want to make assumptions about some of the selections that the public make, but not about what the tradesman wants. It may be there's a better way to handle this than unconstrained virtual/variant relationships, but I guess that would have to be clarified before the constraints were made. - Andrew On Tue, 2006-06-27 at 12:48 +0200, Jacopo Cappellato wrote: > or... > > can a product be a variant product of more than one virtual products? > > Jacopo > > Jacopo Cappellato wrote: > > I agree that the virtual/variant associations can be improved and > > cleaned-up. > > However, I think that before we can think of adding constraints to the > > number of allowed variants, we should cope with the following other > > issues as well, for example: > > > > how should we treat a variant product that has more standard features > > (types) than the selectable features of its virtual? > > > > Jacopo > > > > > > Scott Gray wrote: > >> Hi All, > >> > >> I'm just a bit curious about why we allow more than one variant > >> product to be attached to the same set of feature combinations of a > >> virtual. If all variants are exactly the same but only differentiated > >> by the selectable features of the virtual then how can two variants > >> with the same features not be the same product? > >> > >> Any thoughts or possible use cases would be appreciated. > >> > >> Thanks > >> Scott > >> > >> > >> > >> > > > > Kind Regards Andrew Sykes <[hidden email]> Sykes Development Ltd http://www.sykesdevelopment.com |
|
|
Hi Jacopo/Andrew
Shouldn't the focus be on the basic concept of a virtual/variant relationship? This seems like it would be the most common use-case and should be supported thoroughly, over and above any other possible customizations. I am still struggling to imagine a real life use-case that would be important enough limit the development of what is otherwise an extremely useful product type. I'm trying to stick to modifications that can go into SVN at this stage, so if works not wanted on this then I'll move on to something else and come back to it later when I'm customizing. I understand that just because I might find it useful doesn't mean it's right for ofbiz, and I have no doubt that you guys know better than I in this regard. Regards Scott Andrew Sykes wrote: > Jacopo, > > I think the answer to both of these should be yes. > > Imagine you had a VERY complex set of variants for a specific trade, you > may want to create a simplified version of your site for the public. > > So you may want to make assumptions about some of the selections that > the public make, but not about what the tradesman wants. > > It may be there's a better way to handle this than unconstrained > virtual/variant relationships, but I guess that would have to be > clarified before the constraints were made. > > - Andrew > > On Tue, 2006-06-27 at 12:48 +0200, Jacopo Cappellato wrote: > >> or... >> >> can a product be a variant product of more than one virtual products? >> >> Jacopo >> >> Jacopo Cappellato wrote: >> >>> I agree that the virtual/variant associations can be improved and >>> cleaned-up. >>> However, I think that before we can think of adding constraints to the >>> number of allowed variants, we should cope with the following other >>> issues as well, for example: >>> >>> how should we treat a variant product that has more standard features >>> (types) than the selectable features of its virtual? >>> >>> Jacopo >>> >>> >>> Scott Gray wrote: >>> >>>> Hi All, >>>> >>>> I'm just a bit curious about why we allow more than one variant >>>> product to be attached to the same set of feature combinations of a >>>> virtual. If all variants are exactly the same but only differentiated >>>> by the selectable features of the virtual then how can two variants >>>> with the same features not be the same product? >>>> >>>> Any thoughts or possible use cases would be appreciated. >>>> >>>> Thanks >>>> Scott >>>> >>>> >>>> >>>> >>>> >>> |
|
|
Scott,
I really appreciate your attitude and work. Could you please be more specific about the changes you are proposing? Jacopo Scott Gray wrote: > Hi Jacopo/Andrew > > Shouldn't the focus be on the basic concept of a virtual/variant > relationship? This seems like it would be the most common use-case and > should be supported thoroughly, over and above any other possible > customizations. I am still struggling to imagine a real life use-case > that would be important enough limit the development of what is > otherwise an extremely useful product type. > > I'm trying to stick to modifications that can go into SVN at this stage, > so if works not wanted on this then I'll move on to something else and > come back to it later when I'm customizing. I understand that just > because I might find it useful doesn't mean it's right for ofbiz, and I > have no doubt that you guys know better than I in this regard. > > Regards > Scott > |
|
|
Hi Jacopo
I was initially looking at requiring featureTypes to be associated to the virtual before any selectable features can be added and somehow enforcing that variants should exist for every possible feature combination, and then using those rules as a basis to improve the UI. But I think I'll leave this for now, the more I look into how it all works at the moment any changes I begin to consider become horrendously complicated and perhaps not worth while. I think I'll stick to more basic/straightforward issues until I have a better understanding of the whole product structure including production and then perhaps see what improvements I think could be made to virtuals, if any. Thanks for your comments Scott Jacopo Cappellato wrote: > Scott, > > I really appreciate your attitude and work. > Could you please be more specific about the changes you are proposing? > > Jacopo > > Scott Gray wrote: >> Hi Jacopo/Andrew >> >> Shouldn't the focus be on the basic concept of a virtual/variant >> relationship? This seems like it would be the most common use-case >> and should be supported thoroughly, over and above any other possible >> customizations. I am still struggling to imagine a real life use-case >> that would be important enough limit the development of what is >> otherwise an extremely useful product type. >> >> I'm trying to stick to modifications that can go into SVN at this >> stage, so if works not wanted on this then I'll move on to something >> else and come back to it later when I'm customizing. I understand >> that just because I might find it useful doesn't mean it's right for >> ofbiz, and I have no doubt that you guys know better than I in this >> regard. >> >> Regards >> Scott >> > > |
|
|
In reply to this post by Jacopo Cappellato
Scott,
I agree with Jacopo, please don't be put off by bizarre use cases and such like, it's just important that anyone making changes enters into them with all the subtle nuances in mind. It would be great to see what kind of suggestions you had in mind... - Andrew On Fri, 2006-06-30 at 12:41 +0200, Jacopo Cappellato wrote: > Scott, > > I really appreciate your attitude and work. > Could you please be more specific about the changes you are proposing? > > Jacopo > > Scott Gray wrote: > > Hi Jacopo/Andrew > > > > Shouldn't the focus be on the basic concept of a virtual/variant > > relationship? This seems like it would be the most common use-case and > > should be supported thoroughly, over and above any other possible > > customizations. I am still struggling to imagine a real life use-case > > that would be important enough limit the development of what is > > otherwise an extremely useful product type. > > > > I'm trying to stick to modifications that can go into SVN at this stage, > > so if works not wanted on this then I'll move on to something else and > > come back to it later when I'm customizing. I understand that just > > because I might find it useful doesn't mean it's right for ofbiz, and I > > have no doubt that you guys know better than I in this regard. > > > > Regards > > Scott > > > Kind Regards Andrew Sykes <[hidden email]> Sykes Development Ltd http://www.sykesdevelopment.com |
|
|
Hi Andrew
Not put off at all, but I am perhaps getting a bit ahead of myself at any rate. I can work quite happily within the current setup and what i really want to get on to next is improving the product requirement planning. I just have a bad habit of getting easily distracted :-) Regards Scott Andrew Sykes wrote: > Scott, > > I agree with Jacopo, please don't be put off by bizarre use cases and > such like, it's just important that anyone making changes enters into > them with all the subtle nuances in mind. > > It would be great to see what kind of suggestions you had in mind... > > - Andrew > > On Fri, 2006-06-30 at 12:41 +0200, Jacopo Cappellato wrote: > >> Scott, >> >> I really appreciate your attitude and work. >> Could you please be more specific about the changes you are proposing? >> >> Jacopo >> >> Scott Gray wrote: >> >>> Hi Jacopo/Andrew >>> >>> Shouldn't the focus be on the basic concept of a virtual/variant >>> relationship? This seems like it would be the most common use-case and >>> should be supported thoroughly, over and above any other possible >>> customizations. I am still struggling to imagine a real life use-case >>> that would be important enough limit the development of what is >>> otherwise an extremely useful product type. >>> >>> I'm trying to stick to modifications that can go into SVN at this stage, >>> so if works not wanted on this then I'll move on to something else and >>> come back to it later when I'm customizing. I understand that just >>> because I might find it useful doesn't mean it's right for ofbiz, and I >>> have no doubt that you guys know better than I in this regard. >>> >>> Regards >>> Scott >>> >>> |
«
Return to OFBiz - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |