anchor.diff: -= Modular AngularJS Application
  +//= Modular AngularJS Application
  += AngularJS アプリケーションのモジュール化
   
   In this section we continue <<_spring_and_angular_js_a_secure_single_page_application,our discussion>> of how to use http://projects.spring.io/spring-security[Spring Security] with http://angularjs.org[Angular JS] in a "single page application". Here we show how to modularize the client-side code, and how to use "nice" URL paths without the fragment notation (e.g. "/#/login") which Angular uses by default, but most users dislike. This is the seventh section of a tutorial, and you can catch up on the basic building blocks of the application or build it from scratch by reading the <<_spring_and_angular_js_a_secure_single_page_application,first section>>, or you can just go straight to the https://github.com/dsyer/spring-security-angular/tree/master/modular[source code in Github]. We will be able to tidy up a lot of loose ends from the JavaScript code of the rest of this series, and at the same time show how it can fit very snugly against a backend server built from Spring Security and Spring Boot.
   
   [[breaking-up-the-application]]
  -== Breaking up the Application
  +//== Breaking up the Application
  +== アプリケーションの分割
   
   The sample application that we worked with so far in this series was trivial enough that we could get away with a single JavaScript source file for the whole thing. No larger application will ever end up that way, even if it starts out life like this one, so to mimic real life in a sample we are going to break things up. A good starting point would be to take the "single" application from the <<_the_login_page_angular_js_and_spring_security_part_ii,second section>> and have a look at its structure in the source code. Here's a directory listing for the static content (excluding the "application.yml" that belongs on the server):
   
  
positive.code: This is the Angular JS dependency management system in action. Other frameworks have similar (and arguably superior) features. Also, in a larger application, you might use a build time step to bundle all the JavaScript together so it can be loaded efficiently by the browser, but that's almost a matter of taste.
  
  [[using-natural-routes]]
  == Using "Natural" Routes
  
  The Angular `$routeProvider` by default works with fragment locators in the URL path, e.g. the login page is specified as a route in `hello.js` as "/login" and this translates into "/#/login" in the actual URL (the one you see in the browser window). This is so that the JavaScript in the `index.html`, loaded via the root path "/", stays active on all routes. The fragment naming is a bit unfamiliar to users and it is sometimes more convenient to use "natural" routes, where the URL path is the same as the Angular route declarations, e.g. "/login" for "/login".  You can't do that if you have _only_ static resources, because `index.html` can only be loaded one way, but if you have some active components in the stack (a proxy or some server-side logic) then you can arrange for it to work by loading `index.html` from all the Angular routes.
  
  
negative.code: ____
  
  [[conclusion]]
  //== Conclusion
  == 結論
  
  In this section we have seen how to modularize an Angular application (taking as a starting point the application from <<_the_login_page_angular_js_and_spring_security_part_ii,section two>> of the tutorial), how to make it redirect to a login page, and how to use "natural" routes that can be typed or bookmarked easily by users. We took a step back from the last couple of sections in the tutorial, concentrating on the client-side code a bit more, and temporarily ditching the distributed architecture that we were building in Sections III-VI. That doesn't mean that the changes here can't be applied to those other applications (actually it's fairly trivial) - it was just to simplify the server-side code while we were learning how to do things on the client. There _were_ a couple of server-side features that we used or discussed briefly though (for instance the use of a "forward" view in Spring MVC to enable "natural" routes), so we have continued the theme of Angular and Spring working together, and shown that they do so quite well with small tweaks here and there.
  