-
-
Notifications
You must be signed in to change notification settings - Fork 29
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add compatibility for inline JS/CSS groups #40
Comments
I'm not going to be at a machine with a web stack on it for a few days, but until then... Are you getting confused between the (confusingly named) inline groups, and the You should be able to define three groups (without_jquery, footer, and with_jquery), setting the 'inline' property on the former and latter to 'true', then just render them one after another? i.e. \Casset::render_js('without_jquery');
\Casset::render_js('footer');
\Casset::render_js('with_jquery'); Mind you, it's been a while since I used Casset, so I could be wrong. Thinking about it, I can't see the point of being able to define a JS string to be included, and being able to specify dependencies on that string. You might as well just enable those groups. Adding random JS strings to an existing group might be handy, but could well be more effort than it's worth. |
I'm not confused about the naming of the groups but perhaps I'm just going about my implementation the wrong way. To achieve what I'd like with the groups as they stand now I'd have to write CSS/JS to files so that Casset could include them as part of the group. Perhaps if I explain the functionality/use case properly rather than trying to abstract it, it'll give you a better understanding. I have a modular application, which outputs some inline JS in the head such as paths. These can't be saved to a file because they change depending on the installation directory or the currently enabled language etc. The various modules output the variables or bits of code they share. <script type="text/javascript">
var base_url = 'http://localhost/application/public/';
var active_language = 'en';
var drag_rest_location = "api/v1/actions/test/reorder";
</script> Now that we have these variables they can be used in other bits of Javascript in any of the groups- great. jQuery (and other scripts) ideally need to be output just above the <head>
\Casset::render_js_inline();
</head>
<body>
\Casset::render_js('footer'); // Includes jQuery
</body> But now if I decide that I need to allow a module to output some inline JS but some which relies on jQuery then It appears above the inclusion of jQuery. Similarly, render_js_inline() can cause race conditions when a bit of inline relies on another bit of inline JS, i.e. a modular dependency. There's no way to guarantee that the required inline JS has been output. The only way to get around the former issue at the moment is as follows. But this doesn't alleviate the inline JS dependencies problem. <head>
\Casset::render_js('jquery'); // includes jQuery
\Casset::render_js_inline();
</head>
<body>
\Casset::render_js('footer'); // No longer includes jQuery but group has deps => jQuery
</body> As I say, perhaps I'm looking at this all wrong. If you could provide some insight that'd be much appreciated. Cheers |
One clarification: when you say "But now if I decide that I need to allow a module to output some inline JS", is that inline JS which can be put in a file, or is that generated at run-time as well? |
Generated at runtime too. For example I have a WYSIWYG module which can be switched out with various different JS implementations depending on client settings- it determines if there are any instances of $(document).ready(function() {
$('#fieldset-field-id').wysiwyg()/redactor()/ckeditor(); //etc 1.n times
// or
$('.wysiwyg')..wysiwyg()/redactor()/ckeditor(); // etc
}); There are other modules which do similar things but this is just one of the examples. |
Any word on whether or not you're considering this? Cheers |
It'd be nice to be able to render groups of inline JS/CSS much like you can with the standard groups.
The reason for this is for example outputting non jQuery related global vars in the header i.e.
And then also the ability to add some bits after the group in which jQuery is rendered.
It'd also be nice given the above if dependency support for inline groups might be included too.
Cheers
Ben
The text was updated successfully, but these errors were encountered: