PDA

View Full Version : Breaking changes regarding Code Editing [Build > 298]



aconran
28 Feb 2012, 11:23 PM
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.

History:

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:
http://www.sencha.com/forum/showthread.php?184095-Breaking-changes-regarding-Code-Editing-Build-gt-298&p=745334&viewfull=1#post745334

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.

Feedback?

wemerson.januario
29 Feb 2012, 4:08 AM
Congratulations team! I'm very happy with this point of view!
Thanks for continuing using the "writeonce" and "writealways" concept.

wemerson.januario
29 Feb 2012, 4:25 AM
Tested and aproved the new concept of implementation classes.

Guys, now the next step for the goal is add more features to the Sencha Designer editor. It would be niceeeeeee
But, again, amazing work!

delgrundy
29 Feb 2012, 5:49 AM
Sounds like a good compromise.

ssamayoa
29 Feb 2012, 6:43 AM
Let do it this way.

When you think this feature will be available?

Regards.

marc.fearby
29 Feb 2012, 2:20 PM
Could you please clarify a bit further what you mean by "may break existing projects"? Due to a bug in 1.2 I've actually had to start using the 2.0.0 beta1 to continue development on a rather complicated form that kept crashing 1.2, so I'm now committed to the new program irrevocably. I realise that you can't support people that knowingly use a beta like this, but what will this mean? Some files might be renamed to a new format (.gen) but essentially will retain the UI code within them, and perhaps new implementation classes will be genereated (into which I could copy my old implementation code)? If so, then I'll adapt and I'm sure I'll cope. If, however, existing projects can't be opened in the new build and it's a fresh slate from then on, then I guess I'm screwed :-)

By the way, where do I download the latest builds? I'm still on 268 and the download I used yesterday (http://www.sencha.com/forum/showthread.php?152941-Sencha-Designer-2-Beta-Download-links) (for Windows) still gave me 268.

As for the code editor, I could probably get RSI typing up what I'd like to see, but here are the few features I don't think I could live without:

Ability to move current/selected line/s up and down via Ctrl+Up and Ctrl+Down
Collapsible regions of code so that class methods I'm not working on can be shrunk thereby making scrolling up/down through the implementation quicker and easier (& having these collapsed regions remembered between sessions)
Some kind of class inspector that shows the properties and methods for the current class, allowing you to double-click to jump to them
Ability to Ctrl+Click on a method name to jump to that method
Refactoring of method names, variables, etc
Search/replace that also highlights (at once) all matches so you can scroll through and see at a glance all occurances
Code templates/snippets ability so commonly-typed things can be inserted after a combination of letters is typed by the developer
Ability to customise the text font, size, and colours
I haven't used Designer to type code yet but I can see that I wouldn't cope having a two-click process to switch between UI Class and Implementation. That grey strip at the top could easily have three left-aligned buttons (tabs?) so that this becomes an easy one-click step. That vertical white strip to switch between UI and code is a waste of space, too, and these two functions could each be in that horizontal grey strip (again, as separate buttons).
The toolbox could take up less width, too. Perhaps those grey category links could be in a strip at the top as buttons, without text, with Button/Grid/Chart/etc small icons that are easily distinguishable to allow switching categories? I also went looking for buttons in the form category. A category called "Buttons" with just 4 items seems unecessary (to me, at least). Or perhaps the toolbox could use an accordian layout if there weren't too many categories and each accordion header wasn't too chunky?
I realise that there is a LOT of work involved in developing all these things but without them, I can't see me ditching my present IDE solely in favour of Sencha Designer for my implentation code. At the moment I'm only using it to generate UI and that's it.

Sorry if I'm being too demanding... some of us can be an ungrateful lot :-) But I do prefer 2.0 over 1.2 already so I can see the improvements so far have been worthwhile.

aconran
29 Feb 2012, 2:25 PM
I realise that you can support people that knowingly use a beta like this, but what will this mean? Some files might be renamed to a new format (.gen) but essentially will retain the UI code within them, and perhaps new implementation classes will be genereated (into which I could copy my old implementation code)? If so, then I'll adapt and I'm sure I'll cope. If, however, existing projects can't be opened in the new build and it's a fresh slate from then on, then I guess I'm screwed
It's not going to be an impossibility, just might be a bit painful.



