[Fwd: svn commit: r495891 - /ofbiz/trunk/applications/prod
Locked
12
[Fwd: svn commit: r495891 - /ofbiz/trunk/applications/prod
Re: [Fwd: svn commit: r495891 - /ofbiz/trunk/applications/prod
Re: [Fwd: svn commit: r495891 - /ofbiz/trunk/applications/prod
Re: [Fwd: svn commit: r495891 - /ofbiz/trunk/applications/prod
Re: [Fwd: svn commit: r495891 - /ofbiz/trunk/applications/prod
Re: [Fwd: svn commit: r495891 - /ofbiz/trunk/applications/prod
Re: [Fwd: svn commit: r495891 - /ofbiz/trunk/applications/prod
Re: [Fwd: svn commit: r495891 - /ofbiz/trunk/applications/prod
Re: [Fwd: svn commit: r495891 - /ofbiz/trunk/applications/prod
Re: [Fwd: svn commit: r495891 - /ofbiz/trunk/applications/prod
Re: [Fwd: svn commit: r495891 - /ofbiz/trunk/applications/prod
Re: [Fwd: svn commit: r495891 - /ofbiz/trunk/applications/prod
Re: [Fwd: svn commit: r495891 - /ofbiz/trunk/applications/prod
Re: [Fwd: svn commit: r495891 - /ofbiz/trunk/applications/prod
Re: [Fwd: svn commit: r495891 - /ofbiz/trunk/applications/prod
Re: [Fwd: svn commit: r495891 - /ofbiz/trunk/applications/prod
Re: [Fwd: svn commit: r495891 - /ofbiz/trunk/applications/prod
Re: [Fwd: svn commit: r495891 - /ofbiz/trunk/applications/prod
Re: [Fwd: svn commit: r495891 - /ofbiz/trunk/applications/prod
Re: [Fwd: svn commit: r495891 - /ofbiz/trunk/applications/prod
12
[Fwd: svn commit: r495891 - /ofbiz/trunk/applications/prod
 
|
Re: [Fwd: svn commit: r495891 - /ofbiz/trunk/applications/prod
|
|
Re: [Fwd: svn commit: r495891 - /ofbiz/trunk/applications/prod
|
|
Re: [Fwd: svn commit: r495891 - /ofbiz/trunk/applications/prod
|
|
Here are my previous comments about it earlier on the mailing list: ========================================= This isn't a universal policy or anything, but I'd say for something minor like this there isn't a problem with hard-coding it. The whole point of the ID generation is to make the IDs unique. In the UI you can specify an ID instead of using the default, so it only matters so much. ========================================= In general if this sort of thing were to be configurable, would we really want it in a properties file? I'd say no, especially since one of the new objectives that has been discussed recently is to make it easy to configure things, make things configurable more granularly, and make it easier to use different seed data files for OOTB industry- specific configurations. What to do... -David On Jan 19, 2007, at 8:59 PM, Scott Gray wrote: > Hi > > I actually said that we should do it if anyone had objections, but > no one did so that's why it went in as is. But yeah if over- > running the limit is a possibility then it should probably be > changed. Perhaps there should be some code in there anyway for > coping with that situation, if someones running that many features > saving 1 character might not be much of a bonus. > > Regards > Scott > > Jacopo Cappellato wrote: >> I agree with Si. >> >> Jacopo >> >> Si Chen wrote: >>> Hey there - >>> >>> This patch is a good idea, but I think Scott Gray suggested that >>> this "-" could be configured in a properties file, and I think >>> that's a good idea. Otherwise, if you have four or five features >>> you will easily overrun the 20-character productId key limit. >>> Keeping it in properties file is a good way to allow it to be >>> modified. Otherwise it's not very nice to have to go into the >>> code to do it. >>> >>> Jonathon, you up for doing this and sending in another patch? >>> >>> Si >>> >>> -------------------------------------------------------------------- >>> ---- >>> >>> Subject: >>> svn commit: r495891 - /ofbiz/trunk/applications/product/src/org/ >>> ofbiz/product/feature/ProductFeatureServices.java >>> From: >>> [hidden email] >>> Date: >>> Sat, 13 Jan 2007 12:48:56 -0000 >>> To: >>> [hidden email] >>> >>> To: >>> [hidden email] >>> >>> >>> Author: jleroux >>> Date: Sat Jan 13 04:48:55 2007 >>> New Revision: 495891 >>> >>> URL: http://svn.apache.org/viewvc?view=rev&rev=495891 >>> Log: >>> A patch from Jonathon Wong "Prepend feature idCodes with >>> '-'" (https://issues.apache.org/jira/browse/OFBIZ-620) >>> >>> Modified: >>> ofbiz/trunk/applications/product/src/org/ofbiz/product/ >>> feature/ProductFeatureServices.java >>> >>> Modified: ofbiz/trunk/applications/product/src/org/ofbiz/product/ >>> feature/ProductFeatureServices.java >>> URL: http://svn.apache.org/viewvc/ofbiz/trunk/applications/ >>> product/src/org/ofbiz/product/feature/ProductFeatureServices.java? >>> view=diff&rev=495891&r1=495890&r2=495891 >>> ==================================================================== >>> ========== >>> --- ofbiz/trunk/applications/product/src/org/ofbiz/product/ >>> feature/ProductFeatureServices.java (original) >>> +++ ofbiz/trunk/applications/product/src/org/ofbiz/product/ >>> feature/ProductFeatureServices.java Sat Jan 13 04:48:55 2007 >>> @@ -227,7 +227,7 @@ >>> List newFeatures = new LinkedList(); >>> List newFeatureIds = new >>> LinkedList(); >>> if (currentFeature.getString >>> ("idCode") != null) >>> - newCombination.put >>> ("defaultVariantProductId", productId + currentFeature.getString >>> ("idCode")); >>> + newCombination.put >>> ("defaultVariantProductId", productId + "-" + >>> currentFeature.getString("idCode")); >>> else >>> newCombination.put >>> ("defaultVariantProductId", productId); >>> newFeatures.add(currentFeature); >>> >>> >> >> >> > |
smime.p7s (3K)
Re: [Fwd: svn commit: r495891 - /ofbiz/trunk/applications/prod
|
|
Re: [Fwd: svn commit: r495891 - /ofbiz/trunk/applications/prod
|
|
I think this is a little extreme, and I'm not sure hiding the productId is a good idea. The way it is now works really well for most companies I've worked with. And for the rest, having the productIds visible is not too much a problem, and they can be sequenced just fine. I should maybe say it again: this change it SO SO SO MINOR it is hardly worth reading the commit, let along discussing it. It is a default setting for a fairly special purpose UI and the ID can be manually set in the UI anyway. -David On Jan 19, 2007, at 10:31 PM, Chris Howe wrote: > I think this is best handled by reverting r495891 and > simply giving instruction for the modification for > those that wish to use it. With a move towards > granularity, we should be discouraging this type of > use as a primary key to begin with. This auto > generation should be creating a GoodIdentification > value instead of a primary key. If the primary key is > a surrogate key, let it truly be a surrogate and > remove the application data meaning surrounding it. > Then keep it hidden from the user of the application. > > Once we've finished successfully hiding the > Product.productId from the user and possibly scripts > to regenerate legacy Product Entities, then set up the > delimiter as a ProductCatalog setting. > > > --- "David E. Jones" <[hidden email]> wrote: > >> >> Here are my previous comments about it earlier on >> the mailing list: >> >> ========================================= >> This isn't a universal policy or anything, but I'd >> say for something >> minor like this there isn't a problem with >> hard-coding it. >> >> The whole point of the ID generation is to make the >> IDs unique. In >> the UI you can specify an ID instead of using the >> default, so it only >> matters so much. >> ========================================= >> >> In general if this sort of thing were to be >> configurable, would we >> really want it in a properties file? I'd say no, >> especially since one >> of the new objectives that has been discussed >> recently is to make it >> easy to configure things, make things configurable >> more granularly, >> and make it easier to use different seed data files >> for OOTB industry- >> specific configurations. >> >> What to do... >> >> -David >> >> >> On Jan 19, 2007, at 8:59 PM, Scott Gray wrote: >> >>> Hi >>> >>> I actually said that we should do it if anyone had >> objections, but >>> no one did so that's why it went in as is. But >> yeah if over- >>> running the limit is a possibility then it should >> probably be >>> changed. Perhaps there should be some code in >> there anyway for >>> coping with that situation, if someones running >> that many features >>> saving 1 character might not be much of a bonus. >>> >>> Regards >>> Scott >>> >>> Jacopo Cappellato wrote: >>>> I agree with Si. >>>> >>>> Jacopo >>>> >>>> Si Chen wrote: >>>>> Hey there - >>>>> >>>>> This patch is a good idea, but I think Scott >> Gray suggested that >>>>> this "-" could be configured in a properties >> file, and I think >>>>> that's a good idea. Otherwise, if you have four >> or five features >>>>> you will easily overrun the 20-character >> productId key limit. >>>>> Keeping it in properties file is a good way to >> allow it to be >>>>> modified. Otherwise it's not very nice to have >> to go into the >>>>> code to do it. >>>>> >>>>> Jonathon, you up for doing this and sending in >> another patch? >>>>> >>>>> Si >>>>> >>>>> >> > -------------------------------------------------------------------- >> >>>>> ---- >>>>> >>>>> Subject: >>>>> svn commit: r495891 - >> /ofbiz/trunk/applications/product/src/org/ >>>>> >> ofbiz/product/feature/ProductFeatureServices.java >>>>> From: >>>>> [hidden email] >>>>> Date: >>>>> Sat, 13 Jan 2007 12:48:56 -0000 >>>>> To: >>>>> [hidden email] >>>>> >>>>> To: >>>>> [hidden email] >>>>> >>>>> >>>>> Author: jleroux >>>>> Date: Sat Jan 13 04:48:55 2007 >>>>> New Revision: 495891 >>>>> >>>>> URL: >> http://svn.apache.org/viewvc?view=rev&rev=495891 >>>>> Log: >>>>> A patch from Jonathon Wong "Prepend feature >> idCodes with >>>>> '-'" >> (https://issues.apache.org/jira/browse/OFBIZ-620) >>>>> >>>>> Modified: >>>>> >> > ofbiz/trunk/applications/product/src/org/ofbiz/product/ >> >>>>> feature/ProductFeatureServices.java >>>>> >>>>> Modified: >> > ofbiz/trunk/applications/product/src/org/ofbiz/product/ >> >>>>> feature/ProductFeatureServices.java >>>>> URL: >> > http://svn.apache.org/viewvc/ofbiz/trunk/applications/ >> >>>>> >> > product/src/org/ofbiz/product/feature/ProductFeatureServices.java? >> >>>>> view=diff&rev=495891&r1=495890&r2=495891 >>>>> >> > ==================================================================== >> >>>>> ========== >>>>> --- >> > ofbiz/trunk/applications/product/src/org/ofbiz/product/ >> >>>>> feature/ProductFeatureServices.java (original) >>>>> +++ >> > ofbiz/trunk/applications/product/src/org/ofbiz/product/ >> >>>>> feature/ProductFeatureServices.java Sat Jan 13 >> 04:48:55 2007 >>>>> @@ -227,7 +227,7 @@ >>>>> List newFeatures >> = new LinkedList(); >>>>> List >> newFeatureIds = new >>>>> LinkedList(); >>>>> if >> (currentFeature.getString >>>>> ("idCode") != null) >>>>> - >> newCombination.put >>>>> ("defaultVariantProductId", productId + >> currentFeature.getString >>>>> ("idCode")); >>>>> + >> newCombination.put >>>>> ("defaultVariantProductId", productId + "-" + >>>>> currentFeature.getString("idCode")); >>>>> else >>>>> >> newCombination.put >>>>> ("defaultVariantProductId", productId); >>>>> >> newFeatures.add(currentFeature); >>>>> >>>>> >>>> >>>> >>>> >>> >> >> > |
Re: [Fwd: svn commit: r495891 - /ofbiz/trunk/applications/prod
|
|
Re: [Fwd: svn commit: r495891 - /ofbiz/trunk/applications/prod
|
|
Re: [Fwd: svn commit: r495891 - /ofbiz/trunk/applications/prod
|
|
In reply to this post by jonwimp
Maybe, as a compromise, to avoid the properties file issue you could just put an extra field in the UI for the character(s) to use to separate the base ID from the feature idCode(s). -David On Jan 20, 2007, at 12:04 AM, Jonathon -- Improov wrote: > Si, > > > This patch is a good idea, but I think Scott Gray suggested that > this > > "-" could be configured in a properties file, and I think that's > a good > > idea. Otherwise, if you have four or five features you will easily > > overrun the 20-character productId key limit. Keeping it in > properties > > file is a good way to allow it to be modified. Otherwise it's > not very > > nice to have to go into the code to do it. > > David said it's ok to hardcode it for now. I was arguing, but of > course it struck me that it wouldn't be difficult to > "customization" the hardcoding it folks needed to place say '--' or > '*' instead of '-'. > > I was of the idea that we put a field on the QuickAddVariants page > to allow users to specify the separator ('-' or '*' or 'whatever'). > > I was thinking we have '-' as the default. Then we allow config > properties to override this default. > > > Jonathon, you up for doing this and sending in another patch? > > Ok, sure. Which config file and what config param name you want it in? > > Jonathon > > Si Chen wrote: >> Hey there - >> This patch is a good idea, but I think Scott Gray suggested that >> this "-" could be configured in a properties file, and I think >> that's a good idea. Otherwise, if you have four or five features >> you will easily overrun the 20-character productId key limit. >> Keeping it in properties file is a good way to allow it to be >> modified. Otherwise it's not very nice to have to go into the >> code to do it. >> Jonathon, you up for doing this and sending in another patch? >> Si >> --------------------------------------------------------------------- >> --- >> No virus found in this incoming message. >> Checked by AVG Free Edition. >> Version: 7.5.432 / Virus Database: 268.17.0/639 - Release Date: >> 1/18/2007 6:47 PM > |
Re: [Fwd: svn commit: r495891 - /ofbiz/trunk/applications/prod
Administrator
|
Re: [Fwd: svn commit: r495891 - /ofbiz/trunk/applications/prod
|
|
In reply to this post by cjhowe
Chris, The point is that in the system we're going to support both ways. That's it. I see no good reason to write a bunch of stuff to force one way or another, especially when we've already written stuff (that's fairly simple really) to allow both. Another thing to consider: even if a productId is generated it doesn't mean you necessarily want it hidden. People may want to write it down, have fields where they can enter with a barcode scanner, etc, much like an order or invoice ID. -David On Jan 20, 2007, at 12:15 AM, Chris Howe wrote: > I agree that the delimiter issue is very, very small, > however the manner in which the order and ecommerce > component utilize the productId is not unique in a > company's life cycle. Granted, you won't run into > this problem on initial deployment or if your product > never changes. But very few companies keep their > product the exact same over the span of several years. > > To give you a real life example of the problem this > practice exposes. > We do business with a company that exposes their > primary key as their productId that we order with. > They manufacture power wheelchairs. Their vendor for > the seat kit (upholstery and mounting hardware) on the > chairs started becoming unreliable with delivery and > they had to get the upholstery from another vendor > (began as a mixed utilization before going completely > with the new vendor). In order to keep up their > quality control tracking, they had to issue a new > productId to distinguish the two chairs apart as seat > kits are not serialized. They allow their customers > to view real time inventory. They weren't able to > effectively communicate this change of productId to > their customers, so their customers kept getting "out > of stock" messages on the power wheelchairs. Their > customers ended up meeting their chair needs from > other suppliers. They experienced a 25% decline in > power wheelchair sales in the quarter this occurred, > had to discount their overstock the following quarter > and they have yet to win back many of the customers > that fulfilled their initial orders with another > supplier as well as the customers who now have the > perception of a "new" untested chair on the market. > > Because of a change in upholstery they had to consider > the ramifications on marketing, sales force training, > and inventory. This really isn't necessary. To the > customers these are the exact same chairs, they should > be ordering them with the exact same marketed > productId. Their inventory counts should be > consolidating the separate counts. Their sales force > should not be worried about how to explain the > differences in the two chairs. This could be a lot > simpler. > > This may be an extreme change, but it's extremely more > flexible and more accurately describes a business's > product line. > > ,Chris > > --- "David E. Jones" <[hidden email]> wrote: > >> >> I think this is a little extreme, and I'm not sure >> hiding the >> productId is a good idea. The way it is now works >> really well for >> most companies I've worked with. And for the rest, >> having the >> productIds visible is not too much a problem, and >> they can be >> sequenced just fine. >> >> I should maybe say it again: this change it SO SO SO >> MINOR it is >> hardly worth reading the commit, let along >> discussing it. It is a >> default setting for a fairly special purpose UI and >> the ID can be >> manually set in the UI anyway. >> >> -David >> >> >> On Jan 19, 2007, at 10:31 PM, Chris Howe wrote: >> >>> I think this is best handled by reverting r495891 >> and >>> simply giving instruction for the modification for >>> those that wish to use it. With a move towards >>> granularity, we should be discouraging this type >> of >>> use as a primary key to begin with. This auto >>> generation should be creating a GoodIdentification >>> value instead of a primary key. If the primary >> key is >>> a surrogate key, let it truly be a surrogate and >>> remove the application data meaning surrounding >> it. >>> Then keep it hidden from the user of the >> application. >>> >>> Once we've finished successfully hiding the >>> Product.productId from the user and possibly >> scripts >>> to regenerate legacy Product Entities, then set up >> the >>> delimiter as a ProductCatalog setting. >>> >>> >>> --- "David E. Jones" <[hidden email]> >> wrote: >>> >>>> >>>> Here are my previous comments about it earlier on >>>> the mailing list: >>>> >>>> ========================================= >>>> This isn't a universal policy or anything, but >> I'd >>>> say for something >>>> minor like this there isn't a problem with >>>> hard-coding it. >>>> >>>> The whole point of the ID generation is to make >> the >>>> IDs unique. In >>>> the UI you can specify an ID instead of using the >>>> default, so it only >>>> matters so much. >>>> ========================================= >>>> >>>> In general if this sort of thing were to be >>>> configurable, would we >>>> really want it in a properties file? I'd say no, >>>> especially since one >>>> of the new objectives that has been discussed >>>> recently is to make it >>>> easy to configure things, make things >> configurable >>>> more granularly, >>>> and make it easier to use different seed data >> files >>>> for OOTB industry- >>>> specific configurations. >>>> >>>> What to do... >>>> >>>> -David >>>> >>>> >>>> On Jan 19, 2007, at 8:59 PM, Scott Gray wrote: >>>> >>>>> Hi >>>>> >>>>> I actually said that we should do it if anyone >> had >>>> objections, but >>>>> no one did so that's why it went in as is. But >>>> yeah if over- >>>>> running the limit is a possibility then it >> should >>>> probably be >>>>> changed. Perhaps there should be some code in >>>> there anyway for >>>>> coping with that situation, if someones running >>>> that many features >>>>> saving 1 character might not be much of a bonus. >>>>> >>>>> Regards >>>>> Scott >>>>> >>>>> Jacopo Cappellato wrote: >>>>>> I agree with Si. >>>>>> >>>>>> Jacopo >>>>>> >>>>>> Si Chen wrote: >>>>>>> Hey there - >>>>>>> >>>>>>> This patch is a good idea, but I think Scott >>>> Gray suggested that >>>>>>> this "-" could be configured in a properties >>>> file, and I think >>>>>>> that's a good idea. Otherwise, if you have >> four >>>> or five features >>>>>>> you will easily overrun the 20-character >>>> productId key limit. >>>>>>> Keeping it in properties file is a good way to >>>> allow it to be >>>>>>> modified. Otherwise it's not very nice to >> have >>>> to go into the >>>>>>> code to do it. >>>>>>> >>>>>>> Jonathon, you up for doing this and sending in >>>> another patch? >>>>>>> >>>>>>> Si >>>>>>> >>>>>>> >>>> >>> >> > -------------------------------------------------------------------- >>>> >>>>>>> ---- >>>>>>> >>>>>>> Subject: >>>>>>> svn commit: r495891 - >>>> /ofbiz/trunk/applications/product/src/org/ >>>>>>> >>>> ofbiz/product/feature/ProductFeatureServices.java >>>>>>> From: >>>>>>> [hidden email] >>>>>>> Date: >>>>>>> Sat, 13 Jan 2007 12:48:56 -0000 >>>>>>> To: >>>>>>> [hidden email] >>>>>>> >>>>>>> To: >>>>>>> [hidden email] >>>>>>> >>>>>>> >>>>>>> Author: jleroux >>>>>>> Date: Sat Jan 13 04:48:55 2007 >>>>>>> New Revision: 495891 >>>>>>> >>>>>>> URL: >>>> http://svn.apache.org/viewvc?view=rev&rev=495891 >>>>>>> Log: >>>>>>> A patch from Jonathon Wong "Prepend feature >>>> idCodes with >>>>>>> '-'" >>>> (https://issues.apache.org/jira/browse/OFBIZ-620) >>>>>>> >>>>>>> Modified: >>>>>>> >>>> >>> >> > ofbiz/trunk/applications/product/src/org/ofbiz/product/ >>>> >>>>>>> feature/ProductFeatureServices.java >>>>>>> >>>>>>> Modified: >>>> >>> >> > ofbiz/trunk/applications/product/src/org/ofbiz/product/ >>>> >>>>>>> feature/ProductFeatureServices.java >>>>>>> URL: >>>> >>> >> > http://svn.apache.org/viewvc/ofbiz/trunk/applications/ >>>> >>>>>>> >>>> >>> >> > product/src/org/ofbiz/product/feature/ProductFeatureServices.java? >>>> >>>>>>> view=diff&rev=495891&r1=495890&r2=495891 >>>>>>> >>>> >> > === message truncated === > |
Re: [Fwd: svn commit: r495891 - /ofbiz/trunk/applications/prod
|
|
Re: [Fwd: svn commit: r495891 - /ofbiz/trunk/applications/prod
|
|
Re: [Fwd: svn commit: r495891 - /ofbiz/trunk/applications/prod
|
|
Re: [Fwd: svn commit: r495891 - /ofbiz/trunk/applications/prod
|
|
Re: [Fwd: svn commit: r495891 - /ofbiz/trunk/applications/prod
|
|
Re: [Fwd: svn commit: r495891 - /ofbiz/trunk/applications/prod
|
|
Re: [Fwd: svn commit: r495891 - /ofbiz/trunk/applications/prod
|
|
Re: [Fwd: svn commit: r495891 - /ofbiz/trunk/applications/prod
|
|
Re: [Fwd: svn commit: r495891 - /ofbiz/trunk/applications/prod
|
|
| Free forum by Nabble | Edit this page |