Re: [Zope.Com Geeks] Re: [Zope-dev] zope-dev list policies

2004-06-24 Thread Michael Bernstein
Ken Manheimer wrote:
I noticed this when it went initially went by, but didn't have time to 
follow up.  The upshot is that there is absolutely no way *under the 
current arrangement* that this is going to happen.  I can see a way to 
swing it, requiring earnest volunteer effort.  Here are the details.

Being the administrator of many of the zope lists (probably over ten and 
below twenty), i am already dismayed by the challenge of the typically 
thirty to one hundred held spam messages, bounces, and other effluvia i 
have to handle *per day*.  I do not know how many of the legitimate list 
messages would additionally be held and require more attention (with the 
current mailman implementation, it takes a lot more fuss to approve a 
held message than to discard it), but the load is already untenable, so 
one more is too many.
I believe the proposal wasn't to *hold* non-member emails, but to bounce 
them or discard them, so your workload should actually be reduced.

--
- Michael R. Bernstein  |  Author of Zope Bible
  michaelbernstein.com  |   Zope.org Webmaster
 panhedron.com  |PythonPhotos.org
___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Re: zope-dev list policies

2004-06-24 Thread Michael Bernstein
Casey Duncan wrote:
-1 on changing the list policy. I read and post to all of the public
lists through Gmane, which won't work if the policy is changed.
Umm... Why wouldn't this work? Isn't Gmane a subscriber?
--
- Michael R. Bernstein  |  Author of Zope Bible
  michaelbernstein.com  |   Zope.org Webmaster
 panhedron.com  |PythonPhotos.org
___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Re: [Zope3-dev] Zope and zope

2004-04-18 Thread Michael Bernstein
Jim Fulton wrote:

Jim Fulton wrote:

The first question is:

Is it a problem to have two packages with names differing only in case?
+1

--
- Michael R. Bernstein
  michaelbernstein.com
  Author of Zope Bible
___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Proposal: Rename zope package

2004-04-16 Thread Michael Bernstein
Jim Fulton wrote:

Based on recent discussions, I've created a proposal:

  http://dev.zope.org/Zope3/RenameTheZopePackage

to rename the zope package to z. Unless there are strong
objections, we'll do this after we move the Zope repository head to
subversion at the end of the month.
From a consistency in nomenclature POV, I find 'z' jars a bit with 
ZConfig, zdaemon, ZEO, zLog, and ZODB, which one might expect to find 
nested within 'z' (as 'z.Config' for example). This is admittedly only 
an issue for the newest newbies still trying to guess at where stuff is 
located.

However, rather than suggest a wholesale moving and renaming of these 
packages within 'z', I'd like to suggest an alternative short name for 
the 'zope' package, 'OPE', which avoids this issue:

 import OPE.interface
 from OPE.app import zapi
 from OPE.app.event import publish
 from OPE.app.event.objectevent import ObjectModifiedEvent
Cheers,

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


Re: [Zope-dev] Proposal: Rename zope package

2004-04-16 Thread Michael Bernstein
Fred Drake wrote:

On Friday 16 April 2004 01:31 pm, Michael Bernstein wrote:
   From a consistency in nomenclature POV, I find 'z' jars a bit with
  ZConfig, zdaemon, ZEO, zLog, and ZODB, which one might expect to find
  nested within 'z' (as 'z.Config' for example). This is admittedly only
  an issue for the newest newbies still trying to guess at where stuff is
  located.
I don't know what zLog is; presumably you mean zLOG?
Yep.

zLOG is dead in Zope 2.8, and will remain only for API compatibility.

I don't think there's any real consistency now for what's in the Zope 2 head, 
so I don't think that's a big deal.
Shouldn't we strive for consistency in nomenclature going forward?

  However, rather than suggest a wholesale moving and renaming of these
  packages within 'z', I'd like to suggest an alternative short name for
  the 'zope' package, 'OPE', which avoids this issue:
 
import OPE.interface
from OPE.app import zapi
from OPE.app.event import publish
from OPE.app.event.objectevent import ObjectModifiedEvent
Hehe.  ;-)

(I do hope you're joking!)
About even considering a 'wholesale moving and renaming' yes, obviously, 
but as far as suggesting 'OPE' as an alternative to 'z' (insofar as it 
is still necessary to avoid a name-clash with 'Zope'), no. 'OPE' (as an 
acronym for Object Publishing Environment) seems like it fits better 
conceptually than 'z'.

Did I miss something? Did I just manage to embarrass myself? Is this a 
dream where I find I am wearing nothing but underwear in public and then 
wake up?

--
- Michael R. Bernstein
  michaelbernstein.com
  Author of Zope Bible
___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Proposal: Rename zope package

2004-04-16 Thread Michael Bernstein
Shane Hathaway wrote:

Michael Bernstein wrote:
Did I miss something? Did I just manage to embarrass myself? Is this a 
dream where I find I am wearing nothing but underwear in public and 
then wake up?
Well, OPE made me think of:

- Opie on The Andy Griffith Show - http://www.imdb.com/title/tt0053479/

- Spelling it zOPE to take advantage of a frequent mishap involving 
the cAPS lOCK key

- Shouting the name of the product repeatedly in code as a method of 
advertising
How about 'ope', then?

Actually, I don't really care what it's changed to. Jim is right in that 
it needs to be changed, and I thought 'z' to be not-so-great a choice 
for the reasons I already gave (in addition to some of the cons that Jim 
lists in his proposal). An optimal choice probably doesn't exist, though.

I thought it was funny. :-)
Do I *amuse* you? ;-)

--
- Michael R. Bernstein
  michaelbernstein.com
  Author of Zope Bible
___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] dtml-in batching badly

2001-06-20 Thread Michael Bernstein

seb bacon wrote:
 
 * Joachim Werner [EMAIL PROTECTED] [010618 20:28]:
   That's not the behaviour I'd expect.  Can anyone confirm this is a
   bug?
 
  As LEE Kwan Soo has already said, it is not a bug, but a clever (too
  clever?) feature that should maybe not be enabled by default. Every second
  week or so somebody runs into this and thinks it is a bug.
 
 Thanks for the hint, folks.
 
 I'm not a zope newbie, and this still bit me.  IMO there's something
 fairly wrong with the current setup.  either the default behaviour
 should be changed to orphans=0, or the visibility of default values
 for tags should be improved (from the book: orphan=int The desired
 minimum batch size - no mention of defaults).
 
 Furthermore, the 'feature' doesn't work as I'd expect.  In the example
 I posted, for the sequence (1,2,3,4), I got:
 
  batch 1: 1
  batch 2: 2 3 4
  batch 3: 3 4
  batch 4: 4
 
 This isn't in batches of at least 3... If it were iterating in minimum
 batches of 3, shouldn't that be:
 
  batch 1: 1 2 3
  batch 2: 2 3 4
  batch 3: 2 3 4
  batch 4: 2 3 4

Orphan control shouldn't actually set the desired minimum
batch size, it should set the size at or below which the
last batch should be combined with the next to last batch.

If my batch size is five, and orphan is set to three, and I
have a set of eight records that I am iterating through, I
will get a single eight record batch, because the orphan
setting tries to prevent the last batch having three or less
results by combining them with the previous five.

Orphan settings typically do not override where the batch
starts (that would be a 'widow' setting) only where it ends,
which is why you are getting increasingly smaller batches.

However, the fact that you are getting four batches (rather
than just one) is arguably a bug. A batch size of one,
combined with an orphan setting of three, should actually
give the following result:

 batch 1: 1 2 3 4

But the algorithm doesn't seem 'smart' enough to roll-up the
batches by recursing through them in reverse order. Arguably
though, you should never set your batch size smaller than
the orphan size, so this isn't really an issue.

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: BTreeFolder

2001-04-27 Thread Michael Bernstein

Shane Hathaway wrote:
 
 Chris Withers wrote:
  will you be releasing a new version of BTreeFolder that makes use of the new
  funky BTrees at any stage?
 
 We've done some work on it; in fact Jim came up with a bold new idea
 that makes them inherently faster. Now to find the time. :-)

Does this have any implications for the BTree implementation
used in ZPatterns Racks?

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] Q: Specialists, Racks, and ZCatalogs?

2001-02-04 Thread Michael Bernstein

Steve Alexander wrote:
 
 Michael Bernstein wrote:
 
  If the SkinScript
  has functionality that should be shared by more than one
  Rack, it should go in the Specialist,
 
 Not quite. If the SkinScript has functionality that is shared by
 all the Specialist's Racks, then it should go in the Specialist.

If the functionality is shared among *most* of the Racks,
can't you override the SkinScript in the exceptions?

 Although you can do that, it is not always the best thing to do.
 Sometimes, a bit of redundancy helps ease a system through the 
 pains of evolution :-)

On that subject, does anyone know why SkinScripts don't
support cut-n-paste or copy-n-paste?

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] Q: Specialists, Racks, and ZCatalogs?

2001-02-03 Thread Michael Bernstein

Hi all,

I've started implementation of a simple ZPatterns based
application, and so far things have been going well.

The problem is, I'm not sure if I'm doing this right.

Here is my setup:

Zope 2.2.0 hosted at Codeit.com on a Linux box
ZPatterns 0.4.3b2

'BookProduct' product
 *'BookClass' ZClass (inherits from
  _ZClass_for_CatalogAware, _ZClass_for_DataSkin)
   * Methods: editInstanceForm, editInstance, index_html,
 AllTextMethod

'Books' Specialist
 * defaultRack which stores 'Book' ZClasses
 * Methods: addBookForm, addBook, index_html, BookSearch,
   BookResults (the last two methods are a Z Search
   Interface)
 *'Catalog' ZCatalog

The 'BookClass' editInstance method contains:

[snip]
dtml-call
"propertysheets.Standard.manage_changeProperties(REQUEST)"
dtml-call reindex_object
[snip]

The 'Books' Specialist's addBook method contains:

[snip]
dtml-let ni="newItem(isbn)"
 dtml-call
"ni.propertysheets.Standard.manage_changeProperties(Authors=Authors,
Title=Title, Price=Price)"
 dtml-call "ni.index_object()"
/dtml-let
[snip]

I've snipped out only the most relevant parts of these
methods.

As I said, so far this has worked ok. But it seems to me
that either the reindex_object or the index_object is in the
wrong place, but I'm not sure which. I'm also not sure it's
a good or bad idea to place the ZCatalog directly into the
Specialist.

Also, I would like to replace the three indexes I'm
maintaining on the books with a single text index on a
computed attribute. I understand that this involves adding a
SkinScript to the Rack containing something like 'WITH SELF
COMPUTE AllText=AllTextMethod', but I'm unsure of the
details. I have a method (AllTextMethod) on the ZClass that
returns several fields concatenated as a single string,
which I would like to use as a text index.

So, I decided to ask for a critique of the application
design (such as it is). I also seem to recall mention of
'indexing agents' that might make this a bit more elegant,
but haven't found a how-to on the subject.

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] How to get the mailing list to work

