Re: [Zope-dev] Possible 'bad' with Client.py and urllib

2001-02-27 Thread Chris Withers

Dieter Maurer wrote:
 
 Chris Withers writes:
    urllib  Client block Zope 
 That would suggest a bug in Python's socket implementation:
 
   its "makefile().read" method would not release the global
   interpreter lock.

Do you think this is likely? If so, where would I go to report it, or maybe it's
perhaps already fixed in Python 2.0?

That said, this problem only started manifesting itself when the target of the
urlopen or Client.get was a Python Script. It had been working fine before when
the target was DTML Method. 

What with the Byte Code hacks, etc, in Python Scripts, I wonder if that isn't
maybe the problem.

Has anyone got any ideas how I'd go about inestigating this?

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] ZCatalog stuff

2001-02-27 Thread Chris Withers

"R. David Murray" wrote:
 
 On Thu, 22 Feb 2001, Chris Withers wrote:
  Apart from that, any ideas how I'd search for a record where the indexed
  attribute is blank or the secondary sort stuff?
 
 Somebody contributed a patch for the secondary sort stuff a while back.
 Whether it still works with 2.3.0 is a good question.

Any idea where I'd find that? I may need to give it a go...

 I also remember a *long* time ago (back when I was first starting with
 zope about a year ago) someone posting a method for picking up all
 the records in a catalog with a blank value for a field.  How you'd
 find it in the mail archives, though, I have no clue, nor do I
 remember what the method involved.

Likewise with this. The only solution I can think of at the moment is to have a
seperate 'x_is_blank' index that set to 'not x', but that seems terribly
inefficient to me :-S

Any ideas gratefully recieved :-)

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] How to build indexes in the MemberCatalog of Membership Component?

2001-02-27 Thread Steve Alexander

Bill Anderson wrote:


 I use, and recommend the use of a ZPattern trigger. You can get it by
 downloading the DataSkins product. This way, whenever a member is
 modified, it automatially updates/creates it's entry in the catalog.
 Just be sure to specify MemberCatalog :)

To expand on what Bill said:

Stick this in a SkinScript method in your Membership folder, on the Data Plug-Ins tab 
of err... Users perhaps? User Sources?
You should be able to work it out. (I don't have a live LoginManager to hand right 
now.)

WHEN OBJECT ADDED CALL
MemberCatalog.catalog_object(self, _.string.join(self.getPhysicalPath(),'/'))
WHEN OBJECT DELETED CALL 
MemberCatalog.uncatalog_object(_.string.join(self.getPhysicalPath(),'/'))
WHEN OBJECT CHANGED CALL 
MemberCatalog.uncatalog_object(_.string.join(self.getPhysicalPath(),'/')),
MemberCatalog.catalog_object(self, _.string.join(self.getPhysicalPath(),'/'))

--
Steve Alexander
Software Engineer
Cat-Box limited


___
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] catalog object owners?

2001-02-27 Thread Chris Withers

Chris McDonough wrote:
 
  Aha?  So if I specify a field index of,
  get_parent_node_id, which is a
  function call on all objects that are to be indexed, this
  would
  index the returned value?
 
  If so, how long has this been available?
 
 As long as the catalog has been around, AFAICT...
 
 This is one of its very most basic features.

And one of it's most endearing :-)

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] Search Features and Zope Directions Road Map

2001-02-27 Thread Matt Hamilton

 p.d.  Right now I'm quite interested at the technology of searching
 and finding non structured content, in order to compose structured
 documents. For example, the guys at Vignette (StoryServer) say that
 its customers don't need to keyword anything in order to have a
 "related content" section. After the writer finishes a story,

Take a look at http://beta.osdigger.com.  It is a mailing list search
engine I was working on about a year ago, unfortunately I've not had the
time to work on it since.  It is designed to scale to doing full text
ranked searches on millions of email messages in under a couple of seconds
on a single machine (currently PII-300).  It has a 'two-step' search
feature which brings back related terms to ones you put in (usually
:). eg. type in 'scsi controller' and chances are it will return adaptec
amongst the list of other terms.  The idea is to prompt the user to be
more specific with their search.

