Re: [Fwd: svn commit: r495891 - /ofbiz/trunk/applications/product/src/org/ofbiz/product/feature/ProductFeatureServices.java]

Fri, 19 Jan 2007 23:25:10 -0800 


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" <[EMAIL PROTECTED]> 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" <[EMAIL PROTECTED]>

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:
[EMAIL PROTECTED]
Date:
Sat, 13 Jan 2007 12:48:56 -0000
To:
[email protected]

To:
[email protected]


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 ===

Attachment: smime.p7s
Description: S/MIME cryptographic signature

Reply via email to