Thursday, June 17, 2010

Introduction

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

3 comments:

  1. Hi Matt,

    "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!!!

    ReplyDelete
  2. Matt,
    Where 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

    ReplyDelete
  3. Hi Neel,

    Thanks 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

    ReplyDelete