- Zope - Zope lists

RE: [Zope] date arithmetic in DTML
by Michel Pelletier 14 Jul '99

14 Jul '99

> -----Original Message----- > From: Joachim Schmitz [mailto:perry@ac-copy.net] > Sent: Tuesday, July 13, 1999 8:07 AM > To: zope(a)zope.org > Subject: [Zope] date arithmetic in DTML > > > > how can I datearithmetic in DTML for example today - 30 days, > to search > for a date in a db, which is not older than today - 30 days. > Where can I > find documentation about it ? >  is 30 days previous today. The DateTime module has many, many options like this. I would suggest looking at: lib/python/DateTime/DateTime.py -Michel > > Gruß > > Joachim Schmitz > > WWW-Consultant > > email: js(a)ac-copy.net > tel: +49-241-89491-0 > fax: +49-241-89491-29 > > > > _______________________________________________ > Zope maillist - Zope(a)zope.org > http://www.zope.org/mailman/listinfo/zope > > (For developer-specific issues, use the companion list, > zope-dev(a)zope.org - http://www.zope.org/mailman/listinfo/zope-dev ) >

4 3

RE: [Zope] Defining variables
by Alexander Staubo 13 Jul '99

13 Jul '99

Sounds good to me. Great, in fact. Bring it on! -- Alexander Staubo http://www.mop.no/~alex/ "He could open a tin of sardines with his teeth, strike a Swan Vestas on his chin, rope steers, drive a steam locomotive and hum all the works of Gilbert and Sullivan without becoming confused or breaking down in tears." --Robert Rankin, _The Book of Ultimate Truths_ >-----Original Message----- >From: Phillip J. Eby [mailto:pje@telecommunity.com] >Sent: 14. juli 1999 01:54 >To: Alexander Staubo; Zope Mailing List (E-mail); 'Brian Lloyd' >Subject: RE: [Zope] Defining variables > > >At 11:54 PM 7/13/99 +0200, Alexander Staubo wrote: >>> Syntacticly, each argument to be evalulated in the head of the let >>> tag must be seperated by a newline. Enclosing an argument in double >>> quotes causes it to be evaluated by the DTML expression machinery. >>> Un-quoted arguments are referenced by name. >> >>Is it just me, or is this newline-separation syntax really crazy? How >>does the "let" tag handle multiline expressions? Why not just use >>commas? It would mean alienating those suckers who actually use commas >>in object ids, but that's not a huge loss. ;-) > >Um, the documentation quoted above is incorrect. I submitted >a patch for >the doc file the other day, but it has not been applied. >Newlines are not >required in order to seperate "let" arguments. The normal >argument parsing >of DocumentTemplate tags applies, except that "let" allows >arguments to be >repeated. I think the person writing the docs just assumed >that newlines >were required because all my examples used newlines and whitespace for >clarity. > > >>Indenting is just part of the reason I think the "let" tag is >>inappropriate here. With the closing tag, that's just seven characters >>less than the REQUEST.set() alternative! Plus line break, that's >>actually five characters gained. Not much typing saved there. >> >> >> >> >>I essentially want something like >> >> >> >> > >I'm planning to write a "set" tag that does exactly this. The >tricky part >is, it'll only be able to be used within the body of a "let" >block, because >it'll need to know what level of the namespace stack it can >safely write >to. It will do exactly what you want as long as there is at >least *one* >containing "let" block somewhere in the DTML namespace stack. >It doesn't >have to be in the same document or method, so long as the document or >method is called from inside a let block somewhere. > >The only other way I see to handle it, is to have >DocumentTemplates add an >extra dictionary to the namespace stack at every level of >calling stack - >which is a heavy overhead to pay for such a feature, >especially for those >who don't use it! The "let" tag has to add a dictionary to >the namespace >stack anyway, and it also has the additional benefit of >precisely scoping >the applicability of the variable assignment. So "set" would never set >anything globally, it would be strictly local to some precisely defined >block. REQUEST.set would still be available for anything that really >needed to be global. To give an example: > > >code... > >more code... > >still more code.. > >etc. > > >As you can see, actually defining the variables in the let tag >itself would >be unnecessary. Although I've also thought it might be cool >to require any >variables you "set" to be defined by the "let", thus allowing >a bit more >safety. > >You see, one of the other tricky things about allowing "set" (in the >general case), is that it breaks the "untrusted code" model of >Zope. If >method 1, written by user A, calls method 2, written by user >B, and method >2 is sneaky and resets a variable used by method 1, then method 2 can >potentially make method 1 do something it ain't supposed to. >(Notice that >setting things in the REQUEST object doesn't have this problem, because >REQUEST is so far down in the namespace stack, AND if you're >trying to be >secure, you'll be wary of anything coming from the REQUEST >object to begin >with.) To make a safe "set" tag that deals with this >situation requires >more internal Zope Zen than I care to learn at this stage of things, >because the stuff I use DocumentTemplates for doesn't use the Zope's >"untrusted code" model. > >But, making "set" only valid inside a "let" block eliminates >that problem, >because you can always wrap a call to untrusted code in >another let block >so any changes it makes will be thrown away. Anyway, that's >what I have in >mind to implement, I'm open to suggestions as to how it might >be done better. >

