[Helma-dev] JavaScript Templating Engine

[Matthias Platzer]

Hi,

i missed the discussion on friday, but i would be *very* happy if 
skinning in helma would take the next step.


i think the proposal from hannes (feb 05) is a good starting point.

i uploaded an example code file (skin/template) to the wiki:
http://dev.helma.org/static/helma.dev/Wiki/Helma%202%20Templates/Helma.Skin2.xml%20(matthias%20-%204.12.05)

i tried to write a template as i would like to see it as a template 
designer. (i didn't care too much about how to implement this in helma)

the goal was to have a file that can be viewed with a standard browser 
(or IDE, using a browser rendering engine), but still use the clean 
separation introduced with skins 1.0.


matthias


Hannes Wallnoefer schrieb:
> A little help to clear things up here:
> 
> HopObject.__proto__ is the prototype object.
> HopObject._prototype or
> HopObject.__prototype__ is the name of the prototype
> 
> The new proper way to get a helma.framework.core.Prototype object is
> 
> app.getPrototype(prototypeName)
> 
> The problem with implementing Prototype.getResource(resourceName) is
> that a resource with the same name may be defined in several
> repositories. The other problem is that Repository.getResource(name)
> creates and returns a resource even if the underlying file does not
> exist, so you'd have to check that too.
> 
> Regarding the templating discussion, I'd like to take that out ouf the
> mailing list and into the dev.helma.org wiki. But just to let people
> know where I stand on various issues, I think the basic cornerstones
> for Helma 2 skins are these:
> 
> * We need some native if..else/for..in constructs and nested skins in
> order to stop skin proliferation. We rather don't want unprotected JS
> in the templates, though.
> * Implementing skins as JS function is an interesting idea because it
> allows the ultimate integration, and does not at all imply we need to
> use JS syntax for template logic. I see this simply as an alternative,
> interesting implementation approach.
> * I'm rather sceptical about the protected JS context idea. It sure is
> an interesting idea, but I currently don't see through the
> implementation issues to make it both secure and efficient.
> 
> hannes
> 
> 2005/12/2, Juerg Lehni <juerg at scratchdisk.com>:
>> Chris, this still doesn't work for me.
>>
>> It returns the HopObject prototype regardless of what JS prototype I
>> pass to it.
>>
>> Are you sure it actually works for you? Maybe your test case contains
>> skins in HopObject only, so it doesn't make any difference?
>>
>> The only thing that does work up to now is my evil string parsing
>> hack, unfortunately...
>>
>> I think accessing resources from the scripting environment should be
>> made easier. There are other situations where this makes sense, e.g.
>> keeping a text file with messages related to the prototype, for
>> printing out to the user, etc.
>>
>> I would like to propose to add this function to HopObject,
>> implemented in Java:
>>
>> HopObject.prototype.getResource(name)
>>
>> It would avoid these hacks, we wouldn't need to access the prototype
>> through app and to walk the resource lists...
>>
>> What do you think, Hannes?
>>
>> Jürg
>>
>> Am 02.12.2005 um 01:26 schrieb Chris Zumbrunn:
>>
>>> On Dec 2, 2005, at 1:06 AM, Juerg Lehni wrote:
>>>
>>>> But did your code actually work? app.getProrotype() needs to
>>>> recieve the prototype name as a string. this.__proto__ returns the
>>>> prototype object, and I haven't found a more elegant way to find
>>>> it's name than removing "[object " and "]" from it:
>>> Yes, I was tracing that down, too. The code I had at the end
>>> worked, because I ended up using app.__app__.getPrototype() instead
>>> of app.__app__.getPrototypeByName()
>>>
>>> That still works in your new version as well:
>>>
>>> var resources = app.__app__.getPrototype(prototype).getResources();
>>>
>>> ...instead of...
>>>
>>> var resources = app.getPrototype(prototype.toString().match(/\
>>> [object (.*)\]/)[1]).getResources();
>>>
>>> That means the __app__ has to stay, but it's the lesser evil.
>>>
>>> Chris
>>>
>>> _______________________________________________
>>> Helma-dev mailing list
>>> Helma-dev at helma.org
>>> http://helma.org/mailman/listinfo/helma-dev
>> _______________________________________________
>> Helma-dev mailing list
>> Helma-dev at helma.org
>> http://helma.org/mailman/listinfo/helma-dev
>>
> _______________________________________________
> Helma-dev mailing list
> Helma-dev at helma.org
> http://helma.org/mailman/listinfo/helma-dev
>