Re: [Zope-dev] fanstatic and preprocessors
Hi Wolfgang, On 15 April 2011 07:13, Wolfgang Schnerring w...@gocept.com wrote: Hi, is this the right place to ask stuff about fanstatic? Fanstatic lives at fanstatic.org , the mailing list at fansta...@googlegroups.com . Let's continue this discussion there. Unfortunately I haven't had the opportunity to have a proper look at fanstatic (yet!), but I've just been reading about SASS and CoffeeScript, which are preprocessors/compilers for CSS and JavaScript. So I wondered whether it is within fanstatic's scope that one could feasibly write a plugin to support something like this. Something like, I drop a foo.coffee file somewhere and it would be run through the CoffeeScript compiler, probably cached, and served to clients as foo.js. (This thought has been triggered by what Rails is doing right now[1] which is powered by their equivalent resource manager[2].) Wolfgang [1] http://www.rubyinside.com/rails-3-1-adopts-coffeescript-jquery-sass-and-controversy-4669.html [2] https://github.com/sstephenson/sprockets Supporting pre-processed resources is definitely on the fanstatic roadmap. I am working on pluggable support for javascript resources (CoffeeScript, Google Closure Compiler, ...) and CSS (SASS, LessCSS, ...). Cheers, -- Jan-Jaap Driessen ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] CatalogPathAwareness and zope.lifecycle
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello Zope Developers, I've asked about this on the zope@ list, without getting any replies. Talking about it in #zope, I decided that maybe I will have to ask here from another point of view. As I was testing moving a big, old application to Zope 2.13, I was greeted with the following error: (...) from Products.ZCatalog.CatalogPathAwareness import CatalogPathAware ImportError: cannot import name CatalogPathAware Looking at the code informs me that CatalogPathAwareness is deprecated. I since noticed that apart from the depreciation, also the emtpy class CatalogPathAware(CatalogAware) has been removed from CatalogPathAwareness.py. The depreciation message points to zope.lifecycleevent. Looking at http://pypi.python.org/pypi/zope.lifecycleevent I see some examples about calling those notify() events, but nothing that would tell me how to replace CatalogPathAware with this stuff. Googling for [CatalogPathAware zope.lifecycleevent] does not give me anything besides some SVN commit messages. So, anybody have some examples of doing this, please? Specifically an example for replacing CatalogPathAware with zope.lifecycleevent. Since this is what the depreciation message talks about, it's been done many times over and should be well documented, right? I also hope that developers are aware that this change involves changing the base classes that classes in production systems out there are based on. I assume this kind of thing has been discussed and the decision has been taken on judging backwards compatibility vs. the benefits of doing this? (Personally I don't know those benefits, but I'm open to learn. I'm also open to help if there is any work involved, I'm planning to give back more to the zope community in the near future.) Thank you very much, Regards, Sascha -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (Darwin) iD8DBQFNqBeEpYOq9ODq/IoRAr8UAKCmziFbjoJ/rD+jOqycMnzyCjrPngCfQFoP UOqcNboJ0XMuX3z9sBM6z2o= =3aWj -END PGP SIGNATURE- ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] CatalogPathAwareness and zope.lifecycle
On Fri, Apr 15, 2011 at 12:05 PM, Sascha Welter zopel...@betabug.ch wrote: Looking at http://pypi.python.org/pypi/zope.lifecycleevent I see some examples about calling those notify() events, but nothing that would tell me how to replace CatalogPathAware with this stuff. Googling for [CatalogPathAware zope.lifecycleevent] does not give me anything besides some SVN commit messages. So, anybody have some examples of doing this, please? I don't think there's any examples. Documentation for developing with current Zope 2 is virtually non-existant. Specifically an example for replacing CatalogPathAware with zope.lifecycleevent. Since this is what the depreciation message talks about, it's been done many times over and should be well documented, right? The last piece of documentation I know of is http://codespeak.net/z3/five/event.html. It's from several years back now and was written when object events where first introduced. The general principle should still be the same, even if the details of import locations have changed. I also hope that developers are aware that this change involves changing the base classes that classes in production systems out there are based on. Changing base classes isn't any problem. The only thing that is persisted is the actual class of an instance. The base classes are taken from the current code base, so you can change them to whatever you like without any content migration. I assume this kind of thing has been discussed and the decision has been taken on judging backwards compatibility vs. the benefits of doing this? The particular code was unused for several years, using manage_* methods is deprecated since Zope 2.8 or 2.9. If you really need this code, just copy it from an old release into your own codebase. Developing with Zope 2 is probably a frustrating experience, but that shouldn't come as a surprise to anyone. The project is dead for several years now and is only kept left alive while Plone is migrating away from it or some long time developers are still using it. It's a large piece of legacy code that has no future - certainly not for new users or developers not already familiar with it. Hanno ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] CatalogPathAwareness and zope.lifecycle
On Friday 15 April 2011, Hanno Schlichting wrote: I don't think there's any examples. Documentation for developing with current Zope 2 is virtually non-existant. How are people expected to upgrade to new code that replaces the old functionality if there is no documentation for it? What is the justification for removing the old code if there is no real viable upgrade path? Is the old code causing problems? I assume this kind of thing has been discussed and the decision has been taken on judging backwards compatibility vs. the benefits of doing this? The particular code was unused for several years, using manage_* methods is deprecated since Zope 2.8 or 2.9. It may have been marked as deprecated for a long time but no actual docs on what to switch to or how to do it instead so that is not really an upgrade path. If you really need this code, just copy it from an old release into your own codebase. Developing with Zope 2 is probably a frustrating experience, but that shouldn't come as a surprise to anyone. The project is dead for several years now and is only kept left alive while Plone is migrating away from it or some long time developers are still using it. It's a large piece of legacy code that has no future - certainly not for new users or developers not already familiar with it. Zope 2.x is only recently been a frustrating experience with features being removed or changed. However even with all of that zope is pretty much one the most reliable and flexible system I can think of. Zope 2.x is still very easy to plug things into and acquisition and traversal are massively powerful. There still don't seem to be any other frameworks that actually take security remotely seriously. So what is the future of zope 2.x? Is any feature that plone does not use to be removed with no documentation until plone no longer needs zope 2.x and then zope 2.x will just be discarded? What about developers who build on zope 2.x and use it very successfully, what should they switch to? Zope 2.13 represented a pretty major upgrade for zope users. Threaded zeo was a huge improvement. I have done a lot of testing recently against relstorage running postgres and memcached vs 2.13 zeo and even under 1000 concurrent connections zeo was faster, more reliable and used less memory. It just seems that there is a real effort to make zope 2.x hostile for people to continue to use. Like we are not wanted and should just move to something else. Zope 2.x is still an amazing product and with some work I believe it could be a major player again since it can still do many extremely useful things that other frameworks can not even approach. If someone did migrate to plone will that be a stable development target with documentation on how to handle upgrades when features are deprecated? Will plone keep the security system of zope 2.x or something like it? Is plone open to changes to speed up usage of the system? ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] zope-tests - FAILED: 8, OK: 77
This is the summary for test reports received on the zope-tests list between 2011-04-14 00:00:00 UTC and 2011-04-15 00:00:00 UTC: See the footnotes for test reports of unsuccessful builds. An up-to date view of the builders is also available in our buildbot documentation: http://docs.zope.org/zopetoolkit/process/buildbots.html#the-nightly-builds Reports received ZTK 1.0 / Python2.4.6 Linux 64bit ZTK 1.0 / Python2.5.5 Linux 64bit ZTK 1.0 / Python2.6.5 Linux 64bit ZTK 1.0dev / Python2.4.6 Linux 64bit ZTK 1.0dev / Python2.5.5 Linux 64bit ZTK 1.0dev / Python2.6.5 Linux 64bit Zope 3.4 KGS / Python2.4.6 64bit linux Zope 3.4 KGS / Python2.5.5 64bit linux Zope 3.4 Known Good Set / py2.4-32bit-linux Zope 3.4 Known Good Set / py2.4-64bit-linux Zope 3.4 Known Good Set / py2.5-32bit-linux Zope 3.4 Known Good Set / py2.5-64bit-linux Zope Buildbot / zope2.12-py2.6 slave-osx Zope Buildbot / zope2.12-py2.6 slave-ubuntu32 Zope Buildbot / zope2.12-py2.6 slave-ubuntu64 Zope Buildbot / zope2.12-py2.6 slave-ubuntu64 Zope Buildbot / zope2.13-py2.6 slave-osx Zope Buildbot / zope2.13-py2.6 slave-ubuntu32 Zope Buildbot / zope2.13-py2.6 slave-ubuntu64 Zope Buildbot / zope2.13-py2.6 slave-ubuntu64 Zope Buildbot / zope2.13-py2.7 slave-osx Zope Buildbot / zope2.13-py2.7 slave-ubuntu32 Zope Buildbot / zope2.13-py2.7 slave-ubuntu64 Zope Buildbot / zope2.13-py2.7 slave-ubuntu64 Zope Buildbot / zope2.14-py2.6 slave-osx Zope Buildbot / zope2.14-py2.6 slave-ubuntu32 Zope Buildbot / zope2.14-py2.6 slave-ubuntu64 Zope Buildbot / zope2.14-py2.6 slave-ubuntu64 Zope Buildbot / zope2.14-py2.7 slave-osx Zope Buildbot / zope2.14-py2.7 slave-ubuntu32 Zope Buildbot / zope2.14-py2.7 slave-ubuntu64 Zope Buildbot / zope2.14-py2.7 slave-ubuntu64 Zope Buildbot / zopetoolkit-1.0-py2.4 slave-osx Zope Buildbot / zopetoolkit-1.0-py2.4 slave-ubuntu32 Zope Buildbot / zopetoolkit-1.0-py2.4 slave-ubuntu64 Zope Buildbot / zopetoolkit-1.0-py2.4 slave-ubuntu64 Zope Buildbot / zopetoolkit-1.0-py2.5 slave-osx Zope Buildbot / zopetoolkit-1.0-py2.5 slave-ubuntu32 Zope Buildbot / zopetoolkit-1.0-py2.5 slave-ubuntu64 Zope Buildbot / zopetoolkit-1.0-py2.6 slave-osx Zope Buildbot / zopetoolkit-1.0-py2.6 slave-ubuntu32 Zope Buildbot / zopetoolkit-1.0-py2.6 slave-ubuntu64 Zope Buildbot / zopetoolkit-1.1-py2.5 slave-osx Zope Buildbot / zopetoolkit-1.1-py2.5 slave-ubuntu32 Zope Buildbot / zopetoolkit-1.1-py2.5 slave-ubuntu64 Zope Buildbot / zopetoolkit-1.1-py2.6 slave-osx Zope Buildbot / zopetoolkit-1.1-py2.6 slave-ubuntu32 Zope Buildbot / zopetoolkit-1.1-py2.6 slave-ubuntu64 Zope Buildbot / zopetoolkit-py2.5 slave-osx Zope Buildbot / zopetoolkit-py2.5 slave-ubuntu32 Zope Buildbot / zopetoolkit-py2.5 slave-ubuntu64 Zope Buildbot / zopetoolkit-py2.6 slave-osx Zope Buildbot / zopetoolkit-py2.6 slave-ubuntu32 [1]Zope Buildbot / zopetoolkit-py2.6 slave-ubuntu64 Zope-2.10 Python-2.4.6 : Linux Zope-2.11 Python-2.4.6 : Linux Zope-2.12 Python-2.6.5 : Linux Zope-2.12-alltests Python-2.6.5 : Linux Zope-2.13 Python-2.6.5 : Linux Zope-2.13-alltests Python-2.6.5 : Linux Zope-trunk Python-2.6.5 : Linux Zope-trunk-alltests Python-2.6.5 : Linux winbot / ZODB_dev py_254_win32 winbot / ZODB_dev py_265_win32 winbot / ZODB_dev py_265_win64 winbot / ZODB_dev py_270_win32 winbot / ZODB_dev py_270_win64 [2]winbot / z3c.coverage_py_265_32 [3]winbot / z3c.rml_py_265_32 [4]winbot / zc_buildout_dev py_254_win32 [5]winbot / zc_buildout_dev py_265_win32 [6]winbot / zc_buildout_dev py_265_win64 [7]winbot / zc_buildout_dev py_270_win32 [8]winbot / zc_buildout_dev py_270_win64 winbot / ztk_10 py_254_win32 winbot / ztk_10 py_265_win32 winbot / ztk_10 py_265_win64 winbot / ztk_11 py_254_win32 winbot / ztk_11 py_265_win32 winbot / ztk_11 py_265_win64 winbot / ztk_dev py_254_win32 winbot / ztk_dev py_265_win32 winbot / ztk_dev py_265_win64 winbot / ztk_dev py_270_win32 winbot / ztk_dev py_270_win64 Non-OK results -- [1]FAILED Zope Buildbot / zopetoolkit-py2.6 slave-ubuntu64 https://mail.zope.org/pipermail/zope-tests/2011-April/038158.html [2]FAILED winbot / z3c.coverage_py_265_32 https://mail.zope.org/pipermail/zope-tests/2011-April/038166.html [3]FAILED winbot / z3c.rml_py_265_32 https://mail.zope.org/pipermail/zope-tests/2011-April/038160.html [4]FAILED winbot / zc_buildout_dev py_254_win32 https://mail.zope.org/pipermail/zope-tests/2011-April/038208.html
