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?
Related
I started a new application on the SAP HANA Cloud platform. However when I start it i get the following errors:
GET https://webidetesting5949052-p1940909951trial.dispatcher.hanatrial.ondemand.com/resources/sap/m/messagebundle_de_DE.properties 404 (Not Found)
GET https://webidetesting5949052-p1940909951trial.dispatcher.hanatrial.ondemand.com/webapp/i18n/i18n_de_DE.properties 404 (Not Found)
GET https://webidetesting5949052-p1940909951trial.dispatcher.hanatrial.ondemand.com/webapp/i18n/i18n_de.properties 404 (Not Found)
and so on....
However I never started to use i18n and I just want to disable it. I cant find anything in the manifest and I am not loading a i18n model anymore.
How can I resolve this issue? I dont want to use i18n, as it just clutters my code.
The first missing file is from within the framework. Some of the controls in sap.m have translatable text, and afaik there is nothing you can do about it.
The other lines suggest that you are instantiating an i18n model somewhere. Check your manifest.json or Component.js or neo-app.json for such an entry. These are the files where you'd normaly setup your models, including the i18n model.
Edit: It seems like you are using the WebIDE. To remove i18n from manifest.json, switch to Code Editor
If you don't want to use i18n in your code, don't use it. But the code of the framework itself heavily relies on that feature and no hardcoded strings are stored inside a .js file. If there actually was a way to disable i18n, then for example the sap.m.DatePicker wouldn't work anymore, since all strings for months and days are stored in one of the property files.
Btw I think having your logic (JS code) separated from content (i18n strings) is awesome and quite the opposite of cluttered code. All big mobile platforms (Android, iOS) and probably alot more frameworks support that feature. But that's just my 2 cents.
TL;DR don't instantiate your own i18n model, ignore the framework's errors
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.
I have a Grails plugin which I’m using as basically a container for some shared static resources that will be used by various other Grails projects in-house (CSS, JS files, etc). The idea of using a plugin was just to share these things — the plugin doesn’t really do anything else very interesting. What is the best way to directly reference resources inside the plugin? I’d rather not create custom taglibs, since I’m not really adding any functionality here; I just want access to the resources inside the plugin — something like this, e.g., to reference a CSS file from a GSP:
<g:link rel="stylesheet" url="${resource(dir:'css', file:'mycss.css',
plugin:'myplugin')}"/>
Does this idea violate the concept of plugins, where only certain aspects of it should be exposed, and the rest is a black box? Alternative approaches to sharing static resources among related Grails projects are also welcome, in case I’m headed down an insane, wrong-headed path by even trying this. :)
First, in Grails, a plugin is not considered a black box. To the contrary, all the code is exposed; if you really want to make it a black box, then you should use another plugin, Binary Artifacts.
Secondly, your approach is very sensible. To access plugin resources, I would have created a taglib like:
def res = { attrs ->
attrs.dir=pluginContextPath
//Do whatever you want here
out << g.resource(attrs)
}
and call it the same way as <g:resource>. That way, you don’t even have to expose your plugin’s resources path. The Nimble plugin is using this approach.
Also you might have a look at the Grails Resources plugin, which is trying to handle the nightmare of static resource dependencies among Grails plugins and projects. I have never used it, but for sure in my next Grails project, I will integrate it (BTW, it will be included into Grails 1.4).
I have a website that has related pages. They have links that point back and forth to one another but I have no integrated system, nor do I know what that would mean.
What is the minimum code that a group of web pages must have to be considered a Content Management System (CMS). Is it that all the settings are in the database and the pages are generated somehow? Is there some small snippet that all my pages could share that makes them a CMS, database or not?
Thanks. I was also hoping not to have to study a giant CMS to see what makes it a CMS . After maybe a basic understanding I would know what I was looking for.
edit: here's why I ask about code. Whenever I have looked at a CMS, and maybe they aren't all the same, I saw that to develop a module you always had to inherit from certain classes and had some necessary code. I didn't know if there was some magic model that I just don't get that all cms makers understand.
edit: perhaps my question is more about being extendable or pluggable. What would a minimum look like? Is it possible to show that here?
edit: how about this? Is something a CMS if it is not extendable and/or pluggable?
I think this is really impossible to say. We all manage content. The "system" is just whatever mechanism you use to do so(dragging and dropping in Explorer or committing content changes via a SQL query). To say there is a minimum amount of code needed really isn't indicative. What is indicative is how often you find yourself making mistakes and how easy it is for a given user of a given skill level and knowledge to execute the functions in the designed system. That tells you the quality/degree of what you have in place being worthy of being called a "CMS."
Simply put a CMS is an application that allows the user to publish and edit existing web content.
In response to the edit:
A "good" CMS allows of extensibility. By using inheritence you can extend the functionality of a CMS outside of the core components provided. That's the magic.
About Extensibility:
Depending on the language/framework you want to build your CMS with, you can load pages or controls(ASP.NET) using command built into the framework. Typically what is being done is a parent class/interface is being defined that forces an module that is to be developed to follow some given standards:
Public MustInherit Class CMSModule
'Here you will define properties and functions that need to be global to all modules being developed to extend your CMS.
public property ModuleName as string
End Class
public class PlugInFooCMSPage
inherits CMSModule
end class
Then it's just a matter of simply loading a module dynamically in whatever construct a given language/framework provides.
Ultimately, a CMS is a system that lets you manage content, so it needs an user interface that is dedicated to letting you easily create, edit and delete pages on your website.
However, it's fairly usual to expect from a CMS to provide a browser-based WYSIWYG page editor, file uploading, image resizing, url rewriting, page categories and tags, user accounts (editor, moderator, administrator), and some kind of templae system.
Without dragging you into a theoretical explanation of what a CMS is and what it's not, perhaps some tutorials on the building methodology of a CMS will help you better understand.
http://css-tricks.com/php-for-beginners-building-your-first-simple-cms/
http://www.intranetjournal.com/php-cms/
A Content Management System is a System that Manages Content. :)
So if you got many pages that share the same layout, you can create a system that stores the content into a database and when a page is requested, it gets that content, merges it with a template that contains the page header, menu, etc.. and outputs the result.
The basis idea is that you don't want to copy HTML pages, and have to edit hundreds of them when you want to change your layout.
Such a system can be very complex, featuring wysiwyg editors, toolbars, version control, multiple user publishing and much more, but it could be as simple as a single page behind a standard loging, that contains only an input field for the title and a textarea in which you type the html content.
I am building a perl cgi::application using html::template.
I am using 7-8 different templates having the same layout - header, footer, left column etc.
How can I separate this html out of the template files into a single layout file. What perl modules do I need in addition to cgi::app and html::template.
Thanks
I agee that Template-Tookit is better.
If you absolutely have to use HTML::Template you can use the TMPL_INCLUDE directive. It'll search your defined template paths or you can specify a full path to another template. It'll process the variables in it as well.
You can create seperate template files for the header, footer and such and in your page templates just TMPL_INCLUDE them. It's less elegant and more repetative than Template Toolkit's WRAPPER (You'll have to TMPL_INCLUDE in each page several times for all shared elements) but it'll get the job done.
If you can, invest the time and use Template Toolkit.
I'd switch out HTML::Template for Template-Toolkit and make use of it's WRAPPER directive.
I don't know about Template-Toolkit. So i won't discuss about which solution is the most convenient.
I can just give you another solution, which is dependant of the server your running your cgi's on.
With Apache server, you can use includes in your html :
<!--#include virtual="/includes/header/header.htm"-->
you may call htm (static pages) as well as dynamic pages :
<!--#include virtual="/perl/includes/dynamic.pl"-->
but you have to do some apache tweaking. see Apache Tutorial: Introduction to Server Side Includes
Hope this will help, or at least give some ideas
Can the people who don't like HTML::Template please say why? While the Wrapper idea seems helpful to this particular poster, there's nothing wrong with the idea of includes: they're more flexible, and many web developers will already be familiar with the concept from non-dynamic publishing.