Missing CSS,JS Content and other issues with HMVC

[edmundchaniii]

Hi,

Just wanted to report some intermitant issues we are seeing with Sprinkle.

We are using the latest version of Modular Extensions with CI 2.x and the latest Sprinkle.

When we first started using Sprinkle, things seemed fine. Lately we have been doing heavy css/html/js development (no php code changes) and Sprinkle has become unstable.

It started creating cache files that were empty. It is also having problems picking up routes now too! Very odd. We thought maybe something was wrong with the spacing in our YAML files so we checked them and they are correct, we recreated the config using the PHP files and still had the same issues, so it wasn't the YAML file.

I have some log messages when I was trying to debug what was going on:

INFO - 2012-02-10 15:19:48 --> Sprinkle::_parse_routes - COMPARING >>>> - URI: test KEY: test/(.+)
INFO - 2012-02-10 15:19:48 --> Sprinkle::_parse_routes - *** NO MATCH *** - URI: test KEY: test/(.+)
INFO - 2012-02-10 15:19:48 --> Sprinkle::_parse_routes - COMPARING >>>> - URI: test KEY: (.+) VAL: Array
INFO - 2012-02-10 15:19:48 --> Sprinkle::_parse_routes - MATCHED !! - URI: test KEY: (.+)

So, for some odd reason, it misses matching "test/(:any)" and just matches the "(:any)". It's not just with the "test" module either. Once it starts happening it just continues.

The other programmer working on this project said that when he had just a few assets with only a few routes it was working correctly. As he added more assets it started acting strangely.

We have now moved to External Asset Manager and it is working correctly, so I don't think it is anything in our code, and besides, our PHP code hasn't changed for a long time. Just the CSS/JS.

Also, once Sprinkle starts to mess up, it continues to misbehave. Even if we clear the cache out it will create empty cache files. At some point, it will just start working again!

We have absolutly no idea what is going on with it. Has anyone else reported any odd issues?

I noticed that the disable_processing doesn't really seem to work the way we expected, but I see someone has already opened an issue with it.

There is one more thing that happens and I don't know if you expected the routing to work like this. If there is a specific match of the routes, Sprinkle will continue to look for matches and if there is an "(:any)" route after a matching route, it will overwrite the previously matched routes assets. Should you have a "break;" in the _parse_routes function if it finds a match so the matching stops?

Have you heard of these problems before?

I really like what you have done with Sprinkle, I just wish it worked all the time.

Anyway, I will try to debug it more when I get time, unless you are already aware of these issues and are addressing them.

Thanks in advance,

Edmund Chan

[edmundask]

Thanks your for your detailed analysis. I haven't tested Sprinkle extensively with HMVC and, to be honest, didn't expect it to misbehave like this. I may have an idea what is causing the problem with the routes parsing and I'll make sure to fix it as soon as possible.

Empty cache files could be because of filters facing problems doing their job (trouble parsing, minifying due to incorrect syntax in the original asset file, for example). Some filter combinations may cause troubles. Personally I didn't have problems like this.

The disable_processing option was named a bit recklessly. Its purpose was to avoid Sprinkle checking for changes of the original asset files (and also to avoid parsing them). I think this option should be renamed to something more fitting the idea behind it. Then there could be another option solely for COMPLETELY disabling the processing which obviously would be very helpful.

Lastly, could you give an exact example of what you have in mind with route assets being overwritten? I never ran into such trouble while testing the library.

[edmundchaniii]

Hey..

Thanks for responding so quickly!

If I recall correctly, what was happening is like this:

test1/(:any)
test2/(:any)
test3/(:any)
(:any)

The way your "_parse_routes" function works, If I went to my "test1"
module, the route would match "test1/(:any)" and will continue down and
will match "(:any)" last. If I remember correctly, it was overwriting the
"test1/(:any)" results.

So, it will continue to check routes until there are no more left.

I don't know if that is how you expected it to work, or if "(:any)" was
supposed to be more like a default so if no routes matched, the assets
would be processed for any pages that didn't have matches in the routes.

So, to get around that you have to put "(:any)" at the top of the list or
add a "break;" at the bottom of the "key match" code in the "_parse_routes"
function.

Anyway, if I recall correctly, that is what we saw happening.

BTW, if there is any testing you would like me to do to help fix the
problem, just let me know.

Hope that helps.

Edmund

On Fri, Feb 10, 2012 at 4:10 PM, Edmundas <
reply@reply.github.com

wrote:

Thanks your for your detailed analysis. I haven't tested Sprinkle
extensively with HMVC and, to be honest, didn't expect it to misbehave like
this. I may have an idea what is causing the problem with the routes
parsing and I'll make sure to fix it as soon as possible.

Empty cache files could be because of filters facing problems doing their
job (trouble parsing, minifying due to incorrect syntax in the original
asset file, for example). Some filter combinations may cause troubles.
Personally I didn't have problems like this.

The disable_processing option was named a bit recklessly. Its purpose
was to avoid Sprinkle checking for changes of the original asset files (and
also to avoid parsing them). I think this option should be renamed to
something more fitting the idea behind it. Then there could be another
option solely for COMPLETELY disabling the processing which obviously would
be very helpful.

Lastly, could you give an exact example of what you have in mind with
route assets being overwritten? I never ran into such trouble while testing
the library.

---

Reply to this email directly or view it on GitHub:
#6 (comment)

[edmundchaniii]

Just wanted to add...

I believe I'm describing what we saw happening correctly with the routing..

BUT IF NOT..

What was happening was that "(:any)" was getting added to anything.. I
just really don't recall what the case was.. Sorry about that.. I just
wanted to clarify though how you intended it to work.

Like I said, I thought that it would be default assets that would only be
used if no other matching routes were found.

If you meant it to actually be used with ALL urls, maybe it should be
called "(:all)" and if you meant it to be used as a default call it
"(:default)" or something??

Just an idea..!

C'ya,
Edmund

On Fri, Feb 10, 2012 at 5:40 PM, Edmund Chan edmundchaniii@gmail.comwrote:

Hey..

Thanks for responding so quickly!

If I recall correctly, what was happening is like this:

test1/(:any)
test2/(:any)
test3/(:any)
(:any)

The way your "_parse_routes" function works, If I went to my "test1"
module, the route would match "test1/(:any)" and will continue down and
will match "(:any)" last. If I remember correctly, it was overwriting the
"test1/(:any)" results.

So, it will continue to check routes until there are no more left.

I don't know if that is how you expected it to work, or if "(:any)" was
supposed to be more like a default so if no routes matched, the assets
would be processed for any pages that didn't have matches in the routes.

So, to get around that you have to put "(:any)" at the top of the list or
add a "break;" at the bottom of the "key match" code in the "_parse_routes"
function.

Anyway, if I recall correctly, that is what we saw happening.

BTW, if there is any testing you would like me to do to help fix the
problem, just let me know.

Hope that helps.

Edmund

On Fri, Feb 10, 2012 at 4:10 PM, Edmundas <
reply@reply.github.com

wrote:

Thanks your for your detailed analysis. I haven't tested Sprinkle
extensively with HMVC and, to be honest, didn't expect it to misbehave like
this. I may have an idea what is causing the problem with the routes
parsing and I'll make sure to fix it as soon as possible.

Empty cache files could be because of filters facing problems doing their
job (trouble parsing, minifying due to incorrect syntax in the original
asset file, for example). Some filter combinations may cause troubles.
Personally I didn't have problems like this.

