On Sun, Feb 15, 2009 at 1:03 AM, Linly <[email protected]> wrote: > > Hi Dan, > > 2.46 introduced a new feature that change code.skinvars to > code.snippets. I have some ideas about this. > > There are two different things inside "code.skinvars". One is true > variables, say, Name; another is, I don't know how to name it, maybe > snippets is the exact word. All of these things can be used in skins > as well as in normal pages to display specified content. > > How about separating these two kinds of things as variables and zones? > "Login" can be "zone.login", "search" can be "zone.search", "footer" > can be "zone.footer"... > > The most benefit is if user want to change footer, just open > "zone.footer" to change it. Comparing the logic to open > "code.snippets" and find the "Footer:" to change. > > Zones contain contents. They occupy a certain area. In this case, > login, search... can be zones no doubt. > > Just a thought.
You are right here are both simple fields and larger code chunks (delimited by \n\n) in code.snippets. Snippets probably is the right word for the latter. But I'm not so sure about your suggestion... We can already create a zone.search page and do [(include zone.search)]. In a skin you just put ==[(include zone.search)]==. We could have $$search do one more check on it's list of possible return values, but I'm not sure I want to go that far. And if we did, I'd be inclined to store them in pages like code.snippets.search, instead. Actually, that's a good idea...But then it might conflict with code.snippets.skinname (which is available). I don't know... The think that is unique about $$vars is your data can come from multiple sources. It looks in lot's of different places and returns the first thing it finds that matches. Here's the order it checks: page:some.page $$skin/image.gif $$icon/image.gif A matching system var A matching data field on the same page A snippet on code.snippets.skin A snippet on code.snippets So it has multiple uses. One idea would be to put a $$description in a meta tag. You could set something site wide in code.snippets and then override it on local pages. (Thinking about it now, realize local data vars should override system vars, and will switch order for next release). I also like the possibility of being able to tap into the site.config settings, and had it working, but decided it might be wiser to not disclose those settings so easily. Anyway, these options make the markup more complex, but powerful. In the next release I'll put a hook for a myBOLTsnippets() so you can customize this anyway you want. Cheers, Dan --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