2001-02-03 Thread Michael Bernstein

Just address your emails to [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] Q: Specialists, Racks, and ZCatalogs?

2001-02-03 Thread Michael Bernstein

Steve Alexander wrote:
 
 Michael Bernstein wrote:
 
  'BookProduct' product
   *'BookClass' ZClass (inherits from
_ZClass_for_CatalogAware, _ZClass_for_DataSkin)

 Don't derive from CatalogAware when you're also deriving from DataSkin.

Ok.

 Rather than use the CatalogAwareness mechanism to
 manually call reindex() when your object changes, you
 should use some SkinScript in your Specialist or in your
 Customizer to catalog, uncatalog and recatalog on changes.
 
 WHEN OBJECT ADDED CALL
 Catalog.catalog_object(self, _.string.join(self.getPhysicalPath(),'/'))
 WHEN OBJECT DELETED CALL 
Catalog.uncatalog_object(_.string.join(self.getPhysicalPath(),'/'))
 WHEN OBJECT CHANGED CALL 
Catalog.uncatalog_object(_.string.join(self.getPhysicalPath(),'/')),
 Catalog.catalog_object(self, _.string.join(self.getPhysicalPath(),'/'))

Thanks, Steve. I'll try this a little later today. What are
your thoughts on placing this in the Specialist's 'Plug-ins'
tab vs. the Rack's?

 [snip]
  Also, I would like to replace the three indexes I'm
  maintaining on the books with a single text index on a
  computed attribute. I understand that this involves adding a
  SkinScript to the Rack containing something like 'WITH SELF
  COMPUTE AllText=AllTextMethod', but I'm unsure of the
  details. I have a method (AllTextMethod) on the ZClass that
  returns several fields concatenated as a single string,
  which I would like to use as a text index.
 
 You don't need a method for this; do it all with SkinScript like this:
 
 WITH SELF COMPUTE
   all_text='%s %s %s' % (title, headline, content)

Thanks again, Steve.

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] Q: Specialists, Racks, and ZCatalogs?

2001-02-03 Thread Michael Bernstein

Steve Alexander wrote:
 
 Michael Bernstein wrote:
 
 
  Thanks, Steve. I'll try this a little later today. What are
  your thoughts on placing this in the Specialist's 'Plug-ins'
  tab vs. the Rack's?

[snip excellent explanation]

Thanks, Steve. That was very helpful. To summarize your
explanation, if I understood correctly:

This is strictly an implementation issue. If the SkinScript
has functionality that should be shared by more than one
Rack, it should go in the Specialist, otherwise keep it with
the Rack that it's specific to. Or, looked at another way,
common functionality should be factored out and acquired.

All in all, a very 'Zopish' principle.

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 )



[Zope-dev] test, please ignore

2001-02-02 Thread Michael Bernstein

test

___
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] Mapping multiple IP addresses/domains to one Zope

2001-01-24 Thread Michael Bernstein

Aaron Gillette wrote:
 
 My company has many sites which share some content. Each site uses a
 different IP address. I would like to bring all of these sites into one
 instance of Zope on an NT machine. I am looking at the possibility of either

 1) running Zope behind IIS, or 

 2) running Zserver exclusively.

You have a third possibility, which is to run Zope behid
Apache on NT. I would guess that this list has more
experience with Apache rewrite rules than IIS.

This setup should also be fairly easy to migrate to Linux.

Personally, I've found it more convenient to point all my
domains to a single IP address, and let Zope (with help from
SiteAccess) handle the rest. This has been easier, even
though Zope is behind Apache, as Zope Access Rules are
easier to create (IMO) than dealing with name or IP based
virtual hosting under Apache. Those Apache rewrite rules are
horribly cryptic.

HTH,

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

2001-01-23 Thread Michael Bernstein

Erik Enge wrote:
 
 [Chris Withers]
 
 | ...and is that specifically for BTree folders, or Zope BTree's in general?
 
 I don't believe that B-Tree folders have those kinds of limitations by
 general design.  I'm more conserned that somewhere along the lines,
 doing operations on a huge BTree Folder (Yes, in Zope) will be slow.

What sort of 'operations' do you mean? copying and pasting
the whole thing?

 Hm, more over, if you actually need to stuff that many objects into
 one Folder, you are probably trying to use the wrong tool for the job.
 
 I do expect that stuffing 27 million objects into one BTree Folder
 will be slow, and I don't want to segment the data.  I do expect that
 I'll have to resort to a relational database, and I have no problem
 with that.  Object databases aren't always the right tool for the job,
 and when they aren't, Zope let's me talk with the other ones nicely,
 so no problemo seor ;).

Eric,

I had separated the storage issue into a different thread
(Specialist/Rack Scalability), and received a reply from
Phillip Eby:

 Just to expand a little on the abov...  Racks should scale at least as
 well, if not larger than a ZCatalog, given the same storage backing for
 the ZODB.  This is because ZCatalog has to manage a minimum of one
 forward and reverse BTree for *each* index, plus another few BTrees
 for overall storage and housekeeping.  Also, keyword and full text
 indexes store multiple BTree entries per object, so that's a factor as
 well.

So the question I was asking is: "if we ignore the issue of
storage and consider indexing and searching the ZCatalog
alone, and assuming that wildcard searches are disallowed,
how far will a single ZCatalog with a text index (on a
computed attribute that concatenates several properties) and
a keyword index (for creating ZTopic heirarchies) scale?"

While I'm perfectly willing to split up the storage of the
data as neccessary, I am far less enamoured by the prospect
of divvying up the indexing and searching to multiple
ZCatalogs. In any case, according to Phillip, if I don't
have to split the ZCatalog, I shouldn't have to split the
storage (in Racks, anyway, but probably BTree Folders too),
either.

Anyway Eric, I hope that when you report your results,
you're able to separate indexing, searching, storage, and
retreival results, so that the appropriate factor can be
identified as the bottleneck. Or at least into
indexing/searching and storage/retreival.

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 )




Re: [Zope-dev] Specialist/Rack scalability

2001-01-22 Thread Michael Bernstein

"Phillip J. Eby" wrote:
 
 Just to expand a little on the abov...  Racks should scale at least as
 well, if not larger than a ZCatalog, given the same storage backing for the
 ZODB.  This is because ZCatalog has to manage a minimum of one forward and
 reverse BTree for *each* index, plus another few BTrees for overall storage
 and housekeeping.  Also, keyword and full text indexes store multiple BTree
 entries per object, so that's a factor as well.
 
 So don't worry about the Rack.  If you're using a Rack, you can store the
 data anywhere, and you can index it in an RDBMS, LDAP directory, ZCatalog,
 or some combination thereof, using triggers to keep the data in sync.

Thanks Philip, that's reassuring. I guess now I need to make
certain that the ZCatalog can scale as far as I need it to.

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

2001-01-22 Thread Michael Bernstein

We seem to have disposed of the wildcard issue [snipped out
below], and I'm looking forward to Eric's results, but does
anyone else have any information about whether there is a
practical upper limit on how many objects can be indexed and
searched in a ZCatalog?

Michael Bernstein wrote:
 
 After comsidering the feedback I got from the previous
 'Massive scalability' thread, I decided to split my queries
 into two areas: Rack scalability and ZCatalog scalability.
 This email deals with the latter.
 
 [snip]

 What I am interested in for my application are two things:
 
 - ZTopics populated using one or more keyword indexes
 
 - Full text search on a single computed attribute that
 concatenates several fields including the aforementioned
 keyword index fields and a few simple string attributes
 (title, caption, description, etc.)
 
 I need to know how far the ZCatalog will scale using this
 indexing and search strategy. Does anyone have anectodal or
 benchmark data to suggest if (and when) I will hit a 'wall'
 regarding the number of objects being indexed and searched?
 Some anectodal data suggests that single field indexing will
 scale easily to 60,000 objects, but what about hundreds of
 thousands or even millions of objects?

 [snip]

___
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] Specialist/Rack scalability

2001-01-21 Thread Michael Bernstein

After comsidering the fedback I got from the previous
'Massive scalability thread, I decided to split my queries
into two areas: Rack scalability and ZCatalog scalability.
This email deals with the former.

It seems clear that indexing and searching are more of a
botleneck than storage/retreival. Nevertheless, so far I
have not heard of anyone trying to store more than 60,000
objects in a rack. I need to know if there is any reason to
suspect that storage (in the ZODB) or retreival performance
would suffer if the number of objects was in the hundreds of
thousands or even millions.

Does anyone have anectodal or benchmark data that would
suggest what happens with that many objects?

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

2001-01-21 Thread Michael Bernstein

After comsidering the feedback I got from the previous
'Massive scalability' thread, I decided to split my queries
into two areas: Rack scalability and ZCatalog scalability.
This email deals with the latter.

Partial match (wildcard) searches have already been
identified as a resource hog, depending on the size of the
result list. I am more than willing to give up wildcards in
my application for performance.

What I am interested in for my application are two things:

- ZTopics populated using one or more keyword indexes

- Full text search on a single computed attribute that
concatenates several fields including the aforementioned
keyword index fields and a few simple string attributes
(title, caption, description, etc.)

I need to know how far the ZCatalog will scale using this
indexing and search strategy. Does anyone have anectodal or
benchmark data to suggest if (and when) I will hit a 'wall'
regarding the number of objects being indexed and searched?
Some anectodal data suggests that single field indexing will
scale easily to 60,000 objects, what about hundreds of
thousands or even millions of objects?

Also, is there a way to disable wildcards in full text
searches?

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 )




Re: [Zope-dev] ZCatalog scalability

2001-01-21 Thread Michael Bernstein

Steve Alexander wrote:
 
 Michael Bernstein wrote:
 
  Also, is there a way to disable wildcards in full text
  searches?
 
 Do not allow direct queries to search the catalog. Instead, make
 searches go through an external method (or a PythonScript with Proxy
 permissions) that uses string.replace to change '*' and '?' to ''.

A *very* handy suggestion. You might want to add that as a
Tip to Zope.org.

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 )




Re: [Zope-dev] ZCatalog scalability

2001-01-21 Thread Michael Bernstein

Erik Enge wrote:
 
 [Michael Bernstein]
 
 | I need to know how far the ZCatalog will scale using this indexing
 | and search strategy. Does anyone have anectodal or benchmark data to
 | suggest if (and when) I will hit a 'wall' regarding the number of
 | objects being indexed and searched?
 
 I'm going to try to stuff 27 million objects into ZODB sometime in the
 next week or the week after that (all post addresses in England).  I
 haven't got a clue as to whether this will work or just... well not
 work.  I haven't come up with a strategy for segmenting the data, but
 that shouldn't be a problem at all.  This isn't actually much data, so
 I don't expect the Data.fs file to more than 500 MB.
 
 I'm quite confident that ZODB, ZCatalog and BTree will scale very
 nicely for this.  I have a plan ;).
 
 I'll let you know how it goes.  (And please, do poke at me if it takes
 too long.

Will do, 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 )