The disable_processing option was named a bit recklessly. Its purpose
was to avoid Sprinkle checking for changes of the original asset files (and
also to avoid parsing them). I think this option should be renamed to
something more fitting the idea behind it. Then there could be another
option solely for COMPLETELY disabling the processing which obviously would
be very helpful.

Lastly, could you give an exact example of what you have in mind with
route assets being overwritten? I never ran into such trouble while testing
the library.

---

Reply to this email directly or view it on GitHub:
#6 (comment)

[edmundask]

The way I intended for the routing to work is slightly different from how CodeIgniter works with URI routing. I'll need to update the documentation to provide with more examples.

For example, to setup URI routes, you have to first declare routes of the "highest order" and work your way down. In Sprinkle, although it uses the same code for parsing the routes, is the other way around. So first you declare (:any) route for all pages, then, let's say, welcome/(:any) for all methods of welcome controller. Maybe I'm approaching this from the wrong angle but it does make sense to me. If it was constructed in the opposite way, there would be a problem with ordering assets. For example, if I first declare welcome/(:any) route and want to load jquery ui, I must also load jquery:

welcome/(:any):
  assets:
    - jquery
    - jquery-ui

ideally I would want jquery to be loaded globally:

welcome/(:any):
  assets:
    - jquery-ui

(:any):
  assets:
    - jquery

but now the problem is that jquery ui will be loaded before jquery itself. So you see how doing it this way would complicate things. I was having thoughts of implementing some sort of ordering system but I still need to figure out a neat way to do it without making asset loading too complicated.

Taking your example, you have something like this:

test1/(:any)
test2/(:any)
test3/(:any)
(:any)

which actually should be like this:

(:any)
test1/(:any)
test2/(:any)
test3/(:any)
test3/foo/(:any)

right away you might think that it still doesn't solve one problem -- what if I do not want to "inherit" assets from, let's say, the global route? This is where asset replacement and exclusion features come in. Assets can be replaced and excluded with replace and exclude attributes respectively. I have documented them in the wiki.

So, for some odd reason, it misses matching "test/(:any)" and just matches the "(:any)". It's not just with the "test" module either. Once it starts happening it just continues.

At the moment I'm doing tests with HMVC and after doing some debugging I noticed that module routes are slightly different "under the hood". I'm working on the issue right now.

