Page 1 of 2 12 LastLast
Results 1 to 10 of 19

Thread: Who uses Sencha Architect exclusively?

  1. #1

    Default Who uses Sencha Architect exclusively?

    Hi all, I'm just wondering who here uses Sencha Architect exclusively for all of their app development; web, mobile and/or desktop?
    I'd love to hear your experiences with this approach.

    Thanks in advance,
    Niall.

  2. #2
    Sencha Premium User
    Join Date
    Oct 2012
    Location
    United States
    Posts
    130
    Answers
    11

    Default

    Quote Originally Posted by niallobrien View Post
    Hi all, I'm just wondering who here uses Sencha Architect exclusively for all of their app development; web, mobile and/or desktop?
    I'd love to hear your experiences with this approach.

    Thanks in advance,
    Niall.
    we use it exclusively, well 98% w/ a few external files.

    If you could be more specific, i'd be more than happy to answer whatever i can.

  3. #3

    Default

    Am I correct in assuming that you can't really edit the code outside of Architect (and have it sync with Architect)? If so, do you find this overly limiting at all?

    How is your team's productivity developing apps this way?

    Thanks in advance.

    Quote Originally Posted by grosst View Post
    we use it exclusively, well 98% w/ a few external files.

    If you could be more specific, i'd be more than happy to answer whatever i can.

  4. #4
    Sencha Premium User
    Join Date
    Oct 2012
    Location
    United States
    Posts
    130
    Answers
    11

    Default

    Quote Originally Posted by niallobrien View Post
    Am I correct in assuming that you can't really edit the code outside of Architect (and have it sync with Architect)? If so, do you find this overly limiting at all?

    How is your team's productivity developing apps this way?

    Thanks in advance.

    The short answer is - no you really can't... This is because of the metadata files but that's not so much a limitation to us. We do have some other things external such as pivot grids which we then include as a JS resource via secondary app folder called 'externals' . But what we do externally is use the generated files fortesting testing things like event's and update them via sublime text or chrome console. Then move the working solution into SA to reduce lag time between debugging.

    I'd say when you first start, trying to reproduce one of the example apps in the kitchen sink can be somewhat of a pain if a configuration is missing, you really have to take time and learn the nuances of architect(both the fun and not so fun). Such as being able to add a property that isn't there or using process config when you need to do something that you normally couldn't do within SA. Also setting up a git repo for the first time for use within a team env is a pain.

    There are some obvious frustrations but I would say overall being able to manage a project and build independent modules, it's quite simple because of the view from 30,000 ft and ease of navigation between items.

    Architect as a whole gets better with each update, there were some hiccups but from starting w/ ext4 and now using the same project in 6, it has been rather easy to truck along.

    My best advice is to not only learn Ext JS, but also Learn Architect... The reason i say learn ExtJS even though it should be obvious is that architect on the most basic level is a crutch. It enables you to do so much in a rapid fashion, that it's easy to forget there is so much more outside the box.

    TLDR -

    If you're willing to take the time to overcome obstacles within architect and figure out what works and what doesn't, it's well worth it in the long run, even if you're just using it to prototype. The program is getting better with each release and the frequency of them is happening faster.

    Good -
    • Quick prototyping
    • Time saver
    • The SA Team is extremely knowledable and can usually provide a quick solution or work around to your issue.
    • Easy to use w/out a ton of ExtJS knowledge
    • Navigating between MVVM is effortless
    • Visual building for those on the fly changes to things like grids and charts without having to save in IDE-> tab over to browser -> refresh -> check -> fix etc.
    • API docs at your fingertips, and some of it in an automated fashion. like creating event bindings and not having to remember properties etc.
    • Beautiful Syntax, and best practices assurance for the components structure, which can get lost in the mix easily.


    Frustration
    • Updates lag behind releases so sometimes you're handcuffed to an older version of ExtJS or SenchaCmd for a bit. As well as left to deal w/ those frustrations.
    • Sometimes only the default type of config exists and you're not able to convert configs from things like object to a string. or array to obj, so you're forced to use process config which doesn't 'process' in the design view etc... this is very minor
    • External code / updating items outside of SA is not straight forward.
    • Extensions may be a solution, but the documentation and examples out there leaves you feeling lost at times.


    Hope that helps..

  5. #5

    Default

    Wow, thank you so much for sharing. There's some great tips in there for sure. Yeah, I'm purely looking at it from the perspective of rapid prototyping & development. At the moment we're happy to write everything the traditional way, however, being able to visualise your views as you build them is quite an advantage. To then be able to visually glue the app's functionality together is, to me, amazing. The lack of being able to sync the code is quite a disappointment however, as I'm quite fond of my Webstorm setup.
    What is this 'process config' that you make reference to?

    Thanks in advance,
    Niall.

    Quote Originally Posted by grosst View Post
    The short answer is - no you really can't... This is because of the metadata files but that's not so much a limitation to us. We do have some other things external such as pivot grids which we then include as a JS resource via secondary app folder called 'externals' . But what we do externally is use the generated files fortesting testing things like event's and update them via sublime text or chrome console. Then move the working solution into SA to reduce lag time between debugging.

    I'd say when you first start, trying to reproduce one of the example apps in the kitchen sink can be somewhat of a pain if a configuration is missing, you really have to take time and learn the nuances of architect(both the fun and not so fun). Such as being able to add a property that isn't there or using process config when you need to do something that you normally couldn't do within SA. Also setting up a git repo for the first time for use within a team env is a pain.

    There are some obvious frustrations but I would say overall being able to manage a project and build independent modules, it's quite simple because of the view from 30,000 ft and ease of navigation between items.

    Architect as a whole gets better with each update, there were some hiccups but from starting w/ ext4 and now using the same project in 6, it has been rather easy to truck along.

    My best advice is to not only learn Ext JS, but also Learn Architect... The reason i say learn ExtJS even though it should be obvious is that architect on the most basic level is a crutch. It enables you to do so much in a rapid fashion, that it's easy to forget there is so much more outside the box.

    TLDR -

    If you're willing to take the time to overcome obstacles within architect and figure out what works and what doesn't, it's well worth it in the long run, even if you're just using it to prototype. The program is getting better with each release and the frequency of them is happening faster.

    Good -
    • Quick prototyping
    • Time saver
    • The SA Team is extremely knowledable and can usually provide a quick solution or work around to your issue.
    • Easy to use w/out a ton of ExtJS knowledge
    • Navigating between MVVM is effortless
    • Visual building for those on the fly changes to things like grids and charts without having to save in IDE-> tab over to browser -> refresh -> check -> fix etc.
    • API docs at your fingertips, and some of it in an automated fashion. like creating event bindings and not having to remember properties etc.
    • Beautiful Syntax, and best practices assurance for the components structure, which can get lost in the mix easily.


    Frustration
    • Updates lag behind releases so sometimes you're handcuffed to an older version of ExtJS or SenchaCmd for a bit. As well as left to deal w/ those frustrations.
    • Sometimes only the default type of config exists and you're not able to convert configs from things like object to a string. or array to obj, so you're forced to use process config which doesn't 'process' in the design view etc... this is very minor
    • External code / updating items outside of SA is not straight forward.
    • Extensions may be a solution, but the documentation and examples out there leaves you feeling lost at times.


    Hope that helps..

  6. #6
    Sencha Premium User
    Join Date
    Oct 2012
    Location
    United States
    Posts
    130
    Answers
    11

    Default

    Quote Originally Posted by niallobrien View Post
    Wow, thank you so much for sharing. There's some great tips in there for sure. Yeah, I'm purely looking at it from the perspective of rapid prototyping & development. At the moment we're happy to write everything the traditional way, however, being able to visualise your views as you build them is quite an advantage. To then be able to visually glue the app's functionality together is, to me, amazing. The lack of being able to sync the code is quite a disappointment however, as I'm quite fond of my Webstorm setup.
    What is this 'process config' that you make reference to?

    Thanks in advance,
    Niall.

    Example of hasMany config being broken in model - - Bug report link: https://www.sencha.com/forum/showthr...es-build-error

    Quick work around to fix compiling issue.budgetProcessConfig.png

  7. #7
    Sencha Premium User
    Join Date
    Sep 2011
    Location
    Tamworth, NSW, Australia
    Posts
    1,353
    Answers
    13

    Default

    I use Architect as the sole developer so I haven't needed to address the issues faced in a team environment (although I may soon have to do so if the use of Ext JS and Architect are continued in our large organisational restructure). Given that I'm the master of my own domain I do everything in Architect and don't try to edit anything outside it. The use of processConfig is something I use often, too.

  8. #8

    Default

    Thanks for sharing - how do you think it will work out for you once in a team environment? Specifically, I'd be interested to know how well it works with version control - any input in this area is much appreciated.

    Thanks in advance.

    Quote Originally Posted by marc.fearby View Post
    I use Architect as the sole developer so I haven't needed to address the issues faced in a team environment (although I may soon have to do so if the use of Ext JS and Architect are continued in our large organisational restructure). Given that I'm the master of my own domain I do everything in Architect and don't try to edit anything outside it. The use of processConfig is something I use often, too.

  9. #9
    Sencha Premium User
    Join Date
    Oct 2012
    Location
    United States
    Posts
    130
    Answers
    11

    Default

    Quote Originally Posted by niallobrien View Post
    Thanks for sharing - how do you think it will work out for you once in a team environment? Specifically, I'd be interested to know how well it works with version control - any input in this area is much appreciated.

    Thanks in advance.

    Version control is not bad, but should tweak to accommodate your environment.


    for example ours looks like -


    #Sencha Architect Ignores
    .architect
    bootstrap.json
    ext/*
    build/*
    bootstrap.css
    bootstrap.js
    bootstrap.jsonp
    sass/example/*

    we used to ignore the app folder since you can rebuild it on the fly... but that then became an issue w/ some overrides and external files. Plus it's always nice to be able to just pull and load it up right away, instead of having to open the project again in architect then click 'save entire project' ... just to verify/test changes.

    There's no need to commit your ext folder and your build folder, since the ext should exist locally on everybody's machine.and your build is re-generated fresh when packing an updated application.

    If you're considering doing this within a team environment, my best advice to you would be:



    • Before doing any sort of pull/merge/patch etc, close architect first. Just because you updated the metadata file via a pull request, it doesn't get picked up in architect. So a save entire project would just overwrite any merged changes w/ your current ones.



    • Sometimes architect likes to start taking internal references such as a button xtype.. and add numbers so all the sudden button can become button1, button2,button3
      • don't be alarmed though, it's only happening within the metadata file .. but will not change your actual app folder and mess up the aliases. As a rule of thumb if it's in a pull request where it's adding a number and no real changes to the file. Then i won't accept it until it has been discarded. I typically only see this when it's a file where no real update was made, but architect decided it needed to do something.




    • Last but not least which is on point with today, when a new version is released. DO not just go ahead and upgrade.. commit, make a zip do whatever, just keep a copy of the previous version.


    Assuming you're the one w/ oversight.. load the project in the new version and see what happens. Don't let people just upgrade blindly. While a lot of updates are seamless, assess first then distribute the newly upgraded one to everybody.

    Just because architect uses cmd 6.2 and now it's 6.2.1 and framework is now 6.2 -> 6.2.1 does not mean it will all work perfectly. After that is when we(the royal we decide if we will move into the next version or wait for the next update on it. but stay current if you can


    on a side note, i do find it easier to just build the application through the command line, given that the syntax errors like a random trailing comma or something will be picked up with a nice [WRN]

  10. #10
    Sencha Premium User
    Join Date
    Sep 2011
    Location
    Tamworth, NSW, Australia
    Posts
    1,353
    Answers
    13

    Default

    Quote Originally Posted by niallobrien View Post
    Thanks for sharing - how do you think it will work out for you once in a team environment? Specifically, I'd be interested to know how well it works with version control - any input in this area is much appreciated.

    Thanks in advance.
    I probably won't get the chance to find out. Yesterday I was told that the technologies being selected for us in the larger organisational restructure will be Angular and Ruby on Heroku (none of which I've so much as even looked at before, so I'll be busy having to re-learn everything over the next 12 months or so). My single license of Premium will probably be renewed for the short to medium term, at least until the dozen things I've written with it over the years are retired or replaced by something else.

Page 1 of 2 12 LastLast

Similar Threads

  1. Replies: 5
    Last Post: 21 Mar 2017, 6:03 AM
  2. Replies: 1
    Last Post: 9 Sep 2016, 5:25 AM
  3. Can i upgrade from Sencha Architect 3 to Architect 4?
    By pawanchowdary in forum Sencha Architect 4.x: Q&A
    Replies: 1
    Last Post: 7 Aug 2016, 7:19 AM
  4. Replies: 2
    Last Post: 29 Apr 2016, 6:54 AM
  5. Replies: 1
    Last Post: 14 Nov 2014, 6:52 AM

Posting Permissions

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