I would love to take more time to work on it again, and would like to
be able to access it from withing Zope and use it to catalog arbitary Zope
object like ZCatalog does. 

-Matt

-- 
Matt Hamilton [EMAIL PROTECTED]
Netsight Internet Solutions, Ltd.  Business Vision on the Internet
http://www.netsight.co.uk   +44 (0)117 9090901
Web Hosting | Web Design  | Domain Names  |  Co-location  | DB Integration



___
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] 'inheritedAttribute' vs. 'call of superclass'

2001-02-27 Thread Gregor Heine

I have two Python classes, say A and B, where B subclasses A.
If I want to call a method in A from an overridden method in B I can either
use:

B.inheritedAttribute('method_in_A')(self. *args)
or:
A.method_in_A (self, *args)

Can anybody explain me the differences between those two, because the second
one seems (at least in the context of Zope Products) not always to work
properly whereas the first one doesn't look very OO'ish and is (AFAIK) not a
Python function but something coming from Zope.

Thanx,

Gregor Heine
Software Engineer
CDC Communications and Design Consultancy GmbH
 

___
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: commitSubtransaction() gives AttributeError on commit_sub

2001-02-27 Thread Ian Sealy

Dear Brian,

  req = context.REQUEST
  context.propertysheets.info.manage_changeProperties(longdesc=req.f
  orm['longdesc'])
  context.commitSubtransaction()
  req.RESPONSE.redirect(req['URL1']+'/edit_longdescForm')
  
  context is a DataSkin instance.  When I submit the form, I get an
  Attribute Error on commit_sub (traceback below in case it helps
  anyone).  As far as I can see from the ZPattern's source, I'm making
  the call correctly and it is an appropriate call.  Any clues?
  
  This is Zope 2.3.1b1 and Steve's convenience release of ZPatterns.
  
  --RDM
  
  Traceback:
 
  AttributeError: (see above)
 
 I believe we've tracked this down and fixed it properly - the 
 fix will be in 2.3.1 b2, but I've a attached a copy of the 
 updated Transaction.py that you can drop into lib/python/ZODB, 
 then restart. It would be great if you get a chance to confirm 
 the fix and let me know how it goes...
 
 Note I've cc'ed a few other folks who have run into this 
 specific problem - if any of you can spare a few moments 
 to verify the fix and let me know if you still see any 
 problems, I'd really appreciate it.

That sorted everything for me. Thanks very much.

Just for info, I'm still using Zope 2.2.5 and just dropping the updated
Transaction.py into that worked fine.

Thanks again.

Cheers,
Ian


___
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] More ZCatalog Stuff.

2001-02-27 Thread Toby Dickenson

 I am assuming that the code you provided goes into a
 manage_addCustomIndex method that is part of a CustomIndex
 Python Product.

hehehehe, nothing so general-purpose as that ;-)
 
  You will need to implement a subclass derived from one of 
 the standard
  indexes to provide your custom indexing policy, whatever that is.
 
 Can you provide the code for your custom KeywordIndex, so I
 have a starting point? I realize yours subclasses a
 KeywordIndex, and I probably need to subclass a TextIndex,
 but it would still probably help. I can integrate and hack
 on other peoples code better than I can write my own from
 scratch.


from SearchIndex.UnKeywordIndex import UnKeywordIndex, MV, intSet
from types import ListType, TupleType

class UnTrackingIndex(UnKeywordIndex):

meta_type = 'Tracking Properties Index'

"""Like a Keyword Index, only it indexes tracking properties
"""

def __init__(self,question):
id = 'tracking_'+unicode(question).encode('unicode-escape')
self.question = question
UnKeywordIndex.__init__(self,id)

def index_object(self, i, obj, threshold=None):
""" index an object 'obj' with integer id 'i'"""

index = self._index
unindex = self._unindex

try:
kws = obj.tracking_answers(self.question)
if type(kws) not in [type([]),type(())]:
raise ValueError('Indexing a tracking property set of
inappropriate type %r' % type(kws))
except:
kws = (MV,)

# index each item in the sequence
for kw in kws:
set = index.get(kw)
if set is None:
index[kw] = set = intSet()
set.insert(i)

unindex[i] = tuple(kws)

self._index = index
self._unindex = unindex

return 1


___
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] More ZCatalog Stuff.

