Adding custom XML tags to schema?

Sorry if I’ve asked very similar things over the past couple days, but is there a way to read any custom tags from the xPDO XML schema? Let’s say I develop a plugin or a Snippet that uses xPDO, and I want to store data related to the model. The logical place for this would be alongside the existing model descriptors inside the XML file.

Does the API allow for an easy way to get XML components out of the XML file? Or is it going to come down to old-school XML parsing to get the nodes I want?

Thanks for any pointers.

The schema is generated into the map files. Custom attributes should come through in the arrays it creates in there. Custom elements will be ignored.

I don’t really follow what you mean by "I want to store data related to the model." Can you be more specific so I’m clear on what you want to do.

Thanks for the response. In particular, I was thinking about form generation. It makes sense to me to be able to add optional attributes to a field’s xml that would specify what type of html form element would be used to generate it (or more likely, an attribute that specified which function in a FormGeneration class would be called in order to generate the necessary form element).

E.g.


I’ve tinkered around with this a lot with a FormGeneration library I’ve written... there are times when I feel this type of stuff should appear only in the view, but there are other times when I feel that the form elements are tightly bound to the field definition (e.g. in the case of an enum). What I would like to avoid is having multiple definitions scattered throughout the site that all apply to the same table/model.

There might be other instances where being able to extend the field’s attributes could be useful to 3rd-party component development.

Hmmm, I still think that kind of stuff belongs separate from the fields of the model; the validation rules in particular would be a better location for form extensions I think. What if you have multiple forms affecting the same data table but with differing rules? Though not common, it is a valid issue, and could possibly be handled better by extending the validation rules. It might take a little core work to get them when you need them, but I’m certainly willing to work with you on that.

Yes, it’s not entirely uncommon to require different sets of form rules in different scenarios. E.g. editing/creating a record may require different forms. Or a fairly common input scenario: 3 fields for month, day, year get stored into a single database "date" field. Yes, these things do really belong with the validation rules... maybe that’s the best place for them, but they are tangentially related to the model. I have a fair number of use-cases already mapped out from using my form-generation library out in the wild.

Maybe we should talk about this more off-line, but I’d love to see tight integration in here somehow.

I tend to think of validation rules for data fields in the ORM as being very much separate from validation rules pertaining to form input fields.
Unless you’re talking about very simple forms based on very simple models, wouldn’t it be more flexible to model the forms themselves? Then you can model any craziness at all that you might want to implement on the front end, including dynamic data via ajax, DOM events etc, mixing fields from different tables or even data from outside the ORM.