Hello friends,
But actually I wouldn't advise to overload macros.vm, from experience it becomes a maintenance hell over the long term.
I can see how that can happen. Unfortunately, I think it was the best way to do it, because I converted the menu and sub menu system to a list instead of span to work with the css hovers. Additionally, isn't it more semantic this way, or was there a reason it is this way that I did not realize? Regarding this change, my only observation is an usability one. What are
the most common actions a user will want to do on this page? Navigate away from the page? See comments? See informations? IMO edit action should not be the last in the menu. Maybe you could move edit and export to be more visible or closer to the content. A quick solution would be to put the items in the beginning of the list and not at the end. This way the user doesn't need to scroll all the way down for them.
Makes sense. The change has been made in the implementation (xo5) There are, actually, a couple of mandatory files XWiki will look for (like
view.vm, edit.vm, etc. all those that are referenced from struts actions in java) ; but if they aren't found, XWiki will look for them upstream : in the parent skin (if there is one), then in templates/ folder. So nothing really is mandatory for a skin to implement, you just override what you need to. If you look into Lyrebird you'll there are far less templates than in colibri. It's due both to the fact that for some feature the skin just uses the colibri version (because it works fine) and the fact some templates in lyrebird aggregates what is several templates in colibri, to make it simpler.
This is a good explanation, and confirmed what I thought. Thanks! All those are legitimate questions :) it takes some getting used to and
some experience to grasp the whole skin architecture. For lyrebird I knew where I wanted to go, so I implemented that by either : * adapting (CSS tweaks, reuse of velocity macros, etc.) colibri features (ex: breadcrumb), or * re-writing the feature entirely (ex: top navigation bar, edit mode controls/inputs) But I'm a bit biased since I know the whole structure of colibri well enough to arbitrate this quickly.
Thanks for the insights No you're right fundamentally you don't need a maven build since for now
skins can't be distributed as extensions (but will in the future). But it makes things easier anyway for releasing (creating a SCM tag with an associated version), for creating the zip, etc. Practically, the build could also permit to minify JS and CSS files, filter out some resources, or do some other operation required before distribution.
Ok, I will keep this is mind as I progress further. Progress: a lot of the skin has been implemented (enough to work mostly?). I am still having a bit of issues that I got stuck on, however. - The biggest head scratchier I have right now is the historyinline.vm that I am putting in the sidebar. All the other components of docextra.vm seems to be working fine. But when I turn on the line that pulls in historyinline.vm, the contents in mainContentArea disappears? I tried messing with historyinline.vm, but I can't figure out what is causing it. The history ui and controls works fine, it's just the document oddly disappears. (The way I am turning it off/on is in the sidebar.vm, I put a "!" on line 22 to reverse the if-- causing history to disappear if the document asks for it. The current historyinline.vm is straight from the template). Any idea? - Second, I can't find any mention of the gadget wrappers or anything to do with gadgets in the templates? Did I miss it, or is it placed elsewhere. The reason is I want to add a <section> wrapper as per html5, since each "gadgets" are a "section" of the articles/content, correct? I will touch upon this in email regarding semantics. As always, source (for implementation) is at: https://github.com/jssolichin/xo5 Thank you again for all the help and insights! Jonathan Solichin