Owen, I understand that you want to make a clear format. However, I feel like you are making it unnecessarily complicated for themers. The whole idea of allowing this XML is to make it simpler, not more complicated.
I understand this is the Pluggable XML, which is fine. Some of my points only apply to themes: they would only work as such in themes. I don't think you are being pragmatic in your demands that plugins and themes behave in exactly the same way. Where possible, we should make it easier for themers or there is no point to any of this work. 0.7 should make it EASIER to do a theme, not HARDER. If, where you disagree with me, you can provide a good reason for it, I am wiling to accept that. Otherwise, I don't consider unnecessary complication just for the sake of "standardization" unacceptable. On Jun 3, 11:35 am, Owen Winkler <[email protected]> wrote: > 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. On <attribute> blocks I can agree with you. Fine, make them required so translation must be encouraged. However, it is not mutually exclusive. I don't like your idea that we should do NO sensible defaults. What is wrong with defaulting type to fieldset on <containers>? > 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. I strongly disagree. It's not about making the files shorter, it's about making them clearer. I'm not sure where you suddenly got the idea that sensible defaults are a bad thing. Please, try for once to not think like a developer. As a themer, there is pretty much no reason I would have <containers> that aren't fieldsets. You should not make my job more complicated for no good reason. > > 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. Yes, I meant optional attributes. We do not know what those will necessarily be. The spec should support this. > 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. Again, the very nature of such attributes is that I *cannot* know what they will be ahead of time. I do not know what every possible formcontrol will require, so we should make sure the format is extensible. > > 4) I don't see anything in there for <option> children. Should those be > > included? > > Yes. I'll add that in a new iteration. Okay. > > 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. Please, try to stop thinking of the user as a "developer." This system is not written for you, it is written for themers with relatively little programming experience. I do not expect the majority of themers to be able to write a storage handler. I expect them to be able to hook into the system which intelligent developers provide. For most themers, I do not think null:null: makes sense as a sensible default. If I add a text control with a name, I don't expect that it won't be saved, I expect I'll be able to access it as a theme option. > 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. I'm sorry, but I fear you're taking standardization too far. Of course this is the Pluggable XML spec. The default for PLUGINS can be null:null. For themes it should be theme:name. To demand that there are absolutely no differences between what themes and plugins leverage is shortsighted and impossible. Please, I urge you to work from the presumption that the person who will be writing this XML does *not* know as much programming as you. Their PHP and XML experience is most likely limited. At present, your proposal, and your insistence to not provide any sensible defaults, does not accommodate that person. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
