I've been reading alot about AngularJS and I just absobutely love the concept behind it and want to get my feet wet. I've read up on several tutorials and eventually downloaded Visual Studio Template SPA and that's where the "fun" stops. The way I see it - using that template seems to go against the grain of creating a SPA - there are very little examples to go on.
By default, the SPA Template installed sets up this like:
app
app_start
Content
Images
Routing
Scripts
Vendor
app.js
controller.js
(the rest you get the idea)
Views
you get the idea.
The question is really bugging me. For example,I want to insert a hockey player and coach page (two separate SPA) to work under the current masterpage content. This is where I'm a bit lost on "separation"
The way I see it, I would have to add a route to app.js and a controller to controller.js for coach and player but I don't like that because I want to separate the player and coach controller code and put it under the player and coach modules like this.
But what I tried to do and fail is:
Module
Player
playerApp.js
playerControl.js
player.cshtml
Coach
coachApp.js
coachControl.js
coach.cshtml
I'm struggling to "hook" them up. I certainly do not want to put the coach controller and the player controller in the control.js file under the scripts folder and the views (player and coach) under the Views folder. It would become too difficult to read and eventually become messy.
Any guidance would be appreciate on what I should be reading on.
thanks,
This is somewhat of an opinionated question and answer, but I want to offer one possible scenario which I have found works well.
Unless you have a compelling need for Razor (i.e. existing user controls), your path of least resistance is to not use ASP.Net MVC at all. Instead, you can leverage ASP.Net WebAPI, which operates similarly to MVC, but provides a REST interface to handle JSON data instead of using Views and Server Routing.
In your Web App, you can simply use a single index.html which can be hooked up with angular, and your individual modules can be separated without needlessly being concerned with multiple "app" pages, how to interact between them, etc.
On the server, you can either run the WebAPI from a different URL, or more commonly, from something like http://yoursite.com/api/. IIS would be configured to redirect anything that is not static files (.css, .js, images, etc.) or api calls back to the single index.html.
Related
I have recently worked in a pure Scala-Play application and later in a pure AngularJS application. I'm very impressed with both and I'm wondering what is the sweet spot of combining the two frameworks together. Since the two frameworks can be complementary but also overlapping in different areas e.g. MVC and page routing, as far as I know these are some of the possibilities:
Single Page design, use AngularJS MVC-only and use Scala-Play as "dull" service layer backend with no full page refreshes.
Allow page reloads and each page reload becomes a different AngularJS root application. This seems quite flexible e.g. the client side is not bloatted with so much data for larger applications but better partitioned for the different use-cases. The downside is that I'd need different AngularJS MVC applications and I'm not even sure how to organize it as a project. Are there examples of this?
Typical server side Web App, use Play MVC-only and AngularJS for handling UI models for each separate page.
My choice of IDE for these types of architecture would of course be WebStorm but unfortunately I can't have all client-side (AngularJS and JavaScripts) and sever-side (Scala-Play) codes in a single project.
I believe that there is no the ultimate optimal architecture for combining Play and Angular. It depends on the specificity of the project, team etc.
The decision to develop UI part with Angular and the server side back-end with Play is very reasonable. Technically it may be done as following:
Development:
Both parts are developed as detached projects with the preferable IDE.
The client should have some entry point HTML page. It is reasonable to name it index.html, but is may be any other name.
For client-server integration do on the Play side as following:
Select a sub-folder under the play application root, which will serve as the "home" for the client files. The default solution is to use the folder public, since all files under it are automatically deployed.
All client files should be copied under the public folder. The files may be organized in any structure.
Add a route for the default URL as a route to the index.html. The argument path in the route should be the full path of the index.html relatively to the application root.
If index.html is directly in the public folder, the route is like this:
GET /defaultUrl controllers.Assets.at(path="/public", file ="index.html")
Add routing to the client files:
GET /*file controllers.Assets.at(path="/public", file)
Now the distribution package will include all the client files.
Putting of the client files into the public folder should be done automatically, for example by organizing the client directory structure and appropriate configuration of the client IDE.
You can find more examples in this post.
I was wondering if anyone could help me at all.
I posted a previous question in regards to this title but I didn't receive much of a response (probably due to lack of information).
I started out with an Ionic Application and built the view files using state URLS to navigate from page to page in the WWW folder. I've then created corresponding controllers for the view files, for basic calls and functionality that I want my app to do in the front-end via Ionic.
My question is how do I setup MongoDB + Mongoose so I can have access to the models I have created?
I have scoured the internet but to no avail, I mean I know there is no set way to define a model within this type of application but some general guidance would be really appreciated.
I understand that when building an application with Angular you're essentially building 2 applications, the front-end where your CSS, JS and HTML goes with the front-end frameworks on top of them.
Then the backend application that runs the server, stores data and runs the business logic. This is where I have created the User Schema model for my application and have inserted a document into my database via the MongoDB shell whilst running mongod.
However I also created a users.js in another models folder in my front-end where I'm returning a resource following a url with either a get, save, query, remove or delete.
First of all I would like to say I'm relatively new to building mobile applications so this may even be entirely wrong and secondly up to this point I get lost as to what to do in my application.
I have tried setting up an express server in my app.js file and I can connect to it via my terminal as it is listening on the port number, but in the browser it is coming up with cannot /GET.
If you need any more information please feel free to ask, I know I haven't really gone into any technicals, but I'm really not sure even if I'm asking the right questions to begin with.
Thank you in advance.
I want to use Symfony2 as back end to create a REST API and use AngularJS as front end. The 2 are completely separated ie Symfony 2 will not render anything, it'll just send json data to AngularJS.
I'm not sure on how to configure my web server (nginx).
The Symfony documentation gives the configuration but it's intended for a site that only uses Symfony, and so everything outside of the /web/ folder is not accessible.
I can see several possibilities:
Create 2 different directories (eg /path/frontend and /path/backend) and a corresponding website for both. I would then have 2 different addresses to access the front end and the back end (eg http://myfrontend.com and http://mybackend.com). The problem I see is that I probably won't be able to directly use AJAX calls in AngularJS.
Create 2 different directories (eg /website/frontend and /website/backend) and only one website. I would then probably need to access the front end and back end with something like http://example.com/frontend and http://example.com/backend. I'm not sure how to configure the web server though (issue with root /website/backend/web).
Put the AngularJS directory inside the web folder of Symfony, but then I'd need to also change the configuration so that nginx doesn't only server app.php, app_dev.php and config.php.
Put the AngularJS directory in the src folder of Symfony, and have Symfony handle the routing. I don't know if it will mess with AngularJS' one routing. Also I will probably have a few other php that should be accessible, so I'd need to route them through Symfony also.
What would you suggest and why? Maybe I'm missing something obivous?
I guess you could accomplish your task using any of those methods. It would come down to how you want to structure you application and what it's objectives are. For large scale projects the first method (having the API separate from the AngularJS) would serve you well. Twitter really made that software model big.
So I would suggest going with method one. All you would have to do is specify an Nginx header in your server block that allows cross domain access to another domain. So you would specify the following directive in your frontendangular.com site:
add_header Access-Control-Allow-Origin backendsymfony.com;
This way every time a page request comes in on your front end app Nginx tells the browser that it is safe to access another domain (your symfony setup).
These are 2 frameworks that both have powerful routing capabilities, and it looks like you are going for a best of both worlds. There are many pros and cons to any setup, so I'll list a few that come to mind:
Angular routing / templating is great but it will leave you with SEO and meta issues to solve . It's probably better to manage your major pages with symfony2 and any routing within each page with angular. This would allow you to still make dynamic pages w/out compromising your meta and SEO control. Access Control seems flexible but probably not necessary, I would just put all calls to REST API under http://www.thesite.com/api and if I need another setup something like https://api.thesite.com, nginx can route or proxypass this without leaving the domain.
Locating partials gets a little wonky but that's probably fine for a large application. Just note that you will probably need to search the js location object for [host] / [path] /web/bundles/someBundle/public/blah.... Or you can setup a '/partials' path in nginx.
Twig and Angular tpl may end up a confusing mix as they both use {{foo}}. This alone would make me reconsider mixing the 2, and I might look to go with a frontend server, like node with ejs where I could also benefit from the streaming transfer of the data sent from the API.
You can get around it easy enough with but it's still concerning:
angular.module('myApp', []).config(function($interpolateProvider){
$interpolateProvider.startSymbol('[[').endSymbol(']]');
}
);
You do get the benefit of angular partials as symfony twig, which can be good or bad depending on how you see the flexibility being used. I have seen guys making examples of forms that fill out values with symfony data, but they are just undermining the power of angulars binding.
Don't get me wrong, I actually do really like the idea of the two harmonizing.
Just food for thought - cheers
I'm new on angluarjs and trying to build an example-application.
This application is divided into 3 parts/sections:
A.) map
B.) "received"-area
C.) "send"-area
Every section has its own layout/view-area, not visible at the same time.
In part B.) you can load information from server by click or automatically, which will be displayed in part "B.)" as text and in section "A.)" as map-marker.
Additionally you can click inside section "A.)" to set a new marker.
In section "C.)" there is a send button to take the new marker from "A.)" in order to send this to the server.
Currently: all of the sections (A,B,C) are angular modules/own apps.
But I don't know, if that is the right way/best practice.
An other way could be a single module for the whole page an 3 controllers (A,B,C) which handle the logic for sections A,B and C.
What is the right way in angularjs?
From your description, I recommend designing it as a single AngularJS app with separate controllers for each view. It sounds like you would benefit from using an angular service to handle the client-side business logic and cache any shared data/models that could be used by the views. It is a best-practice in Angular to keep the controllers pretty lean and focused just on the view setup/binding and orchestrating the access to the services.
After searching the way to get some inspiration, i decided to realize the following think:
For all the self-made code, I use one module for the whole application and for all the external things, bundled with external plugins and services, I take a different module. This means: pne module for each "service-plugin bundle" (like google API & angular-google-maps plugin)
So I can switch the module, if the external service does not work, etc.
Looking at my example in the question this means:
Application part A: the map and all the map-specific things (set new marker, draw circle, etc) are insight a map-module. If I decide to use open street map instead of google maps i will plug in an new maps module
Application part A and B: this is my "main" app module with different controllers.
I am starting to develop a business spa application (mobile/desktop web app) with Play Framework 2 and AngularJS. Right now I am tending to go with following solution:
Play behaves as a RESTful application
Play also pre-processes partials
AngularJS handles the rest
My arguments for pre-processing partials are:
Play can remove parts of a partial for a more compact mobile view
Different user roles see more/less content of the partial
Correct language will be loaded into the partial
Are there any disadvantages with this approach? Do you think this would be the best solution for the project's requirements?
Server-side templating is usually what you want to get rid of when building an SPA. In general this should work, but there are a couple of disadvantages:
You are mixing two template languages, Play and AngularJS, so you must be careful not create an unmaintainable mess
Your display logic will also be distributed or duplicated between Angular and Play; in a pure RESTful approach Play would mostly be concerned about access control and JSON (input, output, validation)
You must create a route for every partial instead of just using the assets route
Server side templating slows down compilation speed
Returning different content depending on roles and desktop/mobile might mess with Angular's $template cache
Different user roles see more/less content of the partial
This should be handled by Angular IMHO, Play would just make sure to only serve the appropriate JSON to the right users.
Correct language will be loaded into the partial
How would you reuse Play's Lang in Angular? Build an inline variable? Again, just load it via JSON when the app bootstraps.