I'm completely new to Angular. I currently have a Django app that acts as a JSON-serving API (using Tastypie) and also serves up a few static pages for things like user registration, invitations, and viewing events.
Eventually, we're going to have a webapp that interacts with the Django API in all kinds of ways and makes total sense as a single page web app written in Angular (or something similar). However, as it stands right now, I just want to separate out these relatively self contained pages (mostly forms, confirmation pages, and event viewing pages) into their own app.
Since eventually everything is going to be in Angular, my thought is that I might as well start making these things in Angular, even though Angular's architecture doesn't seem very tailored to small forms and other things that will likely just be linked to from email messages.
Does it make sense to build these things out using Angular, setting up the necessary service/factory calls, making controllers for the form/event viewing pages, etc.? And if so, what's the best architectural decision in terms of modularity? Should every part of the app that "stands alone" (i.e., doesn't really interact with other parts of the app) be a separate Angular module?
If they are literally separately loaded pages and you eventually plan to have these pages be part of a single page angular application, Than what I would do is:
Create angular modules that have the same variable name for all seperate pages so like var app = angular.module('blah',[])
I'd link all my controllers for each individual pages at the time to their specific "app" module app.controller('blahCtrl',function(){}); ...
You boot these modules separately on their respective pages for the
time being
then when you do make the transition to moving it to one module where everything is in one page you can simply port the controllers because they will all belong to a module represented through the variable "app"
Related
I have a requirement to develop multiple Angular 2 applications independently by various teams. Each team will have independent releases scheduled. Towards the end, all these applications will need to be injected into one main application at runtime. They will need to work as a Single Page Application.
We tried Lazy loading modules of Angular 2. One of the roadblocks we see is that we cannot compile the main application using web pack without having the lazy load modules in the project solution.
Here is the structure of my present solution:
Image1
This is how I defined the routes
image2
We have defined two routes that lazy loads two modules(LazyModule and MoreLazyModule). This solution works fine.
When we remove those modules from the solution try to build it using web pack, the compiler throws an error.
Is there any way we can decouple the modules to develop them as independent projects and inject those modules in production?
Lazy Loading is the solution for your problem (at least as far as I know).
If I understand correctly, what you are trying to build is an app which has an external container (app.module and app.component) which need to orchestrate several other independent apps. The whole thing needs to behave as a Single Page Application.
If this is the case, then what I suggest you to do is the following:
have a team (or an individual responsible for all the code of the
Container app (app.module, app.component, any other common code you
may want to share among the various apps) - the Container app
references all the subApps (and gets updates as soon as a new subApp
is added)
have different teams responsible for the different subApps - these
teams work on the code of their competence, submit to the code
repository when ready, but use the entire project (i.e. also the
subApps of the other teams) any time they build
I do not see any issue in organizing the work like this, as soon as every team checks in the code to the central code repository only when all tests have passed (and the tests cover the application functionalities thoroughly). The coordination effort required to the team responsible for the Container app is really minimal.
I'm thinking about making something with the MEAN stack. I need a way to edit the content of the site, like e.g. Wordpress offers (basically a CMS).
The confusing bit is how the CMS and Angular would work together. I've looked at a CMS named Keystone, and there you have to set up some routing etc. in Node. Won't this crash with the routing you set up in Angluar?
In other CMSs I've used, the creation of the views happens on the server side. In Angular, as far as I understand, you crate a HTML template, which you can populate with data in an angular controller. This also seems like something that could crash between CMSs and Angular. Is this the case?
Is there any other quirks or similar about Angular and content managment systems I should know about, or is it usually not much problems integrating the two?
meanjs.org has a pretty good approach to this. Install meanjs. It comes with a sigin/signup and even allows you to create articles from the vanilla install.
Put simply, when you are creating a web app with the MEAN stack, think of AngularJS as "THE" app, and node.js as the api.
If you approach building your web app as a javascript application (AngularJS), that happens to get its data from an server api (node.js), then you will begin to understand how to properly use the MEAN stack.
First: Angular will have the routes defined in the $routeProvider. Build the routing urls in AngularJS first. They are "THE" routes for your web app. A good way to look at it is to build the AngularJS portion with the ability to change your api server, even to another language (PHP, python, go, etc) if necessary.
Second: Build your AngularJS to communicate to the api with $resource. Essentially a $resource is an easy way to call out to an api using restful routing. This "restful routing" is now the routing that needs to be "mimicked/copied" into the routing for the node.js routes.
Often the AngularJS routes (the url) will match the $resource routing that matches the node.js routing.
Again, take a look at meanjs.org and you will have a better understanding on how to properly organize what "seems like" (and actually are) two separate apps.
Basically, you need three sets of routes (or two if you are doing it on the cheap).
Start out with a set of routes on the server that return regular webpages. Forget about JavaScript. Do not involve Angular at this stage.
Second, add another set of routes on the server which return data in a rawer form (such as JSON). This would typically be a RESTful API.
Third, add Angular to the client. When the view needs to be updated, update the URL in the browser and use Ajax to hit the RESTful API to get the data needed to populate it. (You want the URL you set the address bar to to match the URL of the page from the first set of routes that you are duplicating with JS and the data from the RESTful route).
If you are doing it on the cheap, like Gawker did, then you would skip the first set of routes and go direct to the JS+REST approach.
I think you need CMS on MEAN stack development environment.
there are some cms on mean stack you can try.
PancilBlue
Calipso
try this.
I was trying something similar, I found this link very useful AngularJsCMS It has told about free respond cms which is based on angularjs and have the ability to create pages like wordpress and manage contents.
We have been working on a project using angular and keystonejs. Simply serve the default template layout found in keystone and inject the data-ng-view tag within the body tag. Serve this template for all requests to '/'.
Then write your angular app normally to consume endpoints. These endpoints can be done in keystone using the api middleware. In the routes/index.js file add a key/value pair in the routes object with the name of your custom endpoint then import the folder containing your endpoint function definitions.
var routes = {
views: importRoutes('./views'),
api: importRoutes('./api')
};
exports = module.exports = function(app) {
app.get('/api/posts', keystone.middleware.api, routes.api.post.index);}
I recently migrated my blog over to MEANie - a lightweight custom MEAN Stack CMS that I developed.
I made it open source for anyone to use and posted details and setup instructions on my blog at http://jasonwatmore.com/meanie.
So I've been doing a lot of learning on Backbone, Sass, RoR, Bootstrap, etc. and I am extremely frustrated that no sources I've found (including in Tuts+ and Code School) mention any way of putting it all together...I have no clue how to style a web page if all of the contents I want in the page are being built through backbone...so if I want to click on the "About" page on a website, have all that page's Backbone contents styled correctly when appended to the DOM.
Secondly, I'm not sure how I should be creating these web pages for a website; should I be creating the whole page in Backbone and then keep that on the server until someone clicks on, for example, that "About" page and then have the whole page loaded into the view? Or am I totally misunderstanding one of the ways you can use Backbone? Along with this then, how am I supposed to communicate Backbone to a Ruby Server? just using Ajax?
I'm looking for sources and anyone who can help me understand this stuff in clear terms!
Thanks so much,
-Stu.
Presuming that you want to build a single page app it is important to understand each one responsibilities:
Rails
Create a full stack application that runs on server
Create a consumable API
Manage assets pipeline
...
Backbone
To manage your frontend javascript application
Decouple data from the views using Models
Connect an API over a RESTful JSON interface
...
Keep in mind this is a oversimplification of both...
Rails will handle the backend, retrieving an API to be consumed by Backbone. The Rails assets pipeline will deliver all files that Backbone needs, including the css that will style you app.
It might be somehow confusing since you will hear concepts that eventually will clash between them, like in both ends will have Models, Views and Router, but they will live live independently from each other, one will work on the server-side (Rails) and the other on the client-side (Backbone).
To give an example:
Rails would render:
domain
|-index.html
|-js/*.js
|-css/*.css
`-api/*.json
Backbone would use the DOM (index.html) and the js scripts to execute logic, append the views into the DOM and Read/Write data using ajax through the API.
Another confusing thing would be views, since Rails will generate those for you, and backbone will also have their own views, so the usual setup:
In the client-side, Backbone will be have at least the following parts:
Router — it will orchestrate your app, binding an event a route, let's say /#about page and create a view and pass the respective model:
Model — it will request data from the API and dispatch an event when done
View — it will use a template to render the model data
In this case Rails would manage the page assets and provide the API, Backbone would have it own router, models, views and templates to render the page on the client-side.
This also means that the way you combine both it could be only answered regarding the project specificities, and there a lot of ways to use both.
That said, IMHO it's really important to first understand how a full Backbone app works,
then use something like backbone-rails gem, to see how both can be managed in a consistente way.
I know what you mean--there's a lot of random tutorials out there for Backbone but not a lot that put it all together. To a certain extent that's just how it is, unfortunately, but I'd say once you're past learning the basics from Code School and others, the hands down best resource for how to actually build complicated apps is:
BackboneRails: http://www.backbonerails.com/
It covers the stack you're talking about mostly. The first few screencasts are free and then subsequent ones are paid but well worth it. Building on the skills I've learned from BackboneRails and I've built several fairly complicated apps that turned out great. Good luck!
For our single page app, instead of having a set of defined views and viewmodels that live on the server as .html and .js files, we need to build a system where the views and viewmodels are created in “real-time.”
This will be an intranet app and we want end-users to be able to define what they see and use in the app as they are using the app. For example, end-user A creates view1, view2, and view3, while end-user B chooses to create view4 and view5, and so forth. These views are then created in the browser session and saved somehow for the user for the next time they use the app.
They can name these views whatever they want (e.g., dashboard 1, plant view 2, etc.), and then they can select one or more “widgets” to be on each view. A “widget” would be a contain set of JavaScript/HTML/CSS code, similar to user controls in the web forms world, and would perform its specific function and be able to be draggable and resizable. Of course, all the widgets that the user has added to each view will be saved for subsequent uses.
So, each time end-user A opens the app, they’ll see their 3 views as tabs across the top (named whatever they named them when the views were configured) and they’ll be able to navigate to the view and see and interact with the widgets they chose on each view.
Our app will sort of be like Trello in which the views can be added, updated, deleted, etc. by the end-user and “widgets” can be added to the views dynamically, moved around, deleted, updated, etc., all in a dynamically created way.
In studying SPAs, the views and viewmodels are developed as actual physical files that live on the production web server and provide the functionality intended to all users. But, our SPA needs to be more dynamic in terms of what views/pages are available.
Can Durandal be used is this sort of scenario? If so, any guidance on how to do build such a thing?
Or, is this not possible with Durandal? If so, what’s a better path for us?
As a last resort, would we need to create some sort of html and JavaScript generator that will output files after the user has selected the configured options?
Or?????
Thanks for your help!
durandal is a framework for aiding in creating single page applications (SPAs). SPAs are essentially just a website that feels like a desktop application.
Your only limitations on what you can create are the limitations of the browser.
Anything you can build that runs in a browser.. can be used in durandal.
You can have multiple spas inside of 1 spa.
You can dynamically download css/html/js if you need too.
There are lots of options on how you can structure you application.
There's nothing stopping you doing this I think.
You can have flexible routing as you define the routes on Durandal start-up so you could use the saved view data to help construct this. But I have a feeling you basically want a shell that other mini applications sit in? Are your views/widgets completely separate to the main application? If so, you might not really need custom routing.
I was working on something similar. I was using iframes to host the applications and the user was able to move them around. I didn't get as far as persisting what the user had laid out though.
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.