Conditionals?

[Steve Purchase]

I'm enjoying pure so far. I find it a great way to totally separate visual design and code, however there are a few niggling issues that cause this separation to fail.

The biggest issue for me is the lack of conditionals - there's no way to conditionally remove a DOM element (that I can find). I realise I could probably manage the same thing with "display: none" but this less than ideal in a mobile context and something I'm trying to avoid.

Something like the following would be beneficial to me, in this case using a question mark to denote inclusion of the element (and its children) only if the given value is true.

{

  "table?": function(a) { return a.context.mydata.length > 0; },

  "tr": {

    "row<-mydata": { ... }

  },

  ".nodata?": function(a) { return a.context.mydata.length == 0; },

}

This also raises the question of whether a similar functionality should be enabled for iterated elements within a list - a filter, in effect. I don't really have enough experience with pure to suggest a suitable syntax/method here but it should probably be considered for consistency if conditionals are desired at all.

[Steve Purchase]

On Monday, 19 March 2012 14:19:39 UTC, Steve Purchase wrote:

This also raises the question of whether a similar functionality should be enabled for iterated elements within a list - a filter, in effect. I don't really have enough experience with pure to suggest a suitable syntax/method here but it should probably be considered for consistency if conditionals are desired at all.

I've just RT(rest of the)FM so now I know filtering is already available :)  Nothing to see here, move alone.

The question on conditionally removing element still stands.

[Mic (BeeBole)]

I did use the same notation when I made test for node conditionals.

But since it was making the code much more complex, I settled on style="display:none".

I don't think it impact browser paint speed, even on mobiles as the display:none nodes are skipped.

And since the template is already loaded on the client, there is no bandwidth to save.

May be the notation, could be used to put a display:none more conveniently than:

'table@style': function(a) { return a.context.mydata.length > 0 ? '':'display:none'; }

But special notations make a templating sub-language, and I try to avoid them to stick to only HTML+JS+CSS (@, +, . are already exceptions I had to use)

[Steve Purchase]

You're right - it doesn't impact paint speed. However in my case I have quite a lot of instances of a number of templates, all within the one DOM (webapp style). It isn't the paint speed I'm worried about but simply the size of the DOM and the downsides that brings - memory consumption and manipulation speed, both more significant in the mobile space.

I'm sure I can solve my issues by changing how I do things within my app, but this does feel like a feature that should be part of pure. Not only does it save DOM space but it also saves template rendering time. It is also possibly a huge boon to users in terms of handling optional sections of a template.

[Mic (BeeBole)]

Do you hit a performance problem the way your app is designed?
Our webapp is quite heavy, and I'm not experiencing any slow rendering
or memory problems, even on mobiles.

[Steven Purchase]

Not specifically, but I'm trying to target as large a range of phones as possible (especially given the slightly higher average age of the users). As this is a hobby project I certainly don't have access to a good range of testing devices, so I would like to simply cut the fat off :)

--
You received this message because you are subscribed to the Google Groups "JavaScript Templates Engine PURE" group.

To post to this group, send email to Pure-Unobtrusive...@googlegroups.com.
To unsubscribe from this group, send email to Pure-Unobtrusive-Rende...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/Pure-Unobtrusive-Rendering-Engine?hl=en.

--
Steve