What is the expected collaboration workflow with Sencha Architect?

Question

I started a trial of Sencha Architect, and the more I use it more questions come to my mind for its actual feasibility usage in a development environment, one of the bigger questions I have is

In an environment that you can't edit the individual files in different editors, how can multiple people collaborate in developing different parts of a site, for example

app/models|components|views/Model1.js  <- In charge of developer one
app/models|components|views/Model2.js  <- In charge of developer two.

In a regular environment you could use git, for example, to distribute each file but in architect, you are not expected to edit files manually (which sucks because features like profiles are not exposed in architect). If you do edit them manually, it will cause problems or it may overwrite your code back to whatever data is on the project file so I am wondering what is the proper, or expected collaboration workflow with Sencha.

Answer 1

Having read the above posts, I still can't believe that keeping Sencha metadata files in code repository and generating ALL JavaScript from metadata is suitable for big projects.

The idea of Sencha Architect is to keep the code not in javascript files, but in JSON metadata, and whenever you need to edit a JavaScript code, you have to use IDE and edit metadata. Phil Strong said "We ask that you continue to use Architect as your editor and doing so with 20 engineers is perfectly safe using Git or SVN.". Of course this workflow is very profitable for Sencha, it forces 20 people to use a licensed Sencha Architect, because to change a single line of JavaScript code the developer must use Sencha Architect.

When two people edit the same file, IDE updates metadata. Then they check-in the file into a code repository, and one of them has to resolve conflicts, so the developer has to merge two metadata files, not JavaScript files.

The whole idea of not letting developers to edit JavaScript unless they use Sencha Architect is counter-productive, because the same person can be using his favorite IDE for both Java and JavaScript development, or Python and JavaScript. Doing both client and server programming in the same IDE is faster than switch between two IDE's. The reality of a big project is that you have multiple teams around the globe who work with different IDE's, you also may have a short-term project implemented by a contractor who also has his favorite IDE.

ExtJS is a well designed framework, you don't need SenchaArchitect to modify a single line of JavaScript code.

When coding in JavaScript, I save my JavaScript file and refresh browser, and see the changes immediately. Sencha Archtect adds and additional step, it requires you to publish javascript (generate JavaScript from metadata), and the bigger the project is, the longer is delay. Often I have to modify JavaScript files in production, sometimes changing a single line fixes the problem, again, I have to use Sencha Architect to re-generate this single line from metadata.

I use Sencha Architect for quick prototyping only, then check-in generated files into code repository and continue to edit JavaScript manually. With this approach I can use a version control system to see the history of JavaScript. If I checked in JSON metadata into a VCS, then I would not have the history of JavaScript, I would have the history of JSON metadata which is counterintuitive.

I think that having metadata for GUI form is OK, but the limitation that MVC controller level has also to be generated from metadata is not OK.