By the way, where do I download the latest builds? I'm still on 268 and the download I used yesterday (for Windows) still gave me 268.
You should have gotten an auto update to 298.



I realise that there is a LOT of work involved in developing all these things but without them, I can't see me ditching my present IDE solely in favour of Sencha Designer for my implentation code. At the moment I'm only using it to generate UI and that's it.

Sorry if I'm being too demanding... Some of us can be an ungrateful lot :-) But I do prefer 2.0 over 1.2 already so I can see the improvements so far have been worthwhile.

You are not being too demanding at all. The designers strength is in rapid building of your user interface and seeing what your application will look like. We are not trying to replace your IDE if you'd like to continue using it, we are just giving those of you that don't want to swap between applications that ability.

marc.fearby
29 Feb 2012, 2:53 PM
You should have gotten an auto update to 298.

I had to configure the proxy with username/password at the startup screen to activate the beta so perhaps that's why the update isn't coming down? Is there a download link somewhere as an alternative?

pkellner
29 Feb 2012, 4:02 PM
Thanks for the update. I totally support you making this breaking change to Designer. I think you've got a great compromise by having one file totally owned by the framework and the other one that we (the developer running the designer) has complete control of after it is generated by the framework. Nice job!

aconran
29 Feb 2012, 7:10 PM
We've made some changes to what we're doing in this regard due to internal feedback.

We've flatten the dual class hierarchy into a single class. This allows us to be even more hands free of the user owned file. The user owned file is now an override as opposed to a subclass.

This file would be completely owned by the designer:


Ext.define('MyApp.view.MyPanel', {
extend: 'Ext.panel.Panel',
alias: 'widget.mypanel',

height: 250,
width: 400,
title: 'My Panel',

initComponent: function() {
var me = this;

me.callParent(arguments);
},

myMethod: function() {
return {
test: 'abc'
};
}

});


And this file would be owned by a user:


Ext.define('MyApp.view.override.MyPanel', {
override: 'MyApp.view.MyPanel',
title: 'changed it',
myMethod: function() {
var o = this.callOverridden(arguments);
o.foo = true;
return o;
}
});

wemerson.januario
29 Feb 2012, 7:18 PM
I am using build 302 and I can not see this new feature (Override). Is it alreary availble? When?

Thanks

aconran
29 Feb 2012, 7:41 PM
It will be going into nightly in the next few days and beta in probably about a weeks time.

For those of you on nightly, I would *highly* recommend putting your work in source control before making changes to your projects. We are working out some bugs...

markofsine
1 Mar 2012, 12:56 AM
I support the suggested two file approach in addition to standardizing naming convention of base class....

But this last change of using overrides as opposed to sub-classes is (perhaps?) more concerning.

Problem 1 - Migration issue:
This will affect all pre-designer 2.0 projects as well as everyone who has already migrated to beta 2.0 (which we know we should not have, but it does bring enhancements and the best way to test is probably using in a live development environment).
This may be painful but is perhaps a one-off so is bearable. (But seriously we need to nail this down.)

Problem 2 - Why?
The reason for the change: "This allows us to be even more hands free of the user owned file"
What does this mean? What additional flexibility does it bring. How does it make developers lives better/easier?
In my mind the current method is clean and is standard OO design. i.e. Base class with an extending class which adds to or overrides the base class functionality as required.

In Summary: perhaps more clarity on this latest change...
1. How will it impact existing projects (v1.2 & v2.0), keeping in mind that the existing project write-once implementation classes have already been generated and will now need to be changed to overrides.

2. What (additional) benefits does it bring to a developer.

3. How do overrides work differently when compared to the base/implementation class pattern (I will read more on this, but would be useful to have an impact summary from yourselves.)


Thanks,
Mark

markofsine
1 Mar 2012, 1:17 AM
As said previously like the approach of a write-once implementation file and write-always base class..

But as a thought...
What about detecting when an implementation file changes and automatically / prompting to bring the changed file contents into the designer.

This allow external file editing but allows those external edits to be seen quickly and simply within the designer.
It could also then be edited in the designer and the external editor may detect the change...

