Is it possible in Zend Framework to contextually autoload a stylesheet based on a unique identifier?
I'd like to load css based on the layout and the action name by first checking if the stylesheet exists then loading it.
Is that possible?
Yes it is possible and surprisingly simple to implement. I have just started trying this for myself in a small project I am working on.
See Andy Baird's blog on this, which also includes the code you need to get you started. He continues it in a second blog which takes the concept slightly further.
He uses the same technique for both CSS and javascript files, so you may want to try it with both too.
Related
Right now, I am using <%- assets.js() %> to include all the javascript files on all pages. So, it means all the functions will be initialized on all pages.
I am wondering how can I disable a javascript file on a specific web page? Or, if there is a way to include some of the javascript files on a specific web page but not all the javascript files.
The trouble with the auto-loading is that it's really hard to dictate the ordering of the source files in any meaningful way-- it really comes down to how you've structured the front-end.
In v0.8.x (the version you're working with, from what I can tell), you can use the config/assets.js to control the ordering of folders that get loaded in. This is not ideal, but is a decent workaround that my team used on several projects.
In v0.9, we've removed rigging/asset-rack in favor of tight integration Grunt, which has a large community and some really cool and well maintained packages for most types of asset bundling, etc.
In any case, here are the different approaches you can investigate for serving assets in the new version of Sails.js:
Treat it just like anything else
In your layout.ejs file, create <link /> and <script></script> tags to link in your css and javascript files like you would normally.
Use AMD (Require.JS)
I think lots of folks would say this is actually the best option. Require is a pretty powerful tool. And I'm mostly in agreement-- if you're working with front-end javascript that could be coming from anywhere, and is going to be extended by other developers who may be using a different framework, AMD is a great way to make sure you stay safe. If you're using Require, each js file is its own module, and declares its own dependencies, so asset dependency management becomes a thing of the past. Then in production mode, there are a couple of different options to compile and minify your CSS and JS. You can even dynamically load templates and CSS from JS with Require, which is pretty neat. AMD/RequireJS is a hands-down winner if you're interested in loading some or all of your assets asynchronously. It's also an all-client-side solution, which is pretty cool.
The only downside in my mind is the complexity. If you have control over the framework being used, you really shouldn't have to manually enter dependencies for each file-- it can figure that out itself (see https://github.com/balderdashy/mast/blob/2.x/lib/raise.js)
Use Grunt
When you make a new project with sails new foo in Sails v0.9, a file called Gruntfile.js is created. It has lots of stuff in it, a lot of which isn't being used by default. You can do almost anything with Grunt, but in particular, you'll want to look at how it's set up to copy files from assets/* to .tmp/public/.
sails new foo --linker (Sails v0.9 only)
Linker is a lot like what asset-rack/rigging does currently. It creates the same Gruntfile as #3 above, but utilizes more of the contents. It will auto-link files in the order you specify. Instead of view partials (e.g. <%= %>), the scriptlinker plugin allows you to customize the delimiters where js, css, and templates will be injected. By default, the Gruntfile is set up to use JST precompiled templates, but again, you can set it up however you like.
Hope that helps guys, and best of luck!
-Mike
PS- v0.9 is coming out very very soon, I've just been working through tests and issues to make sure we're 100% there. If you'd like to try it out, check out:
https://gist.github.com/mikermcneil/5930330
The lead for Sailsjs replied to this issue (though it was about selecting CSS files):
"For now, you can (a) bring in all styles all the time and make only the relevant ones apply (b) use another tool (like Grunt) to bundle assets like you would in a vanilla node.js project or (c) link the stylesheets manually (put them in your public folder)."
See: choosing assets sailsjs
Similar, more complex questions have been asked in the Google group:
https://groups.google.com/forum/#!topic/sailsjs/yt9EpJlfzXA
Considering the above, you may want to have a separate layout.ejs for each page. You can specify the layout.ejs you want for each page with
res.view({ layout: "different_layout" })
The layout.ejs would (a) not call assets.js() but have < script > for all the js files needed, or (b) call assets.js() to serve all the common js files in ./assets/js plus < script > to serve the page dependant ones residing elsewhere.
I have a wrapper around assets.js() that allows you to include all assets except for specified files. You can also use it to include only specific assets elsewhere. So you could load your common assets in layout and include other assets only on pages where they are required.
See my answer to How can I include javascript assets selectively in SailsJS?
Up to now, I used to use template auto-parser. I like the fact I can modify any element of the template using typoscript, without altering the initial HTML file. I also like the fact that I can render the html template directly in a web browser, filling it with dummy elements to see examples of menus and content elements. Finally, with the new backend templates, i now can place content elements anywhere on a grid, in a way that mimics the real aspect of the website.
I know there is also TemplaVoila. I never took the time to learn it. My feeling is that it is less compatible with some extensions, but maybe I am wrong.
Now, there is fluid, that will be used in the next version of Typo3. While it is clear that it is better using it that using template markers, I don't really understand why I should be better using Fluid than using template auto-parser or TemplaVoila. What I dislike is the fact it requires to modify the html template with special tags, meaning that either the web designer has to know Fluid, or the Typo3 integrator has to modify templates from the designer each time a modification is performed.
My question is: should I migrate form template auto-parser to Fluid for my website template? What are the benefits of using Fluid? Why should it be better? What template system should I use with Typo3?
As long as TypoScript does not support objects, the benefits of FLUIDTEMPLATE over template auto-parser are only a few. So there is no need to migrate.
But IMHO there are some arguments to switch to fluid:
more and more extensions will use fluid, so it will help you to learn fluid
you can use an ide with code-completion for fluid (it is just XML!)
fluid is really powerfull, you can have f.e. if statements which checks for empty content
some day TypoScript will support objects as well
But for extension developement, it is totally different. In an Extension, i would allways prefere using FLUID. You do not have to deal with template things inside your extension anymore. Just pass the data to fluid and things which concern the view will be done in your template.
Whever you choose, it should be something based on Fluid - this will allow you to be extremely versatile and it makes the implementation less important than the template, which is quite good.
I myself am the creator of the "Fluid Powered TYPO3" framework (formerly known as FED) and would of course recommend that you take a look at what this framework can do for you - it's capable of great things, not the least of which is saving you a lot of time while at the same time allowing you to create even more consistent templating for pages and content - and even backend modules.
And we're always happy to help new users. We are currently in the process of improving our documentation, but you can already find many fully up-to-date guides on our Github page - https://github.com/FluidTYPO3 - the repository called "documentation" is the place we will store all the documentation.
You may want to have a look at http://fedext.net http://fluidtypo3.org - especially the "Tour of features" which tries to explain the point of Fluid Powered TYPO3 in as few words as possible. After that, the examples from the documentation will give you a much clearer picture of what Fluid Powered TYPO3 can do for you.
We focus on efficiency always - we've tried to do all the heavy lifting so that you really can just sit down and begin creating page templates. We took a lot of inspiration from TemplaVoila but there is no more re-mapping of content and things like this: when you change your templates, that change is immediately reflected, which makes it very nice to work with in iterations and do things like continuous delivery and -integration.
Hopefully this helps!
Cheers,
Claus aka. NamelessCoder
You could also argue, that adding special tags like
<f:section name="typo-content">
<div id="content">This is where the designer intended content to go</<div>
</f:section>
Could assist your designer while doing a redesign to know where you "mapped" your content elements to. This is neither the case with autoparser nor with TemplaVoila. So if the designer moves stuff around you probably get your templates back and they still work without any modifications.
I'm not sure where to ask this, but frankly I'm using some libraries from the zend framework but at this moment have the entire framework in my library folder. Is there any script or exe out there which go through the application and tell which files are not being used and which are. Theres loads of includes and easy loading going on there.
The files that are included via require_once in the Zend Framework code are mostly required only if they are used.
But if you want to be 100% sure that only the really used ones are loaded (on the fly), use the autoloader in combination with a script that strips all the require_once, as shown in the "Class Loading" part the official performance guide. There is a "How can I eliminate unnecessary require_once statements?" section. And this is a well know ZF optimisation technique, so it should be done anyway.
I am new to Zend Framework, but planning to create quite a complex project using it.
I was looking at the view options for Zend Framework. There is one with Zend_View and Zend_Layout and also template engines like Smarty can be integrated with it.
Now I would like to know, do they serve the same purpose? Like I can either use Zend_Layout or Smarty or is it better to use both?
I've worked on two large scale Zend projects. We don't use a separate layout engine, we just use the built in Zend_View.
Layering Smarty on top of Zend wouldn't serve much purpose (imo, would like to see some alternative experiences though)
I have seen lots of benefits of using smarty for nearly 10 years. First of all, smarty restricts template designers to use small set of functions which are related to view only. This will make easier to manage template files and will create a layer of security. Using PHP on view layer allows quick solutions with PHP and can create great mess. Smarty is compiled and there is nearly no performance loss. Syntax is more concise than PHP views. With Smarty 3 "template inheritance" features saved lots of time, which cannot be easily implemented with PHP classes.
I wouldn't use most of the classes from Zend Framework, that's why I'm looking for the thinnest possible ZF configuration.
Is there a better way of finding what I really need other than deleting the whole library/Zend folder, then putting back files based on the error messages that I receive?
I have not used it myself, but http://blog.fedecarg.com/2009/02/01/zend-framework-automatic-dependency-tracking/ may be what you are looking for.
Hm...
There is a lot of information about Zend Framework on SO and with a little bit of reading you would have found the answers to your question
You would also find the answers to your question by just reading the introduction to Zend Framework on the Zend Framework website.
No, that's not how you'll do it. Zend Framework, unlike most/all other PHP frameworks, is rigidly loosely coupled. You can use every component stand-alone. You can only use the loader, or only Zend_Translate. Or you can just use the MVC modules, or Zend_Db, etc.
Of course if you use Zend_Form and want to validate or filter the input, you'll need Zend_Validate and Zend_Filter. But you'll know that because you'll instantiate objects. So just copy into your empty library folder the modules you need. Or even better, copy everything in! A) you won't regret it. B) disk space is not your problem.
What I would do is set up the plugin loader cache and then purge all files apart from the ones called within the automatically generated include file.
zend.loader.pluginloader.performance
I hope it makes sense... :o)