AW: [Helma-dev] Re: Helma Templating

manfred.andres at orf.at manfred.andres at orf.at
Fri Dec 2 12:09:33 CET 2005


Hi.

I totally agree, that the work of Juerg is brilliant on these templating-engines, but my personal experience with systems mixing code with layout like ASP, Tango Enterprise, .hsp, php, perl and so on (it makes me shiver (in a very negative way) to think back into these days), gives me the strong feeling, that these ways of doing web-applications is no good for none-prototyping projects.

If one would like to write an application, which will be used over a long period of time and of course will have to change over time (which is the case for most app's on the web because there are evolving new ways of doing things all the time (html 1,2,3,4, xml, xhtml, ...) or just the ideas of how user interfaces should be designed evolves), it would be a pain to change such tings. It causes me headaches while think of old applications, which aren't changed because they are not readable or are changed but are rendered to be buggy just because one if-statement has been overseen.

I do not say, that FreeMarker/Velocity are totally wrong approaches, I just want to say, that they are totally different solutions for totally different scenarios. Prototyping would be faster with FreeMarker/Velocity, but I don't think, that prototyping would/should be the main-scenario for something as powerful as helma.

If these templating-engines are an alternative way (and are plugged in as an extension or just don't cast a performance penalty on the whole helma-server in any way), I would be fine with it. The preferred templating-engine should stay like it is by now. Maybe some tweaking here and there (like inline-skins for looping over object-collections) or maybe a standard macro for calling skins inside skins, but nothing that would entice a developer to produce things like If (a)
   <htmlcode a>
Else if (b)
   <htmlcode b>
Else
   <htmlcode c>

These decisions would make the code unreadable and every enhancement/bug fix would drain more energy/time than needed. The increase of time and energy spent on such tasks would even be the case if the code is the cleanest code ever, just because one would have to read the html more carefully to make sure that no if-statement or logical construct will be overseen.

It should be the decision of the developer depending on his/here own experience and the type of project he/she wants to develop with helma.

With friendly regards

Manfred

P.s.: Another thing would be, that people, which run into the wall with such a templating-system, would shiver by the thought of doing stuff with helma like I shiver while thinking of ASP...


-----Ursprüngliche Nachricht-----
Von: helma-dev-bounces at helma.org [mailto:helma-dev-bounces at helma.org] Im Auftrag von Andreas Bolka
Gesendet: Donnerstag, 01. Dezember 2005 22:28
An: Juerg Lehni
Betreff: [Helma-dev] Re: Helma Templating



As Juerg's brilliant work on integrating FreeMarker/Velocity stirred a lot of interest, I want to express a few personal thoughts, basically I only expand on Hannes mention of .hsp's: "it's a good thing we went over that".

I always enjoyed (non-hsp-)Helma's extremely strict separation between code and presentation -- when you want to write code, you have to write a macro. There is no second programming language [1] that can be used in skins. Calls to macros are the only way to go. Fullstop. [read on after Juerg's example]

Wednesday, November 30, 2005, 1:28:08 AM, Juerg wrote:

> How would I for example write the following FreeMarker example in
> Helma 2.0:

> <table>
>         <#list param.topics as topic>
>         <tr class="topic">
>                 <td>
>                 <#assign count = topic.comments.count() - 1>
>                 <#if count != 0>
>                         <#if count = 1>
>                                 1 Comment
>                         <#else>
>                                 ${ count } Comments
>                         </#if>
>                 </#if>
>                 </td>
>         </tr>
>         </#list>
> </table>

And my dislike for constructs such as this FreeMarker template is exactly why I like Helma's strict seperation that much. In Helma-land: No second language, no ugly clutter of templates with what is definitely logic/code. Presentation code stays in macros. I don't have to decide if I should write an <#if></#if> or an if{}. And I therefore can't make a "wrong" decision (i.e. violating aesthetics or coding standards).

Now we all know that Helma's strict seperation results in a proliferation of (often very small) .skin files. In the example above we would maybe have 'noComments', 'oneComment' and 'manyComments' skins. That this proliferation becomes cumbersome quickly, is obvious (if not, just imagine you want to change the spelling of "Comments" from uppercase to lowercase). So what's needed in my eyes, is something to help in situations with such micro-/sub-skins.

That's why I liked the outcomes of February's discussion on "internationalization" a lot, especially the scheme Hannes hinted at in http://helma.org/pipermail/helma-dev/2005-February/001696.html
(bottom half). Matthias wrote later in this thread: "i'm excited :)" - so was I. And I still think, that exploring this direction further would be very exciting and valuable. I think I'd like this a lot more than all this PHP-ish code/template messup.





[1]: I state "no second language" as a fact, even though I don't deny that considerations of when a set of macros becomes a programming language on it's own have their (philosophical) value. Also note that FreeMarker's templating language is Turing-complete.

-- 
Best regards,
 Andreas                            mailto:andreas.bolka at gmx.net


_______________________________________________
Helma-dev mailing list
Helma-dev at helma.org
http://helma.org/mailman/listinfo/helma-dev


More information about the Helma-dev mailing list