1. #11
    Sencha User wemerson.januario's Avatar
    Join Date
    Nov 2008
    Location
    Brazil, Goias, Goiânia
    Posts
    372
    Vote Rating
    4
    wemerson.januario is on a distinguished road

      0  

    Default


    I am using build 302 and I can not see this new feature (Override). Is it alreary availble? When?

    Thanks
    Wemerson Januario
    Skype:
    wemerson.januario
    Email: wemerson.januario@gmail.com
    Fone:
    62 84101145 - Goiânia-GO- Brazil
    Consulting and Training Ext JS
    Projects: (Nubes ERP)

  2. #12
    Sencha - Architect Dev Team aconran's Avatar
    Join Date
    Mar 2007
    Posts
    8,892
    Vote Rating
    102
    aconran is a splendid one to behold aconran is a splendid one to behold aconran is a splendid one to behold aconran is a splendid one to behold aconran is a splendid one to behold aconran is a splendid one to behold

      0  

    Default


    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
    @aconran
    Sencha Architect Development Team

  3. #13
    Ext JS Premium Member
    Join Date
    Apr 2011
    Location
    London, UK
    Posts
    32
    Vote Rating
    1
    markofsine is on a distinguished road

      0  

    Default Breaking the build - thoughts

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


    Thanks,
    Mark

  4. #14
    Ext JS Premium Member
    Join Date
    Apr 2011
    Location
    London, UK
    Posts
    32
    Vote Rating
    1
    markofsine is on a distinguished road

      0  

    Default Detect file changes...

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

  5. #15
    Sencha - Architect Dev Team aconran's Avatar
    Join Date
    Mar 2007
    Posts
    8,892
    Vote Rating
    102
    aconran is a splendid one to behold aconran is a splendid one to behold aconran is a splendid one to behold aconran is a splendid one to behold aconran is a splendid one to behold aconran is a splendid one to behold

      0  

    Default


    Quote Originally Posted by markofsine View Post
    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.
    Aaron Conran
    @aconran
    Sencha Architect Development Team

  6. #16
    Sencha - Architect Dev Team aconran's Avatar
    Join Date
    Mar 2007
    Posts
    8,892
    Vote Rating
    102
    aconran is a splendid one to behold aconran is a splendid one to behold aconran is a splendid one to behold aconran is a splendid one to behold aconran is a splendid one to behold aconran is a splendid one to behold

      0  

    Default


    Quote Originally Posted by markofsine View Post
    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...

    Quote Originally Posted by markofsine View Post
    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...
    Aaron Conran
    @aconran
    Sencha Architect Development Team

  7. #17
    Ext JS Premium Member
    Join Date
    Apr 2011
    Location
    London, UK
    Posts
    32
    Vote Rating
    1
    markofsine is on a distinguished road

      0  

    Default


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

  8. #18
    Sencha - Architect Dev Team aconran's Avatar
    Join Date
    Mar 2007
    Posts
    8,892
    Vote Rating
    102
    aconran is a splendid one to behold aconran is a splendid one to behold aconran is a splendid one to behold aconran is a splendid one to behold aconran is a splendid one to behold aconran is a splendid one to behold

      0  

    Default


    Neither of those should be a problem...
    Aaron Conran
    @aconran
    Sencha Architect Development Team

  9. #19
    Ext JS Premium Member
    Join Date
    Sep 2010
    Posts
    333
    Vote Rating
    4
    stewardsencha is on a distinguished road

      0  

    Default


    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.

  10. #20
    Sencha - Architect Dev Team aconran's Avatar
    Join Date
    Mar 2007
    Posts
    8,892
    Vote Rating
    102
    aconran is a splendid one to behold aconran is a splendid one to behold aconran is a splendid one to behold aconran is a splendid one to behold aconran is a splendid one to behold aconran is a splendid one to behold

      0  

    Default


    Quote Originally Posted by stewardsencha View Post
    Thank you for taking the time to read.
    Thanks for the feedback.
    Aaron Conran
    @aconran
    Sencha Architect Development Team

film izle

hd film izle

film sitesi

takipci kazanma sitesi

takipci kazanma sitesi

güzel olan herşey

takipci alma sitesi

komik eğlenceli videolar