Re: [Zope3-dev] catalog 'all documents' abstraction
Jim Fulton wrote: [snip] It would be helpful if someone could explain the motivations behind the extent catalog, by the way -- this information seems to be missing in zc.catalog. Am I at all on the right track with my thinking on it? What information? Sorry for being unclear. I meant the information motivating the various things introduced, in particular the extent concept. I.e. textual information with goals and motivations -- the why of extents. Anyway, Gary's been replying to this bit so I'll continue in that area of the thread. 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] catalog 'all documents' abstraction
Gary Poster wrote: On Aug 30, 2005, at 1:57 PM, Martijn Faassen wrote: [snip] It would be helpful if someone could explain the motivations behind the extent catalog, by the way -- this information seems to be missing in zc.catalog. Am I at all on the right track with my thinking on it? It should be pointed out initially that the son-of-queued-catalog code doesn't have anything to do with extents. I think Jim wants that factored out when we have time so that can be a mix-and-match capability. I think you are asking about extents themselves, though. Okay, I didn't realize yet glancing at this that this is *also* son-of-queued catalog. Interesting. I'll glance at it some more. :) We had three use cases that led us to extents. First, we wanted several catalogs that only indexed certain different things. This could have been done by subscribers, so this wasn't terribly compelling by itself. Okay, this is clear. It's not that clear to me how to efficiently make a subscriber only handle one object type (I've been using the is this a IFoo? If not, return pattern at the start of subscribers), but that's another discussion. Second, we wanted to transparently support queries that merged results across catalog-like data structures. The catalog defined the items we wanted to search through, while some of the other data structures kept track of a larger set of objects (subsuming the set that the catalog cared about). Sometimes, users could perform a query that didn't actually use any of the catalog's data structures, but that should be filtered by the set of the catalog's objects--its extent. I'm not sure I comprehend the motivations behind this one. Could you elaborate? Third, we wanted to let our indexes data be usable for NOT queries. In order to do that, we needed an IFBTree structure that describes the complete set for a given catalog, so that a contained index can simply (and reasonably efficiently) subtract the query result from the full set. The indexes in zc.catalog also use extents for some other similar tricks. This one's also clear. An extent that accepts all objects would effectively be the data structure you want, as I understand it. I'm not sure -- 'not' is indeed context dependent, so which extent is in use to determine the results of a 'not' operation depends on the query. I think it's okay to ask the users to explicitly specify the extent when they're doing the query, as long as there's an easy way to construct it for the simple cases. It is actually (at least typically for us) different than the intid mapping because there are several classes of things that have intids that are not cataloged. If more than one catalog all index the same objects, I'd first wonder why the indexes were not all in the same catalog; Good question. I think one example of such a scenario is if you wrote a codebase, and I extended this codebase with some adapters which carry around information I also want indexed. I may decide not to introduce new indexes into your catalog but instead produce my own catalog to have the concerns separate from each other. In this case I'd want to do queries over multiple catalogs which index the same objects. I'd second say that yes, they probably could share a filter-less extent. Why filter-less? I mean, wouldn't you want to filter on object type? If we want any of zc.catalog in the Zope core, each component will certainly need a proposal, by the way: we're offering this as code that has helped us out and that we think might help others, either directly or as ideas, so we are not duplicating effort. We're not proclaiming it to necessarily be our next core step. Understood. I'm giving you feedback. :) We (Infrae) are going to put some code online eventually that we produced in the project we're working on, for the same reasons. 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] catalog 'all documents' abstraction
On Wednesday 31 August 2005 05:41, Martijn Faassen wrote: Okay, this is clear. It's not that clear to me how to efficiently make a subscriber only handle one object type (I've been using the is this a IFoo? If not, return pattern at the start of subscribers), but that's another discussion. The better pattern is: Have a subscriber to your event E that sends out another event notification for (E, E.obj). Then you have many subscribers to the latter pair. Note that we are already doing this for object events. Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] how-to fool XML-RPC publisher
On Tuesday 30 August 2005 11:55, Adam Groszer wrote: Is there any way to fool the Z3 XML-RPC publisher to unmarshall strings *always* as unicode? I think the problem is that xmlrpclib tries to convert all strings to str, but in Z3, all strings should be stored as unicode. Even better that zope.schema enforces unicode also. So my exposed methods would start with converting all necessary parameters to unicode. If this is not done, I would consider it even to be a Zope 3 bug. Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] how-to fool XML-RPC publisher
On Tuesday 30 August 2005 11:55, Adam Groszer wrote: Is there any way to fool the Z3 XML-RPC publisher to unmarshall strings *always* as unicode? I think the problem is that xmlrpclib tries to convert all strings to str, but in Z3, all strings should be stored as unicode. Even better that zope.schema enforces unicode also. So my exposed methods would start with converting all necessary parameters to unicode. Darn, I pressed send to fast. I think you can register custom objects to unmarshall the data. This custom object could handle the unicode issue for you (I have not tried this yet though). Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] XML header and TAL interpretor
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi there, I got a problem with the standard macros use and the XML header. I've a view defined like the one below : ?xml version=1.0 encoding=UTF-8? html xmlns:tal=http://xml.zope.org/namespaces/tal; xmlns:metal=http://xml.zope.org/namespaces/metal; body metal:use-macro=context/@@standard_macros/page !-- content -- /body /html And there, I got the following error when Zope's trying to render it : - - 2005-08-31T13:21:56 ERROR SiteError http://localhost:8080/+/addBar.html%3Dbar Traceback (most recent call last): File /home/zopes/Zope-3_ECM/src/zope/publisher/publish.py, line 138, in publish result = publication.callObject(request, object) File /home/zopes/Zope-3_ECM/src/zope/app/publication/zopepublication.py, line 164, in callObject return mapply(ob, request.getPositionalArguments(), request) File /home/zopes/Zope-3_ECM/src/zope/publisher/publish.py, line 113, in mapply return debug_call(object, args) File /home/zopes/Zope-3_ECM/src/zope/publisher/publish.py, line 119, in debug_call return object(*args) File /home/zopes/Zope-3_ECM/src/zope/app/pagetemplate/simpleviewclass.py, line 44, in __call__ return self.index(*args, **kw) File /home/zopes/Zope-3_ECM/src/zope/app/pagetemplate/viewpagetemplatefile.py, line 83, in __call__ return self.im_func(im_self, *args, **kw) File /home/zopes/Zope-3_ECM/src/zope/app/pagetemplate/viewpagetemplatefile.py, line 51, in __call__ sourceAnnotations=getattr(debug_flags, 'sourceAnnotations', 0), File /home/zopes/Zope-3_ECM/src/zope/pagetemplate/pagetemplate.py, line 117, in pt_render strictinsert=0, sourceAnnotations=sourceAnnotations)() File /home/zopes/Zope-3_ECM/src/zope/tal/talinterpreter.py, line 270, in __call__ self.interpret(self.program) File /home/zopes/Zope-3_ECM/src/zope/tal/talinterpreter.py, line 345, in interpret handlers[opcode](self, args) File /home/zopes/Zope-3_ECM/src/zope/tal/talinterpreter.py, line 887, in do_useMacro (`macroName`, `mode`), self.position) METALError: macro u'context/@@standard_macros/page' has incompatible mode 'html', at line 6, column 3 If I remove the xml header the error disappears. It's really a huge problem because it means Zope3 'as it' can't render valid XML pages with standard macros... Any idea how to fix thix problem without having to rewrite the standard macros ? My use case is the inclusion of XForms within the Page Template and the mozilla plugin requires the page to be XML valid and thus to have the xml header. Any hints welcome. J. - -- Julien Anguenot | Nuxeo RD (Paris, France) CPS Platform : http://www.cps-project.org Zope3 / ECM : http://www.z3lab.org mail: anguenot at nuxeo.com; tel: +33 (0) 6 72 57 57 66 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFDFZaDGhoG8MxZ/pIRAm9YAJ4uVr/IrXuVeRr1jlVyU4RQJ+IzIgCfQrRF gH79PuOE0yu2qppa+xykwUE= =XWiD -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: XML header and TAL interpretor
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Philipp von Weitershausen wrote: Julien Anguenot wrote: I got a problem with the standard macros use and the XML header. I've a view defined like the one below : ?xml version=1.0 encoding=UTF-8? html xmlns:tal=http://xml.zope.org/namespaces/tal; xmlns:metal=http://xml.zope.org/namespaces/metal; body metal:use-macro=context/@@standard_macros/page !-- content -- /body /html And there, I got the following error when Zope's trying to render it : [snip] (`macroName`, `mode`), self.position) METALError: macro u'context/@@standard_macros/page' has incompatible mode 'html', at line 6, column 3 If I remove the xml header the error disappears. It sucks, don't it? big time yeah... It's really a huge problem because it means Zope3 'as it' can't render valid XML pages with standard macros... Any idea how to fix thix problem without having to rewrite the standard macros ? My use case is the inclusion of XForms within the Page Template and the mozilla plugin requires the page to be XML valid and thus to have the xml header. Any hints welcome. [...] So, instead of proposing to radically get rid of HTML4 mode, I propose this: - XML mode of ZPT becomes the standard mode. +1 - We keep HTML4 mode around as long people need it, but it's not the standard mode. The switch whether to use XML or HTML4 mode is done via ZCML and not some sniffing in the PageTemplate contents. I don't have any opinion on this. Yes, I realize that this will suddenly introduce the requirement that all templates need to carry namespace declarations. That's not a problem. I think that's a good thing. They're not dead chickens. Namespace declarations are meaningful and useful and they're what XML-capable people and tools are used to. To sum it up: it's the spec. I've always found it much harder to explain why Zope wouldn't support the spec in this or that particular case than just sticking with the spec in such cases. clearly. I would be willing to work this out as a full-blown proposal together with Julien. great ! J. - -- Julien Anguenot | Nuxeo RD (Paris, France) CPS Platform : http://www.cps-project.org Zope3 / ECM : http://www.z3lab.org mail: anguenot at nuxeo.com; tel: +33 (0) 6 72 57 57 66 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFDFakfGhoG8MxZ/pIRAmJ9AJ47mCTNwIBx62Vq0hekv4kB/WAa6ACeLhoh svXXo+MgmusOVhrFmmIiblM= =K9kd -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: XML header and TAL interpretor
Julien Anguenot wrote: Ok the problem is the doctype declaration on top of the macro files that force the tal interpretor to enter html mode and as far as I understand you can't have mix moded macros. Exactly. I forgot to mention that in my follow-up... Btw, doctype declaration is something else. You probably just mean the XML processing instruction. If you change the doctype declaration with the xml header and add the xmlns declaration for tal, metal and i18n then everything's fine after. See for instance the navigation macros : http://svn.zope.org/Zope3/trunk/src/zope/app/rotterdam/navigation_macros.pt?rev=28163view=auto If you change the header like this then it can be succesfully included : ?xml version=1.0 encoding=UTF-8? html xmlns=http://www.w3.org/1999/xhtml; xmlns:tal=http://xml.zope.org/namespaces/tal; xmlns:metal=http://xml.zope.org/namespaces/metal; xmlns:i18n=http://xml.zope.org/namespaces/i18n; i18n:domain=zope body What kind of issue could we have changing the headers like this on all the standard macros since it's xhtml already ? I'm not sure if this is a good idea. Because once Zope3's macros are XML mode, all other templates using those macros need to be XML mode. That, in turn, means that all templates need to carry the ?xml ...? processing instruction because that's the only way XML mode is currently triggered. Since that processing instruction is optional (as opposed to namespace declarations which are mandatory), I wouldn't want to force it on template authors. I would think changing the headers like the above AND changing the default mode to XML mode at the same time would probably be more appropriate because it would only introduce one upgrade hurdle (the mandatory namespace declarations). Philipp ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] catalog 'all documents' abstraction
Martijn Faassen wrote: Gary Poster wrote: On Aug 30, 2005, at 1:57 PM, Martijn Faassen wrote: [snip] It would be helpful if someone could explain the motivations behind the extent catalog, by the way -- this information seems to be missing in zc.catalog. Am I at all on the right track with my thinking on it? It should be pointed out initially that the son-of-queued-catalog code doesn't have anything to do with extents. I think Jim wants that factored out when we have time so that can be a mix-and-match capability. I think you are asking about extents themselves, though. Okay, I didn't realize yet glancing at this that this is *also* son-of-queued catalog. Interesting. I'll glance at it some more. :) Actually, it isn't. I should have thought to menion this earlier. This code just provides a within-transaction queue, so that multiple modifications to an object within a transaction cause only one indexing operation. Queued catalog uses a persistent queue to allow a separate dedicated thread to do indexing to reduce conflicts and to provide greater aggregation of index operations to reduce database writes. Queued catalog needs to be ported still. It *also* needs some repair to a bug in it's queue conflict-resolution algorithm to improve it's effectiveness. Tests wouldn't hurt either. :) 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
Re: [Zope3-dev] security problems with database adapters (second edition)
Velko Ivanov wrote: Dmitry Vasiliev wrote: Maybe we need always check security map at the root folder? I don't believe this is the solution. Altrough it will solve my example, it wouldn't help in other scenarios. I would eventually make ZopeConnection and ZopeCursor locatable, if they aren't already, and assign the database adapter as the parent of the connection and the connection to the cursor at the time of their creation. Actually I'm going to patch it like that right away. ZopeConnection and ZopeCursor not only an objects without an location, see for example '/++etc++process' so I think it is the UI grant tool problem. I'll post an issue to the collector. One last question, to clear things a bit for me, as I don't have a Zope3 copy here to try - Imagine the user accesses some python class by the means of submiting a form and that class needs to do some work with the database, so it obtains a database connection, creates a cursor and executes some queries. In this case, will the class access the connection with the user's privileges, or is it trusted ? If it is trusted, my problem here is not of so big importance, but if not, I imagine zope.app.rdb needs some urgent updates. I don't believe that I'm currently fully understand whole Z3's security system, :-) but I think you can manage access rights through 'permission' attribute of the form's ZCML directive. For instance in one of my projects there is a pages which use a database connection with 'zope.Public' and 'zope.ManageContent' permissions. -- Dmitry Vasiliev (dima at hlabs.spb.ru) http://hlabs.spb.ru ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: XML header and TAL interpretor
On Wed, Aug 31, 2005 at 03:54:45PM +0200, Philipp von Weitershausen wrote: | Julien Anguenot wrote: [...] | If you change the header like this then it can be succesfully included : | | ?xml version=1.0 encoding=UTF-8? | html xmlns=http://www.w3.org/1999/xhtml; |xmlns:tal=http://xml.zope.org/namespaces/tal; |xmlns:metal=http://xml.zope.org/namespaces/metal; |xmlns:i18n=http://xml.zope.org/namespaces/i18n; |i18n:domain=zope | body | | What kind of issue could we have changing the headers like this on all | the standard macros since it's xhtml already ? | | I'm not sure if this is a good idea. Because once Zope3's macros are XML | mode, all other templates using those macros need to be XML mode. That, | in turn, means that all templates need to carry the ?xml ...? | processing instruction because that's the only way XML mode is currently | triggered. Since that processing instruction is optional (as opposed to | namespace declarations which are mandatory), I wouldn't want to force it | on template authors. Don't forget that IE will then have an insane tendency to render the pages wrong. I don't recall all of the details, but it was something like if the document began with ?xml ? IE would switch to quirks mode and do funny things with boxes, margins, and the overall layout. The details are in this list's archives (if they aren't it's in the zope@zope.org list archives). (not that I'm a fan of IE, but I do recall that being a problem for some people) -D -- He is no fool who gives up what he cannot keep to gain what he cannot lose. --Jim Elliot www: http://dman13.dyndns.org/~dman/jabber: [EMAIL PROTECTED] signature.asc Description: Digital signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: XML header and TAL interpretor
On Wed, Aug 31, 2005 at 02:48:11PM +0200, Philipp von Weitershausen wrote: [...] | PageTemplates know two different modes, HTML4 mode and XML mode: [...] | So, instead of proposing to radically get rid of HTML4 mode, I propose this: | | - XML mode of ZPT becomes the standard mode. | | - We keep HTML4 mode around as long people need it, but it's not the | standard mode. The switch whether to use XML or HTML4 mode is done via | ZCML and not some sniffing in the PageTemplate contents. +1 | Yes, I realize that this will suddenly introduce the requirement that | all templates need to carry namespace declarations. I think that's a | good thing. They're not dead chickens. Namespace declarations are | meaningful and useful and they're what XML-capable people and tools are | used to. To sum it up: it's the spec. I've always found it much harder | to explain why Zope wouldn't support the spec in this or that particular | case than just sticking with the spec in such cases. I'm all too familiar with arguments of this form (but the spec says to do it that way and we aren't). I, for one, am almost always in favor of adhering to specifications and doing things right. I think it would be beneficial to encourage the use of XHTML this way. -D -- [Perl] combines all the worst aspects of C and Lisp: a billion different sublanguages in one monolithic executable. It combines the power of C with the readability of PostScript. -- Jamie Zawinski www: http://dman13.dyndns.org/~dman/jabber: [EMAIL PROTECTED] signature.asc Description: Digital signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: XML header and TAL interpretor
On Wednesday 31 August 2005 10:05, Julien Anguenot wrote: Don't forget that IE will then have an insane tendency to render the pages wrong. I don't recall all of the details, but it was something like if the document began with ?xml ? IE would switch to quirks mode and do funny things with boxes, margins, and the overall layout. The details are in this list's archives (if they aren't it's in the zope@zope.org list archives). (not that I'm a fan of IE, but I do recall that being a problem for some people) Having IE full of bugs is not a reason to not support standards such as the xml processing instruction (which makes a document *not* XML valid if it's not present on top of the document) We'll think about buggy browsers in a second step ;) If there is an IE issue it needs to be addressed and a solution be found before any action can be taken. IE still has the majority market share and we cannot be ignorant about it. Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] catalog 'all documents' abstraction
On Aug 31, 2005, at 5:41 AM, Martijn Faassen wrote: Gary Poster wrote: On Aug 30, 2005, at 1:57 PM, Martijn Faassen wrote: [snip] It would be helpful if someone could explain the motivations behind the extent catalog, by the way -- this information seems to be missing in zc.catalog. Am I at all on the right track with my thinking on it? It should be pointed out initially that the son-of-queued-catalog code doesn't have anything to do with extents. I think Jim wants that factored out when we have time so that can be a mix-and-match capability. I think you are asking about extents themselves, though. Okay, I didn't realize yet glancing at this that this is *also* son-of-queued catalog. Interesting. I'll glance at it some more. :) As Jim said, characterizing it as son of queued catalog is perhaps hyperbole. Maybe a queued catalog that is easier to set up and helpful but not as effective as the Zope 2 queued catalog or simply nephew of queued catalog would have been better. :-) We had three use cases that led us to extents. First, we wanted several catalogs that only indexed certain different things. This could have been done by subscribers, so this wasn't terribly compelling by itself. Okay, this is clear. It's not that clear to me how to efficiently make a subscriber only handle one object type (I've been using the is this a IFoo? If not, return pattern at the start of subscribers), but that's another discussion. Stephan replied to this. Interestingly, because catalogs forward their indexing requests to the contained indexes, they act a bit like an event channel, even though the event itself is no longer part of the communication. Therefore the extent catalog's approach is still reasonably efficient, without an intermediate filtering subscriber, as long as you don't need the filtering subscriber to ping any other components too. Second, we wanted to transparently support queries that merged results across catalog-like data structures. The catalog defined the items we wanted to search through, while some of the other data structures kept track of a larger set of objects (subsuming the set that the catalog cared about). Sometimes, users could perform a query that didn't actually use any of the catalog's data structures, but that should be filtered by the set of the catalog's objects--its extent. I'm not sure I comprehend the motivations behind this one. Could you elaborate? Sure. What I'm about to describe wasn't our exact use case, but is a reasonable example, I hope. Imagine you have a two components: one that keeps track of how often an object is viewed, and a catalog. The view tracker might use intids, but because of ConflictError problems with write-on-read, you probably wouldn't want to store the data in the ZODB; moreover, it is not an index. It's a separate component. Further, imagine that the view tracker keeps track of more objects than your catalog does (maybe you have multiple catalogs, maybe the view tracker has responsibilties for non-content objects). Now you are building a search form for your content objects. You don't want your user to be aware of the separation of responsibilities in your design: you want to let the user say things like show me all the content objects Martijn created that have been viewed more than 100 times or something like that. That's a catalog query intersected with a view tracker query: no extent needed. You also want to let the user say show me all the content objects that have been viewed more than 100 times. The content objects set is defined by the catalog: it's the set you are searching through. But the view tracker doesn't have any concept of that set--it has its own larger responsibilities. Enter extent, stage right. The catalog's extent can be intersected with the view tracker results, and the user gets the expected results. End example. The view tracker is of a class of components that can generate results that might need to be transparently merged with cataloged objects, sometimes when there is no catalog query. Extents are a solution to the part of the story when you have no catalog query. Third, we wanted to let our indexes data be usable for NOT queries. In order to do that, we needed an IFBTree structure that describes the complete set for a given catalog, so that a contained index can simply (and reasonably efficiently) subtract the query result from the full set. The indexes in zc.catalog also use extents for some other similar tricks. This one's also clear. An extent that accepts all objects would effectively be the data structure you want, as I understand it. I'm not sure -- 'not' is indeed context dependent, so which extent is in use to determine the results of a 'not' operation depends on the query. I think it's okay to ask the users to explicitly specify the extent when they're doing the
Re: [Zope3-dev] Re: XML header and TAL interpretor
On Aug 31, 2005, at 10:46 AM, Stephan Richter wrote: On Wednesday 31 August 2005 10:05, Julien Anguenot wrote: Don't forget that IE will then have an insane tendency to render the pages wrong. I don't recall all of the details, but it was something like if the document began with ?xml ? IE would switch to quirks mode and do funny things with boxes, margins, and the overall layout. The details are in this list's archives (if they aren't it's in the zope@zope.org list archives). (not that I'm a fan of IE, but I do recall that being a problem for some people) Having IE full of bugs is not a reason to not support standards such as the xml processing instruction (which makes a document *not* XML valid if it's not present on top of the document) We'll think about buggy browsers in a second step ;) If there is an IE issue it needs to be addressed and a solution be found before any action can be taken. IE still has the majority market share and we cannot be ignorant about it. +1 Gary ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re[2]: [Zope3-dev] how-to fool XML-RPC publisher
Hello Stephan, Sorry, I'm a newbie regarding that. As I checked there is a zope.publisher.xmlrpc.premarshal_dispatch_table dict, but this is for the response. The request is handled 'directly' by xmlrpclib self._args, function = xmlrpclib.loads(self._body_instream.read()) Can you please give a hint where to look? Wednesday, August 31, 2005, 12:24:53 PM, you wrote: SR On Tuesday 30 August 2005 11:55, Adam Groszer wrote: Is there any way to fool the Z3 XML-RPC publisher to unmarshall strings *always* as unicode? I think the problem is that xmlrpclib tries to convert all strings to str, but in Z3, all strings should be stored as unicode. Even better that zope.schema enforces unicode also. So my exposed methods would start with converting all necessary parameters to unicode. SR Darn, I pressed send to fast. I think you can register custom objects to SR unmarshall the data. This custom object could handle the unicode issue for SR you (I have not tried this yet though). SR Regards, SR Stephan SR -- SR Stephan Richter SR CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) SR Web2k - Web Software Design, Development and Training -- Best regards, Groszer Adam -- Quote of the day: If passion drives you, let reason hold the reigns. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Atomic reads w ZEO and ZODB
I'm exploring moving our job queue system into z3. But, I'm running into a conceptual problem. As I envision it, I'd have three zope zeo clients working to get the job done. One is the queue manager taking submissions and reporting on the status of current jobs. Another is a queue worker which walks the job through it's workflow. These jobs are usually reports which take from 1 to 120 seconds to build and 50k to 500k in size. The third process is a job delivery service which takes the completed report and delivers it via smtp or via http using a page template. A squid proxy server hides the fact that the job manager and job delivery component are served from different processes (ie different ports). Here's my question: I know how the zodb prevents inconsistent writes using ConflictErrors. But, I'm fuzzy on how the zodb prevents inconsistent reads. The reason I'm concerned is the job objects are polled by the queue manager on behalf of the client's browser (using a AJAX style javascript function). During this time a queue worker will be changing the object according to the workflow. Can ZEO and ZODB handle this kind of reading in an atomic fashion? Also, consistent reads would be key for more than one worker to cooperate on a job. Thanks, in advance, for educating me, David Huttleston Jr ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: XML header and TAL interpretor
On Wed, Aug 31, 2005 at 10:46:34AM -0400, Stephan Richter wrote: | On Wednesday 31 August 2005 10:05, Julien Anguenot wrote: | Don't forget that IE will then have an insane tendency to render the | pages wrong. I don't recall all of the details, but it was something | like if the document began with ?xml ? IE would switch to quirks | mode and do funny things with boxes, margins, and the overall layout. | The details are in this list's archives (if they aren't it's in the | zope@zope.org list archives). | | (not that I'm a fan of IE, but I do recall that being a problem for | some people) | | Having IE full of bugs is not a reason to not support standards such as | the xml processing instruction (which makes a document *not* XML valid | if it's not present on top of the document) | | We'll think about buggy browsers in a second step ;) | | If there is an IE issue it needs to be addressed and a solution be found | before any action can be taken. Ok, here you go: http://mail.zope.org/pipermail/zope3-dev/2005-July/014924.html http://mail.zope.org/pipermail/zope3-dev/2005-July/014911.html | IE still has the majority market share and we cannot be ignorant | about it. Yeah. I never deal with it though, fortunately. -D -- A violent man entices his neighbor and leads him down a path that is not good. Proverbs 16:29 www: http://dman13.dyndns.org/~dman/jabber: [EMAIL PROTECTED] signature.asc Description: Digital signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Resource Library Proposal
I've added a proposal for Zope 3.2. Read at http://www.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/ResourceLibrary. WARNING: zope.org exhibiting some serious caching strangeness, so please comment on the list instead of the wiki. -- 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] [DRAFT] local portlets and perspectives
Jean-Marc Orliaguet wrote: ... - this portlet uses this style not for a *class* of portlets, but for *instances* of classes. Adapters connect interfaces, not instances. Then why not just store the style in the portlet? Again you are making the assumption that a portlet *has* a style. If the portlet is rendered in RSS it has no style ... You clarified this later in the earlier message. I should have moddified my question a bit. Also this is as bad as storing browser view related attributes in a content class - otherwise we are back to the Zope2 old days, where every possible attribute was stored on the objects themselves. There are advantages in storing data on the object, if you can do it in a controlled way. I understand and agree that you don't want the implementation of portlets to know about (depend on) styles. Zope 3 provides a mechanism, annotations, for storing data on an object without affecting the object's implementation. Then OK: if you store the style attribute on the portlet itself, I suppose that this information will be indexed and cataloged. In what way is it different from having a separate relation store that does not duplicate information? Why would it be indexed? Why would I advocate one centralized storage scheme over another? I don't like centralized data structures. They are necessary sometimes. Honestly, Zope3 makes some sort of schizofrenic separation between content and view, in a way that you sometimes cannot get access to the request object because you haven't adapted (context, request). I don't really understand what you are objecting to. Requests are necessary for user interaction. Why should anything but presentation code have access to the request? We obtain presentation code by adapting the request. Why would you want the request elsewhere? How is this schizophrenic? the Zope3 philosophy has to be coherent: if you create a waterproof separation between components, then having a waterproof separation between content elements, i.e. portlets / widgets / styles / layout / visibility options / caching parameters is just as important. Agreed. I'm slowly getting an inkling of what your architecture is and is trying to achiev. As I learn more, I'm liking many aspects. to sum up: for exactly the same reason as why Zope2 moved to a component-based architecture, but for the content this time. I want to be able to connect content objects (portlets, styles, widgets, layouts) in a flexible way. and by the way it works, so why explain why you need something when it works as expected? Because to decide if I want to use it, I need to evaluate the architecture: - I need to know if there are hidden costs that aren't apparent in demos and small scale. Your solution requires a potentially large centralized indexing structure. I don't like large centralized indexing structures. They are necessary sometimes, but I don't want to use them if I can avoid it. I don't know about yours, We don't have anything that does exactly what your system does (assuming that I know what your system does ;). But we've faced similar sorts of design decisions. but I guess that you will store all the information in the portal catalog? what is the difference? I wasn't suggesting storing anything in the catalog. I was suggesting storing data on the objects. - Your system defines a framework that I'll need to understand if we want to use it. I need to understand if developers will find it easy to use the number one target audience is end-users, and application developers. These are two audiences. Are these number one and number two? I suggest you have a number of audiences: - site designers - application developers - content managers (who you call end users). The Zope2 version is already appealing to both users and developers. Cool. I'm a developer and after all this discussion, I have only a loose grasp on what you are trying to do. I think you've indicated that the system you're describing me has evolved from the Zope 3 version. At the university we can't afford to create a product that only developers understand. Content creators, graphic designers don't think as developers, they see things differently and this is what I'm trying to integrate into cpsskins, i.e. *their* knowledge. Great. BTW I'm still unclear whether you are still trying to satisfy the use case of allowing portlet assignments by folder with aggregation along a folder path. I thought you said yes, but it sounded that was not done when you supported perspectives. Do you support by-folder and by-perspective portlet assignment at the same time? How have you addressed the confusion that arises when a user adds a portlet to a page in a folder and it appears on subfolder pages as well? if other combinations of filters are used (a RSS filter for instance), the same data is displayed in RSS instead of HTML. Why would you want to generate RSS in a portlet?
Re: [Zope3-dev] Re: [Z3lab] Why use relations?
Jean-Marc Orliaguet wrote: Janko Hauser wrote: Am 31.08.2005 um 10:25 schrieb Jean-Marc Orliaguet: Hi ! I have been thinking about Jim's question: why do you need relations?. Some obvious answers came first others emerged later on, now I think that most of them are emerged, so I'll try to summarize them by order of importance (to me): I'm in support of most of your points, although I do not see that the catalog is actually proposed as an alternative. Jim's suggestions were more directed to store things in each other. Or reference them somehow, but not by an indirection with a central index. Thanks Janko. :) My intuition is that if you store things in each other you have implicitly created an index as soon as the objects get cataloged. I don't see how. You only have indexes for the information that gets cataloged. Janko summarized my position very well. I'll note that I'm not opposed to relations. I'm not even opposed to a centralized store for relations. I am inclined to limit their use to where they are needed and in leveraging the component architecture to make it easy to change one's mind. 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
Re: [Zope3-dev] [DRAFT] local portlets and perspectives
Jim Fulton wrote: Jean-Marc Orliaguet wrote: ... Also this is as bad as storing browser view related attributes in a content class - otherwise we are back to the Zope2 old days, where every possible attribute was stored on the objects themselves. There are advantages in storing data on the object, if you can do it in a controlled way. I understand and agree that you don't want the implementation of portlets to know about (depend on) styles. Zope 3 provides a mechanism, annotations, for storing data on an object without affecting the object's implementation. here is the use case: - the style of portlets located in slots is associated to the slot (not to the portlets). Why? because content creators focus on content not on CSS styles, when they add a portlet into a slot someone else has already designed the style for the portlet. - the same goes with widgets (the actual presentation of portlets) here is an animation that demonstrates the idea: http://www.z3lab.org/sections/front-page/design-features/slot-formats - the default behaviour for portlets is to inherit formats (styles, widgets, etc) from the slots. - it means that slots (not portlets) should in principle store the format information. - but if you do this (store the style information on slots), there is no way to override slot styles in some given context or perspective only. Maybe you want your end-users to be able to customize the color of the boxes? If you store the information in the slot, there is no way to display portlet boxes in a slightly different way (e.g. add min/max buttons on boxes) - so basically if you store some style information on some given content class (portlet, slot, ...) you will already have shot yourself in the foot, after the third use case only:-) This is why cpsskins uses the notion of display, which is an object that stores all format information (style, widget presentation, visibility, ...) Different displays can be associated to a same slot or a same portlet. Then OK: if you store the style attribute on the portlet itself, I suppose that this information will be indexed and cataloged. In what way is it different from having a separate relation store that does not duplicate information? Why would it be indexed? Why would I advocate one centralized storage scheme over another? I don't like centralized data structures. They are necessary sometimes. do you mean that all information is stored on objects and that you don't index the information in any catalog to get access to it fast? how many pages per second can you render? Honestly, Zope3 makes some sort of schizofrenic separation between content and view, in a way that you sometimes cannot get access to the request object because you haven't adapted (context, request). I don't really understand what you are objecting to. Requests are necessary for user interaction. Why should anything but presentation code have access to the request? We obtain presentation code by adapting the request. Why would you want the request elsewhere? How is this schizophrenic? This could be the subject of another thread, but basically I end up in some cases having to pass the request object to methods (as in Zope2) because the code is neither 100% presentation nor pure content. Maybe I'm doing things in the wrong way ... I need to implement a Read / Write containers (slots) that since that are Containers know nothing about requests, but also need to get some information stored in the request to decide how to store the information. .. the Zope3 philosophy has to be coherent: if you create a waterproof separation between components, then having a waterproof separation between content elements, i.e. portlets / widgets / styles / layout / visibility options / caching parameters is just as important. Agreed. I'm slowly getting an inkling of what your architecture is and is trying to achiev. As I learn more, I'm liking many aspects. to sum up: for exactly the same reason as why Zope2 moved to a component-based architecture, but for the content this time. I want to be able to connect content objects (portlets, styles, widgets, layouts) in a flexible way. and by the way it works, so why explain why you need something when it works as expected? Because to decide if I want to use it, I need to evaluate the architecture: - I need to know if there are hidden costs that aren't apparent in demos and small scale. Your solution requires a potentially large centralized indexing structure. I don't like large centralized indexing structures. They are necessary sometimes, but I don't want to use them if I can avoid it. I don't know about yours, We don't have anything that does exactly what your system does (assuming that I know what your system does ;). But we've faced similar sorts of design decisions. I'm really interesting in learning about your use cases, because it could be that you have use cases that
Re: [Zope3-dev] Re: RDFLib and Zope 3
On Wed, 2005-08-31 at 10:07 -0400, Gary Poster wrote: I'm interested in contemplating RDF as a full catalog solution for Zope, at least as a thought experiment. Great! Note that the use of bound variables also removes the need for brains. We actually don't have catalog brains in Zope 3 anyway, but yes, maybe it would let you only wake up objects when you need to, which is what you are getting at. It might make sorting easier too. Need to think this through. Activation is one issue I actually wasn't getting at, but it's definitely something to think about. What I was getting at was that the result is completely unrelated to any object. A ZCatalog result object had the duel role of also being a handle back to the original object (in addition to preventing activation). When I work on these things I tend to disregard the presence of any kind of Python object that the data is associated with. I think though that we are well on our way to coming up with a way to formalize the rdf/object bridge and we'll eventually have the right solution and terminology here. Sure, there are some notes from me on the z3lab site that might be of interest for thinking about zemantic and catalog integration. Could you send a URL? snip I think the RDF spec can be used for interpretation too, given the rich spellings that RDF allows for predicates, and the typing of its nodes. I do think that the RDF component should only deal with RDF, so I agree with your general desire. But RDF is very, very rich: a *lot* of functionality could be in a pure RDF library like RDFlib, including support for predicate constraints and join indexes for instance. That would be useful whatever your RDF use, if you needed efficiency for common searches. Ah I didn't get that you were going for such a full solution until this email. You're right, it's a bold proposal but I think with some more fleshing out it can become reality. This could completely merge the use cases of both rdf graphs and zope catalogs. As Dan is interested in componentizing everything, this is a good oppertunity to think about how to make these changes. The extra RDF features could also be a layer on top of a simpler graph implementation, if that were a desired design. I'm not saying that RDFlib should have all the features, but that a pure-RDF library *could* have all the features. Yep, I'm on your frequency now. I think it's a good idea. -Michel ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Atomic reads w ZEO and ZODB
On Aug 31, 2005, at 12:07 PM, David Huttleston Jr wrote: ... But, I'm fuzzy on how the zodb prevents inconsistent reads. ... Hi David. A quick answer is that the ZODB implements optimistic multi-version concurrency control, similar to the default PostgreSQL behavior. This link describes the proposal, which is pretty close to the way it turned out, as far as I know. http://www.zope.org/Wikis/ZODB/MultiVersionConcurrencyControl Gary ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