However, there's more trickery involved in the asset routes (not just with HMVC but overall). Suppose you want to load jquery for all welcome controller methods. Instinctively you would define a route like this: welcome/(:any). This will work with all URLs that have welcome/segments/and/some/more/segments. However, it will not work if there's no method specified (for example: http://localhost/myapp/welcome) although CodeIgniter routes to 'index' method if only a controller name is specified in the URL.

On the other hand, if I define welcome route, then assets will be loaded only if I do not specify the method in the URL (even if the default method is specified it won't work: http://localhost/myapp/welcome/index).

Now, I can add omitted method ('index') detection in Sprinkle and a route like welcome/(:any) would work with every URL as long as the controller name is in the URL. However, then defining welcome as a route wouldn't do anything and it would be useless. In that case you would have no way of loading assets for the default method if it's omitted in the URL. Your idea of adding (:default) wildcard would be beneficial then, if that's what you had in mind.

[edmundchaniii]

Just in case you are wondering why I am still trying to use Sprinkle now
that we are using External Asset Manager... It's because External is
working well for us, but it feels rather "raw".

Sprinkle just seems much more refined and is much easier to configure. I
also like how your groups work. It's just much easier being able to see
the order your assets are loaded in as far as groups go at least.

I also like the ability to use YAML for it's configuration. Being able to
Combine and cache the assets is great as well as minifying and lessphp!

"but now the problem is that jquery ui will be loaded before jquery
itself. So you see how doing it this way would complicate things. I was
having thoughts of implementing some sort of ordering system but I still
need to figure out a neat way to do it without making asset loading too
complicated."

Yes, I believe that's what you need. I don't know if you've checked out
"External Asset Manager". There is a "weighting" system in there. It
works well. Each asset is given a weight and after all the assets are
fetched into an array, a sort is run on the weight and the assets are then
ordered according to it's weighting. This carries through to their Groups
as well.

When I was looking at Sprinkle code, I was wondering how hard it would be
to implement a weighting system. I think the way Sprinkle does it's Groups
is better in that you can physically see the order of the assets in the
Group.

Aren't all assets put into the "assets" array before being output in the
_output_assets function? I could be totally wrong cause I'm going off of
memory, but if you had weights for each asset, couldn't you implement a
sort on that array in the "_output_assets" function before the loop that
calls the create_tags function?

"Now, I can add omitted method ('index') detection in Sprinkle and a route
like welcome/(:any) would work with every URL as long as the controller
name is in the URL. However, then defining welcome as a route wouldn't do
anything and it would be useless. In that case you would have no way of
loading assets for the default method if it's omitted in the URL. Your idea
of adding (:default) wildcard would be beneficial then, if that's what
you had in mind."

Yes, that is exactly what I meant about (:default). Only if there is no
match, have it use the (:default) route.

Also, seeing (:any) is kind of ambiguous. Yes, I understand it should
match any URL, but what happens when there are other matches below that?
Are the (:any) assets overwritten or are they included in the final
results?

Just for clarity, I still think if you want assets for a route to ALWAYS be
used for ALL routes, I think instead of using (:any) the route should be
called (:all) or (:always) or even (:always_use). Just much more
descriptive of what it is doing. You know what I mean?

Also, just to let you know "External" seems to be routing correctly with
HMVC. May be worth checking out what they did with their URI's.

---

On Sat, Feb 11, 2012 at 4:15 AM, Edmundas <
reply@reply.github.com

wrote:

The way I intended for the routing to work is slightly different from how
CodeIgniter works with URI routing. I'll need to update the documentation
to provide with more examples.

For example, to setup URI routes, you have to first declare routes of the
"highest order" and work your way down. In Sprinkle, although it uses the
same code for parsing the routes, is the other way around. So first you
declare (:any) route for all pages, then, let's say, welcome/(:any) for
all methods of welcome controller. Maybe I'm approaching this from the
wrong angle but it does make sense to me. If it was constructed in the
opposite way, there would be a problem with ordering assets. For example,
if I first declare welcome/(:any) route and want to load jquery ui, I
must also load jquery:

welcome/(:any):
 assets:
   - jquery
   - jquery-ui

ideally I would want jquery to be loaded globally:

welcome/(:any):
 assets:
   - jquery-ui

(:any):
 assets:
   - jquery

but now the problem is that jquery ui will be loaded before jquery
itself. So you see how doing it this way would complicate things. I was
having thoughts of implementing some sort of ordering system but I still
need to figure out a neat way to do it without making asset loading too
complicated.

Taking your example, you have something like this:

test1/(:any)
test2/(:any)
test3/(:any)
(:any)

which actually should be like this:

(:any)
test1/(:any)
test2/(:any)
test3/(:any)
test3/foo/(:any)

right away you might think that it still doesn't solve one problem -- what
if I do not want to "inherit" assets from, let's say, the global route?
This is where asset replacement and exclusion features come in. Assets can
be replaced and excluded with replace and exclude attributes
respectively. I have documented them in the wiki.

So, for some odd reason, it misses matching "test/(:any)" and just
matches the "(:any)". It's not just with the "test" module either. Once it
starts happening it just continues.

At the moment I'm doing tests with HMVC and after doing some debugging I
noticed that module routes are slightly different "under the hood". I'm
working on the issue right now.

However, there's more trickery involved in the asset routes (not just with
HMVC but overall). Suppose you want to load jquery for all welcome
controller methods. Instinctively you would define a route like this:
welcome/(:any). This will work with all URLs that have
welcome/segments/and/some/more/segments. However, it will not work if
there's no method specified (for example: http://localhost/myapp/welcome)
although CodeIgniter routes to 'index' method if only a controller name is
specified in the URL.

On the other hand, if I define welcome route, then assets will be loaded
only if I do not specify the method in the URL (even if the default
method is specified it won't work: http://localhost/myapp/welcome/index
).

Now, I can add omitted method ('index') detection in Sprinkle and a route
like welcome/(:any) would work with every URL as long as the controller
name is in the URL. However, then defining welcome as a route wouldn't do
anything and it would be useless. In that case you would have no way of
loading assets for the default method if it's omitted in the URL. Your idea
of adding (:default) wildcard would be beneficial then, if that's what
you had in mind.

---

Reply to this email directly or view it on GitHub:
#6 (comment)

[edmundchaniii]

Hey..

Anyway, was just doing some debugging..

I think sprinkle will working correctly if this like is commented out in

the "_parse_routes" function:

$uri = empty($uri) ?: substr($this->uri->ruri_string(), 1,
strlen($this->uri->ruri_string()));

If you have a url like "somemodule/somecontroller", after that line, it
would make it "somecontroller/index.php".

So, it removes the module from that uri. I haven't tested Sprinkle to see
if it works, cause I just yanked that code out and was messing around with
it.

Anyway, help that hopes. I may test sprinkle a little later.

C'ya,
Edmund

On Sat, Feb 11, 2012 at 10:17 AM, Edmund Chan edmundchaniii@gmail.comwrote:

Just in case you are wondering why I am still trying to use Sprinkle now
that we are using External Asset Manager... It's because External is
working well for us, but it feels rather "raw".

Sprinkle just seems much more refined and is much easier to configure. I
also like how your groups work. It's just much easier being able to see
the order your assets are loaded in as far as groups go at least.

I also like the ability to use YAML for it's configuration. Being able to
Combine and cache the assets is great as well as minifying and lessphp!

"but now the problem is that jquery ui will be loaded before jquery
itself. So you see how doing it this way would complicate things. I was
having thoughts of implementing some sort of ordering system but I still
need to figure out a neat way to do it without making asset loading too
complicated."

Yes, I believe that's what you need. I don't know if you've checked out
"External Asset Manager". There is a "weighting" system in there. It
works well. Each asset is given a weight and after all the assets are
fetched into an array, a sort is run on the weight and the assets are then
ordered according to it's weighting. This carries through to their Groups
as well.

When I was looking at Sprinkle code, I was wondering how hard it would be
to implement a weighting system. I think the way Sprinkle does it's Groups
is better in that you can physically see the order of the assets in the
Group.

Aren't all assets put into the "assets" array before being output in the
_output_assets function? I could be totally wrong cause I'm going off of
memory, but if you had weights for each asset, couldn't you implement a
sort on that array in the "_output_assets" function before the loop that
calls the create_tags function?

"Now, I can add omitted method ('index') detection in Sprinkle and a route
like welcome/(:any) would work with every URL as long as the controller
name is in the URL. However, then defining welcome as a route wouldn't do
anything and it would be useless. In that case you would have no way of
loading assets for the default method if it's omitted in the URL. Your idea
of adding (:default) wildcard would be beneficial then, if that's what
you had in mind."

Yes, that is exactly what I meant about (:default). Only if there is no
match, have it use the (:default) route.

Also, seeing (:any) is kind of ambiguous. Yes, I understand it should
match any URL, but what happens when there are other matches below that?
Are the (:any) assets overwritten or are they included in the final
results?

Just for clarity, I still think if you want assets for a route to ALWAYS
be used for ALL routes, I think instead of using (:any) the route should be
called (:all) or (:always) or even (:always_use). Just much more
descriptive of what it is doing. You know what I mean?

Also, just to let you know "External" seems to be routing correctly with
HMVC. May be worth checking out what they did with their URI's.

---

On Sat, Feb 11, 2012 at 4:15 AM, Edmundas <
reply@reply.github.com

wrote:

The way I intended for the routing to work is slightly different from how
CodeIgniter works with URI routing. I'll need to update the documentation
to provide with more examples.

For example, to setup URI routes, you have to first declare routes of the
"highest order" and work your way down. In Sprinkle, although it uses the
same code for parsing the routes, is the other way around. So first you
declare (:any) route for all pages, then, let's say, welcome/(:any) for
all methods of welcome controller. Maybe I'm approaching this from the
wrong angle but it does make sense to me. If it was constructed in the
opposite way, there would be a problem with ordering assets. For example,
if I first declare welcome/(:any) route and want to load jquery ui, I
must also load jquery:

welcome/(:any):
 assets:
   - jquery
   - jquery-ui

ideally I would want jquery to be loaded globally:

welcome/(:any):
 assets:
   - jquery-ui

(:any):
 assets:
   - jquery

but now the problem is that jquery ui will be loaded before jquery
itself. So you see how doing it this way would complicate things. I was
having thoughts of implementing some sort of ordering system but I still
need to figure out a neat way to do it without making asset loading too
complicated.

Taking your example, you have something like this:

test1/(:any)
test2/(:any)
test3/(:any)
(:any)

which actually should be like this:

(:any)
test1/(:any)
test2/(:any)
test3/(:any)
test3/foo/(:any)

right away you might think that it still doesn't solve one problem --
what if I do not want to "inherit" assets from, let's say, the global
route? This is where asset replacement and exclusion features come in.
Assets can be replaced and excluded with replace and exclude attributes
respectively. I have documented them in the wiki.

So, for some odd reason, it misses matching "test/(:any)" and just
matches the "(:any)". It's not just with the "test" module either. Once it
starts happening it just continues.

At the moment I'm doing tests with HMVC and after doing some debugging I
noticed that module routes are slightly different "under the hood". I'm
working on the issue right now.

However, there's more trickery involved in the asset routes (not just
with HMVC but overall). Suppose you want to load jquery for all welcome
controller methods. Instinctively you would define a route like this:
welcome/(:any). This will work with all URLs that have
welcome/segments/and/some/more/segments. However, it will not work if
there's no method specified (for example: http://localhost/myapp/welcome http://localhost/myapp/welcome)
although CodeIgniter routes to 'index' method if only a controller name is
specified in the URL.

On the other hand, if I define welcome route, then assets will be
loaded only if I do not specify the method in the URL (even if the
default method is specified it won't work: http://localhost/myapp/welcome/indexhttp://localhost/myapp/welcome/index
).

Now, I can add omitted method ('index') detection in Sprinkle and a route
like welcome/(:any) would work with every URL as long as the controller
name is in the URL. However, then defining welcome as a route wouldn't do
anything and it would be useless. In that case you would have no way of
loading assets for the default method if it's omitted in the URL. Your idea
of adding (:default) wildcard would be beneficial then, if that's what
you had in mind.

---

Reply to this email directly or view it on GitHub:
#6 (comment)

[edmundchaniii]

Hmm. Interesting..

Never mind.. It's not working correctly. It ends up cutting
"module/function" to just "module", so it won't match "module/(:any)"..

Oh well..

On Sun, Feb 12, 2012 at 11:23 AM, Edmund Chan edmundchaniii@gmail.comwrote:

