Hi
Based on the previous discussion, and with the intention of develop other
alternatives to this problem (if you want it do
it yourself), I have attached a possible solution for this problem. (code
available on TOMAHAWK-1327 file
RendererGenerationUsingXSLT.zip)
The strategy used was generate from a xhtml file a java renderer file
(*.java), using a xslt transformation. The code is
integrated with myfaces-builder-plugin to trigger renderer generation, using
a plugin.
In other words, the idea is generate from this:
<span style="@@style@@" class="@@styleClass@@" content="@@content@@"/>
something like this:
writer.startElement("span", component);
writer.writeAttribute("style", style, null);
writer.writeAttribute("class", styleClass, null);
writer.writeText("content", content, null);
writer.endElement("span");
The elements that needs to be defined are:
1. Define a abstract renderer class like this (the class pointed on class
attribute of @JSFRenderer is the file to generate):
/**
* @JSFRenderer
* renderKitId = "HTML_BASIC"
* family = "javax.faces.Output"
* type = "org.myorganization.SayHelloRenderer"
* class = "org.myorganization.component.sayhello.SayHelloRenderer"
*/
public abstract class AbstractSayHelloRenderer extends Renderer
{
.....
//The method to generate, the body is defined on a xhtml file
public abstract void encodeSomeHtmlOrJavascriptPart(FacesContext
context, UIComponent component) throws IOException;
}
2. Define a xhtml file called
src/main/resources/org/myorganization/component/sayhello/SayHelloRenderer.xhtml
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "
http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd";>
<html xmlns="http://www.w3.org/1999/xhtml";
xmlns:mbp="http://myfaces.apache.org/mbp";>
<mbp:import>javax.faces.component.UIComponent</mbp:import>
<mbp:import>javax.faces.context.FacesContext</mbp:import>
<mbp:import>javax.faces.context.ResponseWriter</mbp:import>
<mbp:import>javax.faces.render.Renderer</mbp:import>
<mbp:import>java.io.IOException</mbp:import>
<body>
<mbp:renderMethod
signature="public void void encodeSomeHtmlOrJavascriptPart(FacesContext
context, SayHelloComponent component) throws IOException"
writerVar="writer" componentVar="component">
<mbp:scriptlet>ResponseWriter writer = context.getResponseWriter();
</mbp:scriptlet>
<!-- HERE GOES SOME HTML OR JAVASCRIPT CODE TO BE COMPILED TO JAVA
SOURCE CODE -->
<span style="@@component.getStyle()@@"
class="@@component.getStyle()@@">@@component.getContent()@@</span>
</script>
</mbp:renderMethod>
</body>
</html>
3. Use myfaces-builder-plugin (see code on TOMAHAWK-1327 for details).
On TOMAHAWK-1327 file RendererGenerationUsingXSLT.zip there is a more
elaborated example using s:togglePanel as
base (see directory named "resume" for details about xhtml source file and
java results).
I'm trying to enhance it with more features and correct some bugs.
If the community would like it I would merge it into myfaces-builder-plugin.
Suggestions are welcome
regards
Leonardo Uribe
On Tue, Oct 7, 2008 at 6:49 AM, Werner Punz <[EMAIL PROTECTED]> wrote:
> Ok to summarize this thread
>
>
> Generelly the compiler is appreciated, but
>
> a) We need a jsp like mechanism for dynamic compilation of the source
> templates, that should be doable, although it would mean modifications
> within the source how the templates are called (probably loading them via a
> utils class from the renderer)
>
> b) We need a more precise handling of the JSF APIs, that is much harder
> than a) but I think it is solvable one way or the other
> (probably by a second interpretion step which scans for tags and
> also merges the incoming variable expressions into the mix.
>
> Anything else?
>
> Besides that one question is open. Do we host it within myfaces
> or should I put it somewhere else (my preferrence would be java.net
> outside of myfaces due to its maven support)
>
> If we host it within myfaces, I will take care of the codegrant today or
> tomorrow and will start to work on the additional features after the code
> drop.
> If not, I will drop it somewhere else and will keep the mailinglist
> notified.
>
> Either option is fine by me!
>
>
> Werner
>
>
>
>
>
>
>
>