Re: [Zope-dev] Specialist/Rack scalability

2001-01-21 Thread Michael Bernstein

Steve Alexander wrote:
 
 Hi Michael,
 
 Michael Bernstein wrote:
 
 
  It seems clear that indexing and searching are more of a
  botleneck than storage/retreival. Nevertheless, so far I
  have not heard of anyone trying to store more than 60,000
  objects in a rack. I need to know if there is any reason to
  suspect that storage (in the ZODB) or retreival performance
  would suffer if the number of objects was in the hundreds of
  thousands or even millions.
 
 [snip]

 So, storing things in a Rack happens in a number of stages:
 
Your application interacts with the Rack
The Rack (perhaps) stores the object persistently in its BTree
The BTree is a collection of persistent ZODB objects
The ZODB objects are stored as Python Pickles in a FileStorage
 
 We can consider what the effect of storing 60 000 objects is at each of
 these interfaces.

Are there any differences if you scale the number of objects
up to the hundreds of thousands or even into the millions?

 The Rack shouldn't have a problem with 60 000 objects.
 
 I doubt a BTree would have a problem.
 
 The ZODB might not like accessing many large objects during a single
 transaction, as all those objects need to be in memory at once.

Neither of my applications require batch adds to the DB,
however, one of them (the image archive) has objects
(Photos) with several images as attributes. This results in
a fairly large object. There is some question in my mind if
accessing any attribute (such as the thumbnail version)
causes all attributes to be loaded into memory. If so,
displaying a list of images with thumbnails may result in
many large objects being loaded into memory.

 A FileStorage should have no problem reading 60 000 stored objects.
 However, if these objects are changing much, your Data.fs will grow
 fast. In any case, you may find undo and history screens take a long
 time to appear.

No. Once added, I don't expect the data to change
frequently.

Thanks for the feedback.

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] Specialist/Rack scalability

2001-01-21 Thread Michael Bernstein

Steve Alexander wrote:
 
 Michael Bernstein wrote:
 
  There is some question in my mind if
  accessing any attribute (such as the thumbnail version)
  causes all attributes to be loaded into memory. If so,
  displaying a list of images with thumbnails may result in
  many large objects being loaded into memory.
 
 Make sure that each large attribute is an instance of a class that
 derives from Persistent.

Ok, I'll give that a try. Since Photo is a Python Product,
what will happen to current instances if I make this (and
only this) change?

 Of course, if this is a ZPatterns application, you'd probably want to
 have the images in their own Rack, and use an Attribute Provider on your
 Photo objects that gets the images for a Photo as needed. The Photo
 (with meta-data) and the images are entirely different objects, accessed
 via different Racks, via different Specialists.

I'm not certain that that makes sense, since the Images are
really cached 'views' of the Photo object. When a new image
is uploded to replace an existing one, *all* versions
(thumbnails, small, medium, large, etc) are regenerated.

But assuming that I went so far as to break out the Images
to their own Rack, would you reccomend that each image size
have a dedicated Rack, or would you suggest that all images
be stored in the same Rack?

Thanks,

Michael.

___
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] [Fwd: Re: [Zope-dev] Massive scalability]

2001-01-17 Thread Michael Bernstein

Forwarded to the list to maintain the thread.

 Original Message 
From: John Eikenberry [EMAIL PROTECTED]
Subject: Re: [Zope-dev] Massive scalability
To: Michael Bernstein [EMAIL PROTECTED]

Michael Bernstein wrote:

 John Eikenberry wrote:
 
 Can you tell us a bit about how many indexes (and what
 types) you were maintaining about each object? Another
 poster reported no problems with 60,000 objects.

I was testing and had a real simple setup. In addition to
the default
indexes I had 1 index on a string type (of 10 chars or less
- last names),
2000 objects indexed. The vocabulary only had the entries
for this field in
it.

Everything was nice and fast except partial searching. It
was fast enough
when ther were small numbers of matches. But as the number
of matches grew
the time it took grew along with it, at a nearly expontial
rate.

-- 

John Eikenberry
[[EMAIL PROTECTED] - http://zhar.net]
__
"A society that will trade a little liberty for a little
order
 will deserve neither and lose both."
  --B. Franklin

___
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: ZCatalog Scalability

2001-01-17 Thread Michael Bernstein

Christopher Petrilli wrote:
 
 Unfortunately, it won't change in b1, it might change before the final
 release if I can find a better solution.  The problem is in the Vocabulary,
 not in the Catalog itself.  One of the things I'm focusing on is improving
 the algorithms that are used for doing globbing.

Which problem is the algorithm improvement meant to address,
bulk adds or partial search performance?

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 )




Re: [Zope-dev] Massive scalability

2001-01-16 Thread Michael Bernstein

John Eikenberry wrote:
 
 Michael Bernstein wrote:
 
  So, again: Has anyone run up against any performance or
  other limitations regarding large numbers (hundreds of
  thousands or more) of objects stored within the ZODB either
  in a BTree Folder or a Rack?
 
 I was looking into the same issues recently, but for a much smaller set of
 data (5ish). In my tests ZPatterns/binary-trees scaled well for storage
 and retrieval. But ZCatalog did not. It was basically useless for partial
 matching searches (taking many minutes for searches that retrieved more
 than 100 matches)

Was this true even for cases where the batch size was
smaller than 100? For example, if a search returns over 100
results but the batch size is only 20 (so that only 20
results at a time are displayed), do you still get the
performance hit?

 [snip]
 I ended up deciding to go with a RDBMS backend for data storage with a
 ZPatterns interface. SkinScripts work so well for this that I'm actually
 glad I switched. It simplified my design and implementation immensely.

So you're saying that you are doing all searching using SQL
statements, and not just object retreival and storage,
correct? How are you handling full text searches?

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] Massive scalability

2001-01-16 Thread Michael Bernstein

Andy McKay wrote:
 
  While that would work for the simple object case, I find the
  prospect of storing a bunch of BLOBs (for the image data of
  the Photos) in an RDBMS to be *most* un-appetizing. Storing
  them on the server's file-system seems in-elegant as well.
 
 Okey dokey, just a suggestion. I have heard people talk about large ZOBD's
 but once I go over a 10,000 object mark I just find a RDBMS easier myself.
 Go for it good luck!

Thanks! I appreciate different points of view on this
problem, even if you have different 'comfort zones'.

  Does anyone know of any hidden 'gotchas' when dealing with
  this many objects, regardless of the hit-load on the system?
 
 Mostly starting and stopping Zope, [snip]

Are you saying that Zope's startup and shutdown time is
affected by the size of the ZODB?

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 )




Re: [Zope-dev] Massive scalability

2001-01-16 Thread Michael Bernstein

RDM wrote:
 
 On Mon, 15 Jan 2001, Michael Bernstein wrote:
  as Squishdot). Adding a dependency on an RDBMS or requiring
  additional setup on the server's FS seems a step in the
  wrong direction.
 [...]
  So the question remains: Will either approach (within the
  ZODB) allow me to scale the application to hundreds of
  thousands (or even millions) of objects indexed in a
  ZCatalog?
 [...]
  I know that the ZCatalog/ObjectManager approach used by
  Squishdot will scale to over 9,000 objects (the number of
  postings to date at technocrat.net), So I'm reasonably
  certain that my proposed ZCatalog/BTree Folder approach will
  be at least as scalable. I'm slightly less confident about
  the Specialist/Rack approach, because I don't know of any
  sites that have used them to store that many objects in the
  ZODB, but only slightly.
 
 My understanding is that the point of ZPatterns is to hide
 the data storage implementation from the application.[snip]
 The point being that you can *change your
 mind* later, with minimal disruption to your application.  Not
 only that, but people who *use* your product can make their
 own decision about where to store the data.  So by using ZPatterns
 you [...] let the users
 of your product use an RDBMs if that works better for them.

Very good points, and ones that I will keep in mind. Thanks.

 In addition, it seems to me that your comments about ZCatalog+BTree
 apply equally well to ZPatterns, since you can use the Catalog
 to index stuff stored in a rack through the use of appropriate
 triggers, and it is my understanding that the default in-ZODB
 rack storage uses BTree internally.

I do not know if BTree folders and Racks share the same
B-Tree implementation, which is why I qualified my statement
as 'slightly less confident'.
 
 Unfortunately I don't have much input on your question about
 real-life scalability...the most I've done is stored 6 small objects
 in a hierarchy of zope folders, indexed by the catalog, with
 no perceptable slowdown in search or retrieval speed.

Hmm. John Eikenberry mentioned a slowdown with about 50,000
objects on partial-match searches, but I don't know how
simple/complex the objects were, or how many atributes were
being indexed. How many indexes of various types was your
ZCatalog maintaining on your objects?

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 )




Re: [Zope-dev] ZCatalog with ZClass

2001-01-16 Thread Michael Bernstein

Lily Li wrote:
 
 Hello, everyone,
 
 It seems that many of you have used ZCatalog pretty well.
 
 My problem is that I'd like a ZClass (of a Product) to subclass
 CatalogAware, and implement all the index and search inside the Product.
 That means I don't want to do any DTML method stuff outside of the Product.

What you probably want is to create a repository that
subclasses ZCatalog as is described in this HowTo:

http://www.zope.org/Members/tseaver/inherit_ZCatalog

And then add your CatalogAware ZClasses into it. Then you
can set up your ZCatalog/ObjectManager with search methods.

HTH,

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] Massive scalability

2001-01-15 Thread Michael Bernstein

Andy McKay wrote:
 
  I am currently planning two separate 'Archive' type
  projects/Products. In both cases, I need to make sure that
  my implementation will scale to hundreds of thousands or
  even millions of objects.
 
 I would recommend using an RDMBS behind Zope then. Its faster, simpler and I
 have always had better results.

While that would work for the simple object case, I find the
prospect of storing a bunch of BLOBs (for the image data of
the Photos) in an RDBMS to be *most* un-appetizing. Storing
them on the server's file-system seems in-elegant as well.

I'd like to build both of these applications as products
that can be easily installed into a Zope server (as easily
as Squishdot). Adding a dependency on an RDBMS or requiring
additional setup on the server's FS seems a step in the
wrong direction.

I'm working with objects here. I prefer to work with them
compared to the approach of decomposing my objects into
RDBMS records or files, and recomposing.

So the question remains: Will either approach (within the
ZODB) allow me to scale the application to hundreds of
thousands (or even millions) of objects indexed in a
ZCatalog?

I should stress that I am far more concerned about the
number of objects than I am about the number of 'hits'.

I know that the ZCatalog/ObjectManager approach used by
Squishdot will scale to over 9,000 objects (the number of
postings to date at technocrat.net), So I'm reasonably
certain that my proposed ZCatalog/BTree Folder approach will
be at least as scalable. I'm slightly less confident about
the Specialist/Rack approach, because I don't know of any
sites that have used them to store that many objects in the
ZODB, but only slightly.

However, so far I have not heard of anyone storing and
indexing as many homogenous objects as I am talking about.
I'd really like to hear from anyone who has attempted to do
this or something similar.

