[Helma-dev] Re: Helma Templating

[Juerg Lehni]

Hello List,

It's about time I comment on the reactions from the last few days.  
I'm mostly offline this week due to my moving to Tokyo for the next 4  
months.

My experiments with different engines and approaches was by no means  
I trial to get rid of the february 2005 proposal or anything the  
like. I actually wasn't really aware of it properly until I read it  
completely this weekend. I just was in the need for more flexibility  
than Helma currently offers, and started to look around. I'm  
currently very happy with my JS implemenation, which I changed quite  
a bit since I last posted about it. My idea is to put it online on  
dev.helma.org in some days, as a starting point for discussion.

But before that I'd like to clarify a few things here:

- I don't intend to go down the HSP road. This was just the easiest  
starting point for an own engine, to quickly get to something that  
works and start refining it from there. HSP is way to flexible, and  
as stated before, JS is not a suitable language to be used in  
templates, less than for example Ruby, because of the curly braces  
instead of keywords like "elseif", "end", etc. (I'm a fan of the  
curly braces though!).

- I don't think we should get rid of macros. I also think that  
subskins are a very nice idea for teams involving more than one person.

- But we should also help small "ego-driven" projects (a very  
unsuitable name in my eyes) and make rapid prototyping easier. I  
think Helma could get quite some attention in that field.

- I think the XML based notation in the feb 2005 proposal would in  
many situations overcomplicate things. That doesn't mean it's not  
usefull in other situations. I just don't think it's a nice solution  
for every problem.

- Code should not be allowed in templates, but we could think of  
making getters available to the template engine. Here's a little  
idea: each function that starts with get (e.g. object.getSomething())  
could be called from the template engine like this: this.something.  
So if for example Chris Langreiter would like to make the object  
hierarchy accessible from the skins, he could define getParent(),  
getPrevious(), getNext(), and use it from the skin through  
object.parent.next, etc.

- I think basic conditional statements and loops should be added to  
skins. They could be turned off by default, people could still work  
in the old way by just using static skins and macros. But having the  
possibilitiy built in is a plus for small projects and one man shows.  
Here's a proposal:

   - <% foreach (object in list) %> ... <% end %> : loops over the  
list, on purpose not named "for (object in list)", because object  
won't be the index but the object itself
   - <% if () %>, <% elseif () %>, <% end %>
   - <% set variable = otherVariable [ + some arithmetic ] %>, e.g. < 
% set count = this.nodes.count %> : count could be a default getter  
for the count() function, as described above. href could be another  
default getter.

These five additional tags would offer more than enough (maybe too  
much) flexibility, and they would go nicely with what we have.

As an anticipation of possible negative reactions to this proposal,  
I'd like to comment on two things:

- Peusdo syntax: The proposed syntax is pretty close to JS, so it  
would feel natural to be using it, but different enough to not cause  
confusion and clearly seperate it from proper code in Helma. Curly  
braces won't work.

- Mixing code and representation. I think basic appearance related  
flow control like this bellows much more to the view than the model /  
code. Forcing to take it out of the skin and having to name subskins  
in order to be able to programmatically use it from the outside is an  
overkill in complexity in many situations. I admit that there are  
many other situations where it's the better road to take, but why not  
giving the user / team the choice instead of forcing one way of  
thinking? I am sure that Helma would profit from this.

Jürg

Am 05.12.2005 um 11:51 schrieb <tobias.schaefer at orf.at>  
<tobias.schaefer at orf.at>:

> hi there
>
> i think i would not be able to improve andreas bolka's statement  
> against all the latest efforts of stepping back (or away) from  
> current helma templating practices.
>
> and i fully support his suggestion to start off with the "february  
> 2005" proposal.
>
> to me the proposed alternative template engines, as excellent an  
> art they might represent, appear to be too "ego-driven", ie. there  
> is only one guy who can handle the resulting code structures -- and  
> that's the one who wrote it. (feel free to correct me here.)
>
> if another template engine should prove anything at all it's that a  
> team of users can easily collaborate with it. that's the case with  
> the current skin&macro implementation of helma. and that's the  
> minimum helma 2.0 should achieve, too.
>
> i know that there is substantially more to do writing macros and  
> skins. but that's actually a smaller amount of work than the one  
> you have to do cleaning up the mess of your colleague's rabid  
> prototyped hsp code.
>
> ciao,
> tobi
>
>
> Andreas Bolka wrote:
>> Friday, December 2, 2005, 1:27:36 AM, Juerg wrote:
>>
>>> I don't think that if I write a table that repeats its rows as many
>>> times as there are elements in a list, it is easier and cleaner to
>>> write one main skin for the table, one for the row per element, and
>>> one macro that takes the list, iterates through the elements and
>>> renders the row skin for each element.
>>
>> The "February 2005" proposal would (at least as I understood it)
>> allow you to combine all those skins into one bigger skin. The
>> iteration logic would stay cleanly seperated in a macro.
>>
>>> I'd like to bring in Rails as an example here once more. The Erb
>>> library (Embedded Ruby: http://raa.ruby-lang.org/project/erb/ ) used
>>> there allows pretty much the same as my current JS template
>>> implementation. And still noone is complaining
>>
>> Well, ERB is just PHP (or ASP or whatever) gone Ruby. With the same
>> advantages and disadvantages. So if "no one complains" (what I doubt)
>> that would be only because there is nothing new to complain about.
>> It's the same mess as before (only with a language that is generally
>> deemed to be sexier).
>>
>> And personally, that's *exactly* the road I don't want to go down (it
>> seems Helma still allows to walk those paths with .hsp; my best
>> wishes for those who want to do so).
>
>
> _______________________________________________
> Helma-dev mailing list
> Helma-dev at helma.org
> http://helma.org/mailman/listinfo/helma-dev