Hi, I'd like to revert the removal of the ++skin++ traverser in Zope 4. As we're working on a replacement ZMI at a sprint currently (more details about that in a bit) we'd like to leverage this feature. From my perspective, I value that Zope 2/4 has always made some choices upfront that one could leverage right away. Especially as multiple orthogonal components (like: your application and the ZMI) need to leverage this plugin point, I'd rather have this provided by the framework. I couldn't find an argument anywhere why ++skin++ should be gone. Christian -- Christian Theune · ct@gocept.com gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 0 · fax +49 345 1229889 1 Zope and Plone consulting, development, hosting, operations
On 16 November 2011 10:30, Christian Theune <ct@gocept.com> wrote:
Hi,
I'd like to revert the removal of the ++skin++ traverser in Zope 4.
As we're working on a replacement ZMI at a sprint currently (more details about that in a bit) we'd like to leverage this feature.
From my perspective, I value that Zope 2/4 has always made some choices upfront that one could leverage right away. Especially as multiple orthogonal components (like: your application and the ZMI) need to leverage this plugin point, I'd rather have this provided by the framework.
I couldn't find an argument anywhere why ++skin++ should be gone.
It was removed in http://zope3.pov.lt/trac/changeset/122056 because it wasn't actually being used anywhere. I'm not completely averse to adding it back, but it does create confusion with the various different alternatives in Zope2 like CMF skins and plone.browserlayer. Laurence
Hi, On 11/16/2011 12:24 PM, Laurence Rowe wrote:
On 16 November 2011 10:30, Christian Theune<ct@gocept.com> wrote:
Hi,
I'd like to revert the removal of the ++skin++ traverser in Zope 4.
As we're working on a replacement ZMI at a sprint currently (more details about that in a bit) we'd like to leverage this feature.
From my perspective, I value that Zope 2/4 has always made some choices upfront that one could leverage right away. Especially as multiple orthogonal components (like: your application and the ZMI) need to leverage this plugin point, I'd rather have this provided by the framework.
I couldn't find an argument anywhere why ++skin++ should be gone.
It was removed in http://zope3.pov.lt/trac/changeset/122056 because it wasn't actually being used anywhere. I'm not completely averse to adding it back, but it does create confusion with the various different alternatives in Zope2 like CMF skins and plone.browserlayer.
I think it was not used by Zope2 itself - however, it's a feature provided by the framework that applications can use. I guess there might be features in a framework that the framework itself doesn't make use of. Going down into the new ZMI project I find it to be the most light-weight approach without adding an extra dependency. Christian -- Christian Theune · ct@gocept.com gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 0 · fax +49 345 1229889 1 Zope and Plone consulting, development, hosting, operations
On 11/16/2011 12:31 PM, Martin Aspeli wrote:
On 16 November 2011 11:30, Christian Theune<ct@gocept.com> wrote:
Going down into the new ZMI project I find it to be the most light-weight approach without adding an extra dependency.
What is this project? ;-)
We're currently sprinting in Berlin to explore a clean-up of the ZMI. We're experimenting a bit with some ideas and I'll make a write-up of what we found in the next days. Technically we're investigating making a separate package that would allow us to remove the old cruft DTML-ZMI and replace it with a small, PT-based Zope4 application that runs in a separate skin. Christian -- Christian Theune · ct@gocept.com gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 0 · fax +49 345 1229889 1 Zope and Plone consulting, development, hosting, operations
On Wed, Nov 16, 2011 at 12:24, Laurence Rowe <l@lrowe.co.uk> wrote:
It was removed in http://zope3.pov.lt/trac/changeset/122056 because it wasn't actually being used anywhere. I'm not completely averse to adding it back, but it does create confusion with the various different alternatives in Zope2 like CMF skins and plone.browserlayer.
Right. Could we standardize on skins or browserlayers plz? Having both confuses the heck out of me. //Lennart
Am 16.11.2011, 12:49 Uhr, schrieb Lennart Regebro <regebro@gmail.com>:
Right. Could we standardize on skins or browserlayers plz? Having both confuses the heck out of me.
Definitely a topic that needs (re)-opening. From a CMF point of I think we're just about at the point where we could switch to browser layers, well, at least once CMF 2.3 has been released. But I think that CMF Skins still offer some functionality that you don't get with browser layers out of the box. Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Kronenstr. 27a Düsseldorf D- 40217 Tel: +49-211-600-3657 Mobile: +49-178-782-6226
On Wed, Nov 16, 2011 at 12:53, Charlie Clark <charlie.clark@clark-consulting.eu> wrote:
Am 16.11.2011, 12:49 Uhr, schrieb Lennart Regebro <regebro@gmail.com>:
Right. Could we standardize on skins or browserlayers plz? Having both confuses the heck out of me.
Definitely a topic that needs (re)-opening. From a CMF point of I think we're just about at the point where we could switch to browser layers, well, at least once CMF 2.3 has been released. But I think that CMF Skins still offer some functionality that you don't get with browser layers out of the box.
When I said skins I meant ++skins++. CMF Skins must die. //Lennart
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/16/2011 07:28 AM, Lennart Regebro wrote:
On Wed, Nov 16, 2011 at 12:53, Charlie Clark <charlie.clark@clark-consulting.eu> wrote:
Am 16.11.2011, 12:49 Uhr, schrieb Lennart Regebro <regebro@gmail.com>:
Right. Could we standardize on skins or browserlayers plz? Having both confuses the heck out of me.
Definitely a topic that needs (re)-opening. From a CMF point of I think we're just about at the point where we could switch to browser layers, well, at least once CMF 2.3 has been released. But I think that CMF Skins still offer some functionality that you don't get with browser layers out of the box.
When I said skins I meant ++skins++. CMF Skins must die.
Note that for all their warts, they are *massively* more successful than the Z3 reimplementation, which was overengineered (I helped with that, I'm sure). In particular, the exceesive amount of ZCA majyk makes complicaterd uses of the Z3 skins very fragile (easy to misconfigure, hard to discover what you broke). Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk7DtUkACgkQ+gerLs4ltQ6m1ACfefhRA+UQGJEuFs8DTl/ADj3b IeUAoLcfBcOUTVAw9uLSYxRxdAMYV/An =EJ4l -----END PGP SIGNATURE-----
On 11/16/2011 02:06 PM, Tres Seaver wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 11/16/2011 07:28 AM, Lennart Regebro wrote:
On Wed, Nov 16, 2011 at 12:53, Charlie Clark <charlie.clark@clark-consulting.eu> wrote:
Am 16.11.2011, 12:49 Uhr, schrieb Lennart Regebro <regebro@gmail.com>:
Right. Could we standardize on skins or browserlayers plz? Having both confuses the heck out of me.
Definitely a topic that needs (re)-opening. From a CMF point of I think we're just about at the point where we could switch to browser layers, well, at least once CMF 2.3 has been released. But I think that CMF Skins still offer some functionality that you don't get with browser layers out of the box.
When I said skins I meant ++skins++. CMF Skins must die.
Note that for all their warts, they are *massively* more successful than the Z3 reimplementation, which was overengineered (I helped with that, I'm sure). In particular, the exceesive amount of ZCA majyk makes complicaterd uses of the Z3 skins very fragile (easy to misconfigure, hard to discover what you broke).
But they also have their merits. If I could make a wish, I'd like to see a shared implementation that marries all the benefits. :) Something I love a lot is the ++skin++ traverser for example. I also like the idea of "tagging" the Request object with structured information (an interface) to indicate specialisation. I hate that I have to spell the layer in each ZCML statement. Just my 0.02, Christian -- Christian Theune · ct@gocept.com gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 0 · fax +49 345 1229889 1 Zope and Plone consulting, development, hosting, operations
Am 16.11.2011, 15:15 Uhr, schrieb Christian Theune <ct@gocept.com>:
But they also have their merits. If I could make a wish, I'd like to see a shared implementation that marries all the benefits.
Something I love a lot is the ++skin++ traverser for example. I also like the idea of "tagging" the Request object with structured information (an interface) to indicate specialisation.
I hate that I have to spell the layer in each ZCML statement.
Smells like a "ZIP" to me. ;-) Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Kronenstr. 27a Düsseldorf D- 40217 Tel: +49-211-600-3657 Mobile: +49-178-782-6226
On 16 November 2011 12:28, Lennart Regebro <regebro@gmail.com> wrote:
On Wed, Nov 16, 2011 at 12:53, Charlie Clark <charlie.clark@clark-consulting.eu> wrote:
Am 16.11.2011, 12:49 Uhr, schrieb Lennart Regebro <regebro@gmail.com>:
Right. Could we standardize on skins or browserlayers plz? Having both confuses the heck out of me.
Definitely a topic that needs (re)-opening. From a CMF point of I think we're just about at the point where we could switch to browser layers, well, at least once CMF 2.3 has been released. But I think that CMF Skins still offer some functionality that you don't get with browser layers out of the box.
When I said skins I meant ++skins++. CMF Skins must die.
While I think there is definitely scope for simplifying the mix of competing skin concepts in the Zope/CMF/Plone space, we need to be careful not to bite off more than we can chew. We still have a lot of CMF skin scripts and templates in Plone that I don't want to become a blocker for adopting Zope 4. This should be the first of several releases that progressively rationalise our software stack, lets not try and do it all at once. Laurence
On 11/16/2011 04:12 PM, Laurence Rowe wrote:
On 16 November 2011 12:28, Lennart Regebro<regebro@gmail.com> wrote:
On Wed, Nov 16, 2011 at 12:53, Charlie Clark <charlie.clark@clark-consulting.eu> wrote:
Am 16.11.2011, 12:49 Uhr, schrieb Lennart Regebro<regebro@gmail.com>:
Right. Could we standardize on skins or browserlayers plz? Having both confuses the heck out of me.
Definitely a topic that needs (re)-opening. From a CMF point of I think we're just about at the point where we could switch to browser layers, well, at least once CMF 2.3 has been released. But I think that CMF Skins still offer some functionality that you don't get with browser layers out of the box.
When I said skins I meant ++skins++. CMF Skins must die.
While I think there is definitely scope for simplifying the mix of competing skin concepts in the Zope/CMF/Plone space, we need to be careful not to bite off more than we can chew. We still have a lot of CMF skin scripts and templates in Plone that I don't want to become a blocker for adopting Zope 4. This should be the first of several releases that progressively rationalise our software stack, lets not try and do it all at once.
Ack. -- Christian Theune · ct@gocept.com gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 0 · fax +49 345 1229889 1 Zope and Plone consulting, development, hosting, operations
On Wed, Nov 16, 2011 at 16:12, Laurence Rowe <l@lrowe.co.uk> wrote:
While I think there is definitely scope for simplifying the mix of competing skin concepts in the Zope/CMF/Plone space, we need to be careful not to bite off more than we can chew. We still have a lot of CMF skin scripts and templates in Plone that I don't want to become a blocker for adopting Zope 4. This should be the first of several releases that progressively rationalise our software stack, lets not try and do it all at once.
Absolutely. Getting rid of CMFSkins is a part of getting rid of CMF, not a part of moving to Zope 4. Different issues. But I do think that whatever skin concept Zope 4 has, should be one that can also be used by Plone. Until we get rid of CMF we have to have at least two skin concepts, and that's one to many. Having a third one is no good. If, as Tres say, ++skins++ is overworked and overcomplicated, could we extend plone.browserlayers to have a traverser or something? //Lennart
Hi Lennart, I'm not sure if you're not mixing different issues here. Am 17.11.2011, 11:35 Uhr, schrieb Lennart Regebro <regebro@gmail.com>:
Absolutely. Getting rid of CMFSkins is a part of getting rid of CMF, not a part of moving to Zope 4. Different issues.
I assume you are referring to removing Plone's dependencies on CMF. That is not relevant to the discussion about Zope 4 / ZMI reimagined. Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Kronenstr. 27a Düsseldorf D- 40217 Tel: +49-211-600-3657 Mobile: +49-178-782-6226
On Thu, Nov 17, 2011 at 11:52, Charlie Clark <charlie.clark@clark-consulting.eu> wrote:
Hi Lennart,
I'm not sure if you're not mixing different issues here.
Am 17.11.2011, 11:35 Uhr, schrieb Lennart Regebro <regebro@gmail.com>:
Absolutely. Getting rid of CMFSkins is a part of getting rid of CMF, not a part of moving to Zope 4. Different issues.
I assume you are referring to removing Plone's dependencies on CMF. That is not relevant to the discussion about Zope 4 / ZMI reimagined.
Which is exactly what I said above. //Lennart
On 11/16/2011 11:30 AM, Christian Theune wrote:
Hi,
I'd like to revert the removal of the ++skin++ traverser in Zope 4.
As we're working on a replacement ZMI at a sprint currently (more details about that in a bit) we'd like to leverage this feature.
From my perspective, I value that Zope 2/4 has always made some choices upfront that one could leverage right away. Especially as multiple orthogonal components (like: your application and the ZMI) need to leverage this plugin point, I'd rather have this provided by the framework.
I couldn't find an argument anywhere why ++skin++ should be gone.
I'm interpreting the thread overall as an OK to revive the ++skin++ traverser. Thanks, Christian -- Christian Theune · ct@gocept.com gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 0 · fax +49 345 1229889 1 Zope and Plone consulting, development, hosting, operations
Op 16 nov 2011, om 11:30 heeft Christian Theune het volgende geschreven:
Hi,
Hello,
I'd like to revert the removal of the ++skin++ traverser in Zope 4.
As we're working on a replacement ZMI at a sprint currently (more details about that in a bit) we'd like to leverage this feature.
From my perspective, I value that Zope 2/4 has always made some choices upfront that one could leverage right away. Especially as multiple orthogonal components (like: your application and the ZMI) need to leverage this plugin point, I'd rather have this provided by the framework.
I couldn't find an argument anywhere why ++skin++ should be gone.
I like ++skin++, and used it. If it is gone it is not a big issue as it is not really difficult to rebuild. There was an issue, due to the perfect implementation of shiftNameToApplication in HTTPRequest.py, it never really worked with the URL computation. However, you could force it in a VirtualHost rewrite rule. Regards, Sylvain, -- Sylvain Viollon -- Infrae t +31 10 243 7051 -- http://infrae.com Hoevestraat 10 3033GC Rotterdam -- The Netherlands
participants (7)
-
Charlie Clark -
Christian Theune -
Laurence Rowe -
Lennart Regebro -
Martin Aspeli -
Sylvain Viollon -
Tres Seaver