simple method subsections
Locked
 
|
I'm looking for some feedback on an idea I'm tossing around
Problem: When creating a custom application, often times you will be creating business logic that is exactly like what is in OFBiz but needs to be slightly modified before sending it to the entity engine for storage or before creating a result. (changing the way a price is calculated, adding specialized field information, etc). It would helpful to be able to call the OFBiz maintained method and then extend it through a custom call. A couple ideas on how to accomplish this 1) Add two new element groups, <section-begin> <section name="sectionA"/> </section-begin ...some logic... <section-end> <section name="sectionA"/> </section-end> ...more logic... and salt the ofbiz method so that you can pull only the logic between the two 2) mimic the screen-widget's decorator pattern 3) add a map of simple-methods to the method's context that allows running extended code extendMethod.myLocation#myMethod and then salt the ofbiz method to call if it exist. TIA for any thoughts ,Chris |
|
|
Chris Howe wrote:
> Problem: When creating a custom application, often times you will be creating business logic that is exactly like what is in OFBiz but needs to be slightly modified before sending it to the entity engine for storage or before creating a result. (changing the way a price is calculated, adding specialized field information, etc). SECAs? They can be triggered pre-commit. |
|
|
In reply to this post by cjhowe
The problem isn't just for entity operations, but also for adding/modifying lists and maps that will end up returning a result for screen display or before passing onto another service.
----- Original Message ---- From: Adrian Crum <[hidden email]> To: [hidden email] Sent: Thursday, November 15, 2007 11:02:57 AM Subject: Re: simple method subsections Chris Howe wrote: > Problem: When creating a custom application, often times you will be creating business logic that is exactly like what is in OFBiz but needs to be slightly modified before sending it to the entity engine for storage or before creating a result. (changing the way a price is calculated, adding specialized field information, etc). SECAs? They can be triggered pre-commit. |
|
|
In reply to this post by cjhowe
Chris,
Have a look at a thread I started at http://www.nabble.com/forum/ViewPost.jtp?post=10803536&framed=y . You also responded to that thread too. When you say "extend" a simple method, it might be easier to simply think of how you would extend a Java method. We would create a new method that first calls the old method, and then perform some custom actions after that (or the order could be flipped). Your suggestion with "selective reuse of parts of a simple method" would mean changing the original method (by inserting <section-begin> <section-end>), to "generic-ize" the original method. Then you might as well not call it "extension", but "customization" or "enhancement" or "refactor" instead. In that thread I pointed to, I had implemented a <call-simple-method-scoped> which allows simple methods to call other simple methods *exactly like how Java methods can call other Java methods*. Unfortunately, the client I worked for now has exclusive rights to that new and convenient artifact. :/ So what's the problem of having simple methods call other simple methods now, you may ask? Scope is all mixed up into a single bowl of alphabet soup, single namespace. For those of us who know Java (or C or VB or just about any programming language at all), we know this isn't conventional, barely "right". To offer a solution to your question, I've found that the only way to call other methods in Minilang with proper scope (stored in call stack) is to use the Service Engine. Yeah, it means that for every simple method you want to call, wrap them in a service and call the service instead. Jonathon Chris Howe wrote: > I'm looking for some feedback on an idea I'm tossing around > > Problem: When creating a custom application, often times you will be creating business logic that is exactly like what is in OFBiz but needs to be slightly modified before sending it to the entity engine for storage or before creating a result. (changing the way a price is calculated, adding specialized field information, etc). > > It would helpful to be able to call the OFBiz maintained method and then extend it through a custom call. > > A couple ideas on how to accomplish this > 1) Add two new element groups, > <section-begin> > <section name="sectionA"/> > </section-begin > ...some logic... > <section-end> > <section name="sectionA"/> > </section-end> > ...more logic... > > > and salt the ofbiz method so that you can pull only the logic between the two > > 2) mimic the screen-widget's decorator pattern > > 3) add a map of simple-methods to the method's context that allows running extended code > extendMethod.myLocation#myMethod > > and then salt the ofbiz method to call if it exist. > > > TIA for any thoughts > > ,Chris > > > |
|
|
In reply to this post by cjhowe
Thanks for the reply. Scope isn't my problem. My problem is a trade-off between code reuse and performance. Lets say I'm doing one of the recursive party relationship services that returns a list of related parties, but I also need to run the partyNameForDate service before adding it to the list and I need to sort by name before displaying it on the screen. My choices are either to bring he recursion service into my custom application and make the minor modification or to iterate back through the list adding the result of the service and then sorting.
----- Original Message ---- From: Jonathon -- Improov <[hidden email]> To: [hidden email] Sent: Thursday, November 15, 2007 9:38:42 PM Subject: Re: simple method subsections Chris, Have a look at a thread I started at http://www.nabble.com/forum/ViewPost.jtp?post=10803536&framed=y . You also responded to that thread too. When you say "extend" a simple method, it might be easier to simply think of how you would extend a Java method. We would create a new method that first calls the old method, and then perform some custom actions after that (or the order could be flipped). Your suggestion with "selective reuse of parts of a simple method" would mean changing the original method (by inserting <section-begin> <section-end>), to "generic-ize" the original method. Then you might as well not call it "extension", but "customization" or "enhancement" or "refactor" instead. In that thread I pointed to, I had implemented a <call-simple-method-scoped> which allows simple methods to call other simple methods *exactly like how Java methods can call other Java methods*. Unfortunately, the client I worked for now has exclusive rights to that new and convenient artifact. :/ So what's the problem of having simple methods call other simple methods now, you may ask? Scope is all mixed up into a single bowl of alphabet soup, single namespace. For those of us who know Java (or C or VB or just about any programming language at all), we know this isn't conventional, barely "right". To offer a solution to your question, I've found that the only way to call other methods in Minilang with proper scope (stored in call stack) is to use the Service Engine. Yeah, it means that for every simple method you want to call, wrap them in a service and call the service instead. Jonathon Chris Howe wrote: > I'm looking for some feedback on an idea I'm tossing around > > Problem: When creating a custom application, often times you will be creating business logic that is exactly like what is in OFBiz but needs to be slightly modified before sending it to the entity engine for storage or before creating a result. (changing the way a price is calculated, adding specialized field information, etc). > > It would helpful to be able to call the OFBiz maintained method and then extend it through a custom call. > > A couple ideas on how to accomplish this > 1) Add two new element groups, > <section-begin> > <section name="sectionA"/> > </section-begin > ...some logic... > <section-end> > <section name="sectionA"/> > </section-end> > ...more logic... > > > and salt the ofbiz method so that you can pull only the logic > > 2) mimic the screen-widget's decorator pattern > > 3) add a map of simple-methods to the method's context that allows running extended code > extendMethod.myLocation#myMethod > > and then salt the ofbiz method to call if it exist. > > > TIA for any thoughts > > ,Chris > > > |
|
|
Are you suggesting something like abstract classes in Java, where some methods are implemented and
some are not (blanks to be filled)? Parameterized simple methods. Sounds interesting. Some effort is needed to refactor the existing "OFBiz maintained" simple methods to publish such "hooks" where you can insert your own custom logics. Because that kind of elegant refactor takes time, it is often easier to just hack it and get the job done. Unless we can identify numerous use cases for such elegant mechanisms, there's little ROI in doing such fanciful stuff. > My choices are either to bring he recursion service into my custom > application and make the minor modification or to iterate back > through the list adding the result of the service and then sorting. I would just reuse the recursion service "as is", and go through the list with some after-processing. Maximize reuse, minimize maintenance cost. Project time frame is seldom less than cruel! If that ever becomes a performance bottle-neck, I'll then do something about it. Jonathon Chris Howe wrote: > Thanks for the reply. Scope isn't my problem. My problem is a trade-off between code reuse and performance. Lets say I'm doing one of the recursive party relationship services that returns a list of related parties, but I also need to run the partyNameForDate service before adding it to the list and I need to sort by name before displaying it on the screen. My choices are either to bring he recursion service into my custom application and make the minor modification or to iterate back through the list adding the result of the service and then sorting. > > ----- Original Message ---- > From: Jonathon -- Improov <[hidden email]> > To: [hidden email] > Sent: Thursday, November 15, 2007 9:38:42 PM > Subject: Re: simple method subsections > > > Chris, > > Have a look at a thread I started at > http://www.nabble.com/forum/ViewPost.jtp?post=10803536&framed=y . You > also responded to that > thread too. > > When you say "extend" a simple method, it might be easier to simply > think of how you would extend > a Java method. We would create a new method that first calls the old > method, and then perform some > custom actions after that (or the order could be flipped). > > Your suggestion with "selective reuse of parts of a simple method" > would mean changing the > original method (by inserting <section-begin> <section-end>), to > "generic-ize" the original > method. Then you might as well not call it "extension", but > "customization" or "enhancement" or > "refactor" instead. > > In that thread I pointed to, I had implemented a > <call-simple-method-scoped> which allows simple > methods to call other simple methods *exactly like how Java methods can > call other Java methods*. > Unfortunately, the client I worked for now has exclusive rights to that > new and convenient > artifact. :/ > > So what's the problem of having simple methods call other simple > methods now, you may ask? Scope > is all mixed up into a single bowl of alphabet soup, single namespace. > For those of us who know > Java (or C or VB or just about any programming language at all), we > know this isn't conventional, > barely "right". > > To offer a solution to your question, I've found that the only way to > call other methods in > Minilang with proper scope (stored in call stack) is to use the Service > Engine. Yeah, it means > that for every simple method you want to call, wrap them in a service > and call the service instead. > > Jonathon > > Chris Howe wrote: >> I'm looking for some feedback on an idea I'm tossing around >> >> Problem: When creating a custom application, often times you will be > creating business logic that is exactly like what is in OFBiz but needs > to be slightly modified before sending it to the entity engine for > storage or before creating a result. (changing the way a price is > calculated, adding specialized field information, etc). >> It would helpful to be able to call the OFBiz maintained method and > then extend it through a custom call. >> A couple ideas on how to accomplish this >> 1) Add two new element groups, >> <section-begin> >> <section name="sectionA"/> >> </section-begin >> ...some logic... >> <section-end> >> <section name="sectionA"/> >> </section-end> >> ...more logic... >> >> >> and salt the ofbiz method so that you can pull only the logic > between the two >> 2) mimic the screen-widget's decorator pattern >> >> 3) add a map of simple-methods to the method's context that allows > running extended code >> extendMethod.myLocation#myMethod >> >> and then salt the ofbiz method to call if it exist. >> >> >> TIA for any thoughts >> >> ,Chris >> >> >> > > > > > |
«
Return to OFBiz - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |