Can someone explain me what it means when they say:
"HTML Helpers enables to encapsulate the rendering of HTML"
Does it mean it will restrict access to the HTML attributes of an object? What if I am using CSS, jquery, Javascript, will it display my JS/jquery and CSS in page source?
HTML helpers are bits of code that will render out the HTML, instead of you writing out the HTML for each and every piece of data directly in the view.
They encapsulate it - meaning they take care of what HTML is output.
By "encapsulating the rendering", they are referring to the encapsulation of the functionality of rendering html.
If there is a common piece of html you render often, (the rails form helpers for example), if you insert the code (or the code building functionality within a helper), each time you need to render that html (or a variant of it) , you merely call the helper method thereby keeping your code "dry" (html code in this case)
Related
The form.as_ul shortcut works completely fine but the html isn't formatted. The only solution I found was to include a middleware which beautifies the complete html but I only want to do that for the form part. Is there a other way than write my own form template?
If you are talking about the formatting of the HTML code itself, consider not worrying about it.
In most cases the formatting of your HTML code is unimportant. It gets consumed by a browser and rendered for users. It is that rendered output that is important.
(Just for fun, load up your local Google search page and have a look at its source. It's definitely not optimized for people to read.)
In case you do want to format your HTML in a particular way you can always render fields manually.
I am making a new version of an "old" software based on the Zend_Frameword 1.x,
this project use zend_form to create versatiles forms I like this aspect of the code, and i'd like to keep it.
But I need to be cross domain and to render the html with javascript, so I'd like Zend_Form to render in JSONP.
on the past I already experience the hard to understand decorators of zend_form and i don't think that I can use them to render in JSON, so, I think that the only way to go is to extend Zend_Form, to implement my own render method, but event so, I have the feeling that it won't be easy...
I'm this afraid of Zend_Form that I am thinking that maybe rendreing the form in html and parsing it on the javascript side to create a structure sufficient to then use it with handlebars (the javascript template engine) would be easier
Parsing html seems suboptimal to me.
Your initial idea - creating your own form class extending Zend_Form and adding a renderJsonp() method - seems a pretty reasonable approach. In the simplest case, your rendering could extract the form attributes and then iterate over the elements, extracting their attributes.
However, remember that a Zend_Form instance is more than just a list of form attributes and elements with their attributes. There are potentially display groups (typically representing html fieldsets) and validators attached to form elements. Also, even if you do not change the decorators used to render the form, they are part of the rendering. A json representation of the form that does not reflect those decorators would probably render into html differently than you experience when Zend_View is responsible for the rendering in a view-script.
While it may be possible to have that displaygroup and validator information reflected in the structure of your json output, it seems unlikely that you would be able to easily automate creation of client-side validation that perfectly parallels that on the server-side side.
One approach I have seen is to have your client-side front-end make an AJAX request to a specially defined route that renders the full html of the form. While I am not a fan of this approach, it does have the advantage that the form remains essentially DRY, all the information required for rendering the form resides back on the server side but is still available to the client. The only thing missing is extracting the server-side validation for use on the client-side.
Just thinking out loud, so not a great answer, but it seemed too long for a comment.
In Seaside, in all those renderContentOn: methods, I can use the HTML canvas object to assemble my DOM tree.
I am writing a bunch of helpers for my components currently, because I'm using Twitter Bootstrap for the styling and don't want to write all that boilerplate code (<div>s en mas) all the time.
For the way this is setup, the easiest way for me is to simply (I want to avoid using with: aBlock in those helpers) write out the HTML for the wrapping DIVs like this:
html html: '<div class="control-group">'.
Is there any reason for me not to do this? Any downsides?
There are various advantages in using the HTML canvas:
The HTML canvas ensures valid tags, a valid tag structure, that all tags are properly closed (at compile time), and that contents is properly escaped.
The HTML canvas ensures valid attributes, that all attributes are properly closed, and that contents is properly escaped.
As a consequence of the above two the HTML canvas automatically avoids the possibility of cross-site scripting (XSS) vulnerabilities.
The HTML canvas enables better reusability by enabling composition of tags (simple function calls), presenters (renderOn: in Objects), and components (renderContentOn: of components).
The HTML canvas avoids generating unnecessary whitespaces.
The use of HTML canvas enables one to use the standard tools the Smalltalk IDE provides on HTML code: senders, implementors, refactoring engine (extract to method, extract to component, inline method, automatic rewrite, ...), etc.
I agree that in some rare cases it is not worth to use HTML canvas: For example, when large static junks coming from an external source need to be embedded into a page.
I don't think there is a real downside to render static html pieces like that.
However, you might want to check out the Seaside integration of Twitter bootstrap: http://twitterbootstrap.seasidehosting.st/
To rephrase one of Lukas' arguments: it basically is not DRY. If you're using it only once, there is no problem. If you have to use this multiple times, the canvas allows you to use all the clean reuse capabilities smalltalk offers you.
I was inspecting today's Google Doodle of Moog Synth, dedicated to Robert Moog,
when I came across the following piece of html code:
<w id=moogk0></w>
<s id=moogk1></s>
<w id=moogk2></w>
<s id=moogk3></s>
(You can view the source & do a Ctrl+F for , you will get it in the first search result).
I googled about s & w tags but found nothing useful except that the s tag is sometimes used to strikeout text but is now deprecated.
Obviously google will not be using deprecated tags but I guess there's a lot more behind this than plain html code. Can anybody explain me the use of this tags? & how does the browser recognise them? & if the browser does not recognise them, whats their use?
The browser doesn't recognise them.
But HTML was designed to ignore what it doesn't recognise, so these are simply not understood by the browser and get ignored. As elements without content, they will not get rendered at all either, though they will be part of the DOM.
However, these can be styled directly as elements in CSS and picked up by Javascript (getElementsByTagName and getElementById etc...).
In short, these elements provide a target for CSS and Javascript without any other impact on display.
Unknown elements are treated as block elements (like div) and can be styled accordingly and be used in scripts.
The tags you are talking about are user created XML tags.
If you need to display dynamic data in your HTML document, it will take a lot of work to edit the HTML each time
the data changes.
With XML, data can be stored in separate XML files. This way you can concentrate on using HTML/CSS for display and layout, and be sure that
changes in the underlying data will
not require any changes to the HTML.
With a few lines of JavaScript code,
you can read an external XML file and
update the data content of your web
page.
So I have some user generated content areas of my site. I want them to be able to use html for markup purposes, but I don't want them to be able to execute any arbitrary javascript.
From my understanding raw() will just output everything, html, javascript, and all right into the webpage.
Is there a method that will allow raw rendering of html but not allow rendering of javascript?
Have a look at sanitize.