Does anyone know of any hidden 'gotchas' when dealing with
this many objects, regardless of the hit-load on the system?

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 )




Re: [Zope-dev] Massive scalability

2001-01-15 Thread Michael Bernstein

Jimmie Houchin wrote:
 
 I would like to echo Michael's sentiment and comments. I am at the
 beginning stage of Zope development of a website which will have
 millions of objects of a single object type and multiple of such.

are your objects intended to be indexed by ZCatalog as well,
or are you planning some other method of finding your
objects?

 [snip stuff about mounted databases]
 
 I think there are many who would like to keep their development within
 Zope using objects. Any information on best use or development
 strategies for such setups would be greatly appreciated.

Thanks for adding your voice!

I also think that applications such as we're discussing
should be possible to deploy using nothing but Zope's built
in capabilities. I understand that Zope has certain
limitations in situations that require many writes to the
database, and I accept those limiattions as being a
neccessary trade-off for a storage strategy that uses an
appending file format. I am still trying to determine if
Zope (especially using the two development options I
outlined) has any built in limitations regarding the number
(or number x size) of objects stored.

I really appreciate Zope's features (especially with
ZPatterns) that allow applications to be developed that are
storage-agnostic, and I feel that this is especially useful
for tying into existing legacy systems, but I don't want to
develop a new application, storing new data, that is tied to
a specific storage methodology such as an RDBMS.

People who wish to customize an application to leverage
their existing legacy data should be free to do so, but I've
noticed that Zope products that have some external system as
a pre-requisite (Worldpilot, ZCommerce, etc.) are deployed
far less often than those which do not (Squishdot, Zwiki,
etc.).

So, again: Has anyone run up against any performance or
other limitations regarding large numbers (hundreds of
thousands or more) of objects stored within the ZODB either
in a BTree Folder or a Rack?

In other words, will the system slow down if you add enough
objects?

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 )




Re: [Zope-dev] Massive scalability

2001-01-14 Thread Michael Bernstein

Steve Alexander wrote:
 
 Michael Bernstein wrote:
 
  I am currently planning two separate 'Archive' type
  projects/Products. In both cases, I need to make sure that
  my implementation will scale to hundreds of thousands or
  even millions of objects.
  
 
  In one project the objects are very simple ZClasses with a
  few attributes, in the other project, the objects will be
  instances of the Photo Product, and considerably larger.
 
 Do you mean "instances of the Photo Product" or "instances of class
 FooBar from the Photo Product" ?

Sorry. I meant instances of class Photo from the Photo
Product.

  Does anyone know if there are any inherent
  limitations on the number of objects that can be stored in a
  Rack? are there any performance limitations at the scale
  that I'm talking about?
 
 If you're talking about the BTree implementation that Racks use when
 they store data in the ZODB, well, I've never stored more than a few
 thousand objects in one of those. There certainly aren't the same
 limitations that you get with the default ObjectManager, as that uses a
 python dict to hold its sub-objects.
 
 The performance limitations will more likely be to do with searching and
 indexing the data, adding the data in bulk (if you need to do this), and
 retrieving the data if you have a vast number of clients wanting it all
 at once.

Yes, I was referring to the way a Rack stores data in the
ZODB.

Photo instances store several sizes of the same image as
attributes of the object, as well as various meta-data
fields. I anticipate indexing the meta-data in a ZCatalog.

Data will not be added in bulk, but several people may want
to retreive the data at the same time (if the site becomes
popular).

  The other implementation I'm considering is to create a
  ZClass that inherits from ZCatalog and Btree Folder.
 
 I can't think why you'd want to do that. What role would instances of
 this class play in your application?

The same as the Rack. A single archive of indexed objects.
It seems that this would scale better than creating a ZClass
that inherits from ZCatalog and ObjectManager as described
here:

http://www.zope.org/Members/tseaver/inherit_ZCatalog

  Would
  this approach run into any scalability problems with the
  number and type of objects I'm talking about?
 
 I think other aspects of your application will determine whether it will
 scale. Scalabillity is an emergent property of a system. You only get to
 know about it when you consider the system holisticly.

The system is fairly simple: I want to store a large number
of objects in a single location, I want to index them in a
ZCatalog, I want to find objects by either searching for
them, or by browsing a ZTopics based heirarchy (that is
populated with ZCatalog searches as well).

The search time (whether a user or ZTopic initiates it)
should happen fairly fast, regardless of the number of
objects (potentially hundreds of thousands), and direct
object retreivals (or rendering) should also happen quickly,
without major penalties for the number of objects.

 With Zope, where you store objects and how you plan to find objects, is
 more significant than what the objects you're storing are.

I hope I've explained myself better this time.

Thanks for the help,

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] ZPatterns implementation question: images attributes?

2001-01-13 Thread Michael Bernstein

RDM wrote:
 
 I have a specialist (actually, EMarket has a specialist grin) that
 manages objects that from a design point of view I think should have
 a couple of Images as attributes (thumbnail and fullsized images of
 the product).  The question is, how do I implement this using
 ZPatterns?  Currently all of the other object data is pulled from an SQL
 database.  I don't mind storing the Images in the ZODB, but I'm having
 a hard time finguring out how I would implement that.

I've been thinking about my own need for a massive
searchable image archive, and have been wondering if I could
reimplement the ZPhotoAlbum TTW product (which inherits from
ZCatalog and ObjectManager) as a Specialist with a Rack of
Photo objects (Photo is a 'normal' Python Product), but I'm
unsure of how to go about this.

I've also been considering creating an ImageArchive ZClass
that inherits from ZCatalog and BTree folder, so I have
infrastructure that is better suited to managing thousands
(potentially hundreds of thousands) of objects.

Any ideas would be welcome.

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] Massive scalability

2001-01-13 Thread Michael Bernstein

I am currently planning two separate 'Archive' type
projects/Products. In both cases, I need to make sure that
my implementation will scale to hundreds of thousands or
even millions of objects.
In one project the objects are very simple ZClasses with a
few attributes, in the other project, the objects will be
instances of the Photo Product, and considerably larger.

One implementation I'm considering is a simple Specialist
with a Rack. Does anyone know if there are any inherent
limitations on the number of objects that can be stored in a
Rack? are there any performance limitations at the scale
that I'm talking about?

The other implementation I'm considering is to create a
ZClass that inherits from ZCatalog and Btree Folder. Would
this approach run into any scalability problems with the
number and type of objects I'm talking about?

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 )




Re: [Zope-dev] New UI for 2.3

2001-01-12 Thread Michael Bernstein

Brian Lloyd wrote:
 
 make a 32 pixel-high concession to a small pittance of
 branding?
 
 The top frame is also a place where we might want to put
 more
 "placeless" operations like logout in the future. You can
 only
 jam so much into the tree pane without it looking very much
 like way too much is being jammed into the tree pane :)

I think that the top pane contents should be put into the
top of the tree pane. In either case, you are pushing the
tree pane contents down 32 px, but by putting the logo et al
in the tree frame, you will at least not be sacrificing the
top 32 px of the main frame.

As far as the 'branding' issue is concerned, I do not
begrudge DC and Zope the recognition they deserve, as long
as it doesn't get in the users way.

As an alternative to placing the 'branding' and 'placeless'
content into the tree frame directly, you might consider
splitting the tree frame instead. This would keep the logo
visible, but would no longer take up screen real estate from
the main frame.

Does DC do any usability testing on proposed UI changes?

HTH,

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] Debugging Zope with Komodo

2001-01-12 Thread Michael Bernstein

Andy McKay wrote:
 
 My lips are sealed.

You're being coy.

Here is the URL:
http://www.activestate.com/Products/Komodo/

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] New UI for 2.3

2001-01-10 Thread Michael Bernstein

Steve Alexander wrote:
 
 I think the new UI for 2.3 is great improvement over 2.2.
 
 I'm already finding the sorted tables of folder contents useful, and
 having the add new items select at the top saves time.
 
 However, I do not like the 3-frame interface. I feel that the top frame
 is wasted space. The Zope logo and "Logged in as username | Logout"
 could as easily go at the bottom of the tree-view frame on the left.
 This would leave extra screen space for doing work.
 
 I also much prefer blue to black as a background colour for the tabs and
 the "Root Folder" link. The black seems a bit overbearing.

Hmm. I haven't checked out the new interface myself yet, but
I wonder if DC did any usability testing on their new UI?

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] CatalogAware

2001-01-08 Thread Michael Bernstein

Chris Withers wrote:
 
 Michael Bernstein wrote:
 
  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.
 
 Look at Shane Hathaway's BTree Folder :-)

Interesting idea, I hadn't considered that as a solution.
Has anyone created a ZClass that inherits from BTree Folder
and ZCatalog?

  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.
 
 Well, all the postings are actually stored in SquishSite.data, so
 they're not actually 'contained' in the SquishSite object, hence they
 don't show up in the contents tab. A bit of magic in
 SquishSite.__getitem__ makes the postings URL traversable.

Interesting.

Thanks for the info. I've been using Squishdot a long time,
and I never knew that.

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] CatalogAware

2001-01-05 Thread Michael Bernstein

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] CatalogAware

2001-01-04 Thread Michael Bernstein

Chris Withers wrote:
 
 Erik Enge wrote:
 
  Are you saying that, as a general rule, inheriting from CatalogAware
  and using index_object, reindex_object and unindex_object does not
  work?
 
 It probably does, but if you're a catalog yourself anyway, as Squishdot
 is, it just more overhead rather than calling your own catalog_object
 and uncatalog_object methods ;-)

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?

index_object, unindex_object, and reindex_object (the
CatalogAware methods) are all methods on the object to be
indexed, not methods of the catalog, as I understand. When
called, they find the nearest (acquisition-wise) ZCatalog
(named Catalog by default), and cause catalog_object and
uncatalog_object to be called on it (I'm not sure what
method reindex_object causes to be called).

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


Do I have this correct?

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] CatalogAware

2001-01-04 Thread Michael Bernstein

Erik Enge wrote:
 
 [Michael Bernstein]
 
 | When called, they find the nearest (acquisition-wise) ZCatalog
 | (named Catalog by default),
 
 I think you can specify the ZCatalog it should index itself in by
 putting the default_catalog attribute in your class.

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*. Therefore,
it will then look for the nearest catalog of the name that
you have redefined as the default.

So if you redefine it to be ZCatalog1, and you have the
following structure:

/
|-/Catalog
|
|-/ZCatalog1
|
|-/folder1
|  |
|  |-/folder1/ZCatalog1
|
|-/folder2

Assuming a CatalogAware ZClass has had it's default_catalog
defined to be 'ZCatalog1', and that an instance of this
ZClass is then added in /folder2, it will index itself in
/ZCatalog1, whereas an instance that is added in /folder1
will index itself in /folder1/ZCatalog1.

This is my current understanding, I apologise if what I've
said is incorrect.

HTH,

Michael Beernstein.

___
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

2001-01-03 Thread Michael Bernstein

