cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Glen Ezkovich <g...@hard-bop.com>
Subject Re: [RT] since we are at it, more irons in the template fire: Xenon
Date Thu, 09 Dec 2004 04:56:48 GMT

On Dec 8, 2004, at 2:55 PM, Leszek Gawron wrote:

> Glen Ezkovich wrote:
>> On Dec 8, 2004, at 11:10 AM, Stefano Mazzocchi wrote:
>>>
>>> I think we should call our CTemplates taglibs "lenses" instead.
> I like it.
>
>> Call them what you will. It doesn't change the core issue. If 
>> "lenses" allow you access databases, send emails, invoke business 
>> methods, etc. you still are inviting JSP/XSP like abuse, albeit, 
>> syntacticly not as ugly. It is not what you want to use them for, but 
>> what they can be used for and how they are introduced into the system 
>> that lead to potential problems.
> Even right now you can call arbitrary Java code in JXTG by simple
> <jx:set var="ignore" value="${Packages.org.apache.cocoon.Foo.bar()"/>. 
> You would have to disallow to reference ANY method. In that case the 
> template language would be very restrictive which I am not that great 
> fan of.

I know. And that would not be what I want. I can think of ways we can 
get around this, but I think it might be going to far; more reflection 
would not help performance and I'm not going to suggest that we write 
another XML mapping file. At some point you have to trust others.

>
>> That said, "lenses" as a name would at least not encourage anyone to 
>> abuse the system. In that sense, it is superior to "taglib". 
>> Unfortunately, they would be semantically the same.
>> So here you have my non-voting +1
> +1. Good name which does not raise wrong emotions.
>
>> And another bit about the issue of needing user defined java backed 
>> taglibs/lenses:
>> Lenses and views are exactly what I want in order to provide 
>> reusability and the building of pages from components. These seem to 
>> be micro and mini templates. What is it that you cannot do with a 
>> library of jx:macros that causes you to need a full fledged Java 
>> object?
> If talking about proper "tag" implemenetation (one that does only 
> allowed actions) probably you could switch to macros. JXTG lacks only 
> one feature that would make macro system complete: the ability to 
> invoke a macro which name is resolved by expression. I will create 
> another post about that.

And this could be added. (and now you seem to be doing just this. it 
took me to long to get back to this ;-))

>
> Still there is one other this that jx:macro is not that suitable for: 
> convertors. See previous threads for the problem description.
>

I recall that thread (or a thread with regard convertors and CForms, if 
this is the wrong thread please, let me know). This is one of the 
reasons I choose to use JXTG to inject data into a xml template and not 
generate the view. This way when it comes time to render the view all I 
have are strings. No assumptions about data types are required and no 
conversions are required. Granted this is not always the most 
satisfying way to do things but it does work.

Now, since obviously a lot of people want to be able to go straight to 
rendering, convertors would seem to be a good thing. Convertors for use 
in CForms need to be bi-directional, going from type to string and 
vice-versa. I can think of domain specific cases where custom 
convertors will be more then useful. There is no doubt that within the 
CForms framework custom convertors make perfect sense.

Converters in templates only need to convert from type to string. 
Granted there is an implicit string to type conversion in something 
like <jx;if test="${obj.getAmount()} &lt; 10}">. It seems that the 
jx:macro can handle these cases. I don't see the need to add external 
libraries in order to render an object.

If you need custom convertors, it seems to me that you would want to 
add them to your project where they are needed. In the form definition. 
To be fair once this work is done it would be nice if there were a way 
to use the convertors from within any template. Convertors are just 
java objects they, can be passed from flow. They could be accessed from 
the form. Or can be made part of the template framework and accessed by 
a tag or attribute.

My point is, for rendering, convertors are not necessary. Once you have 
them, you might as well use them.

Am I missing something about the need for Convertors in templates? 
Sorry for rambling on tangentially.




Glen Ezkovich
HardBop Consulting
glen at hard-bop.com
http://www.hard-bop.com



A Proverb for Paranoids:
"If they can get you asking the wrong questions, they don't have to 
worry about answers."
- Thomas Pynchon Gravity's Rainbow


Mime
View raw message