Re: [Zope-dev] Wildcards in TextIndex query. Do they work?
On Thu, 24 May 2001, Michel Pelletier wrote: I don't think you are using a globbing vocabulary. I think I am: print_info(applic.Catalog(word='scripto*')) unsplitted ['scripto*'] unl: ['scripto*'] unq: [104623, 'or', 112198, 'or', 151568] Length: 6 Content: [mybrains instance at 1226d358, mybrains instance at 127bb540, mybrains instance at 12bd8138, mybrains instance at 127bb658, mybrains instance at 1226c620, mybrains instance at 12092eb0] print_info(applic.Catalog(word='(scripto*)')) unsplitted [] unsplitted ['scripto*'] unl: ['scripto*'] unsplitted [] unl: [['scripto*']] unq: ['scripto*'] unq: [['scripto*']] Length: 0 Content: [] the unsplitted, unl and unq are my debug flags, but you can see what happens: without parens the '*' has it's desired effect, with, it doesn't. Got a clue? Is this my bug, or ZCatalog's? ___ 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] What would *you* like to have in PropertyManager and friends?
On Mon, May 28, 2001 at 09:37:21AM +0100, Chris Withers wrote:
Well, a nicer interface for changing them is about all I think they
need.
And sort the marshalling stuff out. It would be nice to actually store
blank
dates and numbers (None should be a valid value for both of them ;-)
That's about all I can see that it needs (probably forgotten something
though :-S)
Blank datesnumbers are important, I don' t know how they could
escape us.
:-)
As for nicer interface... I guess you' ll have to elaborate a
bit ;-)
Well, I think it's manage_changeProperties (nasty name for starters) that
deletes any property you don't include in its arguments, see the interfaces
wiki for details.
How about just replacing it with:
def modifyProperties(**kw)
...where kw is a dictionary mapping property name to property value. If it
property specified in kw didn't exist, it would be created.
Also, on addProperty and modifyProperties, how about making type coersion
happen and raise an exception if it fails?
so, if you did addProperty('test','string',1.234), addProperty would coerse
1.234 into the string '1.234' or raise an UncoercableException if it
couldn't?
Might be nice if the available property types were also documented
somewhere.
Hmm, also, coersion should check that when something is stored as the
'lines' property type, it only accepts a list of strings.
cheers,
Chris
[]s,
|alo
+
--
I say a prayer now our love's departed
That you'll come back to stay
Bring back the perfect day
http://www.laranja.org/mailto:[EMAIL PROTECTED]
pgp key: http://www.laranja.org/pessoal/pgp
Brazil of Darkness (RPG) --- http://www.BroDar.org/
___
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] What would *you* like to have in PropertyManager andfriends?
On Tue, 29 May 2001, Chris Withers wrote: As for nicer interface... I guess you' ll have to elaborate a bit ;-) Well, I think it's manage_changeProperties (nasty name for starters) that deletes any property you don't include in its arguments, see the interfaces wiki for details. Nope, that's manage_editProperties, and it's just that the values get set to '', not that the property is deleted. manage_editProperties is suitable *only* to be called as the action of a web form that edits all the properties. Otherwise you want to use manage_changeProperties. How about just replacing it with: def modifyProperties(**kw) ...where kw is a dictionary mapping property name to property value. If it property specified in kw didn't exist, it would be created. You can already pass manage_changeProperties a dictionary instead of REQUEST, and you can also pass it keyword arguments in addition or instead, which will cause the specified property values to get set. An interface for batch adding fields would be nice, but I would not want automatic property creation in the modify method. --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 )
Re: [Zope-dev] Wildcards in TextIndex query. Do they work?
On Tue, 29 May 2001, Erik Enge wrote: On Thu, 24 May 2001, Michel Pelletier wrote: the unsplitted, unl and unq are my debug flags, but you can see what happens: without parens the '*' has it's desired effect, with, it doesn't. Got a clue? Is this my bug, or ZCatalog's? Must be ZCatalog's. I'm guessing the paren matching takes a different code path that doesn't expand wildcards. -Michel ___ 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] dtml-in batching improved
Hi all, When using batching in dtml-in, why is 'previous-sequence' only defined at the first iteration of the current batch? And why is 'next-sequence' only defined at the last iteration of the current batch? This behaviour makes it difficult to display a batch like this: -- begin sample -- Item N Item N+1 Item N+2 (link to previous items) (link to next items) -- end sample -- Because the code would be something like: -- begin sample -- dtml-in something start=query_start size=3 [do something with sequence-item] dtml-if sequence-end !-- check if last item of batch -- dtml-if previous-sequence (link to previous items) /dtml-if dtml-if next-sequence (link to next items) /dtml-if /dtml-if /dtml-in -- end sample -- However, if your batchsize is larger than 1, 'previous-sequence' will always be untrue at the last item (when sequence-item is true). The only solution would be implement a second dtml-in after the first one purely for displaying the previous link. Also, dtml-in would re-execute your expr (which it does not very efficiently), so if you want to avoid doing the expr twice, you'd have to store it temporarily using dtml-let (or my dtml-set tag ;). The end result would be: -- start sample -- dtml-let foo=expr dtml-in foo start=start_query size=3 [do something with sequence-item] /dtml-in dtml-in foo start=start_query size=3 !-- code below is safe, as the variables are only true at the resp. top and end, though the truly paranoid could check for sequence-start / -end patch #1 below would break such code! -- dtml-if sequence-end dtml-if previous-sequence (link to previous items) /dtml-if dtml-if next-sequence (link to next items) /dtml-if /dtml-if /dtml-in /dtml-let -- end sample -- And at this point I really would start to implement the batching myself in python :) Of course, basically the same applies if you want both the previous/next link at the top of the batch display. (Imagine you want both! :) Either I'm missing something really obvious here, or the patches below make sense. There are two versions: - patch #1: This version fixes the issue above by enabling the values of previous/next-sequence throughout the entire batch (and other related variables as well: X-sequence, X-sequence-start-index, X-sequence-end-index, X-sequence-size) (which may break existing sites), and - patch #2: This version introduces new variablenames, leaving the behaviour of previous/next-sequence. A third alternative would be to only define the variables at the top and bottom of the batch. Both versions fix (I think) a grammatical error. It's up to the DC guys if they feel like incorporating either of these patches in a next release :) patch #1: define variables everywhere in the batch This patch makes sure that the following variables are available through each iteration of dtml-in, for each item. ! This patch may break alot of dtml code !! next-sequence next-sequence-start-index next-sequence-end-index next-sequence-size previous-sequence previous-sequence-start-index previous-sequence-end-index previous-sequence-size -- patch begins here -- *** Zope-2.3.2-orig/lib/python/DocumentTemplate/DT_In.pyFri Apr 13 21:30:38 2001 --- Zope-2.3.2-src/lib/python/DocumentTemplate/DT_In.py Tue May 29 19:52:36 2001*** *** 583,611 for index in range(first,end): # preset kw['previous-sequence']= 0 ! kw['next-sequence']= 0 # now more often defined then previously # ! if index==first or index==last: ! # provide batching information ! if first 0: ! pstart,pend,psize=opt(0,first+overlap, ! sz,orphan,sequence) ! if index==first: kw['previous-sequence']=1 ! kw['previous-sequence-start-index']=pstart-1 ! kw['previous-sequence-end-index']=pend-1 ! kw['previous-sequence-size']=pend+1-pstart ! try: ! # The following line is a sneaky way to ! # test whether there are more items, ! # without actually computing a length: ! sequence[end] ! pstart,pend,psize=opt(end+1-overlap,0, ! sz,orphan,sequence) ! if index==last: kw['next-sequence']=1 ! kw['next-sequence-start-index']=pstart-1 ! kw['next-sequence-end-index']=pend-1 ! kw['next-sequence-size']=pend+1-pstart ! except: pass
[Zope-dev] bug in ZEO-1.0b3
If the ZEO server goes down, the the client no longer tries to keep reconnecting. This appears to be something to do with the __closed attribute in zrpc.py. Is there a page to check the status of bugs in ZEO? When is the next version due out? and will it be a final 1.0 version? thanks -d ___ 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] bug in ZEO-1.0b3
On Tue, 29 May 2001, Dyon Balding wrote: If the ZEO server goes down, the the client no longer tries to keep reconnecting. This appears to be something to do with the __closed attribute in zrpc.py. Is there a page to check the status of bugs in ZEO? When is the next version due out? and will it be a final 1.0 version? Your bug, and these questions are probably best asked on the [EMAIL PROTECTED] list. -Michel ___ 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 )
