Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.It looks like this module is going to have to start policing it's XML 'correctness' soon, especially if other people are expecting to be able to hand-write patterns that are hosted on a URL for anyone to use.
To move this project closer to an XML validation scheme, how 'bout a DTD at the top of each pattern which calls a global Doctype file containing the definitions of all possible child elements?
This patch creates the DTD, and it references a yet-to-be-created file inside of patterns/patterns/patterns_dtd.xml which would list all the elements such as:
<!ELEMENT pattern (info,modules,actions)>
<!ELEMENT info (#PCDATA)>
<!ELEMENT modules (#PCDATA)>
<!ELEMENT actions (#PCDATA)>
| Comment | File | Size | Author |
|---|---|---|---|
| patterns_add_global_doctype.patch | 503 bytes | Senpai |
Comments
Comment #1
Senpai CreditAttribution: Senpai commentedwoops.
Comment #2
vaish CreditAttribution: vaish commentedThis is very valid and important point but it may not work very well for actions section of XML file. There, we want to allow user to enter new and undefined tags but according to my understanding DTD is forcing you to exactly define all the child elements for each and every XML element.
Example would be contrib module (e.g. location) form-altering content type settings form and adding it's own section. If we want users to be able to configure those settings we cannot limit allowed XML elements for "content" to the list of known and predefined core settings. Another relevant example would be numerous CCK fields with all their settings.
I believe that XML schema could solve the above problem but we would still not be able to limit allowed tags inside actions section (which is the biggest and most error prone part of the patterns file) without sacrificing flexibility and power of patterns module.
Btw, your description above seems to be incomplete. I believe something is missing at the end, so I'm not sure if I' missed any important point.
Comment #3
vaish CreditAttribution: vaish commentedForgot to mention that we are actually not considering hand-writing the patterns as ideal way of creating patterns. It's the only way at the moment, but we are planning to change that soon by implementing one or more alternative methods of patterns generation. Some of the options considered are recording the form submission, generating patterns from existing site configuration and patterns editor (GUI).
Comment #4
Senpai CreditAttribution: Senpai commentedOk, I see your point about the need to have the actions section free-form so that modules can configure things, CCK can configure it's fields & widgets, etc. Getting certain parts of a pattern to remain valid while others do not is going to be an exercise in futility.
At the very least, however, the module could verify that certain XML tags are present for the three main sections (I know it does that in the code already) and that those three sections have at least a certain subset of 'approved' tags, then a pattern could more accurately be deemed "correct". If cck can't handle error checking right now because of the supreme weight of all the possible tags, then how about at least putting the structure in place for the info and modules section?
That question makes me wonder if <actions> isn't trying to handle too much? If the sub-tags of the action section cannot be described because there's simply too many possibilities, how are people ever going to grok the tags scheme in order to write or modify their own? It's like having an API with n+1 public functions that are all treated like private functions by the contrib developers. Every time you come back to a pattern, something might have changed under the surface. Or not. Perhaps Patterns needs to break things down into something a little more granular when it comes to the Actions section.
We know that things like <roles> and <permissions> are not likely to change their methods next week when a new point release comes out (I'm thinking contrib releases here). Same goes for variable_set(). But there are other things like CCK or Views that might change. Validating a pattern for XML correctness according to the entire Actions section is going to fail simply because there are too many vulnerabilities.
It's something that needs to be addressed, explored, talked through, and fixed, but probably not until a post 1.0 release. Setting to 'postponed'.
[Oh, and I had forgotten to use <code> tags around the last part of my original post. It's fixed now. And I also noted the plans for auto-pattern-generation in our Unfuddle Notebooks. Cool stuff, to be sure.]
Comment #5
moshe weitzman CreditAttribution: moshe weitzman commentedI would like a schema that does not flag unknown fields but does help complete new ones. Essentially, I want autocomplete while entering in patterns. I think whats needed is an XML Schema. See http://www.w3schools.com/schema/schema_why.asp
Comment #6
sarvab CreditAttribution: sarvab commentedI like the idea of using an XML schema from there. If the schema is always beening generated on the fly by drupal, it could be possible to create an absolute full schema of everything possible by looping through all the pattern supported form ids and generating default forms/schemas based on the fapi array. The main issue I can see there would be say forms like adding a node. The add node form is dependant on a node type parameter that is passed to the form. That could be solved by having those particular components provide a schema for every form-parameter combination, but that could be a bit overboard.
The other thing is that the configuration framework that should take-over the core functionality is more suited to creating a schema like this since each module component is already describing the incoming data in a more structured way. Currently the data sent to a drupal form handler is not always necessarily from the level immediately following an action tag in the xml and there is no good way of figuring out where in the xml doc that data is set at without basically duplicating what the configuration framework is doing. Considering that it may make the most sense to concentrate on finishing and stabalizing that so it can replace the core of patterns and then get this functionality in there.