aconran
1 Mar 2012, 8:05 AM
What about detecting when an implementation file changes and automatically / prompting to bring the changed file contents into the designer.


This is tracked as DSGNR-1039.
http://www.sencha.com/forum/showthread.php?154063

We've added the underlying native API's to do file system watching but have not implemented it yet.

aconran
1 Mar 2012, 8:12 AM
Problem 1 - Migration issue:
This will affect all pre-designer 2.0 projects as well as everyone who has already migrated to beta 2.0 (which we know we should not have, but it does bring enhancements and the best way to test is probably using in a live development environment).
This may be painful but is perhaps a one-off so is bearable. (But seriously we need to nail this down.)

Yup...



Problem 2 - Why?
The reason for the change: "This allows us to be even more hands free of the user owned file"
What does this mean? What additional flexibility does it bring. How does it make developers lives better/easier?
In my mind the current method is clean and is standard OO design. i.e. Base class with an extending class which adds to or overrides the base class functionality as required.

The class structure is more akin to what someone would write without using the designer. In the dual classed approach we always have to create both the generated class and the implementation class (because the implementation class is what will actually be invoked) This means that the userClassName and userAlias can now be more accurately tracked in the single flat class structure.

Finally, because of these above points we can omit/never create the overrides class if its not needed. This will lead to less bloat and easier to understand code. The majority of the work you would like to do is achievable without dipping into in an override. When you begin writing overrides you are essentially telling the designer, I know what I'm doing, this is advanced mode and I realize I may be breaking things...

markofsine
1 Mar 2012, 9:11 AM
I have done some basic testing to see how this would impact and have run into the following two problems...

1. Is it possible to override any property of the 'base' class?
-- Overriding 'alias' property seems to be ignored.

2. Is it possible to add any property to the override class?
-- Adding the 'mixins' property breaks things...

aconran
1 Mar 2012, 9:42 AM
Neither of those should be a problem...

stewardsencha
2 Mar 2012, 3:08 PM
1. Using the designer to enter 27 model fields is tedious. Compared to an editor and a guy who can run a keyboard. It can never be anywhere near as fast. My IDE highlights missing commas and gives me all kinds of feedback about the code. Never mind search and replace etc. There is no way this tool can replace an IDE/editor, ever.

2. I will make mistakes no matter what you do. The idea of preventing me from making them only goes so far. You can' attain it.

3. Both designer and editor will be open. We're working. Please don't make us shut down and restart for every tweak.

4. I used Delphi Pascal for years. They had an option to "save form as text" or save in some internal binary format. When the internal format file went bad, I was screwed. Nothing to do but start over. When the text file went bad, I could usually recover quickly.

You have the same situation. Some sequence of delete+deploy just wiped out all my controller init code. The reason is unimportant. It's gonna happen.

I don't see why you cannot load in code that we added in elsewhere. It's not like you are really having to parse it, char by char by token by token? Is there not a higher level intermediate format you can read/write, eg json objects or (yuck) XML? An INI file with CDATA sections would be fine. Going back to Delphi, when there was a binary field, they converted it to base64 and wrote it as text. But I haven't seen any binary fields here yet.

If you cannot read the json representation, then I have made an error in typing. Give me a message and let me sort it out.

It's coding. There will be blood. You cannot prevent it. Make it as easy as possible to recover.