2001-02-27 Thread Michael R. Bernstein

Toby Dickenson wrote:
 
 On Mon, 26 Feb 2001 19:00:58 -0800, "Michael R. Bernstein"
 [EMAIL PROTECTED] wrote:
 
 Toby Dickenson wrote:
 
  If you are interested in a short-term hack, it is possible implement
  your own type of index and add it to an existing catalog, without
  having to modify any of the ZCatalog product.
 
 Ok, how? Please keep in mind that I'm more of a designer and
 integrator than a coder.
 
 ZCatalogs are a zopeish wrapper around a zope-neutral catalog object,
 which is stored in the _catalog attribute. That leading underscore is
 a clue that you shouldnt be using it directly, however you need to in
 order to create a custom index. Liek I said, this is a hack.
 
 The main problem is that catalog (and hence ZCatalog) implements a
 factory interface where you specify the name of the index type (for
 example "TextIndex", and it creates the indexing objects.
 
 [snip description and code]

I am assuming that the code you provided goes into a
manage_addCustomIndex method that is part of a CustomIndex
Python Product.

 You will need to implement a subclass derived from one of the standard
 indexes to provide your custom indexing policy, whatever that is.

Can you provide the code for your custom KeywordIndex, so I
have a starting point? I realize yours subclasses a
KeywordIndex, and I probably need to subclass a TextIndex,
but it would still probably help. I can integrate and hack
on other peoples code better than I can write my own from
scratch.

Thanks,

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 )



[Zope-dev] _getOb or __getattr__?

2001-02-27 Thread Chris Withers

Hi,

I need a product with custom attribute getting code and so looked to the
BTreeFolder product for inspiration.

It implements both __getattr__ and _getOb which appear to do roughly the same
thing.

What's the difference?

Shane hints that __getattr__ is slower but allows acquisiton. Why is that?

TIA,

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] Search Features and Zope Directions Road Map

2001-02-27 Thread Brian Lloyd

 after reading the Directions Roadmap from DC, I was surprised that
 a substantial improvement of the searching features of Zope, wasn't
 mentioned as a major concern.

 snip

 Moreover,
 everybody uses more Google to look for everything, bypassing
 windows, doors, and
 portals!. Why? Because it's terribly smart (not mentioning its 6,000 Linux
 boxes, by the way), and because there's no need to follow the
 highly-engineered
 information architecture of a web site, if there's a trustful
 shorcut to the
 relevant content!. So, if I'd have to mention one big feature
 improvement to
 Zope, I wouldn't doubt: "search engine".
 snip

 On the other hand, Fast, from
 Norway, already have a nice multimedia search engine, from regular,
 non-structured, spidered web pages. Can we do that "structuring the
 unstructured" thing within Zope?

You have posed an important question (and, probably some answers),
that hopefully I can clarify.

One of the all-important points of the Zope directions document
is that our number one goal is to make it wildly easier for
_developers_ to create and deploy quality components. Why is this
so important? Your questions in this email is why that is so
important.

You are very interested in high-quality search capabilities, and
others certainly are as well. Some other folks care more about
E-Commerce, or Corba integration, or communication with Java
components.

The problem, of course, is that even if DC devoted every single
person here to creating the "best search engine" (which we
couldn't do for very long - we'd soon be gone), we would still
be hard pressed to even come close to making everybody happy
or being competitive with every other search engine vendor
out there. And the reality is that it is not our goal in life
to be a better Google than Google.

Multiply that by the number of things people want (ECommerce, Corba,
et. al.), and the problem is quite clear - *DC cannot possibly
provide the best, most featureful and competitive component for
every problem*.

The *solution* to this problem is what is outlined in the Zope
directions document - dramatically lowering the bar of development
to allow a thriving marketplace of robust components (that are *not*
written by DC), allows interested parties to write (or better yet,
reuse) "the best x component" for their purposes.

