Token replacement and parameters for sub-patterns
michaek - February 20, 2009 - 17:39
Description
I imagine it may be useful to supply tokens in xml files, and parameters for replacement when including sub-patterns. (I was thinking of this related to #375306: Add fields or groups to multiple content types)
The template might look something like this (within, for example, node.xml),
<content>
<name>{name}</name>
<type>{type}</type>
...
</content>While the declaration in the including pattern something like this:
<pattern name="node">
<parameters>
<name>Human Readable Content Type</name>
<type>drupal_content_type</type>
</parameters>
</pattern>Does this sound useful?
#1
I created a proof of concept for this, though I haven't subjected it to serious testing yet. It does work in the simple cases that I tested for. I'm attaching a diff, despite the fact that it's very rough, still.
At the moment, this relies on the Token module for replacement. The replacement is simple enough that such a dependency shouldn't be necessary.
#2
Hello michaek,
I like you're idea a lot and we'd love to pursue it. The patch also looks like an appropriate place to implement such functionality.
We all kind of have our hands tied at the moment to take and work the patch in (on the other hand it may be a good breather sooner then expected!), so until we're freed up a bit feel free to keep using it if its working for you and definitely post any updated fixes :)
Thanks!
#3
Nice patch michaek! Thanks for sharing it early on, it's a great addition to the module. I'll do some testing on this in the next day or so.
#4
Thanks, folks! It does seem to work, after some more rigorous testing. However, it doesn't manipulate the keys. This is a bit of a problem in the case of taxonomy:
- tag: vocabularyname: '[name] Types'
nodes:
'[type]': '[type]'
Obviously, '[type]': '[type]' is not valid YAML, but it's an illustration of the fact that we sometimes need to be able to set a key dynamically. One possibility would be to use delimiters that are legal in YAML, and do our replacement on keys as well as values. Does that seem acceptable? It doesn't smell right to me...
#5
I've just been working on a related issue for the whole '[type]' => '[type]' thing which really should not be required in the xml/yaml. What I came up with was to peek at the actual fapi form object before running drupal_execute and make it a bit smarter about dealing with those checkboxes/selects/radios that become 'value' => 'value' in the final submit.
Having that in place will hopefully remove any (99%) need for dynamic keys like that, but its not quite ready yet. It is nothing to do with replacements, so we probably still need a solution for that, but it should be less significant if its not "perfect" :)
So for the time being, all I can think of would be to use a key-only prefix/suffix... we are using '__type__' syntax for identifier replacement with keys, but I'm not sure if thats valid in YAML although it is in XML. So something like that would certainly be acceptable.
#6
Thanks for the response! The fapi solution is what seemed right to me, but I wasn't sure whether the implementation was standard enough to reinterpret the forms. I'm glad to hear it is. :) I was thinking of __type__ syntax as well. It does appear to be legal, and it works appropriately to manipulate keys. Using underscores as the delimiter character also removes the need to use quotation marks on values, as the underscore is not a special character in YAML:
- tag: vocabularyname: __name__ Types
nodes:
__type__: 1
(I've attached a new diff to be applied after the above diff.)
#7
I should add that the protection against recursion disables using the same template more than once (which is pretty much the point of this alteration!). I've commented out the following line in patterns.module:
if (in_array($pattern->pid, $pids)) return array();That's not a good solution, so it's not included in the diffs!
#8
I'm providing a new diff that works with the current dev version (and rolls up all the changes discussed above).