Re: Dev - UoM Conversion Enhancement

Posted by Carl Sopchak on
URL: http://ofbiz.116.s1.nabble.com/Dev-UoM-Conversion-Enhancement-tp167105p167116.html

Adrian, sounds good.  My gut tells me there'll be quite a few calls to
convertUom, so it'll probably take some time to hit them all.

It was pointed out to me that it would be more flexible if the new optional
parameter to convertUom was a Map, and I agree, so I have modified the parms
per the attached diff file.  

I plan on continuing this in the JIRA, which is here:
http://jira.undersunconsulting.com/browse/OFBIZ-782

I have the patch to the UomConversion entity there as well.  That's steps 1 &
2 down, 5 to go...

Carl

On Friday, March 10, 2006 11:58, Adrian Crum wrote:

> I'll pitch in on this, but I'd like to wait a day or two for the other
> developers to look over your proposal - to make sure everyone agrees this
> is the way we should go.
>
> I'm kinda swamped today and I won't be able to research this until tomorrow
> (Saturday). I'll comment more then.
>
> Carl Sopchak wrote:
> > I've decided to pursue the use of services via the CustomMethod entity.
> > (Thanks Jacopo for the help!)  Here's what I have in mind now:
> >
> > 1) Add the customMethodId to the UomConversion file, with a relation to
> > CustomMethod.
> > 2) Add an optional parameter to convertUom: productId.
> > 3) Add a check in the simple method convertUom (in CommonServices.xml),
> > right after the check for the UomConversion record being found:  If
> > customMethodId is not empty, call convertUomCustom and skip the rest of
> > the logic in convertUom.
> > 4) Add method convertUomCustom to CommonServices.xml that looks up the
> > customMethodId in CustomMethod and calls the service, which in my case, I
> > plan on calling convertUomProduct.
> > 5) Create a service_uom.xml file in framework/common/servicedef that
> > defines convertUomProduct.
> > 6) Create a UomFormulas.xml in framework/common/script/org/ofbiz/common
> > which implements convertUomProduct.  This would basically do the logic
> > (more or less) of my original post.
> > 7) Find all calls to convertUom and add the productId as a parameter, if
> > one is
> > available.
> >
> > I think this is much more flexible than my original idea, and not very
> > much more work.
> >
> > I will add this to jira.
> >
> > Any other comments are welcome.
> >
> > Adiran, if you'd like to help, how about working on the task #7 listed
> > above: adding productId to the convertUom calls.  I have already made the
> > change to framework/common/servicedef/services.xml to add the productId
> > as an optional parameter.  The diff is attached.  The I should have steps
> > 1 through 4 done today, 5 and 6 maybe as early as tomorrow.
> >
> > Carl
> >
> > On Friday, March 10, 2006 07:50, Carl Sopchak wrote:
> >>Jacopo, thanks for pointing this out!  This should make the flexibility
> >>that should be implemented must simpler to do (since the code is already
> >>there - or close enough to copy and modify).
> >>
> >>One of my hesitations with going for a more general solution is that this
> >>is my first attempt at modifying OFBiz.  I know I can implement my first
> >>suggestion, but things are still fuzzy with the CustomMethod approach.  I
> >>do feel that this is the best way to go, though, so I'll invest some time
> >>in designing a solution based on it and resubmit my plan.
> >>
> >>Could someone point out an example of the usage of the CustomMethod
> >> logic?
> >>
> >>Thanks,
> >>
> >>Carl
> >>
> >>On Friday, March 10, 2006 02:29, Jacopo Cappellato wrote:
> >>>Carl, Adrian, Si, others,
> >>>
> >>>I'd suggest to have a look at the CustomMethod and CustomMethodType
> >>>entities (defined in the framework/common component). You could add a
> >>>"customMethodId" field to the UomConversion entity.
> >>>Then in the CustomMethod entity we simply map the logical name
> >>>(customMethodId) to the service name that implements the conversion
> >>>(customMethodName).
> >>>This pattern is already used to implement the manufacturing formulae for
> >>>bom and route calculations.
> >>>
> >>>Jacopo
> >>>
> >>>Adrian Crum wrote:
> >>>>Si,
> >>>>
> >>>>That's similar to the approach I was suggesting. I added an additional
> >>>>layer though. Your suggestion would be simpler and easier to implement.
> >>>>
> >>>>Carl,
> >>>>
> >>>>We have to convert LF to BF just like you. My suggestion was intended
> >>>>to accomodate additional UOM conversions down the road.
> >>>
> >>>_______________________________________________
> >>>Dev mailing list
> >>>[hidden email]
> >>>http://lists.ofbiz.org/mailman/listinfo/dev
> >>
> >>_______________________________________________
> >>Dev mailing list
> >>[hidden email]
> >>http://lists.ofbiz.org/mailman/listinfo/dev
> >>
> >>
> >>------------------------------------------------------------------------
> >>
> >>Index: services.xml
> >>===================================================================
> >>--- services.xml (revision 6966)
> >>+++ services.xml (working copy)
> >>@@ -248,5 +248,6 @@
> >>         <auto-attributes include="pk" mode="IN" optional="false"/>
> >>         <attribute name="originalValue" mode="IN" type="Double"
> >> optional="false"/> <attribute name="convertedValue" mode="OUT"
> >> type="Double" optional="false"/> +        <attribute name="productId"
> >> mode="IN" type="String" optional="true"/> </service>
> >> </services>
> >>
> >>
> >>------------------------------------------------------------------------
> >>
> >>
> >>_______________________________________________
> >>Dev mailing list
> >>[hidden email]
> >>http://lists.ofbiz.org/mailman/listinfo/dev
>
> _______________________________________________
> Dev mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/dev

 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev