CodeEditor versioning support

When I made a CodeEditor demo to Berkay who is the director of the IFountain, he suggested me to add versioning support to CodeEditor.  At IFountain we develop integration tools for IT departments. The main tool we focused is RapidInsight. It is implemented on the top of Grails Framework with a lot of modifications. It has a lot dynamic features.  This is because of the variability of customer requirements. We are integrating with a lot of different systems and we need to create appropriate models and appropriate integration scripts for our customers. Actually, technical customers can do scripting and other integration modifications easily in RapidInsight but first they have to know Groovy little bit.

When we deployed RapidInsight to any production environment, we change the main product and modify models or some scripts according to customer needs (and of course we use CodeEditor to make these changes). However, after a short time changes applied to main product are forgotten. And if we want to rollback changes and return to any of previous point, we should remember all the changes we made. This is very error prone. If you can not remember a change, you may introduce a bug. The versioning support will help users in situations like this.

Some of the expected features of CodeEditor versioning system may be listed as:::

• Users will be able to edit the code freely, these changes will not be applied to working copy till they commit these changes.
• When user commits the changes, they will be applied to main product
• Multiple users will be able to edit same file at the same time. However, if any conflict occurs, it is their responsibility to resolve these conflicts
• Users will be able to return back to any version. All of the changes applied to working copy will be rolled back.
• Users will be able to customize versioning mechanism. A default implementation (File based or embedded versioning system) will be distributed with plugin and users will be able to customize from a file located under services directory.

All of these features, will make CodeEditor benefical for all Grails Application. I am planning to implement and release it with the next version of CodeEditor.

CodeEditor 0.2.4 is Released!

CodeEditor 0.2.4 is released.

• Several UI bugs are fixed and UI performance is improved (upgraded to EditArea 0.8.1.1 )

• Action execution mechanism and console view to see result of these actions is added. You can reload controllers/filters and etc after editing its content from CodeEditor ui. There are default actions and you can customize actions to be executed from services/CodeEditorActionService.groovy file. Actions will be visible in Exec combo box in toolbar according to configured context.

• Default suggestion injection mechanism added to show dynamically injected methods in code completion. A default implementation is added you can customize and any method and property suggestion using conf/GroovyDefaultSuggestionConfig.groovy file
• Gsp code completion support is added.

You can download it from http://grails.org/plugin/code-editor. Documentation of these features did not finished yet. I will write a detailed documentation soon.

Also, in the next version version control system support will be added. It will help users to manage changes in production environments.

Why to use CodeEditor in Grails Applications?

Currently, There are many perfect IDEs  (Eclipse, IDEA, NetBeans) for groovy/grails project which has code completion, code refactoring, code formatting, syntax coloring and etc. So why developers need a tool like CodeEditor plugin?

1. It has no setup step. It is a simple grails plugin. You can install it onto any grails application.
2. It is accessible from web. You can work with CodeEditor in almost every browser.
3. You don’t need to forward any ports except the HTTP port.
4. You can edit a file and execute related actions with that file. For example if it is a controller you can reload controller and change the application behavior without reloading the whole application.
5. You don’t need to download/upload your code to change.
6. In many production environments accessing the server directly is not possible. CodeEditor enables users to access code without granting any access rights to server.
7. You can control whole application from CodeEditor menus including reloading and applying current changes. Executing other commands which can be configured in grails-app/services/CodeEditorActionService.groovy.
8. CodeEditor has code completion support. You can develop your code by the help of CodeEditor code completion suggestions easily.  Currently, only groovy files has code completion support but I am planning to add gsp, javascript and xml code completion features.

In near feature I want to add go to declaration tool, code formatting and simple code refactoring support.

CodeEditor Exec tool

In Grails there are two main environments which are development and production. Development mode is able to reload changes dynamically but it is slow when it is compared with production mode since for every file it checks whether it has changed or not. Therefore, most commonly a real life applications will be deployed in production mode.  If this is correct why do we need CodeEditor? For this purpose (To make CodeEditor a benefical tool for users :)) I decided to add capability to add actions to reload selective parts of application such as controllers, views, filters and etc. Action can be added and configured from CodeEditorActionService and the visibility of each of this tool from ui will be dependent configuration of the tools in the configuration section of the service. In configuration section user will be able to add tools and should specify displayName of the tool and the regular expression which will be evaluated by javascript code to find files which this tool will be shown.

As an example scenario think that you changed the code of controller and you want to apply this change to application. The only thing you should do is that executing Reload Controllers from Exec menu (See below image). The current file name will be passed to CodeEditorActionService corresponding tool method and since I developed reloading controllers, the change you made to controller will be loaded.

public class CodeEditorActionService
{
    boolean transactional = false
    def actionConfigurationMap = [
            reloadControllers:[displayName:"Reload Controllers", filters:[".*controllers/.*\\.groovy"]],
            reloadFilters:[displayName:"Reload Filters", filters:[".*/grails-app/conf/.*Filters\\.groovy"]],
            reloadViews:[displayName:"Reload Views", filters:[".*\\.gsp"]]
    ]

    def reloadControllers(params){
        PluginManagerHolder.getPluginManager().getGrailsPlugin("controllers").checkForChanges()
    }

    def reloadFilters(params){
        PluginManagerHolder.getPluginManager().getGrailsPlugin("filters").checkForChanges()
    }

    def reloadViews(params){
        GroovyPagesTemplateEngine.pageCache.clear();
    }
}

CodeEditor: IDE for GRAILS applications

I am working on a plugin named CodeEditor for Grails Framework. I planning this plugin to be a full featured development environment for grails application in both development and production environment. Users will be able to edit their code (java, groovy, gsp, jsp, html, xml, js and etc…) from the web.

The main force behind me to implement this plugin is that, personally I don’t like to edit something which is deployed in production environment in unix based text editors such as vii, pico, nano, emacs and etc. First of all accessing these editors requires login to the server using any SSH or telnet utilities. For many servers in customer environments this is not possible since network administrators will not happily provide this level of access rights to their production environments. Therefore, it is hard to access the files you need to change.  Finally, For me UNIX based editors are very hard to use. Graphical edit tools are much easier to use.

The second point is that syntax coloring depending on the the file being edit and code completion support is very  important in development process. Most of UNIX based or WINDOWS editors have no syntax coloring and other features which are very crucial for developers. These features ease the development process and decrease the probability of bugs in code.

Providing all of these capabilities from the web is my main goal while developing CodeEditor for Grails. I will continue to develop. I am planning to add many more functionality. Currently code completion is only supported for groovy files. I will add this feature for JavaScript and Xml files too. There are some minor bugs in the editor, I will try to fix these and improve user interface. Also, in IDE tools which I have used while developing groovy/grails application, I could not see any code completion feature for dynamically injected code. I will try to support this type of functionality in CodeEditor.  Users will be able to add some default methods and properties from a configuration file and these methods will be shown in code completion.