recursion example
rog
i've been trying to understand how the various examples
are working, and i am a bit puzzled by the recursion example.
the class name of the <li> node is "children", but i cannot
see any selectors referencing the children class, and we're
not autorendering, so i cannot see how it's working!
also, i tried using this example in a slightly different way, as
suggested by the iteration example:
$p.compile($('ul.treeItem').mapDirective(directive), 'tree');
$('ul.treeItem').html($p.render('tree', context));
this gives a javascript error: "arg.item not defined."
as far as i can see, this *should* work.
cheers,
rog.
Mic Cvilic
The error comes probably as you try to get arg.item while no loop is
open.
Here below is the same example, without auto-rendering. All directives
are set manually.
To see the code running, place it in the body of a page with pure.js
and jquery.js available.
<ul class="treeItem">
<li class="children"><a class="name" href="#">name</a></li>
</ul>
<script>
var context = {
children: [{
name:'Europe',
children:[{
name:'Belgium',
children:[{
name:'Brussels'},{
name:'Namur'},{
name:'Antwerpen'}]},{
name:'Germany'},{
name:'UK'}
]},{
name:'America',
children:[{
name:'US',
children:[{
name:'Alabama'},{
name:'Georgia'}
]},{
name:'Canada'},{
name:'Argentina'}]},{
name:'Asia'},{
name:'Africa'},{
name:'Antartica'}]};
var directive = {
'li':'child <- children', //loop on each children
'a':'child.name',
'li+':function(arg){
if(arg.item.children){ //if children, recurse
return $p.compiledFunctions.tree.compiled(arg.item);}}};
$('ul.treeItem').compile('tree', directive /* no more context,
autoRender off*/);
$('ul.treeItem').render(context, 'tree');
</script>
Thanks for your updates in the wiki !
Feel free to improve any parts if necessary 8)
Cheers,
Mic
roger peppe
> The error comes probably as you try to get arg.item while no loop is
> open.
i realised that, but i took the example directly from the wiki,
and that example works.
i'm just interested to know why/how it works, because
i cannot see any loop in the example, and it does not
appear to be using auto-rendering (but is there some
hidden trick that means it *is* using auto-rendering anyway?)
cheers,
rog.
Tchvil
rendering turns on.
$( htmlTemplate ).compile(templateName, directive, data)
roger peppe
> When you give data to the compile method(last parameter), the auto-
> rendering turns on.
> $( htmlTemplate ).compile(templateName, directive, data)
ok.
then i guess the following should work, still following the
iteration example, which calls $p.render with the name
of the compiled function and the context:
$('u.treeItem').compile('tree', directive, context);
$('ul.treeItem').html($p.render('tree', context));
however, this gives me a different error: 'html is undefined'.
i think that some entity types are getting confused somewhere.
i'm certainly confused!
cheers,
rog.
Tchvil
Did you try it? May be a browser issue, I've tested it only in FF3
cheers,
roger peppe
> The code I posted above is a working example without auto-rendering.
> Did you try it? May be a browser issue, I've tested it only in FF3
i've been testing in firefox 3, so i'm sure your example works.
i suppose that what i'm trying to get at is that the way that
compile and render works is only shakily defined;
there is nothing in the way of reference documentation
that expains how they actually work in general, rather than just giving
an example.
in the absence of documentation, all i can do is try to infer the
general rules from the provided examples - hence i was trying
to apply a technique from the iteration example to a different
example. it didn't work, and i think that's a bug.
i like the concept of pure, which is why i'm spending some time
with it, but despite the name, i think that it could have a cleaner
interface.
cheers,
rog.
Mic Cvilic
> general rules from the provided examples - hence i was trying
> to apply a technique from the iteration example to a different
> example. it didn't work, and i think that's a bug.
web app, so
any bug found is one bad surprise avoided.
Send me an example such as mine (html + directive + data), with what
you try to build. I'll check it out.
Improving the documentation is on my todo list, but to be honnest in
the bottom of the pile...
> i like the concept of pure, which is why i'm spending some time
> with it, but despite the name, i think that it could have a cleaner
> interface.
release.Hopefully with a better interface. Good shot for the name ;)
So far, only the 3 first examples work in allExamples.html, and with
sizzle only.
To get news when code updates occurs, you can follow the project on
github.
Feel free to suggest improvements on the interface, especially the new
one.
If you have any dreamy way of calling these methods, there is a fair
amount of chance you'll get it.
>
>
> cheers,
> rog.
>
> >
roger peppe
> I'm more than interested in bugs. PURE is the rendering base of our
> web app, so
> any bug found is one bad surprise avoided.
most of the "bugs" i've found so far have been mismatches
between documentation and reality (e.g. the "functions as
directives" page says that an anonymous function takes three
arguments, whereas it actual takes a single object argument)
having inspected the source code, however, i'm a bit worried
by the whole class of potential bugs opened up by the
method that PURE uses to do its templating.
for instance, if you some literal text in your template
with a link to your website, e.g. (http://mywebsite.com/)
then the site name will be deleted. Similarly, any
text containing "pure_" or "pure:" will be corrupted.
the other domCleaningRules have similar potential for bugs.
i can see that using innerHTML like you do is likely
to be fast, but... it has disadvantages too.
> Improving the documentation is on my todo list, but to be honnest in
> the bottom of the pile...
i often find that writing a concise but complete description of a
software interface is a good way to iron out conceptual
bugs and make a generally nicer API, but YMMV.
> Feel free to suggest improvements on the interface, especially the new
> one.
> If you have any dreamy way of calling these methods, there is a fair
> amount of chance you'll get it.
ok, you asked for it!
coming from a static typing background, i like to analyse things in terms
of types. i think you've got approximately 4 fundamental types used by
your interface:
Directive - map CSS selectors to JSON selectors.
DOM - html object tree.
DOMtemplate - html object tree containing JSON selectors in internal form.
JSON - attribute-value store.
if this were a functional programming language, you might characterise
the functions of the current API as follows:
render :: DOM -> Directive -> JSON -> string
render :: DOMtemplate -> JSON -> string
autorender :: DOM -> JSON -> string
compile :: DOM -> Directive -> (JSON -> string)
compile :: DOMtemplate -> (JSON -> string)
mapdirective :: DOM -> Directive -> DOMtemplate
note that from a functional programming perspective, the
type-signatures of compile and render are identical,
(and in fact the current render function does go through a compile
step before performing its rendering). thus we
can subsume the render function into the compile function
(or vice versa).
also, the compilation process actually produces a DOMtemplate
behind the scenes.
so we can simplfy the interface to the following functions:
mktemplate :: DOM -> Directive -> DOMtemplate
mkautotemplate :: DOM -> DOMtemplate
compile :: DOMtemplate -> (JSON -> string)
now, the only reason for exposing DOMtemplate to the world,
it seems to me, is so that you can use it as a DOM template
itself to do nested loops, as in the iteration example.
i would contend that this usage is dubious, as it's very
easy to produce a broken template, for example by
not strictly nesting the loop within the element selected by
the previous loop (see attached file for an example of this).
we still need to be able to do nested loops, however,
so i'd propose extending the directives syntax to allow that.
e.g. the iteration example might be expressed like this:
directive = {
'table.scoreBoard tbody tr': {
'team <- teams': {
'td.teamName' : 'team.name',
'table.teamList tbody tr': {
'player <- team.players': {
'td.player': '#{player.first}
(#{player.last})',
'td.score+': '#{player.score}',
'td.position+':
function(arg){return arg.pos + 1},
'tr[class]+':
function(arg){
return
(arg.player.pos % 2 == 1) ? 'odd' : 'even'
}
}
}
}
}
}
once this is allowed, the need for DOMtemplate goes away, as far as
i can see, so the interface can be simplified even further, while losing
none of its original power.
render :: DOM -> Maybe Directive -> JSON -> String
in javascript terms, that would look like this:
$(target).render(directive or 'auto', data or null)
if the data argument is not given, then this function would return
a compiled javascript function that will render the template on
demand (kind-of currying); otherwise it would return the
html text, as before.
that's all the interface you need, as far as i can see...
easy to document, easy to use, and you can't make
broken templates with it.
is that dreamy enough for you? :-)
cheers,
rog.
Mic Cvilic
> between documentation and reality (e.g. the "functions as
> directives" page says that an anonymous function takes three
> arguments, whereas it actual takes a single object argument)
Ok, I just corrected it, so you are the last one to suffer it...
> having inspected the source code, however, i'm a bit worried
> by the whole class of potential bugs opened up by the
> method that PURE uses to do its templating.
>
> for instance, if you some literal text in your template
> with a link to your website, e.g. (http://mywebsite.com/)
> then the site name will be deleted.
> Similarly, any
> text containing "pure_" or "pure:" will be corrupted.
> the other domCleaningRules have similar potential for bugs.
The DOM cleaning rules came from the today's browser reality.
Especially IE.
The regexp came one bug at a time discovered by the people using it.
Not sure we can avoid that. May be a different approach is possible?
To try escaping the issue, I'm not sure either that hardcoding
external urls in a template is good thing ;)
> i can see that using innerHTML like you do is likely
> to be fast, but... it has disadvantages too.
I know... coming from years of XML/XSLT, I was dreaming about a full
tree(html + JSON) approach.
The first version was DOM based, but a disaster to build a fast and
serious cross browser app.
>
>> Improving the documentation is on my todo list, but to be honest in
>> the bottom of the pile...
>
> i often find that writing a concise but complete description of a
> software interface is a good way to iron out conceptual
> bugs and make a generally nicer API, but YMMV.
As you may see by the resulting code, I'm more a trial & error person.
Documentation(if any...) comes usually last for me.
We need both worlds to make good things.
So thank you to open up the discussion. There was a talk few weeks ago
on the forum about a functional spec. So if someone has a template or
an example, feel
free to post it.
We could do that in a collaborative way with whom is interested.
>
>> Feel free to suggest improvements on the interface, especially the
>> new
>> one.
>> If you have any dreamy way of calling these methods, there is a fair
>> amount of chance you'll get it.
>
> ok, you asked for it!
>
> [...]
>
> is that dreamy enough for you? :-)
Wow! I didn't expect this.
I need to digest it for few days now, and will respond in a dedicated
post ... 8)
Thanks a lot.
Mic
roger peppe
> To try escaping the issue, I'm not sure either that hardcoding
> external urls in a template is good thing ;)
they might not really be hardcoded - they might
have been filled in from a server-side template,
leaving the ajax variables to be filled in by the PURE
client-side template code...
at least, that's one plausible scenario.
cheers,
rog.
roger peppe
script that implements the interface i was talking about.
it doesn't do autorender or compilation and it's jQuery specific, but
it demonstrates the
point, i hope.
i've attached it, along with some example code.
cheers,
rog.
2009/3/26 Mic Cvilic <tch...@gmail.com>:
Tchvil
Could you post here the source or send it to me by email.
This looks very interesting. Thank you.
>
> name
>
> some stuff
>
>
>
> mypure.js
> 5KViewDownload