Re: [Zope3-dev] One namespace for ZCML
On 2/13/06, Stephan Richter <[EMAIL PROTECTED]> wrote: > On Monday 13 February 2006 07:57, Philipp von Weitershausen wrote: > > Yet again looking for comments, this time at: > > http://dev.zope.org/Zope3/OneNamespaceForZCML. > > -1 > > Here some comments: > > - You do not argue how the decision-making process is "highly inconsistent". > > - I do not understand what's so bad about coming up with your 3rd-party ZCML > directives. They are extremely easy to write and use. I think that 3rd-party > ZCML directives are not a bad thing. And yes, I would like to keep those in a > separate namespace. I am also -1. But I take issue with your second statement. ZCML directives are the hardest and scariest code in Zope 3 to understand. It was easier to figure out what was going on with multi-adapter lookup than to figure out how menuItems work! (I lost a day trying to figure out if I could just put a javascript condition on a menu item before coming up with a glorious trick). I still HATE magical ZCML. But I still think ZCML is a good thing and should be modularized. Simplified - yes. Modular (namespaces) - yes. ___ 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: Last chance to comment on Simplify skinning
On 2/15/06, Philipp von Weitershausen <[EMAIL PROTECTED]> wrote: > I find Zope 3's approach much simpler and much easier to explain than > the CMF's approach. In Zope 3 (especially with my proposed changes in > place), a layer is simply a label (read: marker interface) on the > request. When we now look up pages and resources (e.g. images), we take > the request into account and therefore inevitably that label. We will > only find pages and resources associated (read: registered) for this > label. Good news is that any page or resource can be associated for this > label, we just have to remember to do that in their ZCML directive. When you say "with my proposed changes in place", I don't understand how that differs from what currently exists, or what can exist. We at Bottlerocket started serious Zope 3 work with Zope 3.1. We've been defining skins and layers as Interfaces since that time. I didn't understand it entirely at first, but when I was debugging some issues that arose with a fix to multi-adapter lookup that came in Zope 3.2, I understood it more, and now it makes a lot of sense to me. So coming from that world, I'm not entirely sure I understand how your proposal is really different, except for this: In your proposal, 'Skins' are just gone as a separate concept - yes? What is now treated as a Layer can also be treated directly as a skin, yes? Here's a situation from a recent application of mine. The comments and doc strings are verbatim. Notice that I leave a number of breadcrumbs behind about which is the skin and which is the layer:: # Layer class KBase(IBrowserRequest): """ The ``kbase.skin.KBase`` **Layer** """ # Skin class KnowledgeBase(KBase, CMS, IDefaultBrowserLayer): """ The Knowledge Base Skin. Uses the CMS layer, but **not** rotterdam. The Knowledge Base skin is very specialized and does not need as many generic features as the Content Management or default ZMI skins. The primary dependance on the CMS layer is to get its resources (javascript libraries, icons). """ I assign most things in my application to the KBase layer. The KnowledgeBase Skin builds from three layers. Very early versions of this app did a mix of layers and skins in the bases used for ``KnowledgeBase``, but the skin it used brought in too many views that I didn't want interfering with things accidentally, so I went with the ``CMS`` layer instead so I'd get things from our CMS layer, but not get *everything* that was chosen for the *Content Management* skin. Does that make sense? If I understand your proposal correctly, the Layer and Skin above would both basically be the same thing, right? The only thing that I guess really differentiates them right now (in my application) is how they're registered in ZCML. But they're each the same basic collection of interfaces. ``KBase`` is shallow and dedicated to the browser view/resource components in my application, ``KnowledgeBase`` is rich and pulls in components from others. The only thing that I don't understand right now is this concept of Interface Types. I don't have our Zope 3 book in front of me right now, so I'm not sure if it has anything helpful to say. But I'll just say that Interface Types have been an elusive concept for me, so far. -- Jeff Shell ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Zope 3 web root
On 2/10/06, Shane Hathaway <[EMAIL PROTECTED]> wrote: > Chris Withers wrote: > > I'd flip that, because I think you and Steve A would agree on one thing: > > The use of an object database _should_ be a choice, not a requirement, > > but it should also be the default ;-) > > Actually, I disagree--I don't want an object database to be the default. > An OODBMS is good complexity for some projects and bad complexity for > others. Let people first choose the thing they're familiar with (the > filesystem), then make it easy for them to branch out toward an RDBMS or > OODBMS. This is frustrating to see. At least, in the concept of 'Zope' as the full application server it is. Others have brought up the concept of 'Bobo', and I would much rather see that. There are situations where I don't want the ZODB. We have our own data management layer for very very very very complex RDBMS interactions. We have a Zope 2 gateway to this layer right now and then acquisition and other wonderful tricks allow templates/scripts to be picked up and applied to the resulting data. We want to move it to Zope 3 to take advantage of the concept of Views and, most importantly, have all of the templates on the file system. But we really don't need all (or most) of zope.app. Containers, Sized, Catalog, and so on and so on and so on, really don't apply. I know it's *possible* to not use all of that, but just *how* to do it, I don't know. A Zope that was basically zope.publisher, zope.component, zope.interface, zope.schema, and tal/tales (and maybe 'transaction') would be ideal. Your idea terrifies and confuses me. I think I just don't like this 'Newbie comes in and ...' talk. It's so generalizing. These days, I find myself being THWARTED at many turns by the magical special browser: ZCML directives that were to make life easier for newbies. Yeah, they helped me in the beginning. And now I'm pulling my hair out. Don't thwart me! I'm not saying that helping new people is a bad thing. But why push all of these new concepts on them AND seasoned developers like me? Personally, I think that the ZODB is a terrific asset that has achieved a greater level of usability in Zope 3. At least, it has for us, now that we're no longer confused about whether the ZODB should house our persistent objects, or if it should house our icons and scripts and code and the RDBMS should be the store. I wouldn't want to downplay this advantage. Anyways, I believe fervently that a totally pared down version of Zope that was just the basic stuff as mentioned above (zope.publisher, zope.component, etc) would be a good target. That's something I understand. What you describe, I don't understand. > Do you mean "_just_ an RDBMS if you so desire"? We don't want to force > people to use an ORM either. > > Flat files are everybody's land. Our flavor of flat files will be > engineered to ease the transition from flat files to a Python package. Huh? This is sounding like the "but everyone just likes and wants PHP" talk. Maybe it's my fault for never wanting, nor changing, a 'default page' after installing an instance home, and I'm not the target audience. We use the ZODB for data and storage and it's so wonderfully easy in Zope 3 to keep all of that in the ZODB while all of the templates and views are on the file system that I've never thought much about fssync. - I WOULD LOVE TO HAVE EXPORT/IMPORT THOUGH! - (or fssync, but really more for backups or data updates...) And I guess we have the other odd requirement that we often don't have just a single root, or a single view of any particular site root. For our internal CMS customers, the public never sees anything close to the content management screens. 'admin' is thought to be a separate experience, even by our customers. But it's really just a different skin on the exact same data. Not really a root at all. I guess it's my fault for no longer really thinking in terms of "serving up pages," but rather "serving up your flight itinerary" or "serving up a list of related articles and who wrote them." I guess this is all kindof rambling. I just don't see any benefit to me. I'd rather see any effort like this pick up the zope.bobo branch/product or whatever it is right now and deliver a clean and simple stripped down zope publisher that could run on WSGI and could be used to show up all of those "but i can make a wiki in twenty minutes" tutorials and have no dependence on storage of any kind. ___ 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: Last chance to comment on Simplify skinning
On 2/15/06, Fred Drake <[EMAIL PROTECTED]> wrote: > On 2/15/06, Paul Winkler <[EMAIL PROTECTED]> wrote: > > Only that I have the same question Martijn does: > > Can I then override one of those resources and keep the other 34? > > Perhaps the resourceDirectory directive should just be sugar for a set > of resource directives, one for each file in the directory? That > would allow individual overrides, and maintain the convenience. I would prefer not. We've used resourceDirectory to support things like webcams. The image(s) uploaded by the cams might not always be there, but the containing path is. It's nice not having Zope start complaining on startup about making a resource for something that doesn't exist, and allows us to open up select file system points for resource uploads without having to know details about their contents. (We don't use this heavily, but it has been a nice advantage). If it was sugar for a set of resource directives, this could easily fail out on us, unless it was making 'resource' items all the time whenever the directory's contents changed. ___ 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 web root
On 2/10/06, Shane Hathaway <[EMAIL PROTECTED]> wrote: > Wade Leftwich wrote: > > +1 from the standpoint of promoting corporate adoption, especially when > > combined with first-class citizenship for RDBMS. (In the corporation I > > work for, anyway.) > > Yes, RDBMS would become a first-class citizen. New users would be able > to write some page templates and SQL scripts on the filesystem and have > them work with no extra effort. I know I'd like that capability myself. How? How "first class"? Does first class mean "supports SQLite level features"? "MySQL"? Then what happens when you have people needing to use real commercial databases who find a serious lack of support for the features that they want or need? How would you tie that in? Without offending those who just want to use SQLlite to store comments? Would it be all manual SQL statements? Would the be through an O-R layer? What about those (like my company) who have customers on RDBMS and other storage systems that have complex data handling and security requirements that go far beyond most O-R mappers (especially those that appeal to those just wanting a web page to have comments?) Would it be a pain in the ass to integrate a completely custom and different data management layer in? Would it be easy? "extra effort?" This smells like Zope 2 development, but without the ZODB. Just a bunch of little templates and scripts and SQL statements on the file system. The best day in many of Bottlerocket's Zope 2 era RDBMS applications was when we moved them away from both models. Being neither an O-R mapper, nor just full of endless similar SQL statements for basic CRUD stuff (but still using them, as methods on Python classes usually, for custom queries). Personally, I think that a Data Mapper layer that used zope.schema would be very effective. This is essentially what we built in Zope 2, using Formulator. Formulator ensured the data was in a clean / common format and satisfied any constraints, and a very simple layer generated SQL Methods on the fly based on the filtered down data that came in / out. If we migrate any of those applications to Zope 3 and keep the same data model, I easily see us doing it using zope.schema and doing directlyProvides or something like that on what is produced. It's not a situation that works for everyone. But it's one that works for us and is adaptive to different storage solutions. Our 'enterprise' level data management works on a similar level, but with a lot more transformations going on as data flows to / from its sources (and that data management framework itself has no dependencies on Zope, but a simple Gateway allows us to use it with Zope 2 while letting Zope 2 acquire the page templates, authenticated user, etc). Anyways, it's a scenario that I like because the data in these situations is more important to me than whether it looks sorta-like a Python object, yet the boring and repetitive operations are still taken care of. I agree that better integration with external data should be a priority for Zope. But what does that mean? In theory, if something's a Python object it should work with Zope 3 with relative ease... If that's not the case, perhaps we need to look at how much work is required to take some random Python object that may be created by some random data access library and get it into a Zope 3 published web page. If it kicks and screams and resists security and interfaces, or what not, maybe we need to take a look at all of that. If it doesn't kick and scream, we just need clear documentation that's neither too short nor too wordy about what to do... "I just installed cElementTree and have an XML document that I've turned into a Python object. How can I show that in Zope?" > However, I expect ZODB to continue to be the dominant platform for > writing Zope applications, because ZODB is quite productive for writing > abstract applications. ZODB is also very productive in Zope 3 for writing concrete applications. Now that our ZODB databases aren't polluted with a mixture of business objects as well as scripts, icons, sql, templates, etc, the ZODB is a joy to work with. It's very productive for writing NEW applications. I see these other tutorials for every O-R backed database and I'm thinking - "you're only creating a two column table to do a to-do list... why do you even have an RDBMS? you're not generating SQL directly and yay - it turns the todos into Python booleans and strings! Well, uh, again, why even have an RDBMS?" An application that I just completed would have actually been very hard with an RDBMS (especially as data requirements changed - 'can we have that field be in the leg?'). It would have taken me a lot longer to implement if I had to keep switching my mind back and forth between SQL and Python. THIS IS A HUGE ADVANTAGE! Why do we act like we're embarrassed by the ZODB? With zc.catalog, schoolbell.relationships, and vocabularies, I was able to make widgets that assign and remove
Re: [Zope3-dev] One namespace for ZCML
On 2/15/06, Chris Withers <[EMAIL PROTECTED]> wrote: > Stephan Richter wrote: > > I do not think namespace declarations are dead chickens. For me declaring a > > namespace in ZCML is the same as importing a package or module in Python. > > You > > would not want all functions and classes in Python live in one namespace, > > would you? > > The more namespaces, the more needs to be learned, the more confusion. > ZCML is not python, comparing the two isn't right. > > I'm all for simpler and simpler zcml... A single namespace with more options is not a better solution. THAT means more to learn, because now I have more options to sift through. When the units of work are segmented out to appropriate subsystems (and kept reasonable and free of magic), namespaces in ZCML are and could still be a good thing. Am I the only person who uses apidoc to look up what can be done with ZCML? Because honestly, finding out what directives are available and getting decent documentation about ZCML directives is the easiest thing in Zope 3. Understanding what's going on or what the real meaning of a particular value in combination with others might be - that's a different story. But finding out what namespaces are available and what the directives are has never been a problem. And I spend most of my apidoc time (when looking at ZCML) with the 'browser' and 'zope' nodes expanded. I rarely need the others ones. Less directives? Maybe. * Less "does a lot of things for you but offers no easy path to do some of the work yourself?" directives? Yes please. Less "similar to but varying by a couple of small details" directives? (browser:view and browser:page)? Yes please. One namespace for everything? No thanks. Especially if the reason is "I don't like typing those namespaces at the top of the file." Modularity is a good thing. Trust me! We don't need 100 namespaces, we don't need 50, but we can't lump it all in one. I still think that's the wrong fight to fight right now. * I don't mind directives that are easy to read by eye. Lumping everything into and is not going to make things easier to read. I like . I like . I just wouldn't mind the documentation saying is shorthand for ..., and can be done in pure Python and one line of ZCML by I'd also like to see documentation about when custom classes are created and why, and what to do if you don't want the ZCML to generate things for you.. It may have good reasons for generating things, I'd just like to know why. Because god knows, that's the code that I have the hardest time reading. (_discriminator this, handler_ that..). ___ 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 web root
On 2/16/06, Shane Hathaway <[EMAIL PROTECTED]> wrote: > Jeff Shell wrote: > > I agree that better integration with external data should be a > > priority for Zope. But what does that mean? In theory, if something's > > a Python object it should work with Zope 3 with relative ease... If > > that's not the case, perhaps we need to look at how much work is > > required to take some random Python object that may be created by some > > random data access library and get it into a Zope 3 published web > > page. If it kicks and screams and resists security and interfaces, or > > what not, maybe we need to take a look at all of that. > > Let me focus the discussion: I think it's nearly always a bad idea for > anyone, newbie or expert, to put a template or script in ZODB. Do we > have any agreement on that point? I wish we did. I enjoy ZODB for many > purposes, but not for storing templates and scripts. I agree, generally. For one customer, we (sparingly) use page templates in the content space of the ZODB. But those are usually only just one or two lines. Nothing fancy, nothing programmatic. But also not a situation that would require a special view object in that space. Other than that - I completely agree. Your proposal just sounds like you want to have things like we had in Zope 2, but as pages and scripts on the file system that are executed/rendered semi-automatically. And that seems like it comes back to a problem that existed with Zope 2. Ignoring the ZODB for the moment, there's just a bit of a gulf between "templates and scripts" and "browser view classes/components". > The obvious question is, "if templates and scripts are special enough to > not belong in ZODB, what else is so special?" It's really hard to say. > In fact, I can think of rare situations where I actually do want to > put templates and scripts in ZODB. Well, anything can theoretically be stored in the ZODB. You can put scripts and binary images into an RDBMS just as easily. Whether that's a good idea is a separate issue. I think that Zope 2 suffered heavily from the "too many ways to do it" when it came to ways of doing development, and there were gulfs between each style. Each style had its plusses too. ZClasses certainly had an appreciative audience who liked defining schemas and building forms automatically through the web with little programming required. But working with templates and scripts in ZClasses had a bit of a different feel and behavior than working with those things in the 'content' space of the site. And it was very different than working with file system based products. If there's one (and only one) dominant way of developing for Zope 3, that story is easier to tell. Do you want to make things "easier" for "newbies" by telling them "well, you can just put some scripts and templates on the file system, it's that easy!" and "well, if you want to really develop properly for Zope 3, you need to do this..."? That's where I think this "web root makes things easier for newbies" argument falls apart. If you want to do scripts and SQL on the file system, there are lots of other options that do the job better than us. I think we have more important things we could spend the energy on. On the other hand, if I've completely mis-interpreted your initial proposal, feel free to ignore all of the above. > At one extreme, ZClasses tested the hypothesis that everything, > including code, belongs in ZODB. I think experience has proven that > hypothesis wrong. The persistent code idea in Zope 3 tries to give > ZClasses a new birth, but it seems to have turned out even more > complicated than ZClasses. There are certainly advantages that can be gleamed from image-based development. I've seen some really impressive things done with Seaside. But Smalltalk (and its developers) are used to that kind of environment. It's less natural for Python. If persistent code doesn't behave quite like regular Python code, then there's still a gulf that has to be crossed when one wants to "move up" from persistent code. So yeah, I agree - not everything belongs in the ZODB. I agree vigorously! And that's what I'm arguing in favor of. It's so easy now to just have: class Article(Persistent, Contained): tags = () body = u"" And bam - articles! No translation layer, nothing. Put those in the ZODB and go to town happy. > That eliminates the two extremes, so there's no need to talk about those > anymore. We have to choose what belongs in ZODB and what doesn't, and > the decision is often important but not easy. I think that the decision only gets important when one is concerned about optimization of writes, re
Re: [Zope3-dev] Brainstorming about browser pages
grows. I found this to be the case with
zope.formlib. The earlier zope.app.form editforms (which preferred to
be built all in ZCML, including custom widgets) were much more
frustrating when you stepped above a certain threshold. They made it
easy to generate forms without need for any "boilerplate" Python class
- all you needed was ZCML. But when you needed to step up and do just
a little bit more, or just a little bit different, or just run the
status message through your own page notification API, things got a
*lot* harder. (This is a common meme of mine, it seems - if you go out
of the way and make things really easy for certain use cases and take
care of too much behind the scenes, you may get a happy user for the
first two days. But on the third when he needs to do something more
than the automatic tools provide and tries to find answers and finds
brick walls or mazes of ZCML metadirective handlers, THAT's when you
lose them; THAT's when the learning curve complaints start; THAT's
when you see strange hacks in other peoples code that make you go "why
did you do that?" and they go "I couldn't figure out any other way to
do it so I copied this from the root and changed some things but I
still don't know why it does what it does...").
> Third thing:
> "What if someone wants to customize this view by changing the template
> but not the helper method? You either have to subclass this view class
> and add a custom __call__ to your subclass, or you use *named
> templates* from zope.formlib:"
>
> Nh. I don't like this, but I can't tell you why. Maybe just
> because it's too complicated. Same goes with your usecase 1. I
> actually don't want to create a boilerplate class just to hold page
> templates. And sure, if we could get rid of the automated class
> creation in Usecase 3b, then I'd might opt for getting rid of this
> class creation too, but now I just don't see why.
>
> On the other hand, in most cases it means I'll create one view class
> per object and tuck a lot of templates on it, but still, it doesn't
> feel quite right...
I'd say it feels very wrong, in fact, had I not done something sortof
similar with head resources recently. But those were just ways of
compressing five lines of viewlet registration per javascript/css
resource that were meant to be used on every-single-page-in-the-system
into a single line of Python each. But those items aren't providing or
requiring the sort of intelligence that a view might.
Maybe I feel that way because I use page templates less and less and
have broken things out into small work units that generate HTML
through a simple generator based (loosely) on Nevow's STAN. About the
only full Templates I register any more are macro collections -
standard template, form templates, etc. I find that with almost
everything else, at least based on recent work, that I do want a view
class living along side my template. Very few objects in my system
really have the guts to format their data on their own properly, so I
always need at least *some* kind of support.
If done properly, having this::
class ArticleDisplay(PageView):
template = ViewPageTemplateFile('article.pt')
[ZCML]
seems pleasant enough. Then when you need to format the 'description'
field through something like newline_to_br, or present computed dates
('updated 4 and a half hours ago'), you already have a place to hang
them. Whereas with this::
You don't. And then you won't want to put the nice formatter on their
because your brain hits the "oh, I need to make that into a class...
Ugh, not right now" moment. And you find yourself staring at a page
that you want to make prettier, but there's _just_ enough annoying
effort involved to keep you away from it. At least, that's been my
personal experience, but I'm also a bit of a crank.
So this (what I show immediately above with the false 'PageView'
subclass) is effectively the pattern I've started enforcing for all of
our new work, and it can be done now in what ships with Zope 3.{1,2}.
A two line "boilerplate" Python class now saves headaches later.
--
Jeff Shell
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Zope 3 web root
On 2/17/06, Shane Hathaway <[EMAIL PROTECTED]> wrote: > Incidentally, I find it difficult to make any argument about anything > because I fully appreciate many sides of the issue. :-) You and me both :) > Gary Poster: > > one could argue that ZODB-based TTW dev got to be so problematic > > *because* it was so successful. There are strengths there. > > > > That said, I'm eager to see what you might think up as an alternative: > > I think both paths might be fruitful. Personally, I like the idea of third party alternatives. I think one of the most extreme and interesting "portlet" style implementations is Seaside's halos. When they're turned on, from what I can tell from the few times I've looked at Seaside and related documentation, you have a lot of customization power. It's not for everybody. But I think it's an implementation that personalizes Zope 2 style Through The Web capability by localizing what you edit to the component that you see. http://blogs.inextenso.com/seaside/blog/learning/0cf6f89c-7824-11d8-81ca-000a27b05150 http://www-128.ibm.com/developerworks/opensource/library/os-lightweight8/ CSS, HTML, and Smalltalk Source for everything is accessible - but it's accessible *in place*, not buried in a completely foreign interface or buried deep within a master template or script... It's still object oriented. Fascinating. But as I said earlier, this is something that Smalltalk's image oriented development supports (where all of the code lives inside a virtual machine/environment, away from any concept of files). The ZODB *can* behave like this, but that only works best if all concept of code-in-the-ZODB-image is separate from any-kind-of-data that might be in it. Anyways, that's an aside. It's not something I nor any of my customers need. But it would be an interesting thing to see someone take up. > The web root is my best idea for an alternative. > > Although I've been talking about addressing the needs of new adopters, > I'm really trying to address *my* needs. I want to build a complex web > site using Zope technologies, but I don't yet know enough about what I'm > building to be able to do any model/view separation. I intend to write > dirty, filthy, unmaintainable code. It's the right thing to do! If it > works, I'll clean it up. If it doesn't, I'll throw it away and try > something else. If I write it with Zope technologies, I know I can > succeed at cleaning it up because Zope has the most powerful tools out > there. If I write it with Apache, I'm certain I'll end up building my > own framework to support whatever flavor of messiness the solution > generates, it'll take twice as long, and it will be impossible to clean > up, so I'll have to start over if I want it to last. Gimme Zope! > > While I'm writing messy code, I also invent messy processes along the > way, and ZODB can't easily support my random new processes. I often > write automated tests for messy code. I often think to myself, "what is > the ugliest possible way I can write this?" Then I really do it and > laugh. That gets me moving when I'm stalled. Sometimes I rewrite > something ten times, relying on version control to get me back. It > turns out that the CMF skins tool is much better at supporting this kind > of work than Zope 3 currently is. > > I want Zope to encourage clean code just like everyone else, but > interesting things rarely start out clean! If Zope wants to be a > platform that people can use to invent crazy new things, it has to allow > for messy code and processes. Where doesn't it allow this? I wrote about this in Griddle Noise earlier this week. I feel more free to mercilessly restructure in Zope 3. I feel free to write things crappy or mediocre initially. Most of our big projects have been done under hard deadlines and technical debt was accrued along the way. But much of that debt was easy to pay back, sometimes with just a day or two of postmortem reconstructive surgery. How is the skins tool better than actual Python classes as view objects? They're still on the file system. They can still be under version control. The page templates are still on the file system. They can still be under version control. I guess I still don't understand how you're using Zope 3, because it sounds like you're using it very differently than I am. I've long since abandoned the ZMI. I never see that list of addable objects (in fact, in my newest applications, I completely bypass IAdding). I basically see the "Zope 3 ZMI" long enough to add one of my sites/applications. At that point, my skins take over, and that's all I see. The rotterdam skin is there as last resort to get ou
Re: [Zope3-dev] Brainstorming about browser pages
't mean you can't provide a helper API that groups those
responsibilities into a useful tool, but use that API internally.
I don't think it should be the primary responsibility of a view object
to provide an API. Its primarily responsibility should be rendering
content for output. But again, your view can provide an interface and
you can program against that. Just make the decision - "am I making
this object to render output?" or "am I making this object as a helper
for common operations my views need?" and design appropriately.
Core API's and concepts should be simple. Look at zope.contentprovider
- 'update' and 'render'. That's all one really needs. You don't need a
big API supporting, well, I don't know what you'd want to support.
That's the responsibility of systems that build on Zope 3, whether its
a big application like launchpad or an internal CMS framework you use
to support your own customers. Those systems will have their own
needs. What's helpful for me may not be helpful for you. What works
for Plone may not work for an e-commerce solution. I like small
cooperating components, whether they're views or helpers or models or
utilities. Others prefer bigger classes that take on more
responsibilities on their own.
> If we think about MVC then I would say that such a pattern
> isn't the right way to mix it with PageTemplate implementation.
> But that's another part.
It sounds like you want the C more than the V. Personally, I've always
had an issue with MVC, which is that in so many cases, Views and
Controllers really have a tight relationship and for many uses an
object could be both. In Zope 3, you can use ``template =
ViewPageTemplateFile('foo.pt')``, but you can also just do what I do
above and use another HTML generation system. Or use meld3 or any
other offering available. This isn't a Rails type environment where
the 'views' are templates of a particular type that are in a special
directory. You have complete control. I like having my 'views' be
'controllers', and be full intelligent Python objects. A template is
just there to support rendering if I need it. A template is too dumb
to be a view object in my opinion, and I would hate to see
restrictions along those lines.
I think my style of development these days could be described as
MVWBoH (model, view, and a whole bunch of helpers).
> But I agree with you Steve, I think its a good concept if you
> use it in project which uses PageTemplates and doesn't need to
> offer a generic API.
I think the ``update / render`` pair concept (as an elaborated concept
of __call__ on view classes) is great. Steve's concept is similar. It
has nothing to do with page templates, except as a minor
implementation detail. I think __call__ is about the best generic API
we can use right now. On top of that, the 'update/render' API used in
zope.formlib, zope.contentprovider, and zope.viewlet is the best
extension. Why? Because you can look up smaller 'views' within a
larger view and get them ready for display, but not run them through
the rendering stage yet. You can prepare them without having to look
up a richer API, or wonder whether __init__ has set things up yet, or
whether some internals won't really be prepared until the rendering
stage. It's so beautifully simple, and I (personally) have gotten
terrific mileage out of following that pattern for many of our own
views.
--
Jeff Shell
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Two visions
n "Zope". On some level, the logical name would > be "Z" (pronounced "Zed" :). An argument against "Z" is that > it would be hard to google for, but Google handles such queries > quite well and I'd expect that we'd move to the top of Google Z > search results fairly quickly. However, I'll leave naming > decisions to experts. ;) Perhaps it's not the greatest name, but I've become enamored with *lib names like 'formlib'. 'zopelib' Hmmm. Not the prettiest thing. But it does say "Zope Library". If that becomes the *core* of the mythical Zope 5, awesome. I still like having a web server with Zope 3. >Advantages of this vision: > >- Zope 2 users don't need to leave Zope 2. yay >- Zope 3 doesn't have to reproduce all Zope 2 features. yay >- There wouldn't be confusion about 2 Zopes. > >It is important that Zope 5 be backward compatible with both Zope 2 >and Zope 3, although not necessarily in the same >configuration. Many people are building Zope 3 applications today >and they should not be penalized. > > Thoughts? Would it be a significant retread or loss of traction to do this now? I wouldn't want to be stuck with Zope 3.2 for another four years. On the other hand, if this gets the zope.bobo project moving forward, and re-addresses packaging/setup, I'd be all for it. Regarding packaging/setup, I'd like to answer "how do I install just part of Zope?"... Or I guess, really, I'd like to see something that (I guess?) works with paste.deploy, or an enhancement/replacement of the current instance home builder. One that would provide options like: * Create skeleton zope.publisher application. Provide your own storage. Best for completely custom or small applications using other available options for templates, etc. * Create skeleton zope.publisher + zodb application. Provide your own root and skin. Develop rapidly and store Python objects naturally without a translation layer. * Create full Zope 3 application server instance. Customize skins, packages, etc, by modifying configuration. Work with other Zope 3 application server packages easily! Maybe with options regarding the server as well. (twisted, zope.server, 'I have a WSGI server already'). But this way, all of Zope could still be in a single download (no having to pick through a hundred different "editions" ala Microsoft), but provide entry points for web application developers and situations that don't need the full thing. I see a lot of simplicity combined with a fair amount of power in some other offerings, from Ruby On Rails to TurboGears to Seaside. But I think that many of those (perhaps with the exception of Seaside) have a mediocre or magical core architecture that could grow up to suffer problems similar to those that affect Zope 2, problems that the component architecture is meant to solve. Those are my own selfish desires anyways. I still believe that if we can build and deliver a solidly defined core, then we (or others) can do anything on top of it - a full on replacement for ZClasses, continuations based development with through the web shadowing of file system code for custom inline tweaking, continuations based programming where a page fades away as a concept and it's all just live objects on a screen with a natural flow for development of state intensive apps, something without any of that for development of state-carefree content delivery apps with nice URLs and aggressive caching, and so on. :) So again, if this would help us define that core *and make it usable in a variety of configurations*, then again I say 'yay'. -- Jeff Shell ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Two visions
On 2/28/06, Martijn Faassen <[EMAIL PROTECTED]> wrote: > Gary Poster wrote: > [snip] > > On Feb 28, 2006, at 10:06 AM, Philipp von Weitershausen wrote: > > > >> I think focusing on one app server and a dedicated set of libraries > >> would be a good alternative to two concurring app servers. > > > > ...if the single app server is based on acquisition, __bobo_traverse__ > > and friends, objectValues and friends, ZCatalog, and so on, I'd rather > > have two, thanks: at least I can have one I like. > > I can see where Philipp is coming from: yes, it would be good to > collapse the Zope 2 and Zope 3 communities into one if that frees up > more development resources and lets us do less duplicate work. I still fear collapsing them into one. This is no offense to any of the hard work people are doing on all projects. Someone said "Zope 2 + Zope 3 + Five is big complexity", and I agree. A lot. It's easier for us to use only one or only another. I prefer Zope 3. It's simpler. But already there are some design decisions that have happened in recent months that make me less comfortable about that. All of these big features are neat and well. But I want less. I don't know how to use less. There are dependencies on zope.app creeping into packages allowed in zope.*, and I understand that more of that is likely to happen in the future. And that terrifies me. An acknowledged Zope 2 problem is the large inheritance structure that objects have to support to be useful and usable, and that it creates a tight coupling that can't be broken. But having a large collection of loose couplings that can't easily be broken is not a better solution. Having to load up and configure 80% of the zope library to use 30% of its features isn't tenable. The size of Zope 3 "app server" as it stands now is still overwhelming to me. I think we could still stand to do with some smaller cleaner core features first. The part of this vision that worries me tonight is that it gives priority to the Big Complex Application Server With All It's Features (as good as they may be). Instead we could do good by giving that thing a better base to use, and benefit others among us by having a better base to use with less overhead (says the man bit by ZCML browser dynamic class generation again today). IE - move some of the *core* widget concepts out of zope.app and into formlib, and finding ways of severing the zope.app dependency from zope.formlib. Move some of the core interfaces up a level, and make the ones in zope.app.form extend those core ones. If "application server" (still a term I'd like to see defined in this context) becomes a priority, or a separate priority, or we just start thinking about what needs to be done to make core things simple, powerful, and sharable; and how to build the Application Server on that to give people a variety of development/deployment options or pre-built tools to help with so-called "large applications" then I think this could be a good thing. But if it all becomes one big overwhelming library/server/solution again, I can't stick around for that. I don't need something with the weight of Plone or the CMF to make an itinerary manager. Super terrific content management tools aren't going to help me build a state heavy e-commerce application. Getting too tied up in the concepts of containers/containment/"all objects are like this" mentality isn't going to help us deliver a sprawling enterprise payroll management system from five different data sources. The loose coupling of Zope 3 makes doing these different systems in Zope using a similar development technique for each possible. I want to make sure that the loose coupling remains useful and usable, that trying to use a particular widget isn't likely to make my system need to register 80 supporting components and sub systems. Hopefully some simple guidelines can stay in place and stuck to in regards to "how to make sharable components sharable". -- Jeff Shell ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Visionaire! (All your problems, solved)
of both Zope 2 and Zope 3 application servers and offerings. We don't need a hundred different "editions" like Microsoft. Nor do we need a hundred different acronyms like Java development seems to have. I think we could boil things down to these three offerings, while sticking with the current timed release plan as well. And it would finally make a useful and usable "Zope Without Zope" downloadable option available as Zope 3 CA. I can envision the web site now, and may mock a simple and sexy text based one up later this evening. We could even get it up now (zopesuite.org anybody?). - Zope 3 CA: Provides the core elements and concepts for building and sustaining loosely coupled Python programs, as well as the fundamental object publishing toolkit that's been powering Zope based web sites since 1996 (1995?). [download now | more information] - Zope 3 AS: The Zope 3 Application Server. A new approach to Zope web sites built entirely on the Zope 3 Component Architecture and Zope Object Database. A full stack for developing custom web sites and applications using only Python and your imagination. [download Zope 3.2 now | more info ] - Zope Suite: Built on Zope 2 and leveraging elements of the Zope 3 CA and Zope 3 AS, the Zope Suite provides a robust and mature web development environment that is in place already behind many web sites and applications worldwide. [download zope 2.9 now | more info | roadmap ] Thoughts? I think this keeps Zope 3 as we know it alive, keeps the Zope brand intact, and offers a future for Zope 2 and similar caliber desires for a Big App Server while not interfering with the more "pure" and simple concepts that makes Zope 3 appealing for developers like me. -- Jeff Shell ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Visionaire! (All your problems, solved)
On 3/1/06, Shane Hathaway <[EMAIL PROTECTED]> wrote: > Jeff Shell wrote: > > - Zope 3 CA: The Zope Component Architecture. Core services. Would > > include zope.publisher and most other current top level zope.* things. > > Usable as a library, as a publisher for other environments, perhaps as a > > simple standalone server. Easy to deploy against WSGI, Paste.deploy, > > whatever. > > > > - Zope 3 AS: The Zope 3 Application Server. A Zope 3 CA stack using the > > ZODB, ILocation, and most of the zope.app services but without any content > > objects. Perhaps only an application server configuration skin (process > > management) but no ZMI. Maybe have the current configuration installable > > as > > an option. > > > > - Zope Suite (or Zope Web or Zope DE): This is the full "application server" > > perhaps Jim is envisioning. A comprehensive web based user interface, > > based > > on features (and implementations) of both Zope 2 and Zope 3 application > > servers and offerings. > > That's quite appealing, IMHO. Could you agree with the following > distinction? > > - Zope 3 CA expects the model (and the method of persisting the model) > to be completely defined by the Python programmer. Yes, although Zope 3 CA could also be used in non-web environments (I've used it in an internal package manager experiment, for example). I'd like the Zope 3 CA download to include some useful examples and/or skeletons (possibly configured for Paste Deploy) to show some of the different options - use with SQLObject, other template packages (page templates would be included with the core though), etc. It could also include some other publisher/publication objects that could show integration with tools like Routes, for example. These extras would be outside of the core library, of course. For purposes of documentation and evangelizing, the Zope 3 CA can provide improved documentation about core Zope concepts like object publishing, without having to put Zope 3 AS expectations or terms on the programmer, giving them an entry point to the larger world of the Zope Application Servers without being overwhelming. Then we (or someone else) can write "Python on What Have The Romans Ever Given Us", which would show how you can do a rails "programming by convention" style system using the component architecture. The CA would automatically create adapters/views to bind ``models/person.py``, ``controllers/person.py``, and ``views/person/list.pt`` together. How those adapters are registered and used by the publisher would show off the CA. > - Zope 3 AS expects most of the model to be stored in ZODB and implement > ILocation. However, it still expects model objects to be defined by the > Python programmer. Yep. Zope 3 AS might also yield a solid foundation of base interfaces to allow easier use of 'sqlos' and/or 'sqlalchemy' backed objects that still provide a core set of useful and usable information (dublin core, etc), and could offer the option of using one of those instead of the ZODB while providing the caveat that use of other (third party) 'model' components may require additional work to map. Essentially, Zope 3 AS would be the option for those who like the Zope 3 + ZODB way. So many of these other web 'frameworks' with their O-R mappers show off applications that don't really need the full power of SQL. If you don't need it, why go through it? The ZODB is very credible - perhaps more so now than ever. Zope 3 AS would also downplay or replace the ZMI. I think there should be a skin available for configuration - ie, for adding a site (a complete application like Schoolbell, a customer CMS, etc) and maybe giving access to configuration options, like the stuff in ++etc++site, but that's it. I think the current ZMI suffers from being both a system administrator tool and application / data entry tool. I know that security settings can filter out a lot of the administrative features, but the interface that's left still feels a bit incomplete. And it raises the question "should I provide for it? should I define some zmi_menu menu items, just to be useful? should I use it as my user interface?" Django is killing us on automatic data (not system) administration pages. If web based configuration/administration (add a site, set up users, maybe select that site's skin, flush caches; process administration) was separated, then someone could build and provide something like Django's admin screens or Turbogear's Catwalk for doing the data entry. But it would be an option to use that as a view/skin/tool, and clearly marked as such. Some applications, like many CMS's, need something like the ZMI as they often separate the concept of data e
[Zope3-dev] Django, Catwalk, nice admins (was re: Visionaire! (All your problems, solved))
On 3/1/06, Gary Poster <[EMAIL PROTECTED]> wrote:
>
> On Mar 1, 2006, at 11:02 PM, Jeff Shell wrote:
> [...]
> > Django is killing us on automatic data (not system) administration
> > pages.
> [...]
>
> I didn't follow this, probably because I don't know Django. Do you
> mean they excel in automatic data entry forms, a la Zope 3 edit forms/
> formlib? As in Ruby-on-Rails slick SQL-driven AJAX forms? Or...?
It's not just formlib, but it's on the contents screen. This effbot
post summarizes it pretty well:
http://online.effbot.org/2006_02_01_archive.htm#20060215
It includes example code and a screen shot. In a very few lines of
pure Python, he has an edit screen for announcements. There's a search
field, the columns are sortable, etc. There's also a 'date hierarchy'
which gives clickable years across the top of the listing to filter.
Django comes out of newspaper focused content management, and has a
polished CMS style UI (based on the screen shots I've seen, I've never
actually used it) and ways of rapidly putting it together. I'm not
fond of the way they put it together in the code, but the results are
impressive.
A low priority project I have is to make a new base 'admin' skin and
collection of components/tools for us at Bottlerocket. One of the
things I really want to do is create a formlib inspired contents
view(let). The contents view we have in our current CMS is based
(stylistically if not subclassed) on the one in
zope.app.container.browser.contents. It has ajax elements (inline
renaming and title editing), and no copy and paste. But it does have
delete. Delete (and the other things) are methods of the contents
view, and a lot of the display is bound up in the template. When my
co-worker wanted to adapt it for more specialized content listings,
where he wanted grouping and no renaming, it was quite a bit of work.
It's late, and I've been watching nothing but South Park and Monty
Python's Personal Best series (an hour of Terry Gilliam animations -
dada enlivened!), but I envision something like:
class AnnouncementContents(ContentsView):
contents = JSSortableContentsTable(
listOnly=IArticle,
columns=ColumnFields(IZopeDublinCore.modified,IZopeDublinCore.title),
actions=ItemActions(
ViewAction(icon=Resource('rsrc/delete.gif'), viewname='delete',
title='Delete', post=True)
)
)
contents.order(table.columns['modified'], reverse=True)
contents.columns['title'].widget = InPlaceEditor
*shrug*. That's a bit messy. But it's also only fantasy right now. :)
Anyways, Django has a very nicely polished 'admin' interface. Which,
as I mentioned earlier, is something that is very attractive for
certain application types. It allows the focus to be on the
application's real skin, and offers an easy almost-no-brain data entry
skin to be made that's also quite usable.
Something like this would be a great option, emphasis on option. It's
not usable for every situation. At Bottlerocket, we want to brand and
customize and this has often been one of the reasons we've made our
own apps instead of using something like Plone. "Hmm. Looks like
Plone. We don't want something that looks like Plone..." (This was
only really bad when it came to trying to figure out how to publish a
site that didn't look like plone to end users, but did for data
entry). This is one of those issues that spirals out of control, and
easy usability - "wrap this interface around all your models in one
line of code!" - and customizability start to clash. But having it as
an option to startup could be priceless.
An even more interesting application is CatWalk, which is now part of
the TurboGears 0.9 toolbox. One metric I saw was that it's 1200 lines
of Javascript, 900 lines of Python. It does a LOT via Ajax/JSON. And
it's _extremely_ impressive, especially when it can actually be
wrapped around your model objects in a single line of code (or just as
a launch option!).
http://checkandshare.com/catwalk/
(he also has a model designer running -
http://www.checkandshare.com/modelDesigner/ )
The nice thing with TurboGears and these tools is that they feel like
*additional options*. At least, that's the feel I get just from some
semi-casual observations on my part. They don't feel like the default
UI that you don't know if you have to support or not.
Anyways, the other communities have things like this going on and
we're still debating over release / roadmap / naming strategies?
--
Jeff Shell
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: [Zope3-Users] Visionaire! (All your problems, solved)
On 3/1/06, Terry Hancock <[EMAIL PROTECTED]> wrote: > On Wed, 1 Mar 2006 21:43:10 -0500 > Chris McDonough <[EMAIL PROTECTED]> wrote: > From a marketing or "user convenience" perspective, labels > like the ones proposed remain useful, however. Personally, > I think they're fine. I'm not sure I wouldn't ditch the "3" > though, and just call it "Zope CA"/"Zope AS" or even "Zope > Component Architecture" and "Zope Application Server" -- > would there actually be any ambiguity? Yes. There's a dominant Zope name out there. It's not the Component Architecture nor is it built on it. It's starting to use it, but it's not based on it. However, since the project that Zope 3 [AS] came out of is still identified in the Wiki as the 'Component Architecture' project, maybe the '3' can be dropped for that one. But not for application server: That dominant Zope, aka Zope 2, is also an application server. So there really needs to be a separate definition. This was discussed here a couple of months ago when people were enamored with the concept of totally different names or code names or release names, which I was against. Zope 3 is Zope. But Zope 3 is Not Zope. Zope 3 has *some* degree of buzz around it, more than something with a new name. I still believe that the '3' has meaning, at least for now. Maybe it can disappear over time. The Zope 3 Application Server can be defined, I think, as "the result of the Zope [3] Component Architecture Project, Zope 3 AS builds a new Zope application server and library purely on the core Component Architecture and its principals. It is not meant to be a replacement for the popular Zope 2 server or the new Zope Suite. Instead it provides a smaller subset for developing new custom web applications that take advantage of Zope's core concepts while providing the blank slate to build the system you want. Zope 3 AS is targeted primarily to Python programmers, and is a powerful toolkit for building the web application of your dreams." *shrug* I think keeping the 3 in that one is important, and keeping the 3 in 'Zope 3 Component Architecture' ties those two together, and puts them out there as the tangible results of the Zope 3 project. The "Zope 3 as a someday successor to Zope 2, maybe" message goes away. 'Zope 3' becomes less of a product name on its own and comes to stand for the work done to re-imagine Zope as a loosely coupled collection of components, and the possibilities that it opens up. The message then becomes "Zope 3 CA and Zope 3 AS, and the individual packages that make them up, are the products available now from the Zope 3 group. The Zope Suite leverages that work into the established Zope 2 project." -- Jeff Shell ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: [Zope-dev] Re: Two visions
On 3/3/06, Chris McDonough <[EMAIL PROTECTED]> wrote: > On Mar 3, 2006, at 3:08 AM, Max M wrote: > > Splitting up Zope to let people use seperate pieces of Zope aka Zed > > is not a valid reason. Good software practise is a valid reason. > > But catering for those few developers that wants to use just a few > > pieces is probably not worth the effort. > > Here's one of the reasons I want good packaging: I'd like to > continue using Zope-the-technology even if the Zope-the-brand loses > all recognition. Whether in the future I'm working on > DjangoRailsGears 3.0 or Zope3006 or Plone-NG, I'd like to be able to > carry the various bits of technology that make up Zope around with me > reasonably easily and run it under different Python platforms. I say > this with my cynical and Zope-bigoted "consultant" hat on. There. I > said it. ;-) Today I tried installing Ruby on Rails 1.0 and TurboGears 0.9a1. And now I'm really with you on the good packaging bit. $ gem install rails --include-dependencies $ easy_install -f http://www.turbogears.org/preview/download/index.html TurboGears Although, I also really like Zope's configure/make/make install process and the fact that I don't need to set up no stinkin' mysql server to use Zope. But as I watched TurboGears install and saw all of the pieces it's pulling in, I have to admit that it was really impressive. That page in the link above is intimidating to look at - there's just a lot of links to lots of different packages with version numbers like 0.5.0a1. But the easy_install thing worked. I've been avoiding Eggs and the like for a while now (The name 'eggs' bugs me for some unknown reason, and I'm petty enough to avoid something just for that reason). Seeing them in action was impressive. One of the impressive things: having/extracting PyProtocols and RuleDispatch out of PEAK has made those things widely used. PEAK has some interesting ideas in it, but it's big and scary to me, and I'm sure it is to others as well. PEAK has some web stuff in it, from what I can tell, so in some ways TurboGears is a competitor to the full PEAK package. But since PyProtocols and RuleDispatch are available separately, TurboGears can include them and use them. And maybe that's a good argument for renaming some of the core stuff. I just think 'Z' and 'Zed' are terrible names. But it's a good argument for packaging, especially fine-packaging of the core tools. >From those core tools, lets build and let others build wild and crazy applications, app servers, and even competition. One of my thoughts for some weekend hacking was to look at zope.bobo, or play with my own concept just to see if I really understand how the publisher/publication interact. As I started thinking about that, I started wondering (a) how to get the pieces I needed and only the pieces I needed, (b) how/where to install them while I was developing, and (c) how to package them up if I was able to come up with anything successful. -- Jeff Shell ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Notice: zope.interface is now a separate project
On 3/3/06, Thomas Lotze <[EMAIL PROTECTED]> wrote: > Am Mon, 27 Feb 2006 15:56:16 -0600 schrieb Paul Winkler: > > > We are planning to do this to a number of other packages: > > > > zope.i18n > > zope.i18nmessageid > > zope.deprecation > > zope.exceptions > > zope.tal > > zope.component > > What was the reason for choosing these and not choosing others? What > about, e.g., zope.schema? I think that one's as interesting for non-Zope > use as, e.g., zope.interface and zope.component. I agree. I think zope.schema is integral. It has so many potential uses, not to mention that it really makes 'zope.interface' a complete design by contract system since it can be used to enforce constraints on data / arguments / etc. It's also fiendishly good for formatting and translating data to/from objects. I've used zope.schema to serialize values to and from reStructuredText style fields, as a way to do fancy declarative programming in Python through deferred object constructors that used zope.schema to enforce/convert arguments. This latter one was in an experiment in using the zope component architecture in a totally not-Zope application. I highly recommend adding zope.schema to this list. I believe its dependencies are pretty small, and I think it's a good system to use for people who like the concept of 'static type safety' while being much more adaptive, useful, usable, and flexible than most basic type systems. I think that zope.schema, zope.component, and zope.interface could be highly effective when combined with a tool like 'sqlalchemy'. -- Jeff Shell ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Zope Eggs
Cool effort. One thing that I noticed in Rails when I downloaded it this weekend was how you installed plug-ins. Very easy. There are various 'sources' that can be loaded up which work, I assume, in a similar manner to how you can point easy_install at a web page and tell it 'find links'. To install a plugin into an application instance (similar to a Zope instance home), it's just an effort of: $ script/plugin install acts_as_taggable The plugin is found, and installed in the instance home equivalent. This uses 'gems' under the hood from the looks of it, and adds in the knowledge of a Rails application layout. It was pretty gratifying, being able to start adding in functionality so easily. I think a good goal would be to have something like this: A Zope instance home aware package/egg loader, so that in an instance home you could add in packages like this: $ bin/package install zc.catalog $ bin/package install hurry On 3/5/06, Nathan R. Yergler <[EMAIL PROTECTED]> wrote: > During the Zope3 sprint following PyCon, Paul and I, with Jim's > guidance, began work on exploring how Zope can utilize eggs and be > packaged using eggs. Since we're still experimenting with how eggs > will be used, I wrote a script, zpkgegg, which reads the zpkg > configuration information for a package and generates a "standard" > setup.py from which an egg and vanilla sdist can be generated. > > You can find the script in subversion in the projectsupport project. > For a brief overview of how the script is used, see README.txt (in > http://svn.zope.org/projectsupport/trunk/src/zpkgegg/). The eggs > generated by zpkgegg do not attempt to distinguish between "runtime", > "testing" or "development" dependencies, so almost all packages will > want zope.testing. README.txt contains a brief example of how to > point easy_install at the appropriate folders so that easy_install can > resolve the dependencies. > > Note that at this point we're still experimenting with how we'll use > eggs, so suggestions, feedback and comments are welcome. > > Thanks, > > Nathan R. Yergler > ___ > Zope3-dev mailing list > Zope3-dev@zope.org > Unsub: http://mail.zope.org/mailman/options/zope3-dev/eucci.group%40gmail.com > > -- Jeff Shell ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: The vision thing
On 3/5/06, Max M <[EMAIL PROTECTED]> wrote: > Geoff Davis wrote: > > Jeff Shell has posted some thought-provoking pieces on his blog that are > > relevant to Jim's recent attempt to better articulate a vision for Zope: > > > > http://griddlenoise.blogspot.com/2006/03/zope-crisis-of-faith-coming-this-march.html > > > > http://griddlenoise.blogspot.com/2006/03/crisis-of-faith-messengers-have-been.html > > > Griddle *Noise* and thats exactly what it is... noise. Well, I do love me the noise. [ Check me out at No Fun Fest 2006, Brooklyn! http://www.nofunfest.com/ Mar 17 2006 | http://euc.cx/aodl/ ] I say repeatedly that I'm not a good person. I'm cranky. I don't apologize for it. I see a Zope 3 deliverable in front of me that has half-assed versions of Zope 2 items (the page templates, etc). Zope 2 is far more mature here. I'd love to have a vision that would move these half-assed items out of the Zope 3 application server I have installed here, and fit them into a new vision that does match the maturity of Zope 2. And then, when those things are gone, I'll have a simpler Zope 3 to start from that doesn't have those elements as strange distractions. I'll ultimately have a Zope 3 where a third party developer might write a much better behaving through the web Page Template object and behavior. I'll have a Zope 3 with a simple core and easy-to-install extensions. I'll have a Zope 3 that I will be able to tailor to the needs of me and my customers, who have widely varying needs. I'll have a Zope 3 that I can make lean and mean and fast, with a minimum of configured objects and options threatening to take up memory and resources, which is going to be very important in an upcoming project. > He is probably following the discussions on the lists, and then he is > publishing his view on them on his blog instead of participating in the > dicsussion. It's hard to keep up with all of the discussions, and sometimes it's good to just get big ideas off the chest and open what I have to say up to a larger group of people. > We have probably all seen the Ruby On rails in 15 minutes video, where > they showcase their take on nineties web technology. > > I could probably do one that is a lot more impressive with an UML tool, > Plone, archetypes and ArchgenXML. And it would most likely last 10 > minutes... if I talked very very slowly. And I don't know of any UML tool that didn't have me reaching for the shotgun within 10 minutes. UML is great for sketching. If you want tools to do all your programming, you don't need Python. I think it's ridiculous that they hide the programming language and its usability under so many layers. > But that is not the point. He rants about Rails. But what are the > visions of rails? I don't see that anywhere on their website either. I think it's in pretty big type on the front page. "optimized for programmer happiness and sustainable productivity... write beautiful code by following convention over configuration." One of the best visions I've seen about Rails was saying that J2EE is Slow'n'Clean. It's totally proper. It's totally abstracted. There are lots and lots of XML configurations. Lots and lots of separated objects. And it's a lot of work to do something simple. PHP is the other end of the spectrum: it's quick, but dirty. It's a lot of work to do something 'clean'. Rails tries to provide "Quick'n'Clean". After some quick experiences with it this weekend, it mostly works. I think Zope could be a "mostly quick'n'clean." But right now, it's going back towards a "quick'n'mostly confusing". Ruby's `script/generate scaffold accounts expenses` command is beautiful. It generates an application based on a model. No huge layers like ArchGenXML or ArchgenUML. It uses the model in the database. It then *generates useful and usable starting point code for an application*. The generated interface is simple, and unlike a lot of code generation tools it actually feels like code that you can start modifying and working from. So you have a good starting point for an application, and you can pretty quickly start making it your own. The starting point is really basic, rather bland, but usable. So you know that you can start modifying it from there. It gives the experience of immediate results, as well as immediate "ok, now how do I start making it look/behave like I want?". > He is just another developer who wants Zope to consists of only those > elements that he is insterrested in. I don't mind there being other elements. But I don't want them in the way. I have different visions for me, for my customers, and so on. Some of their needs are VERY VERY VERY di
Re: Movies, audiences, wasted effort, was Re: [Zope3-dev] The vision thing
;halos' in the web browser. This puts boxes around all of the *objects* in a page - because the page is actually constructed of objects and not of strings inserted into a bigger string. You can inspect the shopping cart in the corner. You can inspect the item listing. You can tweak the CSS for any of those objects right there. Or you can go directly to the Smalltalk code behind the object in a simple web version of the Smalltalk system browser, with full access to the full environment. It's all live. And it is all...totally...cool. But this is a style that Smalltalk's nature supports. It's not so natural for Python. Still, it's something that I think about. (Plus I love its Smalltalk based way of HTML generation. I hate Page Templates for most things now, and pretty much have my newer applications boiled down to two or three with content providers/viewlets responsible for their own HTML, with CSS taking care of most of the major look and feel). I'd like to give certain customers the ability to see their e-commmerce stores from the front page, turn on something like halos, and be able to go in and directly edit how an individual item gets displayed. No full templates - just turn the promotional item around and see a simple template language (perhaps similar to Django's) where displayed values are obvious. Or to turn it around and change some other values, right there. But ultimately, the big thing is to treat and think of many of the little things on a page as the objects that they are - viewlets, most likely, wrapped around a PurchasableItem, and to add in a layer that allows direct manipulation. It's not quite like Portlets or any design like that. It's more for direct customization of applications that aren't a bloody content management entry tool. The 'customize' feature of CMF Skins is actually kindof close to what I'm thinking of. The core system look and feel would all come from disk based products, still, with the ability to overridden by something stored in the ZODB or some other tool. But instead of monkeying with scripts and full templates, it would be with much smaller pieces that make up a page. Recent experiences trying to tweak a few small layout oriented features in a very complex and nasty shopping cart template through the web in Zope 2 - even with a lot of logic 'coded behind' the template - have brought this idea closer to mind. > If there's a moral to this story, it's this: > Scaffolding that gets you up and running with a minimum of > fuss is a great thing. Rapid interactive and iterative development > is also a great thing. But if you can't easily transition from there to > more complex apps that are still maintainable, it sucks. It's irritating > to have to throw away some of your knowledge and completely replace it > with new ways of thinking; it's better if the new knowledge strictly > supplements the old. It's worse than irritating to have to throw away > your work and rebuild it from scratch; it's better if your new work can > cleanly leverage the old. This is an area where Rails is particularly strong. I'm normally not a fan of code generation. But their tool generates just-enough. It's code you can actually understand and start building from, and a quick run to the api docs they have online is usually all that's needed to start understanding the code you're looking at. The code their tool generates runs basically what you see if you have it dynamically providing 'scaffolding', so the conceptual difference between the automatically generated and what it gives you out of the box is pretty small. I think that zope.formlib (and maybe zc.table, from what I've looked at) are great tools for things like this. formlib is pure Python. It's got big documentation. It's got a nice API that you can follow. There are base classes and common functions that do a LOT of the 'heavy lifting', but they're understandable... Mostly. Much more so than trying to follow a ZCML directive. This is all still for a developer focused crowd, which is still my main interest. I'll provide the cool things for my customers. The more cool and usable things go into the core that help me more than they coddle me, the better application I can create. I can shape 'formlib' into just about anything... well, anything supporting forms :). I like that. I love it. I can't stop praising it enough. > Put another way, if we consider Jim's first two audiences, how do we > teach a single person to move from "i don't want to have to care" to > zope zen master / SVN contributor with minimal wasted effort along the > way? > > Today I don't know if there's a clear coherent story to be told there, > even for zope 2. If there was... wow, that would be a great. > > Sorry if I haven't really said anything new. > > -- > > Paul Winkler > http://www.slinkp.com > ___ > Zope3-dev mailing list > Zope3-dev@zope.org > Unsub: http://mail.zope.org/mailman/options/zope3-dev/eucci.group%40gmail.com > > -- Jeff Shell ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Mandatory Viewing!
y-customize one. I think if zc.table were used too, someone could come up with a better CRUD application that's flashier and more dedicated than the ZMI, is less overwhelming than Plone, is easy to generate from a base Schema, and is easy to start branding to one own's desires and morphing into one's own application. Add viewlets/content providers on to that and you could really really have something. Add a TTW management interface that worked on the viewlet/wrapper level instead of the folder's full of miserable to edit templates level and you *really* have something. At least, so thinketh I. At least, for the present late moment. -- Jeff Shell ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] a new zcml directive?
On 3/10/06, Shane Hathaway <[EMAIL PROTECTED]> wrote: > Martijn Faassen wrote: > > If I'm doing this quite a bit, this looks like something that would be > > better expressed in a... new ZCML directive (..waiting for the crowd to > > start flinging stones). > > A possibly valid direction we haven't discussed yet is to embrace ZCML's > flexibility and make new high level directives often. For instance, > every time I feel like I'm repeating myself in ZCML, maybe I should make > a new high level directive to eliminate the repetition. The risk is > that configuration ends up more magical, but maybe new tools can > mitigate that risk. Thoughts? No. No no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no. There are very few ZCML directives whose code I can read. It's way too mystical and magical and full of weird things that I *still* don't understand like 'discriminator'. And there are leading and tailing underscores all over the place. This bit me like a mother recently when I was trying to write a unit test to cover a bug I found in my own code. It depended on me setting up enough of the test environment to mimic what was happening. It wasn't quite 'smallest unit of work' type unit testing as could/should often be done. But it was the amount of detective work and pain and trial and error and trial and error and trial and error to follow so many ZCML trails to set up what I needed for my test that really kicked off my recent round of frustration. A 3 line test, a 4 line fix, and over a hundred lines of imports / helpers / harness support from a long day's work into the night to support those seven lines... And really, so much of it was just trying to figure out what the ZCML was doing and how to mimic enough of that to set things up for my test... That's where the time was lost. I still steam up thinking about it. Why not provide helpful classes and functions, and make it obvious that they're there to support programmer code, not ZCML? (I noticed this with some of the odd little deferred factories around that get registered as utilities for things like vocabularies). Automate repetitive tasks with Python. I see something, theoretically, like this as a possibility: class AnnotationsAdapter(object): def __init__(self, annotationsKey, factory, assignName): self.annotationsKey = annotationsKey self.factory = factory self.assignName = assignName def __call__(self, context): annotations = IAnnotations(context) try: return annotations[self.annotationsKey] except KeyError: obj = self.factory() annotations[self.annotationsKey] = obj # to please security... zope.app.container.contained.contained( obj, context, self.assignName) return obj # In some other module from zope.annotations.helper import AnnotationsGetter FOO_KEY = 'foo.key' FooBarAnnotationsAdapter = AnnotationsAdapter(FOO_KEY, Foo, 'foo') And then in the zcml:adapter registration, or directly in the Python (either place above), declare the provides/adapts for this thing. I'm sure it can be done without requiring another ZCML directive. The bulk of my frustrations with Zope 3 have involved going down the rabbit hole of ZCML. Whether it's just trying to understand how something works, how I can provide a slightly different version of 'something' (ie - menu items with javascript actions), or trying to determine whether some erratic behavior is a bug on my part or Zope's, I inevitably end up in metaconfigure.py land. And it's the hardest code in Zope to read - even the metaprogramming in Interface and the sys._getframe tricks are easier to follow! So, please no. No more ZCML for automation. Please yes only for registration control. Please yes (or maybe) for global utility configuration like how to connect to an RDBMS (watching the Turbogears community start to realize that 'config.py' may not be a good thing because certain test and documentation tools will try to run it as Python and not set up its magic made me chuckle). But I beg you not to add to the ZCML pile because you had to copy and paste 12 lines of Python code. I think annotations are useful and I ran into having to write a similar bulk of code the other day - although my adapter and annotator had a larger separation (so 'zope:annotation' wouldn't have helped me anyways). I would argue that most situations requiring some sort of automation can be done by Plain Old Python Objects and Helpers and Plain Old Adapters and Utilities that can, wherever possible, be registered in "short form" . -- Jeff Shell ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Fwd: [Zope3-dev] a new zcml directive?
d by the machine. You have to have them to make certain things work. But what they are isn't obvious. They become painful to debug, introspect, etc. It really seems like one of the goals/ideas for ZCML was that you could make a crazy application with Zero Python Code - just use a lot of ZCML and it will generate everything for you. Or use ZCML, an interfaces.py module with some schema, and have a couple of persistent classes, and then use all of this ZCML to have the system build everything for you. I think that's a terrible idea. It binds you to a narrow view of the system, and restricts growth opportunities for when you need to do "just one little thing different". What if this annotations directive doesn't quite do what I need to do with my annotations adapter? Can I still use it? If not - how do I then provide annotations? What is this directive doing and how can I translate that into plain old python and then register the right thing instead? That's the headache I run into time and again: there's no path between "this is the easy one line ZCML way of doing things" (although it's often five lines after some trials and error) and "this is the slightly harder but will let you do what you need to do way of doing things that will still work like the one line ZCML way of doing things when all is said and done." To me, that feels like the "Z Shaped Learning Curve" re-invented. So no - I don't want more directives. A few months ago I defended ZCML pretty staunchly. Today, not so much. It's becoming the bane of my Zope 3 development experience, causing more headaches and lost time than it feels like it's helping. >From "ZCML Needs to do Less", at the very end (proposed guidelines for new packages): * Try to reuse as much of the existing Component Architecture concepts (utilities, adapters, views) as possible. * Try not to invent new ZCML directives unless you have a really really compelling reason to do so. If you're limiting yourself to utilities, adapters, and views anyways (and this should be enough), you shouldn't need new directives, the existing once should suffice. * Don't let ZCML do automation, Python is better at it. People will look for some of the behaviour in the Python code only to find out that it's not there but hidden behind dubious ZCML directives. This can be avoided. Simply try to look at ZCML directives as on/off switches and you're half-way there. http://www.z3lab.org/sections/blogs/philipp-weitershausen/2005_12_14_zcml-needs-to-do-less Let my ZCML be like that. I don't want to have to program in it, please. (And note: my frustrations have nothing to do with ZCML being XML, or being a configuration language at all. It only has to do with the automation making things 'easy', which then makes them very very very hard to work with outside of ZCML because what you learn in one system does not apply to the other). -- Jeff Shell ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] what is ZCML?
On 3/13/06, Alec Mitchell <[EMAIL PROTECTED]> wrote: > On Monday 13 March 2006 10:59, Dieter Maurer wrote: > > Note, that configuration files should be understand and > > adaptable by administrators. Therefore, they should be readable > > and understandable -- without an understanding of the implementation > > (but with reading of the component documentation). > > +1 The first time I saw: > > > > I was a bit disturbed. What's the point? It tells you nothing unless you > refer to the actual implementation. Why not just put the registration in > python alongside the implementation if that's where the configuration of > provided and required interfaces is going to be? I had considered one of > zcml configuration's greatest benefits was that it could give a high level > overview of how pieces of a package were interconnected. Of course it's > still possbile to do things the old way, but I get the impression that it's > discouraged. Brevity is not always a boon, though that cuts both ways here > (adding a new "magical" seeming zcml declaration to save a copy/paste here > and there may not be the best idea either). I consider one of ZCML configurations greatest detriments is that it does many things that cannot be easily replicated in Python (one day, you'll probably come across having to set up just the right unit test harness and you'll realize what I mean). I consider one of it's greatest detriments is that it completely destroys Don't-Repeat-Yourself. You can do: class MyFrank(object): def __init__(self, context): # ... See? No declarations on MyFrank that says what it does. Or you can do: class MyFrank(object): implements(IFrank) adapts(IBun, IRelish) def __init__(self, context): # ... And do the full line in ZCML. But then you've just said the implements / adapts twice. Using different words, I should point out. Or you can do the line the short way and let the Python code say what it does. Three options. I know I'm not consistent with the ones that I choose. I just know that I spend more time looking at Python code and I'd rather understand what the Python code is doing by looking at the Python code. Three options. That sure kills the "there should be one, and only one, obvious way to do it" theory too. Don't even get me started about when I might want to use 'zope:view', 'browser:view', or just plain old 'adapter' (since a view is just a multi adapter, as are content providers and viewlets and all sorts of other fun and useful combinations). Anyways - for me, the point of is that I already said in MyFactory that it implements and adapts certain interfaces already. I don't want to say that twice. And I think it's very important for the Python code to say what it does, so when I come back to a module five months later I'm not staring at MyFactory going "yeah, but what is it?" And I also think it's important for code to be debuggable, inspectable, so that when there's a bug from ... well, wherever it came from, code can be traced. It's very hard to trace through ZCML statements, and what they've produced. From dynamically made classes to the weirdness of the metaconfigure.py code (handlers, discriminators, etc) - all of those things get in the way of a productive pdb or "why is this thing blowing up?" session real fast. In my experience anyways. So I figure - the less ZCML I use, the better it will be for me to maintain in the future. -- Jeff Shell ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] what is ZCML?
On 3/13/06, Dieter Maurer <[EMAIL PROTECTED]> wrote: > Martijn Faassen wrote at 2006-3-13 17:15 +0100: > > ... > >A newer interpretation of ZCML is: > > > >""" > >ZCML is a configuration language that configures a number of basic > >directives for configuring the component architecture and security: > >adapters, utilities, security requirements, and little else. Everything > >else should be done in Python code, as configuration in Python code is > >more flexible and packages can form a more self-contained whole. ZCML > >should reflect the underlying universality of the component architecture. > > > >If two directives work with, say, adapters underneath, they should > >really be one directive. ZCML should be simple and minimal so it is easy > >to grasp. > > > >ZCML is not readable standalone. ZCML is simply used to turn on various > >adapters and such, hooking them into the system, but we do not get a > >clue what the adapters are doing by just looking at the ZCML - Python > >code needs to be consulted. > >""" > > > >I believe that this interpretation is the up-and-coming interpretation > >of ZCML. > > I hope not... > > Note, that configuration files should be understand and > adaptable by administrators. Therefore, they should be readable > and understandable -- without an understanding of the implementation > (but with reading of the component documentation). I think differently. ZCML is primarily for programmers. ZConfig style configuration is what administrators deal with more, isn't it? Maybe ZConfig and the things in the root $INSTANCE_HOME/etc/ ZCML files. I don't think of ZCML as administrative configuration. I'd rather have Python files that I can read and understand what's going on without having to consult ZCML files, directives, documentation, and so on, just to understand why a certain class whose code I'm looking at is getting its behavior when I can see no superclass. I'd like to know that a class I'm looking at is an adapter and what it provides and what it adapts without having to dig through a large ZCML file. An administrator is not likely to override my 'inplace_editor' view. He may want to configure global services (if my application is written that way) such as RDB connection parameters and mail services. But beyond that, just loading it up in package-includes or in a specific file is likely to be the bulk of 'administrative' effort. Did administrators go into your ``initialize(context)`` functions in your Zope 2 Product's __init__.py files and change things? That's what I view ZCML as being - a better version of that. (Better in only that configuration and initialization can be executed separately from Python imports) -- Jeff Shell ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] what is ZCML?
On 3/13/06, Shane Hathaway <[EMAIL PROTECTED]> wrote: > Martijn Faassen wrote: > > A newer interpretation of ZCML is: > > > > """ > > ZCML is a configuration language that configures a number of basic > > directives for configuring the component architecture and security: > > adapters, utilities, security requirements, and little else. Everything > > else should be done in Python code, as configuration in Python code is > > more flexible and packages can form a more self-contained whole. ZCML > > should reflect the underlying universality of the component architecture. > > > > If two directives work with, say, adapters underneath, they should > > really be one directive. ZCML should be simple and minimal so it is easy > > to grasp. > > > > ZCML is not readable standalone. ZCML is simply used to turn on various > > adapters and such, hooking them into the system, but we do not get a > > clue what the adapters are doing by just looking at the ZCML - Python > > code needs to be consulted. > > """ > > IOW, "most of the directives we need have already been invented. [1] We > don't want to build high level directives; ZCML will follow the BASIC > school of language design." :-) > > [1] http://www.inventionmysteries.com/article4.html > > While I was initially on board with the idea of reducing the number of > directives, I've changed my mind. I think we want high level directives > and we want people to feel free to write new directive types. We want > tools that let us inspect and search the resulting low level directives. > If we have to use ZCML, then ZCML should be expressive. Then why do we have Python? Is Zope going to be a "write ZCML directives to write your Zope app" system? Or is it going to be "write Python code to write your Zope app" system? I don't know if it's possible to use a ZCML configuration-execution outside of ZCML, which makes testing an awful hard beast sometimes. There's functionality that's locked away inside the directives that you then have to have not only the Zope environment set up to run, but a ZCML environment too. Pain pain pain pain pain. Unlock the magic. If it must exist, make it available and understandable to me. Don't hide it under more layers and verbs and nouns that conflict and change meaning depending on if you're using ZCML and Python. "Make ZCML More Expressive" - did we learn nothing from DTML Expressions? It starts out simply enough, but how long until we have more and more logic in ZCML? We already have this conditional that I barely understand (but appreciate in theory). Why design a language at all? I only want ZCML to allow me not to take on a packages provided components when I import it. I don't want to start thinking I can write an enterprise workflow and document management system in it. Let Python be the language. Let ZCML exist to do the final step of loading/registering registerable objects in a predictable manner, and to provide the few things that we don't want to pollute our (or others) Python code with, like security declarations. -- Jeff Shell ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Dissecting NamedTemplate (was Re: [Zope3-dev] Re: a new zcml directive?)
classic way if you'd like:: class CancelButton(object): implements(INamedTemplate) adapts(ICancelAction) def __init__(self, context): self.context = context def __call__(self): if not self.context.available(): return u'' ... That last bullet is important. This is the "yeah, but how do I grow up beyond ___?" answer. With custom ZCML directives, there often comes a point where you hit a wall where you need to do something different than what the directive allows. NamedTemplateImplementation does a lot of what the specialized directives do: automation of a common registration. But by NOT having it as a custom directive, hopefully it makes it just a little more obvious that you can actually do an INamedTemplate implementation of your own and it would work exactly the same. (Not that the namedtemplate.py code goes out of its way to make this clear, but it is still easier to understand than the discriminator/handler stuff of ZCML). -- Jeff Shell ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: a new zcml directive?
On 3/15/06, Martijn Faassen <[EMAIL PROTECTED]> wrote: > In the new world for ZCML, ZCML as a language falls apart in a > minimalistic XML language, and some support code (such as > zope.app.annotation.AnnotationFactory) to help it do more advanced things. That's what I'd like to see! :) > One remaining benefit of higher-level ZCML is that it gets picked up by > apidoc and thus can be discovered fairly easily by developers as part of > the configuration story. While AnnotationFactory is doing definition and > is in Python code in the new world for ZCML, this act of definition is > closely associated with the act of registering it in ZCML. I agree with that benefit of higher-level ZCML. But I've found in practice that documentation is still terse and sparse. That alone is what has had me digging into the code to try to figure out "ok, what does that mean?" name - TextLine (default = None) Name Adapters can have names. This attribute allows you to specify the name for this adapter. So, yay for documentation. That bit's good. But things like this could really really benefit from some examples. Especially on core things like adapter, whose 'locate', 'permission', and 'trusted' properties and their impact on each other are a bit tricky to figure out. But Python code and interfaces get picked up by apidoc too. Well, most of them (schema fields have gone missing in action.. I think a search will turn them up, but they can't be browsed to directly). One of the biggest downsides of higher-level ZCML to me is that it feels totally disconnected from Python. The documentation, as it stands now, generally documents the fields. But it doesn't go into what's being done behind the scenes, or why I should be using directive X, or how to use the results of directive X. The other downside is that higher level ZCML needs the ZCML 'runtime' in order to work. Besides, AnnotationFactory isn't just associated with registering something in ZCML. It can be associated with registering something with:: zope.component.provideAdapter(...) I know that the adapter directive does a bit more than just provide an adapter. But the point is that it could be used outside of ZCML. > It would be nice if we somehow retained discoverability for APIs that > are meant to work with ZCML - it's obvious from this subthread that it > takes some idiots^H^H^H^H^H^Hpeople a while to pick up an API... We'd > like people working with annotations to be able to find out that we have > this available. Perhaps a README.txt in the annotation package is enough > for now, though. Perhaps we can think of other ways to help make this > discoverable... I don't know the status of the static-apidoc tool, but maybe that could help in some ways... By having http://api.rubyonrails.com/ , not only is there a great online API reference, but it's (of course) searchable by the search engine of choice. Hopefully there will be a day when a search for 'zope annotations' will have the API reference and a couple of darn good recipes/articles/tips as the first set of results. I know it's been helpful to see a reference to something in Rails and google ``rails validates_presence_of`` and usually get to the api reference first. (Not that I'm leaving Zope for Rails, but I have been toying with it a bit, I admit). -- Jeff Shell ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: what is ZCML?
ems, and a nice chinchilla. How does that ZCML benefit an administrator or integrator that you feel must be protected from all of the Python code? Don't you think that, to an outsider, digging for:: on line 294 of browser/configure.zcml is NOT going to be foreign? It's only marginally (and I mean *marginally*) better than the following anyways:: What kind of non developer are either of those options going to appeal to? If I'm deploying an application, I'd probably prefer to have: 'import zip = off' As a developer, I can at least from the second ZCML example above, I can translate that 'for' into a 'getMultiAdapter' call. Which any 'integrator' whose doing their integration in Python may care about more anyways when they're trying to look something up programmatically. Besides, looking at any of the above, you're probably going to have to consult code at some point to really know what's up with the above. I don't see anyone who doesn't understand Python and Zope 3 as someone who would prosper in a land ruled only by ZCML. And I don't see anyone who understands Python as not getting infuriated with ZCML's roadblocks at some point of ZCML grows towards a more specialized language. > The fact that such developer-admins are the primary users of ZCML so far > is due to the small size of the Zope3 market to date. I actually see very little of ZCML as it stands now as being beneficial to admins who don't have some degree of developer in their blood. ZCML feels more developer oriented. But it also feels like it tries to coddle the developer to help them get up to speed faster. The downside of that is what happens when you're at full speed and ZCML locks you there. Besides, I think some of the reasons for the small size of the Zope 3 market (to date) is that ZCML is intimidating, or just annoying, to Python developers looking in from the outside. I still think that appealing to good, intelligent, passionate Python developers is what's going to grow Zope 3 by allowing many different kick ass products, sites, and applications to be built. Making it easy for a site administrator to install a couple of components isn't going to do much if there's not a lot of appeal for other developers who haven't already drunk the kool-aid to write those components. If you could get all of the lines of XML required to register a viewlet (in a readable style) down to: And have everything else in the Python code:: class BatchImportViewlet(ViewletBase): implements(IViewlet) adapts(...) I think it's then a lot more appealing to a Python programmer. There's nothing stopping a knowledgeable administrator from overriding that configuration call and establishing different permissions, or different 'provides'/'for' settings. Or a different name even. But I would expect such a person to be knowledgeable. Since most web sites and applications are matters of some degree of custom development and *not* just configuration, I think ZCML should be a thin layer and the Python layer should be robust. I think it would promote better code, components, applications, sites, etc, if the Python developer remained the chief focus of the current round of development. The community of developers will then provide the kick ass automatic-generated interfaces, or the 'ez-system-configuration' toolkit, and those will appeal to and be used by their specific audiences while a strong, clean, and powerful Zope rules all. And then I never have to lose a day finding out why my Choice field doesn't work. -- Jeff Shell ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Coarse-grained reuse.
x27;t handle this. Not unless the ZCML in question was basically a pointer to a callable object, at which point you've got an event handler all over again. I'm looking at my code to set up the authentication utility for some of our sites. Very specific rules about what plugins are needed (users, groups, http credentials) and things in those plugins (default groups). There's no way I'd want to automate that in anything BUT Python. (Plus, in its current form, this code can also be used by a view that responds to there being no auth system setup). -- Jeff Shell ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Coarse-grained reuse.
On 3/16/06, Martijn Faassen <[EMAIL PROTECTED]> wrote: > Jeff Shell wrote: > > I don't think there's anything wrong with "custom Python" code to set > > this up. It's programmatic, isn't it? A lot of it may be repetitive, > > and if that's the case, functions/methods can help. Are we all just so > > used to writing big long blocks of code in Zope 2 Python Scripts that > > we've forgotten we can do this? > > Writing Python code for setup is very handy, but we've also seen where > it went wrong in Zope 2. Writing Python code for setup therefore worries > me. What's the Zope 3 idea on this? It used to be simple: we had ZCML > for such things. But when I started using Zope 3 ZCML turned out to be > insufficient from the start for this activity, so I used Python code > (with an event hooked up to the site add event, too). And now, ZCML is > not going to be used for some of this anymore, so I become less certain. > > Where I think "just using Python code" starts going wrong (potentially) > is when I want to combine my setup Python code with your setup Python > code to build a larger application. Then you write a third batch of Python code that further tweaks, removes, or adds to what the combination of the first two do. This is only kindof setup. ZCML, again, is registering very very very core things. Like in Formulator's initialization code: set up the registries, register the core fields. That doesn't stamp out a form. When I build a Knowledge Base site, I'm going to need X and Y and Z in order to use it. I'm going to need each of those to be configured according to how I designed the knowledge base. Python gives me the best option for automating that, because it is (in a way) a kind of business logic: I'm indexing on these fields, I'm building Extent catalogs on these, uh, extents, I'm setting up groups and roles for user management according to these requirements. > I'd like there to be common patterns so there's at least a reasonable > chance that you can plug my TTW UI for user management into your > application without having to rewrite large parts of either. I'd also > like this pattern to be there when I'm *writing* my larger application, > so I say, 'okay, this is all for TTW user management' then, and then > more easily extract it later. I don't want your TTW UI for user management. No offense to your TTW UI for user management, but the chances of it meeting my requirements for style, presentation, ease of use, look and feel are not high. If you have tools that make it pretty easy, I'd probably love to use them. But I'm going to be customizing it to my application anyways. Now - this is for applications whose user management may be turned over to the customer, or is expected to run within the user interface of my custom application. If I were using a more generic data management interface for administration (ZMI, etc), it might be a different story. > > I'm trying to abstract some common Bottlerocket patterns out into new > > base framework/library for my company to use, and this is actually one > > of them. I was trying to come up with something last night for just > > this issue. Basically, I thought of writing a couple of interfaces > > that would do something *like* zope.app.generations, but instead of > > being a 'database opened' event response, used to automatically patch > > persistent data with the expectations of code, these things would work > > on a 'site added' event. What I didn't spend any time thinking about > > was whether to have future upgrades go through this tool, or through > > generations. > > This may be in the direction of a solution. I haven't studied > generations in detail, myself. Anyway, any such solution needs to be in > the common codebase, otherwise we're going to end up with a lot of > custom ones. Maybe. But I don't even know what the common codebase is going to be or wants to be these days. This is also a chance for someone to offer a "here today" alternative for others to install and use. > [snip design ideas] > > > * Using an adapter to bind the configurator to the site allows the > > 'framework' to handle when and how the configuration gets run for > > a particular site / added object, but doesn't worry about what it > > does. > > * Use the wonders of object oriented technology to provide a base > > class with helpful methods for the common configuration chores. > > * Use this same wonder to allow common sites to share common tasks > > for establishing local utilities. > > * Still have the power to be as progra
Re: [Zope3-dev] what is ZCML?
On 3/16/06, Martijn Faassen <[EMAIL PROTECTED]> wrote: > Shane Hathaway wrote: > [snip] > > But the ZCML I've > > written gives me a sick feeling, because I don't know how to refactor > > ZCML. The sick feeling doesn't go away, so I get scared of Zope 3. Then > > I come here, hoping to find comfort. > > I share these sentiments. Not that I have a particularly sick feeling > (I've been immunized by too much exposure? :) but because I'm grasping > for ways, patterns, to make my code look better, briefer, shorter, less > repetition, more reuability. Reuse is overrated. :) Honestly, I think reuse best happens in Python. I've found it easy to wrap and roll things up into more common APIs for personal use. This has been one of the really positive things of Zope 3. But for that sort of roll up to happen, the environment needs to support common refactoring patterns (extract method/class/etc). I do not believe that ZCML supports that. > > I would feel more comfortable if one of the following things were to > > happen: > > > > 1. The group acknowledges that repetition in ZCML is bad. > > I definitely acknowledge his one. > > > 2. Someone shows me how to avoid repetition in ZCML. Use less ZCML. Be creative. Have fun. This answer doesn't work for everybody, and isn't as easily applicable as I would like. > > 3. We decide that ZCML is a failed experiment. > > On the one hand, I'm not willing to do that. On the other hand, if ZCML > is to be a simple registration language, I am starting to idly wonder > why a bunch of CSV tables wouldn't do (and might not be clearer and > simpler). Because editing CSV tables sucks an even bigger electrical outlet. (Honestly - I'm too stupid to understand Excel... But maybe I'm saying that after spending a week writing an CSV inventory importer. Ugh). > If ZCML is to be a simple registration language, I'd also like there to > be a 1 to 1 mapping of ZCML statement to Python code. Right now there is > a mapping and while it may be reasonably straightforward, I personally > am still lost in APIs (and it looks like Jeff Shell is too). This > learning curve should be smaller. I agree. I think Jim said early on that ZCML should be theoretically replaceable. Looking at many of the directive implementations, I do not see this. If the "Zope 3 CA" vision that I had is to have a good chance of succeeding outside of this community, I'd hope that it doesn't ship with or require ZCML. > Whatever we do, if ZCML is to be replaced we need to replace it with > something. I think many of the notions of ZCML are dead on - this > registration shouldn't be happening in normal Python code mixed with the > rest but as a separate activity. It should allow overriding. It should > be amenable to analysis. I'm mixed about whether this should happen in normal Python code. A few months ago I laid out a vision for how I think it would work. Basically, configuration would have to be a very locked-down module: it couldn't really be imported by regular code, wouldn't really execute when called from 'regular' code. It would, in short, try to somehow enforce the "importing a package should NOT automatically register its components." > > 4. We decide that ZCML should gain more qualities of a high level language. > > I personally am quite interested in exploring this, but I'd like to see > some examples of what this would actually look like, concretely. We have a high level language. It's Python. I think that people just have gotten bad at thinking in objects and usable APIs and have somehow developed a strange fear of the language. I don't get it. class ArticleEditForm(form.EditForm): form_fields = fields.FormFields(IArticle, ITaggable) form_fields['tags'].custom_widget = ... Wow. So much better than . It's possible to design other parts of the system like this. I just know it is. "like this?" "yes" "what is this?" "respects the Python developer". Now I know forms are a special case, as Tres or Shane or both brought up. I was just impressed by the amount of actually-helpful objects, APIs, and base classes in formlib. That one package has made me more productive and flexible than most of the rest of Zope 3's default elements (zope.interface/component/schema/app.container excepted). I think we can learn something from it. At least, I hope we can. Zope can, at the end of the day, only provide some good core tools. I think those tools, and the concepts behind them, should be simple. Then if someone wants to build the giga-framework on top of it, they can. But also, if I'm writing what should be a simple application like the PyWebOff example, I don
Re: [Zope3-dev] Re: a plan for widgets?
On 3/16/06, Tres Seaver <[EMAIL PROTECTED]> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Martijn Faassen wrote: > > > > > * sources and terms are nice, but we should at least provide some basic > > sources and register some basic terms for them; that bit is completely > > missing in Zope 3 right now. People should be able to at make a simple > > drop-down widget happen without having to figure out how to tie all > > these components together - they should just import and use the right > > source, perhaps import, use, and register the right term, and there they > > go. Um. Straight up sources are pretty easy, especially when you use terms directly. We have a few Choice (and our own 'RelaxedChoice') fields in one application that get their values, at present, from tuples in a ``values.py`` file. ``values=values.area_codes``. Works fine for straight and simple sources. The problem I have with vocabularies is, ahem, the vocabulary. "they should just import and use the right source, perhaps import, use, and register the right term, and there they go"... what? As I mention below, I've ultimately started to find Vocabularies very useful. But I also found them incredibly daunting with a surprisingly high entry barrier. Terms, Tokens, Titles, deferred vocabulary loading and binding, direct vocabulary-field binding, the vocabulary registry (versus the Utility registry), the different vocabulary registry set up in zope.app, ... It's been hard to control and understand. And especially (strangely) hard to learn by interaction in the Python interpreter. > > > Hmm, another case where high-level ZCML support would be useful: > defining simple terms for a vocabulary. Why should somebody who wants > to tweak a vocabulary have to edit software? E.g.: > > > Plato > Aristotle > Immanuel Kant > > > Of course, we could also keep the vocabularies in another data file, and > merely have the high-level directive "source" it: > > name="philosophers" > file="philosophers.csv" > /> > > If - and only if - and really really really really really only if - you mean to do this, fix the HELL up the vocabulary registration stuff. That's where most of my time got lost when I had that debugging session the other week that pissed me off to no end about ZCML. I have no idea how I fixed my situation either. By the way, isn't it pretty easy to provide straight up values anyways for those quick drop-down situations? trip_type = zope.schema.Choice( title=_(u"Trip Type"), description=_(u"Trip Type"), default=u"Business", required=True, values=(u"Business", u"Personal"), ) replacementOptions = SimpleVocabulary(( SimpleTerm(value='none', title='No - keep all current articles'), SimpleTerm(value='matching', title='Only replace matching IDs'), SimpleTerm(value='all', title='Yes - replace all existing articles'), )) class ImportSchema(Interface): importfile = zope.schema.Bytes( title=u"Import Zip File", description=u"Zipe file of items to import.", required=True, ) replace = zope.schema.Choice( title=u"Replace existing articles?", vocabulary=replacementOptions, default='none', ) class ImportArticlesForm(form.Form): ... @form.action(u"Import Articles", failure='handleFailure') def importArticles(self, action, data): replace = data['replace'] zipped = self.openZip(data['importfile']) if replace == 'all': self.clearExistingArticles() ... Maybe someday I'll force us at Bottlerocket to make the time for me to at least put up a version of my knowledge base app so I can publish recipes I put up on the mailing list. I think that a lot of the easy / relatively easy aspects get obscured or lost. A recipe or tip for "how do I make a simple drop down?" would be nice. ___ 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: a plan for widgets?
On 3/17/06, Fred Drake <[EMAIL PROTECTED]> wrote: > On 3/17/06, Martijn Faassen <[EMAIL PROTECTED]> wrote: > > As far as I understood, vocabularies are on the way out in Zope 3.3: > > > > in zope.schema.interfaces: > > > > # BBB vocabularies are pending deprecation, hopefully in 3.3 > > That's correct. Gary and I invented vocabularies to solve some > problems. Jim followed up with "sources", which have fewer warts. In > Zope 3.2, Benji and I added iterable and named sources, so I think > sources now have the same basic range of functionality as > vocabularies. It should now be possible to use a source wherever a > vocabulary was used in the past. And it's all incredibly confusing. "Gluttony of choice" they call it. I settled on Vocabularies for an interesting widget/requirement because they were documented in the book. Trying to translate doctest-speak to how-do-i-make-this-work-in-my-project-speak on Sources was hard. Many ways of doing things, no way to understand when to choose one over the other. And it was frustrating to finally figure out vocabularies and see the "oh, but they'll probably be deprecated soon" comment in the code. Not that I have anything against Sources. But for me, sources and vocabularies were another long headache. My fancy vocabulary and widget implementation is *GREAT* and now I understand the reasoning behind the design. But the road there was very long. And I still have absolutely no idea how the queriable stuff is supposed to behave. > > I may have this wrong, but that's what I read in the code. We've used > > vocabularies before, but apparently they're deprecated. > > Please try to revise your applications to use sources. If there's > anything missing for sources, it may make sense to delay the > deprecation of vocabularies. It would also indicate that what needs > to be added to allow sources to replace vocabularies. Vocabularies are at least documented in the Zope 3 books that are out there. It took me a couple of re-reads of the chapter just to understand *them*. I printed out the Source doctest docs and started down an implementation path in a different application, but I didn't get far (mostly due to that experience being an experiment). I'm going to keep pushing the guys I work with to let me have a sandbox where I can put up a site with recipes and tips and whatnot. If I'm supposed to "try to revise my application to use sources", there needs to be a couple of good narrative pieces about what this means. I depend heavily on custom vocabularies for a customer application I'm about to resume work on this week. I don't think I'm going to have time to do any such revision. But I would like to know (or help others know) how to apply such a revision in the future. -- Jeff Shell ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: a plan for widgets?
On 3/17/06, Tres Seaver <[EMAIL PROTECTED]> wrote: > Jeff Shell wrote: > > By the way, isn't it pretty easy to provide straight up values anyways > > for those quick drop-down situations? > > > > You're missing the point -- the vocabulary is *not* software, and Python > is *completely* the wrong place to define it: it is *pure* policy. THe > fact that you are administering all the sites you build blinds you to > this fact. > > My examples move the definition of the vocabulary out into integrator / > administrator land, which is where they belong. No. I think they are software. Or can be as much software as anything else. Sometimes I don't care what the values I get for a Choice field are. Sometimes I care very very very much. With the interfaces, vocabularies can come from a lot of sources. Personally, if I were giving someone an editable vocabulary list in text because they were an 'integrator/administrator', I'd write a Vocabulary object that used something like YAML. Or CSV if that's what the user that's meant to maintain it is. But I'm not going to turn over site.zcml or overrides.zcml with all of its other crap just to let a secretary add an airport code to a "preferred destinations" vocabulary. There's nothing in the Zope 3 implementation stopping you from having the definition come in from outside. But don't restrict me from using Python just to make a bone stupid simple list of values when I have 100% or even 80% surety that it's *not* something that needs to be an editable policy. It's a waste of time, it's another layer of confusion, and as I said above: this is another policy thing that may not even be maintained by any 'administrator/integrator'. So if there was just one concept of a registered Vocabulary: that of a named utility providing the IVocabulary (or a derivative) interface, then it's easy: write one for your integrators/administrators that sources itself from ZCML, OPML, RDF, whatever. I don't need it. For me, it becomes a maintenance nightmare, or just a roadblock early on. So maybe I am blind. But I **absolutely do not need to worry about integrators/administrators**. And I absolutely hate wasting time writing something that hurts me to write and maintain for a role that I, nor my colleagues, nor my customers, really have to play. Maybe you do. But then, you should do like I do and build yourself some frameworks on top of Zope that suit your world, your customers needs, etc, and work through those. Don't make me have to jump through hoops and XML pain just to make a "yes/no/maybe" option list just because there's this theoretical person out there that might want to add a "maybe not" after they find it buried deep within the trenches of XML files buried in an Egg. -- Jeff Shell ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Re: a plan for widgets?
On 3/17/06, Sidnei da Silva <[EMAIL PROTECTED]> wrote: > On Fri, Mar 17, 2006 at 09:08:14AM -, Martin Aspeli wrote: > | 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? :) > > A endorsement I guess, since Mr. Shell seems to think that's the Right > Way (tm). I'm not sure if it's the Right Way or not. But it's the way that's available now and makes enough sense for simple situations. -- Jeff Shell ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: a plan for widgets?
On 3/20/06, Tres Seaver <[EMAIL PROTECTED]> wrote: > So *don't use ZCML*; use Python: there is literally nothing which can > be done in ZCML which cannot be done in Python. I wish that folks who > don't like / need ZCML would quit trying to dictate how the rest of us > use ZCML. "Literally nothing"? Try literally everything. I'm sorry. But that was the experience I had that set me in such a bad temperament. I had no idea what half of these directives were doing, and when trying to duplicate them in a test environment I nearly threw the laptop to the ground and swore of programming forever. I was *INCREDIBLY* frustrated. There is a lot of potentially valuable functionality *hidden behind ZCML*. If a ZCML directive were a one line wrapper/adapter around a common function, I'd feel different. My argument and wish has been only this: simplify ZCML. Make it more transparent what it is doing. > Or, if you like ZCML but don't like the current directive set, feel free > to propose a new set of directives you think are better, and implment > them in *your* namespace: if enough other people like them, we can talk > about making people who are already using the current set change. But > let's quit tearing up what people have alredy learned in favor of a > it-must-be-better-because-its-new variant which doesn't yet exist, and > whose improved usability we have to take on faith. My set of directives is , , , and maybe . Inside of , , , , and (because I do believe that 'factory' there is a nice shortcut). Nothing new. Only less. Less concepts to have to remember. Less concepts to have to look up. Less code to have to try to follow when it's 10:30 at night and I've been working six hours too long and I still can't figure out why my field adapter on an IChoice isn't getting its value set properly and I can't get a vocabulary bootstrapped up to write a test to debug and then verify the fix of it. Make ZCML do whatever you want. But if you're going to share it, it needs a HELLUVA lot better documentation. I'm glad for what's there now. But I've been surprised by ZCML one time too many, and have lost too many hours trying to figure out the surprise. Too many similar directives, too many possible attribute combinations, and too little information about what certain choices will actually do or what they're good for. And the source is not a readable, reliable backup point to look at. > I'll note that the "Refactor mercilessly" meme from XP is *not* > particularly well-suited to frameworks / libraries: it is best suited > when applied to *applications*, where the impacts of such changes are > borne entirely by the people who make them. When you tear up the API of > a framework / library, you force *other* people to make changes, often > without any particular benefit to them. What is well suited to frameworks and libraries is to provide maximum playability with a minimum number of concepts. When the component architecture was simplified (Zope 3.0 -> Zope 3.1), the whole thing suddenly made a whole lot more sense to me. Utilities and Adapters. Nice. There are a lot of ways those can be combined, especially when multi-adapters come into play. But the core concepts are clean and simple. Transparency also counts, especially with open source. Even with books and APIDOC, I still have to consult the source a lot (and a lot (and a lot (and a lot (and a lot to try to understand the best application / use of something. ZCML lacks transparency - the language of the directive implementation seldom plays out like something I can read and understand. There's another framework, another run-time, going on there. And I understand why: it's bootleg/startup service. But when shit breaks, or acts funny, debugging it is nearly impossible. At least with Zope 2's initialize(context), I could stick a pdb.set_trace() at the beginning of such a function implementation to step through the loading process. It wasn't the easiest code to follow, and was a long and painful process sometimes, but I could at least follow obscure (and accidental) bugs and problems to the source. Go ahead and make ZCML the most beautiful new language you want it to be. But it's got *severe* problems right now. And the "just about anything doable in ZCML can be done in Python" line does not work. I have scars to prove it. -- Jeff Shell ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] ZCML, Paths, and the Things You Actually Want To Change At Configuration Time
"No sir, I am a real horse" Another frustrating aspect of ZCML is that the things you actually WANT to have sys-admin style control over the configuration of seem to get buried. I'm talking about things where the configuration is always specific to the running environment, things like: * RDB adapters (database name, connection/login information, etc) * Mailers (hostname, port) and Delivery systems (queue directory, etc) * Additional browser Resources (ie, using a special directory outside of instance home as a drop-zone for a webcam, so that a zope application can just refer to the resource like @@/webcam/latest.jpg or whatever). These are the things that can easily get buried in source code, in the midst of enormous ZCML files or lost within a large package hierarchy. And it's not until you move from a development server to staging (or back) that you realize "oh crap, can't load up, that directory doesn't exist here!") Is there any good pattern for dealing with this? The best we can think of, right now, for our policy at Bottlerocket is to have an INSTALL.txt file that provides descriptions / examples of expected mailers, rdb connectors, etc, so that they can be put into overrides.zcml (I guess that's the right place?) and set up easily for their target environment. We've also talked of having an etc/ or environments/ directory in a package/application that would house ZCML files that configured the machine-specific resources, would keep them in source control, and in each deployment the includes would include something like: This is an area where I would like to see ZCML really provide help for configurations - where the application's configurations (sigh) could specify "expects mailer utility with name 'example-mailer'" or "expects an RDB adapter with the name 'example_db'", and at startup time the ZCML could complain if at the end of all of the meta, configure, and overrides loading it never came across an 'example-mailer' declaration and could say "The Example package requires an email utility with the name 'example-mailer'" - set one up by putting something like this in overrides.zcml to configure mail support."... something that'd make it obvious that a machine specific resource was missed, or not configured. These are the little things we forget about (especially when more than a couple of months have gone by since active application development), and whenever code has to be moved between machines, we deal with all of these bits blowing up because they were just forgotten. Speaking of mailers. The path support in ZCML is lousy and fights against customization and environmental configuration. Tools like the Queued mail delivery should *probably* be putting things in $INSTANCE_HOME/var. At least, that would be a good option to have. Then one could configure some of those things in the application's configuration and generally have it work anywhere. As it stands right now, the queue directory and other such paths are local to the configuration. And I had many a CVS update blow up because I didn't have a 'mail/...' directory inside a package I had checked out. It would be nice, I think, to expose some sort of environmental variables to the Path field in ZCML to refer to the instance home and maybe to other variables that could be set up in ZConfig (other common roots), since ZConfig actually supports the ability to define new variables for things like that. I also suggested, a long time ago, to support a way to address paths relative to packages. I remember in early Zope 3 experiments making a little product, and then trying to make a product that built on it. In one product, I'd have something like: package: example1: In another package, I subclassed Foo and wanted to register that as an alternate view. class SubFoo(example1.Foo): ... You can't refer to foo.pt here! You have to copy it! This really bit me when it came to using the browser:*form directives in a base framework we used to build our apps, and then tried to use in other packages. This is one of the HUGE reasons why I grew to hate the browser:* directives and found them to hinder reuse much more than they ever helped it. But anyways, I thought (and still think) there should be - if this kind of ZCML is to continue - a way to address package relative paths. I swear someone made an implementation of this at some point. As far as I can tell, the 'Path' schema field is not much more than a string. For a 'configuration' language, that's rough. -- Jeff Shell ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Riddle: zope.interface versus zope.formlib
g trick field = iface[name].bind(None) # IBar extends IFoo, therefor IBar['title'] if field.interface.isEqualOrExtendedBy(iface): field.interface = iface return field Then when establishing fields in formlib.FormFields, one could use this on single items or en masse. Maybe `form.Fields` could have a constructor option of 'normalize=(*ifaces)', which will downcast items. Or maybe 'getFieldIn' could take Field objects as well as names. Or ... Before playing with it, I would like to know what other people think. So, what do you think? I think that you haven't explained the situation adequately. I understand what you're saying: "Oh, suddenly I wanted/expected IBar['title'] to be bound to IBar when really it was bound to IFoo," but I don't understand the solution that you're trying to get to and why. Specifically, I don't get how it "hurts formlib." I think a good copy-and-modify tool for zope.interface.Attribute (or at least zope.schema.Field) objects would be a more useful tool. I think it should be part of the Field interface so that complex fields (like the vocabulary-using ones) can do extra work if required. And I think that some more clarity about how adaptation is used in formlib's different setUp*Widgets and applyChanges methods might be a good thing to have. I really like the pretty-much-automatic adaptation that goes on, most of the time, but I find myself having to mind-trace the source quite a bit just to remember the impact of different options, parameters, or methods. I think it would also be nice if it were easier to register/use one-shot adapters that are made for just one form (I've done this in the past, and it feels like a waste of typing and time and effort to go through all the joys of ZCML registration and naming and thought just to use a particular Adapter class/factory once - especially if I'm doing the adaptation for just two fields out of, say, eight). -- Jeff Shell ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Python version for Zope 3.4 ?
On 9/28/06, Philipp von Weitershausen <[EMAIL PROTECTED]> wrote: Christian Theune wrote: > Morning, > > Baiju M wrote: >> Hi, >> What is the target Python version for Zope 3.4, is it Python 2.5? > > Right now it's still Python 2.4, as Zope 3.4 is scheduled for next year, > we should consider using Python 2.5 though. We should definitely try to *support* Python 2.5, but we can't require it till Zope 2 has been "certified" for it. Why isn't Python 2.5 even supported at present? Does Zope 3.3.0 flat-out break when run on 2.5? Or does Zope 3.3 + Python 2.5 work, but it hasn't been tested enough to say "it's usable, but not required"? -- Jeff Shell ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: Re: [Zope3-dev] Python version for Zope 3.4 ?
On 9/28/06, Martijn Faassen <[EMAIL PROTECTED]> wrote: Jim Fulton wrote: > Baiju M wrote: >> Hi, >> What is the target Python version for Zope 3.4, is it Python 2.5? > > That's a good question. I fear it will take a fair bit of work to > get to it and, frankly for me there are higher priorities. I think we'd be okay in not supporting Python 2.5 yet for this release. Python 2.5 has just been released, and the 9 months or so will give it time to gell out, Python extensions a bit of time to catch up with the newer version, and for us to do some experimenting. Linux distributions will likely still be supporting Python 2.4 (along with 2.5) at that stage as well. Are you talking not-supporting Python 2.5 at all? Or just not wanting to require it? If Zope 3 can't at least run on Python 2.5 within three months of Python 2.5's release, I don't think that looks good for us. I would hope that by being more "Pythonic" and free from the old ExtensionClass magic - especially in Zope 3 - that Zope could keep better pace with Python. But nine months? A year? Can I expect the developers of toolkits we use, in some cases more heavily than Zope itself, like SQLAlchemy to hold off on requiring Python 2.5 for that long? So unless a volunteer steps up to do lots of hard work between now and march next year, let's stick with Python 2.4. Otherwise let's plan it in for Zope 3.5 and Zope 2.12 I really really really hope it doesn't take that long to be able to at least run on Python 2.5: even if it has to be with some caveats or mild warnings. If security and restricted python / security proxies are the main issue, what about if one is running Zope sites with absolutely ZERO through the web code - no page templates, nothing - can't there be a lighter weight security implementation that wouldn't take half a year of "lots of hard work"? -- Jeff Shell ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: Re: Use launchpad ! (was Re: [Zope3-dev] the maintenance of change logs)
On 9/25/06, Martijn Faassen <[EMAIL PROTECTED]> wrote: Baiju M wrote: > On 9/22/06, Jim Fulton <[EMAIL PROTECTED]> wrote: > >> Finally, I'm experimenting with using launchpad for bugs: >> >>https://launchpad.net/products/zc.buildout/+bugs >> >> and feature requests: >> >>https://features.launchpad.net/products/zc.buildout/ >> >> So far this is working OK. I haven't really stressed it. Launchpad >> makes this very easy to set up and I don't think they are allergic to >> having us create lots of projects. > > Let's move Zope3 issue collector to launchpad? > (Once this discussion came to ZF list, I think there were more +1) Before we move any issue collectors to launchpad, we need a bit more experience with the launchpad issue tracker and its capabilities. I'm also wonder whether launchpad has good issue export facilities in case we want to move to another system. With Tres, I think we should also explore options like Trac. I personally think Trac has attractive features in the way it integrates the development process into things like an issue tracker. I love Trac. I've never installed it or used it to manage any projects on my own, but I find that I stay on top of open source projects more if they're using Trac. On a small aesthetics side, I find Launchpad's side bars incredibly distracting, and I don't like looking at the page because it feels like there are too many things vying for my attention and I have a hard time really reading the text in front of me. The content gets squished. And then I find myself looking at all of these links and buttons around the page trying to figure out what has the information I'm interested in. The sidebar on Zope.org bothers me in the same way when I try to read the Zope 3 wiki - but Zope.org feels nowhere near as noisy as Launchpad. I'm sure their tools are great, and the hosting service is a good feature. But my temper is short these days. My attention span is not: if I can find and read a page that's not full of distractions, I'll stay and read it and learn. But when there are boxes on all sides chock full of colors and links, reading is much harder. A nice simple example is this nice page in SQLAlchemy's Trac wiki (a page I read over and over as I migrated code to 0.2): http://www.sqlalchemy.org/trac/wiki/02Migration It's very nice. I can read that page, print it, save it to a local permanent archive, etc. There is something about Trac's feature set, implementation, and in how it's installed (in most cases) that make it very nice for a cantankerous, stressed out, often overburdened worker like me to stay on top of and even want to get involved (even on some small level) with a project - and that I can do this in small amounts of time. The Zope 3 wiki, collector, and even subversion browser, all feel like they require more of a full time job to stay involved. And if not a full time job, then at least some seriously set-aside time. It's very hard to get answers to "what's gone on recently?", "what are all of the bugs, and let me see and sort them quickly on some different criteria, and let me then see how they were fixed, and then let me quickly find some minor annoyance issues that I might be able to fix". With a Trac setup like SQLAlchemy is using, I feel like I can do this at home in the morning during my browse-and-drink-coffee-time. With the current Zope tools (and my limited experience with Launchpad's tools), it does not feel casual at all to keep up with everything going on. And that makes it hard to stay enthusiastic and energized about a project. Compare: - http://dev.zope.org/Zope3/RoadMap - http://www.sqlalchemy.org/trac/milestone/0.3.0?by=severity I wish there had been something like that Trac milestone page for Zope 3.3. Of course, it doesn't show everything going on. But it would have made it much easier to find out what may have been slowing the release down so much, and then easier to want to get involved and make it happen sooner. The lack of distracting side columns, the integration of the Wiki, the Roadmaps/Milestones, the Subversion integration (being able to refer to tickets, wiki pages, etc in commit log messages and having the links generated in the web. [ticket:309], etc), the custom issue tracker reports: it's a very nice system to use, even casually. The Timeline is like a Wiki's "Recent Changes" on crack. Except the crack is filled with helpful vitamins: recent wiki changes, recent checkins, recent issue tracker activity (bugs submitted, opened, closed). It just feels so much more alive. -- Jeff Shell ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: Re: [ZF] Re: Use launchpad ! (was Re: [Zope3-dev] the maintenance of change logs)
On 9/29/06, Steve Alexander <[EMAIL PROTECTED]> wrote: >> On a small aesthetics side, I find Launchpad's side bars incredibly >> distracting, and I don't like looking at the page because it feels >> like there are too many things vying for my attention and I have a >> hard time really reading the text in front of me. The content gets >> squished. And then I find myself looking at all of these links and >> buttons around the page trying to figure out what has the information >> I'm interested in. The sidebar on Zope.org bothers me in the same way >> when I try to read the Zope 3 wiki - but Zope.org feels nowhere near >> as noisy as Launchpad. I'm sure their tools are great, and the hosting >> service is a good feature. I understand what you're saying about the Launchpad UI, and I agree with it. There's a significant re-design of the Launchpad UI underway right now that ought to address many of these issues. It won't be on the live site for a couple of months, though. I see that you have Matthew P Thomas involved. I know he's had some good writings in the past about usability and consistency. And after looking at `help.launchpad.net` really quickly, I now realize the big seller for Launchpad: bug tracking across multiple projects. With all of the little Zope things out there (zc.catalog, zc.buildout, etc), it would be good to be able to share such data between them. Actually, this is an issue that my very small company runs into frequently - needing to focus on specific projects while also keeping an eye on the underlying tools and frameworks. So many other systems seem suited for just-one-project-at-a-time, and it's frustrating to try to keep track of issues four layers down from customer-specific code. So: I really like Launchpad's goals and intentions. But its a usability nightmare to me as a casual visitor. And I've found that for me, personally, it's hard to stay involved with or on top of a project in that situation, especially when I'm stressed out (like I have been the past few days). I look forward to seeing the re-design. -- Jeff Shell ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: Re: [Zope3-dev] Grrr. zope.org wikis are evil.
On 10/7/06, Jim Fulton <[EMAIL PROTECTED]> wrote: Fred Drake wrote: > So whatever the ZF's plans for dealing with zope.org, I think there's > no way to go wrong with the wikis except by keeping what we have now. > While it's nice to use a Zope-based solution, I think we need to just > get a solution that works. That could be a Zope 2 installation with a > recent version of ZWiki, or something else (MoinMoin would make me > happy as well, and has good reStructuredText support these days). reStructuredText support would be greaet. As well as EXPLICIT Wiki links. All those damn question marks on things that shouldn't be drives me absolutely batty. I believe that Wikipedia is incredibly useful because its links have to be explicit, and not accidently by way of FunNy SpellIng. > Yeah, I'm grumbling. It's Friday night, and I've had it with the > archaic StructuredText. If we end up using Trac, we'll be using that wiki. 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. I think reStructuredText and Markdown are quite acceptable structured text syntaxes, especially for an audience that is largely technical. I think a system that facilitates easy copying and pasting from doctest documents, formatted doc strings, emails, etc, is ideal. We have a Knowledge Base application developed in-house that allows use of Textile, reStructuredText, Markdown, Plain Text, etc. The big benefit is that its easy to bring in data from sources ranging from Writeboards (Textile) to Zope 3 doctests and our own docstrings and other in-code documents with just a copy and paste. WYSIWYG editors for browsers are getting better, but they can still be a bit slow, taking me back to using geoWrite on the Commodore 64. Type'n'wait :). But yeah... I've found it much easier to share and upload technical documentation when the Wiki / Knowledge Base / Whatever supports the structured text syntax I've been writing in. Oh well. I absolutely agree that we need to replace the existing wikis. One other thing we'll need to consider is anti-spam capabilities. I'll agree with this agreement. -- Jeff Shell ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Big Problem with FTP in Zope 3.3.0, seems to be the result of using `v = self.get(name, self); if v is self...` in a land where Proxy objects can kill identity comparison
I probably needed to because my first try - "Let's see if IReadDirectory is doing the right thing by firing up debugzope.." - worked as expected. Moral of the story: don't use ``query/get (..., default=self)``, ``if value is self`` paradigm? Be careful of identity comparisons? Is there a moral? Is there any reason why the ``_marker = object() get(..., default=_marker)`` paradigm isn't used? After encountering this, I am rather uneasy about the number of places in which I see this "self as default marker check" paradigm. My biggest unease comes from not knowing proxies and when things are proxied and when they're not and when I have to be careful about them and when I don't. Anyways, for our particular FTP problem, I can patch around it since we have a custom Read Directory adapter anyway. -- Jeff Shell ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Big Problem with FTP in Zope 3.3.0, seems to be the result of using `v = self.get(name, self); if v is self...` in a land where Proxy objects can kill identity comparison
I have to follow this up. While I thought I was doing a good job
reporting and testing the problem, I didn't do a hard enough
control-group study. So, I started to investigate further:
Even though I saw absolutely nothing about our ReadDirectory subclass
that would cause the strange behavior, I decided to double check the
behavior against a fresh install of Zope 3.3.0, with only my
pdb.set_trace statement in place (this time I placed it in
``zope.app.filerepresentation.ReadDirectory.__getitem__`` so I could
watch traversal).
Trying to chdir to '/customer/bogus' in FTP yielded the desired result::
ftp> cd customer/bogus
550 /customer/bogus: No such file or directory.
After seeing that, I stepped through the debugger. Sure enough, the
``if v is self`` failed in ``ReadDirectory.__getitem__``, causing the
situation I explained before:
Basically, in the FTP situation (or any situation wherein proxies are
being made), the following scenario happens. The _dir is used in place
of 'self' to show that it's what ultimately gets returned to the
publisher::
1. publishTraverse('bogus') from customer
2. _dir = IReadDirectory(customer)
3. _dir['bogus'] is called
a. v = _dir.get('bogus', _dir) [returns _dir]
b. ``if v is _dir: raise KeyError('bogus')`` fails, as v and _dir
are the same proxied objects, but have diferent identities at the
Python level.
c. Instead of raising a KeyError on the bogus (ha!) name, ``_dir``
is returned.
So this phantom ReadDirectory object gets sent out to the publisher.
The same situation is happening on a clean Zope 3.3.0 instance and on
the instance on which we found the problem (which provides a
subclassed ReadDirectory adapter for our container objects). If Zope's
ReadDirectory and Bottlerocket's ContentContainerReadDirectory are
being pushed up to the publisher as phantoms in each case, why does
the default setup return the proper FTP "No such file" error where the
Bottlerocket setup allows one to enter this non-existing directory?
I traced the behavior down to
``zope.app.publication.ftp.FTPPublication`` and the *callObject*
method. `callObject` essentially is doing this (staying with the
'_dir' object mentioned above)::
_dir = ob
view = queryMultiAdapter((ob, ftprequest), name='ls', default=self)
Ignoring the ``default=self`` here, `queryMultiAdapter` **fails on the
default setup, but returns FTPView in our custom setup!** Again - we
do nothing special in our ZCML registration, and our custom setup
subclasses from the default ReadDirectory, what's going on? I decided
to look at the list of provided interfaces at the moment of
``FTPPublication.callObject``
The behavior of a *clean setup*, doing ``chdir ... bogus``::
(Pdb) pp list(providedBy(ob).__sro__)
[,
,
]
Hmmm. So I tried this on our *custom setup*, and got this::
(Pdb) pp list(providedBy(ob).__sro__)
[,
,
,
,
,
,
,
,
,
,
]
Well it turns out that there's one place wherein we diverge from the
base ReadDirectory: we include a ``zope.interface.implements``
declaration::
class ContentContainerReadDirectory(ReadDirectory):
implements(zope.filerepresentation.interfaces.IReadDirectory)
Between the screaming and the sobbing, I commented out the
``implements`` line and tried again::
(Pdb) pp list(providedBy(ob).__sro__)
[,
,
,
]
And lo and behold, our custom setup worked::
ftp> cd /customer/bogus
550 /customer/bogus: No such file or directory.
So!!! This situation happened because our class had the audacity to
declare its instances' provided interface! The same interface that the
ZCML adapter declarations say they provide. It seems to change the
interface / specification order in a way that then elicits different
behavior. The FTPView commands are registered for IReadContainer,
which is the direct parent of IReadDirectory.. So when I had the
``implements`` line in our custom setup, we could change into those
non-existing directories since the IReadDirectory adapter of the
parent directory ('customer') was being returned by its own getitem
lookup; and by declaring implements directly, IReadContainer shows up
in the SRO, allowing Zope to go ahead and bind the 'ls' view to this
funky directory.
This seems MAJORLY broken: the only way to get the right behavior
(aside from patching / overriding getitem) is to NOT declare support
(in Python) for the interface my IReadDirectory adapters provide.
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Zope 3.3.0 - Why is the minimum generation for 'zope.app' 1? What's a good practice to update to generation 5 prior to my own evolver?
I'm working on moving an old customer to our updated CMS. Their current site is running on Zope 3.1, with our new work being done on Zope 3.3. I've gone through their project, removing deprecation warnings, and watched the code work against a fresh / clean ZODB. But when I moved one of the old development databases over, things started blowing up immediately. It appears to be coming from our CMS core's evolver code. The latest generation (2) removes the old zope.app.catalog instance and replaces it and its indexes with a new zc.catalog Extent Catalog and indexes. On the last job I worked on (the first customer developed with our revised CMS), this evolver script ran fine. But that customer's ZODB started out fresh on Zope 3.3. New customer (on fresh ZODB):: >>> connection = debugger.db.open(); cr = connection.root() >>> cr['zope.app.generations'].items() [(u'br.cms', 2), (u'zope.app', 5)] Old customer (old ZODB, trying to evolve to new, running on Zope 3.3). This is the report _FROM_ the Zope 3.3 instance:: >>> connection = debugger.db.open(); cr = connection.root() >>> cr['zope.app.generations'].items() [(u'br.cms', 1), (u'zope.app', 1)] I would like those numbers to be 2 and 5. But Zope's default evolution mechanism is to "evolve to minimum," and the zope.app schema manager is configured like this:: ZopeAppSchemaManager = SchemaManager( minimum_generation=1, generation=5, package_name=key) Great. Well it turns out that generations 2 through 5 do some pretty important things. In my case, I'm interested in generation 4 which evolves the Registrations so that I can unregister and delete an old catalog and replace it with zc.catalog. Unless my ZODB is updated to at least generation 4, I can't even do this from the ZMI. I downloaded Zope 3.3 again just to look at the docs to see if there was any tidbit that I missed about using generations. Because this 'evolve to minimum' scenario is just raising hell. Go ahead - find an old ZODB, run it on Zope 3.3, and try to unregister or remove a Utility in a ++etc++site/default scenario. I doubt it will work. Has no one else run into this? This is another element that seems very broken: there's this code to update one's ZODB instance when moving to a new Zope version, but it's not configured to ever execute by default. And there isn't any "how to update your ZODB" documentation that even mentions "you may want to add the following to your overrides.zcml to ensure that the ZODB is updated to its current generation, as the minimum generation may not work on your data". Is there a reason for this? Finally, is there any way that I can easily add guards in my own scheme manager evolve() scripts to ensure that other evolutions have happened first? My `br.cms generation 2` evolver depends on the new registration system, which isn't in place on older ZODB instances unless zope.app is at generation 4 or later. This is a huge issue. I promised my boss that we could update and upgrade this old customer's code in less than a day. The customer's code now loads up without deprecation warnings on a fresh ZODB, but I'm struggling to load up an old ZODB copy with real data, and am now suddenly behind schedule. We have at least three more customer code bases beyond this one that we want to update as well. I'm trying to think of a better way to automate this situation for us so that development and deployment can be pretty transparent. -- Jeff Shell ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: Re: [Zope3-dev] Zope 3.3.0 - Why is the minimum generation for 'zope.app' 1? What's a good practice to update to generation 5 prior to my own evolver?
On 11/3/06, Christian Theune <[EMAIL PROTECTED]> wrote: Hi, what about calling the evolve() scripts from your generation? That would be reasonable IMHO. I'm trying to do that now. And now it seems that evolve3 (for zope.app) is failing because it wants to use the new Registrations system to do something to Pluggable Auth group folders...? But of course, the new registrations system won't work until evolve4! Blargh. I was hoping to run the zope.app registrations fairly "properly" through the schema manager, starting from the current until I got to the level I require... But it looks like I'll have to manually monkey with the order... :( I blame myself. I should have gotten more involved during the beta testing period for Zope 3.3, just to test it against our old databases... It's been a rough week. -- Jeff Shell ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: Re: [Zope3-dev] Zope 3.3.0 - Why is the minimum generation for 'zope.app' 1? What's a good practice to update to generation 5 prior to my own evolver?
Oops; I think I sent this reply (initially) only to Christian. I'm sharing it now with the group. I still don't know what's going on. I finally got it working (it appears) for us by writing my own evolver that forced removal of all old Utility Registrations and also forced removing the Dependencies on the local utilities themselves. But it wasn't enough. We have to go back to Zope 3.1 for this particular project. We've lost way too much time wrestling with obscure issues last week, and I've declared Zope as "hazardous to my health" as it was the final straw that got me smoking again after two months clean. On 11/3/06, Christian Theune <[EMAIL PROTECTED]> wrote: Jeff Shell wrote: > On 11/3/06, Christian Theune <[EMAIL PROTECTED]> wrote: >> Hi, >> >> what about calling the evolve() scripts from your generation? That would >> be reasonable IMHO. > > I'm trying to do that now. And now it seems that evolve3 (for > zope.app) is failing because it wants to use the new Registrations > system to do something to Pluggable Auth group folders...? But of > course, the new registrations system won't work until evolve4! > > Blargh. I was hoping to run the zope.app registrations fairly > "properly" through the schema manager, starting from the current until > I got to the level I require... But it looks like I'll have to > manually monkey with the order... Humm. I know that. I thought we evened that out during beta. Out of curiosity: did you try bumping the minimum version to 5 so all generations get run at once? I tried running the 'evolve-maximum' subscriber, and set my product's maximum to just be '1' for now instead of 2 (2 being the one that wants to use the registration system). It still errors out in zope.app generation 3... Waaa! -- Jeff Shell ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Bugday today
On 11/15/06, Christian Theune <[EMAIL PROTECTED]> wrote: Hi, just a quick reminder: Today is a bugday to help get Zope 3.3 virtually free of bugs (by handling bugs from the collector.) Any status report on this? The collector state(s) seem unchanged. -- Jeff Shell ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Applying schema data on an object
On 12/13/06, Christian Theune <[EMAIL PROTECTED]> wrote: Hi, I've been trying to DRY some code and found that the following pattern keeps popping up: class SomeObject(object): def __init__(self, many_keyword_arguments): self.y = y self.x = x self.z = z From the outside this then is called from a view (where data comes from a formlib AddForm: def create(self, **data) return SomeObject(**data) I'd like to remove the explicit assignments from the constructor and use a function to do this in a generic way. I didn't find anything that does this yet, except from a formlib function that requires FormFields instead of a schema, so I wrote my own: - def set_schema_data(context, schema, data): """Update the context's attributes with the given data that belongs to the specified schema. """ for name in schema: field = schema[name] if not zope.schema.interfaces.IField.providedBy(field): continue if name in data: field.set(context, data[name]) - I've used a similar pattern for a while - especially in a couple of non-zope experiments that used interfaces and schema. I've noticed that I seldom write initializers for my persistent objects anymore, as I often have formlib or some other function applying data. That's probably a bad habit. One thing that I like about formlib is the ability to combine fields from multiple Interfaces together, and have adaptation apply them. Outside of form usage, however, this might not be as necessary. With forms, it's excellent, as DublinCore fields (like 'title') can easily be included in the field set. There are more complex things you could do in here, such as validation or setting of defaults. Even without that, here's what I would do:: import zope.schema def applyschema(target, data, schema, validate=False, applydefaults=False): for name, field in zope.schema.getFieldsInOrder(schema): field = field.bind(target) if name not in data: if applydefaults: field.set(target, field.default) continue value = data.get(name) if validate: field.validate(value) field.set(target, value) There is a function around already which comes from zope.formlib and requires the schema to be specified as a FormFields setup. I'd like to not have the formlib dependency in this code. I propose to include the given function in zope.schema or zope.interface. Eventually this could also be spelled as a method on a schema (symmetrical to field.set): schema.set(object, data) Would that then be a function of Interfaces? zope.schema is basically nothing but a bunch of extensions of `zope.interface.Attribute` and some helper functions to filter out Field objects from the Interface's members. If applied to zope.interface, you'd have to either move the basic definition of a 'schema field' to zope.interface (which I believe is beyond its scope), or have 'schema.set' work for Attributes (but not interface.Method, which is also extensions of Attribute). I'd propose putting this in `zope.schema._schema` or some other module in zope.schema for utility functions. It could also include my favorite trick - a schema-to-dict-by-way-of-tuple-pairs iterator! def __iter__(self): """ Yields pairs of (name, value) reflecting IStreetAddress """ for name, field in zope.schema.getFieldsInOrder(IStreetAddress): yield (name, field.query(self, field.default)) Since ``dict(iterable)`` works if the iterable produces (key,value) pairs, this is a handy to get consistent mappings out of objects. I use the above heavily to copy / move address data around between ZODB, RDBMS (via SQLAlchemy), and CSV files. Maybe made as a general function like this? :: _marker = object() def pairs(source, schema, applydefaults=True): """ Yields pairs of (name, value) from `source` based on the schema fields in 'schema'. If 'applydefaults' is True (default), missing values will be replaced with the default specified on the field. """ for name, field in zope.schema.getFieldsInOrder(schema): value = field.query(source, _marker) if (value is _marker) and applydefaults: value = field.default yield (name, value) address = dict(pairs(contact.address, IStreetAddress)) # or pprint.pprint(list(pairs(contact.address, IStreetAddress))) that latter one is handy when debugging. -- Jeff Shell ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Do not serialize one attribute
On 12/14/06, Florian Lindner <[EMAIL PROTECTED]> wrote: Hello, I have a object, derived from Persistent when contain one attribute which is not serializable and that's not a problem for me, but Zope complains about that. Can I mark this attribute somehow as "not to serialize" and make Zope call a member function when it has unserialized this object so I can reinstantiate this attribute? What do you need to do to re-instatiate the attribute? As another reply mentioned, you can use the Python property descriptor in combination with an `_v_` attribute. The ZODB will not serialize an attribute whose name starts with _v_ (v means "volatile"). Alternatively, you can override ``__getstate__()`` and ``__setstate()__`` http://www.python.org/doc/2.4/lib/pickle-inst.html Classes can further influence how their instances are pickled; if the class defines the method __getstate__(), it is called and the return state is pickled as the contents for the instance, instead of the contents of the instance's dictionary. If there is no __getstate__() method, the instance's __dict__ is pickled. Upon unpickling, if the class also defines the method __setstate__(), it is called with the unpickled state.13.5 If there is no __setstate__() method, the pickled state must be a dictionary and its items are assigned to the new instance's dictionary. If a class defines both __getstate__() and __setstate__(), the state object needn't be a dictionary and these methods can do what they want. So let's say that the name of this particular attribute is 'unserializable'. You'd remove it from the 'state' dictionary returned by 'getstate', and add it back in during 'setstate'. Warning: It's been a long time, I think, since I've used these methods. There may be better practices. :: class Example(Persistent): ... (other code) def __getstate__(self): state = super(Example, self).__getstate__() # you _might_ want to add '.copy()' to the above to play safe. if 'unserializable' in state: del state['unserializable'] # Alternatively, you might want to store a tuple or some way # of restoring the unserializable object if you can. Some # kind of small memento. # This is what gets pickled and stored in the ZODB. return state def __setstate__(self, state): # here is where you can re-instantiate 'unserializable' state['unserializable'] = unserializableReinstantiationCode() super(Example, self).__setstate__(state) -- Jeff Shell ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: Re: [Zope3-dev] Do not serialize one attribute
On 12/14/06, Jeff Shell <[EMAIL PROTECTED]> wrote:
On 12/14/06, Florian Lindner <[EMAIL PROTECTED]> wrote:
> Hello, I have a object, derived from Persistent when contain one
> attribute which is not serializable and that's not a problem for me,
> but Zope complains about that. Can I mark this attribute somehow as
> "not to serialize" and make Zope call a member function when it has
> unserialized this object so I can reinstantiate this attribute?
What do you need to do to re-instatiate the attribute? As another
reply mentioned, you can use the Python property descriptor in
combination with an `_v_` attribute. The ZODB will not serialize an
attribute whose name starts with _v_ (v means "volatile").
Is this the IJabberClient object you were asking about a couple of
weeks ago? I just saw that thread today. Anyways, the _v_ option is
probably what you want if that is the problem.
class JabberClient(Persistent):
... (other code) ...
@property
def client(self):
if not hasattr(self, '_v_client'):
self._v_client = xmpp.Client(...)
return self._v_client
You could try using this descriptor as well (something like this might
already exist. If not, perhaps it should? This is a simple
implementation, but it should work)
class volatile(object):
""" A descriptor that reads and writes to a volatile attribute """
def __init__(self, name):
self._volatilename = '_v_%s' % name
def __get__(self, klass, inst):
if inst is None:
# return this descriptor if accessed on the class
return self
return getattr(inst, self._volatilename, None)
def __set__(self, inst, value):
""" Set the value on the instance in a volatile attribute """
setattr(inst, self._volatilename, value)
def __del__(self, inst):
""" Clear the volatile attribute """
delattr(inst, self._volatilename)
And here's how it would be used.
class JabberClient(Persistent):
... (other code) ...
client = volatile('client')
--
Jeff Shell
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RE: [SpringCleaning07]
rkdown renderers in place as well. Many of our CMS customers are using this (although I hope to move them to HTML w/ TinyMCE or Kupu if I can ever get Kupu to actually do something useful). Our Knowledge Base application also uses zope.app.renderer. It's been invaluable to be able to move documents from Writeboard (Textile format) to our KBase for long term storage, as well as being able to post our own reStructuredText based documents. 'zope.app.renderer' is a bit confusing, but its disappearance could be critical. Again, I don't mind too much of it disappears from the core distribution, as long as it's made obvious (ie - not buried in a wiki page on some far flung remote site) and can be easily downloaded/installed. I'll note that the removal of several of the zope.app.* packages means a further distancing from TTW, offering the casual newscomer even less to look at. I am okay with this direction, but others might object strongly. This should really be brought up on zope3-users or other high-level mailing lists. I'm also for this. Besides, the casual newcomer can't really do much with the stock TTW objects anyways. For casual TTW style development with all of its features (and drawbacks), Zope 2 is a far better choice. Side Topic: When you install Pylons, you don't have anything to "look at". But making a quick and simple application with it was rather straightforward. On the other end of the spectrum is Django, whose admin screens are actually usable by other humans and very very easy to customize. How easy is it in Zope 3 to customize a folder contents view so that it shows different columns, allows sorting only on certain ones, and allows quick searching, grouping, and filtering? I know (or assume) that 'zc.table' can provide for this functionality, but it's nowhere near the core. As a developer, doing custom 'listing' or index pages is something I need to do all of the time. 'title', 'size', and 'modified' aren't interesting to me in a folder full of invoices. I would be interested to know if anyone has succesfully used the TTW ZPT Page and SQL Scripts or SQL Exprs to make a usable application. Those never seemed to be the focus of Zope 3, and with the lack of auto-acquisition and Python scripts, they felt extremely crippled compared to their Zope 2 cousins. I certainly could never get them to do anything useful, because I had no answers about what objects/namespaces/modules/etc I could even access. All of the things that were easy in Zope 2's TTW environment didn't seem doable in Zope 3's. But that's OK, as custom Python / product / etc development is much easier. I'd rather see the elevation and inclusion of tools like 'zc.table' and 'zc.resourcelibrary' which can be useful across so many application domains and could solve some very common problems. And if we want to give casual newcomers something to look at, lets focus on how Instance Homes and Products/Applications are used and can be built. Perhaps give templated starting points like paster does:: $ paster create --template=zope3product easytodo The Zope 3 experience does nothing to start the casual newcomer towards building a simple starter application. Both Pylons and TurboGears have a 'quick wiki' tutorial which includes a line similar to the one above. Unlike 'mkzopeinstance', the generated directories and files reflect a working product with some starter modules, classes, and templates: the equivalent of 'BoringProduct', in a sense, but with some skeleton parts (class names, etc) filled in instead of having to be manually replaced. -- Jeff Shell ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: [SpringCleaning07]
On 12/20/06, Martijn Faassen <[EMAIL PROTECTED]> wrote:
Rocky Burt wrote:
> On Wed, 2006-20-12 at 12:52 +0100, Martijn Faassen wrote:
>> http://genshi.edgewall.org
>>
>> Inspired by Kid (in turn among others inspired by ZPT), the main
>> template language of TurboGears, written by the people who also created
>> Trac, and it seems to be getting traction. TurboGears among others is
>> going to adopt it, but also things like the creator of SQLAlchemy (and
>> Myghthy) spending time optimizing it, etc. It's close enough to ZPT to
>> be palatable to me, and has some nice features for reuse.
I both like and dislike ZPT and other such languages these days.
They're great when working on some design-heavy sites. But in other
situations, it's an awful lot of useless typing and structuring.
It matters to me especially when we're talking about reuse. Template
languages differ significantly in their approach. I also prefer to pick
something that has a certain momentum and a certain performance.
If TAL / Page Templates isn't really made available to anyone else,
how could it get momentum? 'zope.tal', 'zope.tales' and
'zope.pagetemplate' could probably be combined into a nice
world-usable egg. With the right extras and entry points, they could
be used with Buffet and then available to TurboGears, Pylons, web.py,
whatever.
Performance is also a strange game, as template languages differ
significantly in how (or even if) they compile, and how/where they
store that compiled manifestation.
Pylons uses Buffet, or at least a customized version of Buffet,
alongside 'Beaker'. 'Beaker' is a WSGI middleware thing that uses
Myghty's containers (which I guess basically make up the heart of
Myghty's supposedly powerful caching system) to cache templates,
fragments, all in a template-language-neutral way apparently. It would
be nice to be able to use things like that with Zope. Keep TAL, allow
for use of Buffet or something like it (perhaps something using the
same entry point) so that any other supported template language could
be plugged in.
http://projects.dowski.com/projects/buffet
http://pylonshq.com/project/pylonshq/browser/Pylons/trunk/pylons/templating.py
As a side topic, I'm also slowly coming to the conclusion that tales
path expressions are a waste of time and effort. We spent a lot of time
making sure that we can express something as a path expression, and a
Python expression would be just as easy to read and explain. We're not
stopping people from writing more complicated python expressions anyway,
and there are real cases where they're needed. A very different
templating mechanism where there is no Python at all and data is always
pregenerated before rendering is still attractive for other reasons, but
in the ZPT case I've become less and less convinced it's worth the hassle.
The nice thing then about something like Genshi is that instead of:
python:foo.bar
I can simply write:
foo.bar
Python expressions in TAL are cumbersome in part because they're simply
hard to type, not because they're necessarily *complicated*.
It's not TAL's fault - path expressions are just configured to be the
default for the engine used by Page Templates.
It should certainly possible to set Python Expressions as the default
for your ZPT Page Templates. I did a simple-stupid string template
language that basically looked for the following pattern::
{{ expr }}
and ran the TALES expression inside. For that setup, I set Python
expressions to be the default. This was used for generating emails,
etc. Kindof a slightly fancy mail merge::
Dear {{customer.name or 'customer'}},
But I could use string, path, whatever as well.
Doesn't Genshi allow for {{ expr }} type things in its templates? Or
was that Kid? Anyways, I hate having to type a whole bunch of TAL to
generate a fake tag and all of that to do a simple insertion in cases
where I could really do without that overhead::
Featured?
'view/featuredFlag' renders lots of fancy HTML on its own, so I don't
need a span or div or anything right there.
--
Jeff Shell
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: future of fssync (was: RE: [SpringCleaning07])
This is a very delayed response, I'm sorry. I seldom get/make the time to check GMail these days. Eternally busy, for better or worse :). On 1/2/07, Stephan Richter <[EMAIL PROTECTED]> wrote: On Wednesday 20 December 2006 16:03, Jeff Shell wrote: > > > > zope.fssync > > It's too bad that this seems to have gone unfinished. The biggest pain > (well, one of the big pains) we experience with Zope 3 is the lack of > anything like Zope 2's export/import. Or, going further back, > 'manage_exportHack'. :). This is a side topic and I'm not going to > elaborate further except to beg for some low to medium level > export/import capability. It seems that fssync was one of the > alternatives, or could be, if I recall correctly. The question is why you need it. zope.fssync was originally developed for TTW development via the filesystem. I think this use case has gone away. What use cases do *you* have for using fssync? More than anything, we need export/import, ala Zope 2. If my memory serves, 'fssync' was often described as the Zope 3 replacement for it when I brought it up in the past. In Zope 2, export/import was often used by us as a release mechanism: export a folder/site from a development instance, import it into a production instance. Since we don't really do much in the way of "through the web" development in the Zope 3 era, this hasn't been a terribly critical feature. However, we do large CMS based web sites and sometimes have sub-sections or sites that we need to build up in house with lots of graphic design, customer sign-off, etc, that then needs to be integrated with the existing production servers. For these purposes, I don't really care what the exported / sync'd files look like. I'd just like to be able to move elements from one machine / instance to another without having to replace the entire Data.fs file. And again, if memory serves, it seemed like fssync was often pitched as the potential answer to this situation. But it was pretty clear to me back then that fssync's development had stalled. I didn't have the time to contribute (hell, I barely get time to check GMail any more), and haven't had the time to look into our own solution, so we just blunder-force our way through these particular deployment scenarios. Fortunately we've had only to deal with a few such cases. -- Jeff Shell ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] SOAP support?
On 1/7/07, Andreas Jung <[EMAIL PROTECTED]> wrote: Hi, I am actually looking at options for bringing SOAP support into Zope 2. Is there some SOAP infrastructure available in Zope 3 (or some add-ons) and might be re-used in a reasonable way? FWIW, I managed to bang out a brute force RPC style SOAP publisher, based on the XML-RPC one in Zope 3. I used ZSI to handle the parsing / writing, and expect my "views" / published methods to do the same - ie, I can't just return a dictionary or list and have it all get bundled up correctly. This is because SOAP, as far as I can understand it, suuucks. ZSI - http://pywebsvcs.sf.net/ I had to bang this implementation together because a customer has an old flash applet that retrieved some data from a ColdFusion Component exposed as a web service. They apparently don't have the Flash source any more, and we've been unable to get much help from their developers or anyone in regards to what this Flash tool expects. All we have is the cold fusion component source - and we don't even know what data is actually being returned! At most we can see the columns / keys. Ugh. I'm glad that Zope 3 has a built-in place to attach a SOAP request factory/handler/thing, but I definitely wouldn't expect or want any more than that. I had to pull some nasty hacks to get the generated SOAP response to be handled properly by the Flash client - what ZSI generated was probably close to some kind of spec, but just didn't behave in the same manner as these two Macromedia, er, Adobe tools. It feels like the best chances of any kind of interoperability come from servers and clients built by the same provider. What a mess. I've attached the publisher side of what I've managed to cobble together so far in case anyone is interested. I'm probably not going to take this thing any further as it basically provides just enough functionality to allow us to communicate with the Flash client. The Zope application side of my project used ZSI's `wsdl2py` and `wsdl2dispatch` to generate the skeleton code, typecodes, and rough ideas on how to write a response handler. "The S Stands for Simple" is definitely a great read. It's terrifying because it's true. (At the same time, I can see the appeal of SOAP in the heavyweight compiled commercial crap tools business - exposing a ColdFusion Component as a web service is as easy as adding ``?wsdl`` to the URL, and I was able to attach the web service to a table in Flash 8 Professional and witness data being returned, and I don't know or use Flash (or ColdFusion) at all. Ugh. Shame it's such a crap system. Viva AJAX with JSON! Viva View-Source! Viva good old fashioned GET and POST HTTP requests that don't have additional traversal steps buried in a body that one could never type by hand!) - 100 for adding this kind of support to the core. It's way too much of a mess, and the Python SOAP libraries all seem to be in pretty bad shape. -- Jeff Shell soappublisher-0.0.0.tgz Description: GNU Zip compressed data ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] zc.resourcelibrary resources positioning in
On 2/21/07, Shaar Gabriel <[EMAIL PROTECTED]> wrote:
a little thought about zc.resourcelibrary. shouldn't the added
resources (at least javascript) be closer to than to .
this way the specific javascript resources can make use of the more
general ones included in the skin with the template. does this make
sense ?
Like Gary, I don't put more general items in the main template. I
shout out my need from the head of the main template::
So I would want my items to be towards the top. Usually. The more
specific resources should be wired to require `brcms-rsrc` or one of
its dependents. This is how I've always expected resourcelibrary to
behave.
But I've been thinking about resourcelibrary. In fact, I logged in to
GMail to ask some questions about it. It's such a useful tool, in some
regards, but it falls short in others. I don't know how to fix it
properly without changing the paradigm (which I would like to do).
One of my complaints is similar to yours, but I want better control of
the positioning. I've thought of making a second pipeline in the
result that would look for very simple markers - just a kind of string
insertion template language (no conditionals, loops, etc). So that
instead of looking for a tag, it might look for
or something like that... maybe even
an XML processing instruction?
Short of an aggressively object-oriented system like Seaside, where
one is building a document page out of objects instead of just
rendering a template / raw string, I guess I really want some kind of
pipelining. I don't want the pipelining to bound to ZPT in any way.
But I imagine there might be some kind of lesson that could be
extracted from how resourcelibrary mucks with the implicit result; or
even with explicit results?
::
def _implicitResult(self, body):
#figure out the content type -- this is straight from resourcelibrary
content_type = self.getHeader('content-type')
if content_type is None:
if isHTML(body):
content_type = 'text/html'
# now we veer off in the land of hypotheticals
postprocessor = queryAdapter(self, IResultPostProcessor,
name=content_type)
if postprocessor:
# the resourcelibrary code that writes all the
Re: [Zope3-dev] zope.cachedescriptors outdated
On 2/22/07, Christian Zagrodnick <[EMAIL PROTECTED]> wrote: Hi the cachedescriptors package is quite aged as it seems. It hasn't been updated for decorator use. Actually there are only three descriptors: CachedProperty – Needs to be updated to be used as decorator. But I guess we need a deprecation period. Lazy – Works like charm as property decorator. readproperty –can go away i think. The property builtin is find. I'd add a 12 month deprecation warning. As long as `Lazy` doesn't go away, I don't mind. CachedProperty is a little overwhelming.. I guess I haven't had a need for it. I use Lazy a lot in views and other objects that exist only during the request/response cycle. It's super handy in those situations. I wouldn't mind seeing `Lazy` renamed or aliased as `lazyproperty` or `lazyreadproperty`. I use `readproperty`, but I have my own copy of it. I didn't realize it was in cachedescriptors. As I understand it, `readproperty` is different from the built-in basic `property` descriptor: you can write to a readproperty. You can't write to a basic `property` that is used only as a decorator around a getter method. >>> class Foo(object): ... @property ... def bar(self): ... return 42 ... >>> f = Foo() >>> f.bar 42 >>> f.bar = 33 Traceback (most recent call last): File "", line 1, in ? AttributeError: can't set attribute With `readproperty`, you can still have the simple getter-method-wrapper property, with the ability to replace the value on instances. So no, the builtin 'property' descriptor is not fine. `property` came into being when Python got descriptors, but before it got decorators. By grand design or divine accident, the fact that the first argument for `property` is the getter function makes it a useful decorator. But it wasn't written with decorators in mind. It was written for ``x = property(getX, setX, delX)``, or some combination thereof. -- Jeff Shell ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] LocationProxy+None
On 8/14/07, Adam Groszer <[EMAIL PROTECTED]> wrote: > A strange thing happened today: > >>> x = LocationProxy(None, "foo", "bar") > >>> x is None > False > >>> x == None > True > > Is this OK or I'm just missing something? You have to understand how Python's ``is`` differs from ``==``. An `is` check is an identity check, not an equality check. It's generally faster than comparing equality. It's basically like this:: a is b if id(a) == id(b) The Python `id` function is basically a memory address of that specific instance. None, True, and False are all basically constants that have the same identity unless that name is overridden in a local namespace. When proxies enter the picture, you're wrapping the object with a proxy, so it's no longer the same by identity. >>> from zope.location import LocationProxy >>> located_none = LocationProxy(None, "foo", "bar") >>> id(None) 3120456 >>> id(located_none) 404616 >>> id(None) == id(located_none) False >>> located_none is None False Since the proxy object is masquerading as its wrapped object, equality checks works. But identity doesn't. The `zope.proxy` package includes some functions that you can use for help. >>> from zope.proxy import removeAllProxies, sameProxiedObjects, isProxy >>> isProxy(None) False >>> isProxy(located_none) True You have the option of removing all proxies, which would return the object wrapped up by the proxy. Since we wrapped up None, it would return the actual None object and identity checks would pass: >>> removeAllProxies(located_none) is None True Or you can use `sameProxiedObjects`, which does the identity check on the internal objects of one or two proxies: >>> sameProxiedObjects(located_none, None) True You can see this when wrapping another instance of None with a location proxy. >>> singing_nun = LocationProxy(None, 'austria', 'jane') >>> id(singing_nun) 7378424 >>> singing_nun is located_none False >>> sameProxiedObjects(singing_nun, located_none) True -- Jeff Shell ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] KeywordIndex
I'm working on a simple application which is the first time I get to use the catalog in Zope 3. I'm writing against Zope 3.1b1. I was dismayed not to see KeywordIndex in the main catalog set, but then I found it in zope.index.keyword. But it seems to be a bit behind. I have it somewhat working through subclassing, etc, but it's been purely guess work on my part to get things this far. In my product package, I have the following: -- from zope.app.catalog.interfaces import IAttributeIndex, ICatalogIndex from zope.app.catalog.attribute import AttributeIndex from zope.app.container.contained import Contained from zope.index.keyword.index import KeywordIndex as KeywordIndexBase from zope.proxy import removeAllProxies from BTrees.IFBTree import IFTreeSet, IFSet, multiunion class IKeywordIndex(IAttributeIndex, ICatalogIndex): """ Interface-based catalog keyword index. """ class KeywordIndex(AttributeIndex, KeywordIndexBase, Contained): implements(IKeywordIndex) def index_doc(self, docid, value): # All security proxies need to be removed from the value. value = removeAllProxies(value) return super(KeywordIndex, self).index_doc(docid, value) def apply(self, query): # Keyword index doesn't implement apply(query) either. return self.search(removeAllProxies(query)) def _insert_forward(self, docid, words): """insert a sequence of words into the forward index """ # Replaces parent _insert_forward because apply() claims to want IFSets idx = self._fwd_index has_key = idx.has_key for word in words: if not has_key(word): idx[word] = IFSet() idx[word].insert(docid) -- I first overrode index_doc because the base KeywordIndex does an isinstance(value, (ListType, TupleType)), which failed on a security proxy guarded value. Then I added 'apply()' when I noticed that the base KeywordIndex didn't implement apply. Looking at the other supported indexes and at the index interfaces in zope.index, I noticed that IFSets were what was desired as the output of apply(), and that's when I replaced _insert_forward with a near identical copy that uses IFSet. This works... so long as I only search for one keyword. If I search for more than one through the catalog interface (and I imagine I would get the same result manually), I get the following traceback: -- File "/Users/jshell/Documents/Programming/kbase/lib/python/br/kbase/browser/search.py", line 22, in search results = catalog.searchResults(tags=query) File "/Library/ZopeX3/3.1/lib/python/zope/app/catalog/catalog.py", line 105, in searchResults results = self.apply(searchterms) File "/Library/ZopeX3/3.1/lib/python/zope/app/catalog/catalog.py", line 84, in apply r = index.apply(index_query) File "/Users/jshell/Documents/Programming/kbase/lib/python/br/kbase/catalog.py", line 36, in apply return self.search(removeAllProxies(query)) File "/Library/ZopeX3/3.1/lib/python/zope/index/keyword/index.py", line 139, in search rs = f(rs, docids) TypeError: invalid argument -- 'f' is IISet.intersection() The implementation of search() in the base KeywordIndex uses IISets for default values. I don't know if this is conflicting with the IFSets I set up in my subclass. I tried quickly editing zope.index.keyword.index to use IFSets instead, but I got the same traceback and then quickly reverted back to leaving the code untouched. It's been *years* since I've even touched simple indexing code, so I don't really know what's going on here or what's required. I would really like to have Keyword Index. In fact, such an index is the core of my application. I can throw together my own, I'm sure, that's a bit more brute force for my own purposes if necessary. I don't claim to have a solid understanding of how indexes and the catalog work (although it's been much easier to figure out in Zope 3, thanks!) Is there any reason why KeywordIndex seems half-abandoned? I guess it's not exposed to zope.app because of this. What would it take to make it catch up to FieldIndex? Thanks -- Jeff Shell ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] KeywordIndex
Hi Gary! I'd be very interested in this. It's not critical for me right now, so there's no need to rush making something available. I have an inefficient but fun solution for my system that can be replaced when this comes along. I primarily wanted to know the state of the indexes. Is what's there right now going to be what ships with Zope 3.1 final? On 7/18/05, Gary Poster <[EMAIL PROTECTED]> wrote: > > On Jul 18, 2005, at 11:14 AM, Jeff Shell wrote: > > > I'm working on a simple application which is the first time I get to > > use the catalog in Zope 3. I'm writing against Zope 3.1b1. I was > > dismayed not to see KeywordIndex in the main catalog set, but then I > > found it in zope.index.keyword. But it seems to be a bit behind. > > Hi. Yes, we needed it too. Here's another thing we want to open > source. Look at the attached .txt file; if you want it then tell me > and I'll make it available in a sandbox. We'll move it over into the > Zope repo (probably with a new name, or rearranged on the appropriate > locations (zope.index and zope.app.catalog, etc.) RSN. > > Downsides: > > - Note that some functionality requires that you use an extent > catalog, another goodie in the package. > > - We have some refactoring of this that we want to do. We'll have > legacy issues ourselves, then. > > Additional upside: > > - This package also includes a replacement for the field index > (called a value index) and customizations of the value and set > indexes specific to timezone-aware datetimes, as well as a few other > things. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Z-I with GCC 4
Zope 3.0 doesn't seem to work with GCC 4, as I (and others) have had the same problem. On my system (Mac OS X 10.4), GCC 3.3 is also available, and I was able to use 'gcc_select' to switch to 3.3 to build Zope 3.0. If you have, or can get, both gcc's on your system, this appears to be the best route. Zope 3.1b1 builds fine with GCC 4. On 7/18/05, Chris Spencer <[EMAIL PROTECTED]> wrote: > I tried installing Zope Interface on FC4 using GCC 4, and I received the > following error: > > running install > running build > running build_py > running build_ext > building 'zope.interface._zope_interface_coptimizations' extension > gcc -pthread -fno-strict-aliasing -DNDEBUG -O2 -g -pipe > -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -m32 -march=i386 -mtune=pentium4 > -fasynchronous-unwind-tables -D_GNU_SOURCE -fPIC -fPIC > -IDependencies/zope.interface-ZopeInterface-3.0.0/zope.interface > -I/usr/include/python2.4 -c > Dependencies/zope.interface-ZopeInterface-3.0.0/zope.interface/_zope_interface_coptimizations.c > > -o > build/temp.linux-i686-2.4/Dependencies/zope.interface-ZopeInterface-3.0.0/zope.interface/_zope_interface_coptimizations.o > Dependencies/zope.interface-ZopeInterface-3.0.0/zope.interface/_zope_interface_coptimizations.c:339: > > error: static declaration of 'SpecType' follows non-static declaration > Dependencies/zope.interface-ZopeInterface-3.0.0/zope.interface/_zope_interface_coptimizations.c:73: > > error: previous declaration of 'SpecType' was here > error: command 'gcc' failed with exit status 1 > > Does Zope not yet work with GCC 4? Is there anything I can do to work > around this? > > Thanks, > Chris Spencer > > ___ > Zope3-dev mailing list > Zope3-dev@zope.org > Unsub: http://mail.zope.org/mailman/options/zope3-dev/eucci.group%40gmail.com > > ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Why I posted about Zope3.org (the outsider's thoughts that got me thinking)
it. If there were to be a model for a Zope 3 web site, that would be it. The development wiki should still be inside of it, of course. But weblog entries like mine, like Martijn's, like Benji's, should all go into it as well (not as a "planet zope" type stream, but more dedicated so it's known that relevant information shows up). I think that Zope 3 has its own momentum away from Zope 2. Five is what is going to be appealing to Zope 2 developers learning about Zope 3. There should be something that appeals to the general Python crowd that I still believe to be the main target for Zope 3 as it stands right now - a shorter path between your Python objects and publishing them on the web. Or a shorter path between writing some plain old Python code and seeing a result. I need to read more of the other thread about this. I just know that there's some debate of whether Zope 3 should be a part of the Zope.org site. I'm for having it be separate. There are a lot of Python developers out there who have bad memories of Zope 2 but just may be the kind of developers who'd like or love Zope 3 if they could really see and understand what makes Zope 3 so great. -- Jeff Shell http://griddlenoise.blogspot.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] Why I posted about Zope3.org (the outsider's thoughts that got me thinking)
On 10/11/05, Stephan Richter <[EMAIL PROTECTED]> wrote: > On Tuesday 11 October 2005 13:24, Jeff Shell wrote: > > I'd really like to give Zope 3 a try, and I keep trying to. The docs > > are just nauseating. They might look good or fine to someone who's > > used Zope for years, but to someone new they're horrid. As I > > mentioned, the site is laid out horribly for someone who wants to > > learn Zope 3. Why is the left bar saturated with links when I just > > want Zope 3? > > > > It's incredibly frustrating and disappointing to hear about all the > > cool stuff you can do in Zope 3, and not see anywhere that shows it > > actually being done with descriptions on how it works, etc. Where are > > the examples? Where are the recipies to "do cool thing X"? > > > > The developers I see talk about Zope are all in companies that use > > it, that have teams that use it, that have tons of actual knowledge > > that doesn't exist on the website. I really really want to give Zope > > 3 a spin, I have a few fairly complex projects I'd like to try out > > with it. How do I get started? > > I would say, buy the books. It is too hard to keep documentation up to date, > if you do not get paid. The alternative are doctests of course, which we have > available as mentioned in my previous mail. Again, I think it is a lack of > manpower, my own included. I would love to update the Web site to the version > of my book that has actually been printed, but I just do not have time. All > it needs is someone to merge the stupid DOC files to the TeX master documents > and it would be online. Note that I already put them in a zope.org-based > repo, so anyone can work on that task. That was my response to him. But for people evaluating Zope 3, or just starting out and not knowing whether it's a worthwhile technology to continue with, buying a book is probably a non-starter. Some good "quick starts" and recipes would help there. I don't think that the type of documentation that is in a book should be on the web site and maintained constantly. It's too big and too hard, a fact I'm sure you're aware of. The API Doc tool, the books, are all useful things to have once you've really committed to a project. But getting people that far is where zope3.org or maybe zope3rocks.com or something - anything! - would be useful. Instead of trying to update reams of documentation with new features in Zope 3.2, one could post a document like "Zope 3.2 - Introducing zope.formlib" or "Zope 3.2 - deprecated functions" Because, for example, I see the warning about using 'getView - use getMultiAdapter instead', but there's no explanation of how a getView(...) call should be translated into a getMultiAdapter call.. One can figure it out, but it's a couple of lines that could be in a document that many of us here can write.. I just don't want it lost in the desert sands of the wiki. I can find proposals about simplifying the component architecture, but there's no final document about what that simplification really produced and how it affects me. The deprecation machinery is great at telling me about these things (again - I think it's a great feature), but oh man - I think any major architecture like Zope 3 that gets *simpler* in a new version is something to sing about. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Why I posted about Zope3.org (the outsider's thoughts that got me thinking)
On 10/11/05, Stephan Richter <[EMAIL PROTECTED]> wrote: > On Tuesday 11 October 2005 13:24, Jeff Shell wrote: > > Personally, I really like the Z3ECM project site - z3lab.org. It has a > > combination of blogs, papers, demos (animations) and documentation. > > That's still a project in its infancy, but it's a good looking site > > with a variety of sources feeding into it. If there were to be a model > > for a Zope 3 web site, that would be it. > > I have followed the mailing list the last months and the site a little bit, > and I still do not know what the project is really working on at the moment. > I know that Roger helped developing a high-level workflow engine atop WfMC > and Jean-MARC works on CPS skins (why CPS skins, if there is no CPS for Zope > 3), but that's pretty much it. Specifics about the Z3ECM project aside, it's just a nice site in my opinion. The front page layout - 'Latest News' and 'Spotlight Information' on top, the list of documentation updates, blog posts, documents and white papers on the side, the explanatory text further down - it's great. It's not super flashy, but it gets information across and has the feel of "freshest information on top" and avoids the feel of "lots and lots of new and old information all over the place" that Zope.org has (which stems from Zope.org's noble efforts as a community site which has built up a lot of data over the years, which is why I think a good Zope 3 marketing / information site should be more 'invite-only' in regards to publishing information, at least initially). ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] fssync and export/import for Zope 3
YES YES YES YES YES YES YES YES YES YES YES YES YES YES YES OH GOD YES! I mean. Yes! Backup/restore, and deploy. We're deploying a customers site in chunks - one section, then another, then a third. It's content that's being migrated off of Zope 2. The other developer here was complaining about having to do the third chunk on the live server. All of these chunks are well sectioned off, and import/export would be wonderful. fssync isn't in the release (we try to only use release code around here - easier to manage), and we didn't know what it meant that the code looks like it hasn't been touched in over a year - is it simple and stable enough to work with production Zope 3.1, or has it fallen behind? We didn't know this, but were thinking that now that things have settled down (somewhat), it might be nice to investigate. So - yes! This exactly mirrors a conversation we had just a couple of minutes ago. On 10/7/05, Garrett Smith <[EMAIL PROTECTED]> wrote: > Is anyone interested in using export/import capabilities in Zope 3? > > As we get more Zope 3 deployments, I think this will become an important > topic. It looks like the fssync code has become only slightly stale. With a > little use, this could be break-out feature for Zope 3 developers. > > As Jim just pointed out, there are a couple a 'visions' associated with > fssync: > > - The export/import functionality people are used to with Zope 2 > > - A checkin/checkout functionality that would let someone make long-running > changes to a part of a site, with the option of commiting or aborting those > changes > > I suspect the export/import feature alone will be attractive to anyone with > production servers, as it enables object-specific backup and restore. > > If anyone is interested in using this, let me know. I'll be looking into > adding a simple command-line tool for object-specific backup/restore (i.e. > export/import) and it would be helpful to have some other users, if not > contributors. > > -- Garrett > ___ > Zope3-dev mailing list > Zope3-dev@zope.org > Unsub: http://mail.zope.org/mailman/options/zope3-dev/eucci.group%40gmail.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: zope3 website report?
Why is WYSIWYG so important? Who's going to be editing all of that? I don't want another zopewiki.org. I think that zopewiki.org is a good site and that there should be an area of the site that's like that which may be open to the world - but I'd like serious / fun / USABLE documentation to be separate from that. You all know my feelings about Wikis. I walk away from so many technical wikis frustrated. I finally find a page I'm looking for, and it's contents are either: --- MultiAdapter A multi adapter adapts multiple objects --- Or --- HowToMakeAPie I found this link to a tip on this other site and it seems cool. http://www.example.com/how/to/make/a/pie --- As an outsider trying to get started, it doesn't take long for me to get frustrated and walk away. When I may be more settled in and curious about more, full community recipe sites or wikis may be a trove of terrific information. But don't waste my time making me click on page after page. Look at how accessible the quick start, the about, the docs, and more are accessible on TurboGears: http://turbogears.org/ Ruby On Rails has a wiki, but it's a few steps back from the front page, which again makes information well available: http://www.rubyonrails.com/ Django's got an informative web site: http://www.djangoproject.com/ Most of the information one would want on these sites are available within a few clicks, without their front pages feeling cramped and overloaded. Tutorials, quick starts, downloading, getting involved - all close. There are two nice quick start documents written in ReST already. Why don't we make it easy for those authors to put those in a common place first instead of debating over WYSIWYG editing? Let the smart people put the first content together. Make it easy for new people to find information over making it easy for new people to add noise. Are you trying to attract outsiders so that they'll get excited and grow the platform's base, or are you trying to keep Zope 3 within this small community and make it easy for those within this small community to tell each other what most of us already know? It sounds like the priority has been on the latter - make it a site to drive development of the Zope 3 platform itself. I think development is going fine with the tools already in place. Lets drive adoption by making our message heard! And again - that's not to say that the development wiki or a community wiki is excluded from that. But as I showed with the comments of just one smart outsider - getting information about Zope 3 is a frustrating process. On 10/12/05, Martijn Faassen <[EMAIL PROTECTED]> wrote: > Stephan Richter wrote: > > On Tuesday 11 October 2005 12:41, Philipp von Weitershausen wrote: > > > >>If anyone here really needs WYSIWYG, please make a point, but I doubt that > >>there will be one... > > > > > > It's a top priority for Jim. Uwe and I agreed we would prefer ReST. > > I got the impression from Jim that this was just an idea that he wanted > to try out. Ideas you're eager to try are different than top priorities, > right? > > Unfortunately having a wiki page in HTML and in ReST is rather > incompatible; while you can translate ReST to HTML, HTML to ReST would > at best be unreliable and confusing. This means HTML pages can only be > edited as HTML ever. > > Then again, I'm interested in seeing how the idea would work. Whether > that should be driving a Zope 3 site as a whole is another question. > > Regards, > > Martijn > ___ > Zope3-dev mailing list > Zope3-dev@zope.org > Unsub: http://mail.zope.org/mailman/options/zope3-dev/eucci.group%40gmail.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] hurry.query in Zope 3.2?
I love hurry.query. Whether it's in the core or not doesn't phase me, but it is really really helpful. We got bit by not realizing that FieldIndex queries passed directly to the catalog/index had a low and high range. It was a small bite. But it took us a while to figure out why searching for 'summer' pages included 'winter' ones, but searching for 'winter' pages only returned winter. So we put in hurry.query. And were able to do it without depending on zc.catalog. It made the catalog experience a lot nicer. I'd put my vote behind inclusion. While the catalog is certainly cleaner and easier to understand than the Zope 2 catalog, querying it is still kindof a pain, which is mentioned in zope.index.interfaces.IIndexSearch TODO This is somewhat problemetic. It means that application code that calls apply has to be aware of the expected query type. This isn't too much of a problem now, as we have no more general query language nor do we have any sort of automatic query-form generation. It would be nice to have a system later for having query-form generation or, perhaps, sme sort of query language. At that point, we'll need some sort of way to determine query types, presumably through introspection of the index objects. hurry.query seems to fill in this hole. On 10/24/05, Martijn Faassen <[EMAIL PROTECTED]> wrote: > Hi there, > > Would there be any interest in merging hurry.query into Zope 3.2? > > What it does: > > hurry.query - higher level query system built on top of the Zope 3 >catalog. Some inspiration came from Dieter Maurer's >AdvancedQuery. See src/hurry/query/query.txt for >documentation. > > Here's the code: > > http://codespeak.net/svn/z3/hurry/trunk/src/hurry/query/ > > And here's a doctest: > > http://codespeak.net/svn/z3/hurry/trunk/src/hurry/query/query.txt > > Of course, it probably needs a review and adaptations before it's > accepted, and time until the feature freeze in november is short. It > would be a very useful addition to Zope 3's featureset, however. It > exposes features of various indexes that the normal catalog API does not > expose, or if so, only very obscurely. :) Now that I think of it, > exposing the ZCTextIndex properly with the various features involved may > need the most work. > > If there's interest, I'd really appreciate volunteers for putting up a > proposal on the wiki and integrating it into the codebase. This way it'd > get a review by that person. If it'd be up to myself I likely won't have > time... > > By the way, is zc.catalog up for merging with Zope 3.2, or won't this > happen yet? hurry.query has a dependency on zc.catalog, though I believe > I succeeded in keeping this optional. > > Regards, > > Martijn > ___ > Zope3-dev mailing list > Zope3-dev@zope.org > Unsub: http://mail.zope.org/mailman/options/zope3-dev/eucci.group%40gmail.com > > ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Generations - a missed use case? (Evolving an application for the first time)
I have an application where I'm trying to use 'zope.app.generations'
for the first time. And after much pulling of hair and looking at the
core code, I found what may be a missed scenario.
Basically, we deployed this application for a customer and now they
want some changes. It changes the schema of one item to store values
in tuples instead of strings. I wrote an evolve module, 'evolve1.py'
in myapp.generations, made the schema manager, registered it as a
utility, bla bla bla. But my code seemed like it would never run.
I'd run the debuzope script and look at the database
root['zope.app.generations'], and there was 'myapp' with the value of
1. I'd keep deleting that key and committing the transaction, but my
code would still never run. I tried running it manually using
pdb.run() to step through it and make sure that it was finding the
right objects and doing its job. My code was fine. So I looked at the
code in zope.app.generations.generations and found this interesting
tidbit:
for key, manager in findManagers():
generation = generations.get(key)
if generation == manager.generation:
continue
if generation is None:
# This is a new database, so no old data
if IInstallableSchemaManager.providedBy(manager):
try:
manager.install(context)
except:
transaction.abort()
logging.getLogger('zope.app.generations').exception(
"Failed to install %s",
key)
raise
generations[key] = manager.generation
transaction.commit()
continue
(the code continues from there
There's one problem here - in my situation, it's NOT A NEW DATABASE.
There is old data that needs to be evolved, but there's no record of a
generation for this application because there was no need for a schema
manager until now.
I really like the concept and general implementation of the schema
manager, but this scenario is driving me crazy. I could write an
'install' script, but that doesn't really cover this situation. After
install is run, the database marks the application generation. This
makes sense for new applications installing themselves - there's no
old data to update, so if the application is at generation 5, for
example, it doesn't need to be evolved to '5' if all of the data
that's installed or used is already in generation 5 form. (ie - if I
were deploying my application fresh today, my fields would already be
tuples instead of strings).
But my situation, where I already have a deployed application, is not
covered by this. I *could* write an 'install' script for the schema
manager that did this first evolution that I need to do. But then that
installer would have to be updated with all of the future evolutions
as well - since in theory, I could update an application from before
the schema manager and need to bring it up to generation 5 or 8 from
essentially 0.
It seems like the Schema Manager needs an 'evolve from 0' option, with
'0' being set by the evolution script of no previous evolution was
found but (somehow) existing data could be detected. The other
solutions seem to be:
* Write an install script that then manually calls all of the evolvers
to bring things up to the current generation.
* Always put a schema manager in your application, with the starting
generation of 0, so that you can upgrade in the future.
Neither option seems quite tenable - like a bad hack that goes against
the Zope 3 concepts. You shouldn't need a schema manager utility until
you need it, and having a script that manually does
'evolve1.evolve(context); evolve2.evolve(context)'... seems like it
goes against the sort of problem that the generations system is trying
to solve.
Is there something about the schema manager/generations system that I missed?
___
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.2.0 Beta 1 released
No 'formlib' for the core distribution, or was that just omitted from the feature list? I plan to start testing this soon. We had some problems with Python 2.4.1 + Zope 3.1 on one of our deployment boxes (the app/ZODB was developed against Python 2.3.x). I'm hoping it was just the [EMAIL PROTECTED]&#$ BSD stack issue (I think the python 'make test' series passed, even on the regex tests that tend to expose the BSD default stack size issue, but we didn't investigate further since Python 2.3.5 was running fine), On 12/6/05, Jim Fulton <[EMAIL PROTECTED]> wrote: > The Zope 3 development team is proud to announce Zope 3.2.0 beta 1. > > Zope 3 is the next major Zope release and has been written from scratch based > on the latest software design patterns and the experiences of Zope 2. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Ajax in Zope 3
Bottlerocket has also chosen MochiKit. It's not full of flashy effects, but its Ajax support is nice, it's well tested, and it brings a lot of Python style functionality to JavaScript which makes JavaScript suck a whole lot less (for real - the DOM and Iterator libraries are absolutely great). In the Bottlerocket CMS, Mochikit has been used to give us sortable tables (used in contents view - click a column header to sort by name, order, title, and so on), Ajax based inline renaming and title editing in the contents view, a 'dynamic table' widget which allows adding and removing rows from tabular data for web pages, and more. I generally loathe JavaScript, but working with MochiKit has actually made it a lot of fun. > FWIW, as far as Ajax libraries, ZC has chosen mochikit so far. It > has a lot going for it. > > Gary___ ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] View lookup changes in Zope 3.2?
Today I finally got around to installing Zope 3.2b1 and started testing one of our sites against it. I'm running into a few problems, some of which are my fault, some that I don't quite understand, and one that is really bad. We have been basically rolling a custom CMS in Zope 3, and the content management skin that we made has been working wonderfully in Zope 3.1. One of the key parts of our CMS's user interface is a custom contents view that uses MochiKit for javascript/DOM based table sorting (easy sorting on item name, title, and size), and uses MochiKit's AJAX support for inline renaming/retitling of items in the container. That's registered as 'contents.html' for our own base contentcontainer interface. We've also made a custom metadata view that allows editing of keywords (subjects). In Zope 3.1.0 both of those worked fine. In Zope 3.2b1, I'm getting the Rotterdam or default contents view, wrapped up in our template. The same goes for the custom '@@+' view I've made for the same objects, which is used to filter certain Zope entries out of the add menu. For our container objects, I'm also getting the Zope meta-data view, but on some of our custom content objects I get our replacement view. I use our own menu, 'cms_views', for tabs, and have contents and EditMetaData registered as actions. If I rename my 'contents.html' view to 'contentsplus.html', I can see it fine. Here's my skin setup: from zope.publisher.interfaces.browser import IBrowserRequest from zope.publisher.interfaces.browser import IDefaultBrowserLayer from zope.app.rotterdam import rotterdam class CMS(IBrowserRequest): """The `cms` layer.""" class ContentManagement(CMS, rotterdam, IDefaultBrowserLayer): """ The Skin """ configure: and the contents.html view starts with: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: XUL, DHTML
There's nothing (as far as I'm aware) stopping you from using XUL for your own Zope 3 apps - even replacing some or all of the basic ZMI with it and then offering it as a management skin for Zope. But for what it's worth - we've been working on a CMS in Zope 3 with a custom skin for managing content. It's a pure CSS / DHTML layout. Works great in Firefox and Safari both, but not in IE. It's hard to convince customers not to use IE. Just like you're not going to convince me to use Firefox daily on my Mac (sorry - Safari actually acts like a Mac application, and Firefox doesn't. I don't mind using Firefox, but it just not where I spend the bulk of my time). Right now we (my company) can kindof get away with saying to customers "Use Firefox, not IE". I'm not a fan of that answer though - our customers shouldn't have to care, really, and I don't like telling them they HAVE to use Firefox. Hell - I hated having to install the 'StaticTree' skin every time I played with Zope 3 during its development phase since Safari didn't support the dynamic tree widget in the Rotterdam skin until recent versions of Safari/Webkit. Personally, I think these web UI things still tend to be very trendy - Java Applets, Flash, XUL, DHTML/AJAX. It's always changing. SVG and XForms still haven't really shown themselves as real contenders to break us from what's already in place. So it's best that the core support as broad of a range as possible and then through add-ons or configurable layers provide support for flashier things. Those flashy things will be done differently in a year or two anyways. DHTML has gotten quite effective these days thanks to the prevalence (finally) of some well written Javascript libraries and a stable/mature enough web browser population that supports the technology. I think there was a proposal for smart widgets that could require Javascript but have the supporting Javascript library loaded only once..? What's become of that? On 12/6/05, Fabrice Monaco <[EMAIL PROTECTED]> wrote: > For the backend (manage) this isn't problem. i have just one suggestion > FireFox+xul+Zope is good ? > > -Original Message- > From: Chris Withers [mailto:[EMAIL PROTECTED] > Sent: mardi 6 décembre 2005 16:07 > To: [EMAIL PROTECTED] > Cc: zope3-dev@zope.org; Fabrice Monaco > Subject: Re: [Zope3-dev] RE: Zope3-dev Digest, Vol 29, Issue 9 > > > Stephan Richter wrote: > > On Tuesday 06 December 2005 09:44, Fabrice Monaco wrote: > > > >>Why not XUL? > > > > Because it sucks and is browser-specific. > > Be careful, or you'll have Paul in tears ;-) > > Chris > > -- > Simplistix - Content Management, Zope & Python Consulting > - http://www.simplistix.co.uk > > ___ > Zope3-dev mailing list > Zope3-dev@zope.org > Unsub: http://mail.zope.org/mailman/options/zope3-dev/eucci.group%40gmail.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: View lookup changes in Zope 3.2?
Is it related to this? "Bug in Multi Adapter Lookup"?
http://www.zope.org/Collectors/Zope3-dev/396
('fixed' in Zope 3.2b1)
That's my suspicion. This is a major blocking / "freaking out" kind of
issue. I'm trying to figure out now how to crawl through the debugger
and test the 'getMultiAdapter' lookup for this skin + object to
compare the results and hopefully.. I don't know. I have a pretty
complex view declaration that's meant to replace 'contents.html' for a
lot of our containers, and I'm hoping that I don't have to re-declare
the view for each container type. I guess I should also learn more
about how everything collaborates to establish an objects interfaces
and in what order so I can ensure that the base Zope interfaces are
lower on the providedBy list?
On 12/12/05, Jeff Shell <[EMAIL PROTECTED]> wrote:
> Today I finally got around to installing Zope 3.2b1 and started
> testing one of our sites against it. I'm running into a few problems,
> some of which are my fault, some that I don't quite understand, and
> one that is really bad.
>
> We have been basically rolling a custom CMS in Zope 3, and the content
> management skin that we made has been working wonderfully in Zope 3.1.
>
> One of the key parts of our CMS's user interface is a custom contents
> view that uses MochiKit for javascript/DOM based table sorting (easy
> sorting on item name, title, and size), and uses MochiKit's AJAX
> support for inline renaming/retitling of items in the container.
> That's registered as 'contents.html' for our own base contentcontainer
> interface. We've also made a custom metadata view that allows editing
> of keywords (subjects).
>
> In Zope 3.1.0 both of those worked fine.
>
> In Zope 3.2b1, I'm getting the Rotterdam or default contents view,
> wrapped up in our template. The same goes for the custom '@@+' view
> I've made for the same objects, which is used to filter certain Zope
> entries out of the add menu. For our container objects, I'm also
> getting the Zope meta-data view, but on some of our custom content
> objects I get our replacement view.
>
> I use our own menu, 'cms_views', for tabs, and have contents and
> EditMetaData registered as actions.
>
> If I rename my 'contents.html' view to 'contentsplus.html', I can see it fine.
>
> Here's my skin setup:
>
> from zope.publisher.interfaces.browser import IBrowserRequest
> from zope.publisher.interfaces.browser import IDefaultBrowserLayer
> from zope.app.rotterdam import rotterdam
>
> class CMS(IBrowserRequest):
> """The `cms` layer."""
>
> class ContentManagement(CMS, rotterdam, IDefaultBrowserLayer):
> """ The Skin """
>
> configure:
> interface="example.cms.skin.CMS"/>
> interface="example.cms.skin.ContentManagement"/>
>
> and the contents.html view starts with:
> permission="example.cms.ManageContent"
> layer="example.cms.skin.CMS"
>
> I'm referring to the layer with its interface path in ZCML, always.
>
> If I moved 'rotterdam' out of the base interfaces for the
> ContentManagement skin and set it as the base for the CMS layer
> object, the same behavior still shows up.
>
> This setup works as I expected it to in Zope 3.1, but breaks in Zope 3.2.
>
> FWIW, I opened up a debugzope session in both Zope 3.1 and 3.2 in this
> same configuration just to check the list of providedBy(obj) for the
> same folder in each site, to see if the interface resolution order
> might have changed, but the lists appear to be identical.
>
> Bug? Or did I do something wrong in my Zope 3.1 implementation that
> Zope 3.2b1 has "fixed"?
>
___
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: View lookup changes in Zope 3.2?
On 12/13/05, Jim Fulton <[EMAIL PROTECTED]> wrote:
> Jeff Shell wrote:
> > Is it related to this? "Bug in Multi Adapter Lookup"?
> > http://www.zope.org/Collectors/Zope3-dev/396
> > ('fixed' in Zope 3.2b1)
> >
> > That's my suspicion.
>
> That would be my suspicion too. It should be easy to test.
> Just get a check out and merge out that change:
>
>svn merge -r40385:40384 svn+ssh://svn.zope.org/repos/main/Zope3/trunk
>
> and see if you still have the problem. If you don't, then you still have some
> digging to do. If you do, then well, lets get into that if you
> verify that that is the problem.
>
> This was an honest-to-gosh bug. It is also the case that there were
> registrations in Zope that depended on this bug and had to be changed.
Going through a lot of debugging, it looks as through it has to do
with how things are ranked in
zope.interface.adapter.AdapterLookup.lookup() for multi-adapters. I
haven't stepped through it in the debugger in Zope 3.1 yet, but I just
got finished doing it in Zope 3.2 and these are my results:
>>> from zope.app.component.hooks import setSite
>>> from zope.publisher.browser import TestRequest
>>> from zope.app import zapi
>>> from zope.publisher.interfaces.browser import ISkin, IDefaultSkin
>>> conman = zapi.getUtility(ISkin, name='br.cms.skin.ContentManagement')
>>> customer = debugger.root()['customer']
>>> setSite(customer)
>>> winter = customer['winter']
>>> contents = zapi.queryMultiAdapter((winter,
TestRequest(skin=conman)), name='contents.html')
>>> contents.__class__.__bases__
(, )
So then I do a pdb.run("zapi.queryMultiAdapter((winter,
TestRequest(skin=conman)), name='contents.html')") and it's inside
AdapterLookup that I get the following. When all of the adapters for
this container and the request with the name 'contents.html' are
looked up:
(Pdb) pp byname.get(name)
[((,
),
),
((,
),
),
((,
),
)]
The one the I want is the second set in this list, 'br.cms.skin.CMS'.
Unfortunately, that's the one that loses out in the ranking algorithm
that ranks based on interface's ranking in the spec resolution order.
(NOTE: The IContentContainer there is different than the Zope
IContentContainer! This has cause some confusion in house)
The first one (IFolder, IDefaultBrowserLayer) produces the rank: (4, 4)
The second one, which I want, (IContentContainer, CMS) produces the rank (12, 2)
The third one, which I'm suspecting is generated from a zcml
containerViews directive, wins with the rank (3, 4).
It wins because the 'best' tuple is kept around. A rank wins 'best' by
being less than the current 'best', and (3, 4) is less than all of
them.
I understand why this is happening, but it's (obviously) not what I
want to have happen. I want MY skin layer's declaration of
'contents.html' to win out. It actually works for all container types,
so maybe I need to declare it for a root Zope container interface for
my layer?
I've been living under the impression that the layer a view was
assigned to had higher precedence than may have been intended, and
maybe this is part of the discussion going on in the
'SimplifySkinning' proposal/thread which I should take a closer look
at.
___
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: View lookup changes in Zope 3.2?
On 12/13/05, Jim Fulton <[EMAIL PROTECTED]> wrote:
> Jeff Shell wrote:
> > On 12/13/05, Jim Fulton <[EMAIL PROTECTED]> wrote:
> >
> >>Jeff Shell wrote:
> >>
> >>>Is it related to this? "Bug in Multi Adapter Lookup"?
> >>>http://www.zope.org/Collectors/Zope3-dev/396
> >>>('fixed' in Zope 3.2b1)
> >>>
> >>>That's my suspicion.
> >>
> >>That would be my suspicion too. It should be easy to test.
> >>Just get a check out and merge out that change:
> >>
> >> svn merge -r40385:40384 svn+ssh://svn.zope.org/repos/main/Zope3/trunk
> > Going through a lot of debugging,
>
> Did you do the experiment I suggested? (above)
Yes. Against that merge, against a Zope 3.2b1 release, applying those
specific revisions to the 3.2b1 release, even going back to the
revisions listed in Collector Issue 396, the same result happens.
It's one that makes sense to me, in its way. As stated in the
debugging output message, I just expected the layer to somehow have a
higher precedence than it does. At the multi-adapter lookup level, I
think I can understand why the new code does what it does. I may just
need to re-evaluate how my interfaces are declared, or what my
subclassing is causing to happen, or how my views are declared.
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Interface implementation declaration weight (was Re: View lookup changes in Zope 3.2?)
On 12/13/05, Jim Fulton <[EMAIL PROTECTED]> wrote: > Jeff Shell wrote: > ... > > Going through a lot of debugging, it looks as through it has to do > > with how things are ranked in > > zope.interface.adapter.AdapterLookup.lookup() for multi-adapters. > > Yup. > > I don't know enough about the relationshipd between your content > interfaces, to comment directly, but I will note that the intent > was that content interface would have precedence over skin. This > was not the case before due to a bug in multi-adapter lookup. I'm sure that's the issue here. The software worked "fine" in 3.1, or basically worked in a way that I assumed was fine. The situations where this is affecting us is in some of our oldest major Zope 3 code, and it's code we've had issues with before. Those issues, and this one, are likely due to it being early code and us (namely me) still learning a lot of core concepts and maybe not applying them so well. So I have a new question: with the different ways that 'implements' and 'provides' may be applied to an object, is there a document that details how those affect the interface/spec resolution order? I'm thinking of things like interface inheritance, class inheritance, ZCML's 'implements' directive, 'zope.interface.implements(IFoo)' in a Python class statement, and any interfaces said to be provided by a particular instance - how much weight does each method provide? A concrete example being: my content management system wants to provide a new 'contents.html' view for the content management skin for all of my different container types, most of which subclass core Zope objects somewhere along the way. I thought that having a root 'IContentContainer' interface was the best way to go - but as subobjects embrace and extend other container types, the 'IContentContainer' interface seems to be getting buried in the resolution order - for the object that I debugged, it ranked 12, while Zope's IFolder ranked 4th and a more specialized CMS content folder interface ranked 3rd. But I want the specialized contents view, which has a lot of sub-pages, so its not something I'd want to have to duplicate in ZCML for every interface, to work for all of them. How can I ensure that IContentContainer (or IManagedContent, or any of my other core-core-core interfaces) DO take precedence over core Zope interfaces for situations where I subclass core Zope objects? ___ 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: View lookup changes in Zope 3.2?
On 12/15/05, Martijn Faassen <[EMAIL PROTECTED]> wrote:
> Jim Fulton wrote:
> > Martijn Faassen wrote:
> [snip]
> > > Or am I wrong in even imagining this would be desirable?
> >
> > I think so. If there are custom views for more specific interfaces,
> > it is likely those custom views provide features that your generic
> > view doesn't. It would be a bit unkind for your view to override
> > those.
>
> I can see that...
>
> I have to consider what this means in practice -- with a skin you often
> want complete control over what users see. If suddenly bits of Zope 3
> pop up for your end user, that'll be very disconcerting; often I really
> don't want that to happen.
>
> Then again, in practice this might not happen, as your end user may not
> be capable of creating such objects anyway in an application; if they
> could you would've skinned them... Not sure...
>
> One troublesome scenario I can imagine is that if I make my total skin
> in Zope 3.n, it works, and then Zope 3.n + 1 is released and it has a
> more specific view registered for some content object that I'm using. I
> was relying on having skinned the more general interface, but suddenly
> in Zope 3.n + 1 I get the Zope 3 view. That'd be bad.
>
> So, I'm not sure whether or not this ability is compromised in practice
> with this bugfix...
If it is compromised, it may be bad design on your part? That's the
decision that I came to. I made a slightly modified
'EditMetaData.html' view for our CMS system that added a 'keywords'
field, made the form look nicer in our interface, and then mapped
'keywords' to IZopeDublinCore.subject (subjects? I can't recall right
now). I bound the view to one of our core interfaces,
'IManagedContent', used to distinguish CMS objects from other content
objects. Anyways, after installing Zope 3.2b1 I was getting the
default EditMetaData.html view instead of ours.
I wrote a little helper module for me to 'debug' this situation -
basically I took the internal
zope.interface.adapters.AdapterLookup.lookup code that did the
multi-adapter lookup and compiled a list of the multi-adapters it
chose from instead of having it choose the best. For this
'EditMetaData.html' situation, I got the following results for one of
my objects:
[(((3, ),
(4, )),
),
(((5, ),
(2, )),
)]
The integers are the ranks used, mapping to (view for, layer). This
particular case shows me that the IAnnotatable, IDefaultBrowserLayer
combination is ranked (3,4) which wins out over my IManagedContent,
CMS view, ranked (5,2). The solution here was for me to re-declare
what my view was for and make it for IAnnotatable. I run my debug
function again and get the following results:
[(((3, ),
(4, )),
),
(((3, ),
(2, )),
)]
Now my custom view is ranked (3,2) and wins out over the default one.
I'm still unsure about how I feel about this situation in my gut. The
Zope 3.1 way felt strangely intuitive, but I recognize why it was
incorrect and why the 3.2 implementation does what it does.
I decided to make a special branch of our CMS to deal with Zope 3.2
beta testing, and it's turned into a big refactoring / mild
restructuring branch. I'm re-evaluating a lot of the blind
'implements' declarations I was making. I'm re-evaluating some of my
core interfaces and decided what ones belong to concrete objects and
which ones are or can be abstract notions ('marker' interfaces). This
is a task that's been in the back of my head for a while. I have a
pair of core content objects and corresponding interfaces that we've
used interchangeably and I really needed to come down hard with a
policy. For us at Bottlerocket, these core objects have bitten us in
the past. So for me - and I'm not saying it applies for you or anyone
else - this change to the 'correct' behavior for multi-adapter lookup
has highlighted some design flaws in our code and way of thinking. If
this issue didn't show itself now, a different issue may have shown up
in the future.
I'm attaching the little 'debug' module I whipped up. Using it, along
with statements like pprint(providedBy(myfolder).__iro__) helped me
realize that I had some bad implements declarations in my base classes
/ ZCML.
So for me, this helps because it should make my code tighter. Where it
doesn't sit well with me is just that for me (and you too Martijn), it
seems like it's more intuitive for the skin layers to have precedence.
Whether that intuitive feel comes from the Zope 3.1 behavior, or
whether it may be the 'right' way people expect things to behave, I
don't know.
But now that I understand multi-adapters and how they're used to do
browser views, I have to admit that I'm very impressed with how the
very core component architecture is used for *everything*, especially
after the 'Simplify Component Architecture' proposal was implemented.
I'll gladly break with what Zope 3.1 let me get away with in favor of
a "work
Re: [Zope3-dev] URGENT RFC: Is anyone using response.write in Zope 3?
I was using it in some custom views for HurryFile based images. I've removed it since I started testing our code against Zope 3.2. Right now I just return the hurryfile binary data with a return statement (one big chunk), but am looking forward to knowing how to return long output. On 12/19/05, Jim Fulton <[EMAIL PROTECTED]> wrote: > > When we refactored the Zope 3 pubisher to work more closely with WSGI, > we decided to remove the response.write method. We should have written > a proposal for this, but we failed to do so. Over the last few weeks > there has been much discussion of this in which I asserted many times > that I didn't think any applications outside of Zope 3 itself used this > method. No one has disagreed with me. I want to double check this. > Does anyone have any Zope 3 applications that are using response.write? > > Assuming that the answer is "no" (or that no one answers today), I'm going to > more clearly document how to return long output and I'm going to add a > method that generates a hopefully helpful error. > > Note that we may add this method (or something like it) back in the future > to support chunked streaming output, > > Jim > > -- > Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! > CTO (540) 361-1714http://www.python.org > Zope Corporation http://www.zope.com http://www.zope.org > ___ > Zope3-dev mailing list > Zope3-dev@zope.org > Unsub: http://mail.zope.org/mailman/options/zope3-dev/eucci.group%40gmail.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] URGENT RFC: Is anyone using response.write in Zope 3?
Yes, it's hurry.file. What's Tramline? We're using hurry.file for small images, generally, and it's been working fine. We've recently written a cache manager that writes the images out to the file system where Apache can serve them. So when that's in place (and working), efficient image serving from Zope is not that big of a concern to us... But back to the issue at hand - knowing how to better serve those out to the response would be a big help. On 12/19/05, Martijn Faassen <[EMAIL PROTECTED]> wrote: > Jeff Shell wrote: > > I was using it in some custom views for HurryFile based images. I've > > removed it since I started testing our code against Zope 3.2. Right > > now I just return the hurryfile binary data with a return statement > > (one big chunk), but am looking forward to knowing how to return long > > output. > > Is HurryFile the same as hurry.file? You know of course hurry.file is > pretty inefficient if you don't use tramline (which still needs > integration into hurry, patches welcome :). > > Regards, > > Martijn > ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Important Heads Up: I'm making IResult private
On 12/23/05, Jim Fulton <[EMAIL PROTECTED]> wrote: > > I've been working on trying to clean up the IResult/response.write mess. > I want to retract IResult from the public API. > > Here's what I propose to do: > > - Move IResult from zope.publisher.interfaces.http to >zope.publisher.http, thus making it a private interface. > > - I'm arranging that a published method can simply return a file, >rather than a string. This will be how you can efficiently >return large results. By file, do you mean a Python ``file`` object? Will StringIO suffice? Or will a very simple interface like IReadFile (zope.app.filerepresentation) be enough? ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: abolishing python: expressions in ZPT TALES
-1. I use them very rarely, and expect to use them less with Viewlets now in the picture. But there are still little situations where Python expressions are handy, especially on big-macro templates where there's not a backing view. I'm not advocating programming in page templates, but there are some boolean or quick-transformation (ensuring a potential iterator/generator is a list and has length) that needs to be done out in this phantom land. As I mentioned above, I really believe that Viewlets and Viewlet Managers will help with these big complex templates which provide the look and feel of the front page or the basic template. But I know that sometimes, when putting those pages together from a designers input on a tight deadline with multiple browsers to test, the quick math and other small expressions we can squeeze into those spots have been a life-saver, even in recent weeks. On 12/28/05, Rocky Burt <[EMAIL PROTECTED]> wrote: > Hi all, > > Please don't mistake this as a proposal or anything of the sort but I > was just curious what the rest of the zope3 community thought on this > particular topic. (Please forgive me if this topic has been exhaused to > death already) > > Its my personal opinion that anytime a page template requires logic > complicated enough to warrant using a 'python:' expression, that logic > should be re-thought and placed into a view class. I know that some > python: expressions are fairly simple, but for an HTML designer, *any* > python: portions are dangerous to touch (and shouldn't be touched by the > HTML designer). > > What do you all think? > > Regards, > Rocky > > > -- > Rocky Burt > ServerZen Software -- http://www.serverzen.com > ServerZen Hosting -- http://www.serverzenhosting.net > News About The Server -- http://www.serverzen.net > > ___ > Zope3-dev mailing list > Zope3-dev@zope.org > Unsub: http://mail.zope.org/mailman/options/zope3-dev/eucci.group%40gmail.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] attr name space (was: RFC: abolishing python: expressions)
On 12/30/05, Alexander Limi <[EMAIL PROTECTED]> wrote: > On Thu, 29 Dec 2005 15:49:46 +0100, Philipp von Weitershausen > <[EMAIL PROTECTED]> wrote: > > > I think it would be quite possible to do explicit key or attribute > > lookup with TALES, e.g.: > > > > foo/attr:bar (for foo.bar) > > foo/key:bar (for foo['bar']) > > foo/item:1(for foo[1]) > > This reminds me of a thing Steve Alexander and myself talked about when > working together on a project using Zope 3 a while back: > > One of the ugliest and most error-prone parts of TAL is its handling of > multiple attributes: > > > > etc. > > We looked at having a separate namespace for these kinds of statements. > The above code would then be: > > attr:title="some/title" /> > > thus doing away with the need for semicolons and the "should the last line > have a semicolon or not" confusion. Maybe it's the crack talking, but I'm vaguely remembering conversations about syntax like this from back in the early days of TAL specification development. Of course, back then TAL was aiming to be a very-good XML citizen. And I think this meant that: - the TAL namespace had a limited and proper list of attributes. A very limited set of names that could be (theoretically) validated with standard XML tools. - XML processing, if I recall correctly, does not cover ordering of tag attributes, nor gives them any significance. You couldn't have 'attr:title' have any dependency on 'attr:href', for example. As a result, there are a limited list of TAL keywords with a well defined order of execution. How would these namespaces impact that? When doing "proper" XML processing with TAL, would the 'attr' and 'defines' and other namespaces all need to be explicitly loaded? I neither love nor hate the semicolon to separate statements - except in string: expressions. I'm still not sure how to properly escape them there. I like that I can do multi-line strings as a single statement (useful for JavaScript when one's given Dreamweaver mouseover code). But I sometimes get too many semicolons showing up in some javascript onFoo attributes (like trying to generate an onLoad for a page that could define additional onLoad events, although I've found other ways to get around that). > The same would probably be relevant for tal:defines, something like: > >define:fish="here/getFish" > > /> > > This provides the following benefits: > > - Easier to parse for XML tools (no semicolons with any meaning) See my concerns above. They might not be real concerns, but they're little things I remember coming up in early TAL discussions. > - More consistent syntax, no need to learn a special way to separate > several attributes/defines No, instead one needs to learn a large crop of new namespaces on top of the regular TAL and METAL ones, and how their order impacts other TAL statements. More namespaces increases the chance of namespace collision. What impact does this have on other TAL statements (condition, repeat, etc) - are they still in the tal: namespace? TAL and TALES have a very simple and well defined syntax as they are. This proposal adds in some special cases. Learning to use a semicolon as a way to separate statements is not that hard to learn. If you have multiple statements on a single line of Python, you have to use a semicolon (some situations make having this nice). If you have multiple JavaScript expressions in an event handler in HTML, you separate them with a semicolon. > - It looks nice! :) That's relative. I love the simplicity of TAL and basic TALES expressions. There are other things about TAL/TALES these days that bugs me. The special TALES path namespaces like zope:title_or_id - I wish it was easier to discover what things like that are defined and how to define ones own. That's a feature that I often forget is there, and there may be some helpful things in those namespaces that I'm not even aware of. > For the record, I'm also for getting rid of the python: stuff in TAL, but > only if we can solve the common use cases others have identified earlier > in this discussion. Making ZPT carry less smarts and preferrably get it a > bit faster would be very welcome in my universe. :) I think that separating the attrs out into individual calls makes TAL have to carry more smarts. By the way - a common situation I was reminded of while typing all of this: no boolean expressions for doing things like 'ensure a false value is an empty string'. I know you can do things like "path1/path2|string:" but that only works if that path can't be traversed. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: abolishing python: expressions in ZPT TALES
Actually, I just found another place where Python expressions are handy. I have a simple but kindof specialized form - one that is too simple and too specific to really go through the Zope schema system without a lot of gnashing of teeth. It may be easier to do with zope.formlib, but it's still not something I want to find out. With only two radio buttons and a checklist (in one variation) that can appear or disappear based on the radio button settings (via Javascript) or the current configuration. Figuring out how to go through all the schema stuff and present it in the way I want to present it is just way too much work for this problem domain. So here I am with: I suppose I could go through and apply things to the view and set true or false attributes like 'currentSettingIsEditors' 'currentSettingIsEverybody', but that seems a little ridiculous for this situation. This is a rare case as well, usually the zope.app.form or zope.formlib material provides more than enough. But those are both overkill for the situation I have here, especially when some simple Javascript needs to be applied. For the record - the formlib stuff doesn't really work here because there's no real Schema of any kind to work with; it's a multiple choice display with a lot of information displayed for each radio button choice (how to do this easily with schemas I just don't know. Vocabularies still make my brain hurt when I try to use them, binding the right custom widget for some of these collection / choice type fields is difficult, and this situation really wants a custom widget to render this text as I want it); and one of the choices may enable another field to show up when selected. The view behind it does a lot of computation to figure out the current setting. This is all to provide a drop-dead-easy security form for certain objects where a restricted user can opt to share a particular object with an even more restricted set of users, or keep it public. It seemed easier to use basic HTML skills to design the UI and dedicate the view's logic to computing the current setting and applying the user's decision. Not having Python expressions to do a boolean test to see which radio button to highlight wouldn't have been the end of the world, but it would have been severely frustrating. (Figuring out all of the ways that security and 'anonymous' access can best be granted or denied was more than enough fun on its own, thank you). On 12/28/05, Rocky Burt <[EMAIL PROTECTED]> wrote: > Hi all, > > Please don't mistake this as a proposal or anything of the sort but I > was just curious what the rest of the zope3 community thought on this > particular topic. (Please forgive me if this topic has been exhaused to > death already) > > Its my personal opinion that anytime a page template requires logic > complicated enough to warrant using a 'python:' expression, that logic > should be re-thought and placed into a view class. I know that some > python: expressions are fairly simple, but for an HTML designer, *any* > python: portions are dangerous to touch (and shouldn't be touched by the > HTML designer). > > What do you all think? > > Regards, > Rocky > > > -- > Rocky Burt > ServerZen Software -- http://www.serverzen.com > ServerZen Hosting -- http://www.serverzenhosting.net > News About The Server -- http://www.serverzen.net > > ___ > Zope3-dev mailing list > Zope3-dev@zope.org > Unsub: http://mail.zope.org/mailman/options/zope3-dev/eucci.group%40gmail.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: RFC: abolishing python: expressions in ZPT TALES
On 1/3/06, Wade Leftwich <[EMAIL PROTECTED]> wrote: > Andreas Jung wrote: > > To bring it to the point: _scripters_ should be able to develop in Zope > > 3 as easy as in Zope 2 :-) > > Or at least almost as easily as in RoR or Django. TTW is not a > requirement; Chris McDonough's "TTB" posting was right on target > (http://www.plope.com/Members/chrism/ttb_programming). Are those 'scripters'? I see RoR and Django going down the same path that Zope 2 went down. They're great, they're young, they're inexperienced. Django's horrible query syntax reminds me of the cryptic early index querying that Zope / Principia had that was geared primarily for input coming in from web forms and not scripting. I see both of those projects taking either shortcuts or blanket "we only do things this way" statements. [Django: "we don't support HTTP auth. We've never needed it."]. It's not to say they're bad products at all. To work in Django, you essentially are using Django's "admins", which apparently many of their target users don't mind. This is akin to just using and promoting the Plone UI, the ZMI (zope 2 or zope 3's) or whatever. Neither I nor my customers have wanted those UIs. I love Zope 3 for finally giving me the freedom of detaching from the ZMI completely (with me having the option to use it for emergencies, but our own much more focused skins should do the job well enough to not need it). > There are 3 PHP developers in the group I work in, and they know they > want something better, and they like Python. But when they look at Z3 > they get all upset & confused. I like Ruby. But when I look at rails I get all upset and confused. I still have no idea how its widgets work. With Zope 3, I was able to follow the adapter lookup chain. Granted, I'm pretty familiar with Zope 3's component architecture by now. Zope 3 needs better advocacy. It needs better web site(s). If zope3.org turns out to be a Wiki I promise to take extra medication and try to add some helpful material to it as possible, because I think Zope 3 is really lacking in different levels of tutorials from different authors who have different perspectives that may better help different audiences. *whew!* That's the problem. It's great that there are books out there. But there's no good central and well promoted advocacy sites. Many Zope 3 developers, like myself, I imagine are often very heavy with real work engagements and finding spare time to write and advocate aren't there. > Is this (increased usability for non-experts) a possible project for the > Zope sprint at Pycon? I'll be there. And since I am not an expert > myself, I will have a head start. I still think that a great "increased usability" could come from a zope3 focused web site that is simple and fun. With the time based releases, it's known what's going to be in each release. My gods, I'd LOVE to see articles like "Exploring Zope 3.x: New feature - Viewlets". I'd LOVE to see clear documents like "Exploring Zope 3.x: what's deprecated, why, and how to fix it." The doctest documentation about content providers, forms, and viewlets are great for experts. At least there's fairly comprehensive documentation that I can read and figure out and go "ahh!". But turning that into a more comprehensive non-expert story on a web site would be a good thing. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Undo Principal Transaction problems with pluggable users
I've developed a sick fascination with undo and have been working [hard] over the past few days trying to write some code for our internal frameworks to make Undo easy. Inspired by GMail's "Message Discarded (Undo Discard)" functionality, I've set about making something similar that does a modified version of zope.app.undo.browser's "Undo Last Action", which uses the 'undoPrincipalTransactions()' method of the ZODBUndoManager (zope.app.undo). I've filed a collector issue, 529 http://www.zope.org/Collectors/Zope3-dev/529 Basically, unless the request.principal comes from the global registry, a principal can't undo their own transactions (UndoError gets raised). Even when I tried to patch the code to get the user from zapi.principals() (which worked and put a principal object in the transaction entry information being retrieved), a later identity comparison of info['principal'] against request.principal failed, causing UndoError to be raised. I tried an equality check, but it didn't work either. If I'm logged in as a global principal defined in zcml, it works fine. 'getPrincipalTransactions' works fine, I'm assuming (or hoping) that as a workaround that once my code has the filtered transaction list, I could call 'undo' on the undo manager instead of undo principal transactions, so long as I remove the security proxy first. I'm fairly satisfied (enough for tonight) that the selected transaction I want the view to undo is the users own. I'm hoping that works so I can leave here in relative peace tonight, hurry home to my dog, and enjoy a ski day tomorrow :) ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Principal Comparison and/or References
I found an issue with zope.app.undo's ZODBUndoManager wherein it only
could undo principal transactions if the principal in the request came
from the global principal registry. I tried patching our copy by
changing it to look up the principal of a transaction record from
zapi.principals() (gets the nearest IAuthentication utility).
When it tries to do the undo, it compares request.principal against
transaction['principal'] with identity comparison (' is '). That
doesn't work for pluggable auth principal folder based principals,
even if by my own assumptions and simple application setup they are
the same.
With all of the other principal / group mini-proposals going on, does
there need to be a way to strongly (if that's the right word) compare
a principal looked up from an id that came out of... well, somewhere
(a transaction log record, a string stored in the 'creators' dublin
core sequence, etc), or even against each other?
>>> b3_1 = zapi.principals().getPrincipal('brcms.user.3')
>>> b3_2 = zapi.principals().getPrincipal('brcms.user.3')
>>> b3_1 is b3_2
False
>>> b3_1 == b3_2
False
Comparing the id attribute works. Is it reasonable to assume that
zapi.principals().getPrincipal(request.principal.id) should return the
same principal as request.principal? And thus if
somerecord['creator_id'] == request.principal.id, that's considered a
good match?
--
Jeff Shell
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Principal Comparison and/or References
On 1/13/06, Gary Poster <[EMAIL PROTECTED]> wrote: > > Comparing the id attribute works. Is it reasonable to assume that > > zapi.principals().getPrincipal(request.principal.id) should return the > > same principal as request.principal? And thus if > > somerecord['creator_id'] == request.principal.id, that's considered a > > good match? > > Yes. We compare on principal id. > > I believe it would be relatively easy to set up your system in such a > way that this would not be safe. For instance, you could have two > sites, both with authentication utilities. If each authentication > utility had the same prefix and had a user with the same key in the > auth utility, then you would have two different users with identical > ids in the system. I was thinking of that, and the possibility that (somehow) the system could be hijacked in a way that after authentication a different utility would respond first to getUtility(IAuthentication) and provide a different matching principal for the principal id. I don't know how big of a concern that is. It might fall into the realm of "if your code is doing that, it's stupid; if some other code managed to do that, you're probably severely hacked anyways and this is the least of your problems." What I'm saying is that I'm not sure what a security auditor would look for in a situation like this. For our applications right now, we're not too concerned about really tight security, so if I know that comparing the IDs is good enough, I'd just go ahead and do that. I have a feeling that it might not be enough for everybody. I know that Zope 2 would keep track of the authentication path, and its entries in the transaction log include the path to the acl_users the user came out of. I think most other people using RDBMS systems for managing users or storing a user id in the RDBMS didn't use this, and would basically store just the user id. I guess most people found that good enough..? > It might be reasonable to add a bit to the IPrincipal interface that > __eq__ is provided and uses id to compare. That seems reasonable to > me, but maybe others have qualms. Care to write a mini-proposal? ;-) I'm interested in what others think. Other people here have a deeper knowledge of the security policies, principals, than I do. I don't know if this is something that should be pluggable - IComparablePrincipal? - so that a tighter security policy (I guess?) could compare principals on more than the ID. Since IPrincipals aren't locatable, you can't really compare the path that yielded the principal. That's the part that I'm unsure about - if it's possible (or worth worrying about) for a getPrincipal() call later in a request to yield a different result than it would have when request.principal was set. So maybe something that wanted tighter control and wanted to compare not just the id but the authentication utility that yielded the Found or Authenticated principal could listen for the respective events (zope.app.authentication.interface.FoundPrincipalCreated | AuthenticatedPrincipalCreated) and tag the principal with information about the authentication utility that provided it, such as the path (if the authentication utility is locatable). The adapter then says the principal directly provides IPathAwarePrincipal. An IComparablePrincipal adapter is provided for IPathAwarePrincipal that compares the paths of two principals as well as the id. It seems like a heavy scenario, and again I add the disclaimer that for me it doesn't matter much for our current customers and people who think harder about security may have better insight, but it seems like a way to allow applications to install stricter comparisons so that any code - regardless of where it is or who wrote it - can do something like: # obj.author = 'foo.user.1' owner = zapi.principals().getPrincipal(obj.author) if owner == request.principal: # it's the owner. that code stays simple, natural, and "pythonic" (no need to remember looking up something like IPrincipalComparator as a utility or adapter), but comparison can be rich if the application wants. I've already found one spot in Python code that does a comparison like this, and it works for global registry principals. Regardless of how it's made to work, it should work for all. At the same time, I recognize the desire to keep the zope.security.interfaces.IPrincipal interface small, so I'm not sure what to suggest. Since comparison works fine for global registry items, maybe __eq__ should just be put into zope.app.authentication.principalfolder.Principal since that's what's created by the default Found / Authenticated principal factories? Or is the answer "if this is something you care about, provide your own principal factories for pluggable auth that provide the principal you want and don't pressure the core to do more?" ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archiv
[Zope3-dev] schema api
I noticed that modules that begin with an underscore aren't shown in apidoc in Zope 3.2. I think (but am unsure) that Zope 3.1 showed these. I'm sure there may have been a good reason for doing this, but it makes navigating the zope.schema package for documentation even more difficult. In particular, there are the convenience functions in the _schema.py module that are useful for schema querying. getFieldNames, getFields, etc... I can never quite remember what's in there and which ones return sequences of tuples and which return mappings or lists or iterables. There's also no easily visible list of all of the fields available from zope.schema.*. The interfaces are there, but people interact with the classes in this package more than their interfaces. Since all of the fields are defined in _bootstrapfields and _fields, they're no longer visible. They can be found from the interface down in the factories/classes section, maybe that's good enough? -- Jeff Shell ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: ZCML bad ;-)
e will be lost. Again - I like what zope.formlib offers, and I like the IFormAPI interface and concept. I'd like to see more of a move in that direction for the core facilities. Instead of "write these n lines of ZCML to auto-generate an edit form for a schema/interface", it should be "write these 5 lines of Python to generate that form, and 1-2 lines of ZCML to register it, name it, and protect it." And then, as the user may need to customize the form, they can add to this class instead of having to span the two worlds of ZCML automation and Python. It's much easier to go up a good and simple base class tree and read / understand the code than it is to go through ZCML meta configurations. And it makes the distance between the main doctest documentation and how things work a lot shallower. (I liked viewlets a lot more while reading the main viewlet info file, and liked them less after reading about and wrestling with their ZCML directives). -- Jeff Shell ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] ZCML bad ;-)
On 1/24/06, Chris Withers <[EMAIL PROTECTED]> wrote: > Gary Poster wrote: > > > > FWIW, me too. I'm no XML guru (as Fred will attest ;-) ) but reading > > the namespaces on an XML file seems like basic XML procedure. > > Well, the reading of them is the lesser of my two complaints... > > I find it irksome to have to type them at the top of ever file. Is there > no way that they could be pre-bound in the XML parser? That way you'd > only need to inlcude them if you wanted to rebind them... It's like those damned imports in Python. Why can't everything just be available in one big honkin' namespace automatically? ;-) Seriously - it's not that bad. ZCML's use of namespaces is judicious, I believe. There's no namespaced attributes - just the directives. I too use browser: as the default namespace in my browser focused ZCML files. There's only one or two things to type, ever. The namespaces are easy to remember. I can't believe it's a big deal at all. It's certainly a case of 'explicit is better than implicit', I believe. Like with Python code and modules and avoidance of import *, it makes all names easily traceable. Are you using an editor that makes it difficult to go to the top of the file to check on the names? ___ 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: Selecting a code name
ot; but are fine with writing ``first_name = meta.CharField(maxlength=30)``. But in Zope 3.2, you can't even get a list of zope.schema.* fields in apidoc easily! To make up for it, there's *great* documentation about formlib, but it's in the source. Anyways, I'm sure this is all stuff that we can agree on. I think the code-naming thing is silly. Names drive me crazy after a point because I just don't find the worth in keeping my internal translations up to date. If the next release is going to be sexy, I still think that there should be good articles written as the release approaches. From "New in 3.2: zope.formlib, why it's better than zope.app.form, how to start using it" to "Deprecated in 3.2: i18nmessageid versus i18nmessage and how it affects you (especially if you don't know anything about internationalization)" It's like the difference between this, which we have: http://www.python.org/2.4.2/NEWS.html http://www.python.org/2.4/highlights.html and this, which I absolutely love: http://www.python.org/doc/2.4/whatsnew/whatsnew24.html I know that even I would care a lot less about new Python releases if it weren't for Andrew's terrific documents. And while they're not comprehensive, they're great for quickly getting that "oh, so that's what that new thing is!" enlightenment. But with 3.2, some of the new big features seemed to be surprise to even some core developers: "Viewlets made it? Whoa..". So if Viewlets are in Zope 3.2 Xing Hua and no one knows about them, does the fancy branding make a sound? This is an important discussion and I don't think I'm saying anything new here, at least not new for me. I just want to say that 'brand' is very important, and not to be taken lightly. But also there are far more important things than coming up with fancy names. There's been a lot of discussion about packaging and releases - very important, I think. I had to write my own little semi-packaging system because I was pulling in so many disparate and useful third party tools and had our own stack and getting it all out of the various subversions and CVS repositories and into something usable and something I knew would work with the released version of Zope (or released version we're using for a particular suite of apps). 'zpkg' was way too hard to figure out. Eggs... Hell if I understand them anyways. So while it's great there are so many useful tools and libraries people have made available, who thinks they could write a page for the mythical Zope 3 web site that says "You've just downloaded Zope 3.2 - Now what are some other things you can use with it? [list of packages, easily downloadable and installable]" Again, knowing I have Zope 3 Clemens is of no concern if I have to spend another hour arguing with subversion and CVS and then finding out what I checked out worked with the upcoming Zope Big Muddy but not Clemens. So I say - let's focus on the points you and others have brought up about good informational resources, and just make 'Zope 3' a strong brand by making it a strong brand. Otherwise, it's like those episodes of The Wire where Stringer Bell, basically in charge of half the drug trade in Baltimore, was trying to figure out how to keep people coming to his corners when their product was inferior to the dope the east side boys were slingin'. In a business class he learned that changing the name was an option, and soon the corner boys were calling out different names every other day for the same sorry product. Without a change in quality, it doesn't help. > This is the proposal that considers the most serious consideration in my > opinion. The original discussion showed that a lot of people found Zope's > lack of branding a problem. Now it's time to find a solution to that > problem. Something that I admire about Ruby on Rails, Django, MochiKit, and TurboGears all is that they're opinionated, proud of it, clear in their message, and all seem to have a similar degree of respect for simplicity and communication. I hope that's the message that people are getting. You're right in what you say earlier - you can visit these sites and instantly get a grip on what's going on. (On the other hand, 'eggs' and 'paste' and all of these other things, I still don't understand). Alright, I've stayed up way too late on this. -- Jeff Shell ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Selecting a code name
On 2/7/06, Stephan Richter <[EMAIL PROTECTED]> wrote: > On Tuesday 07 February 2006 05:09, Jeff Shell wrote: > > Alright, I've stayed up way too late on this. > > Jeff, > > you always make great points! I would like to nominate you as the "Zope 3 > Propaganda Minister"! :-) No seriously, you have a great way of explaining > why Zope 3 is better than the latest hype; I think you are probably the best > qualified to lead the marketing efforts? Are you willing? Anyone seconding > me? :-) I'm willing, if I can make the time. And if I can make the time to write the lengthy emails that I do, I can write a real document, right? :) Last night I was looking at this page: http://www.zope.org/WhatIsZope and going "damn, that's nice" and then "damn, I wrote a lot of that!" There was some pre-existing material, but I remember updating it into the form that it stands at now and has stood at since. It really makes me want to register a "whatiszope3.com" and putting a page like that up. I've really really really been wanting to do this, and I've talked with the other guys here about doing something.. anything... to give back to the community. Heck, I've been wanting a little server here that I could play with in making a public facing Zope 3 application. But our resources have been severely limited :\. I may still go ahead and make a static page for now, or a post in Griddle Noise. Or even make a Writeboard.. Or a page in my Backpack account.. Or.. So many options, but so many deadlines. But I'll do my part to try to do something in the next few days. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