Hey..

Anyway, was just doing some debugging..

I think sprinkle will working correctly if this like is commented out in

the "_parse_routes" function:

$uri = empty($uri) ?: substr($this->uri->ruri_string(), 1,
strlen($this->uri->ruri_string()));

If you have a url like "somemodule/somecontroller", after that line, it
would make it "somecontroller/index.php".

So, it removes the module from that uri. I haven't tested Sprinkle to see
if it works, cause I just yanked that code out and was messing around with
it.

Anyway, help that hopes. I may test sprinkle a little later.

C'ya,
Edmund

On Sat, Feb 11, 2012 at 10:17 AM, Edmund Chan edmundchaniii@gmail.comwrote:

Just in case you are wondering why I am still trying to use Sprinkle now
that we are using External Asset Manager... It's because External is
working well for us, but it feels rather "raw".

Sprinkle just seems much more refined and is much easier to configure. I
also like how your groups work. It's just much easier being able to see
the order your assets are loaded in as far as groups go at least.

I also like the ability to use YAML for it's configuration. Being able
to Combine and cache the assets is great as well as minifying and lessphp!

"but now the problem is that jquery ui will be loaded before jquery
itself. So you see how doing it this way would complicate things. I was
having thoughts of implementing some sort of ordering system but I still
need to figure out a neat way to do it without making asset loading too
complicated."

Yes, I believe that's what you need. I don't know if you've checked out
"External Asset Manager". There is a "weighting" system in there. It
works well. Each asset is given a weight and after all the assets are
fetched into an array, a sort is run on the weight and the assets are then
ordered according to it's weighting. This carries through to their Groups
as well.

When I was looking at Sprinkle code, I was wondering how hard it would be
to implement a weighting system. I think the way Sprinkle does it's Groups
is better in that you can physically see the order of the assets in the
Group.

Aren't all assets put into the "assets" array before being output in the
_output_assets function? I could be totally wrong cause I'm going off of
memory, but if you had weights for each asset, couldn't you implement a
sort on that array in the "_output_assets" function before the loop that
calls the create_tags function?

"Now, I can add omitted method ('index') detection in Sprinkle and a
route like welcome/(:any) would work with every URL as long as the
controller name is in the URL. However, then defining welcome as a route
wouldn't do anything and it would be useless. In that case you would have
no way of loading assets for the default method if it's omitted in the URL.
Your idea of adding (:default) wildcard would be beneficial then, if
that's what you had in mind."

Yes, that is exactly what I meant about (:default). Only if there is no
match, have it use the (:default) route.

Also, seeing (:any) is kind of ambiguous. Yes, I understand it should
match any URL, but what happens when there are other matches below that?
Are the (:any) assets overwritten or are they included in the final
results?

Just for clarity, I still think if you want assets for a route to ALWAYS
be used for ALL routes, I think instead of using (:any) the route should be
called (:all) or (:always) or even (:always_use). Just much more
descriptive of what it is doing. You know what I mean?

Also, just to let you know "External" seems to be routing correctly with
HMVC. May be worth checking out what they did with their URI's.

---

On Sat, Feb 11, 2012 at 4:15 AM, Edmundas <
reply@reply.github.com

wrote:

The way I intended for the routing to work is slightly different from
how CodeIgniter works with URI routing. I'll need to update the
documentation to provide with more examples.

For example, to setup URI routes, you have to first declare routes of
the "highest order" and work your way down. In Sprinkle, although it uses
the same code for parsing the routes, is the other way around. So first you
declare (:any) route for all pages, then, let's say, welcome/(:any) for
all methods of welcome controller. Maybe I'm approaching this from the
wrong angle but it does make sense to me. If it was constructed in the
opposite way, there would be a problem with ordering assets. For example,
if I first declare welcome/(:any) route and want to load jquery ui, I
must also load jquery:

welcome/(:any):
 assets:
   - jquery
   - jquery-ui

ideally I would want jquery to be loaded globally:

welcome/(:any):
 assets:
   - jquery-ui

(:any):
 assets:
   - jquery

but now the problem is that jquery ui will be loaded before jquery
itself. So you see how doing it this way would complicate things. I was
having thoughts of implementing some sort of ordering system but I still
need to figure out a neat way to do it without making asset loading too
complicated.

Taking your example, you have something like this:

test1/(:any)
test2/(:any)
test3/(:any)
(:any)

which actually should be like this:

(:any)
test1/(:any)
test2/(:any)
test3/(:any)
test3/foo/(:any)

right away you might think that it still doesn't solve one problem --
what if I do not want to "inherit" assets from, let's say, the global
route? This is where asset replacement and exclusion features come in.
Assets can be replaced and excluded with replace and exclude attributes
respectively. I have documented them in the wiki.

So, for some odd reason, it misses matching "test/(:any)" and just
matches the "(:any)". It's not just with the "test" module either. Once it
starts happening it just continues.

At the moment I'm doing tests with HMVC and after doing some debugging I
noticed that module routes are slightly different "under the hood". I'm
working on the issue right now.

However, there's more trickery involved in the asset routes (not just
with HMVC but overall). Suppose you want to load jquery for all welcome
controller methods. Instinctively you would define a route like this:
welcome/(:any). This will work with all URLs that have
welcome/segments/and/some/more/segments. However, it will not work if
there's no method specified (for example: http://localhost/myapp/welcome http://localhost/myapp/welcome)
although CodeIgniter routes to 'index' method if only a controller name is
specified in the URL.

On the other hand, if I define welcome route, then assets will be
loaded only if I do not specify the method in the URL (even if the
default method is specified it won't work: http://localhost/myapp/welcome/indexhttp://localhost/myapp/welcome/index
).

Now, I can add omitted method ('index') detection in Sprinkle and a
route like welcome/(:any) would work with every URL as long as the
controller name is in the URL. However, then defining welcome as a route
wouldn't do anything and it would be useless. In that case you would have
no way of loading assets for the default method if it's omitted in the URL.
Your idea of adding (:default) wildcard would be beneficial then, if
that's what you had in mind.

---

Reply to this email directly or view it on GitHub:
#6 (comment)

[edmundchaniii]

Acck...

Just decided to update the line to check for segments and it seems to be

working (not sure about in sprinkle, but I would assume it does):

$uri = empty($uri) ?: (preg_match('@/@',$uri) ? $uri :
substr($this->uri->ruri_string(), 1, strlen($this->uri->ruri_string())));

C'ya,
Edmund

On Sun, Feb 12, 2012 at 2:36 PM, Edmund Chan edmundchaniii@gmail.comwrote:

Hmm. Interesting..

Never mind.. It's not working correctly. It ends up cutting
"module/function" to just "module", so it won't match "module/(:any)"..

Oh well..

On Sun, Feb 12, 2012 at 11:23 AM, Edmund Chan edmundchaniii@gmail.comwrote:

Hey..

Anyway, was just doing some debugging..

I think sprinkle will working correctly if this like is commented out in

the "_parse_routes" function:

$uri = empty($uri) ?: substr($this->uri->ruri_string(), 1,
strlen($this->uri->ruri_string()));

If you have a url like "somemodule/somecontroller", after that line, it
would make it "somecontroller/index.php".

So, it removes the module from that uri. I haven't tested Sprinkle to
see if it works, cause I just yanked that code out and was messing around
with it.

Anyway, help that hopes. I may test sprinkle a little later.

C'ya,
Edmund

On Sat, Feb 11, 2012 at 10:17 AM, Edmund Chan edmundchaniii@gmail.comwrote:

Just in case you are wondering why I am still trying to use Sprinkle now
that we are using External Asset Manager... It's because External is
working well for us, but it feels rather "raw".

Sprinkle just seems much more refined and is much easier to configure.
I also like how your groups work. It's just much easier being able to see
the order your assets are loaded in as far as groups go at least.

I also like the ability to use YAML for it's configuration. Being able
to Combine and cache the assets is great as well as minifying and lessphp!

"but now the problem is that jquery ui will be loaded before jquery
itself. So you see how doing it this way would complicate things. I was
having thoughts of implementing some sort of ordering system but I still
need to figure out a neat way to do it without making asset loading too
complicated."

Yes, I believe that's what you need. I don't know if you've checked out
"External Asset Manager". There is a "weighting" system in there. It
works well. Each asset is given a weight and after all the assets are
fetched into an array, a sort is run on the weight and the assets are then
ordered according to it's weighting. This carries through to their Groups
as well.

When I was looking at Sprinkle code, I was wondering how hard it would
be to implement a weighting system. I think the way Sprinkle does it's
Groups is better in that you can physically see the order of the assets in
the Group.

Aren't all assets put into the "assets" array before being output in the
_output_assets function? I could be totally wrong cause I'm going off of
memory, but if you had weights for each asset, couldn't you implement a
sort on that array in the "_output_assets" function before the loop that
calls the create_tags function?

"Now, I can add omitted method ('index') detection in Sprinkle and a
route like welcome/(:any) would work with every URL as long as the
controller name is in the URL. However, then defining welcome as a route
wouldn't do anything and it would be useless. In that case you would have
no way of loading assets for the default method if it's omitted in the URL.
Your idea of adding (:default) wildcard would be beneficial then, if
that's what you had in mind."

Yes, that is exactly what I meant about (:default). Only if there is no
match, have it use the (:default) route.

Also, seeing (:any) is kind of ambiguous. Yes, I understand it should
match any URL, but what happens when there are other matches below that?
Are the (:any) assets overwritten or are they included in the final
results?

Just for clarity, I still think if you want assets for a route to ALWAYS
be used for ALL routes, I think instead of using (:any) the route should be
called (:all) or (:always) or even (:always_use). Just much more
descriptive of what it is doing. You know what I mean?

Also, just to let you know "External" seems to be routing correctly with
HMVC. May be worth checking out what they did with their URI's.

---

On Sat, Feb 11, 2012 at 4:15 AM, Edmundas <
reply@reply.github.com

wrote:

The way I intended for the routing to work is slightly different from
how CodeIgniter works with URI routing. I'll need to update the
documentation to provide with more examples.

For example, to setup URI routes, you have to first declare routes of
the "highest order" and work your way down. In Sprinkle, although it uses
the same code for parsing the routes, is the other way around. So first you
declare (:any) route for all pages, then, let's say, welcome/(:any) for
all methods of welcome controller. Maybe I'm approaching this from the
wrong angle but it does make sense to me. If it was constructed in the
opposite way, there would be a problem with ordering assets. For example,
if I first declare welcome/(:any) route and want to load jquery ui, I
must also load jquery:

welcome/(:any):
 assets:
   - jquery
   - jquery-ui

ideally I would want jquery to be loaded globally:

welcome/(:any):
 assets:
   - jquery-ui

(:any):
 assets:
   - jquery

but now the problem is that jquery ui will be loaded before jquery
itself. So you see how doing it this way would complicate things. I was
having thoughts of implementing some sort of ordering system but I still
need to figure out a neat way to do it without making asset loading too
complicated.

Taking your example, you have something like this:

test1/(:any)
test2/(:any)
test3/(:any)
(:any)

which actually should be like this:

(:any)
test1/(:any)
test2/(:any)
test3/(:any)
test3/foo/(:any)

right away you might think that it still doesn't solve one problem --
what if I do not want to "inherit" assets from, let's say, the global
route? This is where asset replacement and exclusion features come in.
Assets can be replaced and excluded with replace and exclude attributes
respectively. I have documented them in the wiki.

So, for some odd reason, it misses matching "test/(:any)" and just
matches the "(:any)". It's not just with the "test" module either. Once it
starts happening it just continues.

At the moment I'm doing tests with HMVC and after doing some debugging
I noticed that module routes are slightly different "under the hood". I'm
working on the issue right now.

However, there's more trickery involved in the asset routes (not just
with HMVC but overall). Suppose you want to load jquery for all welcome
controller methods. Instinctively you would define a route like this:
welcome/(:any). This will work with all URLs that have
welcome/segments/and/some/more/segments. However, it will not work if
there's no method specified (for example: http://localhost/myapp/welcome http://localhost/myapp/welcome)
although CodeIgniter routes to 'index' method if only a controller name is
specified in the URL.

On the other hand, if I define welcome route, then assets will be
loaded only if I do not specify the method in the URL (even if the
default method is specified it won't work: http://localhost/myapp/welcome/indexhttp://localhost/myapp/welcome/index
).

Now, I can add omitted method ('index') detection in Sprinkle and a
route like welcome/(:any) would work with every URL as long as the
controller name is in the URL. However, then defining welcome as a route
wouldn't do anything and it would be useless. In that case you would have
no way of loading assets for the default method if it's omitted in the URL.
Your idea of adding (:default) wildcard would be beneficial then, if
that's what you had in mind.

---

Reply to this email directly or view it on GitHub:
#6 (comment)

[edmundchaniii]

Acckk. sorry again.. Still doing some odd things..

I'll let you know what I find after doing heavier testing.

C'ya,
Edmund

On Sun, Feb 12, 2012 at 2:41 PM, Edmund Chan edmundchaniii@gmail.comwrote:

Acck...

Just decided to update the line to check for segments and it seems to be

working (not sure about in sprinkle, but I would assume it does):

$uri = empty($uri) ?: (preg_match('@/@',$uri) ? $uri :
substr($this->uri->ruri_string(), 1, strlen($this->uri->ruri_string())));

C'ya,
Edmund

On Sun, Feb 12, 2012 at 2:36 PM, Edmund Chan edmundchaniii@gmail.comwrote:

Hmm. Interesting..

Never mind.. It's not working correctly. It ends up cutting
"module/function" to just "module", so it won't match "module/(:any)"..

Oh well..

On Sun, Feb 12, 2012 at 11:23 AM, Edmund Chan edmundchaniii@gmail.comwrote:

Hey..

Anyway, was just doing some debugging..

I think sprinkle will working correctly if this like is commented out in

the "_parse_routes" function:

$uri = empty($uri) ?: substr($this->uri->ruri_string(), 1,
strlen($this->uri->ruri_string()));

If you have a url like "somemodule/somecontroller", after that line, it
would make it "somecontroller/index.php".

So, it removes the module from that uri. I haven't tested Sprinkle to
see if it works, cause I just yanked that code out and was messing around
with it.

Anyway, help that hopes. I may test sprinkle a little later.

C'ya,
Edmund

On Sat, Feb 11, 2012 at 10:17 AM, Edmund Chan edmundchaniii@gmail.comwrote:

Just in case you are wondering why I am still trying to use Sprinkle
now that we are using External Asset Manager... It's because External is
working well for us, but it feels rather "raw".

Sprinkle just seems much more refined and is much easier to configure.
I also like how your groups work. It's just much easier being able to see
the order your assets are loaded in as far as groups go at least.