1 0

RE: [Zope] Re: Zope digest, Vol 1 #186 - 49 msgs
by Alexander Staubo 13 Jul '99

13 Jul '99

[What's this subject line to do with your question?] Sounds like an ideal use of TinyTables if there ever was one. I think performance will be excellent. The alternative, which is likely slightly faster but not quite as elegant in terms of object-orientational succinctness and flexibility, is to write an External Method which returns a Python dictionary of the values you need. Eg., def GetMySelectLists(): return { 'apples': 'oranges', 'pears': 'bananas', [... more items here ...] } -- Alexander Staubo http://www.mop.no/~alex/ "He could open a tin of sardines with his teeth, strike a Swan Vestas on his chin, rope steers, drive a steam locomotive and hum all the works of Gilbert and Sullivan without becoming confused or breaking down in tears." --Robert Rankin, _The Book of Ultimate Truths_ >-----Original Message----- >From: root(a)zope.codeit.com [mailto:root@zope.codeit.com]On Behalf Of >Jason >Sent: 14. juli 1999 00:11 >To: zope(a)zope.org >Subject: [Zope] Re: Zope digest, Vol 1 #186 - 49 msgs > > >Hey Zopesters, > >I have large select lists that I need on my site and I was wondering if >TinyTables is the best way to do an  tag insertion of all the >possible values. It's not quite a uniqueValuesFor situation because >there are some values which we don't want available. The list might be >about 100-200 or so items long. Is that going to be to slow in a >TinyTable? > >All my best, > >Jason Spisak >webmaster(a)mtear.com > >_______________________________________________ >Zope maillist - Zope(a)zope.org >http://www.zope.org/mailman/listinfo/zope > >(For developer-specific issues, use the companion list, >zope-dev(a)zope.org - http://www.zope.org/mailman/listinfo/zope-dev ) >

2 1

RE: [Zope] Defining variables
by Alexander Staubo 13 Jul '99

13 Jul '99

>-----Original Message----- >From: Brian Lloyd [mailto:Brian@digicool.com] >Sent: 13. juli 1999 23:47 >To: 'Alexander Staubo'; Zope Mailing List (E-mail) >Subject: RE: [Zope] Defining variables > > >> Currently we have REQUEST.set(). This is nice, but I think there is a >> need for a general-purpose variable namespace that isn't related to >> REQUEST (plus the fact that typing "REQUEST.set(...)" all the >> time isn't >> so cool). >> >> I have one specific case where it's simply arduous having to mix real >> REQUEST variables -- meaning those that come in through the >> query string >> or form data -- with actual request-related variables. >> >> How about adding something like _.set()? >> >> -- >> Alexander Staubo > > >Doesn't the Let tag basically accomplish what you are >asking for? From the Let tag docs: The problem is that the let and with tags are block tags. If I have numerous variables, that's a lot of blocks! Eg.,    ...    (And no, you can't convince to stop indenting. :-) Indenting is just part of the reason I think the "let" tag is inappropriate here. With the closing tag, that's just seven characters less than the REQUEST.set() alternative! Plus line break, that's actually five characters gained. Not much typing saved there.   I essentially want something like    or, as I outlined, something like _.set(). >The let tag: > > is a new tag that lets you create blocks like: > >  >  >  *  =  >  >  > > Which yields: > > 1 * 0 = 0 > 2 * 1 = 2 > 3 * 2 = 6 > 4 * 3 = 12 > > The #let tag works like the #with tag, but is more flexible in that > it allows you to make multiple assignments, and allows you to chain > assignments, using earlier declarations in later assignments. Notice > inthe ablove example, the 'result' variable is based on 'num' and > 'index', both of which are assigned in the same #let expression. > > Syntacticly, each argument to be evalulated in the head of the let > tag must be seperated by a newline. Enclosing an argument in double > quotes causes it to be evaluated by the DTML expression machinery. > Un-quoted arguments are referenced by name. Is it just me, or is this newline-separation syntax really crazy? How does the "let" tag handle multiline expressions? Why not just use commas? It would mean alienating those suckers who actually use commas in object ids, but that's not a huge loss. ;-) > Evaluation is in sequence with the result of earlier assignments > available to later ones. Later assignments can also override earlier > ones, which can be helpful for longer step-by-step calculations. The > variables thus set are in effect for the life of the  > block. > > > >Brian Lloyd brian(a)digicool.com >Software Engineer 540.371.6909 >Digital Creations http://www.digicool.com > -- Alexander Staubo http://www.mop.no/~alex/ "He could open a tin of sardines with his teeth, strike a Swan Vestas on his chin, rope steers, drive a steam locomotive and hum all the works of Gilbert and Sullivan without becoming confused or breaking down in tears." --Robert Rankin, _The Book of Ultimate Truths_