In the future, Zope may come with "some batteries included", in that
a Zope distribution may include the latest versions of the most popular
and widely used components. But we hope that the idea of "The ZCatalog"
(for instance) will fall by the wayside. Zope may still come with a
search component such as ZCatalog that is useful for certain tasks and
perhaps as a learningtool, but it will not be an infinitely-scalable
infinitely-featureful thing that everyone uses for every problem.

The hope is that when you outgrow ZCatalog you can move on to other
search components particularly suited to your problem domain. If
you scale beyond what ZC can handle, maybe you move up to some
VeritySearch component that makes use of existing software. Even
now, with the current pain level of component development, building
a VeritySearch component would probably take considerably less time
than building and maintaining equivalent features into "the ZCatalog".

This is the future - the way that Zope will succeed is by being the
best framework and component integration platform for the Web, not
by trying to compete with verticals like search engine vendors on
feature points. "Use the right tool for the job" is something we
have always believed in, and providing a platform that will allow
you to use and integrate the most appropriate tools will be our
focus going forward. That is why "substantial improvement of
searching features" is not on the futures roadmap - we do not want
to provide the best search engine for every task. We want to make
it easy for you to build or integrate the "right" search solution
for your task.


Brian Lloyd[EMAIL PROTECTED]
Software Engineer  540.371.6909
Digital Creations  http://www.digicool.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] _getOb or __getattr__?

2001-02-27 Thread Chris Withers

Jeffrey P Shell wrote:
 
 _getOb and _setOb are for placing subobjects somewhere besides attributes
 (which is the default implementation).

When would __getattr__ be used then?

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] _getOb or __getattr__?

2001-02-27 Thread Chris Withers

Jeffrey P Shell wrote:
 
 _getOb and _setOb are for placing subobjects somewhere besides attributes
 (which is the default implementation).
 
 _getOb and friends are the default protocol that *SHOULD* be used by systems
 that change subobjects (ie - copy and paste).

Sorry, just thought of another coupla questions:

If x is an instance of my class, then:
If I do x.a = 1, is _setOb called?
If I do print x.a, is _getOb called?

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] _getOb or __getattr__?

2001-02-27 Thread Jeffrey P Shell

"Chris Withers" [EMAIL PROTECTED] wrote:

 Jeffrey P Shell wrote:
 
 _getOb and _setOb are for placing subobjects somewhere besides attributes
 (which is the default implementation).
 
 When would __getattr__ be used then?
 

In what context?  You could wire __getattr__ to call into _getOb (and
probably __getitem__ too, since that's also used in traversal and as a way
of getting non-Pythonic ID'd objects).

def __getattr__(self, attr):
return self._getOb(attr)

Until very recently, __getattr__ on persistent objects was like playing with
nuclear fire.  But now, I *believe* it behaves properly, which means
__getattr__ gets called when it receives an unknown name.  How that affects
Acquisition, I don't know.


___
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] _getOb or __getattr__?

2001-02-27 Thread Chris McDonough

 Sorry, just thought of another coupla questions:

 If x is an instance of my class, then:
 If I do x.a = 1, is _setOb called?
 If I do print x.a, is _getOb called?

No in either case.

_setOb shouldn't be used directly in the current ObjectManger
implementation.  It doesn't populate the _objects list of the object manager
on which it was called (your object won't show up).  Instead, _setObject
should be called.


___
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] Zope Good/Bad News Article

