Well I agree here mostly especially since
Tools like Netbeans rely on the startElement
etc... APIs. I just do not want to lose the generic tooling
I have regarding java.
Probably the sanest approach to resolve this would be some
kind of framework interceptor which could intercept
the code emitting stage for doing its own thing.
Then it could scan for tags and split it apart into the JSF APIs.
as for the other case:
> /*BEGIN_TEMPLATE
> <span style="$style" class="$styleClass">
> END_TEMPLATE*/
>
> // encode children
>
> /*BEGIN_TEMPLATE
> </span>
> END_TEMPLATE*/
I don´t think this is a huge problem, after all the interceptor must
parse the tags properly, every correct starting tag must result
in a startElement and a set of writeAttributes commands emitted.
Every endTag in an endElment. A syntax check for correct closure is not
needed, as long as it is a simple rewriter api.
As for closing the template and then open it again, this already is
covered by the compiler.
I purposely left the grammar that way that you at every stage
except for being inside a command (which is usually a #.... construct)
you can intercept the templating by simply closing the template
then doing java code and then reopening it.
Also I added the possibility of method calls from within templates as
long as they have a return value by treating variable calls like
$blabla() as method calls, so in many cases you wont even need
to break out of the template anymore!
Pretty much the same way velocity handles those issues.
And pretty much the opposite of minimalistic approaches like the EL.
For instance a call to encodeChildren at the current stage
could be done the following way:
/*TPL
<span style="$style" class="$styleClass">
TPL*/
this.encodeChildren(facesContext, component)
/*TPL </span>
TPL*/
or the better option because it gives a more precise control
on the layouting!
/*TPL
<span style="$style"
class="$styleClass">$this.encodeChildren($facesContext, $component)</span>
TPL*/
or if you want to have multilines without any carriage returns in the
result code
/*TPL
<span style="$style" class="$styleClass">\
$this.encodeChildren($facesContext, $component)\
</span>
TPL*/
The second and third options however would only work in the current state
if encodeChildren returns something printable. I will add a void
resulting method option in the next days, but for now I am purely
functional, regarding this. (I am still thinking about a good solution
which does not have to revert to introspection)
Werner
Andrew Robinson schrieb:
-1 on this idea
The problem is that I have seen code, like in Trinidad, where it is
required an essential to call start & end element. For example,
Trinidad uses escaping inside of a SCRIPT element to ensure that the
encoded text does not break the HTML. Removing these calls and
bypassing the ResponseWriter recommended APIs could easily break
output that "smart" ResponseWriters depend on.
Perhaps if this were done, the comment would be parsed by the parser
into XML and then use that XML to extract element names and attribute
name value pairs.
So:
/*BEGIN_TEMPLATE
<span style="$style" class="$styleClass">$content</span>
END_TEMPLATE*/
would become:
responseWriter.startElement("span", component);
responseWriter.writeAttribute("style", style, null);
responseWriter.writeAttribute("styleClass", styleClass, null);
responseWriter.writeText("content", content, null);
responseWriter.endElement("content", content, null);
the problem here is if this were done, how to treat code java code
that needs to run inside the content like:
/*BEGIN_TEMPLATE
<span style="$style" class="$styleClass">
END_TEMPLATE*/
// encode children
/*BEGIN_TEMPLATE
</span>
END_TEMPLATE*/
I don't have a good implementation idea on the creation of the code,
but I would really hate to see any code bypass the startElement,
writeAttribute and endElement methods.
On Mon, Oct 6, 2008 at 4:15 PM, Werner Punz <[EMAIL PROTECTED]> wrote:
Actually Simon you just gave me the perfect example
Simon Kitching schrieb:
We are not talking about doing away with any existing templates, right?
No, the existing templates are not touched, what we have here is more or
less an extension to java which adds multiline strings and string templating
in a very generic way without colliding with the java syntax itself.
AIUI we're just talking about replacing a whole bunch of calls to
responseWriter.startElement("span")
responseWriter.write("hello," + planetName);
responseWriter.endElement("span")
etc
Actually the new code would look like
... do something in java here
/*TPL
#outputop(responseWriter.write)
<span> hello $planetName </span>
TPL*/
... do again something in java here...
It would not result in entirely the same code after the compile,
but with the current state of affairs more or less in following code:
responsewriter.write("<span> hello ");
responsewriter.write(planetName);
responsewriter.write(" </span>");
I do not cover the startElement stopElement, and attribute etc.. apis
because I wanted to be as generic as possible (so that it can be covered
outside of jsf.
Theoretically it would be possible in the long run to cover those as well
(by simply parsing the code which has to be printed in a second step for tag
constructs). For now I leave it that way.
As I said in an earlier mail, I got the idea by groovy which has multiline
strings and limited string templating, but I went for the comment syntax
because I did not want to break existing java tooling.
(Pretty much like the jboss guys did in their compiler, but on the xml side
by using CDATA blocks to cover the java code)
I hope that clears things a little bit up.
Werner
