29 Feb 2012 7:18 PM #11
29 Feb 2012 7:41 PM #12
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...Aaron Conran
1 Mar 2012 12:56 AM #13
Breaking the build - thoughts
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.)
1 Mar 2012 1:17 AM #14
Detect file changes...
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...
1 Mar 2012 8:05 AM #15
We've added the underlying native API's to do file system watching but have not implemented it yet.Aaron Conran
1 Mar 2012 8:12 AM #16
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...Aaron Conran
1 Mar 2012 9:11 AM #17
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...
1 Mar 2012 9:42 AM #18
Neither of those should be a problem...Aaron Conran
2 Mar 2012 3:08 PM #19
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.
2 Mar 2012 3:11 PM #20