Re: [Zope3-dev] RE: [SpringCleaning07]
On Wednesday 20 December 2006 16:03, Jeff Shell wrote: Another side topic: even after cleaning out all deprecation warnings in our code to make it run under Zope 3.3, I still get deprecation messages bubbling up from the ZODB, claiming to come from ZODB's broken.py. It dawned on me just yesterday that there are probably references to the deprecated/moved modules in our ZODB databases. Yes, that could be it. For FileStorage, I have used the following pattern as part of a generations script: http://source.schooltool.org/viewcvs/trunk/schooltool/src/schooltool/generations/evolve5.py?rev=6312view=auto Of course, you would want to pack your database after that. I don't want Zope 3.5 to roll around and have our databases blow up because of permanent removal of the old 'zope.app' packages that have been moved to 'zope.*'. Is this a legitimate fear? Is there something we can do to repair these references? I don't know if zope.modulealias supports that or not. No, part of your migration from version to version is providing generation scripts. The Zope App server is responsible for updating its own classes/types, but you have to do it for your code. If the app server is not totally clean in updating, please let us know, since it is a bug. Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RE: [SpringCleaning07]
On Wednesday 20 December 2006 16:03, Jeff Shell wrote: zope.app.file -1, I use it all the time in combination with zope.app.image to have quick file support. This is acceptable, if you do not plan to store thousands of large documents. BTW, I would welcome a conversion to use blobs. Also -1. We use zope.app.file quite a bit ourselves, for better or worse. I haven't seen any plausible alternatives. BTW: In my 3.3 release, I don't see 'zope.app.image', but I do see 'zope.app.file.image'. Is that what you meant? Or is there a 'zope.app.image' package that hasn't been included in the distribution? There is zope.app.image; I think it is a distribution bug for not having it in the release. Since I always use a checkout, I do not notice things like that. I believe that storing binary data in the ZODB - especially in content management situations - is of high interest to many. Doing it well, however, is the hard part. I think that the main Zope distribution should definitely provide helpful base classes and/or tools for storing and reading the data efficiently and easily. The current 'zope.app.file' code feels a bit scattered. Also important is good HTTP support for binary data. Additional Request / Response support for cache headers, 'If-Modified-Since', etc. There has been some work in this area and it works well. See z3c.file. Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RE: [SpringCleaning07]
On Wednesday 20 December 2006 16:03, Jeff Shell wrote: On the other end of the spectrum is Django, whose admin screens are actually usable by other humans and very very easy to customize. How easy is it in Zope 3 to customize a folder contents view so that it shows different columns, allows sorting only on certain ones, and allows quick searching, grouping, and filtering? I know (or assume) that 'zc.table' can provide for this functionality, but it's nowhere near the core. As a developer, doing custom 'listing' or index pages is something I need to do all of the time. 'title', 'size', and 'modified' aren't interesting to me in a folder full of invoices. Right, the contents view of the container is very static. The problem here is that noone wants to touch the existing skins for a multitude of reason. My main reason is that I am not using the UI patterns anymore, so I have either the choice of rewriting all management screens or deal with the old stuff. I would be interested to know if anyone has succesfully used the TTW ZPT Page and SQL Scripts or SQL Exprs to make a usable application. Me too. But I doubt that anyone uses them in production. They are just too limited. I think TTW would only become interesting, if you could develop components in the UI. I had started this work a while ago at z3c.webdev but decided I want to concentrate on other areas. Approaches like z3c.baseregistry are much more promising and I have built a very simple plugin system (took about 4 hours) on top of it. Those never seemed to be the focus of Zope 3, and with the lack of auto-acquisition and Python scripts, they felt extremely crippled compared to their Zope 2 cousins. I certainly could never get them to do anything useful, because I had no answers about what objects/namespaces/modules/etc I could even access. All of the things that were easy in Zope 2's TTW environment didn't seem doable in Zope 3's. But that's OK, as custom Python / product / etc development is much easier. I'd rather see the elevation and inclusion of tools like 'zc.table' and 'zc.resourcelibrary' which can be useful across so many application domains and could solve some very common problems. I think that once Zope 3 is eggified, we will have two Zope 3 default installation options; a bare bones one and one with batteries included. I could also imagine taking the plugin concept a bit further and have something similar to the Plone add-on installer. We can do a lot here. And if we want to give casual newcomers something to look at, lets focus on how Instance Homes and Products/Applications are used and can be built. Perhaps give templated starting points like paster does:: $ paster create --template=zope3product easytodo Note that ArchGenXML's new implementation is a generic system now that can be used for Zope 3 packages. I think Jens wants to work on it during the Snow Sprint again. The Zope 3 experience does nothing to start the casual newcomer towards building a simple starter application. Both Pylons and TurboGears have a 'quick wiki' tutorial which includes a line similar to the one above. Unlike 'mkzopeinstance', the generated directories and files reflect a working product with some starter modules, classes, and templates: the equivalent of 'BoringProduct', in a sense, but with some skeleton parts (class names, etc) filled in instead of having to be manually replaced. Yes, I think there is a lot of oppurtunity for us here. But note that I also think that Zope 3 has been taught and introduced incorrectly in the past years. I have started a training outline that takes a vastly different approach. See the attached file. I have taught the training once this way, and it worked out great! The reason it works so well is because it concentrates on the following three goals: 1. Early success by creating something visual first. This is a well-known technique in pretty much any field, but we have been neglecting this in Zope 3. Writing a content type and checking it out in Python just does not cut it. It's too boring for the non-hardcore Python developer which cannot appreciate the machinery behind it. 2. Introduce fundamental concepts later. I have tried very hard to introduce a minimal set of concepts for each session. I have managed to not introduce components (including adapters and utilities) until the third day. (BTW, this is one of the reasons that we need high-level ZCML directives.) I have found that I lost a good set of students when introducing components; this is not surprising, since many of them did not have a solid Python foundation or formal CS education. 3. Teach what they need. The way the training is structured is the way people are integrated as developers at Lovely Systems. A junior/new programmer will not start by developing content types, adapters and other business logic, but write view-related code, in Lovely's case ZPT-templating, viewlets, pages,
Re: [Zope3-dev] Re: [SpringCleaning07]
Martijn Faassen wrote: Myghthy) spending time optimizing it, etc. It's close enough to ZPT to be palatable to me, and has some nice features for reuse. I've really grown to hate attribute-based languages over the years. Macros in ZPT now make me cry. If we're going to get out of the server business we could also consider getting out of the template language business. :) Well, as someone who's got myself firmly into the template language business, I'd agree. That said, I'm pretty passionate about Twiddler. It's now feature complete and if people can give me metrics showing that it's slow or has bugs, I'll be pretty eager to fix them. cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: [SpringCleaning07]
Previously Jeff Shell wrote: If TAL / Page Templates isn't really made available to anyone else, how could it get momentum? 'zope.tal', 'zope.tales' and 'zope.pagetemplate' could probably be combined into a nice world-usable egg. With the right extras and entry points, they could be used with Buffet and then available to TurboGears, Pylons, web.py, whatever. There is a growing number of projects that use SimpleTAL. Wichert. -- Wichert Akkerman [EMAIL PROTECTED]It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: [SpringCleaning07]
Martijn Faassen wrote: http://genshi.edgewall.org Inspired by Kid (in turn among others inspired by ZPT), the main template language of TurboGears, written by the people who also created Trac, and it seems to be getting traction. TurboGears among others is going to adopt it, but also things like the creator of SQLAlchemy (and Myghthy) spending time optimizing it, etc. It's close enough to ZPT to be palatable to me, and has some nice features for reuse. If we're going to get out of the server business we could also consider getting out of the template language business. :) Martijn I'm a big fan of using lxml.etree for templating. Very pythonic, very easy to refactor, very explicit. It's premature to announce (we plan to have eggs on pypi soon) , but take a look at zif.xtemplate at zif.sourceforge.net . It's pretty alpha at the moment, but it uses a DTD and some xpath to get around the tags that shouldn't be minimized issue, and it includes a first stab at an HTML sanitizer, to use when snippets of untrusted HTML are to be included on a page. In addition, the entire page DOM is available for postprocessing right up until serialization. Of course, those with better lxml knowledge are encouraged to point out issues with the implementation. -Jim Washington ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
RE: [Zope3-dev] Re: [SpringCleaning07]
Hi Martijn I saw the Grok package but what is Genshi? Can you point me to a link? http://genshi.edgewall.org Inspired by Kid (in turn among others inspired by ZPT), the main template language of TurboGears, written by the people who also created Trac, and it seems to be getting traction. TurboGears among others is going to adopt it, but also things like the creator of SQLAlchemy (and Myghthy) spending time optimizing it, etc. It's close enough to ZPT to be palatable to me, and has some nice features for reuse. If we're going to get out of the server business we could also consider getting out of the template language business. :) Looks great in a first overview. Let me know if you or somebody else starts to port it to z3. I'm interessted to using another template language in z3 too. Thanks for the hint Roger Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
RE: [Zope3-dev] Re: [SpringCleaning07]
Hi Jim, It's premature to announce (we plan to have eggs on pypi soon) , but take a look at zif.xtemplate at zif.sourceforge.net . It's pretty alpha at the moment, but it uses a DTD and some xpath to get around the tags that shouldn't be minimized issue, and it includes a first stab at an HTML sanitizer, to use when snippets of untrusted HTML are to be included on a page. In addition, the entire page DOM is available for postprocessing right up until serialization. Of course, those with better lxml knowledge are encouraged to point out issues with the implementation. What's up with jsonserver? Did you move the package to a new repository? Can you offer a mailinglist for the zif packages? I'm very interested in observing the state of jsonserver since we use it most projects. Can you give a short statement about the zif and jsonserver repo? Regards Roger Ineichen -Jim Washington ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/dev%40projekt01.ch ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: [SpringCleaning07]
Roger Ineichen wrote: Hi Jim, It's premature to announce (we plan to have eggs on pypi soon) , but take a look at zif.xtemplate at zif.sourceforge.net . It's pretty alpha at the moment, but it uses a DTD and some xpath to get around the tags that shouldn't be minimized issue, and it includes a first stab at an HTML sanitizer, to use when snippets of untrusted HTML are to be included on a page. In addition, the entire page DOM is available for postprocessing right up until serialization. Of course, those with better lxml knowledge are encouraged to point out issues with the implementation. What's up with jsonserver? Did you move the package to a new repository? Can you offer a mailinglist for the zif packages? I'm very interested in observing the state of jsonserver since we use it most projects. Can you give a short statement about the zif and jsonserver repo? Hi, Roger There has been interest in a namespace for the packages I have been offering. And a public repository. And eggs. David Pratt and I have been working on this on sourceforge for less than a week, so I was definitely a bit premature in pointng anyone to the SourceForge site. Unfortunately, I just could not help saying something about xtemplate while templating was being discussed here. So, a short statement about zif and jsonserver: zif.jsonserver on sourceforge is the same as jsonserver on codespeak, except for a bit of an update for a zif namespace. There will be some kind of announcement after we are satisfied with an upcoming release. Additional contributors will, of course, be welcome. Roger, I acknowledge your interest in a mailing list. I think it would be a good idea, though I am a bit hesitant ATM to start YAFML. I think it may be just a matter of throwing a switch on SF, so it is certainly doable. For the moment, the Zif Collective is all alpha and experimental on SourceForge. Nothing released. Nothing to be alarmed about. Nothing decided about other repositories. -Jim Washington ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
RE: [Zope3-dev] Re: [SpringCleaning07]
Hi Jim, Subject: Re: [Zope3-dev] Re: [SpringCleaning07] What's up with jsonserver? [...] Hi, Roger [...] For the moment, the Zif Collective is all alpha and experimental on SourceForge. Nothing released. Nothing to be alarmed about. Nothing decided about other repositories. That's ok for me. Just keep it going and tell us if you have more such nice packages like jsonserver. Regards Roger Ineichen -Jim Washington ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: [SpringCleaning07]
On 12/20/06, Tres Seaver [EMAIL PROTECTED] wrote: I'm actually -1 on getting out of the server business as well, at least in terms of the Zope2 ZServer: I don't see it as requiring much maintenance, and there *are* folks in the community (I can think of five or six, at least) who know Medusa / ZServer well enough to go forward. From looking at the ZServer from Zope 3, I had the impression that it had significant improvements over the version from Zope 2, in that it's not so much of a complete rewrite than it's a cleanup/reorg. The few issues I have with the Zope 2 ZServer could be easily fixed by someone with a bit of time and Medusa knowledge. They are mainly due to the fact that handling 'streams' and 'gzip compression' are done inside the ZServer with some not so nice workarounds, instead of using the producers that medusa provides which would simplify ZServer a lot. The impression I had was that the person that added streaming and gzip did not know about the medusa producers. -- Sidnei da Silva Enfold Systemshttp://enfoldsystems.com Fax +1 832 201 8856 Office +1 713 942 2377 Ext 214 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RE: [SpringCleaning07]
On 12/19/06, Stephan Richter [EMAIL PROTECTED] wrote: On Tuesday 19 December 2006 06:16, Roger Ineichen wrote: Here is a list of candidates for removal (please verify!): I'm only commenting on the ones that I use, think have some use, or just have questions about. zope.fssync +1 0 It's too bad that this seems to have gone unfinished. The biggest pain (well, one of the big pains) we experience with Zope 3 is the lack of anything like Zope 2's export/import. Or, going further back, 'manage_exportHack'. :). This is a side topic and I'm not going to elaborate further except to beg for some low to medium level export/import capability. It seems that fssync was one of the alternatives, or could be, if I recall correctly. zope.modulealias +1, though I might think some people still use it. So we have to be careful. 0 Another side topic: even after cleaning out all deprecation warnings in our code to make it run under Zope 3.3, I still get deprecation messages bubbling up from the ZODB, claiming to come from ZODB's broken.py. It dawned on me just yesterday that there are probably references to the deprecated/moved modules in our ZODB databases. I don't want Zope 3.5 to roll around and have our databases blow up because of permanent removal of the old 'zope.app' packages that have been moved to 'zope.*'. Is this a legitimate fear? Is there something we can do to repair these references? I don't know if zope.modulealias supports that or not. zope.app.file -1, I use it all the time in combination with zope.app.image to have quick file support. This is acceptable, if you do not plan to store thousands of large documents. BTW, I would welcome a conversion to use blobs. Also -1. We use zope.app.file quite a bit ourselves, for better or worse. I haven't seen any plausible alternatives. BTW: In my 3.3 release, I don't see 'zope.app.image', but I do see 'zope.app.file.image'. Is that what you meant? Or is there a 'zope.app.image' package that hasn't been included in the distribution? I believe that storing binary data in the ZODB - especially in content management situations - is of high interest to many. Doing it well, however, is the hard part. I think that the main Zope distribution should definitely provide helpful base classes and/or tools for storing and reading the data efficiently and easily. The current 'zope.app.file' code feels a bit scattered. Also important is good HTTP support for binary data. Additional Request / Response support for cache headers, 'If-Modified-Since', etc. - zope.app.sqlscript This package has for me the same importance as zope.app.dtmlpage and zope.app.zptpage. It contains some nice code that shows how to use RDB connections correctly, but I doubt that anyone is seriously using them. SQLObject and ZAlchemy are just better options. I would leave it in the repository, but remove it from the core tree. 0 We use this, but in a strange way. We don't use sqlscript's like these in the ZODB, but use them on some classes, ala:: from zope.app.sqlscript.sqlscript import SQLScript class ECards(...): sql_search = SQLScript( CONNECTION_NAME, SELECT * FROM ecard WHERE dtml-sqltest ecard_id column=ecard_id op=eq type=string , 'ecard_id' ) But I want to move this code to our SQLAlchemy based system anyways. So, sqlscript could go and I wouldn't shed many tears. - zope.app.undo Is anyone using this? I am certainly not. I think it can be removed. Phllip, you put a lot of work into it, what do you think? However, I think the code has a place in the repository, though there it runs in danger of quickly being outdated. -1 We depend on it. We don't use any of the UI pieces that are in it, but we do use the IUndoManager utility. I think that having fairly easy access to 'undo' is important: it's one of the distinguishing features of the ZODB. We use it to provide an undo last feature. Deleted 'foo' (undo) (with 'undo' being a link), like you get with GMail. Heck, this could be a good pitch point or article for Zope development. Ever wanted to do an easy-undo feature like you see in GMail? With the ZODB, FileStorage, and the Undo Manager utility, it's easy! Without a suitable replacement utility or set of tools for finding / undoing historical transactions, I'm against losing this. - zope.app.renderer You can safely remove it from the base tree. It was not such a big success as I was hoping for. Other approaches are easier. Note that wiki and bugtracker still use this code, so it should be still available for those packages. -1 We use this *quite* heavily, with Textile and Markdown renderers in place as well. Many of our CMS customers are using this (although I hope to move them to HTML w/ TinyMCE or Kupu if I can ever get Kupu to actually do something useful). Our Knowledge Base application also uses zope.app.renderer. It's been invaluable to be
Re: [Zope3-dev] Re: [SpringCleaning07]
On 12/20/06, Martijn Faassen [EMAIL PROTECTED] wrote:
Rocky Burt wrote:
On Wed, 2006-20-12 at 12:52 +0100, Martijn Faassen wrote:
http://genshi.edgewall.org
Inspired by Kid (in turn among others inspired by ZPT), the main
template language of TurboGears, written by the people who also created
Trac, and it seems to be getting traction. TurboGears among others is
going to adopt it, but also things like the creator of SQLAlchemy (and
Myghthy) spending time optimizing it, etc. It's close enough to ZPT to
be palatable to me, and has some nice features for reuse.
I both like and dislike ZPT and other such languages these days.
They're great when working on some design-heavy sites. But in other
situations, it's an awful lot of useless typing and structuring.
It matters to me especially when we're talking about reuse. Template
languages differ significantly in their approach. I also prefer to pick
something that has a certain momentum and a certain performance.
If TAL / Page Templates isn't really made available to anyone else,
how could it get momentum? 'zope.tal', 'zope.tales' and
'zope.pagetemplate' could probably be combined into a nice
world-usable egg. With the right extras and entry points, they could
be used with Buffet and then available to TurboGears, Pylons, web.py,
whatever.
Performance is also a strange game, as template languages differ
significantly in how (or even if) they compile, and how/where they
store that compiled manifestation.
Pylons uses Buffet, or at least a customized version of Buffet,
alongside 'Beaker'. 'Beaker' is a WSGI middleware thing that uses
Myghty's containers (which I guess basically make up the heart of
Myghty's supposedly powerful caching system) to cache templates,
fragments, all in a template-language-neutral way apparently. It would
be nice to be able to use things like that with Zope. Keep TAL, allow
for use of Buffet or something like it (perhaps something using the
same entry point) so that any other supported template language could
be plugged in.
http://projects.dowski.com/projects/buffet
http://pylonshq.com/project/pylonshq/browser/Pylons/trunk/pylons/templating.py
As a side topic, I'm also slowly coming to the conclusion that tales
path expressions are a waste of time and effort. We spent a lot of time
making sure that we can express something as a path expression, and a
Python expression would be just as easy to read and explain. We're not
stopping people from writing more complicated python expressions anyway,
and there are real cases where they're needed. A very different
templating mechanism where there is no Python at all and data is always
pregenerated before rendering is still attractive for other reasons, but
in the ZPT case I've become less and less convinced it's worth the hassle.
The nice thing then about something like Genshi is that instead of:
python:foo.bar
I can simply write:
foo.bar
Python expressions in TAL are cumbersome in part because they're simply
hard to type, not because they're necessarily *complicated*.
It's not TAL's fault - path expressions are just configured to be the
default for the engine used by Page Templates.
It should certainly possible to set Python Expressions as the default
for your ZPT Page Templates. I did a simple-stupid string template
language that basically looked for the following pattern::
{{ expr }}
and ran the TALES expression inside. For that setup, I set Python
expressions to be the default. This was used for generating emails,
etc. Kindof a slightly fancy mail merge::
Dear {{customer.name or 'customer'}},
But I could use string, path, whatever as well.
Doesn't Genshi allow for {{ expr }} type things in its templates? Or
was that Kid? Anyways, I hate having to type a whole bunch of TAL to
generate a fake tag and all of that to do a simple insertion in cases
where I could really do without that overhead::
strongFeatured?/strong
tal:insert content=structure view/featuredFlag /br /
'view/featuredFlag' renders lots of fancy HTML on its own, so I don't
need a span or div or anything right there.
--
Jeff Shell
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: [SpringCleaning07]
On 12/20/06, Jeff Shell [EMAIL PROTECTED] wrote: If TAL / Page Templates isn't really made available to anyone else, how could it get momentum? 'zope.tal', 'zope.tales' and 'zope.pagetemplate' could probably be combined into a nice world-usable egg. zope.pagetemplate is used in JOTWeb: http://jotweb.tummy.com/ I'm sure there are others using zope.pagetemplate friends. -Fred -- Fred L. Drake, Jr.fdrake at gmail.com Every sin is the result of a collaboration. --Lucius Annaeus Seneca ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RE: [SpringCleaning07]
On 12/19/06, Roger Ineichen [EMAIL PROTECTED] wrote: Hi Baiju Subject: [SpringCleaning07] Here is a list of candidates for removal (please verify!): zope.dependencytool zope.fssync zope.importtool zope.modulealias zope.sequencesort zope.wfmc zope.xmlpickle zope.app.dtmlpage zope.app.file zope.app.fssync zope.app.zptpage -- What does removal mean? IMO, the proposal (http://wiki.zope.org/zope3/SpringCleaning07) can elaborate on that. Anyway, a package selected for spring cleanup can be changed it's location in svn. For example, zope.fssync is now in the toplevel of subversion. But 'src/zope/fssync' is an svn:externals to svn://svn.zope.org/repos/main/Zope3/trunk/src/zope/fssync. Now fssync source can be moved to this location, after removing svn:externals. But some packages are not yet added to toplevel of svn, it can be added as part of eggification. Regards, Baiju M ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RE: [SpringCleaning07]
Hi, Roger Ineichen wrote: What does removal mean? We have two possible situations for a package that I'd like to consider during spring cleaning: 1. packages that are in the src/ tree but are not distributed with Zope releases The question is whether those packages are maintained and there is interest to keep them around. If they are not maintained and there is no interest from anybody, we can either put them into a retirement section or just delete them. 2. packages that are distributed but untested/unmaintained/unused Those should eventually not be distributed anymore and maybe have the same destiny as packages from 1. I try to support Jims vision of a smaller core system with this. However, those packages that are currently distributed need to be considered very carefully and require a deprecation cycle. As deprecating things that are used by other people is bad IMHO, we should be very sure that we don't annoy people by doing so. Christian -- gocept gmbh co. kg - forsterstraße 29 - 06112 halle/saale - germany www.gocept.com - [EMAIL PROTECTED] - phone +49 345 122 9889 7 - fax +49 345 122 9889 1 - zope and plone consulting and development signature.asc Description: OpenPGP digital signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
RE: [Zope3-dev] RE: [SpringCleaning07]
Hi Christian, Baiju Subject: Re: [Zope3-dev] RE: [SpringCleaning07] Hi, Roger Ineichen wrote: What does removal mean? We have two possible situations for a package that I'd like to consider during spring cleaning: 1. packages that are in the src/ tree but are not distributed with Zope releases The question is whether those packages are maintained and there is interest to keep them around. If they are not maintained and there is no interest from anybody, we can either put them into a retirement section or just delete them. 2. packages that are distributed but untested/unmaintained/unused Those should eventually not be distributed anymore and maybe have the same destiny as packages from 1. I try to support Jims vision of a smaller core system with this. However, those packages that are currently distributed need to be considered very carefully and require a deprecation cycle. As deprecating things that are used by other people is bad IMHO, we should be very sure that we don't annoy people by doing so. +1 I'm fine with that as long as the zope.app.file is contained in the distribution. Regards Roger Ineichen _ END OF MESSAGE Christian -- gocept gmbh co. kg - forsterstraße 29 - 06112 halle/saale - germany www.gocept.com - [EMAIL PROTECTED] - phone +49 345 122 9889 7 - fax +49 345 122 9889 1 - zope and plone consulting and development ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RE: [SpringCleaning07]
On Tuesday 19 December 2006 06:16, Roger Ineichen wrote: Here is a list of candidates for removal (please verify!): zope.dependencytool -1, it is used by people to find dependencies in their packages. It is not referenced anywhere in the code, because it is a standalone utility. zope.fssync +1 zope.importtool -1, ditto to zope.dependencytool. Finding all the unused imports in a package is very useful and people do this from time to time. Clearly this code is not used anywhere, because it represents a standalone utility. zope.modulealias +1, though I might think some people still use it. So we have to be careful. zope.sequencesort +1 zope.wfmc +1, but please make it very easily available. People do use this code in production; Zope Corp. and Adam Groszer come to mind. zope.xmlpickle +1 zope.app.dtmlpage +1 zope.app.file -1, I use it all the time in combination with zope.app.image to have quick file support. This is acceptable, if you do not plan to store thousands of large documents. BTW, I would welcome a conversion to use blobs. zope.app.fssync +1 zope.app.zptpage +1 I would suggest the following packages in addition to the ones above: - zope.app.i18nfile This package was only a demo early on, but I think we can remove it now. - zope.app.homefolder I know that some people -- particularly Florian Lindner -- are using this package. I think it should be available in the repository, but the use case of a homefolder is very CMS-specific and does not need to be in the base Zope 3. - zope.app.preview I think the template in this package could be merged into another one. - zope.app.recorder I really hope noone is using this old way of doing functional tests anymore. Even if they do, the recorder is not required for running them. - zope.app.schemacontent I really love this package, because it really demonstrates some fascinating aspects of the Zope 3 API. However, it should not be part of the base distribution or be in the source tree. :-\ - zope.app.servicenames While the deprecation warning says Zope 3.5, I really doubt that anyone has still code based on services working with Zope 3.3. That would be a miracle. I suggest you can remove it now. - zope.app.sqlscript This package has for me the same importance as zope.app.dtmlpage and zope.app.zptpage. It contains some nice code that shows how to use RDB connections correctly, but I doubt that anyone is seriously using them. SQLObject and ZAlchemy are just better options. I would leave it in the repository, but remove it from the core tree. - zope.app.zopetop It's dead for a long time. - zope.app.versioncontrol I think better approaches have been provided. As far as I can remember, ZC came out with their own package that fixes several design flaws of this package. - zope.app.undo Is anyone using this? I am certainly not. I think it can be removed. Phllip, you put a lot of work into it, what do you think? However, I think the code has a place in the repository, though there it runs in danger of quickly being outdated. - zope.app.renderer You can safely remove it from the base tree. It was not such a big success as I was hoping for. Other approaches are easier. Note that wiki and bugtracker still use this code, so it should be still available for those packages. - zope.app.sqlexpr A truly simple example of writing new TALES expressions, but nothing that should be any longer in the base tree; however, I would really like to keep it in the repository. This could move into the z3c namespace. - zope.app.demo This is a really tricky one. The point of the package is to collect demonstration code and the point of it living in zope.app is that it will always work. But does it belong here? I do not know. What do others think? - zope.app.styleguide This package contains Zope 3 coding style conventions, but I am not sure it is used as the canonical source for the conventions. I think the Wiki is more central. I know Roger put a lot of time into the package, so maybe we can put the information not contained in the wiki there and then remove the package. -- I'll note that the removal of several of the zope.app.* packages means a further distancing from TTW, offering the casual newscomer even less to look at. I am okay with this direction, but others might object strongly. This should really be brought up on zope3-users or other high-level mailing lists. Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
RE: [Zope3-dev] RE: [SpringCleaning07]
Hi Subject: Re: [Zope3-dev] RE: [SpringCleaning07] - zope.app.demo This is a really tricky one. The point of the package is to collect demonstration code and the point of it living in zope.app is that it will always work. But does it belong here? I do not know. What do others think? I vote for remove this package from the core. - zope.app.styleguide This package contains Zope 3 coding style conventions, but I am not sure it is used as the canonical source for the conventions. I think the Wiki is more central. I know Roger put a lot of time into the package, so maybe we can put the information not contained in the wiki there and then remove the package. I'm fine with removing this package from the distribution and copy the content into a wiki. I'll note that the removal of several of the zope.app.* packages means a further distancing from TTW, offering the casual newscomer even less to look at. I am okay with this direction, but others might object strongly. This should really be brought up on zope3-users or other high-level mailing lists. I think we should find maintainers for every package or a bunch of them and cleanup strictly all other parts. Perhaps this will give us a positive sideeffect in fixing bugs. Perhaps it's realy time that the zope foundation give us a OK to implement the ZSCP process. If we whould have such a process we shouldn't have a problem with unmentained packages in the future. Regards Roger Ineichen Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RE: [SpringCleaning07]
Stephan Richter wrote: - zope.app.renderer You can safely remove it from the base tree. It was not such a big success as I was hoping for. Other approaches are easier. Note that wiki and bugtracker still use this code, so it should be still available for those packages. I believe apidoc uses this package. And having looked at it, I generally like the package itself (and have begun using it in a small project), but if apidoc doesn't really need it, moving it to a separate project in the repo would be fine. -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RE: [SpringCleaning07]
On Tuesday 19 December 2006 09:29, Benji York wrote: Stephan Richter wrote: - zope.app.renderer You can safely remove it from the base tree. It was not such a big success as I was hoping for. Other approaches are easier. Note that wiki and bugtracker still use this code, so it should be still available for those packages. I believe apidoc uses this package. And having looked at it, I generally like the package itself (and have begun using it in a small project), but if apidoc doesn't really need it, moving it to a separate project in the repo would be fine. Now that I know the package has some traction, I am much more motivated to leave it in. :-) /me is happy now. And yes, you are right, I used it in apidoc. Thanks for checking. Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: [SpringCleaning07]
On Tuesday 19 December 2006 10:01, Martijn Faassen wrote: - zope.app.undo Is anyone using this? I am certainly not. I think it can be removed. Phllip, you put a lot of work into it, what do you think? However, I think the code has a place in the repository, though there it runs in danger of quickly being outdated. This isn't used from the ZMI? Yeah, but as far as I could see all ZMI support is part of this package. So if you remove the package, the undo options are simply gone. Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: [SpringCleaning07]
On Tuesday 19 December 2006 10:01, Martijn Faassen wrote: What the ZMI is for needs a rethink; as part of the Grok project we hope to replace it with an admin UI, not a development UI. Yes, Roger and I are doing this too in a couple of our custom projects. But our admin UIs are often focused on the particular problem domain, allowing us to make decisions about menu layout and other UI features that are not possible in the ZMI. Also, we are using UI programming patterns that are not accepted by the entire community yet (macro-free templating, view templates, clear separation of layer and skin, formal UI API specification)[1]. I'll note that Lovely Systems is also using/developing this approach to UI, but do not usually write admin UIs. I have been thinking about replacing the ZMI several times, but there are some issues that cannot be resolved: 1. Zope 3 would need to add some of the additional packages developed for our way of doing UIs. Ideally, the larger community would embrace a new strategy to develop UIs. 2. Backward Compatibility. There is no way that I would want to support old ZMI views, simply because we are not doing macros anymore. This might be a big problem for a range of people. 3. Massive amount of work. Rewriting all the existing UI might be a large effort. On the other hand, if we rethink the ZMI to become an Admin interface, the ZMI could become much smaller and more feasible. Overall, I think the first step would be to agree on a common set of UI patterns. I know that our UI patterns are very formal and an overhead, if you do both, Python view code and templating, but we also have achieved some very old design goals. For exmple, the designer can create templates any way s/he likes, correctly rendering locally, and we only need to add a few TAL and ZRT (for CSS) directives to the files to make it work any way we want to. We were also able to completely decentralize the UI development. [1] Here is a link to a blog entry describing the early patterns: http://www.lovelysystems.com/author/srichter/ Anyhow, I meant to communicate my support for a more specific Admin ZMI and the fact that I have been thinking about those lines already as well. I hope you can forgive my quick sidetrack to UI patterns. :-) Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
RE: [Zope3-dev] Re: [SpringCleaning07]
Hi Martijn Subject: [Zope3-dev] Re: [SpringCleaning07] By the way, I'm quite interested in seeing whether we can integrate Genshi into Zope 3 and Grok as a templating language. It has some interesting ways to do things, and there's quite a bit of momentum behind it. I saw the Grok package but what is Genshi? Can you point me to a link? Regards Roger Ineichen _ END OF MESSAGE Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/dev%40projekt01.ch ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RE: [SpringCleaning07]
Hi, Adam Groszer wrote: Hello Stephan, Tuesday, December 19, 2006, 2:53:33 PM, you wrote: zope.wfmc SR +1, but please make it very easily available. People do use this code in SR production; Zope Corp. and Adam Groszer come to mind. Yes, here :-) If it would be moved out of the feature-freeze-on-the-trunk jail I would say +100. If my project continues, I might be able to contribute some code into it. Right. Moving wfmc out of the core gives the project it's own life cycle. Christian -- gocept gmbh co. kg - forsterstraße 29 - 06112 halle/saale - germany www.gocept.com - [EMAIL PROTECTED] - phone +49 345 122 9889 7 - fax +49 345 122 9889 1 - zope and plone consulting and development signature.asc Description: OpenPGP digital signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
