Si Chen,
Question. Is there any way to know who did the QuickAddVariants flow in the first place? Maybe the
original author should be responsible for correcting this MVC-related problem, for refactoring the
"getVariantCombinations" service?
The original service "getVariantCombinations" already "hardcodes" the construction procedure of
the variants' product IDs.
Yes, I agree my patch should not have added a new hardcode (the "-" separator)
into that service.
However, if I were to avoid that "evil", I'd have to refactor the service itself, plus the
QuickAddVariants screen, the whole works.
Sigh. Whether you take it as my fault (selfish change to serve my needs) or as David's lack of
management of SVN trunk, I have only 1 answer: time constraint. David says OFBiz folks (including
yourself) are busy; I say I am busy ("almost getting fired" kind of busy).
Only solution is to pour in more resources. I have no ideas regarding where to
find billionaires.
I still disagree with David that this is a trivial change. My boss requires the auto-generated
variants' product IDs for hundreds, no less, of variants per product. No reason for me to think
nobody else needs the same functionality, but different separator.
I guess this discussion is more a management issue than a coding issue? For example, who audited
the commit of the service "getVariantCombinations"?
This management issue does worry me (as does you, since your flagship CRMSFA/Financials rely on
OFBiz heavily), so I'll risk taking a retort from David here.
Jonathon
Si Chen wrote:
David E. Jones 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
==============================================================================
---
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);
David,
Unfortunately I find this to be somewhat unsatisfactory for two reasons:
1. Any potential problem when present should be addressed or at least
considered. This bit of code possibly adds a trivial enhancement in the
eyes of some users but definitely potential for bugs in the case of
other users.
2. While it is true that somebody can just correct those on the data
entry screen, the fact that this is at the service level rather than
just on the screen in a .bsh file means that somebody else might be
relying on this service to do things in a way that cannot be corrected
on a screen. To the extent the service layer offers a set of APIs in
the form of services, such services should work without resorting to
corrections in the view layer. One of my favorite things about OFBIZ is
the separation of the layers.
Still, I agree with you--let's not have a long discussion about small
things like this. If I find problems with it down the road with this
code I'll fix them myself in a way that's acceptable to all.
Si
