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 _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