I also like the ability to use YAML for it's configuration. Being able
to Combine and cache the assets is great as well as minifying and lessphp!

"but now the problem is that jquery ui will be loaded before jquery
itself. So you see how doing it this way would complicate things. I was
having thoughts of implementing some sort of ordering system but I still
need to figure out a neat way to do it without making asset loading too
complicated."

Yes, I believe that's what you need. I don't know if you've checked
out "External Asset Manager". There is a "weighting" system in there. It
works well. Each asset is given a weight and after all the assets are
fetched into an array, a sort is run on the weight and the assets are then
ordered according to it's weighting. This carries through to their Groups
as well.

When I was looking at Sprinkle code, I was wondering how hard it would
be to implement a weighting system. I think the way Sprinkle does it's
Groups is better in that you can physically see the order of the assets in
the Group.

Aren't all assets put into the "assets" array before being output in
the _output_assets function? I could be totally wrong cause I'm going off
of memory, but if you had weights for each asset, couldn't you implement a
sort on that array in the "_output_assets" function before the loop that
calls the create_tags function?

"Now, I can add omitted method ('index') detection in Sprinkle and a
route like welcome/(:any) would work with every URL as long as the
controller name is in the URL. However, then defining welcome as a route
wouldn't do anything and it would be useless. In that case you would have
no way of loading assets for the default method if it's omitted in the URL.
Your idea of adding (:default) wildcard would be beneficial then, if
that's what you had in mind."

Yes, that is exactly what I meant about (:default). Only if there is
no match, have it use the (:default) route.

Also, seeing (:any) is kind of ambiguous. Yes, I understand it should
match any URL, but what happens when there are other matches below that?
Are the (:any) assets overwritten or are they included in the final
results?

Just for clarity, I still think if you want assets for a route to
ALWAYS be used for ALL routes, I think instead of using (:any) the route
should be called (:all) or (:always) or even (:always_use). Just much more
descriptive of what it is doing. You know what I mean?

Also, just to let you know "External" seems to be routing correctly
with HMVC. May be worth checking out what they did with their URI's.

---

On Sat, Feb 11, 2012 at 4:15 AM, Edmundas <
reply@reply.github.com

wrote:

The way I intended for the routing to work is slightly different from
how CodeIgniter works with URI routing. I'll need to update the
documentation to provide with more examples.

For example, to setup URI routes, you have to first declare routes of
the "highest order" and work your way down. In Sprinkle, although it uses
the same code for parsing the routes, is the other way around. So first you
declare (:any) route for all pages, then, let's say, welcome/(:any) for
all methods of welcome controller. Maybe I'm approaching this from the
wrong angle but it does make sense to me. If it was constructed in the
opposite way, there would be a problem with ordering assets. For example,
if I first declare welcome/(:any) route and want to load jquery ui, I
must also load jquery:

welcome/(:any):
 assets:
   - jquery
   - jquery-ui

ideally I would want jquery to be loaded globally:

welcome/(:any):
 assets:
   - jquery-ui

(:any):
 assets:
   - jquery

but now the problem is that jquery ui will be loaded before jquery
itself. So you see how doing it this way would complicate things. I was
having thoughts of implementing some sort of ordering system but I still
need to figure out a neat way to do it without making asset loading too
complicated.

Taking your example, you have something like this:

test1/(:any)
test2/(:any)
test3/(:any)
(:any)

which actually should be like this:

(:any)
test1/(:any)
test2/(:any)
test3/(:any)
test3/foo/(:any)

right away you might think that it still doesn't solve one problem --
what if I do not want to "inherit" assets from, let's say, the global
route? This is where asset replacement and exclusion features come in.
Assets can be replaced and excluded with replace and exclude attributes
respectively. I have documented them in the wiki.

So, for some odd reason, it misses matching "test/(:any)" and just
matches the "(:any)". It's not just with the "test" module either. Once it
starts happening it just continues.

At the moment I'm doing tests with HMVC and after doing some debugging
I noticed that module routes are slightly different "under the hood". I'm
working on the issue right now.

However, there's more trickery involved in the asset routes (not just
with HMVC but overall). Suppose you want to load jquery for all welcome
controller methods. Instinctively you would define a route like this:
welcome/(:any). This will work with all URLs that have
welcome/segments/and/some/more/segments. However, it will not work if
there's no method specified (for example: http://localhost/myapp/welcome http://localhost/myapp/welcome)
although CodeIgniter routes to 'index' method if only a controller name is
specified in the URL.

On the other hand, if I define welcome route, then assets will be
loaded only if I do not specify the method in the URL (even if the
default method is specified it won't work: http://localhost/myapp/welcome/indexhttp://localhost/myapp/welcome/index
).

Now, I can add omitted method ('index') detection in Sprinkle and a
route like welcome/(:any) would work with every URL as long as the
controller name is in the URL. However, then defining welcome as a route
wouldn't do anything and it would be useless. In that case you would have
no way of loading assets for the default method if it's omitted in the URL.
Your idea of adding (:default) wildcard would be beneficial then, if
that's what you had in mind.

---

Reply to this email directly or view it on GitHub:
#6 (comment)

[edmundchaniii]

Ok.. I'm pretty sure I see what's going on... If things are rerouted,
there is an issue.

Just as an example, say we have a routes set up like this:

login = account/login

login/(:any) = account/login

If we use the "account/login" url directly, everything it fine. Both
segments get passed in. If we use "login", we only get redirected to
"login/index"

So, that is definitely causing an issue.

I think this is where the core of the issue is...

Have you seen that?

C'ya,
Edmund

On Sun, Feb 12, 2012 at 2:47 PM, Edmund Chan edmundchaniii@gmail.comwrote:

Acckk. sorry again.. Still doing some odd things..

I'll let you know what I find after doing heavier testing.

C'ya,
Edmund

On Sun, Feb 12, 2012 at 2:41 PM, Edmund Chan edmundchaniii@gmail.comwrote:

Acck...

Just decided to update the line to check for segments and it seems to be

working (not sure about in sprinkle, but I would assume it does):

$uri = empty($uri) ?: (preg_match('@/@',$uri) ? $uri :
substr($this->uri->ruri_string(), 1, strlen($this->uri->ruri_string())));

C'ya,
Edmund

On Sun, Feb 12, 2012 at 2:36 PM, Edmund Chan edmundchaniii@gmail.comwrote:

Hmm. Interesting..

Never mind.. It's not working correctly. It ends up cutting
"module/function" to just "module", so it won't match "module/(:any)"..

Oh well..

On Sun, Feb 12, 2012 at 11:23 AM, Edmund Chan edmundchaniii@gmail.comwrote:

Hey..

Anyway, was just doing some debugging..

I think sprinkle will working correctly if this like is commented out

in the "_parse_routes" function:

$uri = empty($uri) ?: substr($this->uri->ruri_string(), 1,
strlen($this->uri->ruri_string()));

If you have a url like "somemodule/somecontroller", after that line, it
would make it "somecontroller/index.php".

So, it removes the module from that uri. I haven't tested Sprinkle to
see if it works, cause I just yanked that code out and was messing around
with it.

Anyway, help that hopes. I may test sprinkle a little later.

C'ya,
Edmund

On Sat, Feb 11, 2012 at 10:17 AM, Edmund Chan edmundchaniii@gmail.comwrote:

Just in case you are wondering why I am still trying to use Sprinkle
now that we are using External Asset Manager... It's because External is
working well for us, but it feels rather "raw".

