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.
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.
While I appreciate very much Sencha's effort in creating useful and full-featured dev environment I don't think Sencha Architect is quite ready for relatively big projects and teams of developers.
I original Architect software very useful for quick prototyping and designing complex UI structures, but then again - after you figure out the way your UI elements will lay down in JS file - often it's easier and faster to copy-paste existing JS code.
I don't think this is the answer you were looking for, I just wanted to share my thoughts.
When I had searched for this same topic, I had found that it is the metadata/ directory that is the important meat of the project, and that all of the components are separated out into their own metadata files. This, along with the root level project files, is probably the important part for version control. The app/ is regenerated on save and probably can be excluded from version control.
The main xds project file containers more general references and will probably change less often than the metadata components. But it would change when new components are created or project/app level settings are modified.
Ideally, if you just check in the root files and the metadata folder, it should just work.
Working in a team with source/version control is quite easy with Sencha Architect. An Architect project is all enclosed in a project directory. Inside it's made up of n parts
project file - consists of a small amount of data used by Architect to open and maintain your project. It's the single file you can double click to open it
metadata directory - consists of the files that describe all the pieces of your project. Each class (controller, view, model, store, resource) has it's information stored in it's own file.
app directory - consists of the src of the project you've created. A javascript file for each class.
other root files - an app.html and app.js which is the launchpad for your application and what get's run when you preview your application. This is also where your packager.json, app.json would go.
The point of me describing all of this is to show you that the files generated by Architect are pretty much identical to what you would have created in your favorite editor by hand. The only additional information is the metadata and the project file. The metadata is all JSON.
FOR NOW!!
We ask that you continue to use Architect as your editor and doing so with 20 engineers is perfectly safe using Git or SVN. When a dev makes a change it changes both the metadata and the app for those files.
I asked the same question to Aaron from Sencha in a private message. He suggested to check in the entire project structure including app and metadata.
It works, we did one flow in our team.
Related
Ext JS 6 contains 37,903 items that total 504 MB.
Here is the content of the package:
I need to learn which files (white entries) & folders (blue entries) are required in order to use Ext JS 6 without using Sencha Cmd.
p.s. I am not using dynamic loading. I always import ext-all.js and theme-X-all.css files which are located under the build folder.
you really should try to use Sencha Cmd, it reduces your app size and the number of files significantly.
However, If for some reason you don't want to use it, then it is safe to delete the build folder and the build.xml file.
If you are using ExtJS classic then you should keep the classic folder, otherwise delete it. The same goes for the modern folder.
You can also delete the cmd and examples folder.
You won't need the LICENSE file and the licenses folder, however, you should keep it for legal reasons.
Also, delete the Readme, release-notes, templates, sass and welcome files and folders.
You won't need those if you are not using Sencha Cmd, but then again, I advise you to use it, it does a lot better job at creating a nice and clean build of your app.
Sencha has a great getting started guide located here:
https://docs.sencha.com/extjs/6.0.2/guides/getting_started/getting_started.html
This assumes you have sencha CMD which is only available if you purchase a license (not GPL version). With sencha CMD, it automatically extracts the files you need when you run "Sencha App Watch".
If you don't have a commercial license it's best to link to the full sencha library that has everything include in one file. If you are starting out I recommend you use the debug and commented version so you will see your errors better. You can find a link to directions to do that here:
https://docs.sencha.com/extjs/6.2.1/guides/other_resources/extjs_faq.html
(and scroll to "How can I build an application without Sencha Cmd?")
I understand your concern seeing tens of thousands of files. Sencha ExtJS has a pretty steep learning curve but once you learn it there are big pay backs in productivity. All those files really help in debugging. Other libraries just cram them all together and when things don't work you are left without a clue.
HTH's
I'm starting with angular.js and after reading realized that I should use ng-boilerplate to bootstrap my project. But I'm a bit confused, I've cloned the project and stuff and I have a project called ng-boilerplate with all the structure needed, but what now? Do I need to change the project name "ng-boilerplate" to my project name? And what about the folders for example "Home" and "About"? Do I need to delete these folders and create the ones I need? I guess I have to remove some code in other files right? the problem is that I'm starting with angular so don't know what should I remove and what not.
As you can see I'm pretty new with this, am I right with the procedure?
thanks
Well if you read the ngboilerplate documentation carefully you will understand it use. As the first line says:
ngBoilerplate is designed to make life easy by providing a basic
framework with which to kickstart AngularJS projects.
ngboilerplate like many other seed projects, provide a prescriptive guideline about how a project should be structured. To demonstrate the working of the setup some project like this one add implementation for some standard scenarios to highlight how the complete setup works. Remember a working sample is far better than writing lengthy documentation.
The pages that you have mentioned are indeed for demo purpose and you can remove the folders if required. What this organization is telling us is that group your model-view-controller implementation together into a folder. These folders could be one per view or one per feature. The documentation on the site itself is self explanatory here https://github.com/ngbp/ngbp/tree/v0.3.2-release/src/app
Almost all folders of ngboilerplate have some documentation around specifics of that area. Read it to learn more about it.
in qooxdoo desktop you usually have to develop using the SDK and then "build" your app.
Is there a way to generate something like a qooxdoo.js file with the whole library inside so that you can script script it as you like (like jqueryui or dojo)?
Actually it could be nice to have every widget loaded at runtime like dojo's require("dojo.button") but both the approaches would be nice, just avoiding the build phase.
I hope the question is understandable :)
Thank you everybody!
Don't use the output of the build job to run your code as you develop - as among other things - will minify your code and make debugging very difficult.
If you want to code freely without needing to rebuild when you reference new classes then source-all is the build job for you.
In the root directory of your application, type:
python generate.py source-all
If will include the entire framework in the HTML file generated (you'll find it under source/index.html). This would work well if you are composing the UI from scratch and referencing many new qooxdoo widgets with each browser refresh.
If you add a completely new class of your own, you will need to run the source-all job again to include it.
I use the source build job however for a few reasons:
Habit: source-all didn't exist when I started using qooxdoo
Speed: You can notice a bit of lag it when you refresh the browser to view
your app
References: For a mature app, enough of the framework is
included in the application and its rare to add a new reference and
when you do, its probably in a new class of your own which would
require a re-run of the source job anyway.
I suggest you also look at Default Action Jobs as all the possibilities are explained in detail. Hope this helps.
Please check that thread for a detailed answer: http://qooxdoo.678.n2.nabble.com/Using-qooxdoo-desktop-without-having-to-build-it-td7585015.html;cid=1387453759247-228
I started working with sample sencha apps. I find it really hard to find typo and errors in my code.
I added the eclipse plugin for auto-complete during coding. Buts its a trial version just like the sencha architect. Am really confused on how the sencha app should be developed.
I want to know the tools that sencha developers are using so that I can deploy and debug effeciently.
Thanks in advance.
The workflow / tools choice when developing an application is a subjective matter so I'm going to talk about my experience, having been a Sencha Touch developer for the last year.
I find it really hard to find typo and errors in my code.
...
Am really confused on how the sencha app should be developed.
This is not a matter of tools in my opinion. Sencha Touch has an unavoidable steep learning curve. You should start with simple examples, and you could ask here when you have specific programming issues (I personally found Sencha Touch forums less useful than stackoverflow).
The most important thing is understanding the basics concepts:
Sencha Touch class system (http://www.sencha.com/learn/sencha-class-system),
How Sencha implements MVC (http://docs.sencha.com/touch/2.2.1/#!/guide/controllers)
(http://docs.sencha.com/touch/2.2.1/#!/guide/views),
Sencha Touch Layouts (http://docs.sencha.com/touch/2.2.1/#!/guide/layouts),
Sencha Touch Components (http://docs.sencha.com/touch/2.2.1/#!/guide/components)
Also all of these guides will be very useful, make sure you understand them and learn to use Sencha Docs, which definetely has some obscure, non explained properties, but should still be your main resource when developing a Sencha Touch app.
Debugging will always be tricky, unfortunately sometimes setting the wrong property on a Component, or misunderstanding how a Component is meant to work, ends up with some obscure var is not defined error. Do not fear to check Sencha Touch source code when this happens, code is well written and usually easy to understand.
Here the tools to use are again Sencha Touch Docs (when hovering on a class title you can examine directly its source code, plus your browser debugging console. Use frequent console.debug() messages, and when something weird happens inside framework classes stop execution with debugger; and step inside source code).
Now back to your question: I have been using the following tools:
NetBeans,
Chrome DevTools,
Chrome Ripple Extension,
Sencha Command (optional)
Compass CSS authoring framework
a couple shell scripts
The IDE is a matter of personal choice, Netbeans has some nice Javascript suggestions: it highlights variables when they are used but not defined in the current scope, or defined but not used, which really helps a lot against typos. It is very heavy in terms of memory usage. I guess Eclipse, or even a lighter one could be equally good.
Chrome is kinda a forced choice if you are on Windows, their DevTools are excellent, make sure you master them, they will be your main working tools. Once again: lot of RAM helps.
Ripple is an invaluable extension that allows you to test your mobile app on different devices and if you are using Phonegap for native deployment it emulates a part of its API on the browser.
Compass is the tool suggested by Sencha to compile their sass files. There is a detailed tutorial on how to setup compass on Sencha Docs.
I have been using Sencha Command but it's not strictly necessary, if you don't care about resources minification (but you should) you will not miss much about it. If you are developing a native app you can make up for the lack of Sencha Command deploy function with a simple shell script that copies html/js/css resources to the assets folder of your Phonegap project.
Another script activates automatically compass watch on the /resources/sass folder at startup, to avoid having to manually do that each time.
Just my two cents, hope it helps.
Anubis covered majority of the bee knees in hand coding Sencha Touch.
I'd like to add a couple more cents into the kitty.
My personal preference for IDE is Sublime Text. Searching through entire projects of code for anything, I've not seen an equal for effectiveness and speed. You can customise everything - especially colours and keybindings. It also has a ludicrous wealth of plugins, including working in correlation to Chrome, as well as Github.
SENCHA GUIDES
Miami Coder Tutorials - great collection of practical tutorials which will help you understand development patterns faster than most other guides. Great for starters.
Figleaf Training can be a little unconventional, but a great free means of learning Sencha Touch and almost everything it is capable of. Great for starters too.
Druck IT - solid collection of guides and ST information. Has links to many other useful sites such as these listed.
Mitchell Simoens - Mitchell is Sencha staff, a quality coder, and his site has some great advice and snippets to help learn. This is where you'll truly learn how to code ST well. Helps towards getting a grasp, but mainly for mid+ knowledge.
Ladysign - one of the Sencha Trainers. Has content that clears up "how to" in many facets other sites and books never even mention. Quality information. This info will get you above basic and flesh out your knowledge and understanding.
Modus Create - Jay Garcia is one of the devs of ST. Modus Create is his enterprise, which contains some useful guides within the blog.
Custom Font Icons - complete guide for 2.2. Very useful.
There's a few other sites that were incredible sources of tidbits through to information on how to code ST professionally. These links above will help immensely though. Above all, read the source code. It is very well documented, as well as being an example in itself of how to use the code. I have learnt ludicrous amounts this way.
GRUNT (with NPM/Node.js)!
Use Grunt! This will automate the vast majority of what you want to do. For example, typing "grunt" in the command line could jshint/jslint your code, concatenate all .js files together, all css files together (including all the compass joy), obfuscate, compress, run a comprehensive set of unit tests (especially Phantom), output to desired location, then add a cherry on top by refreshing your browser window. Add in the grunt watch plugin, and it'll do that every time a file is saved in defined directories. Any bugs in your code - you get accurate specific line numbers where it is broken.
The beauty of grunt is extended by optional alternate commandlines for different tasks. Also, you can specify in the package.json file of a few kB the precise list of plugins you wish to use with the gruntfile you've created, saving megabytes of file transfer. NPM can process that file, and download and install all that is required to operate. Makes for fast setup on another computer.
Side note: Touch Node has come of age. This permits all ST's class structure to develop your serverside javascript.
Want to include Sencha Cmd?
Sencha Cmd (finally) does do a decent job of collecting only the dependent classes from the full library.
grunt-sencha-build
grunt-senchacmd
Alternative for Sencha Cmd
Extend Grunt with Matt Goldspink's grunt-sencha-dependencies which works for both ST and ExtJS, or use grunt-sencha-resolver - this latter one I haven't used.
I am new to Sencha ExtJS and Architect MVC, but I know MVC and some other JQuery libraries in general.
I want to ask when building a real-world system, what is the proper approach to layout an Sencha app structure in Architect 2?
For example, we have the following departments in our app, they have distinct functionalities:
Accounting, Controlling, Quality Assurance, Customer Services, Human Resources, Logistics, Purchasing, Sales, Records Management ...
Approach 1: Write them in different Sencha Architect projects. Stitch up with master layout page + main area + header/footer + side bar pages. (using MVC.NET in our case)
--- Pros:
Multiple programmers can work on different sub-projects in an agile
environment.
Each project is smaller and easier to be upgraded or replaced.
--- Cons:
We have different Sencha Architect projects for, e.g. main areas, side bar, header, footer. How do they collaborate with each other? We now only use JQuery to pass information between them, but it feels kind of hacky.
Approach 2: Write them all in one big Sencha Architect project. So, it sarts up in a single app.html page with everything in it.
--- Pros:
Now every component in the project can collaborate with each other.
A true Single-Page-App All-in-One app.html looks nice.
--- Cons:
Having hard time if multiple programmers are working on one Sencha Architect project.
It is one big complicated piece of app. Although it is seperated into simple App, Store, M, V, C categories, but we can have name crash on components in a larger project.
Loading speed may be an issue? I am just guessing here because we don't know if Sencha Architect MVC design loads relevant windows and compoents part by part or everything together.
Question is, if we take 1st approach how do we make communications between different projects? If we take 2nd approach, is Sencha Architech 2 designed to build real-world projects that way? stacking everything in one big project?
First I'll say that your thinking about this problem in all the right ways. Your pros and cons are spot on.
Second for full disclosure I'm an engineer on the Sencha Architect team.
My suggestion is to have separate projects that are more loosely coupled and perhaps connected by a portal/dashboard application. The glue app can be written in anything including Ext JS in Architect.
The reason I say this is simply that I don't like putting all my eggs in one basket and if you've built single page apps you'll know that when they're working they really hum. But when an uncaught javascript exception occurs it can force that user to have to do a full refresh to get back to a happy state. Of course if you're perfect this will never happen :p Who's perfect?
I build Architect which is in fact a very large single page application. As a team we all do our best to keep each system able to work with as little dependency on any other system(s) as possible. We use things like eventing, pub/sub, adapter and plugin patterns, etc...
These systems are very much broken into separate namespaces and directories which like all software helps developers compartmentalize. Architect doesn't fully support this idea today. However with convention you can get close. e.g. HRController, HRNewEmployeeForm, HREmployeeGrid
Having HR as a separate app however, affords you HR.EmployeeController, HR.NewEmployeeForm assuming your app name is HR. Each app being a separate project also allows for the dev team to be more agile in how it deploys!! Major win.
Other users have taken this approach and one such user graphs all his projects together using a managed iframe approach
http://www.sencha.com/forum/showthread.php?243179
Asp.Net MVC is another good approach and might afford you some features like user auth etc...
Hopefully this helps!