[Zope-dev] Broadtree Catalog?
Chris McDonough wrote: changed on the write. This will be solved by updates to the catalog which use a new "broadtree" BTree implementation. Any idea when this will land? We'ev had to give up on the Catalog for the mailing list archives and go with MySQL's full text indexing :-( cheers, Chris ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] How is 'retrieveItem intended to work with TTW Specialists?
Hello ZPatterns Folk. I'm trying to implement 'delagation' with a custom Specialist. The idea, (I think this is one of the goals of ZPatterns... to allow delegation of responsibility after the Framework is built...) I have: a) MarketItemManager (Python subclass of Specialist) Some of methods, both DTML Methods, and plain old Python Methods, are *meant* to be acquire by the objects (DataSkins) he manages. b) ThingManager (ZClass subclass of Specialist). This is really just a test class that is supposed to represent some later developer integrating my ZPattern based EMarket into their application, (e.g., inventory or whatever...) in MarketItemManager I've defined a 'retrieveItem' (this would really be done by the integrator...) that does something like this: dtml-return "myGreatSite.ThingSpecialist.getItem(key)" with the hope that when the Specialist class gets traversed it will execute: def __bobo_traverse__(self, REQUEST, name): ob = getattr(self, name, _marker) if ob is _marker: ob = self.getItem(name) --- traversal invokes getItem if ob is not None: return ob raise 'NotFound' return ob def getItem(self, key): """Get an item""" if hasattr(self.aq_base,'retrieveItem'): --- getItem invokes retrieveItem return self.retrieveItem(key=key) # XXX need DTML check? for rack in self.rackList: item = rack.__of__(self).getItem(key) if item is not None: return item So my retrieve item gets called. *unfortunately* it gets called without any namespace parameter... so my retrieveItem DTML method has no way to acquire a namespace so that it can delagate to something else! So... here is what I did... I defined a method in my Python subclass of Specialist.. class MarketItemManager(ZPatterns.Specialists.Specialist): """A Market Item Manager""" # Specify a name for the item type: meta_type='MarketItemManager' def retrieveItem(self, key): """ get an item""" return self.__of__(self).delegateRetrieve(self, None, key=key) Then I made a DTML method called 'delegateRetrieve' like so: dtml-return "myGreatSite.ThingManager.getItem(key)" this way, my integrator can edit 'delegateRetrieve' to point to whatever Specialist he wants to... and I have a Python implementation of retrieveItem. Does this sound OK? Am I working way too hard here? (I feel like I am! ;- ) thanks, -steve ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] ZCatalog : UTF-8 Chinese
HI, I have a project which need search with Chinese. I think I can make Zcatalog to search Chinese in utf8. So I change Voodoo Kludge Splitter.py to convert the input string to unicode (assume it is utf8) and make a version of split of my own (see the attached splitter.py). I borrow (stolen) from Interscript the utf8 encoding conversion scheme. I separate the chinese with space by hand hoping the Zcatalog will work. After changing these, I have a catalog which looks good : I can see from the volucably the chinese were actually there (except with some which have html encode like inside the utf8. I generate the search interface, and test it. However, the search of the index terms return nothings. I search most entries found in the vocubalury but none works, those work will return many unwanted results also. What is causing this failure? What I can do to go further? Rgs, Kent Sin - kentsin.weblogs.com kentsin.imeme.net Splitter.py
Re: [Zope-dev] ZCatalog : UTF-8 Chinese
On Mon, 25 Sep 2000, Sin Hang Kin wrote:
I generate the search interface, and test it. However, the search of the
index terms return nothings. I search most entries found in the vocubalury
but none works, those work will return many unwanted results also.
What is causing this failure? What I can do to go further?
It is possible you are having an issue with the way the splitter
is used on the search term input side. Several of us have found
bugs in that area. We've fixed the ones we've found, but there
may be more wry grin.
Run zope in debug mode ("the debugger is your friend" howto), and
watch what UnTextIndex does with the search terms. (Hint: instead
of trying to set breakpoints per the howto, just uncomment the
appropriate calls to the debugger in the UnTextIndex or Lexicon
source file...)
--RDM
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] RE: [Zope-ZEO] Advice
But there are really two ways to do this, either of which is viable. 1. the right way ;-) 2. Code all of your logic using TTW stuff and Zope components. Use the Publisher.Test.test method to call methods of your Zope components in unit tests. Do you really think this is a viable approach for a product with a non-trivial amount of logic? I'm afraid we are getting way off the topic of ZEO here, but... I think this is important, so... [Agreed. Ill CC zope-dev and I suggest we continue there.] Sorry, I phrased my question ambiguously. I meant, do you think a TTW development approach is viable for applications with a non-trivial amount of logic? ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] RE: [Zope-ZEO] Advice
(I took the ZEO mail list out of the loop)... [Agreed. Ill CC zope-dev and I suggest we continue there.] Sorry, I phrased my question ambiguously. I meant, do you think a TTW development approach is viable for applications with a non-trivial amount of logic? Perhaps not. Not yet. For example, we have no equivalent to CVS for objects in the objectbase. This is why filesystem products are so attractive for apps with lots of logic. But combining the two approaches I think can provide you with the best of both worlds. TTW changeability for presentation, and filesystem base classes for traditional development. The ability to test TTW stuff (particularly DTML methods) with ZPublisher.test allows for traditional unit tests. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] Testing Zope applications (was Re: [Zope-ZEO] Advice)
Note that this conversation hasn't had anything to do with ZEO for some time, so I'm moving it over to zope-dev. Toby Dickenson wrote: (snip) I think it is really much easier to use ZPublisher/Test (which is also available as Zope.debug: import Zope Zope.debug(url) This provides a much thinner and more easily controlled environment. ... but not a complete replication of the deployed environment. For example, you cant test RESPONSE.write. This sounds like a bug that needs to be fixed, not a limitation in the approach. Would you mind submitting a collector item on it? From a philosophical point of view, using Zope.debug is wrong because the whole purpose is an integration test of the interactions of your pre-tested components with the Zope environment (depending on the complexity of your glue, you may also think of it as a unit test of that glue). But Zope.debug uses the Zope environment. Unless you consider ZServer a critical part of the Zope environment. It is extremely rare for the difference between something like ZServer and ZPublisher.Test to have any noticable impact on the application behavior. (snip) The key to this is (as always) ensuring that your design process considers the testability of the glue. What do you mean by glue? The layer which allows Zope-ignorant code to be used as a Zope product. ZCatalog.py is an example of glue for Catalog.py. I think that ZPublisher.Test provides a pretty good test harness for anything below the publisher level, such as ZCatalog. (snip) How does this make anything untestable? You certainly can decide correct and incorrect behavior. I think there is much more possibility of problems due to UI changes or dynamism that make analysis of test results difficult. I suspect our difference in opinion is the scope of what we are testing. Is it a bug if a product can be broken by a Manager using the management interface of an instance of a different product? Should this 'bug' be tested for? If so, then a test plan must verify that every dtml-namespace and every acquisition name lookup can never be subverted by an ObjectManager or PropertyManager instance, no matter how the instances are arranged in containers. The alternative is that the Manager take responsibility for not creating any objects with a conflicting name - but who decides which names are disallowed. How do you test that this list is complete? First, as an aside, you can't prove that non-trivial software is correct via testing. :) Second, part of a test is deciding what the interface to the tested software is. One way to limit the scope of testing is to limit the promises made, for example to leave the behavior undefined under some circumstances. I dont see a way to test this constraint, and it has proven impossible to avoid the problems using design rules. I recently checked some of our recent products using strategically placed debugging __getattr__ hooks - with initially horrifying results. It sounds like this is a problem that needs to be addressed. It's not really a testing problem, but an architecture problem I'm not sure exactly what problem you are refering to. It sound's like an issue of depending on a specific acquired name and having the name overridden with something bogus. Is that it? There have been a couple of recent developments that I think could help this: 1. It's much easier than it used to be to name objects using physical paths and converting the physical paths to objects. This would allow you to refer to a particular object using an absolute reference. 2. There will be a new interface in Zope 2.3 that will allow you to prevent a name from being used lower in a containement hierarchy. This change is documented at: http://dev.zope.org/Wikis/DevSite/Proposals/ReplaceableProperty. The work has already been done and checked into CVS. I've asked Shane, the author, to update the interfaces wiki to capture this change. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! Technical Director (888) 344-4332http://www.python.org Digital Creationshttp://www.digicool.com http://www.zope.org Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email address may not be added to any commercial mail list with out my permission. Violation of my privacy with advertising or SPAM will result in a suit for a MINIMUM of $500 damages/incident, $1500 for repeats. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] trapping undo
Is there any way in python to trap the undo event on a document? -- Robin Becker ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] Suggestion for better Zope error response
Suppose you have a simple form like: html form action="http://www.musi-cal.com/search" method="post" City: input name="performers" type="text" Radius: input name="radius:int" type="text" input type="submit" name="submit" value="Search" /form /html and the user submits the form with an invalid input for the radius. Assuming ZServer was not run with -D, other than the standard boilerplate, all the user sees is exceptions.ValueError However, field2int raised ValueError with a string like ValueError: An integer was expected in the value 'wer' Making this available to the user, even in the non-debug case, seems like it would be useful feedback for the user that could help guide them to their mistake. -- Skip Montanaro ([EMAIL PROTECTED]) http://www.mojam.com/ http://www.musi-cal.com/ ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] I feel your Wiki Pain ;-)
Do you feel that weblogs are bad models for debates? I think they're pretty good least-common-denominators. I would probably prefer the kind of annotation-based thing i described in my last message (and began to sketch in the WikiNG proposal) for collaborative generation of documents, but i can see the place for weblogs, just as i can see a place for network chats. With adequate integration of email (for notification and response), i see them as better than just email... I like the email list proposal of Martijn Faassen earlier on this list. I added some comments to the Wiki discussion page, where someone proposed using XML for Wikis: I agree with Peter that the proposal is practically shouting XML all over the place. In a Zopish way this would mean dividing up a Wiki page in different objects (say Topics or Paragraphs or whatever). So a Wiki page would become an XML document, consisting of Wiki node documents. The advantage is that this would allow for a presentation in the form of - one or several continuous pages as in the OFWikis (OF=Old Fashioned as opposed to NG). - a presentation with 'folded' nodes (like in a folding editor) - a threaded discussion a la S[qu|w]ishdot or the Discussable thingy - an XML document (for who would want it) The editing could be in the form of Martijn Faassens XML Widgets editor: put a node point in front of a 'discussable' node, promote that one to the top when the 'node point' is clicked on and allow for editing. An example below, in which the o stands for an editable (=clickable) node point (for wiki reasons I have not put blank lines between them. pre o this is the first editable node (user::time) this is a comment to it (user::time) and another comment to that (user::time) this another one (user::time) more comments o this the second one this one is not editable o this one is (user::time) a commennt to the last node /pre alternate view (in threaded discussion mode - probably know to all): (- is foldable; + is expandable) pre -This is the first editable node + this is a comment to it - this another one - and another one to that - this the second one this one is not editable +this one is /pre another 2 cents Rik ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] How is 'retrieveItem intended to work with TTW Specialists?
At 08:00 AM 9/25/00 -0500, Steve Spicklemire wrote: So my retrieve item gets called. *unfortunately* it gets called without any namespace parameter... so my retrieveItem DTML method has no way to acquire a namespace so that it can delagate to something else! So... here is what I did... I defined a method in my Python subclass of Specialist.. class MarketItemManager(ZPatterns.Specialists.Specialist): """A Market Item Manager""" # Specify a name for the item type: meta_type='MarketItemManager' def retrieveItem(self, key): """ get an item""" return self.__of__(self).delegateRetrieve(self, None, key=key) Then I made a DTML method called 'delegateRetrieve' like so: dtml-return "myGreatSite.ThingManager.getItem(key)" this way, my integrator can edit 'delegateRetrieve' to point to whatever Specialist he wants to... and I have a Python implementation of retrieveItem. Does this sound OK? Am I working way too hard here? (I feel like I am! ;- ) Remember in the code where I have "# XXX DTML check?" That's because I was anticipating your problem, but since I didn't personally need to do what you're doing yet, I didn't implement it. For one thing, I was waiting to see if Zope core method binding would get fixed. Unfortunately, I'm not sure that Zope method binding is going to be available for anything but PythonMethods in 2.3. As of right now, however, you should be able to use a PythonMethod for retrieveItem, rather than a DTML Method, and it should work. In short, even now, delegateRetrieve should not be necessary. You should be able to implement retrieveItem using a PythonMethod or a DTML Document rather than a DTML Method. (I say *should* because I have not tried it personally.) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
