> > That's why I suggest to change the check to > > "template.skinname.templatename". > > Actually, I think we're just getting too complicated. Maybe we should > think more about putting hooks in to custom certain sections of the > code rather than creating every option in the core.
I think hierarchical capabilities are a simple way to achieve complex results and effects without programming, and without leaving the site interface. A usual way to make things simpler is to generalize rules, in this case the hierarchical syntax for the different elements (skins, styles, templates and zones). But I know it's not easy to find a coherent system to combine skin and hierarchy for all elements. > Because we already have the skin/style order pretty well set, I was > trying to make sure new features match what we already have. So I was > thinking along that line... But I see your point about the CSV. It > would help in zipping up skins if we could make listing them easier. Yes, it is difficult to list or group all template.* pages by skin when the skinname is at the end. > Thinking out loud... Currently we have the following: > > * code.skin, code.skin.skinname, and code.hierarchy.skin. > ** We do not have code.hierarchy.skin.skinname. Same for styles. > * template.templatename, and template.templatename.skinname. We > ** We do not have template.hierarchy.templatename, or > template.hierarchy.templatename.skinname > * zones like side go hierarchy.side and zones.skinname,hierarchy.side (I > think). > > It seems there is some inconsistency with the zones approach... Maybe The zone approach seems more logical to me: I think the first grouping criterium should be the skin used (because the whole site depends on the skin used), and the second the hierarchy. > that's why it didn't quite jive with me right. Notice > code.hierarchy.skin.skinname.hierarchy > template.hierarchy.templatename.skinname > zones.skinname.hierarchy.side > Of course the first two don't exist yet, but they are extrapolations code.hierarchy.skin.skinname.hierarchy ?? > of the options we do have. And nothing fits. To be honest, I'm > inclined to just do this: > *code.skin, code.skinname.skin (same with style) > *template.templatename, template.skinname.templatename > *hierarchy.side, zones.skinname.hierarchy.side That means you accept my suggestion about changing templates' syntax, do you? > To get all your skin files just do > group=code.skinname*,template.skinname*,zones.skinname Right, that it easier. > In addition to the benefit of easier listing and simplified coding. > We'd lose hierarchical skins, but could always do advanced things like > that via a config file. It would be better not to depend on config files for layout and design (though advanced tasks), because config files require special skills, PHP knowledge, and FTP or other server access. Many users will be able to program and design, but when the design tasks can be done inside the wiki framework, the number of potential users grows. I have an idea to keep the door open for hierarchical skins and styles. We can consider the different elements of a page that must be chosen depending on hierarchy and skin: branch, hierarchy, skinname and pagename. In fact we can think hierarchy and pagename are a whole: branch: code.skin skinname: myskin hierarchy and/or pagename: news.2008.12 I think the simpler and more logical approach is to put the skinname first, after the branch. That makes organization, listing and packaging much simpler. So the calculation would be: branch.skinname.hierarchy.pagename Result: code.skin.myskin.news.2008.12 branch: zone skinname: myskin hierarchy and/or pagename: news Result: zone.myskin.news branch: template skinname: myskin hierarchy and/or pagename: mytemplate Result: template.myskin.mytemplate At first sight it looks options are getting more complex: * skin * code.skin * code.skin.skinname * code.skin.skinname.hierarchy * style * code.style * code.style.skinname * code.style.skinname.hierarchy * template.templatename * template.skinname.templatename * template.skinname.hierarchy.templatename * zonename * hierarchy.zonename * zones.skinname.zonename * zones.skinname.hierarchy.zonename But if we make skinname mandatory, things get simpler: * skin DEPRECATED * code.skin DEPRECATED * code.skin.skinname * code.skin.skinname.hierarchy * style DEPRECATED * code.style DEPRECATED * code.style.skinname * code.style.skinname.hierarchy * template.templatename DEPRECATED * template.skinname.templatename * template.skinname.hierarchy.templatename * zonename DEPRECATED * hierarchy.zonename DEPRECATED * zones.skinname.zonename * zones.skinname.hierarchy.zonename The point is not considering "skin" or "style" the pages we are looking for but considering "code.skin" and "code.style" the branches where to look for the actual page, with an optional hierarchy. That way skins and styles would be coherent with the syntax of templates and zones: one common syntax makes thing easier. I see a little problem about deprecating "zonename" and "hierarchy.zonename": all pages to be used like zones must be in the zone branch. I think this is not a big problem. With this approach, the options are: * code.skin.skinname * code.skin.skinname.hierarchy * code.style.skinname * code.style.skinname.hierarchy * template.skinname.templatename * template.skinname.hierarchy.templatename * zones.skinname.zonename * zones.skinname.hierarchy.zonename The default BoltWire installation would contain "skin: default" in site.config and the following pages: code.style.default code.skin.default zone.default.top zone.default.header ...etc Do you think this would make the algorithm easier, as I suspect? > For any other options we could put a couple hooks at key points in the > code to allow full flexibility. Hooks are useful, but I would not depend on them for advanced design and layout, only, because of the same reasons about config files: that would reduce the number of potential users, and the number of tasks an average user can do. The potential of generalizing the hierarchical elements with a common and simpler rule is very interesting. In my opinion it would take BoltWire a bit nearer its Lego approach: one simple rule, many combinations everywhere. Cheers, Marcos -- http://alinome.net --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "BoltWire" group. 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/boltwire?hl=en -~----------~----~----~----~------~----~------~--~---
