How can I embed an external JavaScript library like Google maps within a JSF view?
In traditional HTML I'd do it like <script src="http://maps.google.com/maps/api/js?v=3.6&sensor=false"></script>.
I want to know if its compulsory to use < h:outputScript> tag when I want to include an external JS library in a JSF view, because all examples I was able to find on this subject assumed that the actual JS file was included in a web application project and thus used <h:outputScript>.
You can insert standard HTML elements in your JSF views, like <div> or <script>, as in your case. Moreover, JSF will ultimately render <h:outputScript> as a plain <script> element. We normally use the former to let the JS file pass through the FacesServlet.
All of this yields that your <script> element shall be inserted 'as is'.
Related
Based on the selection of a few form elements, I want to dynamically load a PDF file into an embed/object tag which is stored in a database.
Serving the PDF
I found this solution to serve a PDF from a servlet.
Is this the right approach when using Facelets? Because I thought when using facelets, I shouldn't need Servlets so how would I do that with a Bean?
As I load the PDF dynamically from a Database, I don't have access to a file on the file-system so in which way would I have to modify the response.setHeader?
Call from JSF
I thought that I would somehow first trigger a javascript function to update the content of the src attribute in the embed tag and then with the ajax tag from the jsf core library trigger the rerendering of the embed element.
Is this the right approach?
<embed src="#{pdfServlet.getPdf[desiredFileId]}"></embed>
Or can you render partially and render rest later. So lets say when app starts up it renders most of the html. But when user abc wants to see his profile jade renders name to abc and merge it with regular pre rendered html and then you send it etc.
Rendering whole html pages at every request seems like a waste.
Converting all static html to jade seems like a annoyance that can be avoided. Slowly css became LESS and html became JADE?
I am lost on how to use jade I am learning express.
You can use Jade's compileClient function to create a function that will render predefined Jade code on the fly. (See the API reference.)
So, if you create a Jade file with the dynamic HTML, and compile that for the client, you can then call that function at a later time, and insert the resulting HTML string to the DOM.
I would like to know the possibility to develop custom html tags or custom html attributes to node.js , rather in jade, html or another html template enginer. I was looking at PhantomJS and I don't realize any example that accomplish it, either Cheerio as well. My goal is to make some components to easily usage in any kind of popular html engines. Any direction will be very helpful. Thanks!
Node.js is just a webserver, You need something to parse the custom tags, so its either the template engine that will convert it to valid html, or client side with JavaScript (aka AngularJS directives)
You can write your own filter similar to the example
body
:markdown
Woah! jade _and_ markdown, very **cool**
we can even link to [stuff](http://google.com)
That would give you
<body>
<p>Woah! jade <em>and</em> markdown, very <strong>cool</strong> we can even
link to stuff
</p>
</body>
I get the idea of server and client side templating, but dust.js confuses me a little bit.
In order to use dust.js for client side templating, you need three steps:
complie the template
load the template
render the template
Right?
But where do the templates come from? I saw two different methods:
1. <script> template <script>
2. <div> template </div>
... Both of them are in the DOM. Which is correct?
I also notice that you can load the template via ajax, so the template won't be seen in the DOM, but I don't know how to do that.
Also, I'm currently using jade as express view engine. Is it necessary to switch to dust.js? What is the advantage?
This is LinkedIn Dust JS wiki page that can answer your questions and has very good examples: http://linkedin.github.com/dustjs/
But to answer your questions here:
Yes you need to compile your dust template which becomes a JavaScript file that you can add to your page by <script> tag and then call dust.render method to render your template. Here is an example:
write following code in a template file and save it as sample.tl
<p>Hi {firstName} {lastName}</p>
compile sample.tl to sample.js by dustc sample.tl in command line or use dust.compile("your_template_code", "template_name") to compile the template and save the output in a JavaScript file (sample.js) or you use duster.js to watch and compile templates by nodejs: https://github.com/dmix/dusterjs
add sample.js in your html:
<script type="text/javascript" src="sample.js"></script>
this will also register your template to dust.cache.
in your JavaScript:
var your_json = {firstName:'James', lastName:'Smith'};
dust.render('sample', your_json, function(err, out){
your_dom_element.innerHTML = out;
});
The result of above dust.render method will be <p>Hi James Smith</p>
So you need to pass 3 arguments to dust.render: dust.render(template_name, json, callback)
As the wiki say, you can use dust in the client or in the server. If you use it in the client you should get the template (for example with an ajax request), compile it an render in the browser. You will have to include the dust scripts file in your page.
By the other hand you can use dust in the server, (using rhino or nodejs). In this case you are going to compile and render the template in the server so the browser will receive html.
Should I use JSF2 resources instead of plain html like <link href... or url(image.png)? What are the benefits? For me this is a bit annoying when web-designer creates layout with XHTML, CSS and all that stuff and I need to spend time to replace plain HTML paths and tags to JSF resource tags like#{resource[...]}.
Is there any other way? Like to put all CSS/image files in web root and use normal links?
Your choice.
The major benefit is that you can declare them on a per-component basis. If you need to include them on every single page anyway, then the benefit is little. But if you need to include component-specific CSS/JS code in for example a composite component which is reused more than once in a single view, then for example an <h:outputScript> in a composite component would end up in it being included only once instead of that many times as the composite component is been used as would happen with <script>. The same applies to the #ResourceDependency annotation on real UIComponent classes.
Please note that you are not required to use JSF2 resources only. Just plain vanilla <img>, <link>, <script>, etc is also perfectly fine. It can even point to the JSF resources folder.