[Zope3-dev] Re: Future of zope.app
On Tue, 14 Feb 2006 14:08:07 -, Stephan Richter <[EMAIL PROTECTED]> wrote: On Tuesday 14 February 2006 08:41, Philipp von Weitershausen wrote: Jim said that he wants zope.app to become smaller. I would welcome that. Is it time for this to be thought about? For various reasons, mostly personal ones, I would consider Zope 3.3/2.10 a good point for this to be done. If others agree, we should get started, especially since we moved up the time frame 1 month. I would not mind. I think most of the work will be investigating and documenting the steps to be taken. Technically it is less of a challenge. On the other hand, this release will see a lot of shake-up: ZCML directive removal, adapter registry reimplementation, package location changes. I'd prefer one larger shake than many largeish shakes in consequtive versions :-) Martin -- (muted) ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: One namespace for ZCML
On Tue, 14 Feb 2006 13:48:42 -, Florent Guillaume <[EMAIL PROTECTED]> wrote: For example CPS currently has a cps:upgradeStep directive: Interesting... we've been talking about doing something similar in Plone. Martin -- (muted) ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: zcml abbreviations
On Fri, 17 Feb 2006 00:30:03 -, Shaun Cutts <[EMAIL PROTECTED]> wrote: It seems to me that some of the tension around zcml arises because, on the one hand, everyone wants it to be as simple as possible, and on the other, too much simplicity of the language makes some things very tedious, which encourages "magic shortcuts" via new directives. To let out some of the steam, could zcml support a very simple "abbreviate" directive in over all namespaces? I'm pretty sure this would mean that ZCML would no longer work as valid XML (you can't validate when people invent their own tags on the fly), which would be a shame. Feels a bit like embrace-and-extend, Microsoft style :) I'd rather we concentrated on the actual directives themselves, removed the silly ones, provided decent defaults, maybe even keep some of the shortcut directives if they are semantically and logically different in the minds of the application developer form the primitives they extend. Martin -- (muted) ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Zope 3 web root
On Thu, 16 Feb 2006 06:35:00 -, Shane Hathaway <[EMAIL PROTECTED]> wrote: No, we're still confused. Templates and scripts are code. Should they be in ZODB? Grrr, I hope not. I don't want to suffer that pain, fssync or no fssync. I invented the CMF skins tool primarily to pull a lot of templates and scripts out of ZODB. I invented Ape to pull them *all* out. Now I'm having trouble convincing myself to use Zope 3 because the problem has to be solved somehow yet again! I'm slightly confused too... when are you putting scripts and scripts in the ZODB? The books I read didn't tell me to do so Martin -- (muted) ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Zope 3 web root
On Thu, 16 Feb 2006 17:16:21 -, Alexander Limi <[EMAIL PROTECTED]> wrote:
I have a real client application where the templates themselves *are*
the content being managed: they are *not* software. They *must* be
stored in the ZODB. You could think of these things as "active content
components," or somthing, and they are not logically the same thing as
"stock" templates used for software, but they do include ZPT.
But shouldn't this be an dedicated, custom content type with a transform
or something to handle that particular use case?
That'd be my immediate design idea, too.
I'm agreeing violently with most of the other people here that see no
use for scripting things through the ZODB. Both developer usability-wise
("you can access some modules but not others") and security-wise, it is
a nightmare. Pretty much all the security holes ever found in Zope
through the years have only worked when you allow untrusted users to
author DTML or Python Scripts residing in the ZODB.
Perhaps not violently, but I'm slightly baffled... I'm still a Z3 virgin,
but everything I've been told so far is that the whole
code-in-content-space (and ZODB == content space as far as I'm concerned)
was bad. And I totally agree. CMF tools in content space? Yuck! Page
templates deep into some user-managed folder hierarchy?
If they are needed (and I haven't yet seen a need, but probably because I
haven't written any large Z3 applications), then surely we should devise
better ways of doing things, not encourage mangling of code and content.
Additionally, working as a developer coach for people new to Zope,
explaining people the rationale behind TTW scripting becomes an exercise
in futility ("but why can't I use the set functions in a Python
Script?").
Some means of TTW customisability (primarily of page templates) is very
useful for very simple customisations and has been a good way to sell
Plone, certainly. But the line in the sand needs to be clear. I'd
personally be happy if ZPTs (with python: expressions intact) could be
overridden TTW in a similar way to how CMF's portal_skins/custom works and
that was it. No python scripts in the ZODB, no other nonsense. When you
want to program, you should program (and we should make it sufficiently
easy to set that up so that you can program).
If Zope 3 only allowed code on the FS by default, the world would be a
better place. The only thing it has going for it is TTW customization on
hosting setups that don't allow their customers SSH access, but Zope
isn't hostable in the "$5/month PHP hosting" way anyway. You pretty much
need a dedicated server or at the very least a jail to do anything
useful with Zope.
Keep it simple, and remember: "there should be one -- and preferably
only one -- obvious way to do it".
High +1. Or rather, there should be one well-thought-through,
well-documented and well-designed way. (incidentally, this is why I hate
Perl) :)
Martin
--
(muted)
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Re: Zope 3 web root
On Fri, 17 Feb 2006 23:45:24 -, Shane Hathaway <[EMAIL PROTECTED]> wrote: User interfaces speak louder than books. Start up Zope 3, log in as a manager, and look at the list of things you can add. It includes DTML Page, File, Image, Python Page, SQL Script, and ZPT Page. I suggest that no one should be invited to create these kinds of objects in ZODB; it's a road to misery. We need rip them out and develop another way to fulfill the use cases they represent. Heh, my Z3 experience is limited to theory + some Five work so far. Seriously, though - do people need these? If so, what for? I must say I'm a bit disappointed to learn this. I thought this was exactly the kind of think Zope 3 *didn't* encourage because it learnt lessons from Zope 2. I may be naive about when these are needed, of course. But I'd like to see them switched off by default if no-one can make a convincing case for why they should be there (except, well, you know, they were there in Zope 2, and we thought someone may have liked them). I'm sure I'm missing something obvious, though. Martin -- (muted) ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: The Zope Software Certification Program and Common Repository Proposal
On Mon, 20 Feb 2006 21:28:09 -, Stephan Richter <[EMAIL PROTECTED]> wrote: I have spent the last two weeks working on a proposal that defines a Zope Software Certification Program (ZSCP) and a Common Repository that implements this process. The proposal is attached to this mail. I welcome any comments about it! Hi Stephan, I have only skimmed the document, since it's 1am and I'm going to the mountains tomorrow. I expect a triple-digit post count in this thread when I return. :) I think the proposal is very well put-together. I think it admirably tries to make the Zope 3 community more inclusive of more peripheral developers who simply use the framework, and I think this will benefit Zope immensely if done right. My immediate concern is about resources: Who will have the time or incentive to police the common repository and grant certification? It seems to be a non-trivial process that may end up being quite time-consuming. It may be perceived as too much red tape. It may be perceived as too much centralised control, especially around licensing. At times it may also be open to debate, and a means of resolving disputes would seem necessary. There are certainly a lot of tick-boxes in your table! :-) Secondly, and partly because I'm expecting this to come up in my absence: your proposal is eerily simlar to Alan's two-level Plone collective post to plone-dev, about having an "approved" list of contributors and packages in a fenced-off repository, in addition to the collective. One obvious parallel here, by the way, is with the svn.plone.org/plone repository. That one is controlled by the Plone Foundation, requires a contributor agreement, and imposes restrictions on license and quality (albeit not as formally as you do). I think this is possibly a more valid comparison than with the Collective. I'm actually +1 on your proposal in spirit (if it can be shown to work, and if there is a broad consensus in the community to support it - in fact, this is important: if there is too much division, the proposal would likely be self-defeating) and -1 on his. The reason is that the Plone world is quite different from the Zope 3 world (although there are hard-core Plone developers who sit in both). The Plone community is much larger but naturally also more dispersed. The software is much more narrowly defined (depending on your point of view I suppose, but I mean - it's a CMS, Zope 3 is a framework) and the components developed for it are much closer to the user. Plone thrives on the size and vibrancy of its community. A very large part of its success comes from third party products that people find and marry with Plone to solve their problems. Without the low bar to contributing such components, without an open and very democratic Collective, and without "meta-data" on http://plone.org/products, I don't think this would be possible, certainly not as successful. The uptake of third party product users and contributors, and I think maybe also the quality, has improved quite significantly since we introduced the Products section on plone.org. A framework like Zope 3, and framework-level third party components, thrives more on control and consistency in vision and implementation. (In part, you're solving that with better guidelines around how to write code, guidelines that Zope 3 adopters also benefit from.) I think that the lower down the stack you go, the higher the degree of centralised quality-control needs to be. This, however, is at the expense of perceived eltism and a raised bar to entry. I think that balance is different in Plone than it is in Zope 3. Put differently, I think that *some* Plone components ought to move lower down the stack, target re-usability in different systems, and thus be subject to somewhat different rules. Perhaps these components shouldn't have been Plone components in the first place, or perhaps their evolution would start in Plone and move down the stack. But I think it would be damaging for the Plone community, given its current shape and culture, to impose those rules across the types of components that are higher up the stack - arguably those components which should be "Plone" components still. I'd also note that we solve (or try/continue to solve) some of the visibility and evaluation problems on http://plone.org/products (which is of course open source, albeit GPL, and you can re-use any of this you see fit). Some of those same things, you solve with more technical means - automated testing, common file layouts, XML metadata files. Again, I think these approaches work better at the small-component-high-reusability/framework level than they do with the types of user-facing components that typically land in the Collective. Although you proposal is not technical in design, it's technical in implementation (so to speak). Perhaps it would be
Re: [Zope3-dev] Re: Two visions
On Tue, 28 Feb 2006 17:33:05 -, Martijn Faassen <[EMAIL PROTECTED]> wrote: I don't see how *saying* what Zope 5 will contain will make it *exist* any time sooner. These sound like useful evolution proposals for Zope 2 and Zope 3 to me... The current story of Zope 2, Five and Zope 3 gets us in the right direction (Zope 5, if you want to call it that, though I would definitely want to introduce yet another name in the mix), step by step. We don't promise too much to people. We don't raise the wrong expecations anymore. Everyone in the community is on board. We are already doing the work that's required to reach the ideal of "Zope 5". You could rename Zope 2.10 to Zope 5.0, but I don't see what good that would do except to confuse people. It won't contain the features you list unless someone actually does all that work. The alternative is to put Zope 5 in the nebulous future when all the work you list is done, and it'll be just like our mythical "Zope 3 without the X" then - confusing people and raising the wrong expectations. Martijn, I think you make a very sobering point. It's important to be a little careful with what you promise, and to keep a clear story for the more peripheral community and to outsiders. Zope 3 has, it seems, always been driven by a desire to make the perfect framework. In many ways, that's good, and the result to date is very beautiful. It's important to keep some ties to the real world, the applications people deploy on, systems like CPS and Plone and Silva, and not tempt them to too many false starts or with false promises that leaves them waiting forever. A vision is good. Commitment to that vision is even better. Just be careful what you promise. :) Martin -- (muted) ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Visionaire! (All your problems, solved)
On Thu, 02 Mar 2006 00:42:14 -, Jeff Shell <[EMAIL PROTECTED]> wrote: Personally, I still find it hard to know where the line goes between the ZMI and my own UI code, if I should be extending the ZMI or replacing it. Perhaps because I'm tainted by Zope 2's idea of the ZMI, though. Personally, I think it's insane that Zope 3 still has TTW scripts and templates enabled by default. :-) Personally, I think that Zope 3-the-CA would be the useful in a Zope 2 + Five context, at the very least, which is where a lot of interest will continue to come for. Without understanding the detailed implications of your vision, I must say it's quite attractive. Perhaps the difference between the AS and the Suite may be hard to explain and keep clean, though - I'm really not sure. But less-is-more is a good concept when it comes to frameworks like the Z3 CA. The less stuff I have to learn and understand that's not relevant to me (e.g. as a Five-focused developer, or as someone with lower requirements) the better. Should be easier to document it in these stages, too... And I like having distinct names for the different parts of that puzzle. Martin We've been through a lot lately. You know it, I know it. Zope has a reputation. Sometimes it's good, sometimes it's bad. This has affected Zope 3, since Zope 3 is very much "not Zope 2". But it's affecting Zope 2 as well, as Jim has brought to our attention. Zope 3 is Mature. Zope 3 sounds like Zope 2+1. Zope 2 and Zope 3 have very different concepts. Zope 3 has restricted its audience, for now, to developers; while Zope 2 is appealing to many different kinds of end users and programmer types. Five offers a bridge so that Zope 3 as a library may be used in Zope 2, and the Zope 2 core has started making use of some Zope 3 concepts. But it's obvious we have a name problem. Even within Zope 3, there's a name problem, between "Zope 3 as Application Server" and "Zope 3 as cool collection of packages". Today, I wrote a much longer message in response to the "Two Visions" thread. But I was in a bit of a bad mood, having spent many hours trying to set up a test harness to test one little thing in my own code that was causing problems - a "one little thing" that depended on quite a few components being set up, and it was painful. And I'm still not done. And I realized, as I stewed away, that I like Zope 3 as an Application Server... But I'd like it with less. And this option hasn't been proffered, so far as I can tell. It seems like Jim's Vision might be two options - "zope as library" and "big zope application server with all of the object file system and probably through the web stuff and so on and so on and would be largely compatible with both Zope 2 and Zope 3 as they stand today." Personally, I'd love to have the first option. I also, personally, don't care if I have the second option, but I recognize the need or desire for it, and the desire to get out the message that Zope 2 and the applications on it actually do have a future even though they may not have a future with Zope 3 as Zope 3 is currently known. I'd like a third option: the Zope 3 Application Server as it is right now, but with less. No Rotterdam skin, perhaps no ZMI. No content objects at all, except maybe for some example file and image objects to show how to do BLOBs. It would still be ZODB based. It would still be ILocation based. zope.app.container would be prominent, and zope.app.folder would not be a distraction. It's the basis for building applications like Schoolbell/Schooltool, custom content management, itinerary managers, knowledge bases, whatever. Catalog, local sites/utilities, all still there. But without the distraction of "should I support the ZMI? use it as my user interface?" "should I use the TTW page templates?". "IFolder and IContainer... What is the difference and which should I use? Which should be my base class" (because at Bottlerocket, we chose Folder when we shouldn't have, we found out much later). Maybe that stuff would still be in the library. Maybe it would still be available as a 'mkzopeinstance' option. But the Zope 3 Application Server would probably work best if it promoted custom development via persistent objects, views, and custom skins, as the default way of working with it. It's easier to write documentation for, it could be easy to write mkzopeinstance commands for (to generate a basic starting point with skeleton code and a site.zcml setup that loads the custom skin). There's not this other User Interface and other objects providing a distraction. "I'm making a wiki. How does SQL Script apply? I18N File?". And then I thought about Taligent, for some reason. I'm not going into the history of the company/project, whose products never really made it out into the light of day. But at some point, they broke their product (which was to be a new "object oriented operating system") out into a small set of distinct offerings: TalOS (Taligent
[Zope3-dev] Re: [Zope3-Users] Visionaire! (All your problems, solved)
1) Audience==Middle class: Keep the name Zope to apply to the application server and the middle class. Basically, Zope is the assembly. 2) Audience==Python: Pick a new name for the top-level package of components. For example: "zed3" for the naming. E.g. zed3.pagetemplates. (Examples: SchoolTool, Tiks, Oxfam America via Enfold, etc.) Don't heavily brand zed3. By "middle class" do you mean the developers between the trivial PHP system and the enterize-l33t J2EE system? If so, I think that marketing is right (and very lucurative). I think your proposal separates out the Zope-name-is-good from the Zope-name-is-bad camp well. It doesn't have to be a dichotomy (unless we let emotions get in the way). Your idea and Jeff's are fairly compatible. I too would like to see the CA be made more useful outside Zope, and frankly, no-one will ever require their users to download Zope-3.tar.gz in order to install some simple application that just happens to use the CA. This may well re-invigorate the community, if people who've build a simple application with the CA decide they want to contribute at that level, or start building web applications. Hell, I'd like to use the Z3 CA for a non-web-application, but I don't think I could justiy having Zope 3 as a dependency! Similarly, I think a lot of developers would like to not be confused by a ZMI that may or may not be an application and content types that may or may not be useful or possibly just a demo (actually, I don't fully understand this yet myself) but feel that they have a powerful web development paradigm under the Zope 3 banner with the aesthetic of the Zope 3 CA (Zed?) CA. Martin -- (muted) ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Visionaire! (All your problems, solved)
On Thu, 02 Mar 2006 11:49:31 -, Lennart Regebro <[EMAIL PROTECTED]> wrote: This should be Zope3 as it is now. A couple of things can go away. Maybe the rotterdam skin, I don't know. Definitely the default Folder objects and such. People, especially Zope2 people, think that you are supposed to use them. You aren't, you are supposed to build your own. Yeah, why the hell are there there then? ;-) Martin -- (muted) ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: visions, brands and roadmaps in the sand
On Thu, 02 Mar 2006 17:44:36 -, Martijn Faassen <[EMAIL PROTECTED]> wrote: I would encourage all Zope developers to print out Martijn's post and hang it on the wall over their monitors. Please, no more empty promises that scare people. :) Martin -- (muted) ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: visions, brands and roadmaps in the sand
On Thu, 02 Mar 2006 19:39:54 -, Lennart Regebro <[EMAIL PROTECTED]> wrote: Technology-wise: 1. Zope2 uses more and more of Zope3s technologies. Anything that can be merged gets merged. That means security, pagetemplates and the publisher, and maybe more. Basically, we want to strip Zope2 as much as possible, until Zope2 basically runs "on top" of Zope3. This also includes making sure that a Zope3 product can continue to run on Zope3, even when Zope2 also runs there. I.e, we get to a situation, where you can run Zope3 products unmodified in Zope2. +1 2. Zope3 may also get slightly streamlined, so that Zope3 is what is needed to run Zope2 but not more. That means that Zope3 would lose the ZMI. +1 in the context of Jeff Shell's vision about having one version with and one without the ZMI (in whatever capacity) as a useful data/settings admin interface. 3. We start rewriting CMF tools as Zope3 utilities, with the CMF tools as a thin BBB layer (that may finally disappear). This becomes the basis for the ECM "toolkit" for Zope3. +1 4. We develop TTW development tools for Zope3. I think me and Jim both agree we should have these. I think me and Jim has a completely different vision of what they should be. :) +1 (though lower priority for me at present... I'm more concerned about breaking CMF TTW template cuatomisation etc. in a Five world) This, as far as I can see, is compatible with 99% of the visions we have discussed here, and it will keep us busy for a year. :-) Probably more. Marketing-wise: I can see the point in separating out the non-webby parts of Zope3 to gear it towards people who don't want a big applictaion server. And, to be honest, if I did anything in python today, I'd want to use teh component architecture, even though what I do didn't touch the web. I'm not sure we want to name it Z but i'm not completely opposed either. But I prefer Zope Component Architecture. +1, I like the Zope 3 CA idea. I am opposed to renaming Zope 3. It seems to me that the renaming of Zope3 is suggested for three reasons: 1. "It makes Plone look bad by not running on the latest version of Zope." I honestly couldn't care less. Sorry. I don't know of anyone in the Plone community who's uttered this sentiment. I certainly don't care. 2. "Python people doesn't like things called Zope". Well, Zope3 was heavily geared towards making Zope pythonic. What has the answer from the Python-crowd been? "Eeew, you are using XML!". Honestly, I don't think renaming Zope3 will suddenly make the python-crowd go "Oh, cool, you use XML!" I could be wrong, but that's what I think. But a Zope 3 CA that's non-web-focused and continues the ZCML slimming tradition (if I can make adapters and interfaces without ZCML I think I'll be happy - browser pages and views etc. don't matter in this case) and can be separately deployed/depended upon makes sense. 3. "There is not enough hype!" You don't need to rename Zope3 to hype it. I think renaming will mean we loose a brand, and we make people confused, and we need to change a whole lot of code. :) It doesn't seem worth it. I was always behind the idea of naming it Zope 3 , not lose the Zope or the 3. The is to have something to emphasise a brand around. I think Paul had a really good post about this, though. I think even Zope 3 CA and Zope 3 AS would work fine as names to build hype around. Martin -- (muted) ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: [Zope-dev] Two visions?
On Thu, 02 Mar 2006 16:18:27 -, Jim Fulton <[EMAIL PROTECTED]> wrote: Zope is a agile flexible extensible app server with rich services. You forgot "Enterprise". Martin -- (muted) ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: [Zope-dev] Re: Two visions
On Thu, 02 Mar 2006 13:13:03 -, Rocky Burt <[EMAIL PROTECTED]> wrote: 1) The Zope 3 name and brand is a marketing disaster (from my perspective) -- to be honest there's really no way I could see this actually getting worse by coming up with a new name. How many times in the #plone channel do we get asked, "Does Plone run on Zope 3.1/3.2?" or, "When will Plone run on Zope 3.2" to which we say "no" to the first question and "dunno" to the second question. Actually not as often as I'd feared, but that has more to do with the fact that people don't know they're running on Zope and they don't really know that Zope 3 exists and is in any way different from Zope 2.8 with some bug fixes. Thus proving your point, I think. :) 2) Today when I build new applications with Plone, the best I can hope for is to use Zope 3 as a framework and Zope 2 as a deployment platform. Although the reality is I still use Zope 2 as a framework fr too much as well. I'm hoping (expecting) that Five will continue to make the requirement to use Zope 2 as a framework diminish more and more. As a developer, I certainly prefer working with Zope 3 "the framework" over Zope 2 "the framework". +1 (and thanks for all your hard work in making this better) 1) rename zope 3 the framework as Z or zopelib or Zed or something sensical that doesn't confuse the early adopter's conquest of trying to figure out which zope to start with 2) Make zope 2 the application server acquire the name "zope" once again and be the only app server. This could only work (from a new adopter's perspective) if either the application server is given a new name or given a version number higher than 3. 3) make Zope3-the-application-server have a different name too. It may not make sense to use Zope2-the-app-server always, and eventually we'll hopefully evolve the appserver parts of Zope2 to use Zope3 technologies (the different configurations, same application idea, but we're some way off that). But in the meantime (a loong meantime) there's zope2 and zope3 appservers that serve different purposes and have different strenghts and weaknesses. Who are we worried aboug confusing here? Existing Zope 3 developers? Zope 2 developers? I don't think so, those people are smart enough to figure it out. So I say lets focus on not confusing new adopters in which case SOMETHING HAS TO BE DONE ABOUT THE CURRENT NAMING SITUATION! +1 Martin -- (muted) ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Re: Re: Two visions
On Thu, 02 Mar 2006 19:31:38 -, Stefane Fermigier <[EMAIL PROTECTED]> wrote: Strange how (most of) the Plone people seem to be so quick in willing to sacrifice the Zope brand :( I don't think that's true. I'm certainly not, and I've not heard anyone directly in favour of that either. What I *am* in favour of is branding the current Zope efforts much more strongly, and I think that an *additional* name to hype a Zope 3 brand around (Zope 3 Zebra or whatever) would make such marketing easier. Building our software on a less obscure appserver would make Plone much stronger. I know a very large organisation that would jump on Plone if it were built in Java. Zope is scary. Martin -- (muted) ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: [Zope3-Users] Re: Visionaire! (All your problems, solved)
On Sat, 04 Mar 2006 19:39:50 -, Dieter Maurer <[EMAIL PROTECTED]> wrote: Windows, Windows 98/NT/ME/CE/2000/2003/XP, All of which have the same brandname... Windows, same with Office. I hear of Avalon/Longhorn Longhorn is a codename, it's now called Windows Vista. Avalon is a UI technology in Vista, not an OS. as names for future .Net based Windows versions. Similar (although not that many) variations for Office (Office 98/2000/2003). Ditto. You can find drastic changes in the technology names (rather than the product names): e.g. COM, OLE, ActiveX, COM+ These are not exactly the same technologies, though. Martin -- (muted) ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: The vision thing
- Non-technical users who just want to crank our a web application with little muss and fuss. This was the original focus of Zope 2 and now Plone I think this is better served by applications on top of Zope, rather than trying to make the framework sit that close to the user. Like you said, Plone + its toolchain (Archetypes, ArchGenXML etc.) serve this purpose to a certain extent, at least. I think that although we'd all like "non-technical people" to be able to build "technically advanced applications", it basically degenerates down to the problem that if you want to let these people express themselves as richly as Python or another programming language allows, they'll have to learn something with the same degree of complexity as Python or another programming language anyway. :) Plone + Archetypes + ArchGenXML is about a limited problem domain. You want a CMS-like thing, you want to create some content types with minimal fuzz, you want to be able to skin a bit. That's proven to be a set of tasks that we've reduced in complexty until a larger group of people can accomplish something without understanding the whole stack. Perhaps different applications in different problem domains can achieve the same thing. I don't think it's good for a framework/appserver to try to solve all such cases across all problem domains, because the tradeoffs you have to make start getting awkward. To a certain extent, this is what happened with Zope 2. TTW scripts, and security models for these, and ZClassses (what were they, again...) and all kinds of other mechanisms that ultimately led to sacrifices in the cleanliness of the underlying framework and server. - People who know what an app server is and know they need one. People who know they need to reuse applications and need tools to customise them. People who know they need rich servcies, like security, transactions, etc. These are the people for whom Zope 3 was written. Which I think is a good audience. Zope (2+CMF and 3, but perhaps 3 even more so) has proven to be a very good way of re-using elements of software (e.g. re-using skin elements in Zope 2+CMF, and to a deeper extent in Zope 3), and of getting going quickly. The Zope 3 CA is a really nice architecture that makes it fun to write software, and Zope is good at taking care of teh grunt (security, transactions, authentication) that I don't want to take care of. In fact, I build applications on top of Plone, because Plone lets Zope do those things, and Plone takes care of consistency of UI, usability and a certain degree of integration that I also don't want to concern myself with. - People who want straightforward tools for developing small to moderate complexity sites in Python. I don't think we are servving this audience well. Probably not. Separating out some of the lower level CA stuff (I still like Jeff's Zope 3 CA vs. Zope 3 AS idea; call it ZFC or Zed or whatever) will make this easier for a certain class of people. However, I think it's also possible that Django/TurboGears/Rails will remain good at one thing (possibly lighter/smaller and/or more relational-database-driven applications), that J2EE and .ENT will remain good at another thing (large, enterprise-level installations with needs to integrate with other more established technologies), and Zope can sit happily in the middle. Then there are more fragmented audiences, like people who want a dirt simple way to create applications based on relational databases. Again, Django/TurboGears/Rails are good at this, and I'm not sure it's necessary for Zope to be able to sell itself on this point. Zope can sell itself on the point that it makes a lot of other things easy (e.g. using non-relational storages like the ZODB, transactions, authentication, etc.) and still has the ability to talk to relational databases with similar ORM concepts to what these tools use (maybe we're not quite there yet, but I think we should), as opposed to saying this particular thing is something Zope is better at than all others. My main point is that we need to consider each of these audiences, as they have separate concerns. We need to be explicit about this and have messages and technical solutions tailored to each audience. Do we? Messages, perhaps, but we should also remember that Zope *shouldn't* be all things to all people (because we'll fail miserably at that). It should allow the most flexibility, but at the end of the day, users will make a decision based on the trade-off between what Zope is naturally good at and what it can be made to do with some work. Martin -- (muted) ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Re: A Take on the Hello World Acid Test - from Mandatory Viewing
On Thu, 09 Mar 2006 15:44:56 -, Paul Winkler <[EMAIL PROTECTED]> wrote: On Thu, Mar 09, 2006 at 02:38:48PM +0100, Paul Everitt wrote: One little Python script, maintained as part of the standard distribution, referred to ubiquitously as the right way to start, would have more impact on Zope adoption than nearly any other software activity (save, perhaps, for zope.bobo). All IMO, of course. We do already have bin/pyskel, which is useful as far as it goes, but that's of course not very far. Ben Saller (and others) have worked on a python program called Skeletor (now in the Plone collective) that seems to be a very promising way of generating package infrastructure/scaffolding. I don't think it's Plone or even Zope specific, but may be a useful base. Ben's software tends to be pretty well designed. :) Skeletor https://svn.plone.org/svn/collective/skeletor/trunk/ Ah, and then you mentioned it :-) Martin -- (muted) ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Mandatory Viewing!
On Tue, 07 Mar 2006 18:55:34 -, Stephan Richter <[EMAIL PROTECTED]> wrote: There are tools that do round-tripping, like ArchGenXML, which will have Zope 3 support in the next release. AGX (soon to be called Genesis) doesn't do round-tripping. It lets you re-generate your code from the model and still preserves method bodies, custom methods, and code written in special "protected sections". Full round-tripping is incredibly hard, and probably not worth it all that much. I think it's more important to focus on making development fast and easy (e.g. by not requiring server restarts too often, by having a small number of concepts to learn and a small number basic building blocks that are well-contained and thus easily refactored) than to necessarily support it TTW. To be honest, I don't think a browser is a good replacement for a decent IDE. What the CMF/Plone story has shown us, though, is that simple *customisation*, i.e. tweaking (primarily of UI templates and very basic functionality) is very valuable TTW because it can then become a power-user/non-programmer facility. I'd say that a large part of Plone's success, certainly, comes from the ease with which you can customise (and thus re-use) page templates. Zope 3 does very well on re-use at the programmer level with the CA. Making it possible to tweak/re-use look-and-feel without having to understand python (or much python) is a logical next step. On a personal note, I also think Zope'd be better off if components could be reconfigured without a restart. That way, you could for example provide TTW configuration panels for things ordinarily controlled by ZCML (e.g. the in-ZODB, user setting overrides the zcml-configured default ... for some carefully selected options of course). That'd make it easier to make such UIs and make sure configuration tools. Martin -- (muted) ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: a new zcml directive?
On Sat, 11 Mar 2006 00:49:19 -, Marius Gedminas <[EMAIL PROTECTED]> wrote: I think this is exactly the same as Jeff Shell's suggestion, but its 3am, and I'm too tired to read his entire message. I find I have that problem even at more sociable hours of the day (depending on whom you socialise with). What's worse is that I'm known to produce even longer emails myself from time to time. :-( Martin -- (muted) ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Reducing the Amount of ZCML Directives ready for review
On Fri, 17 Mar 2006 08:56:54 -, Martijn Faassen <[EMAIL PROTECTED]> wrote: Before this merge goes through, I would propose the following steps: Take the document and edit it so it's a clear guide for what you should do with broken directives. I.e. for browser:localUtility we want to exactly specify what needs to be done to register this with the normal content directive. After that, this document needs to be checked in under the doc directory. Finally, there needs to be a clear pointer in at least the changelog as well as the release notes to this document. Is there a DTD or XML Schema for the core ZCML namespace(s)? If not, I think this should happen at the same time, and I'd suggest it be appropriately annotated to serve as documentation. Interfaces aren't just for python code :) Martin -- (muted) ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Re: a plan for widgets?
On Fri, 17 Mar 2006 03:31:59 -, Sidnei da Silva <[EMAIL PROTECTED]> wrote: Yum Yum. That reminds me of Archetypes-Hum. Was that an endorsement or criticism? :) Martin -- (muted) ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Google SoC Project
Hi Stephan! Nate sent just a message that I am interested in a SoC project with the Plone Foundation. Okay, let me write something too. It feels almost like cheating, since you're likely to know more than any potential mentor about the stuff you're working on, but I think it'd be a great idea to give you more time and compensation for contribution. ;-) I think doing a SoC project would be a lot of fun and would give me some time to work on Zope 3. Unfortunately, I am a little bit lost to what I could do that widely benefits Zope 3, Zope 2, CMF and Plone. Here are some of my ideas, some are stolen from the Plone project suggestions: I think it's important (for Google) that it's the Plone Foundation that has been approved for mentorship, not Zope Corp or the Zope Foundation (if there is/will be such a thing...). That means that what you do under this guise needs to be directly relatable to and beneficial for Plone. 1. Finish the ZSCP site[1] I think that the ZSCP process will be vital for controlling software quality in the future and provide people with a valuable resource for additional Zope software. My original proposal was modest by design, since I did not anticipate to have much time to work on a larger vision. With the SoC project I could finish the implementation of the proposal and extend the scope to be more inclusive of existing packages/products, especially with regard to Plone. This project would fit the SoC program well, since its scope is well-defined and extensible. .. [1] http://mail.zope.org/pipermail/zope3-dev/2006-February/018319.html I have two reservation about this - the first is that the process seems very arduous (i.e. there are a *lot* of tickboxes in that table, and there is the potential to create a lot of red tape). The second is that without a large amount of buy-in from the wider community (and in the context of SoC, that means primarily the Plone community), it won't gain the necessary traction to be relevant. To be sure, I support the principle of the ZSCP, but it is a very hard *social* problem (as opposed to a purely technical one) that may not fit the model of a single student working on it for a few months. As I recall, much of the process was also biased (for good reasons!) towards pure Zope 3 products, which may actually mean that the majority of Plone components could never fully comply with the standard... which in turn doesn't make for a great case of the Plone Foundation Summer-of-Code application. :) 2. Implement Local Sites in ZCML I already mentioned this several times: It would be very nice, if we could define local sites in ZCML. I understand this task very well and could write a proposal and implement it in a well-defined time frame. BTW, this task is a "must happen", if we want to port something like Plone to Zope 3 eventually. This project might be too short for the Google SoC. But I think it has a lot of potential. I think that anything that solves one or two of these for Zope 3 would be highly relevant to Plone: - Local-ness - everything in CMF/Plone is about "local". Only when product X is installed should X's functionality be exposed, and before X is installed, something that's registered in ZCML or whatnot could possibly break. People expect to have several Plone sites in one Zope instance and configure them differently. I'm not entirely sure how this fits with ZCML, though, since ZCML is inherently global (i.e. we can't hard-code site names in ZCML ;-), but I'm guessing you're talking about a more generalisable way to install things locally and have things only take effect when locally enabled? - Through-the-web customisability of *templates*. I'm not convinced we need TTW-classes and components and logic - those things fit progammer minds and programmer minds don't mind filesystems and like svn. But people using Plone are *very often* drawn to it because the ease with which they can override/customise page templates (and by extension visual "logic", layout, etc.) without leaving their web browser or learn a large stack of technologies. It's not an ideal model, and we need good ways of getting out of the ZODB and into a "skin product" or similar. But we are extremely reluctant to make use of views with page templates (as opposed to page templates that acquire views and then call its methods) in Plone precisely because it means sacrificing TTW customisability. 3. Optimize ZCML We talked about it many times. The startup time for Zope 3 is too long. In part this is due to the schema field conversion and verification of the ZCML attributes. I would like to work with Jim on some strategies to optimize the startup time by reducing the ZCML processing. Over the years we have thought of several solutions, but they all involved a lot of hard labor that noone was willing to do for free. Well, getting paid to do it
[Zope3-dev] Re: Making a separate project for zope.bforest
On Sat, 06 May 2006 21:14:57 +0100, Gary Poster <[EMAIL PROTECTED]> wrote: Hey all. Seems like no-one but ZC has used zope.bforest, and it probably fits better in the "a million itsy-bitsy projects" story now that we have it (and an accompanying automated test story). Anyone object if I move it out of the trunk? A b-forest? That's like so many b-trees you can't see it for them? Martin -- "You can just adapt yourself out of it..." // Archipelago sprint 26/04/2006 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Zope 3 lacks Ajax capability?
On Mon, 15 May 2006 18:49:24 +0100, Jeff Rush <[EMAIL PROTECTED]> wrote: I looked at MochiKit and studied the Async package, but perhaps I didn't understand it. I only saw ways for the client to sneak HTTP REQUESTSs to the server behind the user's back, but nothing for the server to reach out and shove something into the client whenever the server, not the client, decided it was time. I'd rather not have the client polling the server for said data with HTTP REQUESTs. I'm pretty sure the fundamental AJAX pattern is that you send XMLHttpRequests on some event, either a timer (so it polls) or a user action (e.g. an on-click handler). I've never seen the pattern of a persistent connection ... if you have that, you may as well just write a traditional socket client/server application and deal with scalability there. :) Martin -- "You can just adapt yourself out of it..." // Archipelago sprint 26/04/2006 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Zope 2.9 and Zope 3 i18n, more questions...
On Mon, 05 Jun 2006 14:52:40 +0100, Chris Withers <[EMAIL PROTECTED]> wrote: Personally I'm not looking for a solution for Zope 2.9 or 2.10 as PTS and PloneLanguageTool solve all these use-cases right now, but are hard to extend, impossible to re-use and you know Zope2 ;) Well, these are my key requirements as I try to get as far from Plone as possible... I trust Hanno to get the organisation of products right: what should go into Zope, Five, CMF and Plone and how, and also to make things are reusable as possible outside of Plone. If you can't deal with a Zope 3 package that has a name starting with plone.*, well then I guess you (or your customers?) suffer. Martin -- "You can just adapt yourself out of it..." // Archipelago sprint 26/04/2006 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] XPATH in zope.testbrowser, assertions in zope.testrecorder
Hi guys,
I just started using zope.testbrowser and zope.testrecorder for doing
integration tests. The case study is Ploneboard, the long-overdue
message board for Plone, which has a workflow maze to compete with the
best of them. Permissions control actions like reply, delete, edit and
approve/moderate, which vary according to the different types of forum
(e.g. moderated vs. non-moderated), and forms can get pretty complex.
zope.testbrowser gives us a way to sanity-check all that - I love it :)
There are three features I've found myself missing, though.
o In zope.testbrowser, I sometimes need to be quite specific; for
example, let's say I need to test that user A can see an 'edit' button
on his own post, but not on the post by user B, both of which appear on
the same page.
In this case, having the ability to select nodes by XPATH would be
incredibly useful - both for getControl()/getLink(), and for doing
assertions (fail if/unless this node exists). I imagine an existing
library would be available to make this reasonably easy to implement?
o In zope.testrecorder, the ability to add comments that become
DocTest comments is a stroke of genius. What I'd love to see, though, is
the ability to add assertions for text. Basically, if I could mark some
text in the browser and have that become a statement like
>>> browser.contents
'...some text in the browser...'
... then that would go a long way towards making the post-processing of
the rendered DocTest a very minimal exercise.
o Finally, zope.testrecorder always records full URLs, e.g.
http://localhost:8080/test/foo. It would be nice if it could render
those in the doctest at least with some variable substitution, e.g.:
>>> baseUrl = 'http://localhost:8080/test'
...
>>> browser.open('%s/foo' % baseUrl)
That way, I could make sure that in integration tests, the baseUrl was
always valid and consistent without needing to do a lot of
search-and-replace.
Cheers,
Martin
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: XPATH in zope.testbrowser, assertions in zope.testrecorder
Benji York wrote: Martin Aspeli wrote: o In zope.testbrowser, [snip] having the ability to select nodes > by XPATH would be incredibly useful Yep, I and others have thought the same thing. Cool. Philipp mentioned that lxml may have a nice API for this, too. I imagine an existing library would be available to make this reasonably easy to implement? With ElementTree going into Python 2.5, I suspect testbrowser will grow XPath support. Great! (of course, if we could have it sooner) :p o In zope.testrecorder, the ability to add comments that become DocTest comments is a stroke of genius. What I'd love to see, though, is the ability to add assertions for text. We've considered that too. Patches welcome. :) I looked at zope.testrecorder and thought, hey, that looks simple! Then I saw the .js file... ;-) Realistically, I don't think I'm likely to have time to figure out how this works and make changes in the near future (too many other projects). If I can find the time (or find someone else who has the necessary skill) I would of course love to help out. o Finally, zope.testrecorder always records full URLs, e.g. http://localhost:8080/test/foo. It would be nice if it could render those in the doctest at least with some variable substitution, e.g.: Good idea. The post-record screen (where you choose either Selenium or testbrowser output) would be a good place for that. You could choose any substitution you wanted for the host and port portion of the URIs, defaulting to whatever the actual value was. Yeah, that was my thinking. Actually, I'd prefer if it just rendered it as a '%s/foo' % base_url, where base_url was a variable. That way the test case could do e.g. base_url = self.portal.absolute_url() and we wouldn't have to hardcode anything. We would have to handle the case when more than one base was recorded during the session. True. It wouldn't be too hard to go through the urls in use and present a table of text boxes where you could map each to a variable (or leave as default), I guess. Martin ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: XPATH in zope.testbrowser, assertions in zope.testrecorder
Daniel Nouri wrote: Martin Aspeli wrote: [...] o In zope.testrecorder, the ability to add comments that become DocTest comments is a stroke of genius. What I'd love to see, though, is the ability to add assertions for text. Basically, if I could mark some text in the browser and have that become a statement like >>> browser.contents '...some text in the browser...' ... then that would go a long way towards making the post-processing of the rendered DocTest a very minimal exercise. That's already there. Mark some text and right-click and then some menu pops up. It will render your assertion as "'text' in browser.contents". Aha! It's shift+click in FF on OS X, though :) Martin ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: XPATH in zope.testbrowser, assertions in zope.testrecorder
Philipp von Weitershausen wrote: Benji York wrote: Martin Aspeli wrote: o In zope.testbrowser, [snip] having the ability to select nodes by XPATH would be incredibly useful Yep, I and others have thought the same thing. I imagine an existing library would be available to make this reasonably easy to implement? With ElementTree going into Python 2.5, I suspect testbrowser will grow XPath support. Except that ElementTree doesn't really have XPath support nor an HTML parser, AFAIK. lxml has both. (It doesn't surprise that Schooltool used libxml, therefore.) I understand that you're reluctant to add any dependencies to zope.testbrowser, perhaps Zope 3 will ship with lxml at some point... Or perhaps it could be an optional dependency in the mean-time? Since we're only talking tests, here, it's not terrible of developers have a bit more choice over dependencies. For example, zope.testbrowser itself requires Five 1.4 to run on Zope 2. Plone runs testbrowser tests if they're available, and prints a warning if they are not. Martin ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] zope.testbrowser too trigger-happy with urlencodes?
Hi,
I've got a situation where a form submit will eventually end up in an
action that does (in Zope 2):
context.REQUEST.RESPONSE.redirect('/path/to/foo/#bar')
This works fine through the web, but using zope.testbrowser, the # gets
converted to %23 (which is the correct urlencoding of #). The url
/pat/to/foo/%23bar is not valid, and I get a 404.
I couldn't work out where this was being handled in zope.testbrowser, so
and I guess it may be mechanize or some other library's fault, but I'd
like to know if (a) it's a bug and (b) how I may work around it; save
for that, I have one monster of a functional test now exercising a
pretty complex set of forms and views - and a tutorial on how I did it :)
Martin
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: zope.testbrowser too trigger-happy with urlencodes?
Tres Seaver wrote: Note that the fragment identifier is *never* going to be passed to the server by a "real" browser: instead, the browser strips of the fragment part, submits the remainder of the URL to the server, and then does a search for the appropriate '' element *on the client side*. I'm not sure how this is pertinent to the problem you have found, but Zope will never traverse '#bar' or '%23bar' in the real world. Good point... though if I type a URL with '%23bar' into the URL bar, it does seem to try to traverse to it, which I suppose makes sense - you did the %23 escape for a reason. :) Martin ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Pluggable authentication id management
Jim Fulton wrote: On Jul 31, 2006, at 2:02 PM, Philipp von Weitershausen wrote: ... If you ask me, the slipping of the Zope 3 June release is mostly due to the lack of a release manager. If we had a release manager who'd kick people's asses, we might have more betas since the first one and we might even have a final release. I don't agree. Except for a few people, there hasn't been much interest in fixing bugs. Releasing betas when bugs reported earlier haven't been addressed is counter productive. Why should people bother testing if they don't think the bugs they report are going to be fixed. Disclaimer: I'm not involved in the Zope 3 release process, so what I say below is completely general and not specific to any events having gone on in the Zope 3 community. I'll note from my observations in the Plone community that not having someone bitching is a pretty good way to ensure things don't get done. Everyone has a lot of projects and personal lives that get in the way. I have several bugs assigned to me in the Plone tracker that I never seem to get around to doing. But when Alec or Limi or someone else tells me, we need this or else we can't ship, that makes them jump up the priority list. Having someone vocal with authority to instill a sense of urgency in people is a fairly important part of managing open source projects. Martin ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Zope 3 as a reliable platform?!?
Martijn Faassen wrote: > > So, my proposal for Zope 3.4: > > * have a developer_notes file or directory somewhere. > > * let this contain the developer-visible changes. > > * it should be focused on how to change your code. That's the important > bit. Motivations and such might also be useful to have there, but the > main thing should be: this change from so and so to so and so, so to > make this work, do the following. > +10 - this is becoming really important to us Plone people, since we have some code that needs 2.8 compatability, and some that will probably be 2.10 or 2.11 going forward. People see examples in the 2.8-compatible code and try to follow them, and then end up doing silly things. Even those of us who are pretty close to the core get confused sometimes. Here's the kind of thing I'd love to see, in a clear, well-structured document: """ ZCML directive -- The 'factory' attribute has been renamed 'handlers' because (whatever good reason??). Instead, you should now do """ The important things are (a) it's easy to find this by skimming through a document (oh, I'm pretty sure I'm using a somewhere); (b) there is some rationale. This makes the change easier to remember than just having a blind rule to follow, and allows us to scrutinise changes more; (c) there is a clear example of how it should be done - examples may not speak more than 1,000 words but they're good for 500 at least. This type of document would need to be written by someone who understands the changes, and probably by one or two people not a dozen. A CHANGELOG is mostly useless because it contains too much detail and not enough context. It's fine as an audit trail, but it's very hard to put changes in the context of your own code if they're structured cronoligically and limited to a few key words on a line or two. If anything, this may make me bug philiKON a bit less on IRC ... :-) Martin -- View this message in context: http://www.nabble.com/Zope-3-as-a-reliable-platform-%21--tf2207550.html#a6133275 Sent from the Zope3 - dev forum at Nabble.com. ___ 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: Zope 3 as a reliable platform?!?
baiju m-2 wrote: > > This document is maintained as a wiki page, so anyone can edit it. > http://kpug.zwiki.org/WhatIsNewInZope33 This is great! It's probably exactly what we need. Martin -- View this message in context: http://www.nabble.com/Zope-3-as-a-reliable-platform-%21--tf2207550.html#a6137481 Sent from the Zope3 - dev forum at Nabble.com. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Zope 3.2 maintenance
Rocky Burt wrote: Thanks Hanno! I don't think we should take Hanno for granted (not that you do) - he does some incredible work, and he's always done it without anyone asking him to do so. It benefits Plone more than people realise, and we're really fortunate. If Hanno was less generuos or more busy, we may have to do our own back-forward porting. ;-) Martin ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Release schedule for Zope 2.11/3.4?
Hanno Schlichting wrote: What do you think about a 9 month release cycle? Based on the Plone experience I think this is a good compromise, between release often and stable releases. The Plone experience as I see it is that we get some measure of contribution fatigue. Take Plone 2.5 and 3.0. With the cycles of review bundles (similar to Zope proposals and discussions), development of new features, bug fixes, merging to alphas, releasing betas and rcs, we found that we basically had to get started on 3.0 just as (if not before) 2.5 final went out the door. That's pretty exhausting. People pull together on bugdays and their spare time to get a particular release out, and then they are being hounded for the next release already. In other words - 6 months is a really short time, especially if you expect to have a reasonable alpha and beta cycle where things stabilise. And further, it's very hard to get people to work on two releases simultaneously (polishing x whilst starting on x+1). I agree that 9 months is a better compromise. 12 months is a very long time. The other important thing is to manage scope - let people know quite early what is and what isn't in scope for a particular release and set clear, agreed-upon timelines for things like proposal deadlines, feature freezes, and alpha/beta releases. Just my opinion, of course. Martin ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: [Zope-dev] Release schedule for Zope 2.11/3.4?
Benji York wrote: Personally I think we should just release the trunk every six months (with a list of known bugs) and that be it. (I'm speaking of Zope 3 here, I don't know enough about the dynamics of the Zope 2 ecosystem to comment there.) What good could that possibly do? For the people who are not spending their days reading checkin messages, something that is called a final release is a promise that the features they get have been tested and are considered stable, that they can rely on a certain degree of backwards compatibility, and that they're going to get burned. Releases are externally-facing things. They benefit people other than the core contributors the most (the core contributors mostly get the gratification of having released something, and then probably go on playing with trunk). The quality those people receive must be the most important factor by which a release is judged. .0 releases of Zope (2) have had a somewhat negative image before (to the point where people were afraid to let Plone depend on a Zope release that didn't have a .1 or .2 release out already), which I think is getting better. Undoing that would be to the detriment of how people perceive the quality of our software. By the same token, we could just never have releases and expect everyone to live off svn trunk. The idea of a release *cycle* is surely that it's cyclical: at the beginning, we worry about features and innovation, at the end we worry about stability and polish. If the timelines are worked out correctly, then time-based releases help us manage scope and keep moving at a pace that doesn't mean we have enormous mountains of features that take an infinite amount of time to stabilise and get ready. That's a good thing, but ignoring the end-result quality argument by being slaves to the Great Roadmap that was set out six months ago isn't. It's very waterfall. :) Martin (pardon any hyperbole) ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: zope.interface.Interface.(isImplementedBy vs implementedBy)
Chris Withers wrote: Hi All, What's the difference between these two? implementedBy is what I meant to use, by I braino'ed isImplementedBy instead. def providedBy(object): """Test whether the interface is implemented by the object Return true of the object asserts that it implements the interface, including asserting that it implements an extended interface. """ def implementedBy(class_): """Test whether the interface is implemented by instances of the class Return true of the class asserts that its instances implement the interface, including asserting that they implement an extended interface. """ ... def isImplementedBy(self, ob): warnings.warn( "isImplementedBy has been renamed to providedBy", DeprecationWarning, stacklevel=2, ) return self.providedBy(ob) That's 2.10, grep lib/python/zope/interface on your own instance in case it's changed. However, IFoo.providedBy(obj) and IFoo.implementedBy(obj.__class__) should be the same. Rather than getting an AttributeError, I just got unexpected behaviour :-( You know as well as anyone that this is a pointless message without any more detail. Martin ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Use launchpad ! (was Re: the maintenance of change logs)
Jeff Shell wrote: Compare: - http://dev.zope.org/Zope3/RoadMap - http://www.sqlalchemy.org/trac/milestone/0.3.0?by=severity Or dev.plone.org. Trac is pretty nice, especially as an svn browser and for the roadmap view. The issue tracker is quite good (could be better, but works fairly well), and the wiki features are interesting. Of course, we use the Plone Software Center for roadmaps and the Poi issue tracker for individual products' trackers, see: http://plone.org/products/plone/roadmap http://plone.org/products/poi/issues Martin ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Grrr. zope.org wikis are evil.
Hi Jim, I have some wiki desires of my own that I'll probably never realize: - HTML WYSIWYG Wikis that don't use any form os structures text (small s) and just use an HTML editor. I think that structured text of any kind is an obstacle to Wiki use. Moin moin's markup rules drive me as batty as old Structured Text drives other people. ZWiki supports EPOZ editing and I'd love to see that used. Of course, this sort of experience avoids the need for preview or structured-text documentation. Wicked can do this, I believe, and it will likely (pending voting) be in Plone 3.0. You write ((foo)) and you get a wiki link to foo, regardless of text format. wicked is a bit AT specific, but whit is working to make it be more general, and factor out the re-usable bits. I'm sure he can chime in. - Off-line editing. zsync provides a huge opportunity here. I wish someone had time to work on it. It would be totally cool to be able to check out a wiki onto a local hard disk, work on it, and merge my changes back. I think this is a more general problem - doing proper online/offline sync of content. I'd love to have offline capabilities in Plone, for example. :) Martin ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Test Layers
Chris Withers wrote: > > Now, related to this, say I have content objects X and Y, which are > expensive to set up. I have LayerX which sets up a sample content object > X, and LayerY which does the same for content object Y. This is fine for > tests which need one or other content type, but how do I write tests > which need both? > Layers are ... layered. If your test base class has layer X and a test case subclass of that has layer Y, then it will set up X, run all the X tests, then setup Y and run all the Y and X&Y tests, then tear down Y and then X. I did this in Plone recently, but it completely escapes me where. Maybe I'll have an epiphany after lunch, but look at how the ZCML layer in PloneTestCase trunk works (it sets up all kinds of ZCML) and then try to derive a class from PloneTestCase (or your equivalent) and set layer = myLayer. Martin -- View this message in context: http://www.nabble.com/Test-Layers-tf2458447.html#a6853085 Sent from the Zope3 - dev mailing list archive at Nabble.com. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: PyCon 2007 web frameworks panel
Paul Winkler wrote: This sounds like something that could stand being talked about in public more often... I've never heard of Zope Grok :) Me Grok... me SMASH ZCML! Martin ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] adaptation based on class rather than interface
Chris Withers wrote: > > Hi All, > > I find myself often having to define pure marker interfaces for each > class that I define, purely so I can register adapters for objects of > that class. > Why does your class not have a (non-marker) interface in the first place? The use of interfaces as documentation and as formalisms for expressing a class' functionality (in adapters, utilities etc) is one of the benefits that Zope 3 introduces. I can see how they may not always add that much value immediately, but they are a good way of ensuring things are reasonably well-defined, well-documented and easily locatable. I'd rather start from interface design and implement as necessary, than think of interfaces as necessary evils of the CA, personally. Martin -- View this message in context: http://www.nabble.com/adaptation-based-on-class-rather-than-interface-tf2601087.html#a7257399 Sent from the Zope3 - dev mailing list archive at Nabble.com. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] adaptation based on class rather than interface
Martijn Faassen wrote: > > Oh, I disagree. It's much nicer to be able to be able to start with > adapting classes, and introduce interfaces later, where necessary. Often > they're not. In fact it's already possible to adapt classes and register > views for classes. In ZCML I believe there's some limitations with one > directive or other (a bug), at least there was, but the component > architecture has allowed this for a long time. We've been very happily > using this in grok. > I see your point of view - and I guess there is a balance here. However, I think that one of the big benefits we see in Zope2/CMF/Plone over "the old way" is that people seem to take interfaces more seriously now, and with them internal documentation. Having well-thought-out and well-documented interfaces encouages API stability and re-use and makes it easier to understand someone else's code. By contrast, we often end up with jungles of APIs and no-one can quite decide whether they're stable or not, when programmers are given no hooks on which to hang their design. Do as you wish, of course. I find that abstract discussions like this typically end up being a lot of talk over apparent disagreement that disappears when it comes down to practical design. Martin -- View this message in context: http://www.nabble.com/adaptation-based-on-class-rather-than-interface-tf2601087.html#a7260124 Sent from the Zope3 - dev mailing list archive at Nabble.com. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: adaptation based on class rather than interface
Jean-Marc Orliaguet wrote: And there is nothing wrong with using inheritance when there is a '__IS A __' type of relation (e.g. an ordered folder IS A folder IS AN item, ...), or if there is a HAS_A type of relation (a folder has items, a chair has four legs...). It seems that Zope3 has banned all form of class inheritance, even those that made sense, and that would have simplified the implementation. That is totally, utterly, patently rubbish. Devise some regular expression and grep the zope 3 source code for inheritance. "marker interfaces" have empty specifications, that's the problem: they can't grow into "real" interfaces that have a specification. If you add methods to the marker interface you will have to track down all classes that implement the interface (unless you don't really care whether classes do implement their interface). Marker interfaces by design serve a different purpose than other interfaces. They are the equivalent of an on/off switch about object behaviour or purpose that is externalised from that object (i.e. they are not just booleans in a schema, they are potentially managed outside that class). Martin ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: adaptation based on class rather than interface
OT: Thunderbird makes a real mess of interpreter examples, thinking the '>' is an indent and making it a coloured line. Anyone got an idea how I stop it from doing that? Martin ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: adaptation based on class rather than interface
Jean-Marc Orliaguet wrote: but conceptually it is the same mess :-) i.e. a total lack of specification. It only looks nicer with interfaces. So, in other words (and in summary of previous blog posts): - New techniques complement, rather than completely replace, old techniques - New techniques do not absolve you from thinking about design - New techniques used appropriately can bring benefits - New techniques misused where old techniques would be better can cause problems Pearls. I'm not sure anyone argued otherwise, though. :) Martin ___ 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: adapter registration question
Chris Withers wrote:
>
> Philipp von Weitershausen wrote:
>
>>> ...hence the quotes. It's a "function" in that I want to use it as an
>>> adapter that doesn't need to be instantiated by a factory before being
>>> used.
>>
>> All adapters need to be instantiated.
>
> Why?
>
> def myStrAdapter(something):
> return str(something)
>
> This function adapts strings to integers, why would it need to be
> instantiated?
>
I'm not sure this helps (I'm not quite sure what you're trying to do, it
seems a bit crazy), but the realisation that functions could be adapter
factories hit me at some point.
So, when you do an adapter lookup like
foo = IFoo(context)
or
foo = getAdapter(context, IFoo)
or similarly for getMultiAdapter, the CA will:
1. Find the most appropriate adapter registration by looking at the
interfaces on context and finding the most specific adapter to IFoo
2. Call that adapter registration's factory
A factory is just a callable that takes the context (or multiple context's
in the case of a multi-adapter). A class, of course, is a good factory, so
if you have:
class FooAdapter(object):
implements(IFoo)
adapts(IContext)
def __init__(self, context):
self.context = context
and then
Then getting an adapter is the same as calling foo.FooAdapter(context) - you
get an object providing IFoo by calling the factory.
You could instead do:
@zope.component.implementer(IFoo)
@zope.component.adapter(IContext)
def fooFactory(context):
newAdapter = FooAdapter(context)
return newAdapter
Now, getting the IFoo adapter means calling fooFactory(context). Of course,
it still returns an object providing IFoo, so the contract is still valid.
Incidentally, we use this approach in Plone to fish things out of the ZODB.
You can adapt an object to IPortletAssignments, and we have a factory
function that finds an assignment container (a persistent btree container,
basically) in that object's annotations and returns it. This was a lot less
work than making a dumb transient adapter class that implemented all the
methods of IPortletAssignments (which is a sub-interface of IContainer, so
it has all the dict-like behaviour) and proxied each method call to
annotations on its context. The calling code doesn't care though:
assignments = IPortletAssignments(context)
assignments['my_new_portlet'] = MyNewPortlet()
And of course, if the object wasn't annotatable (say it was a transient
object originating from an SQL database) we could register a different
adapter.
The important point here is that the adapter factory is called each time you
do an adapter lookup. In the most common case, the factory is just a class,
but it could be any callable. If you call a class, you get a new object of
that class, and hence adapter instances tend to be transient, but you could
have a different factory that wasn't.
>> No. You always register a factory which is called upon lookup. That's
>> because adapters are context-dependent and thus need to be instantiated
>> every time you look them up.
>
> What if they're not context-dependent as in my example above?
>
> ultimately, I'm looking to replace code like the following:
>
> convertors = {
>int:{str:str,datetime:datetime},
>str:(int:int,datetime:datetime},
> }
>
> def convert(x,y):
> return convertors[type(x)][type(y)](x)
>
> ...if you see what I mean. Apologies for the trivial examples, but these
> are real problems...
>
I still think this sounds a little over-complicated, but I'm guessing it's
just because you're de-badging the examples. If convert(x,y) was a
multi-adapter factory, then the above should work.
Martin
--
View this message in context:
http://www.nabble.com/adapter-registration-question-tf2606485.html#a7355564
Sent from the Zope3 - dev mailing list archive at Nabble.com.
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] wading through zcml...
Chris Withers wrote: > > What's the difference between zope:view, browser:view, browser:page and > browser:viewlet? > I would strongly encourage you to buy Philipp's book when the second edition comes out, and read some of the available existing documents (e.g. worldcookery.com, the Zope 3 wiki thingie). is deprecated, I believe, an old spelling for before could do multi-adapters. is about registering a new view, typically one that doesn't render a page (so think of it analogous to where you may use a Script (Python) in Zope 2) is about a view typically with an associated template that renders something for the user is about building viewlets, which are small chunks of HTML that are aggregated into a . The DocTest in zope.viewlet explains it all. > I'm trying to register an adapter in such a way that I can do the > following in a page template: > > > You would use a browser:view with a class deriving from BrowserView (Products.Five.browser.BrowserView) and did its magic in the __call__ method i believe. A more common pattern would be to have a method on the view "render" that you call: tal:define="renderView someobj/@@render" tal:content="structure renderView/renderTheData" > Also, why, when zope:view is described as a synonym for zope:adapter, > does zope:view support an allowed_attributes attribute, while > zope:adapter does not? > It has to do with the fact that in the olden days, there were no multi-adapters, and views were special. Then they realised that a view was in a fact a multi-adapter on context, request, and that this was a more generally useful pattern. Martin -- View this message in context: http://www.nabble.com/wading-through-zcml...-tf2641986.html#a7376076 Sent from the Zope3 - dev mailing list archive at Nabble.com. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: wading through zcml...
Chris Withers wrote:
Jim Fulton wrote:
If you want to specify the name of a template in ZCML, then you'll
have to invoke some magic.
Why can't IView (or whatever it is) just specify that the constructor
must accept a request, response and a template instance?
Because the template may not be passed in, and even if it is, where
would it be constructed and how would it be found again?
If you have this:
class MyView(object):
def __init__(self, context, request, template):
self.template = template # IView specifices template = a template
...
then you may as well not have a 'template' attribute for /> at all since you have to do so much work; you could just do this
(which you can do now, in fact)
class MyView(object):
template = ViewPageTemplateFile('mytemplate.pt')
def __init__(self, context, request):
self.context = context
self.request = request
If you have it done in ZCML, though, you can get a template-only view
without any Python at all, though:
Martin
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Some thoughts on Zope 3, Zope 3 applications, and Zope 3 instances
Jim Fulton wrote: > > Some thoughts on Zope 3, Zope 3 applications, and Zope 3 instances > I found this very interesting. As more of an indirect consumer to Zope 3 (but user of Zope 3 via Five and developer of Plone on Zope 2), here are some of my own thoughts. In the Zope2/CMF/Plone world, we are used to Zope instances that may host several sites (e.g. Plone instances). We find that users like to be ablet to have multiple sites (possibly on muiltiple URLs via RewriteRules) and manage a single instance of the app server (Zope 2) on their machine. One-process-and-port-per-application is certainly *perceived* to be more resource intensive and difficult to manage if there are multiple appilcations on one server. Zope 2.10 has been a huge improvement in that regard. The local component registry work has made "site-ness" and local/ZODB-persisted configuration much, much easier. Plone 3 is benefting immensely from this as we speak. We also find that users expect to be able to deploy Plone (a bunch of products in a tarball that extracts to the Products/ directory) and various add-ons (other products) easily. This was one of the things that confused me most when learning about Zope 3. Am I supposed to put application-specific ZCML files in an "instance-global" package-includes? Should I tell people to edit those ZCML files during deployment (oh Java hell)? Should all the components of the application be eggs in the global PYTHONPATH or in the instance home? The second thing that confused me was the role of the ZMI/OFS. In Plone, we have an application that builds on top of Zope2-the-application, then CMF and then Plone's own layers of code. People who develop solutions based on Plone typically treat Plone itself as another application/framework hybrid and customise Plone (using the customisation mechanisms Zope 2 and CMF provide) to their own needs in terms of look-and-feel and functionality. This may not always be architecturally the best idea, but it often makes people very productive, very quickly. If I were building a plain Zope 3 application, I still don't know if I'd want to use the browser menus, folder listings etc of the ZMI and just tweak the look and feel, or if it would be better to start from scratch (though I haven't yet built a plain zope 3 app from the ground, so it may just be ignorance on my part). Certainly, if I had to understand most of zope.* to be able to build my own zope.app.* from scratch, the learning curve may just be too much. Now, I still think Zope (2 and 3) has the most benefits in content-centric use cases. I could see ways to build an application using Zope 3 views and traversers and other components without using the ZODB at all, but I imagine it'd be a lot of work to get going if I didn't have the fundamentally hierarchical nature of the ZODB, mapping its nodes to my application's URLs. I'm sure that is just because I'm tainted by the way I think about Zope 2 and Plone, but it's non-obvious to me how a completely non-contentish Zope 3 application would work; or rather, I think it would be easier to use Pylons or Django or TurboGears in that case, if I were building something that needed a couple of simple forms and a few static pages and a big database behind it. I think your thoughts resonate quite well with my own observations and/or confusion. I would, however, caution against becoming over-zealous in breaking things up. Zope 2, CMF and Plone are successful in large part because people get started quickly. If it takes fifteen trips to the cheese shop to understand how to get a page to say Hello world, I'm not sure people would bother. Most likely, that's solved by having use-case focused (and real-world tested) bundles or distributions that provide meaningful functionality of starting points. It's also solved by having some customisable "best-practice" components that are closer to the user. Learning from such examples is probably the main way people pick up new technologies and conceptualise how they can solve their particular use cases. Martin -- View this message in context: http://www.nabble.com/Some-thoughts-on-Zope-3%2C-Zope-3-applications%2C-and-Zope-3-instances-tf2916344.html#a8157025 Sent from the Zope3 - dev mailing list archive at Nabble.com. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Some thoughts on Zope 3, Zope 3 applications, and Zope 3 instances
Jim Fulton wrote:
>
> I'll make some small comments below, but I want to make a big
> comment to start. Zope 2 and Plone are both examples of
> extensible applications. In my note, I was trying to make the
> point that I think such applications have value. I'd like to
> see them exist. I'd like to see them done well. I think Zope 2
> did it very well, in it's time. I think Plone and other applications
> have carried that forward successfully.
>
> At ZC, for better or worse, we are no longer in the business
> of applications that are extensible in that way. We build
> applications that are used directly by our customers.
> I think this is true of many Zope developers. *We* use Zope 3
> as a library for building applications.
>
> Both uses are valuable and should be supported.
>
> The application that I've been referring to as the "OFS"
> (again, a more or less random name) is a pale imitation of
> Zope 2.
>
This is very much what I read into your comments and I think it is an
impotant architectural decision whether we're building an application or a
framework (Plone itself struggles with that decision sometimes); The strong
"framework" leaning that Zope 3 has adopted is probably to its benefit, and
is almost certainly the main reason why we are able to benefit from Zope 3
at all today in the Plone universe (via Five).
However, Zope 3 should not be and is not just a library that ZC and a few
other people with deep investment in the framework use for their
applications. To grow, stabilise, mature and become a good vehicle for
selling work ("I trust you because you're using Zope 3", rather than, "I
don't trust you becuase you're not using J2EE") the community needs a
constant influx of new developers and interested parties - the first
instance, users of the framework.
The general direction that web frameworks are moving in, led by Rails and to
a certain extent Django, Pylons, TurboGears and arguably Plone in some
circumstances, is that getting started must be quick, results must be rapid,
the tools must support "agile" working practices and the learning curve must
be managable. Most people don't have the time to bet that reading a book or
two will be worth the investment (of time) before they start doing something
useful and productive.
This to me is where we can learn from the success that Zope 2 and Plone have
enjoyed (or been the victim of, as it may be architecturally speaking). The
main reason people think about building applications "in Plone" at all (a
somewhat self-contradictory notion) is that if they can re-use all the
pretty UI and HTML/CSS primitives and user management and navigation
elements and security and workflow from Plone, turning off the portlets and
content types and junk they don't need and turning on the custom
look-and-feel and extra content types and portlets and forms they *do* need,
they get something up and running quicker, to a higher standard, than if
they start from a palette of components and a blank .py file.
In other words, as Martijn has said, I believe it is very important for the
community to support meaningful distributions/app servers/higher level
frameworks (singular or pural) that show off what Zope (3) is good at and
how it's done, that can be customised and (this is where the CA approach
really kicks ass) where future upgrades to this means you benefit, not that
you need to re-fork it for your own needs.
I would be worried if I felt that the Zope 3 community became only about
components and left this "real world but generic assembly" work to "someone
else" when no "someone else" would be interested or skilled or emotionally
invested enough to care. In the Plone world, we have the focus of
Plone-the-application that implies we have to make Plone-the-framework
better. If things become *too* scattered, where is the focus of Zope3?
(note: I'm exaggerating here, I think things are moving in the right
direction not the wrong one, I'm just playing devil's advocate and exploring
what I've seen from the Plone side of the fence)
> Note that there is nothing inherently hierarchical about ZODB.
> Of course, ZODB makes modeling hierarchies (and other graphs) much easier
> in many ways that working with non-object databases.
>
> Of course, I'm a big fan of the ZODB and would use it for all sorts of
> "non-content-centric apps", whatever that means. :)
>
Like I said, I'm quite tainted by Zope2/CMF/Plone. I like to model
(many/some) problems as hierarchical data structures with concepts like
one-to-many relationships as folders with content. I agree the ZODB isn't
necessarily hierarchical, but all the use cases I've ever seen for it have
been. :)
> Well, fortunately, thanks to setuptools and tools like easy_install and
> zc.buildout, you should only need one trip to the cheese shop (or
> wherever)
> and the dependencies should come along automatically. I'm also working
> on ways to automate packaging and app and all of it's dependencies
> together.
>
[Zope3-dev] Re: Some thoughts on Zope 3, Zope 3 applications, and Zope 3 instances
Jim Fulton wrote: Martin Aspeli wrote: ... Anyway - I hope these perspectives are useful. I'm certainly not disagreeing with what you're saying or with the direction you're pointing out. I think we just need be mindful that there were some good things about the past approaches as well as problems (not that you're not). I think we're in strong agreement. I think we need both the Framework and the apps that use the Framework, including Zope2/Plone-style pluggable apps. I think we need to keep these efforts somewhat distinct though. I'd love to see projects that focus on building killer apps on top of the Zope 3 framework. I just want people to understand that the application != the framework. My argument is just that if you're not careful, you may end up with a chicken (or was that xicken) and egg situation; not enough people who know the framework care to build the killer app(s); not enough people who need an app understand (or have time to understand or will risk spending the time on something they don't fully understand) the framework. Someone with the right skills needs to passionately care. Perhaps it's OFS+ZMI; perhaps it's Zope 2 + Five; perhaps it's Plone (man, you have no idea how productive you excellent people have made some of us jaded Plone developers recently); perhaps it's Grok; hopefully some combination. Martin ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Some thoughts on Zope 3, Zope 3 applications, and Zope 3 instances
Martijn Faassen wrote: My hope is that with Grok we can inject some sensibilities into Zope 3 that focus more on getting things done easily and quickly. I think that the basis built with an attitude of reusable and flexible components is great to build a powerful "getting things done easily and quickly" system on top. But we really really need such a system, and I hope Grok will be more than just a new technology but will also help drive a shift in focus in the Zope 3 world. And I fully support it; it's even conceivable I could contribute one day, if I find time. This project is really exciting and deserves more traction than it has at the moment. It would be very interesting also if there was a path through which Plone developers and other Five-dependents could start using Grok productivity boosting tools. We have core Zope 3 developers here at this sprint (Philipp, Christian Theune), so I have some hopes we'll succeed. :) ... but it is a fine team :) So, I agree we need what Jim proposes. We just also need what Grok tries to offer. I think that as an open source development community that wants to grow, we need Grok a lot more than we need splitting up Zope 3 into eggs. +1, though perhaps one makes the other easier. Martin ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Some thoughts on Zope 3, Zope 3 applications, and Zope 3 instances
Paul Everitt wrote: Thus, telling the Zope 3 core team to own and distribute the killer app is neither realistic nor fair. Move Zope 3 to its natural turf and collaborate with folks that feel passionate about other turf. Application != the framework. A very good point. Perhaps the future will be: Developer learns Grok. Developer likes Grok. Developer improves Grok. Developer finds that to improve Grok, he should help improve Zope 3. And then maybe s/Grok/Plone/g or s/Grok/something else/g. I'm obviously not in the business or position of telling people what to do (well, ahem, maybe I do, at least in the Plone world, but that's mostly just good intentions). My concern is that we should make the framework accessible and approachable, and that having a focal point and a "path through" the framework is an important part of that. Grok is encouraging to me in that regard. Plone is quite actively (but not wholesale any time soon) moving in a direction where it becomes a strong consumer of Zope 3. Hopefully, we'll see something else emerge as well that is conceptually a combination of the two: End user-oriented and pure Zope 3. I don't think anyone's argued otherwise, of course, I'm just pointing to existing wisdom I've received and observed. Martin ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Grok sprint 2 reports
Martijn Faassen wrote: Hi there, We had a Grok sprint in Germany over the weekend, and we got two reports about it: Rock on :) What is the current state of the art in terms of Grok examples and documentation? What is the best place to look to find out about the latest development techniques and possiiblities? Martin ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Grok sprint 2 reports
Peter Bengtsson wrote: Philipp has posted a blog entry with a good example of Grok code: http://www.z3lab.org/sections/blogs/philipp-weitershausen/2007_01_09_you-thought-zope-3-wasn Gorgeous! I especially like that you don't have to manually define the template since it's picked up automatically by name. Will the grok effort yield any codegenerating scripts and stuff like the django folks have? If not, I have some ideas that I could maybe contribute with at/for the next sprint even :) Code generation sucks. :) But: - ArchGenXML (hacky though it is) is great for business types because it takes UML (which business analysts understand and customers can be talked through) and produces content types they can CRUD with. Seriously, I've seen people sell big Plone jobs on AGX (kinda scary). - Don't invent a new code generator. Please. :) PasteScript does quite well, and seems to be adopted by others, e.g. Pylons. We already use it to make new egg-like packages for Plone. - You should never, ever *need* code generation. It should be a nice way of getting a common structure for second-order stuff like documentation files and egg metadata (how we use ZopeSkel/paster in Plone), or a way of going from a visual representation to code. Systems that *depend* on generators are always nasty to maintain, upgrade and understand. Tools are just not a replacement for good language design (this is why we see the Java->Rails exodus cliche, and then people realise Rails has tools too, oh well). Martin ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] wildcard adapter
Chris Withers wrote: > > Hi All, > > I was wondering if someone could give me a definitive explanation of > what the following means: > > for="* ISomething *" > ... > > ...means? > > Is the following equivalent: > > provideAdapter(...,adapts=(None,ISomething,None),...) > No, but this is: provideAdapter(...,adapts=(Interface, ISomething, Interface),...) > If it is, then which of the following should I use to register a generic > adapter for any single object to an interface: > > provideAdapter(...,adapts=(None,),...) > provideAdapter(...,adapts=None,...) > > I'm not having a lot of joy registering generic adapters so I thought > I'd come and check my understanding here ;-) > provideAdapter(adapts=(Interface,), ...) Martin -- View this message in context: http://www.nabble.com/wildcard-adapter-tf3027563.html#a8411297 Sent from the Zope3 - dev mailing list archive at Nabble.com. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] development checkout
Chris Withers wrote: > > Hi All, > > It's been way too long since I did that, but how do I go about getting > an svn checkout of Zope 3 that I can develop with? Is there a how-to > somehwere? > > I'd imagine it goes something like: > > 1 - checkout svn url you wish to develop with > > 2 - do some kind of inplace build > > 3 - point your mkzopeinstance-created instance at the checkout > > 4 - develop > > 5 - run tests > > How do I do 2 and 5? > > For 2, how do I do a suitable in-place build on Linux? Are there still > up-to-date pre-built binary bits for Windows that I can unpack? If so, > where do I get them from? > > For 5, how do I run tests for a module in the checkout with the > testrunner, as opposed to tests for a module in the instance? > I'll take a guess that it's not too different from building zope 2: $ python setup.py build_ext -i On windows, you probably need mingw32. This may help: http://svn.plone.org/svn/plone/ploneout/trunk/WINDOWS.txt To run tests, you can certainly run tests from an instance, e.g. $ bin/zopectl -m zope.interface I'm not sure how they should be run if you have no instance available, but it's just a matter of finding a testrunner that has the right PYTHONPATH surely. Martin -- View this message in context: http://www.nabble.com/development-checkout-tf3153826.html#a8745753 Sent from the Zope3 - dev mailing list archive at Nabble.com. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Test layers for zope.app.* packages
Jim Fulton wrote: I *really* want to be able to have the current Zope 3 application assembled entirely from eggs by the end of PyCon. Me too! :) Not that I'm helping (much?), but the Plone people are getting all excited about eggs. We even have a monstrous Plone egg that contains all of Plone's products (still a bit experimental and throws some warnings because it's trying to bytecompile Scripts in skin folders, but oh well). Martin ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Could queryAdapter() have side effects?
Hi, This is most likely just something gone wrong with my test setup, but I thought I'd ask just in case I've hit some obscure bug. Basically, I have a test that uses PloneTestCase and ZopeTestCase on Zope 2.10, with a layer that loads site.zcml. The ZCML for my package registers a particular adapter. There are no local components involved as far as I know. The old code did this: def _handleReferences( self, baseline, wc, mode, wc_ref ): annotations = IAnnotations( wc_ref ) # handle forward references for relationship in baseline.getRelationships(): # look for a named relation adapter first adapter = component.queryAdapter( baseline, interfaces.ICheckinCheckoutReference, relationship ) if adapter is None: # default adapter = interfaces.ICheckinCheckoutReference( baseline ) references = baseline.getReferenceImpl( relationship ) mode_method = getattr( adapter, mode ) mode_method( baseline, wc, references, annotations ) It's basically trying a named adapter if it can, and then falling back on the default if no named adapter was registered. In one of my tests, which does nothing funny with the CA at all, as far as I can tell, it just happens to lead to this piece of code, I got a ComponentLookupError for the fallback (adapter = interfaces.ICheckinCheckoutReference( baseline )). Tracing it, this looked rally weird, because getSiteManager().getAdapters((baseline,), interfaces.ICheckinCheckoutReference) was returning a suitable adapter with name=u"". Out of desperation, I rewrote the code like this: def _handleReferences( self, baseline, wc, mode, wc_ref ): annotations = IAnnotations( wc_ref ) baseline_adapter = interfaces.ICheckinCheckoutReference( baseline ) # handle forward references for relationship in baseline.getRelationships(): # look for a named relation adapter first adapter = component.queryAdapter( baseline, interfaces.ICheckinCheckoutReference, relationship ) if adapter is None: # default adapter = baseline_adapter references = baseline.getReferenceImpl( relationship ) mode_method = getattr( adapter, mode ) mode_method( baseline, wc, references, annotations ) And this works! Some investigation with pdb revealed that if I invoked the ICheckinCheckoutReference default adapter lookup at any point before the call to queryAdapter(), it would work properly, but if the queryAdapter() call came first, I'd get a ComponentLookupError. I'm really stumped as to why this may be the case. There's probably something odd in my test setup that I've somehow worked around by rearranging this code, but I'd love to hear any theories on what. In the worst case, though, it may be a bug in the CA. The test in question is here: http://dev.plone.org/plone/browser/plone.app.iterate/trunk/plone/app/iterate/tests/test_iterate.py The ZCML is here: http://dev.plone.org/plone/browser/plone.app.iterate/trunk/plone/app/iterate/configure.zcml And the code above here: http://dev.plone.org/plone/browser/plone.app.iterate/trunk/plone/app/iterate/copier.py Martin ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: run-time adapter registration and un-registration
Chris Withers wrote: Philipp von Weitershausen wrote: Interesting. plone.portlets actually uses the Component Architecture and a persistent registry as the underlying "plugin system", it just provides a fancy UI on top of this to manipulate the registry. Is this an adapter registry, a utility registry or both? What about subscribers? Does it still get the same performance optimisations as the global registries? It's just the local component registry. I don't know if it's optimised or not, but I assume so. As it happens we register adapters and utilities, but it could do subscribers (which are really just adapters anyway) as well. Martin ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] zope.app.form generates invalid HTML
Hi guys,
I'm pretty sure you're not allowed dots in ids of HTML elements. At
least not when they are prefixed by 'form'. A zope.schema.TextLine in a
formlib form, for example, generates HTML like this:
In particular, we want to style the fields to look a bit more like
Plone, and we have special cases for "title" and "description" that we
want to style by ID, not class.
However, CSS like this has no effect in Firefox or Safari:
#form.title {
font-size: 160%;
font-family: ;
font-weight: normal;
width: 99%;
}
#form.description {
font: 100% ;
font-weight: bold;
height: 6em;
width: 99%;
}
Not all that surprising - it could look like I'm styling a form with
class="description".
I then hacked zope.app.form.widget's renderElement() function to look
like this:
def renderTag(tag, **kw):
"""Render the tag. Well, not all of it, as we may want to / it."""
if 'id' in kw:
kw['id'] = kw['id'].replace('.', '-')
...
The tests in zope.app.form still pass.
Hacky, but the alternatives are to (a) override all the widgets or (b)
at least provide custom ones only for the purpose of getting stylable
ids on various fields. renderTag() is called from a lot of places with
id=self.name. We could fix all those, too, of course.
I would be happy to submit a patch for either the explicit check in
renderTag() or for changing all calls to this in zope.app.form.
However, if someone has depended on the ids being with dots (possibly
not quite as likely as it may seem, since these forms are typically
auto-generated) then we may not have a decent way of deprecating that.
Martin
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] zope.app.form generates invalid HTML
Tres Seaver wrote:
>
>> I'm pretty sure you're not allowed dots in ids of HTML elements.
>
> The attached HTML and XHTML pages both pass the W3C validator (one HTMl
> 4.01 strict, the other XHTML 1.0 strict). Both use dotted IDs for form
> elements. Neither renders "properly" in Firefox 1.5 (the selectors
> based on the dotted ID, as well as those based on attribute, don't get
> applied the form elements).
>
>> At
>> least not when they are prefixed by 'form'. A zope.schema.TextLine in a
>> formlib form, for example, generates HTML like this:
>>
>>
>>
>> In particular, we want to style the fields to look a bit more like
>> Plone, and we have special cases for "title" and "description" that we
>> want to style by ID, not class.
>>
>> However, CSS like this has no effect in Firefox or Safari:
>>
>> #form.title {
>> font-size: 160%;
>> font-family: ;
>> font-weight: normal;
>> width: 99%;
>> }
>> #form.description {
>> font: 100% ;
>> font-weight: bold;
>> height: 6em;
>> width: 99%;
>> }
>>
>> Not all that surprising - it could look like I'm styling a form with
>> class="description".
>
> Not according to the CSS specs. Note that we might be better off making
> it easy to place a custom CSS class on the widget, rather than fighting
> browser failures on various other selectors.
>
I had another look at the specs, and I agree that dots should be valid, but
it's pretty horrendous that neither Firefox nor Safari will let me style
that. If I've messed up the CSS syntax, let me know.
- -1 on changing the default behavior; to paraphrase, "broken browsers
you will have always with you."
+1 on changing 'renderTag' to use some kind of "local" policy (e.g.,
look up an 'ITagElementCleaner' utility) to spply such transforms.
E.g.::
def renderTag(tag, **kw):
cleaner = querytUtility(IWidgetTagCleaner)
if cleaner is None:
kw = cleaner(kw)
...
Yeah, this is nicer. I'd be happy to supply a patch for this. It would also
suport the case where you wanted to other "standard" transformations on
attributes.
I'd like to understand what the chances are of Plone 3 (whch will run on
Zope 2.10.x, whichever is latest when Plone is released in mid-May or a bit
later) being able to depend on this. We may need some kind of monkey patch
in Plone if it can't go into a real Zope release in time,
Martin
--
View this message in context:
http://www.nabble.com/zope.app.form-generates-invalid-HTML-tf3276583.html#a9117875
Sent from the Zope3 - dev mailing list archive at Nabble.com.
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: zope.app.form generates invalid HTML
Andreas Reuleaux wrote: Try #form\.title I had no idea you could do this. Thank you! It works like a charm. I'll shut up now. :) Martin ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Google Summer of Code
Philipp von Weitershausen wrote: Dear developers of Zope, Google is doing Summer of Code this year again. With an entity like the Zope Foundation in place, Zope could participate for the first time. Awesome :) I was involved in running Plone's process last year, and will probably do so again this year. We did learn a bunch of stuff, so catch me on IRC or drop me a mail and we can talk about a few do's and dont's when it comes to picking students, picking projects and picking mentors. Martin ___ 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: Google Summer of Code
Philipp von Weitershausen wrote: > > On 5 Mar 2007, at 09:48 , Christian Theune wrote: >> I've added myself too. > > Thanks. > >> I'd be interested in having some ZODB problem, >> although I'd like not to put the 'clean up the interfaces' burden >> onto a >> student project that ought to be interesting. > > Yes, I realized the same thing. There are lots of things to do in > Zope, but not all of them might be interesting enough for a student. > > I think it'd be cool to have a ZODB-related project, though. How > about improving gocept.zeoraid? > Is BLOB support definitely finished and in Zope 2.11? Plone is *dying* for this functionality. ;-) We were thinking about a Plone GSoC project around large file handling, though there may not be that much to it if ZODB BLOB support lands and is solid. Martin -- View this message in context: http://www.nabble.com/Google-Summer-of-Code-tf3345031.html#a9313188 Sent from the Zope3 - dev mailing list archive at Nabble.com. ___ 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: Google Summer of Code
Christian Theune-2 wrote: > > It's on the ZODB trunk already for a while. The current trunk is going > to be ZODB 3.8 and was already released as an alpha. And it will be the > ZODB that ships with Zope 2.11. > Wonderful :-) > I'm currently writing up a proposal for an extended Blob version that > implements O(1) runtime for two points in the Blob implementation that > are O(N) right now. > Perhaps this is a project for a certain type of student who may want to learn more about object databases? No idea what the scope is, but bear in mind that getting more people to understand the codebase and help maintain it in the future is a worthwhile goal in itself, SoC-wise. Martin -- View this message in context: http://www.nabble.com/Google-Summer-of-Code-tf3345031.html#a9355820 Sent from the Zope3 - dev mailing list archive at Nabble.com. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Eggs for deprecated packages
Jim Fulton wrote: On Mar 29, 2007, at 6:30 AM, Baiju M wrote: Hi, There are few deprecated packages in zope.app namespace, should we create individual eggs for those packages ? Yes. What about creating a single egg with all deprecated packges ? -1. We should be able to create the deprecated eggs once and forget about them. One possible benefit of having all deprecated things grouped somehow (perhaps not necessarily in one egg, what about having a BBB "virtual egg" that has dependencies on all the deprecated things?) is that it makes it easier for developers to test the effects of deprecation on their code. For example, the standard Zope 3 distribution could come with this egg not installed or not activated. If your code breaks on upgrade, you try to install/activate the deprecated egg, in which case you know you'll need to do something about your code, soonishly. Alternatively, it comes installed but you try to remove it to see if your package will survive the next version upgrade. We do similar things with skins in Plone, having a skin layer called plone_deprecated. Martin ___ 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: Eggs for deprecated packages
Jim Fulton wrote: > > > I think we need to have a much more basic discussion. > > IMO deprecation was a reasonable thing to try that hasn't really > worked out well. People find deperecation warnings to be very > annoying and I don't think it's going to be practical to make > backward-concompatable changes when eggs are used. I suggest that > generally, in the future, eggs should not be deprecated but just end- > of-lifed. When we are tempted to make a backward cincompatible to a > package, we should create a new one. Generally, there is little cost > in just leaving old packages around. > > Unfortunately, there are two poitentially significant costs in > keeping obsolete eggs: > > 1. They may break with newer Python versions. :( > > 2. The may be in the dependencies of other eggs. If they are used > internally, then, of course, the dependent eggs can be rewritten to > use newer non-obsolete eggs. In other cases, like zope.app, the > dependency exists to provide some feature and can't be removed > without introducing a backward-incompatible change to the dependent egg. > > Honestly, I'm not sure how to deal with these issues, especially the > later. Maybe for collection eggs like zope.app, we have to accept > deprecation and backward-incompatible changes, at least for a while. > Are you talking only about whole eggs here, or also about changes to APIs within eggs that are deemed to have a right to exist? Deprecation of APIs within a package works reasonably well as we do it now, imho. If you look at other systems, e.g. the Java APIs, deprecations tend to take place, though often deprecated APIs are never removed (which has the downside that they continue to clutter the namespace and sometimes they could be harmful by design). Deprecation warnings are important here, because it gives people a fighting chance of forward migrating their code. Without warnings, we'll have a lot of people that simply get locked into a version, and find that two or three versions down the line an upgrade would really mean a rewrite. Deprecation of entire eggs (e.g. we don't need it anymore, or we think it needs to move to a different namespace, or we want to break it up into smaller pieces or amalgamate with some other pieces to make a bigger package) is kind of a non-issue as far as eggs are concerned. Eggs are versioned, and people can always depend on specific "old" eggs even if they're not actively maintained or ship as part of the main Zope 3 distribution. As far as "the system" is concerned (whatever you want to call the system, but let's say that we mean the collection of eggs that we ship as Zope 3 and promote as a cohesive platform for people to develop on top of) I think we still need some type of deprecation when we decide to stop packaging up particular eggs. Say someone is used to downloading and using the standard Zope 3 distribution (or a particular distribution) - they will assume that all those packages remain there. When they upgrade, they don't want to suddenly find that something's gone missing. That's where I suggest we have a "deprecated-in-version-x" meta-egg that someone can depend on if they need to get particular packages that no longer exist in the form they used to. It can ship with Zope 3, ship disabled, or not ship but be documented as the way to get back the things that were moved, so that developers can understand the implications of package removals/end-of-life on their own code and have time to take action accordingly. Martin -- View this message in context: http://www.nabble.com/Eggs-for-deprecated-packages-tf3485561.html#a9751811 Sent from the Zope3 - dev mailing list archive at Nabble.com. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] A couple of documentation issues in zope.component
Hi guys, Not sure if I need to file these as bugs or not, but: 1. In zope.component.interfaces, unregisterHandler() is defined as: def unregisterHandler(handler=None, adapts=None, name=u''): but the implementation in registry.py is: def unregisterHandler(self, factory=None, required=None, name=u''): I was reading the interface and trying to pass 'handler' and 'adapts' as keyword arguments, which was failing. registerHandler() appears to have a similar problem. I haven't checked the other methods in that interface. 2. In zope.component's README.txt, the interface IValidation is like this: >>> class IValidate(interface.Interface): ... def validate(ob): ... """Determine whether the object is valid ... ... Return a string describing a validation problem. ... An empty string is returned to indicate that the ... object is valid. ... """ But the implementation is: >>> class SingleLineSummary: ... component.adapts(IDocument) ... interface.implements(IValidate) ... ... def __init__(self, doc): ... self.doc = doc ... ... def validate(self): ... if '\n' in self.doc.summary: ... return 'Summary should only have one line' ... else: ... return '' I think the validate() method in the interface should be parameter-less. Martin ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Releasing Zope 3.4
FWIW, and in case it's helpful to someone, below is a (bash) script I
use to release the eggs I manage for Plone. Nothing magical at all, but
it's worked well for me.
It's semi-automatic, meaning that it asks you to review each step before
an svn commit.
I use 'ploneout', a zc.buildout of Plone 3, which puts all eggs in a
src/ sub-directory. I run this script from that directory, using
$ ./release-egg.sh plone.portlets 1.0b1 1.0b2
That means, release plone.portlets (which is the egg name, and also the
directory name where the source egg is found) version 1.0b1, uploading
it to the cheeseshop with an egg and a source tarball, from a tag with
the name /tags/1.0b1. After completion, trunk is set to version 1.0b2,
for continued development.
It's worked pretty well for two Plone pre-releases. With this script, it
takes me 15-20 minutes to release 12 or so eggs. If I removed some of
the safeguards, which ask to review svn diffs before commits, it'd
probably cut the time in half.
Usual caveats apply, of course. :)
Martin
#!/bin/bash
svn_base="https://svn.plone.org/svn/plone";
package=${1}
version=${2}
new_version=${3}
branch="trunk"
if test "${4}" != "" ; then
branch="branches/${4}"
fi
tag_url="${svn_base}/${package}/tags/${version}"
trunk_url="${svn_base}/${package}/${branch}"
cd ${package}
function update_versions() {
echo
echo "Updating version in setup.cfg"
mv setup.py setup.py.old
cat setup.py.old | sed "s/^version = .*$/version = '${1}'/" > setup.py
rm setup.py.old
echo
echo "Updating any version.txt files"
for f in $(find . -name 'version.txt') ; do
echo "${1}" > ${f}
done
}
echo
echo "-> Please revise setup.py. Version will be handled separately."
${EDITOR} setup.py
echo
echo "-> Committing current trunk"
svn status
svn diff
read -p "press any key to continue"
svn commit -m "Updating setup.py"
echo
echo "-> Tagging release in subversion at ${tag_url}"
read -p "press any key to continue"
svn cp -m "Tagging ${version}" . "${tag_url}"
echo
echo "-> Switching to tag"
svn switch "${tag_url}"
update_versions "${version}"
echo
echo "-> Removing setup.cfg"
svn rm setup.cfg
echo
echo "-> About to commit changes to tag"
svn status
svn diff
read -p "press any key to continue"
svn commit -m "Updating version and removing setup.cfg for the tag"
echo
echo "-> Cheesing it up"
export COPY_EXTENDED_ATTRIBUTES_DISABLE=true
python setup.py egg_info -RDb "" sdist bdist_egg register upload
echo
echo "-> Switching back to trunk"
svn switch "${trunk_url}"
update_versions "${new_version}"
echo
echo "-> About to commit new version to trunk"
svn status
svn diff
read -p "press any key to continue"
svn commit -m "Updating version on trunk after tagging"
echo
echo "-> All done"
cd ..
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Releasing Zope 3.4
Philipp von Weitershausen wrote: I think we need some tools for this first. something that allows us to say: for packages x, y, and z do the following: Create a tag, change setup.py, and then create the egg. If we do not have this tool, every release will be a major pain. For 3.4, such a tool would certainly be cool because this will be the first time we'll be releasing lots of eggs at pretty much the same time. The question is whether it will also be the last time :). Please see my script that I posted in this thread. It does exactly what Stefan is asking for. It's just a straightforward bash script, I'm sure it could be generalised more and made more robust, but it's worked well for me over two Plone pre-releases managing about 12 eggs. Martin ___ Zope3-dev mailing list [EMAIL PROTECTED] Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Grok sprint 2 reports
Tres Seaver wrote: > > I think you just proved Martin's point: in my experience, maintaining > other people's AT-based code is like Napoleon before Moscow: thigh deep > in freezing mud. > By AT, I assume you mean Archetypes, and Archetypes doesn't depend on code generation, nor is it very hard to maintain other people's AT based code if it was well-written to begin with. Maintaining other people's badly written code is a pain no matter what tool they used to write it. :) If you're talking about ArchGenXML, which generates AT code from UML, it's not too bad. The code it generates is pretty clean, and if you decide to abandon code generation, there's a minimum of cruft (mostly a few comment blocks) that you can remove if you wish. Martin -- View this message in context: http://www.nabble.com/Grok-sprint-2-reports-tf2947404.html#a10103484 Sent from the Zope3 - dev mailing list archive at Nabble.com. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Zope 3.4, eggs and windows
Christian Theune wrote: Hi, I took Martin's script and adapted it for this release. Heh, I've been doing open source for a few years now, but I still get a slight buzz when someone from outside my "core constituency" makes use of some code I've written. :) Glad it worked out. If you have changes that you think are generally useful, let me know. I didn't check in the original in a Plone repository yet, perhaps I should, or we could just keep one version in the Zope repo if that's easier. Martin ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: yagni on overrides?
Leonardo Rochael wrote: If someone else presents me with an alternative zcml configuration for my package that was useful for their project, I can put this zcml file in my package for others to include when using it, instead of my default configuration. If there are parts in common between the default and alternative configuration, I'll refactor both configurations to make use of a common part (say, the browser cofiguration). Or maybe they're mostly the same except for some unwanted part (say, the subscriptions), then I can pull this part into a separate file that is included by my default configuration along with the other, more commonly used part. A few more iterations of these refactorings and soon enough my package will have configuration subsets that should be useful for most users of my package without requiring them to copy a significant amount of my configuration, and without requiring them to override any part of it. So, perhaps, we don't need powerful zcml overrides, just cooperative package maintainers (of which we have plenty in this community). That assumes that (a) there are meaningful "sets" of configuration settings and (b) that where people want to override something, it's likely others will need the same overrides. I've seen two use cases for overrides.zcml: - Zope 2 code needing to override Zope 3 adapters to do some Zope 2-specific stuff. - Custom code that (i.e. for a specific project) that needs to change the behaviour of some standard component. In the two cases above, however, I'm not sure the assumptions hold. Having 'configuration sets', if I understand you correctly, would mean keeping two sets in sync even if they only deviate slightly. That'd be cumbersome and risk dependency upgrades breaking things. Thus, it only makes sense if there is a maintainer to look after it all. But even then it would be cumbersome. You could have some kind of inheritance mechanism, of course. My set extends your one. That's not very different from an overrides.zcml, though. I have two "sets of configurations by having two overrides.zcml files and making sure only one is in use at any one time. :) When we *predict* the need for things to be overridden, we tend to make things overrideable e.g. with sensible interface modeling to allow a "more specific interface" override for an adapter or view, say. It's the unpredictable cases where overrides.zcml provides a useful safety valve. Martin ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: what dependency to use for "zope 3"
Brian Sutherland wrote: It's just going to get very difficult very quickly to manage such a meta egg with over 100 or so dependencies. Though I guess there'll be automated tools to manage this. Better we do the difficult part than each and every user does it. In the ideal world, there are no version conflicts. In the real world, there will be subtle version conflicts that mean that you can't just always get the latest release of each egg. Anyone who's used something like Gentoo Linux, with frequent and unsynchronized releases of different products know what happens when two packages require different version of the same library, or some automatically updated package suddenly remove the little bit of the API you were depending on. Put differently, you may know that you need zope.annotation and zope.app.content, but I suspect that most people won't quite know where to start, and won't quite know what's available to them. If they start with some particular dependency and start exploring the dependency graph, they'll probably miss something that's either standalone or on a completely separate dependency subtree to the one they're on. I think another alternative is to separate the releases into different "repositories", kinda like "All zope 3.0.0 eggs are at http://download.zope.org/distribution/3.0.0/";. Having eggs doesn't absolve us from doing release management. :) We still need to take some of the pain of testing and making sure there are adequate tests and making sure things work well together. It's part of the QA process (which Zope 3 has done immensely well to date, in my opinion). If that overall responsibility eventually falls on no-one, then I fear we'll lose the great integration power we have in Zope 3 at the moment. Most people just want a "known good" that they can depend on, where they know that changes are going to be limited to important bug fixes. They don't care if they get ten extra packages, what's a few megabytes of disk space. It's all well and good (great, even) that people can specify their own dependency subtrees (I need the annotation and component parts of Zope, I don't want the rest), not at least because it gives entirely different platforms a better chance of re-using our code, but someone still needs to look after the whole. There are too many packages to have independent maintainers who each (a) are available to do timely releases (b) don't forget to make release after a while and (c) are able to test that the code that is supposed to work with other things, continues to work with those things. Martin ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: what dependency to use for "zope 3"
Brian Sutherland wrote: On Fri, May 11, 2007 at 11:59:37PM +0100, Martin Aspeli wrote: Brian Sutherland wrote: It's just going to get very difficult very quickly to manage such a meta egg with over 100 or so dependencies. Though I guess there'll be automated tools to manage this. Better we do the difficult part than each and every user does it. I'm not saying "don't do it", but more "don't try do it by hand" or you'll burn out your release manager. A meta egg that only specifies a few dependencies is managable by hand, but a meta egg that exactly specifies over 100 packages and exact versions is not. If we are capable of managing a release of 100 packages now, and not in the future with eggs, that sounds like a step backwards for me. I think (to me!) a large part of the appeal of Zope3 is that it is a cohesive, well-tested, well-QA'd collection of libraries which solve an aweful lots of needs. If we devolve it all into little bits that live and die on their own, that may make life simpler for the now-possibly-out-of-a-job release manager, but the sum of the parts will be less than the current hole since undoubtedly some bits will stop playing so nicely together. I don't think this is the desire, though. What I'm advocating, is a careful definition of "the core", which is subject to synchronised release management, buildbots, eagle-eyed release managers and all the rest. Some things may then spin off outside the core, or into concentric layers of functionality managed by different sub-communities. But for the *user* of the library, there has to be a way to get a "known good" stable version, which promises some migration path when things change in the future. But I do think that a hand-managed super meta-package is a very difficult thing to do. I don't really care about the mechanism. You may well be right. But we need something. :) Add a meta egg with a few non-versioned dependencies to the above collection of eggs and it becomes a release (or multiple releases) :) Anyone, as long as they only download eggs from that URL, it guaranteed a set of eggs that works well together. So long as someone makes sure the meta-egg keeps working. Eggs with non-specific versions are scary, since a new version could be automatically downloaded and break everything. It requires control and consideration at some level. Bugfixes are simple, simply drop an egg in that directory. One very bad thing about such a URL is that it makes it very tempting for developers to upload forked versions of things like twisted, pytz or mechanize there. However, buildout's approach of "saving" a known good dependency tree is also reasonable: http://svn.zope.org/zc.buildout/trunk/specifications/repeatable.txt?view=auto Though I'm not sure how well it will deal with bugfix releases or allowing others to extend a release you make (i.e. plone on top of zope3). Plone is a good example, since, via Zope 2.10+ it is a consumer of Zope 3's libraries, but not its app server. I'd like to be able to say "my package requires the core of Zope, version 3.3". That may imply a few packages I don't actually use, but so what? Perhaps even buildout can become the method to create a directory of eggs/tarballs that will be a "release". We've thought about using buildout to create installers and tarballs for releases in Plone. Not sure what state that thinking is in. I'm sure both the "repository" and "saved" release types can be tested together automatically using buildout. One advantage of a lower level construct such as a meta-egg (or just a list of eggs withs specific versions?) is that it can be used more easily in a non-buildout environment. Martin ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Status update on b1
Christian Theune wrote: If anybody wants to take on one of the ones named above, feel free to use Jim's template for zope.app packages which lives in /Sandbox/J1m/zope.app-template. Have you guys thought about using Paste Script to create new packages? We do this for virtually all new Plone packages now, and it's a breeze. I wrote a how-to on it here: http://plone.org/documentation/how-to/use-paster If you want to add new Paste Script templates, feel free to add a new one to the ZopeSkel package, which is in the Plone collective. Adding a new one is fairly trivial. Martin ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Splitting package configuration
Stephan Richter wrote: On Wednesday 23 May 2007 12:24, Fred Drake wrote: "Official story" doesn't mean a lot to me these days. I think of individual ZCML files as interface points: someone might reasonably be using them directly (unless the filename starts with an underscore). But you are describing the internal ZC thinking here, certainly not something that has been widely or publically communicated. There are very few people out there using eggs. Perhaps that should change? :) I'm quite concerned that the "use-the-eggs-as-needed" approach, taken to its full potential means no synchronised releases and ultimately degrade the "library user experience" (how do you know where to start? how do you know what works with what?) for those not already experienced with Zope 3. However, eggs are great. They make it much easier to manage your dependencies. Things like entry points and egg script wrappers are very powerful. The Cheese Shop as a way of making releases is really pain free and much more conducive to making frequent releases. We've embraced eggs in a big way for Plone 3, and found the experience generally very postive. Most download a release, create an instance and drop the add-on packages in there, some using SETUP.cfg and others creating/copying the slugs by hand. FWIW, I've found it tricky to use things like z3c.widgets (or more accurately, a part of z3c.widgets, but that's a different story) because there was no egg to find, download and let buildout install for me. Martin -- Acquisition is a jealous mistress ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: "for" attribute not checked in zcml
Christophe Combelles wrote: Hello, Many zcml directives have a "for" attribute, which take an interface as argument. Absent-minded people like me sometimes happen to put a real class instead of an interface in the "for" attributes. * On browser:page, one can put a real class with no error. Is it correct? Yes. Browser views are just adapters, and adapters can be registered for a specific class, as well as for an interface. Think of a class as being an interface which is implemented by a single class only (itself). * On browser:containerViews, that lead to a non explicit error : Error object: list.index(x): x not in list I'm not familiar with this directive, but it sounds like a bug, or if it really isn't supported here, then it should throw an error. Is there a possibility to check this thing during startup, when zcml is parsed? That would save time finding out what the real problem is. It's a feature, not a bug. :) Martin -- Acquisition is a jealous mistress ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: ISite misplaced in zope.app.component.interfaces
Fred Drake wrote: I think "site" is widely understood term in Zope 3 now and everyone knows about it. We gain absolutely nothing by renaming it. I think "zope.site" would be a great package name for "ISite" and friends. Widely understood, yes. Frankly, I've *never* liked it, because it doesn't tightly relate to my more casual ideas on what a "site" is on the web. It compontent registry *can* represent a site in that sense, but that's as much an implementation detail as anything (IMO). The existing APIs certainly can't change, but I'd love to see more reasonable name used for a new package that's less tied to supporting web applications. FWIW, I recently had to explain the concept of a "site" in Zope 3 and how a Plone site root object is a "site" that has a "site manager" and ... it got very confusing. Martin -- Acquisition is a jealous mistress ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Heads up: major change in zc.buildout policy for selecting distributions
Jim Fulton wrote: I'm about to make a new release of zc.buildout that uses a different policy for selecting distributions. In particular, by default, zc.buildout will now prefer final distributions over non-final ones. If there are final and non-final distributions that satisfy a requirement, buildout will, by default, select a final distribution even if there are non-final distributions that satisfy a requirement. This release will cause many existing buildouts to use older distributions than they do now. You can change this behavior by providing a prefer-final buildout option: [buildout] prefer-final = false How will this be versioned? It'd be helpful if it were a different major (or at least minor) version than the current one, to make it easier for people to stick with a version that has the policy they normally use. Other than that, +1 for this policy change. Martin -- Acquisition is a jealous mistress ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Heads up: major change in zc.buildout policy for selecting distributions
Jim Fulton wrote: On Aug 20, 2007, at 2:18 PM, Jim Fulton wrote: On Aug 20, 2007, at 2:02 PM, Martin Aspeli wrote: Jim Fulton wrote: I'm about to make a new release of zc.buildout that uses a different policy for selecting distributions. In particular, by default, zc.buildout will now prefer final distributions over non-final ones. If there are final and non-final distributions that satisfy a requirement, buildout will, by default, select a final distribution even if there are non-final distributions that satisfy a requirement. This release will cause many existing buildouts to use older distributions than they do now. You can change this behavior by providing a prefer-final buildout option: [buildout] prefer-final = false How will this be versioned? It is 1.0.0b29. (The buildout version numbers are a bit of a mess, as I was overoptimistic when I made the initial "beta" release. Hm, maybe I should start using "e"s. These could be eek release. ;) It'd be helpful if it were a different major (or at least minor) version than the current one, to make it easier for people to stick with a version that has the policy they normally use. Maybe I should have, but the release is out of the barn. If this ends up causing too much pain, I could back this out by making a "b30" release with the old policy, although, I'd rather not. No, I'm wrong, I'm going to back these changes out with a b30 release and then release them with a 2x release. Thanks. :) b29? /me recalls ICQ Martin -- Acquisition is a jealous mistress ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: RFC: Known working sets
Philipp von Weitershausen wrote: Philipp von Weitershausen wrote: Deliverables * zc.buildout's extends mechanism would have to be enhanced to be able to load files from HTTP locations. Apparently this already works, I just tested it. I did not bother trying this out before because I didn't think buildout already supported it. Yay! That's quite cool, but I still see a couple of downsides with this. - It only works through buildout. Ideally it would be supported at the setuptools level, imho. - I worry that the management of lots .cfg files could be cumbersome. For Plone, we could probably generate one from the dist_plone package, which otherwise lists "known working sets" for installers and plone.recipe.plone. - This doesn't really solve the dependency problem. I can't say, "Give me Plone 3.0.1 or newer" in a third party package. That could probably done by having a separate "Plone" meta-egg which uses >= type dependency specifications, though. All in all, it looks like a workable solution, though. I'd like to try it out in practice, certainly. Martin -- Acquisition is a jealous mistress ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: What does python 3000 mean for zope?
Tres Seaver wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Philipp von Weitershausen wrote: Philipp von Weitershausen wrote: The ExtensionClass changes are not done, and I think there are other C-level changes which have not It was never said whether Zope 2 would be part of the GSoC project or not. That said, we can't drop Python 2.4 support until ... we've made sure Zope 2 runs on Python 2.5... How are you getting ExtensionClass working? Last I looked, the C extension didn't compile on 2.5. Bad posting by philipp - he was finishing the sentence he forgot in the previous post. Zope 2 does not run on Python 2.5. Martin -- Acquisition is a jealous mistress ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: RFC: Known working sets
Hi Philipp, - It only works through buildout. Ideally it would be supported at the setuptools level, imho. I'm not really convinced that that's necessary. From a practical perspective, zc.buildout is the defacto deployment tool in the Zope community. Alas, not so for all Plone people: Some folks prefer workingenv's in old-fashioned Zope (2) instances, some people use instancemanager, some people still symlink into lib/python. Also, working sets have "deployment" written all over it. Good point. setuptools has little to no machinery to aid automated deployments in any way. True. However, I think it's also legitimate to want to "depend on" a complete "working set", which is more in setuptools land. But I see no problem in solving this at a buildout level first. That said, Wichert's proposed solution to put the information in EGG-INFO would make it open for use by other deployment tools, even setuptools. True. - I worry that the management of lots .cfg files could be cumbersome. For Plone, we could probably generate one from the dist_plone package, which otherwise lists "known working sets" for installers and plone.recipe.plone. Well, or the other way around: the installers could take the .cfg file of the working set and grab the right packages according to that. After all, a .cfg file can be read with ConfigParser quite easily. Yeah, true. It's just that everything wants to be the "one true place". In the Plone land, having to cater to non-buildout deployments may make that harder, but like you said - .cfg files are pretty neutral. - This doesn't really solve the dependency problem. I can't say, "Give me Plone 3.0.1 or newer" in a third party package. That could probably done by having a separate "Plone" meta-egg which uses >= type dependency specifications, though. Yes, this could be covered by a Plone egg (meta or not) and a "Plone>=3.0" modifier that's put in the 3rd party package's setup.py (I think the >=, <= operators can be valid in setup.py, just == isn't). Right. Anyway, like I said - I'd like to see a working version of this approach; Plone could quite usefully use it, imho. Martin -- Acquisition is a jealous mistress ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: RFC: Known working sets
Philipp von Weitershausen wrote: I trust by "this approach" you mean the EGG-INFO approach? Because the stuff I proposed originally already works... Actually, I meant your proposal: I'd like to see a concrete example of it, and a workable process/policy for managing releases in this way; and then I'd like to bake that into plone.recipe.plone. :) Plone's release management stuff needs a bit of a re-jig to avoid some duplication/management overhead anyway. Martin -- Acquisition is a jealous mistress ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: RFC: Known working sets
Chris Withers wrote: Jim Fulton wrote: On Sep 5, 2007, at 10:48 AM, Chris Withers wrote: Jim Fulton wrote: I'm very much against making setuptools *more* complicated than it already is. Indeed, but surely managing "known good" sets of components comes under its remit of version management? Sure. It does this via requirements. Ok, forgive me for being dumb then, but why are we looking to add similar to zc.buildout? We're talking more about a general pattern in zc.buildout. The deficiencies of using setup.py for this alone are described well in the original proposal. Martin -- Acquisition is a jealous mistress ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: What does python 3000 mean for zope?
Lennart Regebro wrote: I'm hoping that Guido will see the errors of his ways, and introduce a Python 2.7 that has more forwards compatibility than what has been promised for 2.6, so that there can be a useable overlap between Python 2.7 and 3.0. Maybe a 3.1 with some more backwards compatibility will be needed to, I don't know. DISCLAIMER: I'm not very close to the core Python/language community, nor have I paid much attention to Py3K. Has there been a strong statement that there won't be a Python 2.7 and beyond? Will Python 2.x be actively killed off? In the discussion on Python 2.x and 3.x compatibility, substitute the word "Zope" for "Python" and think of the irony. Maybe it would've been better if they'd called it Cobra 1.0. Then we could've lived happily in our cohesive Python community. ;-) Martin -- Acquisition is a jealous mistress ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: What does python 3000 mean for zope?
Paul Winkler wrote: On Sun, Sep 09, 2007 at 05:39:45PM +0100, Martin Aspeli wrote: Has there been a strong statement that there won't be a Python 2.7 and beyond? Will Python 2.x be actively killed off? Quite the opposite, Guido proposed last year to do 2.7, 2.8, and 2.9. After that it's not clear to me. In the discussion on Python 2.x and 3.x compatibility, substitute the word "Zope" for "Python" and think of the irony. I'm still waiting for the announcement of Python "Five" :-) I suggest we call it Python -1; 2 - 3 = -1. Martin -- Acquisition is a jealous mistress ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Proposal, free views
Roger Ineichen wrote: Heads up, Please review this proposal. I'll implement it shortly if nobody has objections. We need it for our work here at the Foliage sprint. If you have objections, please tell me what you think is not well done and tell me your ideas to solve the problem in another way. http://wiki.zope.org/zope3/FreeViews I read this, but I still don't understand what you're proposing. Is this about moving component registrations around in the standard Zope 3 packages, or are we talking about new functionality here? Martin -- Acquisition is a jealous mistress ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: AW: Proposal, free views
Roger Ineichen wrote: * Simply *ignore* that they exist. Zope actually has facilities for doing this on a technical basis. Simply don't inherit your skin from IDefaultBrowserLayer, and voila, you won't get any pre-configured views at all. I can't have unused code in our codebase. We have swiss banks as customers and can't pass their security assesment with such a setup. Belive me, it's not easy to fit their needs. * If you're interested in replacing a few select views with your own implementations, you can use ZCML overrides. Or use layers (which is a similar solution to the previous one). Same here, we can't have unused code in our codebase. This will increase the security assesment and I don't like to write more documentation for them. I assume you mean you can't have any unused component active/registered. The code is still going to be there, unless you fork Zope 3 and remove the files you don't need, in which case this proposal isn't going to help you much anyway. I think it makes sense to introduce a pattern that makes it easier choose which components you need. However, if I understand you correctly (and I second Philipp here - the proposal is confusing as it's worded now), you're talking about refactoring the ZCML of every package that uses browser components. I understand there's full backwards compatibility (via includes into the root configure.zcml), but it's still a slightly risky and time-consuming dance. Martin -- Acquisition is a jealous mistress ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Known working sets II [was: Eggification redux]
Jim Fulton wrote: Would it be possible for buildout to retrieve such a list from an egg if it's maintained as an extra, made-up setup.py variable? I just tried this, but it doesn't seem to be stored in egg-info. In theory, but not today. Your use case would be better served by adding a way to tell buildout to use a package version even if it violates some requirements, FWIW, Plone has this problem too - we have a number of packages which are eggs, and some which are Zope 2 products. Our "tactical" solution is plone.recipe.plone[1]. Basically, this has a known-good working set of versions and will peg to releases (using the == version specifier). However, the recipe will also allow you to override versions by explicitly specifying eggs. That's good for developers and power users who need to use a later version, but we "strongly prefer" known good working sets. Of course, plone.recipe.plone has some problems (mainly, it's a product-specific recipe, and we need to release a version of the recipe for each version of Plone), but I could see something like this working (forgetting for a moment that Plone also has non-egg dependencies to think about): - We release the meta-egg "Plone", version 3.0 - In its setup.py I have a set of dependencies (the known-good working set) which works for Plone 3.0, our supported, proper release. This could just be the normal install_requires dance, with == dependencies as the norm. - Buildout allows me to override some of those eggs with some specific syntax, e.g.: [eggs] ... recipe = zc.recipe.egg eggs = Plone==3.0# get all of Plone 3.0's eggs as hard versions plone.portlets==3.1 ! # override the dependency from Plone 3.0 The ! syntax here is an invention, but something like it - it's now explicit that I'm overriding and I know what I'm doing. Without it, buildout would complain about a version conflict. Further, if I had both Plone and FooBar in the eggs list, and both depended on (possibly different) versions of plone.portlets, the ! syntax would allow me to explicitly override *both*, if I knew that really this version was compatible with both. Presumably, setuptools could support this behaviour and syntax natively as well one day, but we could get it into buildout first. I like this approach better than the HTTP-fetched 'versions' spec because (a) it doesn't depend on an external connection and we don't have to maintain some URL where this is stored (a lot of smaller projects may not have a sensible place to even make it available from) (b) it's part of the Plone meta-egg, which we could release to the Cheese Shop as a meta-egg that lets people get a "known good" Plone (c) other packages can simply depend on Plone==3.0 and get the normal behaviour. This doesn't really address Tres' point about collecting "known good" sets in a more decentralised, graph-like way, but it ought to work for people (like Zope, Grok, CMF and Plone) that want to provide their users with a solid release, without making it impossible to sidestep it if you know what you're doing. Martin [1] http://cheeseshop.python.org/pypi/plone.recipe.plone -- Acquisition is a jealous mistress ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: [Zope-dev] I'd lobe to merge the zope3-dev and zope-dev lists
Michael R. Bernstein wrote: On Thu, 2007-10-04 at 19:32 +0530, Baiju M wrote: Jim Fulton wrote: Any objections? This would basically involve retiring the zope3-dev list and moving zope3 developers to the zope-dev list. +1 What about retiring #zope3-dev IRC channel and only using #zope ? No. #zope is roughly the equivalent of the main zope list. There is no #zope-dev channel. Now, someone might suggest that the zope3-users list should be merged with the main zope list, but that someone wouldn't be me. At least not as long as there are separate releases being made. In Plone, we have a -user and -dev list, and a single chatroom, #plone. We do have #plone-framework for the framework team and release manager, but this is much quieter and everyone who's in #plone-framework is also in #plone. Obviously, this is about preference, but we find that having everyone in the same chatroom helps keep people in touch. Reading multiple mailing lists is not so hard - paying attention to multiple chatrooms at once is, and a -user room is pretty much useless if there are no experienced developers paying attention. Also, on the subject of renaming things: Calling it zope-devel or similar may not be ideal, since people who develop with Zope (don't we all?) assume this is for any developers, not just core developers. Something like zope-general and zope-coredev may be better. Martin -- Acquisition is a jealous mistress ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Retaining ease of customisation
Hi all, First of all, a couple of apologies: for the cross-post, but I think this concerns all these groups; for my ignorance: I'm only starting to scratch the surface of Z3, via Five, coming from Plone; and for dragging this out again. However, I think this is important.; and maybe for the length. :) As open source developers, we are dependent on an influx of new talent. That talent starts when people get interested in our products. I got a whiff of Plone for a project, played with it, loved it, learnt about it, and before I knew it, I was a core developer. If ever I have the chance to help out Z3-core, it'll be by way of this path, too, and there are many like me. However, the initial hurdle is quite steep. I really liked the Z2 way when I first learnt about it, and I love the Z3 way even more now that I'm digging into it. But Zope uses obscure technologies that no-one's heard of, no matter how good they are. Hence, anything to lower the burden of entry should be viewed as important, but it's all too easy for those of us who once climbed the hill to be excited by ever-better ways of doing things that we sometimes forget what the learning curve was like. I'm already trying to formulate how we can document to new Plone developers how to take advantage of the Z3 component architecture via Five, and explaining the mind-bend required to think in terms of adapters is actually not so simple. :) But I digress. I think for a lot of people, what drew them to Plone and then Zope-based development was to ease with which one could re-use and override elements of the application, especially the UI. Take a look at http://plone.org/documentation/how-to and see how many of the user-contributed documents are from people who say "I'm not an expert, but I figured out ..." and then go on to talk about portal_skins/custom. Ideally, we'd like to make everything people want to do available with a nice UI, but this is unrealistic. The things people write about in those how-tos are the things real users want to do, and they find low-impedance ways of achieving them with through-the-web customisation. So, when my customer wants a portlet, he discovers that he can copy-and-paste an example he saw on the web into his browser and edit a text box in the ZMI, and suddenly he has his portlet. Okay, that scares me a bit, but it's actually really important. If he had to go to the filesystem, set up a folder with some arbitrary structure, enter some boilerplate python code, remember to name files __init__.py and make a crazy configure.zcml with funny angle brackets, well, frankly, I think he wouldn't bother. More work for me, perhaps, but he could just as easily have been the next optilude, learning, tinkering, testing, exploring and finally contributing something valuable. The arugments against TTW, at least in its CMF 1.x form with portal_skins/custom or, worse still, page templates scattered through a content structure with acquisition magic, are clear. But that doesn't mean the concept isn't valuable. The thing that scares me is that as we move to use more Five/Z3 Views in Plone, those templates stop being customisable through the web. And the more obscure and complicated it becomes for a new user just to change a minor element that can't be fixed with CSS etc. or some setting in the UI, the more likely that user is to give up. I think there needs to be a solution for making quick, preferably TTW customisation of UI templates. As Tres pointed out, this shouldn't add a performance overhead and lead to maintenance woes for those who know what they're doing. Ideally, the site admin should be able to switch this off. Or even, the view creator should have to turn it on (e.g. by using a ZCML directive that makes a template TTW customisable. Or something). I know this strays away from best practice, that people will slap in crazy python: statements in TAL etc. Having a way of dumping this stuff to "real" views would be good, even necessary. But I think ignoring these users because the approach that's most accessible to them doesn't fit with the purity of our framework will seem to them elitist, and it'll probably drive more people to ruby-on-rails, who sell themselves on how easy it is to get started. I don't know how this may work, or whether it should sit in the Z3, CMF2 or Plone 2.x layer of the stack. My hunch is CMF, but I'd like to challenge those more in the know to explain how Z3/CMF/Plone can still accomodate these users, without hurting the more seasoned developers at the same time. Thank you, Martin -- (muted) ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope-CMF] Re: [Zope3-dev] Retaining ease of customisation
> I'm just a tiny little bit confused here, what is a view and what is a resource - in Zope2 and in Zope3 ? > > Maybe I just don't know enough about Zope3 (or 2), but to me what JM calls a view is a resource, and vice > versa... anyway, I think it's a good idea to have the conceptual discussion now based on use cases, and > here's my 2 cents. Hopefully someone can then explain what's what. > > I'm playing around with Plone2.1 and CPSSkins at the moment. Plone has some very nice new features like > LinguaPlone and the new extended content_actions bar (the bar containing the dropdown menus for > workflow actions, cut/copy/paste, add content and manage translations etc.). I agree that CPSSkins is a nice solution, and may well become more prevalent in Plone, but as you've discovered, even this won't afford total flexibility in defining exactly what you want. What I'm worried about is this: People, myself included, come to Plone (probably the same story for CPS etc.) and see that it does 80% of what they want. Then they customise the CSS and that gets them to 90%. For the last 10%. They add some templates, 95%, and then they realise that they'll have to change some of Plone's markup in a way that isn't readily customisable. The thing that makes Zope as a platform so attractive, is that they can very easily say, "global_contentmenu.pt is where the menu is" (okay, so finding that is harder than it should be, but once they know...) and they can override that bit of ZPT in a new skin layer in portal_skins. They can do this very easily with portal_skins/custom TTW. A lot of people go with Plone initially based strongly on how easy it is to customise and re-use elements of the UI. I really don't want to take that incentive away from them. Yet, as I understand, if global_contentmenu.pt was implemented as a View, they couldn't customise it TTW and it would be more difficult (in fact, in my journey through the Five and some of the Z3 documentation, I've yet to discover how) to override this even if they were prepared to set up a bunch of directories and XML files. So, whilst CPSSkins probably is a long term better solution for many of the original use cases, it's unlikely to form a core part of the Plone UI in the near future, and indeed unlikely to be appropriate for every type of application. In the interest of evolution, I'd like to find out how to make it as easy as possible for people to override templates that are parts of views. Unfortunately I'm still lost. :) Martin ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Proposal: Enhance tracebacks in persistent logs
On Thu, 19 Jan 2006 18:46:29 -, Chris Withers <[EMAIL PROTECTED]> wrote: I'd love to see this At some point I want to do something that lets you optionally use .conf format instead of .zcml, I reckon the above would help but my foo is way too low right now to be able to help out with it :-S ... and thus confuse all the people trying to learn Zope 3 by seeing two fundamentally different file formats that do exactly the same thing? Anyone trying to understand anyone else's code would have to learn both anyway. Yay. Martin -- (muted) ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
