Re: [Zope-dev] CatalogAware
Chris Withers wrote:
>
> Michael Bernstein wrote:
> >
> > Now I'm wondering how to duplicate the behaviour of Postings
> > being contained within Squishdot, but not appearing in the
> > 'Contents' tab.
>
> that's definitely a 'bad' thing :-(
Why is that bad? A custom object management UI ('Postings'
and 'Moderation' tabs) seems appropriate for Squishdot. I
wouldn't want to manage postings from the standard
management interface.
> Why duplicate anyway? You writing a replacement? ;-)
No, I'm creating two different applications, an image
archive and a book catalog. Both need to handle large
numbers of items. The standard management interface does not
scale to the number of objects involved from a usability
perspective.
Neither of my projects need objects to nest (as squishdot
postings do) so I don't need to duplicate the tree
interface, but instead I'll probably create a batching
interface to allow relatively easy access to all contained
objects.
I'd like to know how to prevent the objects being listed in
the 'Contents' tab, while still allowing other objects (like
DTML methods) to be added there.
Any clues?
Michael Bernstein.
___
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: Spitter.c Hack
Erik,
> [Jason Spisak]
>
> | I am running on a big machine though. If anyone wants those changes
> | there's really easy. Just mail me directly, since it's a long file
> | to post.
>
> Hi. I would be interested in the file :-).
>
Okay, here's the diff. It truely is nothing more than cutting out the two
parts that eliminate single letter words and numbers:
*** Zope-2.2.4-src/lib/python/SearchIndex/Splitter.c
--- Zope-2.2.4-src/lib/python/SearchIndex/Splitter_Old.c
***
*** 169,192
len = PyString_Size(word) - 1;
len = PyString_Size(word);
- /*if(len < 2) Single-letter words are stop words!
- {
- Py_INCREF(Py_None);
- return Py_None;
- } */
-
- /*
- Test whether a word has any letters. */
for (; --len >= 0 && ! isalpha((unsigned char)cword[len]); );
- /*if (len < 0)
- {
- Py_INCREF(Py_None);
- return Py_None;
- }
-
- * If no letters, treat it as a stop word.
- */
Py_INCREF(word);
--- 169,176
> Would you also be willing to share some statistics on how many objects
> you have in how many indexes, and how much time "complex" searches
> take? I do understand if this is not possible, but it'd be appetiated
> if it was possible. :-)
>
> Thanks.
Well, here's the some output of the "Status" tab in the Catalog.
Subtransactions are Disabled
Subtransactions
-
Index Status
* 48205 object are indexed in bobobase_modification_time
* 48205 object are indexed in calendar_date
* 48205 object are indexed in calendar_day
* 48205 object are indexed in call_date
* 48205 object are indexed in curators
* 48205 object are indexed in data
* 48205 object are indexed in id
* 48205 object are indexed in meta_type
* 48205 object are indexed in resume_in
* 48205 object are indexed in status
* 48205 object are indexed in users_calendar
The only TextIndex is the 'data' index though. It is the one that gets
hammered.
Let's see...time stats...hmmm
I put a REQUEST.set with the ZopeTime at the top of the search page and at
the bottom after the 'in' tag for the Catalog.
Search terms are: los and angeles and C++ and MFC and 310
Subtracting the float of the two times I get 1.85400104523 I'm not sure
what that comes out to, I think it's part of a day though because of
DateTime.
The server stats:
Dual Intel 400mhz Xenon w/ 1MB cache each
LVD RAID 5 7200 RPM disk array
1GB RAM
RedHat Linux 6.1 with some kernel updates...
And the best piece of open source software I know: Zope 2.2.4 binary
release
Hope that helps.
All my best,
Jason Spisak
CIO
__ ___ ____
/ // (_)_/_ __/__ / / ___ ___ __ _
/ _ / / __/ -_) / / -_) __/ _ \(_-<_/ __/ _ \/ ' \
/_//_/_/_/ \__/_/ \__/\__/_//_/___(_)__/\___/_/_/_/
6151 West Century Boulevard
Suite 900
Los Angeles, CA 90045
P. 310.665.3444
F. 310.665.3544
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 )
Re: [Zope-dev] Re: Spitter.c Hack
Casey Duncan:
It truely is nothing more than cutting out the two parts that eliminate
single letter words and numbers:
*** Zope-2.2.4-src/lib/python/SearchIndex/Splitter.c
--- Zope-2.2.4-src/lib/python/SearchIndex/Splitter_Old.c
***
*** 169,192
len = PyString_Size(word) - 1;
len = PyString_Size(word);
- /*if(len < 2) Single-letter words are stop words!
- {
- Py_INCREF(Py_None);
- return Py_None;
- } */
-
- /*
- Test whether a word has any letters. */
for (; --len >= 0 && ! isalpha((unsigned char)cword[len]); );
- /*if (len < 0)
- {
- Py_INCREF(Py_None);
- return Py_None;
- }
-
- * If no letters, treat it as a stop word.
- */
Py_INCREF(word);
--- 169,176
All my best,
Jason Spisak
CIO
__ ___ ____
/ // (_)_/_ __/__ / / ___ ___ __ _
/ _ / / __/ -_) / / -_) __/ _ \(_-<_/ __/ _ \/ ' \
/_//_/_/_/ \__/_/ \__/\__/_//_/___(_)__/\___/_/_/_/
6151 West Century Boulevard
Suite 900
Los Angeles, CA 90045
P. 310.665.3444
F. 310.665.3544
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 )
Re: [Zope-dev] ZPatterns: catching exceptions raised by triggers
At 12:49 AM 1/6/01 +, Steve Alexander wrote: > >WHEN OBJECT ADDED, CHANGED CALL self.ensure_conditions_hold() > >I write the ensure_conditions_hold method so that it returns None if >everything is ok, but raises an exception if there is a problem with the >new state of the object. > >That's all fine. However, I want to catch this exception in my >application, and handle it in a friendly way. However, I've tried using >dtml-try blocks and try: except: blocks from Python Scripts, and either >way, I cannot catch the exception. It still causes Zope to return the >standard_error_message screen. > >I can only speculate that this is all due to the way that triggers get >executed at the end of transaction. I guess I'll have to validate the >data twice if I want to provide helpful feedback to the user. > >How do I catch an error raised by a Trigger? What Ty and I usually do is raise user-friendly error messages (in HTML) to begin with, so there's no need to trap them in an except block; Zope's normal handling works okay then. This is the "as designed/intended" solution to your overall problem. (We often use dtml-raise for this, as it makes it easier to create a full-screen HTML error page.) But to answer the question you asked, you can do it by performing a subtransaction commit, wrapped in a try or dtml-try block. This will fire the triggers in a context where you can trap the exception. We suggest you only use this trick when you really need it, however, and in your situation as described I don't think you really need it. Even if "ensure_conditions_hold" can't be changed to raise friendly exceptions, you can always put a wrapper routine around it that catches and re-raises them. The key idea here is that it's perfectly okay to let an exception propagate to the user, if formatted properly. You probably *want* it to happen, to ensure that *everything* gets rolled back. Even if you do the subtransaction trick and trap the error, you still want to make sure the transaction as a whole aborts, since SQL (for example) might already have been sent to a database. ___ 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] ZPatterns: catching exceptions raised by triggers
Let's say I have a trigger that is called to ensure that what something is changed to holds true. I use some skinscript like this: WHEN OBJECT ADDED, CHANGED CALL self.ensure_conditions_hold() I write the ensure_conditions_hold method so that it returns None if everything is ok, but raises an exception if there is a problem with the new state of the object. That's all fine. However, I want to catch this exception in my application, and handle it in a friendly way. However, I've tried using dtml-try blocks and try: except: blocks from Python Scripts, and either way, I cannot catch the exception. It still causes Zope to return the standard_error_message screen. I can only speculate that this is all due to the way that triggers get executed at the end of transaction. I guess I'll have to validate the data twice if I want to provide helpful feedback to the user. Stranger still, the error message is reporting itself to have a strange content-type, so my browser is asking me if I want to download it as a file; I'm pretty sure this isn't related to the skinscript though, as I can get the same effect with other errors. How do I catch an error raised by a Trigger? -- Steve Alexander Software Engineer Cat-Box limited http://www.cat-box.net ___ 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] Acquisition wishlist :-)
Chris Withers writes: > And I suppose the other part of my wishlist: > > class MyClass(Acquisition.Implicit): > # your_attribute will be acquied > > # index_html won't > index_html = None No, that is not enough! As a side effect to turn off acquisition, you defined the attribute. This will not play well with inheritance: You will not only prevent acquisition of "index_html" but also prevent inheritance of it (which may be really necessary in some contexts). Dieter ___ 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] RFE: Make PythonScripts.standard available from DTML _.standard
Steve Alexander writes: > I like your idea. It is one way to implement my recent "lobbying" request with minimal effort. Dieter ___ 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: Spitter.c Hack
Jason Spisak wrote: > > Zopists, > > I finally got Splitter.c to let me index numbers and 'C++' in a TextIndex. > I have about 50,000 objects in that index, and search performance is nearly > instantaneous still. I am running on a big machine though. If anyone > wants those changes there's really easy. Just mail me directly, since it's > a long file to post. Could you maybe post just the diff for poserity? -- | Casey Duncan | Kaivo, Inc. | [EMAIL PROTECTED] `--> ___ 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: ZPatterns: __getitem__ on a DataSkin instance
Steve Spicklemire wrote: > Hi Steve, > >Hmm.. is the 'id' of your PythonScript also getattr? Yes. I forgot to mention that. And, I realized just after posting the email to the list that calling a method "getattr" is asking for trouble :-) Actually, my workaround doesn't work except in the most trivial cases. My code was making more errors as Zope tried to look up the _ variable via __getitem__ and thus via my PythonScript. I've ended up using a dtml-if to choose whether to use a block or just a plain block. I'd still like to know why a Dataskin from a specialist is behaving differently from one in the ZODB in this respect. -- Steve Alexander Software Engineer Cat-Box limited http://www.cat-box.net ___ 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: ZPatterns: __getitem__ on a DataSkin instance
Hi Steve, Hmm.. is the 'id' of your PythonScript also getattr? thanks, -steve > "Steve" == Steve Alexander <[EMAIL PROTECTED]> writes: Steve> Steve Alexander wrote: >> Let's say I have a DataSkin-derived ZClass that has the >> attribute "forename" (in a dataskin attribute propertysheet). >> >> If I get an instance of this ZClass from the ZODB (set up to >> use a Folder w/ customizer suppport), I can refer to the >> "forename" attribute using . >> >> However, if I get an instance of the same class from a >> Specialist, gives me >> >> Error Type: AttributeError Error Value: __getitem__ >> >> Any idea why there's the difference? >> >> Can the latter case be fixed? Steve> A workaround, using the ever-flexible skinscript: Steve> I've defined __getitem__ through skinscript and a Steve> PythonScript. Steve> SkinScript: WITH SELF COMPUTE __getitem__=getattr Steve> PythonScript: parameter list: index Steve>return getattr(index) Steve> -- Steve Alexander Software Engineer Cat-Box limited Steve> http://www.cat-box.net Steve> ___ Zope-Dev Steve> maillist - [EMAIL PROTECTED] Steve> http://lists.zope.org/mailman/listinfo/zope-dev ** No cross Steve> posts or HTML encoding! ** (Related lists - Steve> http://lists.zope.org/mailman/listinfo/zope-announce Steve> http://lists.zope.org/mailman/listinfo/zope ) ___ 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: Spitter.c Hack
Zopists, I finally got Splitter.c to let me index numbers and 'C++' in a TextIndex. I have about 50,000 objects in that index, and search performance is nearly instantaneous still. I am running on a big machine though. If anyone wants those changes there's really easy. Just mail me directly, since it's a long file to post. All my best, Jason Spisak ___ 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: ZPatterns: __getitem__ on a DataSkin instance
Steve Alexander wrote: > Let's say I have a DataSkin-derived ZClass that has the attribute > "forename" (in a dataskin attribute propertysheet). > > If I get an instance of this ZClass from the ZODB (set up to use a > Folder w/ customizer suppport), I can refer to the "forename" attribute > using . > > However, if I get an instance of the same class from a Specialist, > gives me > >Error Type: AttributeError >Error Value: __getitem__ > > Any idea why there's the difference? > > Can the latter case be fixed? A workaround, using the ever-flexible skinscript: I've defined __getitem__ through skinscript and a PythonScript. SkinScript: WITH SELF COMPUTE __getitem__=getattr PythonScript: parameter list: index return getattr(index) -- Steve Alexander Software Engineer Cat-Box limited http://www.cat-box.net ___ 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] ZPatterns: __getitem__ on a DataSkin instance
Let's say I have a DataSkin-derived ZClass that has the attribute "forename" (in a dataskin attribute propertysheet). If I get an instance of this ZClass from the ZODB (set up to use a Folder w/ customizer suppport), I can refer to the "forename" attribute using . However, if I get an instance of the same class from a Specialist, gives me Error Type: AttributeError Error Value: __getitem__ Any idea why there's the difference? Can the latter case be fixed? -- Steve Alexander Software Engineer Cat-Box limited http://www.cat-box.net ___ 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] ZPaterns, Pluggins
Steve Alexander wrote: > > If you're using ZPatterns anyway, After looking at ZPatterns for a few more days again, I still can't justify introducing that ammount of complexity to the project concerned. Also, ZPatterns seems very skewed towards TTW development now and, for CVS and distributability reasons, that's also innappropriate for this project. > you might like to look at PlugIns. The > idea with PlugIns is that a PlugIn manager delegates the handling of > objects it contains to its various PlugIns. Typically, a PlugIn will > claim objects based on the object's meta-type. As I understand it, the pluggins archicture is now wholey seperated from the ZPatterns one, so I might still take a look at that. Are there any docs about the pluggin architecture anywhere? > PlugIns appear in the user-interface as separate tabs. See the > Customizers and Data Plug-ins tabs in a Folder w/ Customizer Support > instance for an example. Thanks, I'll take a look :-) 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] SkinScript reference in two-up postscript
Hi folks, http://www.cat-box.net/steve/skinscript_ref-0-4-3b2.ps.gz This is a two-up A4 postscript version of PJE's most useful SkinScript reference. It prints out to four landscape-orientation A4 pages. http://www.cat-box.net/steve/skinscript_ref-0-4-3b2_letter.ps.gz This is similar, but for letter size paper. Also available in pdf: http://www.cat-box.net/steve/skinscript_ref-0-4-3b2.pdf http://www.cat-box.net/steve/skinscript_ref-0-4-3b2_letter.pdf The files were produced from the skinscript help page of ZPatterns 0-4-3b2, printed to a file with Mozilla, and then converted to 2-up pages using impose. The pdf versions were produced using ps2pdf on the postscript files. -- Steve Alexander Software Engineer Cat-Box limited http://www.cat-box.net ___ 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] BTree Folders
Chris Withers wrote: > > Right, BTree folders wise, what I'm looking for is to have, in effect > two Contents tabs for one BTree folder object, one showing all contained > items of a particular meta_type (with the BTree Folder's interface to > deal with lots of objects), and the other containing all other items in > the folder (DTML Methods, Gifs, etc, with a normal folder's interface). > > What's the best way to do this? If you're using ZPatterns anyway, you might like to look at PlugIns. The idea with PlugIns is that a PlugIn manager delegates the handling of objects it contains to its various PlugIns. Typically, a PlugIn will claim objects based on the object's meta-type. PlugIns appear in the user-interface as separate tabs. See the Customizers and Data Plug-ins tabs in a Folder w/ Customizer Support instance for an example. -- Steve Alexander Software Engineer Cat-Box limited http://www.cat-box.net ___ 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] zope on win95
where can i download (exact url) binary version of zope to install it on my win95 system? for now i've only been able to download python source code version of zope. how do i execute dtml files? i just want to know that. thanks _ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.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 )
[Zope-dev] BTree Folders
Hi, There was talk a while back of re-doing BTree's in Zope so they were more efficient. Is that still going ahead? If I start using BTree folders now, will there be any nasties when the changes happen? Right, BTree folders wise, what I'm looking for is to have, in effect two Contents tabs for one BTree folder object, one showing all contained items of a particular meta_type (with the BTree Folder's interface to deal with lots of objects), and the other containing all other items in the folder (DTML Methods, Gifs, etc, with a normal folder's interface). What's the best way to do this? I was going going to subclass BTreeFolder, and overide the contents tab and provide an extra one, copying and hacking the DTML as appropriate to filter on meta_type. this strikes me as not very robust as I won't benefit from any improvements to either GUI that are made in the future. Is there perhaps a better way? Also, what's the difference between a 'Full' and a 'Basic' BTreeFolder, which one should I use? 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 )
Re: [Zope-dev] CatalogAware
On 1/5/01 7:16 AM, "Chris Withers" <[EMAIL PROTECTED]> wrote: >> uncatalog_object to be called on it (I'm not sure what >> method reindex_object causes to be called). > > unindex_object followed by index_object. I'm not convinced it's > necessary, as no-one has said that uncataloging is a necessary step > before catalogng something that's already in the catalog. Actually this is where the luminous KeyError lurks. If you don't unindex_object first (prior to 2.2.4), then you could potentially have words in the forward index that your object no longer contains, and eventually it could get into a state where you get a KeyError. In 2.2.4 I modified it (rather bluntly) to always do an unindex_object before even starting the index_object proceedings... This is obviously rather heavy, but it did prevent a lot of faulty uses... CatalogAware was wrong, for example :-) In 2.3a2 (hopefully :-) and if not a3), Jim and I have developed some merging code that will do much more intelligent merging of new and old data, reducing the size of transactions in the Catalog, and also preventing things from being touched when in fact nothing changed---this can be responsible for 70-80% of the bloat in some sites. In addition, many needless objects were touched when they had no relevance to the object being indexed. This should also help reduce bloat. Speed, so far is on par, and eventually we hope faster for most sites. Chris -- | Christopher Petrilli Digital Creations | [EMAIL PROTECTED]Where Zope comes from ___ 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] Acquisition wishlist :-)
Shane Hathaway wrote: > > There's a (much) simpler way: > > class MyClass(Acquisition.Explicit): > your_attribute = Acquisition.Acquired > > # index_html isn't > index_html = None Cool :-) And I suppose the other part of my wishlist: class MyClass(Acquisition.Implicit): # your_attribute will be acquied # index_html won't index_html = None Sorry for wasting the lists' time :-S 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 )
Re: [Zope-dev] Acquisition wishlist :-)
There's a (much) simpler way:
class MyClass(Acquisition.Explicit):
your_attribute = Acquisition.Acquired
# index_html isn't
index_html = None
"Acquired" is a special object that the acquisition module looks for.
However, I wasn't aware you could add a "1" to the ComputedAttribute
constructor. Thanks!
Shane
Martijn Pieters wrote:
>
> On Thu, Jan 04, 2001 at 10:46:35AM +, Chris Withers wrote:
> > Dieter Maurer wrote:
> > >
> > > > acquisition.donotacquire('index_html')
> > > This would be great.
> >
> > Indeed :-)
> >
> > > > class MyClass (Acquisition.Explicit):
> > > >
> > > > acquisition = ClassAcquisitionInfo()
> > > >
> > > > acquisition.acquire('index_html')
> > > > acquisition.acquire('fred')
> > > You already can do that, though with a different syntax
> > > (I would need to search for in the documentation).
> >
> > You may mean that if x is an Acquisition.Explicit object, you can do:
> >
> > x.aq_acquire('your_attribute') (syntax may be wrong ;-)
> >
> > What I meant is that through a declaration in the class you could saying
> > acquire the 'your_attribute' attribute but nothing else. So, you could
> > still do:
> >
> > x.your_attribute ...which would be acquired, but...
> > x.index_html ...which wouldn't be acquired.
>
> You could use ComputedAttribute for that:
>
> class MyClass(Acquisition.Explicit):
> # The following attribute is acquired transparently
> def _acquired_your_attribute(self):
> return self.aq_acquire('your_attribute')
> your_attribute = ComputedAttribute(_acquired_your_attribute, 1)
>
> # index_html isn't
> index_html = None
>
> Or you could define a __getattr__ that does a lookup in a list for
> explicetly acquired attributes:
>
> _acquired = ('index_html', 'fred')
> def __getitem__(self, key):
> if key in self._acquired:
> return self.aq_acquire(key)
> raise AttributeError, name
>
> --
> Martijn Pieters
> | Software Engineer mailto:[EMAIL PROTECTED]
> | Digital Creations http://www.digicool.com/
> | Creators of Zope http://www.zope.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 )
___
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] CatalogAware
Michael Bernstein wrote: > > Now I'm wondering how to duplicate the behaviour of Postings > being contained within Squishdot, but not appearing in the > 'Contents' tab. that's definitely a 'bad' thing :-( Why duplicate anyway? You writing a replacement? ;-) 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 )
Re: [Zope-dev] CatalogAware
Chris Withers wrote: > > Michael Bernstein wrote: > > > > uncatalog_object to be called on it (I'm not sure what > > method reindex_object causes to be called). > > unindex_object followed by index_object. I'm not convinced it's > necessary, as no-one has said that uncataloging is a necessary step > before catalogng something that's already in the catalog. I have no idea one way or the other. > > So, postings would only need to be CatalogAware if you > > wanted them to be able to 'live' anywhere within the Zope > > heirarchy, instead of being contained directly within the > > Squishdot object (which inherits from ZCatalog). > > Yes, but Squishdot postings are intimately tied to the Squishdot > folderish object anyway, so that's not going to happen ;-) I understand. Thanks for your patience. I now have a better understanding of ZCatalog and CatalogAwareness. Now I'm wondering how to duplicate the behaviour of Postings being contained within Squishdot, but not appearing in the 'Contents' tab. Cheers, Michael Bernstein. ___ 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] protocol accesibility
Toby Dickenson wrote: > > > That's not been my experience, but maybe that How-To would help :-) > > Care to write it? ;-) > > It is on my todo list cool :-) > > Protocol independence is not necessarily a good thing in this case. > > Different protocols have different capabilities. > > The zope way of modelling different capabilities is through roles. The right > way to achieve this is to allocate different roles based on protocol. how do you do that? (refs to how-to's, docs, etc all good, just that I never knew you could do that :-) > You could do this today using LoginManager, which allows for roles to be > *computed* during authentication. Give your users different roles depending > on whether they use http or https. ( or ftp? > Indeed, I would be keen to see this > feature in the standard user folder) Maybe that's what I should haev said in my proposal ;-) > Note that protocol is not a key factor here: you might also trust them more > if the socket connection comes from localhost. very true > > http://www.zope.org/standard_html_header > > Can you explain *why* this is a problem? While I agree it's untidy, its only > an untidyness seen by people who go looking for it. Some people (or am I the only one ;-) don't really find that acceptable. The paranoid part of me also wants to know that it isn't possible to find this, as it should only be used by other stuff inside zope, why should stuff outside of zope get to play with it? > > http://www.cbsnewyork.com/objectIds are left hanging out. > > I propose securing the 'access contents information' permission, and you > havent explained why this is flawed. Securing the permission? perhaps you could explain that a bit more :-S > > http://www.cbsnewyork.com/rubbish ain't none too nice either, likewise > > That document has since been removed. Nope, that's the point, it give a yucking Zope Error which lowers user confidence, rather than saying 'that page wasn't found, perhaps you'd like to look here or here', but, to be fair, that's because whoever built that site didn't bother to make standard_error_message useful (don't get me started on tacking tracebacks on the end of html generated by that page ;-) > > http://www.cbsnewyork.com/manage... > > I get an authentication dialog so? Hit cancel. Again, a yucky Zope error rather than saying 'sorry, your username or password were wrong', or, in reference to this thread, not actually being _visible_ to this protocol at all. eg: should raise a 404, as standard_html_header should ;-) 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 )
Re: [Zope-dev] Product dev
Chris Withers wrote: > > Shane Hathaway wrote: > > > > > > when a product has syntax errors. One of the first things I did at > > > > Digital Creations was make sure that got fixed. :-) > > > > > > Does this mean this bit from your average product's __init__.py isn't > > > neeeded anymore? > > > > > > except: # If we can't register, complain! > > > import sys, traceback, string > > > type, val, tb = sys.exc_info() > > > sys.stderr.write(string.join(traceback.format_exception(type, > > > val, tb), '')) > > > del type, val, tb > > > > That's right. As long as you're in -D mode or you have the event log > > going somewhere, you'll see these kind of exceptions. > > Cool, what version was it fixed in? One of the 2.2.0 betas, I think. Shane ___ 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] protocol accesibility
Toby Dickenson wrote: > > IMO their goals are achieved better, and simpler, with a HOWTO > that explains how to configure the 'access contents information' permission. That's not been my experience, but maybe that How-To would help :-) Care to write it? ;-) > I think perhaps you havent appreciated the simplicity of the current > arrangement - all protocols work the same. That remains to be proved, even given the DTML wart you mentioned ;-) > Your word 'accidentally' is a good hint as to the reason. A better (IMO) > principal is 'protocol independance' - a method should behave the same no > matter how it is called. Protocol independence is not necessarily a good thing in this case. Different protocols have different capabilities. For example, you might trust someone a lot more if they were using HTTPS rather HTTP. So, there is a disagreement here. What I proposed would enable us both to be happy, without anymore work on your part thanks to defaults that leave things as they are now. Your point of view leaves only you happy ;-) > > How would you hide things like standard_html_header and _footer from > > users? > > Im not sure why they need to be, please explain. I dont think 'tidyness' is > a sufficient reason. I do, and I'm sure others do to. It's doesn't look very professional when things like http://www.zope.org/standard_html_header and http://www.cbsnewyork.com/objectIds are left hanging out. http://www.cbsnewyork.com/rubbish ain't none too nice either, likewise http://www.cbsnewyork.com/manage... 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 )
Re: [Zope-dev] Objects with multiple parents and storage flexibility, ZPatterns?
Steve Spicklemire wrote: > > No... I don't think so! If you don't mind keeping stuff in ZODB > then you *could* have a traversal interface that made stuff 'appear' > wherever you want it to, though its persistent storage would 'really' > be in a Rack or FwCS. Cool... how would I go about doing that? > Hmm. not really... the Zope 'id' is used by the Rack to keep track > of all the objects of a single type. If all your 'X's are kept in one > Rack, they all need a unique 'id'. Ah, yes, now I see, in my case, as with the ZODB, the unique id would be the path from the specialist/FwCS to the DataSkin in question, ending in the dataskin's ID, I think :-S The difference is that, because of the multiple parents thing, unique id -> dataskin isn't a one to one mapping. many unique id's map onto one dataskin. I suppose that means the _actual_ unique id for the dataskin needs to be a unique integer number or some such. But I guess the user would never need to be exposed to that? Does strike me that this is all redo-ing Zope's traversal stuff, which is why I'm trying to find a better way... wagh! My head hurts :-S > The idea context_id is an id-like > attribute that 'plays the role of id' in the context of a particular > parent. It's probably a bad name... but all I could think of in 5 > minutes... I think id would be better, because it's closest to Zope's notion of id, the bit that goesi nto the Rack probably wants to be called 'unique idenitifier' or maybe even 'path' depending on what gets used :-S > Wow... multiple parents, multiple children.. it's almost incestuous! inbred objects, now there's a concept ;-) > So long as you can write queries for 'find parents for child x' and > 'find children for parent y' it shouldn't matter. cool... > Chris> Hurm... I'd love them to have a UI identical to normal Zope > Chris> folders/objectmanagers, though, with properties, a security > Chris> tab, and, in a dream world, the ability to drop normal DTML > Chris> methods, python Scripts and the like into the foldersish > Chris> objects. > > Chris> Is this asking for too much? ;-) > > You can never *ask* for too much. ;-) But then what happens if I ask how to do it? > Seriously though... for this you'll probably need to store the objects > persistently in the Rack(s), Why? > though you could farm some of their > attributes out to other data storage systems with SkinScript. Nothing > will prevent you from making your DataSkins inherit from ObjectManager > or Folder, but you won't be able to completely 'virtualize' them. Well, that may not be a problem. The important thing is that if someone creates a record in a.n.other system, then one of these 'virtual' objects automatically appears in the Zope side of things... reckon that's not too hard? > The > only way I *think* you could make this work with completely virtual > data-skins is to create 'sister' classes to everything you wanted to > add (e.g. 'SkinDTML Method' and 'SkinPython Script' which would be new > classes that inherit from DataSkin *and* the class you want to emulate > (and probably yet another class that hanldles the interconnection glue > parents/context and all that). Then you'd need to add whatever > attribute providers were necessary to keep all the attributes of the > original classes (e.g., DTML Method) in your external storage. But it > sounds like you just want to keep 'some' of the associated data > in the external source... so I don't think any of that will be > necessary. Why would the sister classes be needed? Anyway, how do I break this down into small beginner sized steps and start doing it? thanks for all your help, 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 )
Re: [Zope-dev] Product dev
Shane Hathaway wrote: > > > > when a product has syntax errors. One of the first things I did at > > > Digital Creations was make sure that got fixed. :-) > > > > Does this mean this bit from your average product's __init__.py isn't > > neeeded anymore? > > > > except: # If we can't register, complain! > > import sys, traceback, string > > type, val, tb = sys.exc_info() > > sys.stderr.write(string.join(traceback.format_exception(type, > > val, tb), '')) > > del type, val, tb > > That's right. As long as you're in -D mode or you have the event log > going somewhere, you'll see these kind of exceptions. Cool, what version was it fixed in? I'll chop the code out of Squishdot et al as soon as I get the chance :-) 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 )
Re: [Zope-dev] Product dev
Chris Withers wrote: > > Shane Hathaway wrote: > > > > when a product has syntax errors. One of the first things I did at > > Digital Creations was make sure that got fixed. :-) > > Does this mean this bit from your average product's __init__.py isn't > neeeded anymore? > > except: # If we can't register, complain! > import sys, traceback, string > type, val, tb = sys.exc_info() > sys.stderr.write(string.join(traceback.format_exception(type, > val, tb), '')) > del type, val, tb That's right. As long as you're in -D mode or you have the event log going somewhere, you'll see these kind of exceptions. Shane ___ 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] ZPatterns question
Christian Scholz wrote: > > > yeah, this is exactly what I'm after too. I'd like the virtual objects > > the specialist is responsible for to have normal Zope management > > screens. > > Well, I think this shouldn't be too difficult to create. Just a subclass > of Specialist and add some Contents-Tab, define objectIds() etc. in the > Methods tab and call it in the management screen of "Contents". > Though the more advanced things like Copy/Paste/Rename might then not > be available.. But for me actually it would be sufficient to get the > contents. :-S I was hoping for something along the lines of subclass from Specialist and Folder, and override objectIds (+ whatver else?) in my new class to do 'the right thing' I wonder how that would pan out? > > Also, much mroe trickily, I'd like them to be able to contain each > > other, although Steve A's __bobo_traverse__ trick might help with this > > bit... > > What do you mean? Nesting Specialists (or these virtual folder specialists)? The DataSkins stored in the specialist ;-) 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 )
Re: [Zope-dev] RFE: Make PythonScripts.standard available from DTML _.standard
Steve Alexander wrote: > > > eg: > > > "mysomething(_['title_or_id'],_.standard.html_quote(absolute_url()+_[id]))"> > > You are being deliberately Byzantine there! I provided a good example for my case, don't know what Byzantine means, erk :-S > However, I agree with you in principle. > I've had other, much simpler, cases where I want to html_quote just a > part of something. I can't put my finger on an example right now, so > that does weaken my case a little :-) *grinz* 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 )
Re: [Zope-dev] RFE: Make PythonScripts.standard available from DTML _.standard
Chris Withers wrote: > > If you have something like that, wouldn't it be better, more readable, > etc, for it to be moved intop a python script, even if that script was > only 1 line long? > > eg: > "mysomething(_['title_or_id'],_.standard.html_quote(absolute_url()+_[id]))"> You are being deliberately Byzantine there! Not to mention that _['title_or_id'] is equivalent to just title_or_id. However, I agree with you in principle. I've had other, much simpler, cases where I want to html_quote just a part of something. I can't put my finger on an example right now, so that does weaken my case a little :-) -- Steve Alexander Software Engineer Cat-Box limited http://www.cat-box.net ___ 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] RFE: Make PythonScripts.standard available from DTML _.standard
Steve Alexander wrote: > > The PythonScripts product could add these functions to the _ namespace > variable at product init time, so there would be no need to change the > DocumentTemplate modules. And here's a patch: Just add these lines at the end of lib/python/Products/PythonScripts/standard.py from DocumentTemplate.DT_Util import d import standard d['standard']=standard del standard Of course, you could add similar lines to PythonScripts/__init__.py, or in a completely new "enable python scripts standard module with dtml" product. -- Steve Alexander Software Engineer Cat-Box limited http://www.cat-box.net ___ 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] RFE: Make PythonScripts.standard available from DTML _.standard
Steve Alexander wrote: > These functions would be really useful as part of the DTML _ namespace > variable. I sometimes find myself wanting to use html_quote in a DTML > expression. If you have something like that, wouldn't it be better, more readable, etc, for it to be moved intop a python script, even if that script was only 1 line long? eg: becomes: > I'd also be able to use these functions from ZPatterns > SkinScript. That's a seperate issue and oen I'm sure I'll agree with once I start using SkinScript ;-) > The PythonScripts product could add these functions to the _ namespace > variable at product init time, so there would be no need to change the > DocumentTemplate modules. Hmmm... since they're both part of the Zope Core, does it make a lot of difference where it's done? 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 )
Re: [Zope-dev] protocol accesibility
Toby Dickenson wrote: > > On Fri, 05 Jan 2001 12:18:07 +, Chris Withers <[EMAIL PROTECTED]> > wrote: > > >http://www.zope.org//Wikis/DevSite/Proposals/ProtocolAccessibility > > > >So it is :-) > > > >Comments are still welcome... > > Comments provided as requested With sensible defaults, what I was proposing would be just as simple as things are now, but explicit and flexible. For example, if you start a method name with _, it's not URL traversable, or available in DTML. I have no idea about FTP but it probabyl won't be accessible through DAV. Alternatively, if you give a method in a python a doc string, it will be URL traversable. Take that doc string away and it won't be url traversable but will be accessible in DTML. Again, don't know about FTP or DAV. I agree the wording might be bad (that proposal is very old now), but how can something that seeks to clearly define and document something that has already been partially and accidentally implemented (as was often the Zope way ;-) be a bad thing? cheers, Chris PS: How would you hide things like standard_html_header and _footer from users? Access Contents Information is needed by a lot of methods (some of which aren't available to give proxy roles to) that using it to prevent peole from sniffing around in your site isn't feasible. ___ 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] RFE: Make PythonScripts.standard available from DTML _.standard
This is an RFE for Zope 2.3. I'm posting it here for discussion, rather than in the Collector. In the new PythonScripts product (that is a standard part of Zope 2.3) there is a standard utility module that can be imported into a Python Script with import Products.PythonScripts.standard or from Products.PythonScripts.standard import * It contains useful functions such as those for text formatting (html_quote, url_quote_plus, and so on). It also contains the DTML class for creating temporary chunks of restricted DTML. These functions would be really useful as part of the DTML _ namespace variable. I sometimes find myself wanting to use html_quote in a DTML expression. I'd also be able to use these functions from ZPatterns SkinScript. The PythonScripts product could add these functions to the _ namespace variable at product init time, so there would be no need to change the DocumentTemplate modules. -- Steve Alexander Software Engineer Cat-Box limited http://www.cat-box.net ___ 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] Developers Reference
Anyone know if there are plans for a second O'Reilly book to cover
development stuff like this?
. o O ( Zope: The Definitive Developers Reference )
Ah, I guess I can only dream for now :-)
cheers,
Chris
Martijn Pieters wrote:
>
> On Fri, Jan 05, 2001 at 12:22:32PM +, Chris Withers wrote:
> > Martijn Pieters wrote:
> > >
> > > You could use ComputedAttribute for that:
> > >
> > > class MyClass(Acquisition.Explicit):
> > > # The following attribute is acquired transparently
> > > def _acquired_your_attribute(self):
> > > return self.aq_acquire('your_attribute')
> > > your_attribute =ComputedAttribute(_acquired_your_attribute, 1)
> > >
> > > # index_html isn't
> > > index_html = None
> >
> > That looks cool :-)
> >
> > Where's it documented? what does the 1 mean?
>
> Erm. The ExtensionClass.stx documentation hints at a ComputedAttribute
> class (but as an example of how you could use an ExtensionClass). The
> current C implementation of ComputedAttribute is not, as far as I can see,
> documented.
>
> As for the '1', the CVS log has the following to say on that:
>
> Added second "level" argument for computed attributes. This makes it
> easier to create computed attributes that work with acquisition.
> Normally, computed attributes are called with unwrapped objects. Passing
> a level of 1, causes computed attributes to be called with one level of
> wrapping. Note that the innermost (single) level of wrapping typically
> reflects a containment context with any extra access contexts stripped
> off.
>
> As I understand it, it makes self.aq_acquire possible.
>
> See also:
>
> http://cvs.zope.org/Zope2/lib/Components/ExtensionClass/ComputedAttribute.c
>
> --
> Martijn Pieters
> | Software Engineer mailto:[EMAIL PROTECTED]
> | Digital Creations http://www.digicool.com/
> | Creators of Zope http://www.zope.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 )
___
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: ComputedAttribute
On Fri, Jan 05, 2001 at 12:22:32PM +, Chris Withers wrote:
> Martijn Pieters wrote:
> >
> > You could use ComputedAttribute for that:
> >
> > class MyClass(Acquisition.Explicit):
> > # The following attribute is acquired transparently
> > def _acquired_your_attribute(self):
> > return self.aq_acquire('your_attribute')
> > your_attribute =ComputedAttribute(_acquired_your_attribute, 1)
> >
> > # index_html isn't
> > index_html = None
>
> That looks cool :-)
>
> Where's it documented? what does the 1 mean?
Erm. The ExtensionClass.stx documentation hints at a ComputedAttribute
class (but as an example of how you could use an ExtensionClass). The
current C implementation of ComputedAttribute is not, as far as I can see,
documented.
As for the '1', the CVS log has the following to say on that:
Added second "level" argument for computed attributes. This makes it
easier to create computed attributes that work with acquisition.
Normally, computed attributes are called with unwrapped objects. Passing
a level of 1, causes computed attributes to be called with one level of
wrapping. Note that the innermost (single) level of wrapping typically
reflects a containment context with any extra access contexts stripped
off.
As I understand it, it makes self.aq_acquire possible.
See also:
http://cvs.zope.org/Zope2/lib/Components/ExtensionClass/ComputedAttribute.c
--
Martijn Pieters
| Software Engineer mailto:[EMAIL PROTECTED]
| Digital Creations http://www.digicool.com/
| Creators of Zope http://www.zope.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 )
[Zope-dev] ComputedAttribute
Martijn Pieters wrote:
>
> You could use ComputedAttribute for that:
>
> class MyClass(Acquisition.Explicit):
> # The following attribute is acquired transparently
> def _acquired_your_attribute(self):
> return self.aq_acquire('your_attribute')
> your_attribute = ComputedAttribute(_acquired_your_attribute, 1)
>
> # index_html isn't
> index_html = None
That looks cool :-)
Where's it documented? what does the 1 mean?
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 )
Re: [Zope-dev] RE: objectIds accessiblilty & and a proposal
Brian Lloyd wrote: > > Are you talking about 'ProtocolAccessibility'? It's still > there (though Jim has done some rearranging of things there > lately)... http://www.zope.org//Wikis/DevSite/Proposals/ProtocolAccessibility So it is :-) Comments are still welcome... 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 )
Re: [Zope-dev] CatalogAware
Michael Bernstein wrote: > > Aha! > > You're saying that catalog_object and uncatalog_object are > methods of the catalog, so when the catalog contains the > objects directly, it's all that's neccessary, correct? Yes :-) > uncatalog_object to be called on it (I'm not sure what > method reindex_object causes to be called). unindex_object followed by index_object. I'm not convinced it's necessary, as no-one has said that uncataloging is a necessary step before catalogng something that's already in the catalog. > So, postings would only need to be CatalogAware if you > wanted them to be able to 'live' anywhere within the Zope > heirarchy, instead of being contained directly within the > Squishdot object (which inherits from ZCatalog). Yes, but Squishdot postings are intimately tied to the Squishdot folderish object anyway, so that's not going to happen ;-) 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 )
Re: [Zope-dev] CatalogAware
Michael Bernstein wrote: > > Your example is correct as far as it goes, but as I > understand it, you are not really specifying the default > catalog per se, but the default catalog *name*. This is true, and one of the reasons why I (and maybe only I ;-) consider CatalogAware somewhat less useful than it could be. 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 )
Re: [Zope-dev] Acquisition wishlist :-)
On Thu, Jan 04, 2001 at 10:46:35AM +, Chris Withers wrote:
> Dieter Maurer wrote:
> >
> > > acquisition.donotacquire('index_html')
> > This would be great.
>
> Indeed :-)
>
> > > class MyClass (Acquisition.Explicit):
> > >
> > > acquisition = ClassAcquisitionInfo()
> > >
> > > acquisition.acquire('index_html')
> > > acquisition.acquire('fred')
> > You already can do that, though with a different syntax
> > (I would need to search for in the documentation).
>
> You may mean that if x is an Acquisition.Explicit object, you can do:
>
> x.aq_acquire('your_attribute') (syntax may be wrong ;-)
>
> What I meant is that through a declaration in the class you could saying
> acquire the 'your_attribute' attribute but nothing else. So, you could
> still do:
>
> x.your_attribute ...which would be acquired, but...
> x.index_html ...which wouldn't be acquired.
You could use ComputedAttribute for that:
class MyClass(Acquisition.Explicit):
# The following attribute is acquired transparently
def _acquired_your_attribute(self):
return self.aq_acquire('your_attribute')
your_attribute = ComputedAttribute(_acquired_your_attribute, 1)
# index_html isn't
index_html = None
Or you could define a __getattr__ that does a lookup in a list for
explicetly acquired attributes:
_acquired = ('index_html', 'fred')
def __getitem__(self, key):
if key in self._acquired:
return self.aq_acquire(key)
raise AttributeError, name
--
Martijn Pieters
| Software Engineer mailto:[EMAIL PROTECTED]
| Digital Creations http://www.digicool.com/
| Creators of Zope http://www.zope.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] case insensitive sorts
Shane Hathaway wrote: > > Shane Hathaway wrote: > > def sort_strings(data): > > sortable_data = list(map(lambda s: (lower(s), s), data)) > > sortable_data.sort() > > return map(lambda s: s[1], sortable_data) > > ... Or better, you could pass a comparison function to sort() like Tres > suggested. :-) This is where this whole thread started ;-) We end up using a comparision function every time we call sort, which is messy and results in a lot of duplicated code... My suggestion was for the default sort function to change so that when you want the sorting that makes sense to humans, you'd just have to do: list.sort() ...and when you wanted sort as it is now, then you could something like: list.sort(lambda x, y: old_cmp(y,x)) But this thread has lost noth its ends, so to speak, so I shall duck out ;-) 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 )
Re: [Zope-dev] Product dev
Shane Hathaway wrote: > > when a product has syntax errors. One of the first things I did at > Digital Creations was make sure that got fixed. :-) Does this mean this bit from your average product's __init__.py isn't neeeded anymore? except: # If we can't register, complain! import sys, traceback, string type, val, tb = sys.exc_info() sys.stderr.write(string.join(traceback.format_exception(type, val, tb), '')) del type, val, tb 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 )
Re: [Zope-dev] Internationalization
On Thu, Jan 04, 2001 at 12:02:17PM -0700, [EMAIL PROTECTED] wrote: > Hello, > > > Has anyone translated a site within Zope ? I have tried the ZBabel > Translation System (http://www.zope.org/Members/TheJester/ZBabel) and > didn't think it did really what I was after. > > I need to translate the site into French , German , and Japanese . > > I assume the best way is to pull the different languages from a database > via a python external method or just Zmysql you can use the Translator product (that does *not* use an external database.) try our cvs via html interface (cvs.mixadlive.com) or download directly from the zope site: http://www.zope.org/Members/fog/Translator/ ciao, federico ___ 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 )
