https://github.com/zewa666/durandal-multisite

Durandal multisite example
https://github.com/zewa666/durandal-multisite

Last synced: about 12 hours ago
JSON representation

Durandal multisite example

• Host: GitHub
• URL: https://github.com/zewa666/durandal-multisite
• Owner: zewa666
• License: wtfpl
• Created: 2014-07-25T11:49:11.000Z (over 10 years ago)
• Default Branch: master
• Last Pushed: 2014-07-25T12:11:43.000Z (over 10 years ago)
• Last Synced: 2023-04-06T14:20:36.314Z (over 1 year ago)
• Language: JavaScript
• Size: 1.11 MB
• Stars: 1
• Watchers: 1
• Forks: 0
• Open Issues: 0
• Metadata Files:
  • Readme: README.md
  • License: LICENSE

Awesome Lists containing this project

README

        
Durandal Multisite Demo

===========



This is an example of how to structure a [Durandal SPA Framework](http://durandaljs.com/) application with a frontend/backend by still reusing the same codebase.

You will see the two entry points frontend.html and backend.html, which could of course be renamed to index.html when deployed

to custom locations.

The idea

-------------------

The separation of front/backend happens by utilizing two separate main.js entry files namely main_backend and main_frontend

Their main purpose in this example is to provide a require mapping list for module aliases.

Why?

Well here the separation of the two apps comes into play.

Let's say we have a simple Login screen (viewmodels/login | view/login) but would like to allow different logins for the resepective entry points.

So instead of creating a duplicate we just exclude the login function to a service module which is provided in two flavors.

The require.js mapping now handles the magic to bind the proper one.

The call to the service happens in viewmodels/login.js

```js

vm_login_frontend.prototype.performLogin = function() {

  var loginService = require('businesslogic/loginService');

  loginService.performLogin();

};

```

note the require call which asks for a loginService without detailed entry point specification.

In case we started with the main_frontend the requirejs map will now map this alias to the specific implementation

of loginService.frontend.js

```js

map: {

    '*': {

        'businesslogic/loginService': 'businesslogic/loginService.frontend'

    }

}

```

That way not only we enforce separation of concerns by encapsuling exchangeable functionality in modules, but also handle

the proper loading via AMD.

How to build/deploy?

-------------

If you care about proper building and deploying scenarios take a look at the [Gulp Durandal Docs][http://durandaljs.com/documentation/Gulp.html].

In this case you should think about moving the businesslogic folder out of the app folder and setup your gulp task to include the specific implementations

you are deploying.

More information

----------------

For more information about Durandal please consult

the Durandal online docs at:

http://durandaljs.com/docs.html