2001-02-27 Thread Brian Lloyd

 Just read your article (http://www.pault.com/zope.html)  and really 
 enjoyed it (besides comparing Java to Macs... yikes!). I agree that 
 DC needs to really work with Zope Product Developers and help them as 
 much as possible.

Have you looked at the Zope Directions document recently 
posted on dev.zope.org?

http://dev.zope.org/Resources/ZopeDirections.html

Dramatically lowering the bar for developers to create quality 
components is our number one priority going forward. It will 
be evolutionary and not happen all at once, but it will be 
happening.


 DC should encourage and then force developers to be a bit better 
 about documentation. I have seen product developers put up a  new 
 product with the full amount of documentation about it being "here it 
 is... have fun." This certainly does not help all of those people who 
 want to install and use Zope products. DC can encourage better 
 product development and documentation by doing simple things such as 
 T-shirt contest for best product documentation, tip, how-to and all 
 the rest.

One idea we've kicked around is to make the eventual 
"components area" on zope.org such that component users 
can provide some +1 -1 type feedback that is incorporated 
into the way that components are listed on the site. This 
would let the most popular / best components appear at 
the top of listings etc.

Brian Lloyd[EMAIL PROTECTED]
Software Engineer  540.371.6909  
Digital Creations  http://www.digicool.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] _getOb or __getattr__?

2001-02-27 Thread Chris Withers

Chris McDonough wrote:
 
  Sorry, just thought of another coupla questions:
 
  If x is an instance of my class, then:
  If I do x.a = 1, is _setOb called?
  If I do print x.a, is _getOb called?
 
 No in either case.
 
 _setOb shouldn't be used directly in the current ObjectManger
 implementation.  It doesn't populate the _objects list of the object manager
 on which it was called (your object won't show up).  Instead, _setObject
 should be called.

well, thankfully, I'm not going near __setattr__, _setOb or _setObject :-)
On the setting side, only __setitem__ is getting meddled with, and I'm guessing
there's not gotachas there?

Anyway, using these methods:

# attribute - based traversal stuff
def _getOb(self, name, default=_marker):
print '_getOb:',name
try:
return higher_getOb(self,name)
except:
import sys
print 'type:',sys.exc_type
print 'value:',sys.exc_value
raise AttributeError,name


def __getattr__(self,name,higher_getattr=higher_getattr):
#print '__getattr__:',name
try:
return higher_getattr(self,name)
except AttributeError:
import sys
#print 'type:',sys.exc_type
#print 'value:',sys.exc_value
raise AttributeError,name

def __getitem__(self,name,higher_getitem=higher_getitem):
print '__getitem__:',name
try:
return higher_getitem(self,name)
except KeyError:
import sys
#print 'type:',sys.exc_type
#print 'value:',sys.exc_value
raise KeyError,name

...it would appear that unrestrictedTraverse first tries to use getattr and then
tries to use getitem to get a name. That much I can veryify from the code ;-)
However, it would appear that somewhere in a __getitem__ as implemented by
ZCatalog, _getOb ends up getting called. Which is a little confusing :-S

I think I know when the __get methods get called; same as normal python right?
But when, why, how and what by does _getOb and/org _getObject and/or anything
else I might be interested about in this space get called? ;-)

Thanks loads for the help so far,

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] Re: [Zope] Search Features and Zope Directions Road Map

2001-02-27 Thread Michel Pelletier


Please do NOT cross post.

-Michel


