new jade user seeks help

[ConvertFromOldNGs]

by Leisa Armstrong >> Tue, 13 Feb 2001 0:55:37 GMT

Hi everyone, especially all my NZ friends. I have just started to learn Jade. If any of you guys have some got example of web applications, shopping I would appreciate a copy of your schemas
Thanks
Leisa
ps I have version 5.1.07 of Jade



--
Dr Leisa Armstrong
School of Computer and Information Science
Edith Cowan University
Bradford St
Mt Lawley
ph 0409 031 538

[ConvertFromOldNGs]

by Dean Cooper >> Tue, 13 Feb 2001 6:14:33 GMT

The JADE Discovery Kit contains an example demo system that implements a standard client and web interface. If you haven't already got the discovery kit, you can download it from:

news.jadeworld.com/jade/jdkit.htm

As you've already got 5.1.7, you don't need to download the whole kit (which includes an evaluation copy of JADE). Just download the modules that you want.

Dean.

[ConvertFromOldNGs]

by Paul Mathews >> Sun, 18 Feb 2001 14:04:20 GMT

It is good that there is a demostration as Dean points.

The following is some feedback I gave Dean on the Erwhon Investments application, on the 26th of April 2000.

So these comments may be out of date.
=================================================================================================== Thanks Dean for sharing your expertise on the the Erwhon Investments application.

There is one major area which I feel is overcomplicates matters quite
a bit.

That is the use of the Activity Agent and it's implementation, TransactionAgent and ValidationAgent.

eg Looking at the Agent Class for example there are the following methods.
TransactionAgent.trxCreateAgent(agentName,address1,address2,address3,phone,fax,email,webSite,agentNew Output
TransactionAgent.trxDeleteAgent(Agent io) TransactionAgent.trxUpdateAgentagentForUpdate,agentName,address1,address2,address3,phone,fax,email,webSite) ValidationAgent.valCreateAgent(agentName,address1,address2,address3,phone,fax,email,webSite)
ValidationAgent.valUpdateAgent(agentForUpdate,agentName,address1,address2,address3,phone,fax,email,webSite)
Company.createAgent(agentName,address1,address2,address3,phone,fax,email,webSite)
Agent.createEntity(agentName,address1,address2,address3,phone,fax,email,webSite, company) Agent.update(agentName,address1,address2,address3,phone,fax,email,webSite)

1) There are 7 methods with a similar set of parameters which have to
be updated any time a parameter is added/changed/deleted.

Using the existing approach this could be simplified by
1) removing:
ValidationAgent.valCreateAgent
ValidationAgent.valUpdateAgent
Company.createAgent
Agent.createEntity
2) i)renaming/changing Agent.update to Agent.setAgent which now is
passed it Parent (currently Company)
ii) All validation Code is now also within this one method. Agent.setAgent(agentName,address1,address2,address3,phone,fax,email,webSite,myParent)

The Interim outcome is now:
TransactionAgent.trxCreateAgent(agentName,address1,address2,address3,phone,fax,email,webSite,agentNew Output
TransactionAgent.trxDeleteAgent(Agent io) TransactionAgent.trxUpdateAgent(agentForUpdate,agentName,address1,address2,address3,phone,fax,email,webSite) Agent.setAGent(agentName,address1,address2,address3,phone,fax,email,webSite,myParent)

If one looks at the code where TransactionAgent.trxCreateAgent and TransactionAgent.trxUpdateAgent are used.
Both methods are not required only TransactionAgent.trxUpdateAgent.
When need to create, null is passed across.

Hence without changing the approach of an ActivityAgent, the number of methods that need to be maintained has been reduced signicantly and provides for future flexibility (changing myParent latter to another Class).

The Final outcome is now:

TransactionAgent.trxDeleteAgent(Agent io) TransactionAgent.trxUpdateAgent(agentForUpdate,agentName,address1,address2,address3,phone,fax,email,webSite) Agent.setAGent(agentName,address1,address2,address3,phone,fax,email,webSite,myParent)

1) For people new to Jade I think they will find this easier to understand.
2) Using this approach it is easier for setMethods to inherit Valid/Updating code when classes are subclassed.
3) When a setMethod updates/creates instances in other Classesall
error handling is encapsulated as other setMethods are called.

PS I may have missed something, but an example of a destructor method
I believe would also be usefull.
A new Exception Class, DeletionException (under NormalException Class)
is added, etc.
eg

delete() updating;

// Date: 19 January 1999
// User: paulm
// Copyright: C&M Systems Group
begin

