[Plone-developers] Before we ship plone.app.theming with Plone 4.2
AnthonyG
annoyances off my chest before we bundle it with the core.
1. If you're including html from an additional plone view then it is
incredibly hard to debug when you have errors in the view. e.g.
If I have a rule like
<append theme="/html/head" css:content="meta"
href="@@standard-page-elements" />
and there is an error rendering @@standard-page-elements then you get the
following very unhelpful message in the logs
2012-01-09T08:48:08 ERROR plone.transformchain Unexpected error whilst
trying to apply transform chain
Traceback (most recent call last):
File
"/home/zopeourafrica/home/eggs/plone.transformchain-1.0-py2.6.egg/plone/transformchain/transformer.py",
line 42, in __call__
newResult = handler.transformIterable(result, encoding)
File
"/home/zopeourafrica/home/eggs/plone.app.theming-1.0b10_20111222-py2.6.egg/plone/app/theming/transform.py",
line 259, in transformIterable
transformed = transform(result.tree, **params)
File "xslt.pxi", line 548, in lxml.etree.XSLT.__call__
(src/lxml/lxml.etree.c:120052)
File "lxml.etree.pyx", line 280, in
lxml.etree._ExceptionContext._raise_if_stored (src/lxml/lxml.etree.c:7959)
XSLTApplyError: Cannot resolve URI @@standard-page-elements
Sometimes you can request the view directly to find the problem but other
times the error only occurs when not logged on and going through virtual
hosting and you have to step through many lines of code to try to locate the
actual exception.
2. When there's an error generating the themed view p.a.theming serves the
Plone view. This just seems wrong to me - if there's an error on the server
you should get a 500 internal server error. On our site I absolutely never
want to show the Plone view to the public, an unformatted 500 Apache error
page would be better. Some hooks in p.a.theming to display formatted error
pages would be ideal.
--
View this message in context: http://plone.293351.n2.nabble.com/Before-we-ship-plone-app-theming-with-Plone-4-2-tp7375809p7375809.html
Sent from the Core Developers mailing list archive at Nabble.com.
------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure
_______________________________________________
Plone-developers mailing list
Plone-de...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plone-developers
Martin Aspeli
2. When there's an error generating the themed view p.a.theming serves the
Plone view. This just seems wrong to me - if there's an error on the server
you should get a 500 internal server error. On our site I absolutely never
want to show the Plone view to the public, an unformatted 500 Apache error
page would be better. Some hooks in p.a.theming to display formatted error
pages would be ideal.
Laurence Rowe
The transform is applied in non-200 responses, but if a transform
itself causes an exception (in Anthony's case from a subrequest) then
we currently bail out and show the unthemed response. This means you
can still log in and possibly switch off theming.
I'm not sure plone.transformchain is doing the right thing here, but
I'm not sure that there necessarily is a single right thing. We
definitely need to show some sort of error message on the page itself
(could this be done with a status message cookie somehow?) Maybe in
production mode we should show the normal error message rather than
catching it and perhaps that error message should be themed (CSS wise)
in a more neutral way (as the login page probably should too.)
Laurence
Martin Aspeli
Anthony Gerrard
No but in this circumstance I think a 500 is also the appropriate
response. Laurence is right that I get this with subrequests. It may
be an 'advanced' technique but it is really powerful and has proved
invaluable to us.
Anthony Gerrard
from the main request to give nicely formatted error pages.
Laurence Rowe
The theme here compiles fine, the problem is in executing it and
deciding what should happen when that execution fails. As well as
failing to compile, a theme can fail to execute because:
1) An error is raised by a parameter expression (e.g.
"python:context.wrongMethodName()")
2) A subrequest referenced by the theme (i.e. due to <replace
theme=".." content="..." href="@@my_theme_stuff"/>) results in an
error.
- We should at least log this better in the InternalResolver.
3) An xpath evaluation raises an error for some reason.
I think plone.transformchain is probably wrong to swallow these
errors, at least in production mode. But letting it raise might be
problematic too.
Anthony Gerrard
pages. We have a nice public view of our site
normally if you request a page that doesn't exist then you get a nice
404 message
http://www.our-africa.org/madeup
There's no hint of Plone to end users and we don't want there to be.
It turns out there's this weird bug in one of plone.subrequest or
VirtualHostMonster that means that if your URL starts with a URL to a
non existent page and ends with a double slash or has a double slash
followed by another slash somewhere then the wrong url for the
rules.xml file is used in the subrequest and so you get the unthemed
version instead. e.g.
http://www.our-africa.org/madeup// or
http://www.our-africa.org/madeup//a/ but not
http://www.our-africa.org/madeup//a
What actually happened here was an internal server error. I'd like a
500 response to the end user and something meaningful in the log to
debug please. Instead the user gets a but of a shock and in the logs
I see XSLTApplyError: Cannot resolve URI /@@standard-page-elements
If you're interested in what the bug is then it seems in this case
that VirtualHostMonster trims additional slashes out of
VIRTUAL_URL_PARTS which means that plone.subrequest calculates the
wrong request root for the rules.xml request. I'm not sure whether
this is a bug in plone.subrequest or VirtualHostMonster.
Anthony
Dylan Jay
I'm a bit concerned we'd be shipping diazo without having it
integrated with browserlayers, skins and resource registry bundles.
For instance a typical theme we'd develop would be filesystem based.
It will have a diazo rules that would assume
- I'm building on top of plonetheme.basic
- I've added some css files from the diazo theme to css registry (via
GS)
- I've disabled some of plonetheme.basics css (via GS)
- I've created a new theme browser layer and hooked some jbot
customisations in there
- I've overridden some skin resources such as logo.png
As you can see these things are currently loosely coupled together
with no central concept of a theme.
Are there any proposals out there any the moment for tying these
together?
---
Dylan Jay
Technical Solutions Manager
PretaWeb: Multisite Performance Support
P: +612 80819071 | M: +61421477460 | twitter.com/djay75 | linkedin.com/
in/djay75
---
Dylan Jay
Technical Solutions Manager
PretaWeb: Multisite Performance Support
P: +612 80819071 | M: +61421477460 | twitter.com/djay75 | linkedin.com/
in/djay75
---
Dylan Jay
Technical Solutions Manager
PretaWeb: Multisite Performance Support
P: +612 80819071 | M: +61421477460 | twitter.com/djay75 | linkedin.com/
in/djay75
Laurence Rowe
> Hi,
>
> I'm a bit concerned we'd be shipping diazo without having it
> integrated with browserlayers, skins and resource registry bundles.
>
> For instance a typical theme we'd develop would be filesystem based.
> It will have a diazo rules that would assume
> - I'm building on top of plonetheme.basic
> - I've added some css files from the diazo theme to css registry (via
> GS)
> - I've disabled some of plonetheme.basics css (via GS)
> - I've created a new theme browser layer and hooked some jbot
> customisations in there
> - I've overridden some skin resources such as logo.png
>
> As you can see these things are currently loosely coupled together
> with no central concept of a theme.
> Are there any proposals out there any the moment for tying these
> together?
In the long run all of these theming things need to be tied into the
CMF skin key. The RR bundle stuff on trunk (which won't ship in 4.2)
is a start. p.a.theming should then grow per-skin key configuration.
It's all desirable, but it would be silly to hold off shipping
p.a.theming which brings real benefits now while we wait for someone
to build it.
"Le mieux est l'ennemi du bien." - Voltaire
Laurence
Martin Aspeli
Hi,
I'm a bit concerned we'd be shipping diazo without having it
integrated with browserlayers, skins and resource registry bundles.
For instance a typical theme we'd develop would be filesystem based.
It will have a diazo rules that would assume
- I'm building on top of plonetheme.basic
- I've added some css files from the diazo theme to css registry (via
GS)
- I've disabled some of plonetheme.basics css (via GS)
- I've created a new theme browser layer and hooked some jbot
customisations in there
- I've overridden some skin resources such as logo.png
As you can see these things are currently loosely coupled together
with no central concept of a theme.
Alex Clark
+1. Though I'm sure people will be confused (E.g. themes and "diazo
themes" in the control panel?), and I'm not sure what the best way to
mitigate that confusion is, I still think Diazo theming in Plone is big
win and we should strive to resolve any confusion / missing features /
etc, vs hold up inclusion in core.
Alex
>
> Martin
>
>
>
> ------------------------------------------------------------------------------
> This SF email is sponsosred by:
> Try Windows Azure free for 90 days Click Here
> http://p.sf.net/sfu/sfd2d-msazure
>
>
>
> _______________________________________________
> Plone-developers mailing list
> Plone-de...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/plone-developers
--
Alex Clark · http://pythonpackages.com
Dylan Jay
>
>
>> On 18 March 2012 12:51, Dylan Jay <dj...@pretaweb.com> wrote:
>> Hi,
>>
>> I'm a bit concerned we'd be shipping diazo without having it
>> integrated with browserlayers, skins and resource registry bundles.
>>
>> For instance a typical theme we'd develop would be filesystem based.
>> It will have a diazo rules that would assume
>> - I'm building on top of plonetheme.basic
>> - I've added some css files from the diazo theme to css registry (via
>> GS)
>> - I've disabled some of plonetheme.basics css (via GS)
>> - I've created a new theme browser layer and hooked some jbot
>> customisations in there
>> - I've overridden some skin resources such as logo.png
>>
>> As you can see these things are currently loosely coupled together
>> with no central concept of a theme.
>
> True, but you could do all of that with Diazo. Yes, you lose out on
> RR resource merging, for instance, and we should fix that, but for a
> lot of people, this is a
The items above we steps I need to have done in addition to installing
a diazo theme.
> nice-to-have feature. It's only really an issue if you need to build
> something that's super high performance.
Fair enough. But its more about telling a simple concise story about
how themeing works. It's hard to understand right now for beginners
how everything works together. It's especially hard to understand how
one theme builds on top of another. Eg. diazo theme customizing
browserresource/skin style theme. Actually this week we've reached the
point where we want base a series of diazo themes on a base diazo
theme... and we're trying to work out how that's structured.... and
it's not obvious :(
You are right that somethings I've listed are advanced but as soon as
diazo become core all these corner cases will get asked and have to be
documented.
Anyway, integrating Diazo with the CMF skin keys seems like a really
good idea. It would be awesome if someone who knows this stuff could
PLIP that for 4.3?
I think what I'm trying to say is that in Plone we have a history of
introducing technologies and not fully integrating them or deprecating
other technologies until later. I can see this is pragmatic as it
allows time to fully see how things work together. This works okish
for people like us that work with Plone day in day out. But for
beginners.... I can see how they would see it as frustrating. I think
it's unfortunate nature of our community that because we're all mainly
plone professionals we are ok with living with tools that you need to
be a professional to use e.g. have caveats :( Just because in a choice
between cleaning up an old tool and creating a new tool which gives us
more functionality, the later wins out, which is perfectly
understandable, we have limited resources.
>
> FWIW, I think we should:
>
> - Figure out what CSS people want to reuse (I think portlets,
> editing controls, maybe forms) and make sunburst ship those as
> separate files (as was intended)
+1
>
> - Make it possible for Diazo-provided CSS and JS to be part of RR
> resource merging (already some groundwork has been done, since you
> can now supply resources via adapter lookup as well as persistent
> reference)
+1
>
> - Encourage people to use plone.app.themingplugins if they want
> jbot-style template overrides or custom views. Ideally, make this
> work TTW as well as on the filesystem.
+0 I'm still not sure about this. It seems like yet another way to do
the same thing. Isn't Plone switching off restricted TAL so wouldn't
TTW jbot be a security risk?
In general we've found TTW template customisations to be a big pain as
it makes it really hard replicate issues as some code is in the
filesystem and some is in the DB. It makes upgrades a big pain as we
often have to reverse engineer what the change was in the template and
redo it, merging in whatever has changed with the base template in the
plone upgrade. Modifying base templates I think is a poor way to make
customisations. It's essentially hacking the core.
I think the future is zero template customisations. We strive to use
only plugins to generate the required html for a site no matter how
ugly it looks. Then we use diazo to massage that into what the client
wants. This means there is a true separation of content vs theme.
Plugins like deco, styledportlets really help get the right html on
the page. We've also started using easytemplates but I think this is
also a hack. I'd love there to be a solution for TTW translations so
simple text changes can be achieved. We also need much more flexible
ways to create listings in portlets and collections.
With more plugins + diazo I think we can avoid the need for 99% of all
zpt template overrides. For that reason I think adding in TTW jbot
should be avoided.
I realise this approach might be a little controversial so I'd be
interested if anyone has had the same thoughts.
>
> As Laurence said, though, this is not a showstopper. The Diazo
> 'interface' is sufficiently self-contained for people to not be
> confused (I'd hope), so this is more about missing possible features
> than it is about active conflict within the stack.
>
> Martin
>
Martin Aspeli
On 19/03/2012, at 4:10 AM, Martin Aspeli wrote:The items above we steps I need to have done in addition to installing a diazo theme.
On 18 March 2012 12:51, Dylan Jay <dj...@pretaweb.com> wrote:
Hi,
I'm a bit concerned we'd be shipping diazo without having it
integrated with browserlayers, skins and resource registry bundles.
For instance a typical theme we'd develop would be filesystem based.
It will have a diazo rules that would assume
- I'm building on top of plonetheme.basic
- I've added some css files from the diazo theme to css registry (via
GS)
- I've disabled some of plonetheme.basics css (via GS)
- I've created a new theme browser layer and hooked some jbot
customisations in there
- I've overridden some skin resources such as logo.png
As you can see these things are currently loosely coupled together
with no central concept of a theme.
True, but you could do all of that with Diazo. Yes, you lose out on RR resource merging, for instance, and we should fix that, but for a lot of people, this is a
Fair enough. But its more about telling a simple concise story about how themeing works. It's hard to understand right now for beginners how everything works together. It's especially hard to understand how one theme builds on top of another. Eg. diazo theme customizing browserresource/skin style theme. Actually this week we've reached the point where we want base a series of diazo themes on a base diazo theme... and we're trying to work out how that's structured.... and it's not obvious :(
nice-to-have feature. It's only really an issue if you need to build something that's super high performance.
You are right that somethings I've listed are advanced but as soon as diazo become core all these corner cases will get asked and have to be documented.
Anyway, integrating Diazo with the CMF skin keys seems like a really good idea. It would be awesome if someone who knows this stuff could PLIP that for 4.3?
I think what I'm trying to say is that in Plone we have a history of introducing technologies and not fully integrating them or deprecating other technologies until later. I can see this is pragmatic as it allows time to fully see how things work together. This works okish for people like us that work with Plone day in day out. But for beginners.... I can see how they would see it as frustrating. I think it's unfortunate nature of our community that because we're all mainly plone professionals we are ok with living with tools that you need to be a professional to use e.g. have caveats :( Just because in a choice between cleaning up an old tool and creating a new tool which gives us more functionality, the later wins out, which is perfectly understandable, we have limited resources.
+1
FWIW, I think we should:
- Figure out what CSS people want to reuse (I think portlets, editing controls, maybe forms) and make sunburst ship those as separate files (as was intended)
+1
- Make it possible for Diazo-provided CSS and JS to be part of RR resource merging (already some groundwork has been done, since you can now supply resources via adapter lookup as well as persistent reference)
+0 I'm still not sure about this. It seems like yet another way to do the same thing.
- Encourage people to use plone.app.themingplugins if they want jbot-style template overrides or custom views. Ideally, make this work TTW as well as on the filesystem.
Isn't Plone switching off restricted TAL so wouldn't TTW jbot be a security risk?
In general we've found TTW template customisations to be a big pain as it makes it really hard replicate issues as some code is in the filesystem and some is in the DB.
With more plugins + diazo I think we can avoid the need for 99% of all zpt template overrides. For that reason I think adding in TTW jbot should be avoided.
Lennart Regebro
> It's especially hard to understand how
> one theme builds on top of another.
They don't?
> Eg. diazo theme customizing browserresource/skin style theme.
What's the usecase for that?
> You are right that somethings I've listed are advanced but as soon as
> diazo become core all these corner cases will get asked and have to be
> documented.
Or avoided. :-)
You do need to override templates sometimes, even with Diazo. But I
don't see how that would be different when you use Diazo.
Also, I do agree that an easier set up of CSS/JS resources would be
nice in conjunction with Diazo would be nice. Plone has nice tools for
that, and currently for my Diazo themes I'm usually just ignoring
them. That's not a big issue as I don't do editing through the Diazo
theme, so there is usually very little Javascript and CSS, but still.
Would be nice.
//Lennart
Martin Aspeli
On Mon, Mar 19, 2012 at 01:54, Dylan Jay <dj...@pretaweb.com> wrote:They don't?
> It's especially hard to understand how
> one theme builds on top of another.
What's the usecase for that?
> Eg. diazo theme customizing browserresource/skin style theme.
Or avoided. :-)
> You are right that somethings I've listed are advanced but as soon as
> diazo become core all these corner cases will get asked and have to be
> documented.
You do need to override templates sometimes, even with Diazo. But I
don't see how that would be different when you use Diazo.
Also, I do agree that an easier set up of CSS/JS resources would be
nice in conjunction with Diazo would be nice. Plone has nice tools for
that, and currently for my Diazo themes I'm usually just ignoring
them. That's not a big issue as I don't do editing through the Diazo
theme, so there is usually very little Javascript and CSS, but still.
Would be nice.
Laurence Rowe
The ability to enable different Diazo themes for different CMF skins
is really useful for larger sites. Of course you can put all of the
logic into a single theme and switch based on conditions, but this
becomes unmanageable when you have many different themes and from a QA
perspective it creates much more work (can you be sure that the change
for one department does not impact on any other department without
checking over everything?)
Laurence
Laurence Rowe
>> Also, I do agree that an easier set up of CSS/JS resources would be
>> nice in conjunction with Diazo would be nice. Plone has nice tools for
>> that, and currently for my Diazo themes I'm usually just ignoring
>> them. That's not a big issue as I don't do editing through the Diazo
>> theme, so there is usually very little Javascript and CSS, but still.
>> Would be nice.
>
>
> If someone wants to work on this, the basic approach should be:
>
> - scan the theme HTML file for resources
> - use the adapter hook in ResourceRegistries to register these with sensible
> defaults
> - possibly, allow some kind of hints (e.g. data-* attributes) to control
> some of the RR options
> - implicitly drop these from the theme and pull in the RR-managed CSS/JS
>
> Some of the settings for these (e.g. what to do with the default RR entries)
> would likely need to be in a custom section in the manifest.cfg file. The
> parser supports that.
I think it would be simpler to just explicitly list the resources for
RR in the manifest.cfg. A single Diazo rules file can reference
multiple HTML themes and they may not all use the exact same set of
resources.
Laurence
Martin Aspeli
Of course you can put all of the
logic into a single theme and switch based on conditions, but this
becomes unmanageable when you have many different themes and from a QA
perspective it creates much more work (can you be sure that the change
for one department does not impact on any other department without
checking over everything?)
Martin Aspeli
On 19 March 2012 10:52, Martin Aspeli <optilud...@gmail.com> wrote:I think it would be simpler to just explicitly list the resources for
>> Also, I do agree that an easier set up of CSS/JS resources would be
>> nice in conjunction with Diazo would be nice. Plone has nice tools for
>> that, and currently for my Diazo themes I'm usually just ignoring
>> them. That's not a big issue as I don't do editing through the Diazo
>> theme, so there is usually very little Javascript and CSS, but still.
>> Would be nice.
>
>
> If someone wants to work on this, the basic approach should be:
>
> - scan the theme HTML file for resources
> - use the adapter hook in ResourceRegistries to register these with sensible
> defaults
> - possibly, allow some kind of hints (e.g. data-* attributes) to control
> some of the RR options
> - implicitly drop these from the theme and pull in the RR-managed CSS/JS
>
> Some of the settings for these (e.g. what to do with the default RR entries)
> would likely need to be in a custom section in the manifest.cfg file. The
> parser supports that.
RR in the manifest.cfg. A single Diazo rules file can reference
multiple HTML themes and they may not all use the exact same set of
resources.
Dylan Jay
Why can't we just include a cssregistry.xml file in a theme zip? I
realize it's XML, its not perfect, it's not pretty but It's a format
that's already documented, implemented and maintained and will likely
be so for a long time. It allows for both disabling or modifying
existing css as well as adding new css. Surely whatever is in going to
be in manifest.cfg is just going to be a cut down version of
cssregistry.xml in an ini style format so it will be a yet another
case of ... "if you implementing things this way then use this file
over here with this format, but if you need feature X then you'll have
to revert to using this other format, using this other technology...
let me explain generic setup to you....".
Personally I think that more important than yet another format for
configuration is the concept of the theme needs to be unified such
that if a diazo theme is active then appropriate RR entries are used
and the any browserlayer theme customisations are also used ... and
the skin associated is used... until such time as skins do die (which
I also wish they would but which doesn't look likely as none of it's
replacements let you override logo.png TTW... another example of one
technology only partially replacing an old technology).
Martin Aspeli
Why can't we just include a cssregistry.xml file in a theme zip?
I realize it's XML, its not perfect, it's not pretty but It's a format that's already documented, implemented and maintained and will likely be so for a long time. It allows for both disabling or modifying existing css as well as adding new css. Surely whatever is in going to be in manifest.cfg is just going to be a cut down version of cssregistry.xml in an ini style format so it will be a yet another case of ... "if you implementing things this way then use this file over here with this format, but if you need feature X then you'll have to revert to using this other format, using this other technology... let me explain generic setup to you....".
Personally I think that more important than yet another format for configuration is the concept of the theme needs to be unified such that if a diazo theme is active then appropriate RR entries are used and the any browserlayer theme customisations are also used ... and the skin associated is used... until such time as skins do die (which I also wish they would but which doesn't look likely as none of it's replacements let you override logo.png TTW... another example of one technology only partially replacing an old technology).
Anthony Gerrard
designers to create themes. Having to specify which css and
javascript gets included in cssregistry / manifest files doesn't sound
great to me. You already know what css and javascript needs to be
included because it's what is in the resultant html.
What would be better? p.a.theming scanning link and script elements in
the head and performing merging operations based on that. You'd
probably err on the side of caution in terms of minimizing and allow
data- attributes to provide hints for more or less aggressive
performance optimization but the default behaviour would just work
with no additional configuration required.
Martin Aspeli
One of the aims of Diazo / p.a.theming was to enable graphics
designers to create themes. Having to specify which css and
javascript gets included in cssregistry / manifest files doesn't sound
great to me. You already know what css and javascript needs to be
included because it's what is in the resultant html.
What would be better? p.a.theming scanning link and script elements in
the head and performing merging operations based on that. You'd
probably err on the side of caution in terms of minimizing and allow
data- attributes to provide hints for more or less aggressive
performance optimization but the default behaviour would just work
with no additional configuration required.