On Mon, 26 Feb 2001, Ausum wrote:

 Zope is a great application server, the same as its soon to be released Content
 Management Framework, because of  its bet on Python, everybody say it.
 Nevertheless, after reading the Directions Roadmap from DC, I was surprised that
 a substantial improvement of the searching features of Zope, wasn't mentioned as
 a major concern.

 For a new Zope enthusiast like me, it is a kind of addiction to arrange and
 administer content while taking the learning curve. Almost everybody in this
 list with a non-programming background might've experimented this. But when I
 arrived to the search features of ZCatalog, I got mixed feelings. (Right now I'm
 stuck on this OR indexes searching :)  )

 The fact is that - according to my strong belief - everybody uses more Google to
 look for Zope Site's content than Zope's own Zcatalog's search engine. Moreover,
 everybody uses more Google to look for everything, bypassing windows, doors, and
 portals!. Why? Because it's terribly smart (not mentioning its 6,000 Linux
 boxes, by the way), and because there's no need to follow the highly-engineered
 information architecture of a web site, if there's a trustful shorcut to the
 relevant content!. So, if I'd have to mention one big feature improvement to
 Zope, I wouldn't doubt: "search engine".

 I just wanted to point on this subject. I know Zope isn't about spidering and
 retrieving, but it should have "Greater Search Capabilities" as a title, within
 that roadmap.  :)



 Ausum



 p.d.   Right now I'm quite interested at the technology of searching and finding
 non structured content, in order to compose structured documents. For example,
 the guys at Vignette (StoryServer) say that its customers don't need to keyword
 anything in order to have a "related content" section. After the writer finishes
 a story, (possibly while) a routine by Autonomy (www.autonomy.com) reads the
 document and finds out what the document is about, and so it triggers a search
 for related content within the site, without the need of intervention by the
 writer.  (For the curious, Autonomy has published a personal version of its
 software. It's called Kenjin (www.kenjin.com) ). On the other hand, Fast, from
 Norway, already have a nice multimedia search engine, from regular,
 non-structured, spidered web pages. Can we do that "structuring the
 unstructured" thing within Zope?


 ___
 Zope maillist  -  [EMAIL PROTECTED]
 http://lists.zope.org/mailman/listinfo/zope
 **   No cross posts or HTML encoding!  **
 (Related lists -
  http://lists.zope.org/mailman/listinfo/zope-announce
  http://lists.zope.org/mailman/listinfo/zope-dev )



___
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] ZClass propertysheets

2001-02-27 Thread Christian Scholz

Hi!

I am just wondering if it's possible to get hold of the properties of a propertysheet
of a ZClass without instanciating it. 

So when instanciating I would just do

map=object.propertysheets[1].propertyMap()

and get all information of my ZClass instance object.
So is this also possible on the class definition? 
(actually I would assume it is stored somewhere as I can edit it via
the management interface. I just didn't manage to get it from the
source code..)

(next question might be how to get the class when only having a 
meta type or the path to it.. but I think I will just search 
the Zope source..) 

kind regards,
  Christian

-- 
COM.lounge  http://comlounge.net/
communication  design [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 )



[Zope-dev] Zope Development Roadmap Components

2001-02-27 Thread Jimmie Houchin

While reading the Zope Development Roadmap about components I had a
question.

It says:
"""Components will be edited via the filesystem as .py files. Components
will probably be checked into and out of Zope via a CVS like facility.
Components can be tested locally without checking them into Zope."""

What does this say about developing components with Py/Perl Scripts?
It looks to be closer to the current Python Products.

I like the idea above but just trying to understand the big picture
about the future.

Any enlightenment appreciated.

Jimmie Houchin

___
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] _getOb or __getattr__?

2001-02-27 Thread Shane Hathaway

Chris Withers wrote:
 
 Hi,
 
 I need a product with custom attribute getting code and so looked to the
 BTreeFolder product for inspiration.
 
 It implements both __getattr__ and _getOb which appear to do roughly the same
 thing.
 
 What's the difference?

_getOb() is part of the ObjectManager interface.  If you want to store
objects in your special ObjectManager in a special way, you override
_getOb(), _setOb(), and _delOb().  (I didn't check the spelling--see
ObjectManager.py)

However, if you store objects in your ObjectManager in a different way
than using setattr(self, name, value), acquisition won't find your
subobjects because acquisition only looks at object attributes.  It
doesn't know anything about _getOb().  (And it's not a good idea to
teach it to use _getOb(); think what it would be like if a Xeon ran like
a 386...)

Overriding __getattr__() lets you make acquisition work again.  However,
as Jeffrey said, until a few months ago it was forbidden.  Then Jim
fixed it.  Now it's used extensively by BTreeFolders, Transparent
Folders, and even the CMF.  However, every time the acquisition
machinery calls a __getattr__() you get a performance hit in the range
of a few microseconds.  But the products I listed try hard to minimize
that impact, so it's not enough of an issue to warrant a C
implementation.

BTreeFolder.py provides a base class that doesn't have __getattr__(). 
You can use that if you think __getattr__() is slowing down your site. 
The derived class is what most people use because it provides the full
functionality.

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] RE: [Zope] Zope Good/Bad News Article

2001-02-27 Thread Shane Hathaway

Brian Lloyd wrote:
 
  DC should encourage and then force developers to be a bit better
  about documentation. I have seen product developers put up a  new
  product with the full amount of documentation about it being "here it
  is... have fun." This certainly does not help all of those people who
  want to install and use Zope products. DC can encourage better
  product development and documentation by doing simple things such as
  T-shirt contest for best product documentation, tip, how-to and all
  the rest.
 
 One idea we've kicked around is to make the eventual
 "components area" on zope.org such that component users
 can provide some +1 -1 type feedback that is incorporated
 into the way that components are listed on the site. This
 would let the most popular / best components appear at
 the top of listings etc.

