Missing CSS,JS Content and other issues with HMVC

Open edmundchaniii opened this issue 12 years ago • 18 comments

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

Feb 10 '12 23:02 edmundchaniii

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.

Feb 11 '12 00:02 edmundask

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 < [email protected]

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: https://github.com/edmundask/Sprinkle/issues/6#issuecomment-3916906

Feb 11 '12 01:02 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 [email protected]:

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 < [email protected]

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: https://github.com/edmundask/Sprinkle/issues/6#issuecomment-3916906

Feb 11 '12 02:02 edmundchaniii

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.

Feb 11 '12 12:02 edmundask

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 < [email protected]

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: https://github.com/edmundask/Sprinkle/issues/6#issuecomment-3920331

Feb 11 '12 18:02 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 [email protected]:

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 < [email protected]
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: https://github.com/edmundask/Sprinkle/issues/6#issuecomment-3920331

Feb 12 '12 19:02 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 [email protected]:

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 [email protected]:
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 < [email protected]
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: https://github.com/edmundask/Sprinkle/issues/6#issuecomment-3920331

Feb 12 '12 22:02 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 [email protected]:

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 [email protected]:
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 [email protected]:
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 < [email protected]
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: https://github.com/edmundask/Sprinkle/issues/6#issuecomment-3920331

Feb 12 '12 22:02 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 [email protected]:

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 [email protected]:
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 [email protected]:
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 [email protected]:
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 < [email protected]
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: https://github.com/edmundask/Sprinkle/issues/6#issuecomment-3920331

Feb 12 '12 22:02 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/(: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 [email protected]:

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 [email protected]:
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 [email protected]:
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 [email protected]:
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 [email protected]:
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 < [email protected]
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: https://github.com/edmundask/Sprinkle/issues/6#issuecomment-3920331

Feb 12 '12 23:02 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 [email protected]:

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 [email protected]:
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 [email protected]:
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 [email protected]:
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 [email protected]:
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 <[email protected]
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 < [email protected]
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: https://github.com/edmundask/Sprinkle/issues/6#issuecomment-3920331

Feb 13 '12 00:02 edmundchaniii

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.

Feb 13 '12 12:02 edmundask

Awesome !!

Can't wait.. Hope things workout !

C'ya, Edmund

On Mon, Feb 13, 2012 at 4:01 AM, Edmundas < [email protected]

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: https://github.com/edmundask/Sprinkle/issues/6#issuecomment-3938500

Feb 13 '12 17:02 edmundchaniii

Oh hey.. Just wanted to say.. I keep forgetting to mention something we previously discussed.

" "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.

"

No, that's actually not EXACTLY what I had in mind. It's more sort of what I had in mind.

Not telling you what to do, and I know Sprinkle isn't External Asset Manager, besides weighting, here is something else he did with the default controller that makes a lot of sense.

If it's the default controller, the uri string is apparently "" (empty). He gives it the value of "home" so that it can still be assigned the assets of the "home" route.

As for (:default). Yes it would be great for when you have a bunch of url's that you don't want to set up individual routes for. You could assign them the assets from the (:default) route.

Also, once again, I know that CI uses the (:any) route in it's routing, but even as you said, your routing works a little differently. I kind of think that in Sprinkle, as an asset manager, it would be better if you were more descriptive with that route. Maybe it would be very clear if you called it (:always) and made it clear in the docs that it's because its assets are ALWAYS included in every route.

Then, if you had weighting, it seems that it wouldn't even matter what order (:always) is declared in the routing list.

So, there are 3 things (besides weighting) that I think would really make

Sprinkle flexible without making it too complex.

home - rename empty route ("") to home so it can match the "home" route.
(:default) - matches all unmatched url's and must be at the bottom of the routes list.
(:always) - change (:any) to (:always) or at least allow it to be used

as a more descriptive alias.

Well, there's a few things to maybe think about.

C'ya, Edmund

On Mon, Feb 13, 2012 at 9:50 AM, Edmund Chan [email protected]:

Awesome !!

Can't wait.. Hope things workout !

C'ya, Edmund

On Mon, Feb 13, 2012 at 4:01 AM, Edmundas < [email protected]

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: https://github.com/edmundask/Sprinkle/issues/6#issuecomment-3938500

Feb 14 '12 09:02 edmundchaniii

Just letting you know that changes are being made in a separate branch: https://github.com/edmundask/Sprinkle/tree/dev

Added (:default) and (:home) wild-cards as suggested. I'll continue working on this until it's stable, then I'll merge it with the master branch.

Feb 19 '12 20:02 edmundask

Awesome!!

Hey,

I don't know how you feel about this being added to sprinkle, but I had modified ours to allow us to add other assets.. For example I added "pagedata" Which was basically just a modified css or js array. At any rate, you could add variables in there such as "title", "description" etc. They would be returned in an array that had the variables that were defined and they would be accessed from that array. I was going to add the ability to allow meta data when I found the issue with the routing.

Anyway, can't wait to get the update!

C'ya, Edmund

On Sun, Feb 19, 2012 at 12:08 PM, Edmundas < [email protected]

wrote:

Just letting you know that changes are being made in a separate branch: https://github.com/edmundask/Sprinkle/tree/dev Added (:default) and (:home) wild-cards as ted. I'll continue working on this until it's stable, then I'll merge it with the master branch.

Reply to this email directly or view it on GitHub: https://github.com/edmundask/Sprinkle/issues/6#issuecomment-4044728

Feb 20 '12 00:02 edmundchaniii

I'm not sure what you mean. In general, Sprinkle is designed to work with assets such as CSS and JS. It should not contain any information other than what is needed for the assets to be loaded on the page. Variables that get injected into the HTML structure should have a system (library) of their own.

I have made a prototype for a templating library not so long ago. Basically, it's a port of Twig template engine for CodeIgniter with a bunch of neat stuff to make the life easier when working with page layouts, templates and overall page structure. That's where such thing as variables should go.

Feb 20 '12 01:02 edmundask

I understand.. I agree too.. I made the mods for the other team member who is working on the front end. It is convenient, though.

The other guy is pretty lazy and he's an older guy that for whatever reason, didn't want to bother learning how to use phil sturgeons template system so that's why that modifcation was made.

Anyway, Thanks for Sprinkle. Once it's stable, I'll be using it on other projects that I am working on separately!

On Sun, Feb 19, 2012 at 5:04 PM, Edmundas < [email protected]

wrote:

I'm not sure what you mean. In general, Sprinkle is designed to work with assets such as CSS and JS. It should not contain any information other than what is needed for the assets to be loaded on the page. Variables that get injected into the HTML structure should have a system (library) of their own.

I have made a prototype for a templating library not so long ago. Basically, it's a port of Twig template engine for CodeIgniter with a bunch of neat stuff to make the life easier when working with page layouts, templates and overall page structure. That's where such thing as variables should go.

Reply to this email directly or view it on GitHub: https://github.com/edmundask/Sprinkle/issues/6#issuecomment-4046940

Feb 21 '12 01:02 edmundchaniii

Sprinkle Sprinkle copied to clipboard

Missing CSS,JS Content and other issues with HMVC

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

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

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

the "_parse_routes" function:

the "_parse_routes" function:

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

the "_parse_routes" function:

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

the "_parse_routes" function:

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

login/(:any) = account/login

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

in the "_parse_routes" function:

With that modification I put on that line in _parse_routes:

With the original line like this:

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

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

login/(:any) = account/login

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

in the "_parse_routes" function:

"

Sprinkle flexible without making it too complex.

as a more descriptive alias.

Sprinkle
Sprinkle copied to clipboard