On Tue, Feb 24, 2009 at 1:08 PM, Hans <[email protected]> wrote: > > okay, today I cannot find anything about skin design guidelines in BW. > But I got some questions: > > I understand the basics about skin design: > * create a folder in farm/skins/ , example: farm/skins/skinname/ > * create a basic skin template in it with file name 'code.skin.skinname' > * add 'skinname' as skin: skinname to site.config > *edit this template from within the wiki > ** first glitch: if I edit it as file in my text editor, I need to > update a copy of it created automatically in wikifield/pages/ > otherwise my edits will go unnoticed, as the skin used is now the one > in wikifield/pages/code.skin.skinname > This caused considerable confusion.
The idea is to develop it in your wiki until it is what you want (finished), then copy it back to the skin folder and zip it up for distribution. BoltWire can not edit the skin files in any way. It's like many other things in BoltWire. You can tweak your local copy, but can't affect the original. Alternately, to update your skin, just delete code.skin.skinname in the pages folder, and the entire skin will get reimported. (At least, I think all pages will be overwritten...) >I am also confused as some other > files have been automatically copied to the wikifield/pages/ folder, > including javascript files. This is currently hardcoded in line 901 of engine.php. Just add .js to the list (I just did for next release). We could make it configurable, but if all skins install the same way, they will be more interoperable for users. So maybe we should just focus on getting the list right and making sure it's documented somewhere. > * add styles: this seems to need a <<style>> markup in the skin > template head, which picks up style code confusingly not from page > code.style, but from page code.style.name (another period of > confusion, second glitch) Correct. Of course, if you don't have a code.style.skin page, it will use the default code.style sheet. This also enables you to revert back to the default skin at will. Same with code.skin.skinname/code.skin. > * the style page needs a heading <style type='text/css'><!-- and an > ending --></style> i.e HTMl tags, and the styles are inserted into > each page's HTML head, not added as a true style page. so this method > adds a lot of bulk to each browser page download. Nice for editing > styles inside the wiki, but not good for speedy page delivery. This is correct. It's designed to be editable in wiki, but it does affect page size. > * Then I thought I can just add <link ...> tags and have a style page > that way fetched by a browser. > ** I can add <link ...> to the skin template page or the skin style > page, seems no different, but adding to the template page seems more > direct. Here is an interesting page with one solution: http://www.boltwire.com/index.php?p=solutions.css.linked But I think your solution is much simpler. The only problem is the.htaccess file probably needs to simply be edited to allow code.style pages. If you can get that to work, I'll change the core distribution so it can be done. This would be excellent! Then you could put <<style>> OR something like <link rel='stylesheet' href='$page:code.style.myskin' type='text/css' /> and get similar results. Actually, the latter would be better, with no drawbacks I can see... > * I then can add skin variables in the template, and so for instance > create style page switching. But skin variables are defined on page > code.snippets, so i need to tell a future admin who wishes to use my > skin what to add there. Or I create a page code.snippets.skinname and > define my skin variables there. But this seems to override anything > defined in code.snippets, so that would annoy any admin installing my > skin. Right, but I'm steering away from the term skinvars. Just snippets, or snippet vars if you wish. Snippets not defined in code.snippets.skinname should revert to the default code.snippets. If not, there's a mistake somewhere. So you would only include snippets here that specifically need to be redefined. I would feel comfortable assuming at least the default code.snippets are available. > * so i get to another variation: create a skin.php file in my > skins/skinname folder, and boldly use $BOLTpluginHeader to get HTML > code into my skin. Instead of using skin variables, i can now use > proper config variables, to let them be set in page site.config. This > may be much nicer for an admin. But editing the template from within > the wiki suffers, as important parts are now defined in skin.php. > Still, this will give me as designer much more possibilities. But i > wonder what those skin variables are good for, and what those snippet > pages are good for... The advantage to using a snippet would be that they could be easily editable within the wiki, without having to open skin.php, and can be done with simple markup. I would use them for site.actions, a mini login form, a small search box, etc., that you might want to insert in different places based on the skin. Plus maybe a way to set various colors or something that an admin could modify easily. You could also insert a dynamic drop down menu or whatever, but if it gets too "coded" a skin.php may prove easier. In general, I'd say it just depends on how likely an admin would be to edit in in-wiki and whether or not it's easier to do it with markup. > * which leads me to consider Zones. I used to call them subpages. As > admin installing a new wiki i would look at it, change the skin > perhaps, then immidiately want to change the header, only it is not > called 'header' but 'top'. I would go to page top, a sthis is the > relevant part of the skin's layout, and change the wiki name and > slogan there. The fact that it is defined as a skin variable in page > code.snippets is just confusing. I would not look there, unless > heavily poked to do so. Intuitively i want to change the zone pages, > as it is there what i see. There is a zones action that is very helpful to a new user, of your skin. Gives them an instant feel where things are. And links to edit them. The default skin has a header/footer zone, but no content until you add it. They are different from the top/bottom zones. You can of course create any zones you want and name them anything you want. Ideally though, your choices would be similar to the default zones, so again it would be easier to switch between skins. As for snippets, they are only a shortcut. You can just as easily replace the $$name/$$slogan in the zone with the actual name or slogan as changing code.snippets. Either will work. Of course if you use the snippet var, then their custom name/slogan is retained on every skin. And admins might have different skins for different sites, or can even allow different users to select different own skins. So keeping them centralized like this has nice advantages. P.S. I just noticed the solutions/skins section was not working and fixed it. You can see the different skins on each page and how the name and slogan are retained. It's a pretty big plus. > * For a skin designer and a wiki admin the zone subpages are cool. > And i understand zone pages can be changed in the page hierarchy and > pass on their content down the page hierarchy. This is even cooler. > * But i miss a mechanism like a markup function for selectively > disable zones. I think we should add that, so a zone can be taken out > via a markup, and nothing of it will be delivered as HTML. This needs > some special markuop for the template to mark beginning and end of a > block of HTML, referenced to the zone page name, which the function > can act on. Yes, I usually do something like [if ! equal {p0} 1]!title... [if]. But I'm open to suggestions. I should point out thought that BoltWire works just a bit different from PmWiki (I think) in that the markup of each zone is processed completely independently of the others, in the order they appear in the skin. So you couldn't for example put anything like [(noheader)] in the main or footer zone and get it to work. There is however a little feature you might be able to take advantage of. If you set urlzones: true in site.config you can turn off specific zones by adding to a url something like header=false or side=false. Anyway, this could perhaps be used in a config file (skin.php) by doing something like: if (your cond) $_GET['header'] = false; Then the header should vanish when you want. There's also an experimental and slightly kludgy "simpleMain: ,view,print,cache," option which can turn off the header and footer zone when (in this case) action=print, view, or cache. Don't ask me what action=cache is. Could probably be configured in other ways though. Thinking about it now, probably much better would be: noPrintZones: side,bottom,header Or for another example, using the new site.config array syntax we might do: nozone:header: test*,main,site* nozone:footer: test*,main Just thinking out loud. But as these are all pretty easy, I'm happy to add either, or something similar. There's also the option (not being recommended) of creating your own myBOLTgetzones($zone) function. Just copy the core function to skin.php and tweak to your heart's content. I've done my best to slide little hooks like these in many of the more important functions so admins can change these functions easily. Just document your changes, so if BOLTgetzones function gets upgraded you can update your custom one as needed. > Anyway, enough said for th emoment. You can see the points i got > confused about, and perhaps see the potential for admin confusion, as > there are so many places things are added and defined. Plus some skin > pages get copied for unknown reasons from the skin folder into the > pages folder, which is not only confusing but can be quite > frustrating. I should add, the reason all but specifically excluded kinds of pages are imported, is that there could be many kinds of pages brought in, code pages, site pages, zone.skinname, etc. I used to require the skin designer to add a page in the skin folder with an explicit list of pages to import but didn't like it. This seems to work much better. If there are other kinds of pages beside .js that should be excluded, let me know. Also, we really should get some of this information into a skin developer tutorial. Perhaps someone could copy this and edit it a bit to an appropriate page in the site docs. Thanks Hans for your feedback on first impressions. We only have the opportunity for them once per developer! 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 -~----------~----~----~----~------~----~------~--~---
