Mixing conventions + config

[robashton]

In most libraries where conventions are used, they're used as a default, on which further config can be placed.

Either I'm missing something or this is not the case in Plates, which is mildly annoying because it means for cases like

var model = {} // Some really cool model
var map = Plates.Map()
                       .where('rel').is('self').use('id').as('href')
var html = Plates.bind(template, model, map)

Will result in only the rel being mapped

Where as with the code previously

var model = {} // Some really cool model
var html = Plates.bind(template, model)

This worked fine and all the data got mapped by class beautifully.

I'm happy to make this change if it is agreed with.

[pksunkara]

You need to ask @hij1nx

[robashton]

Hey @hij1nx pretty please can I make this so?

[heapwolf]

sorry, can you rephrase the problem, im not sure i completely understand.

[robashton]

Sure thing,

Basically, the current situation as I see it

Plates.bind(html, model)

Results in HTML which has been bound via convention, as it guesses where to place data based on class/id

The algorithm for this looks something like this

for(var key in data) {
   var destination = findDestinationByConventionForKey(key)
   destination.text(data[key])
}

Plates.bind(html, model, map)

Results in HTML which has been bound via explicit configuration, as it uses the map to work out where to place data

The algorithm for this looks something like this

for(var key in map) {
  var destination = findDestinationFromMapByKey(key)
  destination.text(data[key])
}

• I would like it to be *

Plates.bind(html, model, map)

Results in HTML that has been bound via explicit configuration where available, and convention where not

Algorithm for this looks something like

for(var key in data) {
  var destination = findDestinationFromMapForKey(key) || findDestinationByConventionForKey(key)
  destination.text(data[key])
 }

I actually made the assumption that this was how it worked, as it seems logical (and indeed the documentation for Weld - the project that came before this one seems to suggest that's how it worked)

I could really do with this behaviour as I'm leaning towards using conventions for pretty much everything in this app, and treating the map as just another pile of custom conventions.

[robashton]

Hey, any word on this? It's something we're working around for the moment with a file of bindings - it's not something we'd like to be doing long term.

If we don't get word of whether the official project is going to take this behavior we'll go ahead and fork and it anyway :-)

[heapwolf]

Ok, so from what I have gathered, you would prefer the bind method to explicitly require the map object?

[robashton]

Hmm - no, I would prefer that if there is a map object present, for it to override the default behavior matching key name to class/id, but if there is no key in that map object then to try and map by class/id.

I'm clearly having a failure to communicate here, are you at nodeconf summercamp in sept? I can show you code then if necessary :-)

[indexzero]

+1 to the request from @robashton. Here's a simple code example:

  var data = { foo: 'foo', 'complex-key-to-remap': 'bar' }

  var html = '<div class='foo'></div><div class="remap"></div>'

  var map = Plates.Map()
    .class('remap').to('complex-key-to-remap');

  console.log(Plates.bind(html, data, map));

This outputs:

  '<div class="foo"></div><div class="remap">bar</div>'

Because passing an explicit map overrides any default mapping. What @robashton would like is that the default convention of mapping to foo remains. i.e. the output is

  '<div class="foo">foo</div><div class="remap">bar</div>'

[gravitezero]

+1

btw, @indexzero, in your example, shouldn't you change in your data name: 'foo' to foo: 'foo' ?
Otherwise, Plates would look for a name id, which doesn't exist.

[gravitezero]

A very quick test seems to indicate that if you remove the else line 252, it's working.

[indexzero]

@gravitezero You're right. Fixed.

[robashton]

Ah cool, this is what we did in our forked copy too so we'll go ahead and throw that away - cheers!

[robashton]

(Although iirc we changed the order because you want the map to override the conventions, not the other way around - I can't check this though as I'm not at the office)

[gravitezero]

Exactly, the overriding part seems to be line 261.

All the If else logic before line 252 only modify attributes & values.
So, you might want to modify attributes and values, and then check on these attributes to fill up with content.

[heapwolf]

ah, this change sounds great, pull request anyone? ;)

[robashton]

The change we made apparently breaks a few tests, I'll need to go through them and make sure it's all sane before sending you anything.

Travelling this weekend, will see what I can do