Posts tagged ‘plugin’

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.


May 27, 2009 at 9:35 pm Leave a comment

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 )
  • 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 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.

May 27, 2009 at 10:39 am Leave a comment

Log management in Grails Applications (Easy log management and continuous log viewing)

To me one of the most important features of the Grails is the ability to change application behavior in the runtime (We can reload application, controller, filters, gsp files and etc). Hence to change the code, to see the log files,  to back up logs, we need direct application server access. We use telnet, a lot of ssh utilities, or if we have direct access to server machine we can use file explorer and utilities on the machine. However, if we don’t have any of these tools or if we don’t have any direct access to machine, we are stuck.

Nowadays I am really curious about whether we can manage the whole application from the web without server access to solve the above problem. To do this, I started to implement CodeEditor. It goes fine and I will ad many more features to CodeEditor. But, I also think that managing logging mechanism of application is as important as to be able to change code from the web. So, I started to implement another plug-in which is called as LogManager.

LogManager will have the following functionalities:

  1. LogManager will have a viewer which is like UNIX tail tool which continuously follows specified file and it print any characters added to to file to screen. LogManager viewer will do the same functionality for Grails application log files. Users will be able to select a log file and file content will be sent to users viewer from server-side. Log file will continuously be polled and any change in the log file will be sent to user.
  2. LogManager will be able to roll any log file at any time.
  3. LogManager will be able change a lot of logging setting (setting log levels, adding/removing log appenders, etc.)
  4. LogManager will persist all of the settings.

I already implemented and finished item 1 and 2. Soon, I will release this plug-in with these functionalities. Later, I will implement item 3 and 4.

April 8, 2009 at 10:46 am 2 comments

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.

Exec Menu

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){

    def reloadFilters(params){

    def reloadViews(params){

March 25, 2009 at 10:57 pm Leave a comment

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.

March 25, 2009 at 7:13 am Leave a comment

My Twitter