collective.xdv - best practice for theming the 'backend'
Locked
|
I want my collective.xdv-themed site to be visually consistent - an anonymous user browsing content and a site admin defining content rules should have a similar experience look and feel wise. This requirement means I can't use the admin.yoursite.com approach to work around how the theme's styles and scripts aren't sympathetic to Plone's 'backend' markup.
Instead I currently have two rules files - view.xml and edit.xml - both referenced from a top-level rules.xml that looks like this: <?xml version="1.0" encoding="UTF-8"?>
<rules
xmlns="http://namespaces.plone.org/xdv"
xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:variable name="edit-templates" select="
(/html/body[contains(concat(' ', normalize-space(@class), ' '),
' template-atct_edit '
)]) or
(/html/body[contains(concat(' ', normalize-space(@class), ' '),
' template-collage_compose '
)]) or
(/html/body[contains(concat(' ', normalize-space(@class), ' '),
' template-criterion_edit_form '
)]) or
.
. (lots more cases here)
.
)])" />
<rules if-content="$edit-templates">
<xi:include href="rules/edit.xml" />
</rules>
<rules if-content="not($edit-templates)">
<xi:include href="rules/view.xml" />
</rules>
</rules>This file uses a class on the <body> to determine whether this is a no-holds-barred view page, or whether it's an edit/admin page where additional styles/scripts should be conservative. I have a rule in edit.xml that drops all stylesheets and scripts from index.html, followed by a rule that appends a set of kindler, gentler static resources. This works, with the restriction that I can't use inline XSL from my xi:included files (collective.xdv 1.0rc11, XDV 0.4b2). Which is a shame because I'd really like to change the general portlet markup with an xsl:template construct in view.xml. I have two questions: - how are others solving the don't-break-the-backend problem in XDV-themed sites? Are there any good code examples around? - is the restriction on inline XSL from xi:included files a bug or a feature? I appreciate that XDV shouldn't do everything (as Martin Aspeli put it: XDV/Deliverance "is more about lifting blocks of html from source to destination, than about complex, element-level transforms like this") but being able to do element-level transforms sure is useful. Dan |
 
|
Martin Aspeli |
Re: collective.xdv - best practice for theming the 'backend'
|
|
Hi,
The last "big" XDV project I did had the editing GUI "themed". I think this is the most "Ploney" way to do things. Our solution had the following: - A single theme.html - A single rules.xml - All the theme's CSS/JS files are registered in portal_css/portal_javascripts with a condition 'request/HTTP_X_XDV | nothing' - All the theme's CSS/JS are then dropped with a <drop theme="//link|//script|//style"/> type rule - Various Plone resources in portal_css/portal_javascripts are turned off in the theme with a condition 'not:request/HTTP_X_XDV|nothing" - All of Plone's CSS/JS/etc are pulled into the theme. We use a single <append /> rule with an "or" for all types of tags so that they arrive in the correct relative order - We have an additional "overrides.css" file that we use to selectively style things coming from Plone that the designer's CSS didn't quite anticipate - Our rules pull in the edit bar and other elements when they exist in the theme There is obviously some work styling the elements, but in most cases we can reuse the Sunburst CSS by enabling the relevant stylesheets (e.g. authoring.css). Certainly, we've not needed anything as complex as what you do below (which I only superficially understand). Martin On 16 September 2010 06:42, Dan Jacka <[hidden email]> wrote:
------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev _______________________________________________ Plone-Users mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/plone-users |
|
|
Thanks for the advice. My rules are looking a whole lot saner, and I'm back to a single rules.xml file. Stylesheets-wise, I have (in this order): - the theme's reset stylesheet, - Plone's default theme styles (excluding base.css and public.css), - an overrides.css in my theme product, - the theme's stylesheets. That overrides.css is the clincher. In that file I reset any custom elements that the theme expects to be unstyled. That is, the overrides.css contains styles like:
#my-custom-form fieldset {
/* reset styles */
margin: 0;
background: transparent;
}
In this way I get Plone's own form styles by default, with my custom forms as exceptions. My convoluted rules file(s) before were an attempt to have the theme's styles as the default, with Plone's styles for special cases. Everything's working fine now. All it took was a complete reversal of my thinking!
Dan |
|
|
Martin Aspeli |
Re: collective.xdv - best practice for theming the 'backend' [SOLVED]
|
|
Thanks for the advice. My rules are looking a whole lot saner, and I'm back The other thing which is useful (if a bit backwards at first) is to actually register all the theme's stylesheets in portal_css, use conditions ("(not:)request/HTTP_X_XDV | nothing") to make sure only the correct ones are included, and then drop all styles from the theme and include all styles from Plone. This way, you get portal_css merging and URL-based invalidation, which will speed up your site and make stylesheet updates easier to deploy. See the collect.xdv PyPI page for details. Martin ------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev _______________________________________________ Plone-Users mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/plone-users |
|
Laurence Rowe |
Re: collective.xdv - best practice for theming the 'backend'
|
|
In reply to this post by Dan Jacka
Your <xi:include> of an <xsl:template> is not working because it is within a <rules> tag with a condition - xdv is unable to apply conditions to a <xsl:template> at this time. Laurence |
«
Return to General Questions
|
1 view|%1 views
Loading...
| Powered by Nabble | See how NAML generates this page |
