Results 1 to 10 of 34

Thread: Breaking changes regarding Code Editing [Build > 298]

Threaded View

Previous Post Previous Post   Next Post Next Post
  1. #1
    Sencha User aconran's Avatar
    Join Date
    Mar 2007
    Vote Rating

    Default Breaking changes regarding Code Editing [Build > 298]

    Thank you everyone for providing tons of feedback and bug reports over the last 30 days as we've run our beta program.

    Due to feedback, we will be making some changes that may break existing projects and wanted to inform you of them as soon as possible.

    Many of you have requested that code editing be easier and that you be able to co-exist with other editors such as Eclipse, TextMate, etc.


    In Designer 1.0, we split the view and store implementation files into two. One was the .ui. or .base. file and was completely *owned* by Designer. Any changes you made to this file outside of designer would constantly be overwritten each time you exported. These files were considered "writealways" or "generated" files. We then advocated that you put any implementation/event bindings/new functions in the implementation file and that you as a user would completely own that file. You could use whatever editor you chose. We would only "writeonce" to that file.

    In Designer 2.0, (build 298 and earlier) we continued the split into two files. Because Designer 2.0 has a code editor, we would allow you to edit specific blocks of code for a function or basic event binding. We continued to put all of the standard UI/base stuff in the ui or base classes and the implementation/event bindings in the implementation files. We were attempting to parse out the implementation files and reflect out the changes you made. We would write to both the ui/base files and the implementation files everytime you saved your project. This worked well when changes were made while designer was NOT running but did not work well when you had both Designer and your text editor of choice open.

    We were following the same practices as to where the types of code should live from Designer 1.0 but really needed to adapt our approach in regard to "writealways" vs "writeonce".

    The new approach will be as follows:
    We've made additional changes since this was originally posted. For further details look here:

    All classes (views, stores, models, and controllers) created in designer will follow the approach of generating two classes. The base class will be given the namespace of .gen. to indicate that it is generated code and will always be overwritten. The parent class that you actually use will be named exactly as you specify.

    The files with .gen. will be owned completely by the designer. All code which you put in via the designer for a Basic Function, event binding or controller action will go here. These files are "writealways" and any external changes will be overwritten. The drop down at the top has changed from "UI or Base Class" to "Generated Class".

    The implementation files will be "writeonce". We will generate an implementation class that extends from the generated class that you can do whatever you would like with. If you want to edit this in an external editor go ahead, we won't touch it again. Many of you have also given us the feedback that you like being able to develop your entire applications within the designer and not having to switch to a text editor. To cater to you individuals, we will be giving you a raw code editor to edit the implementation file from within the Designer.

    In general most tasks should be able to be completed through the generated code entirely and you should infrequently have to dip into the advanced mode of editing Implementation files directly.

    By giving users the ability to edit the implementation file directly, we are allowing you to do all sorts of bad things to yourself. Change the subclass name incorrectly, add syntax errors, etc etc. We are looking at how to synchronize between the configuration and the file for the few configurations that are there. (Currently just userAlias and userClassName). Because of the many issues this raises this feature may be turned off by default and only enabled via preferences to avoid accidents from occurring.

    Last edited by aconran; 29 Feb 2012 at 7:11 PM. Reason: newchanges
    Aaron Conran

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts