from the docs:

The patterns "{foo}{bar}" and "{foo}/{bar}" match exactly the same requests, a single trailing slash at the end of the request is ignored, so {foo}/ matches same requests as {foo}

that is not true on version 0.5.0, not sure if bug was introduced on a previous release or not.

I noticed if you define a rule that is an array of acceptable values on a route, the matching algorithim in crossroads does a case sensitive match against the the acceptable values. Is this the expected behavior? I would assume such a match would be case insensitive. It also doesn't mention anything about case sensitivity in your documentation.

var route = crossroads.addRoute("/{controller}/:action:", function(controller, action) {
    // do stuff...
});

router.rules = {
    controller: ["testcontroller"]
}

crossroads.parse("/TestController/action");

Thanks for writing this library. It's been a great help!

check amd-utils/string/typecast

@koistya suggested on #42 a new type of capturing group {id*}

// {id*} matches the rest of the path including / symbols
crossroads.addRoute('{controller}/{action}/{id*}');

this might be useful in a few cases.

right now there is no way to add optional segments without using RegExp.

maybe add something like:

'{requiredSegment}{optionalSegment}?'

or:

'{requiredSegment}::optionalSegment::'

so far I prefer the later option since it is clearer.

create some kind of special property to the Route.rules object used for cases where you need to check some external condition or do some further checking that isn't directly related with the string structure.

See: #13

considering cases where it would be good to have multiple instances instead of a single static object... maybe add a method create() that creates a new independent instance...

{controller}/{action}/{id?} - ? sign marks the id parameter as optional.
{controller}/{action}/{id*} - * implies that the id parameter can contain the rest of the path (all symbols including /)

lets say we have a pattern like this: '{a}/{b}/:c:/:d: - and we expect the input to be something like:

• news/103/lorem-ipsum
• news/foo/103/lorem-ipsum
• news/103
• article/news/103

it would be very useful to have an option to parse params and only pass "news" and "103" to listener since all the URLs are just alias to the same article.

