[Zope3-dev] Re: RFC: Publication Post-Processing
Jim Fulton wrote: At: http://www.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/PublicationPostProcessing I've put doesn some thoughs for discussion on making the publication APIs more explicit and for supporting post processing tasks like adding standard look and feel or adding missing page components. I've read through this a couple of times now. First, thanks a bunch, Jim, for putting so much thought into it. Couple of thoughts: 1) I don't know if it is or isn't in-scope to discuss page composition outside of Zope server. Consider the headings under Need for page-composition support, Pipelines, Transitive Adaptation, and the subset described under Subscription. It might be possible to also do these inside a WSGI Twisted in Zope 3.2, for example. It might also be possible to do these in mod_python. They all depend on whether Publication Post-Processing should be able to access content *beyond* what enters the publication process. 2) Regarding ordering of events for subscription, it reminds me of (my apologies for this) XSLT. You can have multiple temlates matching on variations of the same event, so to speak: xsl:template match=person xsl:template match=[EMAIL PROTECTED]'customer'] xsl:template match=person mode=header The spec and decisions made by implementors govern which matches. If I understand it correctly, they seem to have reached the opposite conclusion as you. More specific matches first, more general doesn't get called. I like the merits of your thinking, though: It might be argued that invoking more general subscribers first is, in fact, a reasonable, as it allows specific subscribers to build on work done by more general subscribers. 3) I'd be interested to hear how testing could be woven into the adapation process you describe. Meaning, ways to make statements about the structure of the things coming in and going out. --Paul ___ 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 Call for Slaves
Tim Peters wrote: How would you do what manually? Install all the versions of Python you care about on Windows, and build Zope using the version of Python you want to test with. For example, \Python23\python setup.py build_ext -i install_data --install-dir . \Python23\python test.py -v from the root of a Zope3 checkout, to test Zope3 with Python 2.3.5, assuming you installed the latest release in the Python 2.3 line and accepted the default installation directory. Use the path to a different Python if you want to use a different Python. Oh, sorry, I meant how do you select the right version of VC++? and how do you install both VC 6 and VC 7 at the same time? Sorry for being clueless, when it comes to VC I really am, rather than just pretending ;-) Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] A Call for Slaves
Benji York wrote: It's running the tests, that's what we're interested in. Ah, okay, but could we also use the buildbot model to build binary distros for various platforms? As a side issue, what's the security setup like? How do you control who can set up a slave and, as such, who gets to send email failures to this list? cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: RFC: Rename principal to participant
Steve Alexander wrote: Interesting. It looks to me like you're calling a User object what the CMF calls a Member. Sure. Does the CMF have any users who aren't members? The theory is a bit hazy but the practice is quite clear: in CMF all participants are members. The Member object is just a wrapping around the standard User object created during authentication. This wrapping is useful for annotations (email, last_login_time) and other indirections so that Member properties storage is actually dealt with by another tool (the MemberData tool). Florent -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ 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: most specific interface?
On 9/16/05, Florent Guillaume [EMAIL PROTECTED] wrote: (Or use a convenience method to do that, I'm not sure if alsoProvides() was ever implemented.) zope.interface.alsoProvides() works like a champ. -Fred -- Fred L. Drake, Jr.fdrake at gmail.com Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: RFC: Publication Post-Processing
Paul Everitt wrote: Jim Fulton wrote: At: http://www.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/PublicationPostProcessing I've put doesn some thoughs for discussion on making the publication APIs more explicit and for supporting post processing tasks like adding standard look and feel or adding missing page components. I've read through this a couple of times now. First, thanks a bunch, Jim, for putting so much thought into it. Couple of thoughts: 1) I don't know if it is or isn't in-scope to discuss page composition outside of Zope server. It is, at least, worth mentioning. Te discussion is aimed at making if feasible to provide post-processing within the server, although it doesn't rule out out-of-server post processing. Consider the headings under Need for page-composition support, Pipelines, Transitive Adaptation, and the subset described under Subscription. It might be possible to also do these inside a WSGI Twisted in Zope 3.2, for example. It might also be possible to do these in mod_python. They all depend on whether Publication Post-Processing should be able to access content *beyond* what enters the publication process. I'm not sure what you are getting at here. 2) Regarding ordering of events for subscription, Actually, ordering of subscriptions for events. :) it reminds me of (my apologies for this) XSLT. You can have multiple temlates matching on variations of the same event, so to speak: xsl:template match=person xsl:template match=[EMAIL PROTECTED]'customer'] xsl:template match=person mode=header The spec and decisions made by implementors govern which matches. If I understand it correctly, they seem to have reached the opposite conclusion as you. More specific matches first, more general doesn't get called. I like the merits of your thinking, though: It might be argued that invoking more general subscribers first is, in fact, a reasonable, as it allows specific subscribers to build on work done by more general subscribers. This is really apples and oranges. The matching doen in XSLT is really a search problem. You want to find the *best* match for a situation. This is similar to normal component lookup, where you want to find the best-match component. Subscriptions are very different. By definition, all subscribers are called. Then the issue is what, if any ordering is needed. It appears that a most- general to most-specific ordering is useful, but other orderings are desireable for other cases. This happens to be an area where some good ideas are needed. (See, for example, the recent discussion of ordering on ZODB-dev.) 3) I'd be interested to hear how testing could be woven into the adapation process you describe. Meaning, ways to make statements about the structure of the things coming in and going out. I don't know what you mean. 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/archive%40mail-archive.com
[Zope3-dev] Re: most specific interface?
Philipp von Weitershausen wrote: Florent Guillaume wrote: Philipp von Weitershausen wrote: from zope.app.content.interfaces import IContentType from zope.app.file.interfaces import IFile from zope.interface import directlyProvides directlyProvides(IFile, IContentType) Watch out! directlyProvides is evil, it *replaces* the interfaces provided by something. Here, if IFile implemented something else, it would be lost. You should always use: directlyProvides(ob, ISomething, directlyProvidedBy(ob)) (Or use a convenience method to do that, I'm not sure if alsoProvides() was ever implemented.) Yes, alsoProvides() is available in Zope 3.1. So, alsoProvides(ob, ISomething) is the shorter spelling of Florent's line above. Philipp does alsoProvides() check for interfaces already listed? apparently not: interface/declarations.py: def alsoProvides(object, *interfaces): ... directlyProvides(object, directlyProvidedBy(object), *interfaces) what happens if you write: alsoProvides(ob, ISomething) alsoProvides(ob, ISomething) will ISomething be provided twice? this could be a memory leak in that case. /JM ___ 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: Publication Post-Processing
Am 16.09.2005 um 15:59 schrieb Jim Fulton: Paul Everitt wrote: Jim Fulton wrote: Consider the headings under Need for page-composition support, Pipelines, Transitive Adaptation, and the subset described under Subscription. It might be possible to also do these inside a WSGI Twisted in Zope 3.2, for example. It might also be possible to do these in mod_python. They all depend on whether Publication Post-Processing should be able to access content *beyond* what enters the publication process. I'm not sure what you are getting at here. We need a definition what we mean with pipelines. I understand them with a unix-background, where elements of a pipeline are working on the result of the earlier elements. This is data driven, so a pipeline element does only get the information in the data plus some parameters. Paul probably means the reaching back of the pipeline elements in the application-server context. For example are the pipeline elements be called by a controller, which additionally holds the context of the object in the application space. In contrast the elements could purly be data driven, working on xml- data and nothing else. This looks more defined and is probably be simpler, but I see and fear that then parameter stuff is encoded in the xml-data to steer some transformations later in the pipeline. __Janko ___ 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 Call for Slaves
[Chris Withers] Oh, sorry, I meant how do you select the right version of VC++? You don't; distutils does; if you use a Python 2.3 on Windows, its distutils will use VC6 to compile C extensions; if you use a Python 2.4 on Windows, its distutils will use VC7. It's all driven by which Python you use to run setup.py. and how do you install both VC 6 and VC 7 at the same time? Just run their installers. They don't interfere with each other (well, not unless you do something bizarre, like force the installers to use the same installation directory -- accept the defaults and there's no problem). ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: most specific interface?
Jean-Marc Orliaguet wrote: does alsoProvides() check for interfaces already listed? No, but directlyProvides does. Issuing the same directlyProvides(...) call twice has the same effect as issuing it once. Philipp ___ 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.1.0 RC 3 released!
The Zope 3 development team is proud to announce Zope 3.1.0 candidate 3. 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. It is in our opinion that Zope 3.1 is more than ready for production use, which is why we decided to drop the 'X' for experimental from the name. We will also continue to work on making the transition between Zope 2 and Zope 3 as smooth as possible. As a first step, Zope 2.8 includes Zope 3 features in the form of Five. Now that we have a release that we would like to declare stable next week, we are looking for translators, who translate Zope 3 into their favorite language! We are utilizing the Rosetta system from Ubuntu for managing those translations. If you are not familiar with Rosetta, please send us a mail to zope3-dev@zope.org and we get you set up. Downloads http://zope.org/Products/Zope3/ Installation instructions for both Windows and Un*x/Linux are now available in the top level 'README.txt' file of the distribution. The binary installer is recommended for Windows. Zope 3.1 requires Python 2.3.5 or 2.4.1 to run. You must also have zlib installed on your system. Changes Since 3.1.0c2 - Fixed several bugs that were considered critical. * Ported Stuart Bishop's work in ``pytz`` and ``zope.i18n`` to address broken and misleading timezone code (i.e., one issue was broken and another was misleading). * Fixed apidoc to handle extended paths, so that zope packages could be installed in software instances without apidoc losing knowledge of the core zope code. * Added custom ``executemany()`` method for cursors created through GadflyAdapter. See http://www.zope.org/Collectors/Zope3-dev/445 for discussion. - Updated ZODB to 3.5.1b2. Most Important Changes Since 3.0 - New Pluggable Authentication Utility (PAU), which is similar in philosophy to the Zope 2 PAS. The following features are available in the in the basic PAU facility: + Credentials Plugins: Basic HTTP Auth, Session + Authenticator Plugins: Principal Folder, Group Folder For a detailed description of the pluggable authentication utility, see 'zope/app/authentication/README.txt'. - Major simplifications to the component architecture: + Removal of the concept of a service. All outstanding services were converted to utilities: Error Reporting, FSSync, Authentication. + Site Managers are global and local now; adapters and utilties are directly registered with the site manager. Now global and local component registration and lookup behaves very similar. + Local registrations can now only have two states: active and inactive. This simplified the code so much, that 'zope.app.utility', 'zope.app.registration' and 'zope.app.site' were all merged into 'zope.app.component'. + Implemented menus as utilities. The API also supports sub-menus now. + Implemented views as adapters. Skins and layers are now simply interfaces that the request provides. - Added an integer-id facility for assigning integer identifiers to objects. - Added basic catalog and index frameworks. - Added sources, which are like vocabularies except that they support very large collections of values that must be searched, rather than browsed. - Created a new granting UI that allows advanced searching of principal sources. - Implemented a generic user preferences systsem that was designed to be easily used in TALES expressions and via Python code. Preferences can be edited via 'http://localhost:8080/++preferences++/'. A demo of the preferences can be found at:: http://svn.zope.org/Zope3/trunk/src/zope/app/demo/skinpref/ - ZCML now supports conditional directives using the 'zcml:condition' attribute. The condition is of the form verb argument. Two verbs, 'have feature' and 'installed module' are currently implemented. Features can be declared via the 'meta:provides' directive. - Improved API doctool: Code Browser now shows interfaces, text files and ZCML files; the new Book Module compiles all available doctext files into an organized book; the new Type Module lets you browser all interface types and discover interfaces that provide types; views are shown in the interface details screen; views and adapters are categorized into specific, extended and generic; user preferences allow you to customize certain views; 3rd party modules can now be added to the Code Browser. - Improved I18n-based number and datetime formatting by integrating 'pytz' for timezone support, implementing all missing format characters, and reinterpreting the ICU documentation to correctly parse patterns. - Added '++debug++' traversal adapter that allows you to turn on debugging flags in 'request.debug'. Currently the
RE: [Zope3-dev] Resource Library Proposal
Sorry for the long delay in replying. We've been using widget-specific JS and CSS for some time now and I like our approach. It's quite different from the proposal. We're using the same pattern used by forms/widgets -- i.e. the PT is responsible for explicitly including HTML fragments provided by the view. As a point of reference, here's a simple example of including widgets: tal:block repeat=widget view/widgets label tal:content=widget/labelName/label input type=text tal:replace=widget / /tal:block The analog for including header support (i.e. JS and CSS) is: head tal:block repeat=content view/headContent tal:block content=content / /tal:block /head This places the burden of managing unique lists of 'head content' with the view. I see this as an extension of the widget-management framework. I would not personally opt for the proposal because it feels a bit magical -- I think it's too indirect. So, here's my argument in brief: Since widgets are driving the requirements of a consolidated resource list in the HTML head, the solution should extend the existing widget pattern. Yes, this imposes more overhead on the PT and the view, but the upside (IMO) is that the scheme is more transparent. -- Garrett On , [EMAIL PROTECTED] wrote: I've added a proposal for Zope 3.2. Read at http://www.zope.org/Wikis/DevSite/Projects/ComponentArchitectu re/ResourceLibrary. WARNING: zope.org exhibiting some serious caching strangeness, so please comment on the list instead of the wiki. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
RE: [Zope3-dev] Resource Library Proposal
I don't understand what you just said :-) My fault -- I haven't been plugged into the other discussion. Is there a branch somewhere that has a simple demo to help with grokability? -- Garrett On Friday, September 16, 2005 12:28 PM, Gary Poster wrote: On Sep 16, 2005, at 12:49 PM, Garrett Smith wrote: Sorry for the long delay in replying. We've been using widget-specific JS and CSS for some time now and I like our approach. It's quite different from the proposal. We're using the same pattern used by forms/widgets -- i.e. the PT is responsible for explicitly including HTML fragments provided by the view. As a point of reference, here's a simple example of including widgets: tal:block repeat=widget view/widgets label tal:content=widget/labelName/label input type=text tal:replace=widget / /tal:block The analog for including header support (i.e. JS and CSS) is: head tal:block repeat=content view/headContent tal:block content=content / /tal:block /head This places the burden of managing unique lists of 'head content' with the view. I see this as an extension of the widget-management framework. I would not personally opt for the proposal because it feels a bit magical -- I think it's too indirect. So, here's my argument in brief: Since widgets are driving the requirements of a consolidated resource list in the HTML head, the solution should extend the existing widget pattern. Yes, this imposes more overhead on the PT and the view, but the upside (IMO) is that the scheme is more transparent. If we had a clear division between update and render stages, and all template elements had an update call before they were rendered (and so were able to register a need) then the approach you suggest would be generally sufficient for the kind of story we are interested in telling. Pipelining, possibly combined with a modified templating story, can address this in a different way--one of the simplest configurations would support something like separate update and render stages. Even there, though, the resourcelibrary API for clients could remain the same, whether the JS/CSS were inserted by a main template that rendered the gathered JS/CSS calls, in a modified version of your approach; or by the XML-munging (or transformation to put it in a more politically appealing light) that is the current implementation. I'd say that this proposal has two thrusts. First, it proposes that we need a solution to the problem of stand- alone display components that need support from the main page. That's something that we (ZC) want, and for which other replies to the thread have also expressed desire. It enables a drop-in rich- widget story, which is arguably becoming more important as user expectations for richer internet experiences rise, and developer expectations for simpler integration of rich client technology rise. Second, it proposes that the given API can support a number of rendering implementations, from transforming HTML (as in the current implementation) to being a part of a wrapper main template during a rendering stage of a pipeline. The proposal should be evaluated from that perspective, and from the perspective of Jim's recent pipeline discussion. Can you see the need? Can you see how the API can support several rendering implementations? Developers who say yes to both can develop and use drop-in rich sub-page components, such as widgets. Developers who say yes to the first but no to the second are urged to suggest improvements. And thanks to the wonder of the more plug-and-play architecture of Zope 3, developers who say no to the first question don't have to play here, while still joining up elsewhere. :-) Gary ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
RE: [Zope3-dev] Resource Library Proposal
I mean something that illustrates Gary's 'big picture'. I understand the resource lib proposal, but I don't have any grasp of the broader vision driving it. If it's just a patch to get 'rich' widgets working, I'll stick with my initial impression of it being too magical. -- Garrett On Friday, September 16, 2005 3:15 PM, Benji York wrote: Garrett Smith wrote: I don't understand what you just said :-) My fault -- I haven't been plugged into the other discussion. Is there a branch somewhere that has a simple demo to help with grokability? http://www.zope.org/Wikis/DevSite/Projects/ComponentArchitectu re/ResourceLibraryREADMETxt ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
RE: [Zope3-dev] Resource Library Proposal
On Friday, September 16, 2005 4:05 PM, Benji York wrote: Garrett Smith wrote: If it's just a patch to get 'rich' widgets working, I'll stick with my initial impression of it being too magical. The main reasons why this isn't a problem individual widgets can solve is that 1) they can't know if things that should only be done once have already been done (include JavaScript for example), 2) they can't directly add entries to the head section of the page, and 3) the components that require the JS or CSS might not be widgets at all. That's right. But the view can solve these problems easily without a lot of other stuff like yet-another-ZCML directive and automagical transformation of the HTML head element. This is what we have: class IHeadContent(Interface): Something that provides head content for a page. def headContent(): Returns a sequence of HTML snippets to be added to the page head. class SomeView(BrowserView): def __init__(self, context, request): ... self.headContent = [] for widget in self.widgets(): hc = zapi.queryAdapter(widget, IHeadContent) if hc is not None: for content in hc.headContent: if content not in self.headContent: self.headContent.append(content) ... The applicable PT: head tal:block repeat=content view/headContent tal:block content=structure content / /tal:block ... /head This is a trivial change to the existing Zope code. -- Garrett ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
RE: [Zope3-dev] Resource Library Proposal
My point is that if rich widgets are the *only* driver here, the solution below is a better fit with the existing widgets implementation. The transformation of the HEAD doesn't jive with existing patterns. If there's a new pattern afoot (pipelining?), I hope we get a chance to discuss it. If I've just missed the discussion (quite possible), I'll wait for the RC. FWIW, we would not be able to use this new scheme exclusively as some of our IHeadContent providers provide more than file includes. E.g. we have a menu component that dynamically builds JavaScript and includes it directly in the HEAD. -- Garrett On , [EMAIL PROTECTED] wrote: Garrett Smith wrote: That's right. But the view can solve these problems easily without a lot of other stuff like yet-another-ZCML directive and automagical transformation of the HTML head element. This is what we have: class IHeadContent(Interface): Something that provides head content for a page. def headContent(): Returns a sequence of HTML snippets to be added to the page head. class SomeView(BrowserView): def __init__(self, context, request): ... self.headContent = [] for widget in self.widgets(): Like I said before, they're not always widgets. For something like this to work you have to be able to enumerate all the page components no matter what type of thing they were. That's not always convenient or even possible and seems more constraining than the proposal. The applicable PT: head tal:block repeat=content view/headContent tal:block content=structure content / /tal:block ... /head The proposed solution also does not require any dead chickens in ZPT. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
RE: [Zope3-dev] Resource Library Proposal
On Friday, September 16, 2005 3:58 PM, Gary Poster wrote: You could also be asking about the pipeline ideas, but that's not my first guess. :-) Yes, I suspect this is what I'm missing. There was an earlier post about Ajax. It seems an entirely new approach would be needed to solidly support Ajax. I.e. we would need an architecture that let components interact independently of the browser view, or at least could be accessed in isolation of a full page rendering. Is this the sort of thing the 'pipeline' approach is getting at? -- Garrett ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Resource Library Proposal
Garrett Smith wrote: On Friday, September 16, 2005 5:17 PM, Benji York wrote: Garret Smith wrote: FWIW, we would not be able to use this new scheme exclusively as some of our IHeadContent providers provide more than file includes. E.g. we have a menu component that dynamically builds JavaScript and includes it directly in the HEAD. That is a different, but related, problem that should probably be addressed separately. How is this different? Resource library is about including references to (static, file system based) resources on an as-needed basis. The use case you mentioned is about including dynamically generated JS each time a view is rendered. -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Resource Library Proposal
On Sep 16, 2005, at 6:15 PM, Garrett Smith wrote: On Friday, September 16, 2005 3:58 PM, Gary Poster wrote: You could also be asking about the pipeline ideas, but that's not my first guess. :-) Yes, I suspect this is what I'm missing. Maybe so. Maybe you just disagree. :-) In a later email, you and Benji discuss how this might be used for dynamic JavaScript. Benji made the point that that is not what we are talking about. I agree with him, but I think I see your confusion. We expect that the pipelining ideas will lead to a reasonable way to transform output. We hope to leverage that for the resourcelibrary. You could certainly leverage the method yourself, for your own means. The resourcelibrary use case is one of the simple stories that is pushing pipelining--a much larger and more exciting development, I think--along right now. To explore your use case further, though, I'm not sure why you would need something like resourcelibrary for dynamically generated insertions--that is, JavaScript code that the server writes differently for each request. You can just include that inline. The resourcelibrary makes sure that you only include a single instance of the necessary libraries, makes sure that CSS is at the top, as it has to be, and so on. These combined requirements led us to the current approach. There was an earlier post about Ajax. It seems an entirely new approach would be needed to solidly support Ajax. I.e. we would need an architecture that let components interact independently of the browser view, or at least could be accessed in isolation of a full page rendering. Is this the sort of thing the 'pipeline' approach is getting at? No. Pipelining is about taking what the Zope publisher spits out, and then transforming it before returning it to the user. For instance, views might spit out an XHTML snippet, and pipelines would wrap it. Or views might spit out XML of data only, and pipelines would make transform it into a UI. Or views might spit out non- string objects, which would be transformed. And so on. I don't think Ajax needs an entirely new approach--at least what I would mean by an entirely new approach. :-) I'm working out some proposals for that in the new widget code that was started in the sprint. I'll hope to talk about that soonish (though I have a number of other projects I have to wrap up before I get to that :-/ ). The use of ajax libraries will benefit from something like resourcelibrary. Other than that the two are not that related. To get back to your concerns about the resourcelibrary (and conclude), it is currently a drop-in component (from which you can easily opt out) and the pipeline plans should make that even more the case. You'll just be opting out of any shared rich widgets and shared composite page projects that use it. Since you've forked the widget code, it sounds like that sort of thing might not phase you. :-) Gary ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