Chris Withers wrote:
 
 Michael Bernstein wrote:
 
  If you are writing your own cataloging and uncataloging
  code, then I think that it could be.
 
 G
 
 The cataloguing code in Squishdot amounts to about 4 lines, all of which
 are calls to standard ZCatalog interface methods as described in:
 http://www.zope.org/Members/michel/Projects/Interfaces/ZCatalog
 
 If you don't believe me, grep squishdot.py for catalog_object and
 uncatalog_object...

Ok, I believe you! Don't get mad just beacause I was asking
a question. I guess I didn't understand. In fact, if
catalog_object and uncatalog_object are interchangeable with
index_object and unindex_object, then I'm sure I don't
understand the point of inheriting from CatalogAware at all.
Is it reindex_object, which doesn't seem to have an
equivalent?

  I
  was asking why Posting objects shouldn't inherit from
  CatalogAware?
 
 That wouldn't actually change the number of catalog-related lines of
 code in Squishdot. It was merely increase the compelxity of the product
 by adding CatalogAware as another base class for postings.

All right.

Scratching-my-head-over-this-whole-CatalogAware-thing-ly
yrs,

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] CatalogAware

2001-01-03 Thread Michael Bernstein

Chris Withers wrote:
 
 Michael Bernstein wrote:
 
  I guess it's just a matter of only reinventing the wheels
  you have to, and writing less code as a result.
 
 I'm pretty sure Squishdot is re-inventing no wheels ;-)

If you are writing your own cataloging and uncataloging
code, then I think that it could be.
 
  http://www.zope.org/Members/tseaver/inherit_ZCatalog
  http://www.zope.org/Members/AlexR/CatalogAware
 
 These are both pretty old and seem to be aimed at ZClasses.
 Squishdot has nothing to do with ZClasses.

I realize that Squishdot is a Python product, of course. As
far as the information being old, it's tested. I just used
it to build a new application this week. No bugs.

 CatalogAwareness is of no use for a product like Squishdot.
 Squishdot already inherits from ZCatalog.

I realize that Squishdot already inherits from ZCatalog, I
was asking why Posting objects shouldn't inherit from
CatalogAware? I don't think that only ZClasses can inherit
from CatalogAware, that doesn't seem quite right.

Again, it's certainly possible that I'm overlooking
something.

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] CatalogAware

2001-01-02 Thread Michael Bernstein

Chris Withers wrote:
 
 Michael Bernstein wrote:
 
  Hmm. Aren't postings CatalogAware? If they're not, shouldn't
  they be?
 
 Why? ;-)
 
 Squishdot manages the cataloging, re-cataloging and un-cataloging of its
 own postings. I don't think CatalogAware would make that process any
 simpler or more reliable...

I guess it's just a matter of only reinventing the wheels
you have to, and writing less code as a result. Squishdot
seems like it would fall into the category covered by the
following howtos:

http://www.zope.org/Members/tseaver/inherit_ZCatalog
http://www.zope.org/Members/AlexR/CatalogAware

But I'm probably overlooking something.

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 )




[Zope-dev] Re: [squishdot] ZCatalog reindex_object

2000-12-31 Thread Michael Bernstein

Chris Withers wrote:
 
 Michael Bernstein wrote:
 
  reindex_object - should be called when an object is edited
 
 Hmmm... didn't see this method listed in the interfaces wiki. Where did
 you find it?

I found it in the 'Creating a CatalogAware ZClass' HowTo:
http://www.zope.org/Members/AlexR/CatalogAware/

 I just inserted a call to catalog_object which did the job but I wonder
 what the difference between index_object and reindex_object and
 catalog_object is?

Dunno. Sounds like a question for the main Zope list.

HTH,

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] Loginmanager and local roles

2000-12-20 Thread Michael Bernstein

"Morten W. Petersen" wrote:
 
 [Morten W. Petersen]
 
 | Any suggestions?
 
 Found the problem.  There needs to be a method called user_names
 in the acl_users folder, which returns all the user ids:
[snip solution]

Sorry I didn't see your question earlier. Here was what I
posted to the list back in September when I was having the
same problem. Of course, it took me a whole week to figure
out.

http://lists.zope.org/pipermail/zope-dev/2000-September/006953.html

http://lists.zope.org/pipermail/zope-dev/2000-September/007030.html

The second posting includes instructions for fixing
PersistentUserSouce.py, which is part of Membership.

Cheers,

Michael.

P.S. If you can help generalize the solution so it works for
multiple user sources, I'd be grateful.

___
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] Preliminary test of Membership on CVS

2000-12-18 Thread Michael Bernstein

Bill Anderson wrote:
 
 On a related note, I am considering changing the python methods to
 Python Scripts, this way when 2.3 comes out, it drops the number of
 additional installs required by one, leaving Loginmanager and ZPatterns
 the only (current) requirements. Python Scripts eem much better to use
 than Python Methods anyway ;)
 
 Any thoughts on that from the community?

Bill,

The move to Python Scripts sounds like a good one.

BTW, Can you fold in my local roles changes, and create an
additional Type of User Source for use with SMB? I'll
contribute the code that I've got.

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] Validation

2000-12-13 Thread Michael Bernstein

Chris Withers wrote:
 
 Brad Clements wrote:
 
  I keep making this patch to each Zope release, but would like to talk
  about a more permanant and "correct" solution. What do others think?
 
 Validation as a whole could do with looking at, it's be great if there
 were hooks to catch validation problems rather than just raising
 exceptions...

 Along with the TTW ability to define new variable types to
be validated (and their validation methods), such as :email,
:12hTime, :24hTime, :URL, :fqURL (fully qualified URL), and
others.

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] ANN: Extended ManagementTabs Mixin for Python Product Developers

2000-12-10 Thread Michael Bernstein

Johan Carlsson wrote:
 
 Hi,
 I just uploaded my Extended ManagementTabs Mixin Product you can find it at:
 
 http://www.zope.org/Members/johanc/ExtendedManagmentTabs/ExtendedManagmentTabsMixin/
 
http://www.zope.org/Members/johanc/ExtendedManagmentTabs/ExtendedManagmentTabsMixin/
 
 It's should supply any Python Product with multi-level management tabs
 without breaking existing code (peppar peppar). If not please let me know.

Sounds interesting. Can you add a few screenshots to the
product page?

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: Discussion Story Building Mediums

2000-11-11 Thread Michael Bernstein

Chris Withers wrote:
 
 Michael Bernstein wrote:
 
  After some more thought, I realized that this really needs
  to be a three-way gateway betrween a mailing list, a 'blog,
  and a newsgroup.
 
 I'm all up for doing the mailing list/weblog type bits but I have no
 idea how news _works_ and how it could be integrated into the Zope
 environment...

Not really, but two-way gateways between mailing lists and
News servers are pretty well understood, so it should be
possible to let the mailing list sit between the two, and
act as a compatibility layer.

What do you think?

Michael.

___
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] Paul comments on the PythonLabs Move

2000-10-30 Thread Michael Bernstein

Check out his comments here:

http://weblogs.userland.com/zopeNewbies/discuss/msgReader$831

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 )




[Zope-dev] Re: [Zope] The Great Python (and Perl) Method Renaming Poll

2000-10-24 Thread Michael Bernstein

Michel Pelletier wrote:
 
 We will be conducting a community poll to decide what to call Python
 (Perl, insert your language here) Methods.
 [snip]
 So, before the poll, we are calling for nominiations from the
 community.  Please send me an email containing one or more candidate
 names.  These names will be added to the list.  No pre-screening will be
 done, so please exercise some discretion if your favorite name is more
 tounge-in-cheek than practical (you never know what the masses will
 decide though!).
 
 Later this week, I will create a web poll where you can vote for your
 favorite.

I would like to suggest that instead of a plurality vote, we
use a 'Borda count', also known as an 'preferential' or
'single-transferable' ballot. Those of you who followed the
recent ICANN election should be familiar with it.

It works like this:

All votes consist of ranking the availble choices according
to desireability (if there are six choices, you would number
them 1-6, each choice must be uniquely ranked, not all
choices must be ranked).

All voters first choices are tallied. If, at this point, one
choice has achieved over 50% of the vote, the vote is over.

If no choice has achieved 50%, the choice with the fewest
votes is removed, and the voters who voted for that choice
have their second choice counted and distributed. If at this
point one of the choices acheives 50%...etc. Lather, Rinse,
Repeat.

This method has the advantage of better representing peoples
true choice, since no one is tempted to vote for a choice
that they simply disapprove of less, because 'otherwise
they're throwing away their vote'.

In a five-way race for example, a plurality may consist of
25% of the vote, thereby ensuring that 75% of the voters
will be pissed off. With a Borda count though, the winner
could be everyone's second-favorite choice, thus better
representing what people want.

There's a few other wrinkles to this, such as situatuions
where not all choices have been ranked. If a voter has only
ranked four choices and a fifth runoff phase is neccessary,
their ballot is discarded, and the 50% mark is recalculated
for that phase to account for the reduced number of ballots.

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] Meaning :-S

2000-10-23 Thread Michael Bernstein

Chris Withers wrote:
 
 Ken Manheimer wrote:
 
  Huh.  We're looking for something neutral, to connote code that runs in
  zope to do some business logic or similar effect.  It should distinguish
  the language used to express the logic - perl vs python vs xslt,
  etc.  I hate "script", but it occurs to me that the "-let" convention may
  be useful:
 
  Python Zopelet
  Perl Zopelet
  XSLT Zopelet
 
  Zope-specific, runs on the server, shows the implementation language,
  won't be confused with non-remotely-editable functions, methods, scripts,
  code in general.
 
  This is the first one with which i'm comfortable - but i may well have
  missed something.
 
 ...yeah, Zopelet means absolutely nothing, and will just add to
 confusion :-(
 
 Chris . o O ( what the hell is a Zopelet? ;-)

I have to say that I don't like Zopelet either.

I guess nobody else likes my 'Blocks' nomenclature:

Python Blocks
Perl Blocks
DTML Blocks

As I mentioned before, I tend to use DTML Methods in two
contexts:

- as Views on objects (Templates)
- as building blocks for Views

In one context (Views/Templates), the DTML method is meant
to be accessed directly through the web. In the other
context (Block), the DTML method is only ever accessed by a
View.

I would actually like to have a Block object that is not
directly accessible, without having to go through some
proxy-role rigamarole.

Something else to consider for these two Use Cases of
DTML/Python/Perl Methods/Blocks/Scripts, is that typically
only the Block Use-Case is expected to be re-used through
recomposition, as well as acquisition, while Templates/Views
are usually re-used through Acquisition only.

I'm not sure this has any impact on the 'Method Binding'
argument floating around, but I thought I'd mention it again
in that context.

HTH,

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] Python and Perl scripts

2000-10-20 Thread Michael Bernstein

Michel Pelletier wrote:
 
 Keep in mind also that we are moving towards a new architecture with
 "Documents" and "Templates" (ala HyperDOM).  I think Scripts fits right
 in there:
 
 Documents, Templates and Scripts
 
 or
 
 Documents, Templates and Methods