2 1

RE: [Zope] safe sql queries
by Alexander Staubo 13 Jul '99

13 Jul '99

Not having the SQL92 spec at hand, I can only guess that this syntax is a proprietary extension to SQL, much like SQL Server 7.0's contains() predicate*. Whatever suits your application, really, but if you're thinking about portability, "like" is the way to go. [*] a rather useful construct for fuzzy full-text searching. It supports boolean expressions, wildcards, ranking, prefixing, proximity searching (eg., "near"), weighted keywords, word variants (eg., plurals), etc. -- Alexander Staubo http://www.mop.no/~alex/ "He could open a tin of sardines with his teeth, strike a Swan Vestas on his chin, rope steers, drive a steam locomotive and hum all the works of Gilbert and Sullivan without becoming confused or breaking down in tears." --Robert Rankin, _The Book of Ultimate Truths_ >-----Original Message----- >From: zope-admin(a)zope.org [mailto:zope-admin@zope.org]On Behalf Of >Graham Chiu >Sent: 13. juli 1999 23:12 >To: zope(a)zope.org >Subject: Re: [Zope] safe sql queries > > >In article <B059671903C6D211A0D500C0F0301C79139BC2(a)kubrick.mop.no>, >Alexander Staubo <alex(a)mop.no> writes >>This should work (untested): >> >> > >Thanks for the quick reply. I will try this out, but in the >meantime it >just occurred to me that changing the query to > >description containing  > >should do what I require. > > >------- >Regards, Graham Chiu >gchiu<at>compkarori.co.nz > >_______________________________________________ >Zope maillist - Zope(a)zope.org >http://www.zope.org/mailman/listinfo/zope > >(For developer-specific issues, use the companion list, >zope-dev(a)zope.org - http://www.zope.org/mailman/listinfo/zope-dev ) >

2 1

RE: [Zope] Confera "talkback" buttons - is this correct?
by Brian Lloyd 13 Jul '99

13 Jul '99

> Speaking of which, has anybody tried using Confera from > within a ZClass? > It would be much more elegant that was Cees describes. Question being: > Would Confera store its messages in the instance, or in the class? > > -- > Alexander Staubo You would need to arrange for your ZClass to create a new Confera _instance_ in your new object instance at construction time. If you plopped a Confera instance into the actual ZClass, that Confera instance would be shared by all instances of that ZClass - this would be the case for _all_ mutable objects, exactly like in python. For example, to create an object where each instance has its own list attribute (mutable object) in Python, you would do: class foo: def __init__(self): self.data=[] You would _not_ do: class foo: data=[] ...because all foo instances would share the same data list. Hope this helps! Brian Lloyd brian(a)digicool.com Software Engineer 540.371.6909 Digital Creations http://www.digicool.com

1 0

RE: [Zope] Confera "talkback" buttons - is this correct?
by Alexander Staubo 13 Jul '99

13 Jul '99

Speaking of which, has anybody tried using Confera from within a ZClass? It would be much more elegant that was Cees describes. Question being: Would Confera store its messages in the instance, or in the class? -- Alexander Staubo http://www.mop.no/~alex/ "He could open a tin of sardines with his teeth, strike a Swan Vestas on his chin, rope steers, drive a steam locomotive and hum all the works of Gilbert and Sullivan without becoming confused or breaking down in tears." --Robert Rankin, _The Book of Ultimate Truths_ >-----Original Message----- >From: cg(a)cdegroot.com [mailto:cg@cdegroot.com] >Sent: 13. juli 1999 23:47 >To: zope(a)zope.org >Subject: [Zope] Confera "talkback" buttons - is this correct? > > >I've done an experiment for talkback buttons on the bottom of pages. >Basically, I created a Confera topic, copied all files but >index_html to the >top level folder, and copied the relevant part of the Confera's topic >index_html to a top-level "talkback" DTML document. All I need >to do now is >create a Confera topic, edit an index_html inside the topic >just like it was a >normal document, and include a  somewhere >at the bottom. >Seems to work like a charm... > >Is this sensible? Any caveats? >-- >Cees de Groot http://www.cdegroot.com ><cg(a)cdegroot.com> > > > >_______________________________________________ >Zope maillist - Zope(a)zope.org >http://www.zope.org/mailman/listinfo/zope > >(For developer-specific issues, use the companion list, >zope-dev(a)zope.org - http://www.zope.org/mailman/listinfo/zope-dev ) >

