This page (revision-1) was last changed on 19-Jul-2006 09:36 by UnknownAuthor

Only authorized users are allowed to rename pages.

Only authorized users are allowed to delete pages.

Difference between version -1 and -1

At line 1 added 9 lines

[ImageHolder/parachute-small.jpg] "Parachute Rendering" is a term used to describe the general [IKAT] philosophy of rendering RSF "[components|Components]" by a contextual inspection of ''what is in the template already'' rather than just blindly stamping on it, as I believe it is fair to say ''all'' other frameworks do, at least those that even permit HTML templates in the first place.

The IKAT rendering philosophy is one of ''minimal disturbance'' to the template contents - for example, all attributes on a tag peering with a component are preserved, unless they are specifically required to be overwritten by the renderer.

The "parachute" idiom is based on the imagery that the renderer is "dropped in" onto the template from the great height of the code level, to inspect the "situation on the ground" - it uses this to inform its decision as to what rendering strategy to use for a particular component instantiation. This is as contrasted to the "bunker mentality" of JSF, Wicket and others whereby the rendering is decided as part of a "renderkit" or other distant server-side contraption. Parachute rendering puts the maximum power in the hands of the HTML designers and UI team who are in charge of the final deployment of an app to make quite drastic alterations to its appearance without requiring the expense and fragility of code changes.

The current "paradigm example" of parachute rendering in RSF is the renderer for the [UISelect] control, which currently makes a two-way decision based on whether the HTML tag it is peering with is a {{<select>}} or not. If it is a select, it will use it - if it is not, it will simply use the tag as a repository for any [fossilized bindings|FossilizedBinding] required and expect that the meat of the selection functionality will be provided with radiobuttons and checkboxes elsewhere on the page. You can see this in action on the [ComponentTest] test app.

This is just the start! As the RSF component set becomes richer and richer with user-contributed components and templates, the set of available options to renderers will become wider and wider - for example, renderers which automatically recognise Javascript-submitted {{<link>>}} forms, or special low-tech "accessible" templates.