Jade IDE

[ConvertFromOldNGs]

by Glen Richards >> Thu, 13 Sep 2001 5:07:58 GMT

Are there any plans to integrate the class browser, debugger & painter?


Glen Richards
encos Global Systems Limited

[ConvertFromOldNGs]

by vera >> Thu, 19 Sep 2002 1:05:42 GMT

Yeah, I've been asking this question to different people over last 15 months. The only response I ever got was either "what do you mean?" or "no" or just a blank expression in their faces.
I want to ask something else now. Are there any plans to bring GUI of Jade IDE up to the current industry standards of other SW development tools? Look at Delphi or Visual Studio, just examples.

[ConvertFromOldNGs]

by allistar >> Thu, 19 Sep 2002 1:08:41 GMT

What areas of the Jade IDE do you think are lacking?

The Jade development environment is a different paradigm to those
other tools which is why the IDEs differ so much (at least IMO).

Allistar.

------------------------------------------------------------------
Allistar Melville
Software Developer
Auckland, NEW ZEALAND

Greentree International,
Developer of Greentree Financial Software. ------------------------------------------------------------------

[ConvertFromOldNGs]

by vera >> Thu, 19 Sep 2002 3:33:22 GMT

I am talking about ease of use and user friendliness of Jade IDE. How easy it is to use for developers, how efficient and productive they can be with the tool. It's not about different paradigms, or different languages, it's about what today's SW developers expect from their development tools and what features they consider as standard.
For example:
- Browser, painter and debugger should be integrated (not 3 separate Windows MDI applications)
- Getting around source code is a pain. I expect features like dockable windows to organise developer's desktop, use of tabbed controls to display source code instead of multiple windows. And layout of IDE should be completely customizable.
- Definition of classes presented also in a text form (not only down to method level).
- Number of standard Jade controls is extremely low. 100+ would be much more appropriate.
- Search capability is very poor

And it would be really nice if Jade IDE "lost" its Windows 3.1 look.

Cheers,
Vera

[ConvertFromOldNGs]

by CarlRanson >> Thu, 19 Sep 2002 5:14:30 GMT

For the first time ever I feel the need to be the voice of moderation.
I agree with you that jade is not the flashest user interface out there, but I don't think its as bad as you imply.
The hard facts of the matter are that there is only a limited workforce producing the product and they can't do everything. I would much rather see functionality over form.

Further comments below:

I am talking about ease of use and user friendliness of Jade IDE. How easy it is to use for developers, how efficient and productive they can be with the tool. It's not about different paradigms, or different languages, it's about what today's SW developers expect from their development tools and what features they consider as standard.
For example:

- Browser, painter and debugger should be integrated (not 3 separate Windows MDI applications)

Personally, I can't say its ever bothered me that much. I guess it would be nice to have. (Having a dual monitor system helps a lot)

- Getting around source code is a pain. I expect features like dockable windows to organise developer's desktop, use of tabbed controls to display source code instead of multiple windows. And layout of IDE should be completely customizable.

I actually think dockable windows would be a lot more useful in the debugger than in Jade propper. You really don't have all that many non-modal windows in the development environment.

What *would* be useful is a standardisation of the different jade windows you can get. Have you ever noticed how you can print a method from the class browser but not from a list of code. ARRRGGH...why are the menus different!
Come to think of it, why do we need the schema window these days, it would be much nicer if there was a pair of combo box's in the code browser window that let you select the schema being browsed and the superSchema to show up to. The schema browser then becomes much less important.

Propper toolbar support with the ability to add things like a combobox for the current schema etc would be very useful though.

There are still a lot of things you can't reasonably do without the mouse too (try opening a browser window for a different schema for instance). c'mon Jade....how about support us elephants? (i.e. mouse phobics)

Again, i think its a question of manpower...all those fancy features don't come for free.

- Definition of classes presented also in a text form (not only down to method level).

It would be an interesting design problem to make that work....how would you suggest Jade works out whats changed?
Wouldn't it introduce lots of locking problems as the granularity of changes is a lot larger?
It would be hard work for jade to keep track of all the bookkeeping necessary if editing a whole class.

- Number of standard Jade controls is extremely low. 100+ would be much more appropriate.

I wouldn't have said that many, another 10 or so choice ones would be nice though (ie. toolbars).

- Search capability is very poor

I quite disagree. What about the ability to locate references to features/methods etc.
How about the fact that changing a control name fixes up all the references in code.

I think once you take into account that this isnt a text based system where you *have* to troll through files all the time, I would rate its search capabilities as at least "good".
Ok, it could still have some regular expression features.

[ConvertFromOldNGs]

by allistar >> Fri, 20 Sep 2002 0:44:53 GMT

I would agree with you that the IDE does what it needs to do and quite well at that.

I do however think it would be nice to be able to plug-in to the IDE, even if it is in a non-updating manner.

It wouldn't be too tricky for one of us to redevlop the IDE in Jade, unfortuantely we cannot update meta data. I wonder if we redevloped
the IDE in a read-only fashion and showed the plant what we have done whether they would be interested in taking that code and running with
it in their next version. (Having said that I am happy with the
current IDE anyway).

Regards,
Allistar.

[ConvertFromOldNGs]

by vera >> Fri, 20 Sep 2002 2:08:02 GMT

Answer to your question:
"It would be an interesting design problem to make that work....how would you suggest Jade works out whats changed? Wouldn't it introduce lots of locking problems as the granularity of changes is a lot larger?"

