From the very beginning it is important to understand the page design concept behind
gracelets. If this is not understood, it can cause some confusion in regards to expected
functionality when writing gracelet pages.
This concept involves combined code that can participate in different parts of the JSF
life cycle. This could be divided into three different aspects of a gracelet page:
In Facelets, when you design a view, you are really designing a blueprint. In other words
you are saying, this is the blueprint or template, and I want facelets to make a cookie-cutter
copy of this blueprint that will result in a JSF view. Obviously since Gracelets is an extension
to Facelets, this same logic applies. A major part of every Gracelet view is blueprint code. This
code is only ran once when the page is initially compiled and ran only again when the gracelet source
code has been changed.
This is very efficient, since the actual view is compiled into a singleton in memory and the JSF cookie
cutter copies can be made very quickly. Thus when writing a gracelet view, you must have in mind that
the blueprint code is only ran ONCE and is used to create the blueprint off of which each view will be
created. A JSF view is made off the blueprint each time there is a new request, subsequent requests where
the user sends information or requests some action to be done reuse the JSF view previously made.
In Gracelets you can write component libraries and also use inline render time components in your gracelet
views. The render code used in these components is ran every time the page is rendered. This code normally uses
normal markup builders than make xml markup easier to write.
Thus, in these sections of a gracelet view or component library you must have clearly in mind that your are
writing render time code, code that is not ran only once like the blueprint code, but rather every time the
view is rendered.
In Gracelets you can completely avoid using EL (Expression Language) strings, using closures instead of
action expressions, value closures instead of value expressions and so forth. This code is ran depending on its context.
Value closures are ran every time the value is requested, this could be at render time or at any other part of the
JSF life cycle. Action closures will be ran when their corresponding action components fire an event, like when
the user clicks on a button.
Below is an example gracelet view that contains each possible aspect of a view mentioned above. Each distinct
section will be highlighted so was to make clear when the code is ran.
The code in blue is blueprint code. This code is only
ran once in order to build the blueprint that will be used to create this view.
The code in green is render code. This code will be ran
each time the page is rendered. In this instance the code reads from an xml file that is in the same
directory as the view so as to get a list of items for the menu.
The code in red is action code. On line 4, this is code inside
of a factory closure, which will initiate the currentUser bean when it is null. On line 25, this is part
of a value closure, which will determine in this case the rendered logic for the form, which here says
that if the loggedIn flag is false, show the login form. On line 29 and 35 we have a value binding closures which
allows the value of the specified bean property in the closure to be used as the binding for the input components. On
lines 40-43 we have action closure code, which will be executed when the user clicks on the "Login" button. And
lastly on line 48 we have another value closure which is also determining whether or not this template will
show the actual view using it depending on the loggedIn value of the currentUser bean.