by vera >> Tue, 24 Sep 2002 0:57:59 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.