Promopted by discussions about the existance of other framework examples, but with no code published at the time, and a personal gripe with Siebel in the way that scripting can, at times, be a little clunky. I looked at code and noticed that quite often a good chunk of what we write is to do with the "plumbing", rather than the actual logic. In a few cases what we're attempting to do has 4 or 5 lines of the plumbing code, and the important bit is buried amongst this in a single line. Another problem I saw was the repetion - while C++, Java, even JS offer many ways to write once, use many times, I noticed that the same logic gets written over and over - even simple things - looking up field values on LOVs, manipulating dates.
I thought I'd try to come up with my own take on the idea.
Some issues/thoughts I had along the way:
1. whatever way the Framework was implemented should not be version dependent, or depend on either the T or ST engine
2. make it easier to do repeat tasks
3. should work with existing code, not just greenfields - for me attaching code to Array or Object prototypes wasn't ideal as existing code that used for...in would return extra elements
4. memory use
5. speed - as the Framework code is generic it is generally longer than the equivalent original - so it shouldn't have a noticeable performance hit
6. should offer both browser side and server side functions: on the browser side things that are trickier than they should be (get an LOV, get a system preference, even get a field value) should be simplified
7. could use JS objects to offer rich features
There are 4 parts to this that will be posted - server script from a business service (which is the bulk of the framework), browser script from the business service (offers a cut down feature set in brower script), applicaion server script - a call to create the framework, application browser script - a call to create the browser side framework.
I'll post these up initially, then will add discussions to various apects of the framework and the approach later.
Matt
Hi Matt,
ReplyDelete"Whatever way the Framework was implemented should not be version dependent, or depend on either the T or ST engine"
You have type casted the BO and Bc's in your framework which means this cannot be used in application using T engine.
But it is really amazing. Hats off to you for pulling this off and be kind enough to share with us all.
I guess the only thing missing in this is method chaining .. that will be like cherry on top.
Great work!!!
Matt,
ReplyDeleteWhere should I able to download this framework. I would like to try this. Please let me know, if you would be able to share this.
Thanks,
Ajay
Hi Neel,
ReplyDeleteThanks for the comment - you're right about the typing - the code as written would only work in ST - so I'll correct this to make suitable for either T or ST engines.
What advantages do you think method chaining would add?
Matt