Let me enter all kinds of stuff initially (model fields are the best example, but there's a lot more).

When I get to the debug stage, I am making small changes. Alt+tab three keystrokes, alt+tab and refresh. Keep that cycle short, don't make me go to the designer as well. I can poke at source and in the console until I have it right, then take the time to figure out how to tell the designer to do what I just did.

The designer is a killer feature and I don't want to live without it. You guys are way smart enough to share code between an editor and a designer at the same time. I'd rather stab myself (and learn from the mistake) than be hamstrung or faced with using a GUI tool to write code. Or produce nothing but boilerplate forms and "Hello World".

Don't look at it as "giving you the tools to hurt yourself". It is giving us the flexibility to recover from disaster/corruption (whatever the source), and the ability to leverage other code tools in addition to the designer. Make us flip a "kamikazi mode" switch in settings if you want.

Somebody has decided the objective of the designer is to write fail-safe code. Cool. But to me, that is not the main purpose of the program. It's a beneficial side-effect, and usually only applies to wireframes and simple programs. Real life gets more complicated.

Dunno about overrides vs subclass, but the docs for override says "One use for an override is to break a large class into manageable pieces" and that sounds like what we are doing. The class may not be large, but we are each managing a piece. Sounds good to me.

Thank you for taking the time to read.

aconran
2 Mar 2012, 3:11 PM
Thank you for taking the time to read.

Thanks for the feedback.

ssamayoa
3 Mar 2012, 7:08 AM
Make us flip a "kamikazi mode" switch in settings if you want.


Amen.

g13013
3 Mar 2012, 11:20 AM
I am using build 302 and I can not see this new feature (Override). Is it alreary availble? When?

Thanks

Where did you get the build 302 ?

aconran
5 Mar 2012, 5:28 AM
Where did you get the build 302 ?

There are a few users who were part of the private beta program before we released the public beta who have access to the nightly channel. These users have signed an agreement with Sencha to get access. Entrance to this program is full.

g13013
5 Mar 2012, 9:24 AM
I understan, and It's unfortunate :), maybe I will be in, in the version 3 :D

prout_boudin
5 Mar 2012, 2:38 PM
I totally agree with the break changes, I have to close the designer, make changes in the files and reopen it again !


But in your example, it would be more readable to have :

var o = this.callSuper(arguments);in place of var o = this.callOverridden(arguments);

hotdp
6 Mar 2012, 12:25 PM
Hi,
You recommend putting the code under source control, will the SVN fix be added before?

I also need to be sure, will it be possible to get current solutions converted to the new version? I have a large enterprise application and I would like to be able to use the Designer for this application after updating?

aconran
6 Mar 2012, 12:46 PM
Yes, the SVN fix is included in the update.

ssamayoa
6 Mar 2012, 1:00 PM
Yes, the SVN fix is included in the update.

Which fix?

Designer will have a SVN client?

aconran
6 Mar 2012, 1:03 PM
Which fix?
http://www.sencha.com/forum/showthread.php?182997
http://www.sencha.com/forum/showthread.php?184617-Critical-interference-with-.svn-folders


Designer will have a SVN client?
No.

ssamayoa
6 Mar 2012, 1:10 PM
http://www.sencha.com/forum/showthread.php?182997
http://www.sencha.com/forum/showthread.php?184617-Critical-interference-with-.svn-folders


Oh!

So I should't put my Designer's project in VC until new build is released...

hotdp
6 Mar 2012, 1:34 PM
Yes, the SVN fix is included in the update.

Just to be sure, will I be able to put it in svn before the "breaking changes" Or will it all be in same release?

@aconran what about the other Q?

marc.fearby
6 Mar 2012, 2:20 PM
Hi,
You recommend putting the code under source control, will the SVN fix be added before?

I also need to be sure, will it be possible to get current solutions converted to the new version? I have a large enterprise application and I would like to be able to use the Designer for this application after updating?

I'm one of those poor chumps stuck with Microsoft Team Foundation Server which is a right pain in the neck. I use Visual Studio to write C# web services for my Ext JS client apps, but Visual Studio refuses to let you include foreign files in its source code backups (I know there's a shell extension but I'm not manually adding new views/stores/models generated by Designer each time I make a change).

I hear that Microsoft have finally figured out the suckfulness of their software and are going to allow "all files in X solution folder" to be managed by their new source code control system. I am desperately looking forward to it because I'm currently just periodically zipping my entire solution (which includes all Designer-related stuff) and copying it to a server that's backed up nightly.

P.S., blame is attributable to Visual Studio, too, which refuses to let you search/replace all files in a solution folder that do not technically belong to the solution. So, all my *.js files that weren't added to the solution via the official method, are given a very cold shoulder by the IDE. Very poor form, Microsoft.

positive6900
19 Jul 2013, 4:29 AM
it only opens in read mode and i am not able to make changes,how to open in write mode

tangix
19 Jul 2013, 4:46 AM
Things that are automatically generated by Sencha Architect are not editable and you should not touch these directly, instead use the config panel.
Functions (event handlers, configs) and overrides created by you are editable.

/Mattias