Field Elements should accept "id" parameter, overrides to tpls

[GoogleCodeExporter]

Normally, field elements are instantiated based on their "name", and the "name" 
is considered more or less synonymous with the field's id.

With the introduction of the RelationMeta field, however, it became clear that 
this doesn't work... first problem was that the name could contain square 
brackets, e.g.

name="myfield[123][otherfield]"

So the cheeky solution was to put this into the field classes:

$this->id      = str_replace(array('[',']',' '), '_', $this->name);

However, that's not good enough when you need to customize the tpls used by the 
sub-fields in a RelationMeta because you can't predict what the field name will 
be and therefore you can't put in a custom tpl for it.  E.g. the field name 
might be something like "products[123][shipping]" because it's meta data for 
post 123.  So the name changes based on *each* instance of the field.

Better would be something that would allow the field id to be passed directly 
as a field property (and we can always fall back on a str_replace conversion if 
it's missing).  E.g.

if (!isset($this->id)) {
    $this->id      = str_replace(array('[',']',' '), '_', $this->name);
}

And then we'd have to update all places where $FieldObj->set_props() was used 
to add the extra id if necessary.

AND/OR 

Add functions that would allow for overrides of the various tpls used by the 
Field element.  E.g.

function set_tpl($name, $tpl) {

}

Could be used to populate a hash of all the tpls the field needs (most commonly 
element, option, wrapper).  That way the RelationMeta field could even specify 
a suffix for its field names, e.g. text_meta.tpl or some such, and we can still 
have the hierarchy, but it could be accessed from outside the object, e.g.

$fieldtpl = CCTM::load_tpl(
    array('fields/elements/'.$name.'.tpl'
        , 'fields/elements/_'.$type.'.tpl'
        , 'fields/elements/_default.tpl'
    )
);

$FieldObj->set_tpl('element', $fieldtpl);

Original issue reported on code.google.com by ever...@fireproofsocks.com on 16 May 2013 at 5:48

[GoogleCodeExporter]

Original comment by ever...@fireproofsocks.com on 11 May 2015 at 4:53

• Changed state: WontFix