Sprinkle just seems much more refined and is much easier to configure.
I also like how your groups work. It's just much easier being able to see
the order your assets are loaded in as far as groups go at least.

I also like the ability to use YAML for it's configuration. Being
able to Combine and cache the assets is great as well as minifying and
lessphp!

"but now the problem is that jquery ui will be loaded before
jquery itself. So you see how doing it this way would complicate things.
I was having thoughts of implementing some sort of ordering system but I
still need to figure out a neat way to do it without making asset loading
too complicated."

Yes, I believe that's what you need. I don't know if you've checked
out "External Asset Manager". There is a "weighting" system in there. It
works well. Each asset is given a weight and after all the assets are
fetched into an array, a sort is run on the weight and the assets are then
ordered according to it's weighting. This carries through to their Groups
as well.

When I was looking at Sprinkle code, I was wondering how hard it would
be to implement a weighting system. I think the way Sprinkle does it's
Groups is better in that you can physically see the order of the assets in
the Group.

Aren't all assets put into the "assets" array before being output in
the _output_assets function? I could be totally wrong cause I'm going off
of memory, but if you had weights for each asset, couldn't you implement a
sort on that array in the "_output_assets" function before the loop that
calls the create_tags function?

"Now, I can add omitted method ('index') detection in Sprinkle and a
route like welcome/(:any) would work with every URL as long as the
controller name is in the URL. However, then defining welcome as a route
wouldn't do anything and it would be useless. In that case you would have
no way of loading assets for the default method if it's omitted in the URL.
Your idea of adding (:default) wildcard would be beneficial then, if
that's what you had in mind."

Yes, that is exactly what I meant about (:default). Only if there is
no match, have it use the (:default) route.

Also, seeing (:any) is kind of ambiguous. Yes, I understand it should
match any URL, but what happens when there are other matches below that?
Are the (:any) assets overwritten or are they included in the final
results?

Just for clarity, I still think if you want assets for a route to
ALWAYS be used for ALL routes, I think instead of using (:any) the route
should be called (:all) or (:always) or even (:always_use). Just much more
descriptive of what it is doing. You know what I mean?

Also, just to let you know "External" seems to be routing correctly
with HMVC. May be worth checking out what they did with their URI's.

---

On Sat, Feb 11, 2012 at 4:15 AM, Edmundas <
reply@reply.github.com

wrote:

The way I intended for the routing to work is slightly different from
how CodeIgniter works with URI routing. I'll need to update the
documentation to provide with more examples.

For example, to setup URI routes, you have to first declare routes of
the "highest order" and work your way down. In Sprinkle, although it uses
the same code for parsing the routes, is the other way around. So first you
declare (:any) route for all pages, then, let's say, welcome/(:any) for
all methods of welcome controller. Maybe I'm approaching this from the
wrong angle but it does make sense to me. If it was constructed in the
opposite way, there would be a problem with ordering assets. For example,
if I first declare welcome/(:any) route and want to load jquery ui, I
must also load jquery:

welcome/(:any):
 assets:
   - jquery
   - jquery-ui

ideally I would want jquery to be loaded globally:

welcome/(:any):
 assets:
   - jquery-ui

(:any):
 assets:
   - jquery

but now the problem is that jquery ui will be loaded before
jquery itself. So you see how doing it this way would complicate things.
I was having thoughts of implementing some sort of ordering system but I
still need to figure out a neat way to do it without making asset loading
too complicated.

Taking your example, you have something like this:

test1/(:any)
test2/(:any)
test3/(:any)
(:any)

which actually should be like this:

(:any)
test1/(:any)
test2/(:any)
test3/(:any)
test3/foo/(:any)

right away you might think that it still doesn't solve one problem --
what if I do not want to "inherit" assets from, let's say, the global
route? This is where asset replacement and exclusion features come in.
Assets can be replaced and excluded with replace and exclude attributes
respectively. I have documented them in the wiki.

So, for some odd reason, it misses matching "test/(:any)" and just
matches the "(:any)". It's not just with the "test" module either. Once it
starts happening it just continues.

At the moment I'm doing tests with HMVC and after doing some
debugging I noticed that module routes are slightly different "under the
hood". I'm working on the issue right now.

However, there's more trickery involved in the asset routes (not just
with HMVC but overall). Suppose you want to load jquery for all welcome
controller methods. Instinctively you would define a route like this:
welcome/(:any). This will work with all URLs that have
welcome/segments/and/some/more/segments. However, it will not work if
there's no method specified (for example: http://localhost/myapp/welcome http://localhost/myapp/welcome)
although CodeIgniter routes to 'index' method if only a controller name is
specified in the URL.

On the other hand, if I define welcome route, then assets will be
loaded only if I do not specify the method in the URL (even if the
default method is specified it won't work: http://localhost/myapp/welcome/indexhttp://localhost/myapp/welcome/index
).

Now, I can add omitted method ('index') detection in Sprinkle and a
route like welcome/(:any) would work with every URL as long as the
controller name is in the URL. However, then defining welcome as a route
wouldn't do anything and it would be useless. In that case you would have
no way of loading assets for the default method if it's omitted in the URL.
Your idea of adding (:default) wildcard would be beneficial then, if
that's what you had in mind.

---

Reply to this email directly or view it on GitHub:
#6 (comment)

[edmundchaniii]

Ok..

Sprinkle / Routing Things I noticed when testing:

So, this is what I'm seeing:

With that modification I put on that line in _parse_routes:

$uri = empty($uri) ?: (preg_match('@/@',$uri) ? $uri :
substr($this->uri->ruri_string(), 1, strlen($this->uri->ruri_string())));

If I use a route in config/routes.php such as:

$route['login'] = "account/sign_in";
$route['login/(:any)'] = "account/sign_in";

And we use "http://hostname/account/sign_in", in the _parse_routes function
that line is returning "account/sign_in" with NO index.

If I try to use "http://hostname/login", in _parse_routes function that
line is returning "sign_in/index" with NO module.

With the original line like this:

$uri = empty($uri) ?: substr($this->uri->ruri_string(), 1,
strlen($this->uri->ruri_string()));

If I use a routes such as:

$route['login'] = "account/sign_in";
$route['login/(:any)'] = "account/sign_in";

if we use "http://hostname/account/sign_in" , in the parse_routes function
that line is returning "sign_in/index" with NO module.

If I try to use "http://hostname/login", in _parse_routes function that

line will return "sign_in/index" with NO module.

Conclusion:
If there are multiple segments, it seems like CI's routing (or Modular
Extensions routing maybe) removes the "index" segment before we even get it.

If there is a route in the routes.php file, it seems to drop the module on
multiple segmented urls.

Rather confusing !

C'ya,
Edmund

On Sun, Feb 12, 2012 at 3:25 PM, Edmund Chan edmundchaniii@gmail.comwrote:

Ok.. I'm pretty sure I see what's going on... If things are rerouted,
there is an issue.

Just as an example, say we have a routes set up like this:

login = account/login

login/(:any) = account/login

If we use the "account/login" url directly, everything it fine. Both
segments get passed in. If we use "login", we only get redirected to
"login/index"

So, that is definitely causing an issue.

I think this is where the core of the issue is...

Have you seen that?

C'ya,
Edmund

On Sun, Feb 12, 2012 at 2:47 PM, Edmund Chan edmundchaniii@gmail.comwrote:

Acckk. sorry again.. Still doing some odd things..

I'll let you know what I find after doing heavier testing.

C'ya,
Edmund

