[Helma-dev] JavaScript Templating Engine

[Hannes Wallnoefer]

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
>