I tend to think of things as:

Objects, Views (or Templates) and Blocks.

The diference (for me) between a View and a Block is whether
they are intended to be accessed directly by a client
(browser). Blocks also tend to be reuseable in many views (I
typically have a Block (DTML Method) called main_navigation,
for example), and can be composed of other Blocks. Views
like index_html may be reused, but usually through
acquisition, not recomposition.

The lines are fuzzy though, since I'm usually using the same
types of objects (DTML Methods) for both Views and Blocks.
Perhaps we need an object type that is not directly
accessible from a client (but may only be called or rendered
from other objects) in order to clarify the distinction.

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] Better user management: Usership vs. Membership

2000-10-11 Thread Michael Bernstein

Jonas Juselius wrote:
 
 Hello,
 
 I had a look at the Membership product, but I could not get it to work. It
 seems that the PortalMember ZClass in the PortalMembership Product inherits
 from _ZClass_for_LoginUser, which is no longer in the LoginManager...

Were you trying to use Membership with a CVS verson of
LoginManager? Membership 0.7.6 works with LM 0.8.7a and
ZPatterns 0.4.1snap1.

 But
 actually I don't care... I tried to contact Bill about the Membership Prod,
 but he seems to be unreachable because his mail address doesn't work.

Bill just got married, was in the middle of changing network
providers, and his old provider screwed up their IP
addressing (on his wedding day). He says that he'll be back
up Thursday or Friday.

 I found many nice ideas in the Membership product, and I think it would really
 be a good idea to develop it further. Does anybody know about any recent
 developments or what the current status is? Is there going to be a new
 release soon, is anyone even working on the Membership product?

Bill is currently working on re-integrating Membership with
the PTK. I recently found a way of integrating Membership+LM
with the local roles interface. I also modified my copy of
Membership to authenticate off of an NT PDC via SMB from a
Solaris box.

Most LoginManager and Membership discussion happens on the
Zope-PTK mailing list, not Zope-Dev.

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] ZPatterns design questions

2000-10-07 Thread Michael Bernstein

"Phillip J. Eby" wrote:
 
 How (and why) do you distinguish between UI implementation
 and presentation logic?
 
 Presentation logic lives with an object's class, and deals with what that
 object knows about presenting itself.  UI implementation is "glue"
 presentation that lives in a Specialist for use by any object that needs to
 present UI related to objects of the kind the Specialist handles.  The
 terms used here are "official" terminology with precise definitions, btw.
 I am just trying to answer your questions as best I know how.

I'm not sure, but did you mean 'are not' in that last
sentence?

 An example of presentation logic would be a method which displays a form to
 perform some action on the object.  E.g., let's say we have a "Task" object
 with an "Assign To" form.  Tasks are assigned to Assignees, but in a given
 application, there could be many possible kinds of Assignees and the means
 of selecting an Assignee is context-dependent.  Thus, a Task's presentation
 logic cannot implement such a thing directly; it must ask the Assignees
 specialist for a code snippet (UI implementation) that displays an assignee
 selection sub-form within its "Assign To" form.
 [snip]
 The Assignees specialist is responsible for providing an appropriate UI
 implementation (hence the name) for this operation.  It could provide a
 dropdown list, a type-in box with a button to pop up a search window that
 lets you search the employee directory, or any number of other possible
 implementations that would get the necessary data back to the assignment
 method once the form was submitted.  We could include a simple
 implementation with our task management framework, and the application
 integrator would override it if needed for their situation.

Thanks, this is starting to make a lot of sense WRT reusable
frameworks.

Here is where my 'Specialist/Generalist' confusion came
from. It seems to me, that the simple implementation (you
might also call it the default implementation) for the
selector UI in your example should be contained in a
'Generalist' object that could be overridden by a
'Specialist'. This would help make crystal clear the line
between Presentation Logic and Implementation UI, and would
also serve as a useful starting point for creating the
overriding methods in the 'Specialist' by the framework
customizer.

  We have not yet released any actual frameworks based on ZPatterns, [snip]
 
 Isn't LoginManager a framework?
 
 Okay, you've got me there.  I tend not to think of it that way, if only
 because there are many things less than satisfactory about its current
 state of implementation.  For example, if we had it to do over again, I
 would re-work the internal API so that roles, domains, authentication,
 etc., could be controlled by plug-ins on the user sources.  At that point
 there would be no need for different kinds of user sources, as they would
 all be fully generic.  But anyway, I digress.

In light of my own dificulties in adding SMB authentication
to PersistentUserSouce.py, and Bill Andersons dificulties
with password encryption on some Unices, I think that this
would be a *very* worthwhile effort. Such a project might
also give you the mandate to get DC to fix the Zope internal
acl_users interfaces that were getting in your way.

How large of a project would this be?

Thanks for your patience in answering my questions. I think
I'm getting a good understanding of this approach, but I'm
still working on internalizing it.

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] ZPatterns design questions

2000-10-07 Thread Michael Bernstein

Steve Spicklemire wrote:

  - How does this product (simple though it is) exemplify the
  RIPP approach?
 
 pje I'm not sure that you can say it *exemplifies* the RIPP
 pje approach, although it certainly goes along with that
 pje approach.  My hesitation is mainly that it doesn't really
 pje show any of RIPP's major benefits, which are associated with
 pje framework re-use and integration.  For that, you really need
 pje to have more than one kind of object, with some kind of
 pje collaboration taking place.
 
 Hmm.. can anyone thing of a good collaboration 'partner' for
 a simple ToDo list? If it's not too complex.. I'd be happy to
 add it.

I've thought about this since yesterday, and the simplest
kind of 'partner' that I can imagine for a 'ToDo', would be
a 'Deliverable'.

A deliverable would probably have a title, it's own 'Done'
boolean property, and probably an optional DeliverableURL
property. I'm not sure if it would need it's own 'Doer'.

ToDo would need to be reworked so that it's 'Done' property
could only be set if all associated Deliverables (if any)
were also done (Steve McConnel (sp?) calls these 'binary
milestones').

What do you think, is that simple enough?

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] ZPatterns design questions

2000-10-06 Thread Michael Bernstein

Steve Spicklemire wrote:
 
 Ack.. sorry... I was making little changes last night to make sure
 the ZClass was completely consistent with my explaination, and to
 make sure I could start 'from scratch'.

Ok, I just got through stepping through the walkthrough. Thanks! That
*was* a really simple example. Perfect!

I had a few comments:

- You skipped over creating the Product in the Products folder.

- Propertysheets: You don't expressly say that Shared needs to be a
'Common Instance Property Sheet'.

- ToDoManager: I was initially confused as to where this needed to be
created. I tried placing it directly in the Product as well as in the
ZCLass before I tried placing it in a normal folder.

Ok, moving forward, I had some questions about this approach to building
applications:

- What do I need to do to let users add ToDoManagers to their own
folders without creating them from scratch? In other words, How do I
turn ToDoManager into a product?

- The term 'Specialist' implies (at least to me) that this object is
overiding/replacing a 'Generalist' somewhere, but this does not seem to
be the case here. Am I missing something?

- I'm trying to reconcile PJE's methodology of Domain Logic,
Presentation Logic, Data Management Implementation Logic, and User
Interface Implementation Logic. Can you (or Phillip) label each of the
DTML methods as to which category they fall into? And state why, even if
it seems obvious?

- How does this product (simple though it is) exemplify the RIPP
approach? In other words, assume I'm asking annoying whiny two-year-old
'why?' questions after every declarative statement in the tutorial.

Anyway, I'll try to synthesize all of the replies I get (if any) into a
beginners 'Zen of ZPatterns' tutorial.

Thanks again for such a simple example!

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] ZPatterns design questions

2000-10-05 Thread Michael Bernstein

"Phillip J. Eby" wrote:
 
 At 09:49 PM 10/4/00 -0700, Michael Bernstein wrote:
 
 While I wouldn't say that there has been an actual 'paradigm
 shift' between the original RIPP presentation and ZPatterns,
 
 What's happened is that there's been a lot of "implementation shift".  The
 goals of RIPP have never changed, but they are far from being all available
 in convenient form in the ZPatterns implementation of that model. [snip] - we've
 implemented less than half of RIPP at this point.

Ok, That's what's been confusing me. I was thinking that at
least some of the missing functionality was due to a change
of goals.

 I'm sufficiently confused at this point to ask for an
 explanation (with definitions and a *simple* example) of
 your current thoughts on separating 'domain code' from
 'implementation code', both of which still need to be
 separated from 'presentation code' (DTML interfaces), unless
 I'm mistaken. Please assume I'm asking a lot of 'why'
 questions along the way.
 
 Domain logic: methods which implement the basic behavior of an object, by
 manipulating its attributes and by calling methods on itself or other
 objects.  (Including delegation to a Specialist, its own or another.)
 
 Presentation logic: "view" methods which implement user interface by
 displaying object attributes and/or the results of either presentation or
 domain methods, and "controller/view" methods which call domain logic
 methods and display results.
 
 Implementation logic: All of the code and objects contained in a Specialist
 which map between the domain model of an object and its physical storage
 implementation(s).  This category can be further subdivided into data
 management implementation, and UI implementation.
 
 DM implementation deals with storing and retrieving objects and associated
 data, and firing off of implementation rules (e.g. ensure that all objects
 which meet such-and-such criteria are cataloged in catalog Foo).
 
 UI implementation deals with providing snippets suitable for use by
 collaborating classes and/or specialists.  For example, [snip]

How (and why) do you distinguish between UI implementation
and presentation logic?

 Our current practice is to place both domain and presentation logic in
 ZClasses, [snip]

Do domain and presentation logic methods go into the *same*
ZClass, or separate ones (I realize that this may be a
stupid question)?

 dropping down to ExternalMethods or Python bases for the ZClasses
 when domain logic requires things you can't do in DTML or PythonMethods.
 Domain and presentation logic are kept to seperate methods, so that domain
 logic methods can be re-used for XML-RPC or other programmatic interfaces.
 Presentation is usually done in a flexible way, relying upon UI
 implementation hooks where sensible.  (Since objects under a specialist
 acquire from the specialist, it's easy to hook to a specialist-level
 utility method.)

I understood what you were saying until the parentheses.
Could you repeat that part in a different way?

 We have not yet released any actual frameworks based on ZPatterns, [snip]

Isn't LoginManager a framework?

 I'm familiar with the convention of separating 'data' from
 'business logic' from 'presentation logic', but this new
 four-way separation (storage, domain, implementation, UI) is
 confusing the heck out of me.
 
 There's really only three: Presentation, Domain, and Implementation.  These
 largely correspond to Coad's UI, PD, and DM/SI, although we're also mixing
 UI snippets into the DM/SI part, simply because that's the locale for
 customization/integration.  (In general, we do not assume that placing more
 than one kind of thing together as neighbors in the same place is a
 problem.  It's what things *reference* that makes their implementation
 clean or dirty, not necessarily who their neighbors are in the Zope object
 tree.)