On Sun, Feb 12, 2012 at 2:41 PM, Edmund Chan edmundchaniii@gmail.comwrote:

Acck...

Just decided to update the line to check for segments and it seems to be

working (not sure about in sprinkle, but I would assume it does):

$uri = empty($uri) ?: (preg_match('@/@',$uri) ? $uri :
substr($this->uri->ruri_string(), 1, strlen($this->uri->ruri_string())));

C'ya,
Edmund

On Sun, Feb 12, 2012 at 2:36 PM, Edmund Chan edmundchaniii@gmail.comwrote:

Hmm. Interesting..

Never mind.. It's not working correctly. It ends up cutting
"module/function" to just "module", so it won't match "module/(:any)"..

Oh well..

On Sun, Feb 12, 2012 at 11:23 AM, Edmund Chan edmundchaniii@gmail.comwrote:

Hey..

Anyway, was just doing some debugging..

I think sprinkle will working correctly if this like is commented out

in the "_parse_routes" function:

$uri = empty($uri) ?: substr($this->uri->ruri_string(), 1,
strlen($this->uri->ruri_string()));

If you have a url like "somemodule/somecontroller", after that line,
it would make it "somecontroller/index.php".

So, it removes the module from that uri. I haven't tested Sprinkle to
see if it works, cause I just yanked that code out and was messing around
with it.

Anyway, help that hopes. I may test sprinkle a little later.

C'ya,
Edmund

On Sat, Feb 11, 2012 at 10:17 AM, Edmund Chan <edmundchaniii@gmail.com

wrote:

Just in case you are wondering why I am still trying to use Sprinkle
now that we are using External Asset Manager... It's because External is
working well for us, but it feels rather "raw".

Sprinkle just seems much more refined and is much easier to
configure. I also like how your groups work. It's just much easier being
able to see the order your assets are loaded in as far as groups go at
least.

I also like the ability to use YAML for it's configuration. Being
able to Combine and cache the assets is great as well as minifying and
lessphp!

"but now the problem is that jquery ui will be loaded before
jquery itself. So you see how doing it this way would complicate things.
I was having thoughts of implementing some sort of ordering system but I
still need to figure out a neat way to do it without making asset loading
too complicated."

Yes, I believe that's what you need. I don't know if you've checked
out "External Asset Manager". There is a "weighting" system in there. It
works well. Each asset is given a weight and after all the assets are
fetched into an array, a sort is run on the weight and the assets are then
ordered according to it's weighting. This carries through to their Groups
as well.

When I was looking at Sprinkle code, I was wondering how hard it
would be to implement a weighting system. I think the way Sprinkle does
it's Groups is better in that you can physically see the order of the
assets in the Group.

Aren't all assets put into the "assets" array before being output in
the _output_assets function? I could be totally wrong cause I'm going off
of memory, but if you had weights for each asset, couldn't you implement a
sort on that array in the "_output_assets" function before the loop that
calls the create_tags function?

"Now, I can add omitted method ('index') detection in Sprinkle and a
route like welcome/(:any) would work with every URL as long as the
controller name is in the URL. However, then defining welcome as a route
wouldn't do anything and it would be useless. In that case you would have
no way of loading assets for the default method if it's omitted in the URL.
Your idea of adding (:default) wildcard would be beneficial then, if
that's what you had in mind."

Yes, that is exactly what I meant about (:default). Only if there is
no match, have it use the (:default) route.

Also, seeing (:any) is kind of ambiguous. Yes, I understand it
should match any URL, but what happens when there are other matches below
that? Are the (:any) assets overwritten or are they included in the final
results?

Just for clarity, I still think if you want assets for a route to
ALWAYS be used for ALL routes, I think instead of using (:any) the route
should be called (:all) or (:always) or even (:always_use). Just much more
descriptive of what it is doing. You know what I mean?

Also, just to let you know "External" seems to be routing correctly
with HMVC. May be worth checking out what they did with their URI's.

---

On Sat, Feb 11, 2012 at 4:15 AM, Edmundas <
reply@reply.github.com

wrote:

The way I intended for the routing to work is slightly different
from how CodeIgniter works with URI routing. I'll need to update the
documentation to provide with more examples.

For example, to setup URI routes, you have to first declare routes
of the "highest order" and work your way down. In Sprinkle, although it
uses the same code for parsing the routes, is the other way around. So
first you declare (:any) route for all pages, then, let's say,
welcome/(:any) for all methods of welcome controller. Maybe I'm
approaching this from the wrong angle but it does make sense to me. If it
was constructed in the opposite way, there would be a problem with ordering
assets. For example, if I first declare welcome/(:any) route and want to
load jquery ui, I must also load jquery:

welcome/(:any):
 assets:
   - jquery
   - jquery-ui

ideally I would want jquery to be loaded globally:

welcome/(:any):
 assets:
   - jquery-ui

(:any):
 assets:
   - jquery

but now the problem is that jquery ui will be loaded before
jquery itself. So you see how doing it this way would complicate things.
I was having thoughts of implementing some sort of ordering system but I
still need to figure out a neat way to do it without making asset loading
too complicated.

Taking your example, you have something like this:

test1/(:any)
test2/(:any)
test3/(:any)
(:any)

which actually should be like this:

(:any)
test1/(:any)
test2/(:any)
test3/(:any)
test3/foo/(:any)

right away you might think that it still doesn't solve one problem
-- what if I do not want to "inherit" assets from, let's say, the global
route? This is where asset replacement and exclusion features come in.
Assets can be replaced and excluded with replace and exclude attributes
respectively. I have documented them in the wiki.

So, for some odd reason, it misses matching "test/(:any)" and just
matches the "(:any)". It's not just with the "test" module either. Once it
starts happening it just continues.

At the moment I'm doing tests with HMVC and after doing some
debugging I noticed that module routes are slightly different "under the
hood". I'm working on the issue right now.

However, there's more trickery involved in the asset routes (not
just with HMVC but overall). Suppose you want to load jquery for all
welcome controller methods. Instinctively you would define a route like
this: welcome/(:any). This will work with all URLs that have
welcome/segments/and/some/more/segments. However, it will not work if
there's no method specified (for example: http://localhost/myapp/welcome http://localhost/myapp/welcome)
although CodeIgniter routes to 'index' method if only a controller name is
specified in the URL.

On the other hand, if I define welcome route, then assets will be
loaded only if I do not specify the method in the URL (even if the
default method is specified it won't work: http://localhost/myapp/welcome/indexhttp://localhost/myapp/welcome/index
).

Now, I can add omitted method ('index') detection in Sprinkle and a
route like welcome/(:any) would work with every URL as long as the
controller name is in the URL. However, then defining welcome as a route
wouldn't do anything and it would be useless. In that case you would have
no way of loading assets for the default method if it's omitted in the URL.
Your idea of adding (:default) wildcard would be beneficial then, if
that's what you had in mind.

---

Reply to this email directly or view it on GitHub:
#6 (comment)

[edmundask]

Cheers for debugging. I isolated the problems and what is causing them. I'm somewhat busy this week so I'll probably push some updates this weekend.

[edmundchaniii]

Awesome !!

Can't wait.. Hope things workout !

C'ya,
Edmund

On Mon, Feb 13, 2012 at 4:01 AM, Edmundas <
reply@reply.github.com

wrote:

Cheers for debugging. I isolated the problems and what is causing them.
I'm somewhat busy this week so I'll probably push some updates this weekend.

---

Reply to this email directly or view it on GitHub:
#6 (comment)