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

[David E Jones]

On Jan 22, 2007, at 11:45 AM, Si Chen wrote:

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

Sounds fine to me.

-David

[jonwimp]

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:
>>>>> [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);
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>
> 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
>
>

[Scott Gray]

Only 2 quick points here:
1.  Contributors should have no obligation to their contribution once it is
in the trunk, if it has been passed by a committer then the code becomes the
responsibility of the community.  My bet is the "getVariantCombinations"
service was an improvement on what was there previously (probably nothing)
and we should be grateful that there is some functionality rather than none.

2.  "as David's lack of management of SVN trunk" what is this supposed to
mean?  If I were David I would be offended.  Management of the trunk is not
a one man job, it is the responibility of the commiters and it is unfair to
try and blame anything like this on someone who has contributed so much.

Regards
Scott

On 23/01/07, Jonathon -- Improov <[hidden email]> wrote:

>
> 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:
> >>>>> [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);
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>
> >>
> > 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
> >
> >
>
>

[jonwimp]

Scott,

 > 2.  "as David's lack of management of SVN trunk" what is this supposed to
 > mean?  If I were David I would be offended.  Management of the trunk is not
 > a one man job, it is the responibility of the commiters and it is unfair to
 > try and blame anything like this on someone who has contributed so much.

Relax. Reread my post:

 >> says OFBiz folks (including yourself) are busy; I say I am busy ("almost
 >> getting fired" kind of busy).

Very often, to push the responsible parties to act, we take it first upon ourselves. Hopefully,
the committers will start thinking "Was David around when I committed this, or was he at some
conference I was too busy to attend myself?".

I heard from somewhere that David's recently been through a lot. Good that you're looking out for him.

Jonathon

Scott Gray wrote:

> Only 2 quick points here:
> 1.  Contributors should have no obligation to their contribution once it is
> in the trunk, if it has been passed by a committer then the code becomes
> the
> responsibility of the community.  My bet is the "getVariantCombinations"
> service was an improvement on what was there previously (probably nothing)
> and we should be grateful that there is some functionality rather than
> none.
>
> 2.  "as David's lack of management of SVN trunk" what is this supposed to
> mean?  If I were David I would be offended.  Management of the trunk is not
> a one man job, it is the responibility of the commiters and it is unfair to
> try and blame anything like this on someone who has contributed so much.
>
> Regards
> Scott
>
> On 23/01/07, Jonathon -- Improov <[hidden email]> wrote:
>>
>> 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:
>> >>>>> [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);
>> >>>>>
>> >>>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>
>> >>
>> > 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
>> >
>> >
>>
>>
>
>
> ------------------------------------------------------------------------
>
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.5.432 / Virus Database: 268.17.5/645 - Release Date: 1/22/2007 4:10 PM