Arthus Erea wrote: > > 1) Should "type" be required for <container> or can we default to fieldset? > 2) Can we make the "attribute" sections optional for controls, allowing > them to be attached to the main item as well? The attribute sections are > only needed for translation.
We have a responsibility to make good, sensible formats where we can, and I think that takes priority over letting theme developers take shortcuts. Assume that every themer would love to have their theme's strings translated - there's no reason to avoid starting out with the data in the right place for that to happen. I see the choices as two: 1) make the files shorter by omitting values and using obscured, if documented, defaults or 2) make the files longer but necessarily obvious. I like choice 2 for the little suffered discomfort of clarity. > 3) You are aware that there /will/ be many different, optional controls > which different formcontrols require. Does the accommodate that? Does it > matter? If by "optional controls" you mean "optional attributes", then yes, I am aware, and it should accommodate that as-is. Nonetheless, I am human and fallible, so I posted it rather than keeping it to myself that others could verify my work and provide potential corrections. I suggest that if you have a particular concern that you think this format will not address, then you bring it to light, like in point #4 below. > 4) I don't see anything in there for <option> children. Should those be > included? Yes. I'll add that in a new iteration. > 5) Can we make storage optional? The whole point is to make it easier > for themers to create configuration, and forcing them to think about > storage makes that harder. If not supplied, we'd provide > an intelligent default based upon the form location. If storage is optional, then the default should be "null:null", since specifying no storage should indicate that no storage is required, and the developer will handle it with code. Remember that this is not the Theme XML spec, it is the Pluggable XML spec. As such, it makes no sense to default storage to one place when the bulk of configuration options may be stored elsewhere by the other pluggable type. Owen --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/habari-dev -~----------~----~----~----~------~----~------~--~---
