Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.Hello!
Right, I was checking the code today to get my head around it. Hopefully won't take me long until I get the logic behind it.
In the process I did notice that code documentation is needed. It was hard to see how the system was built when I couldn't really understand what each function was doing.
I haven't committed anything yet. I don't wan't to hijack your module. I'm attaching a patch with a start. I I think improving it is really important. As modules grow, more people get involved and good documentation is the key to others being able to collaborate, even if they are not committers. This is specially TRUE for an API that is to be used by others.
Also, I recently started keeping a CHANGELOG for my projects. It really helps keep track of what is going on, and when there is more than 1 person working on the same project, is the perfect place to see what others have done.
Attaching both
Cheers
| Comment | File | Size | Author |
|---|---|---|---|
| #1 | driven-6.x-1.x-dev-960890_1.patch | 8 KB | jm.federico |
| #1 | CHANGELOG.txt | 287 bytes | jm.federico |
Comments
Comment #1
jm.federico commentedComment #2
arhak commentedcdriven takes care of merging a node_form and a comment_form and process them both at once, every other logic beyond that should be delegated to Driven API
the answer for this question is very close to the rationale for the existence of a Driven API
modules exploit the Form API (FAPI) with several different approaches, the principles in FAPI enforce uniformity among them, but at the end, each module decides when and how to react to form elements
a single piece of data might be represented by a single FAPI element, but usually, advanced controls require more complex logic (compound widgets) and each widget knows how to handle/interpret its data
Driven API adds meta data to each type of field (whether it comes from node module in core, taxonomy, workflow, CCK) facilitating their introspection, nevertheless, it might be not enough to know how to interpret their data representation for comparison, or their parent-child structure for access control, and that is what Driven API sub-modules take care of
beyond that, Driven API goes a little farther and also provides helper functions and hooks to easily implement backend pages, grouping all the related modules under the same administration section, which only requires little chunks of code (and, of course, it is not mandatory)
it is just that, a hook gatherer (with its static cache), which also does the default initialization for omitted values (as usual)
available properties must be retrieved through this mechanism (it is mandatory) since other (optional) modules rely on this premise to provide further support (e.g: function driven_props_get_properties at driven_props module)
besides, this is the only way to properly initialize omitted values