1 0

RE: [Zope] Zope and Frontier Comparison
by Michel Pelletier 13 Jul '99

13 Jul '99

> -----Original Message----- > From: Kevin Dangoor [mailto:tazzzzz@yahoo.com] > Sent: Tuesday, July 13, 1999 5:35 PM > To: Kam Cheung; Zope > Subject: Re: [Zope] Zope and Frontier Comparison > > > --- Kam Cheung <zope(a)littlecircle.com> wrote: > [lots of good comparison of Frontier and Zope > acquisition deleted] > > In Frontier, it's another story. When you view a > > Frontier object, Frontier > > will assume that you will acquire the most immediate > > pageHeader, pageFooter > > and template. So, in a Fronter object, all I need to > > do is put in: > > > > Bodytext goes here!!! > > > > I don't need to refer to any pageHeader or > > pageFooter in the html object. > > When I chose to start working with Zope, I also > evaluated Frontier. To me, the automatic use of > templates seems natural and convenient. It allows the > delegation of content creation without the writer > having to know *anything* about DTML. If you use > Structured Text, they only need to know a little > structured text, no HTML. > I just D/Led frontier today, so I'm still looking at it. Looks like interesting stuff. > It would not be difficult in Zope2 to create ZClasses > that automatically use a default template. > These ZClasses have in fact been created here in house, we have a ZClass called STXDocument that has a two sided nature, one is the Content, the other is the Format. You can think of it as a hybrid between DTML Documents and DTML Methods. The content you can edit is the DTML Document part, and the Format is the DTML Method. They're a bit misnamed, because they are not limited to STX, in fact, we could use a good name suggestion for this cool object. By default, the format is    This can be changed in one of the object's 'views' just like a DTML Method. -Michel > Kevin > > _________________________________________________________ > Do You Yahoo!? > Get your free @yahoo.com address at http://mail.yahoo.com > > > _______________________________________________ > Zope maillist - Zope(a)zope.org > http://www.zope.org/mailman/listinfo/zope > > (For developer-specific issues, use the companion list, > zope-dev(a)zope.org - http://www.zope.org/mailman/listinfo/zope-dev ) >

1 0

RE: [Zope] Defining variables
by Brian Lloyd 13 Jul '99

13 Jul '99

> Currently we have REQUEST.set(). This is nice, but I think there is a > need for a general-purpose variable namespace that isn't related to > REQUEST (plus the fact that typing "REQUEST.set(...)" all the > time isn't > so cool). > > I have one specific case where it's simply arduous having to mix real > REQUEST variables -- meaning those that come in through the > query string > or form data -- with actual request-related variables. > > How about adding something like _.set()? > > -- > Alexander Staubo Doesn't the Let tag basically accomplish what you are asking for? From the Let tag docs: The let tag: is a new tag that lets you create blocks like:    *  =    Which yields: 1 * 0 = 0 2 * 1 = 2 3 * 2 = 6 4 * 3 = 12 The #let tag works like the #with tag, but is more flexible in that it allows you to make multiple assignments, and allows you to chain assignments, using earlier declarations in later assignments. Notice inthe ablove example, the 'result' variable is based on 'num' and 'index', both of which are assigned in the same #let expression. Syntacticly, each argument to be evalulated in the head of the let tag must be seperated by a newline. Enclosing an argument in double quotes causes it to be evaluated by the DTML expression machinery. Un-quoted arguments are referenced by name. Evaluation is in sequence with the result of earlier assignments available to later ones. Later assignments can also override earlier ones, which can be helpful for longer step-by-step calculations. The variables thus set are in effect for the life of the  block. Brian Lloyd brian(a)digicool.com Software Engineer 540.371.6909 Digital Creations http://www.digicool.com

1 0

Defining variables
by Alexander Staubo 13 Jul '99

13 Jul '99

Currently we have REQUEST.set(). This is nice, but I think there is a need for a general-purpose variable namespace that isn't related to REQUEST (plus the fact that typing "REQUEST.set(...)" all the time isn't so cool). I have one specific case where it's simply arduous having to mix real REQUEST variables -- meaning those that come in through the query string or form data -- with actual request-related variables. How about adding something like _.set()? -- Alexander Staubo http://www.mop.no/~alex/ "He could open a tin of sardines with his teeth, strike a Swan Vestas on his chin, rope steers, drive a steam locomotive and hum all the works of Gilbert and Sullivan without becoming confused or breaking down in tears." --Robert Rankin, _The Book of Ultimate Truths_

1 0