Ok. That makes some more sense. (still working on the Zen,
though)

 I know that both of you (Phillip and Ty)  are very busy
 right now, but could you perhaps give us a few short
 installments? Starting at the beginning (wherever that is),
 of course.
 
 How's the above for a beginning?

Great! Now I need a really stupid-simple example. Something
that could have been implemented trivially by using Zope's
built in objects, maybe a ZClass, and a bit of DTML, like a
list of press releases, or a FAQ, or a company directory.
Something *really* simple, so I can see how it's done with
ZPatterns.

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 )




Re: [Zope-dev] LoginManager ownership bug!

2000-10-05 Thread Michael Bernstein

Jonas Juselius wrote:

 Another thing which I have tried to do, is to add  support for local roles to
 the LoginManager. At first it looked rather simple, but then I realized that
 it wasn't really _that_ simple, and dropped it because I don't have time... It
 would however be nice to have local roles support in the LoginManager, as it
 would make it more complete.
 
 I am currently using Zope-2.2.1 (and Zope-2.2.2), ZPatterns-0-4-2a1 and
 LoginManager-0_8_7a1.

I used Membership 0.7.6 on top of what you've got, and added
support for local roles as detailed in this posting:

http://lists.zope.org/pipermail/zope-dev/2000-September/007030.html

This ought to give you the clues you need to add the
neccessary getUserNames method to a SQL User Source, and
make the LoginManager user_names modification as well. If
you have any ideas on how to generalize the user_names
method, I'd like to hear them.

Let me know how it goes,

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] ZPatterns design questions

2000-10-05 Thread Michael Bernstein

Steve Spicklemire wrote:
 
 Ack.. of course I forgot to test creating new instances there
 was a snippet of code for editing and creating that didn't work with
 the new propertysheet stuff. I fixed it just now... so it really
 works. ;-)

I didn't get a chance to play with this today, but I'll make
time to do so tomorow. How easy would it be for you to write
a step-by-step HowTo/WalkThrough of creating the example? I
can edit it and flesh it out if you can write a bare-bones
version.

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 )




Re: [Zope-dev] ZPatterns design questions

2000-10-05 Thread Michael Bernstein

Steve Spicklemire wrote:
 
 Again.. this is an embarrassingly trivial example.. but here it goes:
  [snip details]
 That's it.  I can't imagine anything simpler. ;-) Really!

Thanks, I'll be trying this out at work tomorrow.

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] ZPatterns design questions

2000-10-04 Thread Michael Bernstein

"Phillip J. Eby" wrote:
 
 Ty and I use ZClasses because you can see your changes much more quickly
 than if you have to restart Zope.  Basing your ZClasses on DataSkin makes
 the limitations pretty much disappear, from our point of view, because we
 never put any actual "implementation" code in our ZClasses: just domain
 logic, property sheets and UI (DTML) methods.  All the actual mapping
 to/from data storage is carried out in the appropriate Rack or Specialist,
 neatly seperated.  Occasionally we need an ExternalMethod in either the
 ZClass or the Specialist, but these are getting rarer as we find ways to
 create method-like helper objects that can be added through the Zope UI to
 accomplish common tasks.  In general, we prefer that Python written outside
 of PythonMethods be re-usable for a variety of projects rather than a
 one-up for a specific application.  YMMV.  :)

While I wouldn't say that there has been an actual 'paradigm
shift' between the original RIPP presentation and ZPatterns,
I'm sufficiently confused at this point to ask for an
explanation (with definitions and a *simple* example) of
your current thoughts on separating 'domain code' from
'implementation code', both of which still need to be
separated from 'presentation code' (DTML interfaces), unless
I'm mistaken. Please assume I'm asking a lot of 'why'
questions along the way.

I'm familiar with the convention of separating 'data' from
'business logic' from 'presentation logic', but this new
four-way separation (storage, domain, implementation, UI) is
confusing the heck out of me.

I know that both of you (Phillip and Ty)  are very busy
right now, but could you perhaps give us a few short
installments? Starting at the beginning (wherever that is),
of course.

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 )




Re: [Zope-dev] Trying to catch up - what are the best Zope tools today?

2000-10-04 Thread Michael Bernstein

Itai Tavor wrote:

 Can anyone provide a quick rundown of the best choices for building a
 production site at this time? I'm going to need sessions, user
 registration and login, and the usual array of e-commerce pieces
 (products, carts, orders, payments...), with all data stored in SQL.

As far as user registration and logins, LoginManager in
conjunction with the Membership product seem to have reached
a semi-stable implementation. It took me some serious
skull-sweat to figure them out enough to do SMB
authentication from a Solaris box off of a NT PDC, and some
more to get LM to participate in the local roles machinery,
but once I did, it's been working really well. I assume that
creating an SQL UserSource won't be any more dificult. Good
Luck.

Warning: :-)

The current membership product has not yet been
re-integrated with the PTK, so the implementation (though
stable) may have further architectural changes coming down
the pipe.

HTH,

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: Discussion Story Building Mediums

2000-10-02 Thread Michael Bernstein

Chris Withers wrote:
 
 Michael Bernstein wrote:
  It seems to me that there is a potential 'bridge' between
  the mailing lists and the wikis - The mailing list archives!
 
 snip details
 
 I like this idea a lot :-)

After some more thought, I realized that this really needs
to be a three-way gateway betrween a mailing list, a 'blog,
and a newsgroup. The 'blog is obviously the most different
from the other two, as 'blogs usually excersize editorial
control over the root items, but none (or little) over the
ensuing discussion. This is markedly different from both
mailing lists and newsgroups, where moderation is on all of
the postings.

Assuming that gets accomplished, this should take care of
everyones 'discussion' needs, after which the trick is
promoting certain things to permanent collaborative
artefacts, like wikis.

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] Membership and Local Roles

2000-09-23 Thread Michael Bernstein

Michael Bernstein wrote:
 
 Michael Bernstein wrote:
 
  I figured out how to get this to work (finally).
 
  In the acl_users LM, add the following two Python methods:
 
 Well, I discovered another problem:
 
 For some reason, when I create a PortalMembership member, add the two
 Python methods as I described earlier, and use the local roles screen to
 give them a role, they are subsequently authenticated regardless of
 whether their password is correct.
 
 Here's an example illustrating the bug:
 
 [snip example]

This password problem is fixed with Bill Andersons new
release of Membership 0.7.6, so the local roles fix now
works generally.

There is still a platform dependent password problem with
Membership though. It affects Solaris and HPUX (possibly
other unices) but not Linux, and has to do with the crypt
module not being loaded correctly on those platforms,
causing passwords to be encrypted omly part of the time.

Here is the fix for local roles:

First, the User Source needs to support a getUserNames
method. This can be done two ways:

You can add a Python method to the LoginManager named
getUserNames that takes a 'self' parameter, and has the
following body:

 user_ids=self.UserSource.getPersistentItemIDs()

 names=[]
 for i in user_ids:
 names.append(i)
 return names

Or you can add the following code directly to the
PersistentUserSource.py file, preferably right befor or
after the getUsers method:

def getUserNames(self):
user_ids=self.getPersistentItemIDs()
names=[]
for i in user_ids:
names.append(i)
return names

(I hope this will get included in future versions of
Membership)

Next we need to provide a user_names method in the
LoginManager. Currently I only have a Python method to drop
in to the LM. it takes a 'self' parameter, and has the
following body if it's calling another Python method:

return self.getUserNames()

Or if you're calling the method in PersistentUserSource.py,
it has this body:

return self.UserSource.getUserNames()

Note that this user_names method has some disadvantages, and
it needs to be generalized to deal with multiple User
Sources that aren't all named UserSource, and that may not
all implement the getUserNames interface, and that may have
duplicate user names in them.

Suggestions on how to do this would be welcome.

I hope that this little set of instructions helps others who
are trying to integrate LM with the existing security
interface and local roles.

Comments, testing, and improvements would be welcomed.

HTH,

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] Membership and Local Roles

2000-09-18 Thread Michael Bernstein

I posted this to the PTK list on Friday, but didn't get any responses
over the weekend, so I'm reposting here.

I feel that a barrier to Loginmanager and Membership becoming more
generally usable for site builders is it's current lack of support for
local roles. Specifically, members do not show up in the local roles
screen (manage_listLocalRoles) user list.

Through the magic of grep and find, I think I've identified the relevant
sections of code in Zope that need to be duplicated in Membership (or
maybe in LoginManager).

First I tracked down what seems to be the relevant section in
/lib/python/AccessControl/Role.py, in the section labeled 'Local roles
support':


def get_valid_userids(self):
item=self
dict={}
while 1:
if hasattr(aq_base(item), 'acl_users') and \
   hasattr(item.acl_users, 'user_names'):
for name in item.acl_users.user_names():
dict[name]=1
if not hasattr(item, 'aq_parent'):
break
item=item.aq_parent
keys=dict.keys()
keys.sort()
return keys


Then I tracked down the user_names attribute to
/lib/python/AccessControl/User.py, in the section labeled 'Private
UserFolder
object interface':


def user_names(self):
return self.getUserNames()


Well, that wasn't very helpful. searching a bit more and I find:


def getUserNames(self):
"""Return a list of usernames"""
names=self.data.keys()
names.sort()
return names


Experimenting a bit, I find that a normal user folder object responds to
an /acl_users/user_names URL with an error, but does respond to an
/acl_users/getUserNames URL with a list of user names.

And now I'm stuck. I *think* that LoginManager needs a getUserNames
method that cycles through the available User Sources and grabs a list
of
names from each, concatenating them into one big list to return. I'll
settle for some code that has the User Source name hard-wired in,
though.

However, IANAC (I Am Not A Coder), and I don't know how to do this. If
anyone can offer a cut-and-paste set of instructions to add this into
LoginManager or Membership, it would be greatly appreciated.

If I've missed something obvious or misunderstood the problem, please
tell me that too.

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 )




Re: [Zope-dev] Membership and Local Roles

2000-09-18 Thread Michael Bernstein

Steve Alexander wrote:
 
 Michael Bernstein wrote:
 
  I feel that a barrier to Loginmanager and Membership becoming more
  generally usable for site builders is it's current lack of support for
  local roles. Specifically, members do not show up in the local roles
  screen (manage_listLocalRoles) user list.
 
  Through the magic of grep and find, I think I've identified the relevant
  sections of code in Zope that need to be duplicated in Membership (or
  maybe in LoginManager).
 
 I don't know for sure, but I think the API for returning a list of users
 has been omitted intentionally. A LoginManager instance might "contain"
 (or rather, provide authentication to) thousands of users. Listing all
 of these would arguably break the management interface.

I think I saw at least one proposal on a UI change to better accomodate
large numbers of users, and I agree that this is neccessary. But right
now, I need LoginManager to hook into the current management interface
infrastracture to be useful.

In any case, many deployments with that many users will be using LM for
authentication only, and won't be instantiating user objects for them.
This means that you don't have any user objects to list in the Local
Roles UI anyway.

