I am developing a extjs application, and I am just a starter.
It's quite different develop mode for me, and I feel puzzled.
My first question is about client-end architecture, I'm developing a little app now, so I wrote all js codes in only one html file, what if I need to develop a huge app?
like this: [Article Manage(leaf in tree)] -> [CURD List(Data Grid)] -> [Edit Article(Dialog Box)]
There will be lot of leaf in my tree, so there are many XXX Manage.
What should I manage my client-end js files(file structure or something else), and how to load these files dynamically? Is there any exists demo?
um.. maybe what I really want to ask is:
How to put my code for every module into different js files and 'include' the dynamically?
I've got the answer, just use loader property of a container component, this method fit me well. Thanks to all of you.
There are no patterns set in stone, but here's one way to Write a Big Application in Ext 3.x.
Another good resource for ideas, generic to JavaScript, is Nicholas Zakas's video on Scalable JavaScript Application Architecture on YUI Theater.
In my mind the big things to do are:
Write standalone components (think: UI container, data structure, etc) with no dependencies to other components on the page.
When you want to two components to interact, have their parent container wire them together.
Have some kind of logical directory structure for development (doesn't matter what exactly), splitting out each of your "components" into its own file -- even if you plan on combining them into a single file for deployment.
Not sure if I correctly understood your question, but I'll try to answer. For bigger applications use MVC pattern which allows you to split your application to components such as Stores, Controllers, Views etc. Then you can easily send data from server in JSON for example (using server-side technologies - php, java,...) and read it by Stores proxy. If you look into Samples & Demos they're also loading some bigger structures using php script which returns JSON.
Related
How to organize Vue-JS project [files and directory]: Non Javascript way?
Coming from a non-javascript background, I found Vue.js very intuitive and easy to use. My earlier experience in Javascript is with JQuery and vanilla javascript on the browser.
I created an application using Vue , Vue-components and vue router. Everything works fine.
My problem is, I have ended up writing a lot of code in a single index.html file of my project. This file contains over 10 templates that I have created and attached to different component in my app. I want to know that is there a non-javascript way to organize these templates in seperate files.
I see that there are options using webpack and browserify to modularize the project. But coming from non javascript background, I don't find them intuitive. I don't want to go node - npm way because that has its own learning curve and moreover it downloads a dozen of files and dependencies in my project which I don't understand. I am old school and more comfortable downloading the files and including them in the webpages.
So probably, you understand where I am going to. I need a solution where I could put my templates as separate files and read those files in the different components.
What I have tried :
Declaring the templates inside my components. But writing all that html inside the component is not that clean. It also, makes my JS file too huge. I am better in putting all data in the index.html instead.
Storing template as smaller chunk "homepage.html","about.html" and in my components, using $.get / $.load to read different components in ready function of the component. This works but I still have to fire an additional ajax call for each component which is not efficient.
Please refrain from suggesting the obvious node-npm [webpack and browserify] way. I know thats what is supported by Vue but this needs a learning curve and complete setup. Answer to this question would actually help other developers who hesitate going the node-npm way.
Please shout back if you need more clarifications to the question.
The options you've mentioned are your only real ones... the HTML of the template needs to be available when it's needed, so you either have to have it within your html file off the bat, or load it using AJAX or an in-browser loader like RequireJS (and this extension that allows it to load HTML https://github.com/requirejs/text).
In-file templates make sense for very small projects. As your project grows, you'll need to start using the tools that are built for this. NPM rocks and every JS package that you'll ever need can be included in your project in seconds.
I highly encourage you to try the Vue CLI
It does use node, npm, webpack and downloads dozens of files. Which you've you've explicitly asked for not to use, so let me clarify:
The Vue CLI takes care of the complexity and configures webpack for you.
You don't even have to know it's using webpack.
It's very developer friendly (it even has a built-in gui) and lowers the barrier to entry compared configuring a webpack config.
I hope you'll also find it "intuitive and easy to use".
I have two HTML files: One acts as a template, supplying the navigation, sidebars, etc., and the other has the main content. I'm trying to figure out how best to insert the content into the template. I need persistent URLs, so my plan was to have the content page essentially replace itself with the template, plugging the text back into the resulting page. I'm really new to front-end programming and I'm suspicious that this may be an anti-pattern, so my first question is about whether I'm barking up the right tree. The problem seems universal, and I'm sure there must be a best practice, though I haven't yet seen it discussed. If this is an acceptable way to proceed, then what JavaScript function would allow me to access the HTML of two different pages at the same time?
[EDIT: It's a small page on GitHub]
Do not do this. At current implementation HTML is not designed to be template engine. You can use HTML import but it has not full support in browsers. (compatibility table).
Usually this problem can be solved with:
Use frontend framework. Libraries like angular.js or polymer.js (and so on) usually has support of importing HTML documents in different forms.
Build your application HTML. Task runners like grunt.js usually has plugin that includes HTML.
Use server side technologies to extend your HTML from base layouts
If your application have to be consisted from different HTMLs I recommend you to try polymer. It is polyfill for web components and designed to work in such way by default.
UPD:
About edit to your question. It seems like you just need template engine for HTML. You can google for it. I use nunjucks - javascript port of python's template engine jinja2. It is lightweight, simple and can be compiled right in browser.
Another way is to use special tools for building static web pages. You have mentioned that your page is blog build from simple HTML pages. Try to use pelican. It is the static websites (blogs) generator. It is simple and fast. You can build your HTML even on your local machine and just push your HTML pages to github.
Ok I am trying to get my head round this whole backboneJS thing. I understand you have to separate your site into modules and break each module down into Models, Collections and Views like described in this example.
My JS file structure currently looks like this:
-js
-application.js
-lib
-jquery.min.js
-backbone.min.js
-underscore.min.js
-modules
-newsfeed.js //activity feed
-file.js // page to upload files to
-members.js // page that show other members of group
//-general-site-logic.js??
I have two questions:
Should all application logic be controlled from BackboneJS? If not then where should this separate logic reside in my application structure? Surely backbone can't control all of your client-side activity. What about activity that doesn't involve any collections?
Should I be using RequireJS to manage modules when using BackboneJS or not? I have found this example but it seems to complicate the already confusing concepts of Backbone even further.
I am about to embark on a very javascript heavy app and really want to get this right before my code begins to mushroom!
The great thing about Backbone is that it is just a collection of useful pieces that you can put together however you want. You can organize it however you want.
Surely backbone can't control all of your client-side activity.
Why not? I have a rather large client-side app where all of the code (aside from jQuery plug-ins and such) is written using Backbone constructs (Views, Models, Collections, Routers).
In our case, we are using Rails, so we don't need to worry about requiring other JS files. We break the project up into many js (coffee) files and the "asset pipeline" merges it all into one js file for us. (we do need to tell the asset pipeline some ordering rules, however... models before collections, collections before views, etc)
When we do this, we have the following setup:
-assets
-javascripts
-backbone
-collections
-helpers
-models
-routers
-templates
-views
-bootstrapper.js
Of course, that is how WE do it. For larger projects, I always know where to find my components and we create subfolders within for our different sub-views. For instance:
-views
-people
-people_list.js
-people_item.js
-orders
-order_list.js
-order_item.js
-order_form.js
On smaller projects, however, you can put everything in one JS file and it wouldn't be a problem. Most toy examples are laid out this way.
An intermediate layout might be something where you just separate your models from your views like this:
-models.js // models and collections
-routers.js
-views.js
I guess what you should get from this is: "Organize however you'd like". Do what makes sense for the project size and your team's understanding of organization.
Backbone provides structure. It isn't opinionated, however, to how that structure is designed.
If it helps I have a bootstrap, project starter integrating backbone.js, coffeescript, sinatra, jasmine and skeleton.
It'll get you started with project structure and save you time integrating the tech stack. Also uses skeleton css for responsive design.
I'm pretty new to Sencha Touch and am trying to make a simple application that has a login form and makes calls and fetch results into lists.
My question is, how should I create the structure of the application? Should it all be inside one .html file? or should I different pages for each list and the login page? If so, how can I change views from one page to another and get transition effects?
There is actually a generator which you can use to generate the canonical app structure. From the Sencha download, go to the jsbuilder directory, then run a command similar to this:
./sencha.sh generate app MyApp path/to/myapp
Also, this slide set demonstrates the structure, though you may have to dig for more of the philosophy for why things are where:
http://www.sencha.com/conference/sessions/session.php?sid=322
And here's the example app talked about in the discussion:
http://cl.ly/1d1S282O1Y2c3N1v1j1i
It's fine to use a single HTML file to get things started, but in the long run it's worth making the application structure consistent with 'best practices' so that others can look at, and understand, your code subsequently.
Sencha Touch generators (coming in v1.1) place the launch logic in a file called app.js and then have files for each model, view and controller (in respective directories).
While you may not be building a fully fledged MVC application from the start, you should probably still use these conventions. Take a look at the Twitter and Kiva apps in the SDK (and at http://dev.sencha.com/deploy/touch/examples/ ) foor good examples.
The index.html file can link to each file individually, but of course for production, you are also advised to look at the JSBuilder tool to package and minify them all so that the device can fetch them in one single HTTP request.
I would break it up by major function (i.e. purpose). For mobile apps, you want to avoid having unnecessary postbacks / loading multiple pages and views if you can help it.
If your mobile app has one purpose, I would keep it on one html page and only break up the JavaScript files as you need to keep it organized.
If it has two purposes (e.g. 1-to ENTER a bunch of information, and 2-to display reports on your data), then I would break it up into two html files.
For example, if you have a mobile app that takes you through a series of wizard steps to perform data entry (i.e. single purpose), I would house that whole wizard inside of an Ext.Panel (on a single page), and swap out each content Ext.Panel "step" of the wizard as the user progresses through the wizard.
Start with the simplest thing and refactor later. I've just done an app in Sencha Touch and it gets quite bewildering looking at the example files. I found the easiest way to learn was to create a single html file and as soon as something became unwieldy or obviously needed a refactor I started creating subsequent files.
I've just started developing an ExtJS application that I plan to support with a very lightweight JSON PHP service. Other than that, it will be standalone. My question is, what is the best way to organize the files and classes that will inevitably come into existence? Anyone have any experience with large ExtJS projects (several thousand lines).
I would start here http://blog.extjs.eu/know-how/writing-a-big-application-in-ext/
This site gives a good introductory overview of how to structure your application.
We are currently using these ideas in two of our ASP.NET MVC / ExtJS applications.
While developing your application your file and folder structure shouldn't really matter as you're probably going to want to minimize the release code and stick it in a single JS file when you're done. An automated handler or build script is probably going to be the best bet for this (see http://extjs.com/forum/showthread.php?t=44158).
That said, I've read somewhere on the ExtJS forums that a single file per class is advisable, and I can attest to that from my own experience.
I suggest users are willing to wait for an application to load, so we typically load all of JS during initial app startup. I suggest loading and eval'ing JS files as needed is unnecessary - especially when all JS will be minified before deployment to production.
I suggest namepsaces, one class per file, and a well-defined and well-documented class hierarchy.
When starting new big project, I decided to make it modular. Usually, in big projects not all modules are used by a particular user, so I load them on demand. F.e., if a project would have 50+ modules, the big probability is that user is working only with 10-.
Such architecture lets you to have the initial code relatively small.
Modules are stored on the server and loaded by AJAX call, eval'uating the responseText in AJAX callback. The only issue with this, you must keep track on module dependencies, which could be stored inside modules as well. I have a class called Module, and I check every new module instance for existance within the task. If it doesn't yet exist, I load it from the server.