This is assuming that all methods for a single class are implemented in a single edit window! A fairly simple approach is have the IDE parse the source file into each method internally. Using some form of CRC/checksum calculation to compute a value for each method. When the developer selects compile, the CRC values for each method are compared to the list of values stored internally for each method when it was last compiled. The granularity of changes is still at the method level using this approach. The IDE is responsible for managing the changes to ensure the developer doesn't need to worry about it. This frees up the developer to examine the implementation of the class as a larger unit and to look for areas of similar or duplicated code in multiple methods.

[ConvertFromOldNGs]

by allistar >> Fri, 20 Sep 2002 3:21:21 GMT

You say "parse the source file into each method internally". The
source in Jade is stored in an object (specifically a JadeMathod
object). There is no "source file" as such, which is the paradigm
shift I mentioned in my earlier post.

Working out what's changed is simply a metter of stored the edition number of the JadeMethod object. At the moment Jade registers a notification against the open JadeMethod objects and that's how it
knows if someone else has just modified the method you are looking at.

Are you suggesting that a better design would be to show the code for
ALL methods for a class in one edit window at the same time? (Like in
C++ or VB?)

Regards,
Allistar.

------------------------------------------------------------------
Allistar Melville
Software Developer
Auckland, NEW ZEALAND

Greentree International,
Developer of Greentree Financial Software. ------------------------------------------------------------------

[ConvertFromOldNGs]

by CarlRanson >> Fri, 20 Sep 2002 3:39:07 GMT

Yes, i see what you're getting at but I don't think what you suggest would be sufficient.

The reason is if two people edit different methods of a class at the same time, jade then has to work out how to combine the changes.
It the same problem you have with a breifcase folder, where you have to know the timestamps of the methods involved to adequately distinguish whats changed.

I think Allistar is right in the other message, that you could substitue method editions for the timestamp in this case.

So jade connverts the complete class source to a single file, recording all of the methods involved and their editions. Then when saved its got to resolve the new/deleted and updated methods to a set of method changes and apply them.

Could be made to work I guess...still not sure I see the value in it though.

I would have thought being able to edit class properties in this way would be more useful, entering new attributes & references is a bit tiresome at times.
CR

[ConvertFromOldNGs]

by vera >> Tue, 24 Sep 2002 0:57:17 GMT

Here is the thought about ability to view and edit whole class in one edit window in more details.
-----------------------------------------------

I would like to see the current limitation of the Jade editor be removed to display and edit all methods for a class in a single editor window. The main benefits of this approach are to allow the developer to browse all code regardless of which method it belongs to. This will ensure that developers are able to look for duplicated code and to perform other refactoring functions as per the Refactoring book by Martin Fowler.

It would be necessary to provide some extra functionality behind the scenes to enable this. I can see the need for an Editor class to represent the screen view of the methods. This class could track the current method and provide notification to a class controller. The class controller is responsible for aggregating the instances of the JadeMethod class mentioned previously.

In the case of an existing method, as the user begins to edit a Jade method, the controller is notified that this method has been changed and the JadeMethod instance is updated. This forces the appropriate lock to ensure another developer doesn't try to edit the same method. Once the user is satisfied with the changes and selects save, the method is updated appropriately and the lock is removed and the "dirty" flag is reset.

If the user creates a new method, as soon as the method name is entered, the controller is notified and a new instance of the JadeMethod class is created with a state of New. The dirty flag is also set and the user continues to edit this method. The changes made on the screen are automatically passed through to the JadeMethod class to ensure it remains synchronised with the editor window.

Selecting save for the editor will notify the controller class to perform a save. The controller is responsible for iterating through each of the JadeMethod instances and performing the appropriate action. If the method has been edited, perform the save and clear the state and dirty flag. If the method is a new method then save it to the db. Ensure that any new or edited methods have the NeedsCompile flag set. This enables a single compile option to be selected for the entire class and all methods that need to be compiled can be compiled by iterating through the instances of JadeMethod(s).

The existing notification mechanism for the JadeMethod class would remain and it would also include a state (Existing, New, Edited, Deleted). If the state was changed to Edited then the appropriate lock would be required for this method from the repository. The JadeMethod would also be notified if another developer has changed the implementation. The developer would be prompted to "refresh" the source in the JadeClass instance and also notify the controller that this method has changed and to reload the source for this method into the editor. This could be an automatic process or provide a prompt to the developer to ensure they are notified of the change.

To support clipboard operations, if an entire method is cut or deleted, the controller notifies the JadeMethod instance it has been deleted by changing the state. If an entire method is pasted into the editor, the controller is notified and an instance of JadeMethod is created. If the method name matches an already existing method, I would suggest adding some form of suffix to the newly pasted method name. Obviously, this depends on where in the editor the cursor is located when the paste operation is executed. The rules of insert vs replace need to be specified to ensure the developer is aware of the impact of the operation.

The editor, controller and JadeMethod classes all send and receive notifications. This enables the appropriate lock to be acquired when the developer makes a change and also that any methods in the editor are refreshed if another developer makes a change to a method. The existing versioning mechanism is retained.

The main area that could provide some discussion is the order of the methods in the editor. I think that the methods should be grouped by scope. It may be an idea to sort alphabetically within the same scope although a tree representation allowing the developer to manually drag and drop the methods to reorder them could be nice. There would need to be some persistence for this order at the developer level as well. The reason for allowing each developer to reorder the methods is that it allows the developer to group related methods together. Obviously, every developer is not going to reorder the methods for every class in the system but it may be useful to allow each developer to carry out this function so that some classes with a lot of methods could be more logically organised.

Some thought also has to given to what constitutes a method block. For example, if a developer places comments prior to the method name then this should be treated as part of the method implementation. A convention of a single blank line between methods would be sufficient to clearly show each method.