if app.massDelete = false then// No validation check when
doing massDelete
if allCMLists.size > 0 then
DeletionException.raise_(64000,'Cannot Delete,
Children still exist');
endif;
endif;
end;

Paul Mathews
pem@cmsystemsgroup.com.au
Phone: [612] (99717384) Fax[612] (99711679)
(Dee Why,Sydney,Australia)

[ConvertFromOldNGs]

by Torrie Moore >> Sun, 18 Feb 2001 20:15:03 GMT

I disgree with the approach of using the same method to initialise and update and object. There is a difference between creating an object and updating its properties. There are things that are only done when creating and object, such as assigning a unique identifier (separate to the oid). Some attributes may not be able to change once assigned like an invoice number. The code should reflect this. Although Pauls method results in less methods some complexity has been added within the Agent.setAgent method.

Torrie Moore
torrie.moore@computer.org

[ConvertFromOldNGs]

by Craig Shearer >> Mon, 19 Feb 2001 19:04:38 GMT

Hear hear!

I would certainly agree that there must be a distinction between create and update. Too many JADE systems are written in this way - I think it is a hangover from certain poor practises shown in the initial JADE training courses. Perhaps they are still teaching this way

However, I think that the whole approach of TransactionAgent and ValidationAgent is overkill and leads to cumbersome coding, and it's also difficult to maintain as Paul has said. Basically, I object to having to pass stuff around so much, which you have to do using this approach.

While I think that the typical method of placing all transaction code on forms in control event methods is pretty loose, there are other solutions to the problem. In all my systems, I have an invisible control painted on forms that is responsible for all code - and it has events that fire which the developer implements to do all the stuff required. The main advantage of this is that it provides a standard interface for writing maintenance code, and that all the references to controls etc. are kept on the form where they belong.

Just my 2 cents worth

Craig.

[ConvertFromOldNGs]

by Robin Arzoni >> Mon, 19 Feb 2001 22:20:55 GMT

I find that transaction agents are excellent for implementing code that may need to be called in many different contexts: that is, not only from a standard maintenance form, but also from a separately-spawned application, or from a JadeScript. The effort that you put into writing the agent is repaid many times over if you find that you need to perform the same transaction in different circumstances.

It's certainly true that you need to pass a lot of parameters around, but I think this disadvantage is outweighed by the benefits of encapsulating a complex transaction in a single method call. That single call also returns an error number which, if non-zero, can reflect any exception or locking problem that occurred while the method was executing.

Agents are especially useful if you're creating or updating objects that have complex relationships with other objects; for example, where a change to the main object's name may require recursive renaming of its dependants. By packaging the operation into one method, you can guarantee that all the updates either succeeded or failed.

Robin

[ConvertFromOldNGs]

by Craig Shearer >> Mon, 19 Feb 2001 23:24:36 GMT

I find that transaction agents are excellent for implementing code that may need to be called in many different contexts: that is, not only from a standard maintenance form, but also from a separately-spawned application, or from a JadeScript. The effort that you put into writing the agent is repaid many times over if you find that you need to perform the same transaction in different circumstances.

I definitely agree that this is the case where you want to perform the same sequence of actions in a transaction from multiple places - for example, you have several forms that update a customer object. Rather than copying and pasting the same code in several places, then putting this into a separate class is highly advantageous.

However, as you state, there is significant overhead in writing these classes. In my experience, there are usually few cases in a system where this sort of functionality needs to be duplicated and hence these controller classes are justified. The Erewhon system seems to be advocating, as best practice, having ALL transactions performed by these TransactionAgent classes. On this point I disagree.

It's certainly true that you need to pass a lot of parameters around, but I think this disadvantage is outweighed by the benefits of encapsulating a complex transaction in a single method call. That single call also returns an error number which, if non-zero, can reflect any exception or locking problem that occurred while the method was executing.

Agents are especially useful if you're creating or updating objects that have complex relationships with other objects; for example, where a change to the main object's name may require recursive renaming of its dependants. By packaging the operation into one method, you can guarantee that all the updates either succeeded or failed.

Again, I agree entirely where the situation warrants it. I just don't agree that sledgehammers need to be used to crack nuts!

Craig.

[ConvertFromOldNGs]

by Don Rae >> Tue, 6 Mar 2001 3:14:22 GMT

I would certainly agree that there must be a distinction between create and update. Too many JADE systems are written in this way - I think it is a hangover from certain poor practises shown in the initial JADE training courses. Perhaps they are still teaching this way

The team involved in developing and delivering JADE training have discussed this issue, and acknowledge the feedback (thank you Craig).

Up until now, the JADE Developer's Course has taken a simple approach to this, and some other 'best practice' issues; for example file naming conventions. Simple approaches are required early on, especially given the large amount of new concepts and material that many face when taking their initial course. However, the Advanced JADE Course does re-address a number of best practice aspects of using JADE, and certainly revisits the matter under discussion.

One source of 'best practice' that we are incorporating is the recommendations in the JADE Discovery Kit: specifically "Part 4. Design Considerations" of the DemoSystem.pdf. Dean Cooper, the author of the demo system, modestly refuses to refer to his Design Considerations as 'best practice', preferring 'good practice'. There is a discussion on the separation of creates from updates in that document.

When teaching any subject at introductory level as per the JADE Developer's Course, the material can seem simplistic when viewed with the wisdom of experience and hindsight. However, simplicity is an essential quality for new learning: an analogy may be where one is learning to drive. The beginner driver is taught to control their car, and understand the road rules without having an understanding of how to produce a controlled four-wheel drift at 260 k/ph. Later, as the driver becomes more expert, the techniques initially learned may no longer be 'best practice', and may indeed be counter productive to expert performance. You still don't start by learning the 260 k/ph four-wheel drift!

In summary:
- we are aware of the criticism, and are revisiting course materials accordingly, particularly the JADE Developer's Course
- we are in process of gathering requirements for a JADE Design Course
- the online tutorials and Discovery Kit will also be reviewed re 'best practice' issues

[ConvertFromOldNGs]

by Paul Mathews >> Mon, 19 Feb 2001 16:19:47 GMT

1) This approach does not inhibit the use of the constructor method
but be wary when reloading data it is not incorrectly called.

2) Data via if then else statements enables one to have the one method
to maintain but different logic for create and update.


Paul Mathews
pem@cmsystemsgroup.com.au
Phone: [612] (99717384) Fax[612] (99711679)
(Dee Why,Sydney,Australia)