The T-shirt idea has a lot of merit, though.  It would be more fun. :-) 
(and thus more encouraging)

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] Zope Development Roadmap Components

2001-02-27 Thread Michel Pelletier


On Tue, 27 Feb 2001, Jimmie Houchin wrote:

 While reading the Zope Development Roadmap about components I had a
 question.

 It says:
 """Components will be edited via the filesystem as .py files. Components
 will probably be checked into and out of Zope via a CVS like facility.
 Components can be tested locally without checking them into Zope."""

 What does this say about developing components with Py/Perl Scripts?
 It looks to be closer to the current Python Products.

Yes.  We have thought a bit about "composite components" and "persistent
modules" and stuff like that, but we only went so far into elaboration
when we realized that it required lots, and lots of thought and effort.

The current component effort is much simpler, a component is: an object
with an interface.  If this is a ZClass with Perl-based script methods,
then so be it, but we haven't thought far enough into what ZClasses really
are to start thinking about giving them interfaces.

Is this sort of what you're asking?

-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 )



Re: [Zope-dev] Zope Development Roadmap Components

2001-02-27 Thread Jimmie Houchin

Yes this is what I was looking for and somewhat expecting. I can
understand the challenge in getting ZClass, Py/Perl Script, "composite
components" done right. In fact to me they could easily make things more
complex. Potentially more complex process and more complex machinery to
handle it. I would definitely be for a simpler model of components which
are just as describe .py files and an interface.

I read somewhere that doing components right is/can be hard. The author
wrote that component creation is done by the few for the many. There
will be fewer component authors and more component users and
integrators. I agree with his assessment. 

I think what will make it easier for component authors will be well a
defined API. This appears to me what y'all are doing. If I understand
correctly.

Thanks.

Jimmie Houchin

Michel Pelletier wrote:
 
 On Tue, 27 Feb 2001, Jimmie Houchin wrote:
 
  While reading the Zope Development Roadmap about components I had a
  question.
 
  It says:
  """Components will be edited via the filesystem as .py files. Components
  will probably be checked into and out of Zope via a CVS like facility.
  Components can be tested locally without checking them into Zope."""
 
  What does this say about developing components with Py/Perl Scripts?
  It looks to be closer to the current Python Products.
 
 Yes.  We have thought a bit about "composite components" and "persistent
 modules" and stuff like that, but we only went so far into elaboration
 when we realized that it required lots, and lots of thought and effort.
 
 The current component effort is much simpler, a component is: an object
 with an interface.  If this is a ZClass with Perl-based script methods,
 then so be it, but we haven't thought far enough into what ZClasses really
 are to start thinking about giving them interfaces.
 
 Is this sort of what you're asking?
 
 -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] CopySupport issues

2001-02-27 Thread richard

These comments are against the CVS of about a week ago. I can't get to the
CVS to update at the moment - the connection times out.

Is there a reason why the manage_main call at the end of manage_copyObjects
and manage_cutObjects in CopySupport gets called as
self.manage_main(REQUEST) instead of self.manage_main(self, REQUEST)? Using
the first form, we found that the manage_main call was dying because it
couldn't acquire various attributes and methods it needed (eg,
manage_page_header :). The second form just makes sense...

In the Copy operation of manage_pasteObjects, the manage_afterClone is
called before the object is added to its container. We'd much prefer the
object to be both added to the container and re-got so it the
manage_afterClone call may make use of acquired information. This is of use
specifically for us so that the object may determine its new URL and
catalog itself with our (Z)Catalog.

Interestingly, a call to absolute_url() on the object breaks because
self.REQUEST is 'Special Object Used to Force Acquisition' (yes, a
string). Buggered if I know where that came from (actually, I know it
originates in Acquisition.c, but that's a scary, scary place :)


Richard

-- 
Richard Jones
[EMAIL PROTECTED]
Senior Software Developer, Bizar Software (www.bizarsoftware.com.au)

___
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 )