-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
>
>
