Chris,
You have the tendency to put a lot of concepts into very few paragraphs!
Without going into all the details of your message and branching off into many "big picture"
concepts, I'll just say this. I agree with you. I believe there is a need for a product lookup
key, an additional level of indirection perhaps. Product IDs do change, in my experience (though
not very very much). It's good to have the flexibility to rebrand my products.
But as OFBiz is already using productId for so many intelligent logics now, we'll have to leave
that "as is", and create a new field like marketingProductId or something. Original field names
may lose their meaning after some evolution, but at least there's less change
management/propagation required as compared to if we did a refactor (even a simple rename of
field). One example of such vestige is the name "org.ofbiz.odbc" entity group (group no longer
requires use of ODBC?).
For now, I'm just concerned with being able to put to my storefront the model number or branded
name I want. My competitor may have popularized WG-9943. So my productId WG-9943 stays, but I let
my customers now order that same product via a new name: WeizerGun-101-Enterprise (I'd like that
compared to WG-9943 anyway). I guess that (plus your feedback) answers my concern raised by you
regarding flexibility to rebrand products.
Jonathon
Chris Howe wrote:
--- Jonathon -- Improov <[EMAIL PROTECTED]> wrote:
Chris,
Is this how OFBiz is currently doing things? I can
see your point.
This is NOT how OFBiz currently does things. And
without a community effort to modularize the
components, (IMO) will likely never be the way OFBiz
does things. The product component and the
manufacturing components feature sets are simply,
individually too rich. You can't introduce this
concept into the product component without breaking
the manufacturing component (or at least severely
convoluting the conceptualizations as I understand
it). The value of the manufacturing component is just
too high compared to this benefit for this to be
feasible. If you were able to offer an alternative
product component, then a manufacturing component for
that new product component could be created without
the disruption to the current components.
But currently, I have a limiting/crippling "time to
market" constraint. When building for
flexibility, there can be no end to the quest.
Exactly. I can propose "what ifs" and "ponder this"
all day long as I have the luxury of never having to
satisfy your boss/client's actual need to sell
something :-) . This is the benefit and bane of open
source software. The lure to create a better
mousetrap when the only mice you have, you keep as
pets.
Whatever you said of Product IDs, the same may be
said of ProductFeature IDs or any other IDs in
OFBiz.
It's been a while since I've played with
ProductFeature IDs, so I may be off a bit on the
concept, but I don't think the same is true because
those IDs remain internal to your organization, don't
they?
Usually, I'm forced to deliver the
application first, see how things run with
prototype, then figure out where to go next after
getting a better view. I usually can't decide
whether to construct a skyscraper on small plateau
or sprawling shopping mall on large plateau when I
haven't even climbed up the plateau to see what
size it really is. Hindsight is cheaper to buy than
foresight.
Still, back to your discussion with Product IDs. Can
I use fields like "Internal Name" and
"Description" for my storefront? I know the
storefront currently displays Product ID. This is a
real problem. I'd like a bit, even if just a tiny
amount, of discussion or ideas thrown in at this
moment for this topic.
This is largely simply what you're choosing to show
the user of the site through the UI (except where
there are textbox inputs) your link information can
have the Product.productId to send to your services
but have the words that show up on the screen be
Product.internalName.
(To Boss: Any chance you'll be changing your Product
IDs like Chris said?)
Jonathon
Regards,
Chris
