Yes right Chris, a comment is maybe better (though not in log or else... Mmm...)
Jacques ----- Original Message ----- From: "Chris Howe" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, January 12, 2007 10:32 AM Subject: Re: Auto-generating of BOMs from Virtual Product to Variants > Leon's comments are right on and a much more straight > forward explanation then what I was about to send. > So, I'll leave it at +1 Leon to avoid confusion. > > In regards to the org.ofbiz.odbc, just to clarify, > org.ofbiz.odbc never 'required' odbc. The naming > convention used there appears to be because UPS > Worldship integration is done most easily using MS > Access databases. That's an appeasement of UPS, and > never was a requirement for OFBiz. I'm on the fence > though as whether org.ofbiz.external would necessarily > be a better naming convention. I think it may just > need <!-- --> commenting because it is a two part > integration as you have to set up UPS to use an > external database as well. The .odbc does push you in > the right direction. So, who knows? > > > > --- Leon Torres <[EMAIL PROTECTED]> wrote: > > > Isn't this what the GoodIdentification entity is all > > about? > > > > In practice your productIds, internally, should be > > serial numbers like > > 100100010. OFBiz allows the luxury of String IDs, > > and I would consider it a > > huge mistake to fall into the thinking that this is > > to be the ID that is > > marketable, exposable, and what the customer comes > > to identify with. > > > > You shouldn't rely on these *unique internal > > identifiers* to drive your product > > identity. There is a huge difference between data > > representation for purposes > > of system processing and human consumption. > > > > - Leon > > > > Jonathon -- Improov wrote: > > > 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 > > >> > > >> > > > > > > > >
