I feel like there is relatively little documentation on the "best practices" of how one should go about organizing AngularJS code. For example, in many of my web pages, i.e.
index.php
profile.php
editprofile.php
There are often many factories and methods that I need repeated. For example, profile.php,, editprofile.php, and index.php all need the factory userDropdown (to get the top navbar dropdown menu). However, some of them need "modified versions of factories". For example:
index.php needs a way to get all the users and their information
profile.php needs a way to get some users information
editProfile.php needs a way to get only one user information
What I mean is that (and the above was a poor example), is that often many .js files needs some modified "child" of a "parent" factory. I find it hard to scale my application because profile.php, index.php, and editProfile.php all refer to their own factories and methods, not a base file. Changes, improvements, errors, found in one factory and is corrected, will not propagate into other files (which I find very frustrating). I also don't want to write /copy/paste services and factories over and over again. Other issue I've had is that:
X.js file need some providers that Y.js file doesn't. However, both needs providers A and B, but X needs C and Y needs D. Is it bad for me to use the same "factory" and providers" for both of them (i.e. inject A, B, C, and D into both of them?) That's the problem I see with having a base factory of a factory to serve a lot of .js files. How much space or inefficiency is it to define providers or injectable services that you don't use?
How do I accomplish some scalable angularJS code to do this, or how do you guys go about organizing your angular code? And also, what about repeating HTML templates (i.e. repeating HTML code that needs to be used in almost every page? I've heard of some service called $templateCache but couldn't figure out how to use it.)
https://github.com/johnpapa/angular-styleguide This also has an example app but seriously read through his guidelines they seem to be exactly what you are looking for and have been a great resource for me as I've been learning to build bigger angular apps.
Related
I am using angular seed project
https://github.com/angular/angular-seed
where should I put the services and directives ?
This is really totally up to you but there are some good recommendations on project structure here: https://docs.google.com/document/d/1XXMvReO8-Awi1EZXAXS4PzDzdNvV6pGcuaF4Q9821Es/pub
Typically my structure looks something like
app\scripts\user.js
app\scripts\todo.js
Where User.js would have a service and possibly multiple controllers in it... if the file gets too large then I break it up into parts.
The problem with grouping all services together and all controllers is that the services and controllers typically have a relationship (functionally). When you want to re-use the service/controller you are typically going to use them together, when editing one you usually need a reference to the other. This makes it easiest to find things and not have 1000 js files to include and manage in the dependencies and script inclusions.
Also when it comes time and you want to make a bower component out of one of the sections it's easier to see which parts need to be pulled out.
You can make a folder for each under app, so your project tree will look like this:
app/directives
app/services
I'm thinking of moving my site to angularjs, and I want to start very small, by moving all my static server-side plain-text templating from django to angular (otherwise there will be syntax trouble with the '{{}}').
It seems that the best way to do that will be one of two options:
To have an ajax call that returns a JSON with all the texts of my site. The texts will be stored in a variable which is binded to my HTML elements so angular will update everything.
To store a static js file with the dictionary and include it in my HTML and bind the dictionary with angularjs.
Both options will allow me to switch between languages without reloading the page.
Which one is better? In general, is this a good approach or is there a more correct way?
I tried out a few different options, including Angular Translate, but I liked Angular-gettext the best so far.
One thing that helped tremendously is that there's a working demo for it where they i18n TodoMVC, called angular-gettext-example.
The workflow is simple:
Add the "translate" directive to your templates
Run grunt to extract .pot template(s)
Hand off the .pot to your translation vendor or DIY with POEdit or similar software
Drop the .po translation files back into your project
Run grunt to compile the .po files
Set the default language in your scope
Watch the magic!
I'm sure the other solutions posted here are good as well but I haven't seen an end-to-end example so nicely organized as angular-gettext-example.
Cheers,
JD
First of all, there is a way to change angular's delimiters to other symbols as answered here: Angular JS custom delimiter
The 2. option is easier. You include it once and you have all translations on page load. No async calls, no promises, nice and easy.
And yet i'd go with the first one. Services like $translate would really make your life easier following option 1. Plus it has many options for loading and storing loaded data in LocalStorage and cookies, so there's plenty of space for extension and customization. You can then translate your content with $translate service, directive or filter.
And don't forget that 2 option disables any options of cached requests. On each request to your start page the server has to read static file and include it in the html. With first option the user's browser can cache .json for as long as you like.
AngularJS supports il8n/L10n for currency, date and numbers filters only. According to this book:
(sorry for the low quality! cell phone camera)
I would say follow the first approach and load the translation dynamically. It would involve a lot of work but there's no other way around
Have a look at angular-translate :)
It solves both scenarios!
So, I'm in the midst of my first major project with Angular. I have one controller that is doing a ton of the legwork, and it's reached the point where it's thousands of lines of JavaScript.
I'd like to break this up somehow, but I can't seem to find a solid example anywhere. The code is mostly made up of functions used to do calculations on objects, so directives and modules don't seem like the right answer, but I could be wrong there.
How are you guys organizing code in your large Angular projects? Should I just suck it up, or is there a sane way to split this into easy to scan files?
I suggest putting at least some of those objects and their related calculations into services, then inject the services into your controller(s). See the Sticky Notes Part 1 blog entry for an example of a service that encapsulates some data and provides methods to access/manipulate that data.
See if you can break up your controller into multiple controllers, one for each view. A view can be as large as a page, or just some chunk/block on a page.
To quote from a google group post I saw recently: "I prefer to think of angular controllers as dumb apis/configs for my views and leave all the heavy lifting to services." -- reference
There are a few things that you need to ask yourself when you are in a controller.
Are you doing any DOM manipulation in the controller? This is a definite NO. Dont ever do that. It always belongs in the directives department.
Are you writing any Business Logic in your controller? That too is a NO. Your Business logic should in most cases exist in a Service. That is the right place for it.
Now, have a look at your controller. Is it devoid of these 2 things and still larger than 1000 lines? It is highly unlikely, but even if it somehow is happening, then consider breaking down your controller into smaller controllers. This breaking of controllers have to be done based on the view.
To sum things up, your controller is just a place where you glue up the business logic and your views in the HTML. It should technically never contain anything other than these glues.
I usually create a Util factory (seems to be the way to go now in Angular rather than services) and have it return any shared logic as a set of methods.
https://gist.github.com/lamba/c275f5f010090632209e
I'm trying to make an App-wide media-upload which should have the possibility of being accessible from every controller/model.
I thought of on table media which holds record of all uploaded files, my schema looks like this:
id
controller //to keep the reference from which controller the file was uploaded
foreign_key //since files should be uploaded to specific records, I need this id
filename
extension
fullname
size
created
modified
I'm not sure what would be the best approach in doing this. I've thought of components, plugins and a behavior but still am unsure.
My App has many different controllers with different records.
For example it manages projects and should now be able to attach PDFs to specific projects from within the project-edit mask.
Since this is a feature needed by other controllers, too I want to write it application wide.
I'm pretty sure I need a helper to call the upload-function from within the masks.
May something like: echo $this->Media->uploadMask(); which provides me with an ready uploading-mask for the controller and id I'm editing at the moment.
But I don't know which route I should call for the upload. Something like /media/upload would be very good, but I'm not sure if this fits correctly into the MVC-approach.
Would it be better to call it from my specific controllers? Or is an AJAX-upload to just a normal controller/model like better?
What you are describing is a Behaviour, which is basically an object of methods that can apply to any model. For controllers there are also Components.
There are already a couple of established upload behaviours for CakePHP you should check out: Meio Upload which is good for basic image manipulation and also the CakePHP Media Plugin which is more advanced and more recently updated.
I'm developing a CakePHP application that we will provide as a white label for people to implement for their own companies, and they'll need to have certain customization capabilities for themselves.
For starters, they'll be able to do anything they want with the views, and they can add their own Controllers/Models if they need to add completely new stuff. However, I'd rather advise against touching my controllers and models, to make version upgrading easier.
Esentially, the customization capabilities I'm planning to give them are going to be quite basic, I just need to call "something" when certain things happen, so they can do things like update external systems, e-mail themselves/the clients, things like that.
I'm wondering what's the best way to do this?
My plan is to have a "file" (with one class) for each controller of mine, to keep things reasonably organized. This file will have a bunch of empty methods that my code will call, and they'll be able to add code inside those methods to do whatever they need to do.
The specific question is, should this class full of empty methods be a Component? A Controller? Just a regular plain PHP class?
I'll need to call methods in this class from my Controllers, so I'm guessing making it a Controller is out of the question (unless maybe it's a controller that inherits from mine? or mine inherits from theirs, probably).
Also, I'd need the implementer of these methods to have access to my Models and Components, although I'm ok with making them use App::Import, I don't need to have the magic $this->ModelName members set.
Also, does this file I create (etiher Component or Controller) have to live in the app folder next to the other (my) controllers/components? Or can I throw it somewhere separate like the vendors folder?
Have you done something like this before?
Any tips/advice/pitfalls to avoid will be more than welcome.
I know this is kind of subjective, I'm looking to hear from your experience mostly, if you've done this before.
Thanks!
Two ideas that spring to mind:
create abstract templates (controllers, models, whatever necessary) that your clients can extend
write your controllers/components/models as a plugin within their own namespace
Ultimately you seem to want to provide an "enhanced" Cake framework, that your clients still have to write their own Cake code in (I don't know how this goes together with your idea of "basic customization capabilities" though). As such, you should write your code in as much an "optional" manner as possible (namespaced plugins, components, AppModel enhancements, extra libs) and provide documentation on how to use these to help your clients speed up their work.
I would setup a common set of events and use something like the linked to event system to handle this.
That lets the clients manage the event handler classes (read the readme to see what I mean) and subscribe to and broadcast events application-wide.
Also - if you want to have your users not muck about with your core functionality I recommend you package your main app as a plugin.
http://github.com/m3nt0r/eventful-cakephp