add module name to def() call def('crossroads', ['signals'], function(signals){ ... and make browser version grab dependencies like node/amd does (using the deps array)..

not a big deal (won't change anything) but will be more flexible and can be used later.

When using a regexp route, my rules.normalize_ function gets called twice with different arguments.

The problem seems to be that a regex route returns an array in stead of an object with named properties.
Therefore, in route.js, line 45...

var validationRule = this.rules[prop]

...returns this.rules[0] which is my normalize_ function. It is then called on line 59:

isValid = validationRule(val, request, values)

Is there the intent to allow url generation based on the route information? I would be willing to help if this is something that you would be amenable to adding to the codebase.

Something to the effect of

route.generate(params)

where params is either an array or object depending on the normalize function.

Hello,

What is the best way to implement "unordered parameters"? This is common in standard query string by associating a key with a value. The use case for that is mostly advanced search when you don't know witch filter the user is going to use.

thanks for your help

removed JSLint because it enforces that all functions should be declared before calling it and also because it is too strict... I usually spend more time trying to make it validate the rules than it actually helps finding problems and it makes the code harder to read (since it doesn't follow a logic flow).

right now crossroads uses route.matched.dispatch.apply() to pass captured values as parameters, I think we should create an option to toggle between passing parameters as an Array or calling apply()... it will probably increase 2-3 lines of code and can reduce the need of using normalize_ just for that reason...

maybe we should even add a third option to return parameters as an object (like the one we pass to normalize and validation methods..) all the heavy logic is already there, only problem I can foresee is that normalize_ returns an array so it will be impossible to map each value to the real key name (values can be out of order, missing, extra values...), probably user will need to return an object instead of an array if handlers expects objects (which should be totally fine if documented).

not sure if it should be a global setting (per Router) or if each Route should also have it's own setting (that bypass Router setting)...

Hi,

I know the following doesn't work but is it hard to implement?

crossroads.addRoute('/news/{id}', function(id){
  console.log(id);
  return 'Hello'
});
var result = crossroads.parse('/news/123') //result equals 'Hello'

In your example below,

• Is the execution order of the matches the same as they are added?
• Do they execute sync or async.
• Is there any way to cancel the sequential matches from firing? Example.. if the first match checks to see if a user is authenticated, if not redirect rather than executing all sequential requests.

var route1 = crossroads.addRoute('/news/{id}');
route1.matched.add(function(id){
  console.log('handler 1: '+ id);
});
route1.matched.add(function(id){
  console.log('handler 2: '+ id);
});
crossroads.parse('/news/123'); //will trigger both handlers of `route1`

if segment value is "false" or "true" it should be converted to boolean.

Is it possible to access the request and response objects from my matched function?
In this particular case i need to redirect the request after processing a certain request.

too ugly and will reduce flexibility...

It would be good to have the signal that is sent right before the system gets a request to change its state with a new route.

For example, I am developing brand new Facebook-like social network.

Within the network, I have a page with lots of videos from different users.
When I click on a video, a popup appears with this video inside.
This popup is handled by some route and has an url, for example, '#/videos/{id}'.
Within this popup, I have a username of the user who uploaded this video.
This username is a link to user's page, also handled by some route like '#/users/{id}'.
When I click on the username, I want to open the user's profile.
But, before opening the profile, the popup should be closed.
The route '#/users/{id}' should not be aware of the previous route and should not be responsible for closing the popup. On my opinion, this is responsibility of '#/videos/{id}' route, or maybe some another piece of code.

I think a signal that is sent before an actual route handler for '#/users/{id}' will be executed, could solve this problem. I can easily plug a code that closes the video popup into the handler of the signal.

What do you think? Any other ideas how to solve the problem like described above?

no reason for running unit tests on the browser every time, maybe run unit tests together with build process as well (at least to check generated files).

PS: keep HTML files to make it easier to debug browser related issues and also for running tests during development.

vals is only needed for normalize_ so no need to call this._getParamValuesObject(request) every time:

https://github.com/millermedeiros/crossroads.js/blob/a03c8ef5d5/dist/crossroads.js#L220-230

should be trivial to implement if route was generated using a string, probably just need to do a RegExp over Route._pattern like MM_js_lib/microTemplate..

if user don't provide a required parameter it should also throw an error, optional parameters can be omitted.

if route is a RegExp there is no way to do it since we can't figure out what is the string user is trying to build so it should throw an error...

I haven't really needed this feature so far - specially since I'm generating routes dynamically and don't access the routes references after I create them - but I can see it being useful in a few cases.

split helpers into it's own namespace to improve organization and generate methods isFunction(), isArray(), isRegExp() dynamically to avoid code duplication.

probably use joDoc with external markdown files.

the pattern /projects/:id:/:slug: should match against request /projects since id and slug are optional params and trailing slash is ignored on normal routes (i.e. /projects/ === /projects)

The second call to setHash throws an error:

crossroads.addRoute( 'lorem/{id}', function( id ) { alert( id ); } );

hasher.changed.add( crossroads.parse, crossroads );
hasher.init();

hasher.setHash('lorem/123');  // works with alert(123)
hasher.setHash('lorem/456');  // javascript error

right now crossroads.js is flexible enough to change the data format but still requires some repetitive work to parse query strings...

see: auchenberg@89fb9c1 for more info

still unsure how it should be implemented since in some cases the query string may need to be considered as part of a path segment...

spec:

var a = crossroads.addRoute('/123/:foo:/:bar:');
a.rules = {
    foo : /^\w+$/,
    bar : function(val){
        return val === 'ipsum';
    }
};

expect( a.match('/123') ).toBe( true );
expect( a.match('/123/') ).toBe( true );
expect( a.match('/123/asd') ).toBe( true );
expect( a.match('/123/asd/') ).toBe( true );
expect( a.match('/123/asd/ipsum/') ).toBe( true );

expect( a.match('/123/asd/45') ).toBe( false );
expect( a.match('/123/asd/45/qwe') ).toBe( false );
expect( a.match('/123/as#%d&/ipsum') ).toBe( false );

this fails as of v0.5.0+ build 64

I've been setting it to false ever since I added this option so I think it should be the default.

what someone would expect:

crossroads.shouldTypecast = false;
crossroads.addRoute('/news/{id}', function(id){
    console.log(id); // "00012" (keep trailing zeroes)
});
crossroads.parse('/news/00012');

what happens right now (v0.5.0):

crossroads.shouldTypecast = true;
crossroads.addRoute('/news/{id}', function(id){
    console.log(id); // 12 (no trailing zeroes since it's typecasted)
});
crossroads.parse('/news/00012');

not sure if these patterns should all mean the same:

'{foo}{bar}'
'{foo}/{bar}'
'/{foo}/{bar}'
'/{foo}{bar}/'
'/{foo}/{bar}/'

as of version 0.3:

• "/" between 2 variables is optional so '{foo}{bar}' is exactly the same as '{foo}/{bar}'.
• '/{foo}' is different than '/{foo}/' and '{foo}/' because of trailing slashes.

Hi!
Can't make it work via require

define(["Proj/Libs/crossroads", "Proj/Libs/crossroads"], function (controllerBase, pubSub)
...

Error:
GET http://localhost:5608/Proj/signals.js 404 (Not Found)

Even if I copy signals.js to the Proj directory, I have following exception:

Uncaught TypeError: Cannot read property 'Signal' of null crossroads.js:88

Thanks

Currently it appears greedy is globally set to false and can't be accessed from outside.

It would be nice to be able to change this to true globally instead of on a route by route basis.

it would reduce the need of multiple routes for similar patterns and also allow bypassing the '/' segment separator.

crossroads.addRoute(/^foo\\/?([a-z]+)?$/); //would match "foo" and "foo/bar".. if "foo/bar" would pass "bar" as param (capturing group)

maybe it is a good idea to add priority to routes, that way there is no need to add routes on the proper order. code complexity won't increase that much.

not sure if I should keep js-signals as a dependency or just use simple callbacks for everything...

I like to use Signals because it gives way more flexibility and since I'm using signals on all complex projects it won't affect file-size.

I even considered adding it as a plugin since I believe most people won't need more than a single callback for each route but I thought it was going to reduce maintainability.

PS: if you need a routing system you probably also need a custom event system...

was taking a look at https://github.com/cowboy/javascript-route-matcher and it is basically what this method does... maybe it's useful to someone so it should be public.

Bypassed action is called each time crossroads can't match any route. Crossroads passes requestString parameter to the action and I can't do anything except logging. Is there any ability to send 404 or close connection? I think it would be great to have response and request objects available in the "bypassed" action.

maybe something like routed, matched, etc.. and pass request, Route and params to handler... can't think of a real use case now but may be useful for someone in the future.

Hi,

Your lib is quite good, I have a feature-request:
I think it will be cool to create method
crossroads.create({
name: "ROUTE_NAME",
params: {
userId: 4
}
}) --> this should call crossroads.parse(CREATED_LOCATION);

What do you think about this?

This code :

crossroads.routed.add(console.log); //log all routes

will trigger an exception in Chrome (because you are passing log as parameter, but at invocation, "this" is not setted correclty).

The solution I used :

    crossroads.routed.add(function(data){
        console.log(data);
    }); //log all routes

Here is the code of a small page triggering the error :

    //setup hasher
    hasher.changed.add(crossroads.parse, crossroads); //parse hash changes
    hasher.init(); //start listening for history change

    //update URL fragment generating new history record
    hasher.setHash('lorem/ipsum');
</script>

And the stack trace in Chrome :

Uncaught TypeError: Illegal invocation
SignalBinding.executesignals.js:108
signals.Signal.dispatchsignals.js:342
Crossroads.parsecrossroads.js:106
SignalBinding.executesignals.js:108
signals.Signal.dispatchsignals.js:342
_registerChangehasher.js:101
hasher.setHashhasher.js:286
(anonymous function)crossroad-test.html:17

use js-signals package.json as reference.

sometimes it can be important to have strict patterns and other times a loose format may be better.

Current behavior:

"/foo" == "/foo/"
"/foo" != "foo"
"/foo" != "foo/"

it would be cool if Crossroads had 2 modes, strict and loose:

Strict:

"/foo" != "/foo/"
"/foo" != "foo"
"/foo" != "foo/"

Loose:

"/foo" == "/foo/"
"/foo" == "foo"
"/foo" == "foo/"

I think that both behaviors are better than the current one. I think the "loose" mode should be the default since it will probably cause less troubles.

PS: the modes could only be toggled before adding any route since patterns are "compiled" during the route instantiation.

Right now crossroads stops at the first match, maybe we should add an option that enables matching multiple routes so we could use crossroads as an advanced event system.

I've seen some cases where this feature would be useful, but also cases where this feature would deceive the whole "routing" logic and even break things (when you expect that the first route would block execution of subsequent routes...)

If implemented it would also require a way to "stop the route propagation"...

create a simple page for the project.

create numbered rules that match each capturing group or segment by index.

e.g.

myRoute.rules = {
  '1' : function(val){
    ...
  },
  '2' : ['foo', 'bar']
};

matching same route multiple times shouldn't trigger a switched signal, only a matched signal.

Since only dependency is JS-signals it is very simple to create a single wrapper that works for all the environments...

Not sure if it is worth the trouble tho, since generating the 3 dist files is so simple and easier to understand what the code is doing...

sometimes it may be helpful to return all values as strings instead of converting to boolean or number.. cases lilke projects/detail/001/true and pattern: {foo}{bar}{n}{flag} will return ['projects', 'detail', 1, true] - note that the leading zeroes aren't present anymore since it was converted to a number and true is a real boolean...

typecast should be opt-in since it can produce undesirable outcome.