I have less than a hundred users stored persistently (as Members), and
really need to get this working.

 Perhaps what LoginManager (or Membership) needs is a way of stating, for
 each user, whether they should appear in the local-roles list. This
 could be a checkbox for each user, or it could be a method that gets
 called to specify the users that appear, for example, using a regular
 expression, or perhaps based on some quality of the user object.

That sounds like an interesting proposal, and in the absence of a better
one, I'll support it. 

 You should still be able to use local roles, even now, by using an
 external method to add local roles where you need them, and explicitly
 give the user id. You just can't select from the management interface.

Some Products (most notably Tracker) seem to require the same interface
that the local roles UI does, so this approach won't work for them.

IANAC (I Am Not A Coder), except in the most rudimentary sense, and I'm
just trying to get several existing products to integrate smoothly. This
is the last remaining issue (although I'm sure I'll come up with new
ones).

Ideally, I would like a DTML or Python Method that I can drop into the
LM and get this working. Can anybody help with this?

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] Membership and Local Roles

2000-09-18 Thread Michael Bernstein

Steve Alexander wrote:
 
 Michael Bernstein wrote:
 
  I posted this to the PTK list on Friday, but didn't get any responses
  over the weekend, so I'm reposting here.
 
  I feel that a barrier to Loginmanager and Membership becoming more
  generally usable for site builders is it's current lack of support for
  local roles. Specifically, members do not show up in the local roles
  screen (manage_listLocalRoles) user list.
 
  Through the magic of grep and find, I think I've identified the relevant
  sections of code in Zope that need to be duplicated in Membership (or
  maybe in LoginManager).
 
 I think you've found out why local roles don't work. Congratulations on
 a successful code hunting mission :-)

I *think* I've created a getUserNames python method that returns the
appropriate results:


Parameter list:
self

Body:

 user_ids=self.UserSource.getPersistentItemIDs()

 names=[]
 for i in user_ids:
 names.append(self.getItem(i))
 return names


I basically copied the Membership getMembers python method for this.

Guess what? It still doesn't work.

I don't understand the differences between the code I pasted above and
the code on the original getUserNames method (from :

def getUserNames(self):
"""Return a list of usernames"""
names=self.data.keys()
names.sort()
return names

Can anyone tell me what I need to fix?

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] Membership and Local Roles

2000-09-18 Thread Michael Bernstein

Michael Bernstein wrote:
 
 Steve Alexander wrote:
 
  Michael Bernstein wrote:
 
   I posted this to the PTK list on Friday, but didn't get any responses
   over the weekend, so I'm reposting here.
  
   I feel that a barrier to Loginmanager and Membership becoming more
   generally usable for site builders is it's current lack of support for
   local roles. Specifically, members do not show up in the local roles
   screen (manage_listLocalRoles) user list.
  
   Through the magic of grep and find, I think I've identified the relevant
   sections of code in Zope that need to be duplicated in Membership (or
   maybe in LoginManager).
 
  I think you've found out why local roles don't work. Congratulations on
  a successful code hunting mission :-)
 
 I *think* I've created a getUserNames python method that returns the
 appropriate results:

I have made some more progress (of a sort).

I added another Python Method to the LoginManager called user_names :


Parameter list:

self

Body:

return self.getUserNames()


As far as i can see, this should be functionally equivalent to the
user_names method in User.py:

def user_names(self):
return self.getUserNames()


But it doesn't work. On the bright side, I've managed to break the
manage_listLocalRoles local roles screen. This is the first time that
I've had any interaction with the local roles screen, so I guess now I
now I'm messing with the right stuff.

The error message I get is:

Error Type: AttributeError
Error Value: __hash__

Here is the traceback:

Traceback (innermost last):
  File /usr/local/zope/2-2-0/lib/python/ZPublisher/Publish.py, line 222,
in publish_module
  File /usr/local/zope/2-2-0/lib/python/ZPublisher/Publish.py, line 187,
in publish
  File /usr/local/zope/2-2-0/lib/python/Zope/__init__.py, line 221, in
zpublisher_exception_hook
(Object: ElementWithAttributes)
  File /usr/local/zope/2-2-0/lib/python/ZPublisher/Publish.py, line 171,
in publish
  File /usr/local/zope/2-2-0/lib/python/ZPublisher/mapply.py, line 160,
in mapply
(Object: manage_listLocalRoles)
  File /usr/local/zope/2-2-0/lib/python/ZPublisher/Publish.py, line 112,
in call_object
(Object: manage_listLocalRoles)
  File /usr/local/zope/2-2-0/lib/python/App/special_dtml.py, line 121,
in __call__
(Object: manage_listLocalRoles)
  File /usr/local/zope/2-2-0/lib/python/DocumentTemplate/DT_String.py,
line 502, in __call__
(Object: manage_listLocalRoles)
  File /usr/local/zope/2-2-0/lib/python/DocumentTemplate/DT_In.py, line
630, in renderwob
(Object: get_valid_userids)
  File /usr/local/zope/2-2-0/lib/python/AccessControl/Role.py, line 360,
in get_valid_userids
(Object: ElementWithAttributes)
AttributeError: (see above)

Any ideas?

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] Returning a list of names from a Python Method

2000-09-18 Thread Michael Bernstein

Michael Bernstein wrote:
 
 Does anyone on the list know how to change the getUserNames
 Python method to return a list of names instead of a list of
 objects?
 
 The code in question is this:
 
   user_ids=self.UserSource.getPersistentItemIDs()
 
   names=[]
   for i in user_ids:
   names.append(self.getItem(i))
   return names

Ok, I solved this little problem (and of course it looks
obvious once I've done it):

   names=[]
   for i in user_ids:
   names.append(i)
   return names

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] Membership and Local Roles

2000-09-18 Thread Michael Bernstein

I figured out how to get this to work (finally).

In the acl_users LM, add the following two Python methods:

- getUserNames -

Parameter List:

self


Body:

 user_ids=self.UserSource.getPersistentItemIDs()

 names=[]
 for i in user_ids:
 names.append(i)
 return names




- user_names ---

Parameter List:

self


Body:

 return self.getUserNames()



And whatever users or members you've got that are stored
persistently within the User Source will appear in the local
roles screen (manage_listLocalRole).

Preliminary tests show that local roles defined for
LoginManager/Membership users work just as expected.

Thanks to Bill Anderson for pointing out the difference
between returning a list of objects and a list of names,
which was the critical bug in the getUserNames method.

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: Discussion Story Building Mediums

2000-09-15 Thread Michael Bernstein

Ken Manheimer wrote:
 
 Clearly, i agree that the absence of those things in the wiki is a problem
 - i state that directly in the "problems to be addressed" section! *The*
 thing to understand here is that we're currently in a position where
 neither wikis nor maillists, in themselves, provide what we need.  We
 need to do *something* in the meanwhile, if only to bootstrap the
 process so we can get to the point where we have that integration.
 (You'd have to ask brian and the dev folk, but i think the reason
 we're going with wiki is because otherwise all this talk gets **lost**
 - noone has the time to do the transcribing, etc.  At least with wikis
 you can preserve your thoughts and then email interested parties!)

It seems to me that there is a potential 'bridge' between
the mailing lists and the wikis - The mailing list archives!

 I've been challenged with how to fit the WikiNG proposal into the PTK
 - since the PTK is a prime digital creations content management focus,
 management doesn't want to dilute resource assignments with other (eg,
 WikiNG) content-management-oriented efforts.  So i have to figure out
 how it would fit in that frame work - maybe this suggests a way.  I'm
 having trouble fitting my mind around it, though.  Sigh.

What if the mailing list archives were 'PTK-enabled' in such
a way that it was really easy to 'promote' postings to a
wiki page status (preserving the original in the archive)?

What if members of dev.zope.org could automaticaly find all
of their postings and add pointers from them to the relevant
wikis through-the-web?

Wiki pages could serve as the root document for ZDiscussions
that were gatewayed into the mailing lists, as well.

Hmm, if ZDiscussions and the mailing lists were gatewayed
into each other, that would get you a much better archive
interface almost immediately, and you could concentrate on
'promoting' ZDiscussion postings to a wiki page instead.

I'm rambling, but this seems like it would work really well!

HTH,

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] package descriptions

2000-07-07 Thread Michael Bernstein

ethan mindlace fremen wrote:
 
 Michael Bernstein wrote:
 
  Please change the page so both the title and the description
  have the same background color, but that the color is
  alternated between grey and white for odd and even Products.
 
 Ok, well, I've given that a try.  Some people think I should do it some
 other way.  If you feel strongly about it, email [EMAIL PROTECTED]

Thanks, that's a *lot* more legible (I do feel strongly
about it). What other ways are people asking for?

 It also shows the most recently edited products first, and sorting by
 anything or requesting more Member products hides all Digital Creations
 stuff.

Yeah, that's pretty slick. It occurs to me that the same
layout should be used for the How-To's page.

 More Products work is on the way in the medium-term future.
 
 I would still really appreciate it if people would change their products
 page so that the first line is a plain text summary of their product.  I
 have HTML quoted everything, which makes the formatting better, but some
 descriptions are still less than usefull.

Perhaps a 'short_description' property could be added to the
Product, and it would default to 'first line' only if that
property was blank.

 Thanks for your help,

You're welcome.

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] FWIW, ZCVSMixin now at 0.0.2... and rising. ;-)

2000-05-24 Thread Michael Bernstein

Steve Spicklemire wrote:

 I've not heard any comments about the usefulness of this concept...
 am I barking up the wrong tree to get version control of zope objects?
 Does someone know of a better way?

Steve, this has been my fondest hope for about three months
now. Now, if I could also get it to do through-the-web XML
(DocBook) editing and rendering, I'd have a complete
end-to-end document management system. Particularly if it
preserved accountability, like Jonothan was mentioning.

I'll be testing this tommorow, and doing my best to get this
to do unnatural things with XMLWidgets and DocBookDocument.

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




Re: [Zope-dev] eat our own unsupported dog food

2000-05-24 Thread Michael Bernstein

Michel Pelletier wrote:
 
 There is a recent need for us to install ZDiscussions on Zope.org.  I
 have verified that 0.1.0 works with 2.1.6, but I can't seem to d/l
 0.2.0.  The author of said software is not available, any one know the
 status on ZDiscussions?  Has any one tweaked it?

I found this:
http://www.zope.org/Members/BwanaZulia/ZUBB/

HTH,

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] ZPatterns framework improvements

2000-05-21 Thread Michael Bernstein

"Phillip J. Eby" wrote:
 
 So anyway, "index" now seems rather inadequate to describe these indexing,
 search-agenting, business-ruling objects.  (Change Monitors?  Knowbots?
 Indexing Agents?  Index Rules?  Object Matchers?)  If you have any name
 suggestions, I'd love to hear 'em.  :)

- PushMePullYu ;-)
- MetaManager
- Trigger (TriggerManager)
- IndexManager
- RuleManager

HTH,

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 )