Adding parallel/new Forms and Objects to a Jetted system

[ConvertFromOldNGs]

by Anonymous >> Thu, 8 Apr 2004 19:50:07 GMT

As a relatively new user (we are converting a LINC system to Jade with Jet), it is fairly clear that we would like to add new features and functions to our Jetted system WITHOUT using Jet styles of code (to take advantage of efficiency of OO and use the tool as it is designed best to be used).

I am wondering if there are methods of development that your organization has tried and either been successful or dreadfully failed in using. So, using these assumptions:
1) The converted classes (Model and View) are valid
2) New Model and View classes and forms need to be developed and refer to or update existing objects.
3) New Model and View classes need to be developed that create new objects (I.E. Objects not Jetted).
4) Time is important so rewriting the existing system is not appropriate.

What sucess stories or failed efforts (don't do it this way!) can you share to give some guidance to some neophyte developers?

[ConvertFromOldNGs]

by cnwmjn1 >> Wed, 14 Apr 2004 5:31:18 GMT

I have had a good deal of experience over a number of years now in maintaining Jetted systems. With one of these systems in particular we have done a large amount of maintenance and development including:

1. Re-writing a complete module WITHOUT using Jet styles of code
2. Modifying existing forms and reports using Jet styles of code
3. Changing some segments of Jet style code to a non-Jet style to gain efficiencies
4. Writing new forms using non-Jet styles of code and integrating these with the existing Jetted forms
5. Maintaining Jet style code for bug fixing and minor enhancements.
6. Writing complete new modules WITHOUT using Jet styles of code where these had there own new data structures as well as sharing some of those from the Jetted system

As you will see from the above, this convers just about every way in which a system could be modified, short of completely re-writing it.

It is very difficult to make generalised statements that you should use or avoid specific methods of development because it really depends on what you are trying to achieve. Also your methods will be determined somewhat by your attitude to whether you wish to retain the same "look and feels" as your Jetted system, or whether you take the opportunity to begin moving from that to a new style.

Perhaps if you have some specific examples you could communicate directly with me and I can answer some of your questions/concerns.

Regards
Murray Neilson

[ConvertFromOldNGs]

by Stuart R >> Thu, 15 Apr 2004 14:24:29 GMT

Murray,

Thanks for your response. It is refreshing to know (as I suspected) that others have trudged this path before. As we are moving down this road, we also are seeing glimmers of hope in several of the areas that you mentioned. In particular, we will be adding functionality (either new forms or new modules) in non-Jet methodology.

Of course, we will be needing to access much of our existing data so we will be adding more appropriate collections rather than the global collections that Jet created.

As for look and feel, we are definitely expecting that new development will NOT look like the existing Jet system (not a negative about Jet, just a reality of making the product look more attractive to our PC based audience).

So, of most importance, you have provided reassurance that you can have a Jet system and nonjetted code co-exist. That is a different reaction than what we had received from an Aoraki source and it is nice to nice that there can be a light at the end of a shorter tunnel than we originally envisioned.

As we encounter specific issues, I will contact you (and try to keep the issues succinct and answerable). Thanks for your offer of guidance.

[ConvertFromOldNGs]

by cnwmjn1 >> Fri, 16 Apr 2004 2:02:48 GMT

Stuart

Just to pick up on one of your comments re collections. It is not too difficult to move the collections from where they were put by the Jet process, and this can actually benefit the existing Jetted code in some instances.

The Jet process takes a "safe" approach because the jet team has little or no detailed knowledge of your application. This can result in some collections being placed where they are not as efficient as they could be while at the same time faithfully replicating the Linc functionality. Moving these collections can be very beneficial and will generally require very little modification to existing application code.

Cheers
Murray

[ConvertFromOldNGs]

by Rob B >> Fri, 16 Apr 2004 4:29:16 GMT

A few small points from my own experience:

Invest up front in some design and coding standards for non-jet development, e.g. a model/view/agent structure. Define a strategy - ideally incremental - to take your user interface forward.
Encourage developers to think about encapsulation
- define and use rules defined on business objects, not on glb.
- similarly, define utility methods on the relevant primitive, not on glb, - use class rather than global variables.
Encourage passing of parameters to methods, rather than method calls that expect properties on glb to be set up.
Strongly discourage the copy/paste style common to jetted methods, and even invest in rationalising some of these, especially where business rule definitions are repeated.

Cheers,
Rob

[ConvertFromOldNGs]

by cnwjhp1 >> Fri, 16 Apr 2004 9:23:50 GMT

Stuart,

It would be fair to say that most Jet clients start out with plans for refactoring or gradual rewriting. It would also be fair to say that most of them in the end decided that Jetted code isn't so bad to maintain after all, and it isn't worth a lot of effort to change it all over. After all, it works.

As Murray indicated, there are a variety of options, which to me is part of the appeal of Jetting. If you make a small change to business rules, you can copy and paste existing Jet code, or add new stuff using the usual Jet conventions. If you add a new functional area, you can make a clean break and use non-Jet methodology, with or without using legacy persistent data.

As Rob said, it pays to keep the overall architecture in mind. An example from my experience - if you marry Jet and non-Jet styles at runtime in the same app, eg a fancy front-end (with persistent updates) with calls to updating ispecs behind it, make sure you work in with the ispec transaction commit cycle. Otherwise you could end up holding locks when the user is idle. It's no reason not to do it though - you just have to keep the overall architecture in mind when you do.

No problem adding new inquiry gui or search screens to the same app. You can also do quickpads, hotkeys and other things to improve navigation that you couldn't do before.

Jet has to be very careful to do a line-by-line emulation. When you had to do something the hard way before, Jet will faithfully reproduce this the hard way, in order to ensure the same results. A little application knowledge here can reap huge improvements. I addressed one glg that used sd groups, arrays and loops to do capitalisation of customer names. A fairly painless rewrite into pure Jade (with a little application knowledge) made it 1000 times faster. Murray has also told such stories, and I'm sure most Jet clients have done this. No need to do this to every ispec and glg though, unless you have a lot of time on your hands.

Cheers,
John P