[Zope-dev] OSCON 2009 Call For Participation ends Feb 3rd - No Zope proposals yet

[Michael R. Bernstein]

Hi folks,

The deadline for the O'Reilly Open Source Convention Call For
Participation is Tuesday Feb 3rd.

OSCON will be held July 20-24 in San Jose, California.

As of today, there are no Zope-related proposals, so yours could have a
pretty good chance of acceptance. ;-)

There have been a lot of exciting developments in the Zope world in the
past year, and I for one would really like Zope to get more public
exposure. So please, write up your proposals and submit them before the
deadline!

For more information, see
http://conferences.oreilly.com/oscon
http://en.oreilly.com/oscon2009/public/cfp/57

Cheers,

- Michael Bernstein


signature.asc
Description: This is a digitally signed message part
___
Zope-Dev maillist  -  Zope-Dev@zope.org
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] I'd lobe to merge the zope3-dev and zope-dev lists

[Michael R. Bernstein]

On Thu, 2007-10-04 at 09:57 -0400, Jim Fulton wrote:
> Any objections?
> 
> This would basically involve retiring the zope3-dev list and moving  
> zope3 developers to the zope-dev list.

+1

Seems reasonable. The archives for the retired list will remain in
place, right?

- Michael R. Bernstein


signature.asc
Description: This is a digitally signed message part
___
Zope-Dev maillist  -  Zope-Dev@zope.org
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 )

[Zope-dev] Persisting PIL.Image instances in Zope?

[Michael R. Bernstein]

This is a repost from the [EMAIL PROTECTED] mailing list, as I got no
responses there.

For a number of reasons, I find myself wanting to persist instances of
PIL.Image in the ZODB.

Ideally, such a subclass of PIL.Image and Persistent would also be
API-compatible with OFS.Image, but I'd be willing to live without this.

Does anyone already have something like this developed with the bugs
worked out? I'd rather not reinvent this particular wheel if I don't
have to.

-- 
Michael R. Bernstein <[EMAIL PROTECTED]>


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

[Zope-dev] granting access to a single attribute with declarative security

[Michael R. Bernstein]

On Wed, 2002-01-09 at 10:13, Wolfram Kerber wrote:
> >
> > I didn't think you could have more than one
> > setDefaultAccess in a class. If you can, then you can set:
> >
> > security.setDefaultAccess('deny')
> > security.setDefaultAccess({'meta_type': 1})
> 
> The last 'setDefaultAccess' statement in a class will define the actual
> behaviour, i.e use only one.
> 
> > But otherwise, you would have to list all attributes of the class in the
> > dict of a single statement, wouldn't you?
> 
> No, all attributes that aren't in the dict are private.

Thanks, Wolfram. That was very informative.

This will let classes that use declarative security have a deny by
default policy, while still allowing access to certain attributes for
backward compatibility.

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: [ZPT] accessing object attributes from pythonexpression raises error

[Michael R. Bernstein]

On Wed, 2002-01-09 at 01:40, Wolfram Kerber wrote:
> 
> From: "Chris McDonough":
> 
> 
> > > meta_type is an attribute, so you can't just do
> > >
> > > security.declareProtected(ACCESS_CONTENTS_PERM, 'meta_type')
> >
> > That's right.
> >
> > > The id attribute has the getId method, perhaps what's required is a
> > > getMetaType method that can be suitably protected?
> > >
> > > This would still be a pretty easy fix:
> > >
> > > security.declareProtected(ACCESS_CONTENTS_PERM, 'getMetaType')
> > > def getMetaType(self):
> > > """ """
> > > return self.meta_type
> > >
> > > Am I missing something?
> >
> > Nope, that would work.  But I think also:
> >
> > meta_type__roles__ = None
> >
> > .. as a class attr would work as well.
> >
> > I'll try it and let you know if it works.
> 
> security.setDefaultAccess({'meta_type': 1}) should do
> 
> the parameter is what has been __allow_access_to_unprotected_subobjects__,
> that can be a boolean, dictionary or callable

Interesting. I didn't think you could have more than one
setDefaultAccess in a class. If you can, then you can set:

security.setDefaultAccess('deny')
security.setDefaultAccess({'meta_type': 1})

But otherwise, you would have to list all attributes of the class in the
dict of a single statement, wouldn't you?

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: [ZPT] accessing object attributes from python expressionraises error

[Michael R. Bernstein]

On Tue, 2002-01-08 at 14:01, Evan Simpson wrote:
> Michael R. Bernstein wrote:
> > 
> > [snip stuff about accessing a browser_id_manager's
> >  meta_type from unrestricted code raising an
> >  unauthorized exception]
> > 
> > Will this be fixed for 2.5 final?
> 
> 
> That depends.  We're currently waiting for feedback on 2.5b3.  Depending 
> on how that goes, these changes may need to wait for 2.5.1.

Perhaps I am under-estimating how difficult the fix is. I'm assuming
that you simply need to add an appropriate security declaration to the
BrowserIdManager class...

Oh, wait...

meta_type is an attribute, so you can't just do

security.declareProtected(ACCESS_CONTENTS_PERM, 'meta_type')

Hmm...

The id attribute has the getId method, perhaps what's required is a
getMetaType method that can be suitably protected?

This would still be a pretty easy fix:

security.declareProtected(ACCESS_CONTENTS_PERM, 'getMetaType')
def getMetaType(self):
""" """
return self.meta_type

Am I missing something?

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] Zope BOF at Comdex in Vegas?

[Michael R. Bernstein]

As the only (AFAICT) Zope user in Las Vegas, I'd like to propose that
Zopistas that are here for Comdex (Nov 10th through 16th) get together
for a Birds Of a Feather gathering.

This could be a dinner or just meeting for drinks, depending on what
people would like.

How many people would be interested? Does anyone have a preferred
time-frame?

Here's hoping to meet some of you,

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] ZPL2.0

[Michael R. Bernstein]

Sorry for the late replay to the list, I was having some problems with
my mail client which led to replies being rejected by various mailing
lists.

On Fri, 2001-10-12 at 02:38, Chris Withers wrote:
> Kapil Thangavelu wrote:
> > 
> > dealing with RMS is tricky period.
> 
> I am at a loss as to why anyone bothers ;-)
> 
> (nope, this is not an attempt to start a flame war, everybody move
along
> peacefully now...)

No heat in this response :-)

It's pretty simple:

If GPL compatibility in a license is seen as a desirable goal (and it
is, even by some who disagree with the GPL itself), and the FSF in the
person of RMS is the final arbiter of GPL compatibility, then to get
'official' GPL compatibility declared for your license, you have to deal
with RMS.

If your question was actually "why does anyone bother with GPL license
compatibility" then that is a separate discussion.

Cheers,

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 )

Re: [Zope-dev] A modest proposal: Replace medusa with Twisted

[Michael R. Bernstein]

On Wed, 2001-10-10 at 10:47, Andreas Jung wrote:
> 
> From: "Michael R. Bernstein" <[EMAIL PROTECTED]>
> >
> > On Wed, 2001-10-10 at 09:42, Andy McKay wrote:
> > >
> > > Absolutely it may be more work but being able to eventually plug in your
> > > own
> > > front end would be great, be it ZServer, Twisted, Apache or maybe even
> > > IIS
> > > (shudder).
> >
> > How about Tux? Would that even make sense?
> 
> Nope, TUX is linux-only.

Sorry, I meant: "Pre-supposing a pluggable interface, would it make
sense to stick Tux in front of Zope on a Linux box?"

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 )

Re: [Zope-dev] A modest proposal: Replace medusa with Twisted

[Michael R. Bernstein]

On Wed, 2001-10-10 at 09:42, Andy McKay wrote:
> > I think a general proposal for "Pluggable front-ends" would be better
> > received. I know there has been talk about dropping ZServer in favor of
> > Apache 2.0. What would be nice would be to have options.
> 
> Absolutely it may be more work but being able to eventually plug in your own
> front end would be great, be it ZServer, Twisted, Apache or maybe even IIS
> (shudder).

How about Tux? Would that even make sense?

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] 2.5 roadmap and schedule?

[Michael R. Bernstein]

On Mon, 2001-10-01 at 14:51, Brian Lloyd wrote:
> > The current roadmap for Zope 2.5 sets an alpha release date for sometime
> > in september, but is that still likely?
> > 
> > Michael Bernstein.
> 
> Since today is Oct. 1, I would say... no :^)
> 
> The "roadmap" serves as a high-level way for me to relay 
> the basic plan for the next release to those in the community 
> who don't pay day-to-day attention to zope-dev or zope-coders.
> 
> It is also sometimes wrong, since I have to make a best-guess 
> at dates based on circumstances that sometimes change without 
> much notice. The dates are based on my best guesses at what 
> resources will be available when, and sometimes those get 
> pre-empted by things like customer engagements, etc.
> 
> Hopefully my guesses will be less wrong as the community gets 
> more actively involved. That will expand the resource pool 
> which should help - but this will be a learning process. 

>From my POV, I don't mind that you guess wrong, it's just that the
guesses aren't updated when it becomes apparent that they *are* wrong.

It would be nice if the plan for the next release could be updated every
two weeks or so.

So, what is your current best guess estimate for the alpha release of
Zope 2.5?

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 )

Re: [Zope-dev] Zope on Windows/Mac OS X:BatteriesIncludedDistribution

[Michael R. Bernstein]

On Fri, 2001-09-28 at 05:05, Paul Everitt wrote:
> 
> I think, with all the various efforts, it is time to agree on some 
> standards regarding where configuration data lives and how it looks.

I remember that Eric Raymond had created a new language specifically for
describing software configuration options, and that he implemented the
new language using Python:

http://www.tuxedo.org/~esr/cml2/

This may not be appropriate for Zope configuration, but I thought I'd
bring it up.

HTH,

Michael Berrnstein.


___
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: [DISCUSS] Committer agreement not even handedand threadening

[Michael R. Bernstein]

On Fri, 2001-09-28 at 08:32, Paul Everitt wrote:
>
> Dieter Maurer wrote:
> 
> > Paul Everitt writes:
> >  
> > 
> > The "Committer Agreement" does not seem to be even handed:
> > 
> >The committer transfers rights immediately and indefinitely
> >to Zope Corporation (the contributions become a gift to
> >Zope Corporation).
>
> This is an inaccurate representation.  Transfer means you lose the 
> rights and we gain the rights.  Under joint ownership, both have rights. 
>   I think this point was abundantly clear, so I'm surprised to see you 
> portray this as a gift.

Hmm. So, the copyright to the contributed code is held jointly? or does
the contibutor simply grant a non-exclusive license to Zope Corp
(including the right to relicense)?

> >The agreement states explicitly that no rights are transfered
> >to the committer.
> 
> Because they never lost any rights.

This is correct. The contributor gets access to the entire source code
under the ZPL anyway, even without making a contribution. No additional
rights need be asigned from ZC to the contributor, IMO.
 
> >This is not a problem in itself. However
> > 
> >   My intention to contribute would be to strengthen
> >   the Open Source Movement. A statement that
> >   the supported code base (Zope) will remain open source
> >   and that committers will be able to use it (indefinitely)
> >   under terms comparable to the current ZPL would
> >   help to let the agreement to appear more balanced
> 
> 
> I don't think it's really feasible to 100% guarantee things in the 
> future.  Rather, the agreement states that current code, and any 
> contribution, will be available under the ZPL.  Nothing can be 
> retracted.  If someone comes along and gives us one trillion dollars to 
> stop releasing our work as open source, two things would happen:
> 
> 1) First, we'd take the money. :^)
> 
> 2) Second, all the existing code has to remain available under the ZPL. 
>   We just wouldn't do _new_ things under a ZPL.
> 
> This is part of the safety of joint ownership.  If you don't like what 
> we do in the future, you still have rights on your contribution

This prospect (of future ZC code being non-ZPL), while remote, is why I
beleive that it is important that the ZPL be GPL-compatible.

In that scenario (and I stress again that I think it is unlikely), where
future ZC development was proprietary and unavailable to the community,
it's important that it be possible for the community to respond by
making subsequent community contributed code GPL, and therefore
unavailable to proprietary vendors (trhis includes the hypothetical evil
mirror-universe ZC, who will all have beards).

Unless the ZPL is GPL-compatible (at least), this will not be possible,
as it is currently not possible to create GPL licensed products that
subclass ZPL'd Zope classes.

I am *not* advocating that the opening of the CVS repository be held up
for this, I just want to make sure that the goal of making the ZPL GPL
compatible remains on the agenda.

> > The "Commitrer Agreement" is quite threadening:
> > 
> >A committer takes over a considerable risk (complete warranty
> >and indemnification with respect to intellectual rights infringement).
> 
> Yes.  You can't make the risk disappear.  Someone has to bear the risk. 
>   It makes zero sense for ZC to bear the risk of what goes on in someone 
> else's brain.  Even in the scenario of carelessness, a case will have to 
> be made regarding what you knew and when you knew it.

This is another area where I agree with Paul. Publishers frequently
require authors to sign a 'warants and represents' clause that has the
same effect. *Good* publishers still cover legal costs for unsuccessful
lawsuits, so that the author isn't left hung out to dry when someone
files a 'slapsuit'.

I think the same standard should be applied here.

> >Otherwise, commiting anything might easily ruin an individual.
> 
> 
> Instead, you'd prefer that it ruin ZC?  Or are you asserting that 
> somehow we could make it so that nobody would be held accountable?

The contributor should be held accountable in the event of a
*successful* lawsuit. but it isn't reasonable to expect an individual to
have to defend against frivolous lawsuits from large corporations.

> >Especially with the strange US Patent Laws (where almost
> >everything (such as presenting information in a popup window
> >or integrating a Web Frontend with a baking oven) can
> >be patented) and incredibly high damages amounts
> >(5 billion for a smoker who got cancer) assigned in US courts.
> 
> Unfortunately that's the jurisdiction in which we operate.

Thankfuly, our legal jurisdiction also has provisions for countersuing
those who engage in underhanded legal tactics (such as slapsuits) for
legal costs and damages, but a large corporation can still bankrupt an
individual, making that option 

[Zope-dev] 2.5 roadmap and schedule?

[Michael R. Bernstein]

The current roadmap for Zope 2.5 sets an alpha release date for sometime
in september, but is that still likely?

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] Adding a permission to an ObjectManager derived ZCLass

[Michael R. Bernstein]

Hi all,

I posted this 24 hours ago on the main zope list, but didn't receive a
response, so I'm reposting here.

I've got an ObjectManager and Folder derived ZClass that contains
instances of a second rather simple ZClass.

It works fine, the Manager role can access the management interface of
the container, add edit and delete instances of the contained ZClass,
and Anonymous can view index_html.

Now, I am trying to add a permission to the container ZClass that will
let a user with a specialized role that has the permission view the
management interface (the 'Contents' tab) of the container and add,
edit, or delete the simple ZClass instances in the container.

The container doesn't have any property sheets, but the simple ZClass
does.

Does anyone have a simple walkthrough of what I need to do? The Zope
Book only discusses adding a permission to control access to a Property
Sheet.

Thanks in advance,

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: Barriers to Zope popularity: Part 2: sourcecontrol

[Michael R. Bernstein]

On Tue, 2001-09-25 at 18:16, Chris Withers wrote:
> 
> PS: Anyone using DTML or ZClasses for this kind of thing in this day and age
> should be shot ;-)

Personally, I think all extremists and fanatics should be shot.


Oh yeah, I forgot, ;-)

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 )

Re: [Zope-dev] Vulnerability in Zope

[Michael R. Bernstein]

On Sun, 2001-09-23 at 17:00, Andy McKay wrote:
>
> [snip]
> Haven't we been complaining about this automatic appending of
tracebacks for
> a while? To me this is what log files are for but Im not sure what this
> guy is on. I wouldnt count this as a "security vulnerability".

Hmm. It's 'side-band' information. Assuming that a cracker could get
arbitrary code to run on the server through some other vulnerability
(say a buffer overflow in some daemon), this information could be
exploited to make their attack on the Zope installation more targeted.

All this is assuming that the cracker in question is very clever, and
has something in mind that is more subtle that simply shutting the
server down, because if they can get arbitrary code to run on the
server, it's toast anyway.

An example of a subtle attack would be re-writing an e-commerce product
so that any credit-card information would get silently copied and
forwarded elsewhere.

In short, the principle here is that *given* that some other
vulnerability could give a cracker access to the server in some way, you
still don't want to give them any more information on the server
configuration than you have 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] DISCUSS: Community checkins for CVS

[Michael R. Bernstein]

On Tue, 2001-09-25 at 05:27, Paul Everitt wrote:
>
> Does anyone think this is close enough that I can go ahead and get the 
> bootstrap group (under ten, selected by us) going?  I'd like to avoid 
> making them sign and mail an agreement, then do it again if there's 
> substantive changes.

Full speed ahead, and damn the torpedoes!

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] DISCUSS: Community checkins for CVS

[Michael R. Bernstein]

On Tue, 2001-09-25 at 09:19, Paul Everitt wrote:
> 
> We'll probably work up some boilerplate such as, "I'm going to commit 
> your patch to Zope.  It's going to be available under the ZPL and the 
> joint ownership model of the Zope Contributor Agreement.  Please respond 
> agreeing that you understand the ZPL, the joint ownership model, and 
> allow this contribution under these terms."

Might it make sense to require (or perhaps just request) that the
confirmation email be signed with a public key?

Just my $0.02,

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] DISCUSS: Community checkins for CVS

[Michael R. Bernstein]

On Fri, 2001-09-21 at 15:51, Paul Everitt wrote:
> 
> I'll reply in more depth later (on the way out for my b-day dinner)

Hey, happy birthday, Paul!

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] WEBDav error?

[Michael R. Bernstein]

On Mon, 2001-09-17 at 09:04, Phil Harris wrote:
>
> +1 family member.
> 
> The nuclear family is now ready.

I guess it's now time for you to go fission.

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 )

Re: [Zope-dev] Getting Unauthorized from __bobo_traverse__.

[Michael R. Bernstein]

On Wed, 2001-09-12 at 22:45, Erik Enge wrote:
> [Evan Simpson]
> 
> | If you grab OFS/Traversal.py (I think) from the CVS root, it should
> | fix the problem.
> 
> *scabbers off to the CVS*  Thanks! :)

Eeew!

I hope you meant 'scampers', as I have horrific visions of what
'scabbering off' would look like...

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 )

Re: [Zope-dev] Re: RackImage

[Michael R. Bernstein]

Martijn Pieters wrote:
> 
> On Mon, Apr 16, 2001 at 06:37:57PM -0700, Charlie Blanchard wrote:
> > On Tue, Apr 17, 2001 at 11:11:33AM +1000, Itai Tavor wrote:
> > >
> > > Here it is. Hope any of it is any help.
> >
> > My Mutt emailer calls the .tgz file a mac-binhex and none of the
> > usual utilities recognize it as .tgz formatted. Anyone else have
> > the same problem? What's the magic key to decode this attachment?
> 
> Mr. Bernstein had packaged up the file as a gzipped tarball
> indeed, but then his mailer must've wrapped it up in a BinHex
> wrapper.

Wasn't me. :-)

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

[Michael R. Bernstein]

Itai Tavor wrote:
> 
> Thanks, Michael! Turns out I just had to make a few small changes in
> my product to get it to work, which I discovered looking at yours.
> 
> Don't know if anything in my product that it would be interesting to
> add to yours... it's aimed at storing photos for a product catalog,
> most of what it adds to Image is methods for creating a photo based
> on another photo, used for creating a thumbnail.

Sure, I'll take a look at it.

The approach I'm taking (ZPatterns all the way!) is to
generalize the creation and association of the RackImages
with an ArchiveImage ZClass (that holds meta data). I've got
things set up to the point that the ArchiveImages are
traversable into their Rackimages, and the ids are rewritten
appropriately.

So the ArchiveImage ZClass intsances are stored and accessed
like this: ArchiveImages/001

And the RackImages are stored like this:
ArchiveImages/Renderings/001_original <-notice the id!

But I can access the image data from the apropriate
RackImage like this: ArchiveImages/001/original

Next up is RackImage instantiation based on scaled image
data. I think examining your code may be helpful, but I
probably only need your main .py file.

The number and sizes of Renderings that Images have will be
configurable at the application level.

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] Virtual DataSkins

[Michael R. Bernstein]

Steve Alexander wrote:
> 
> In the ScinScript, you need to determine what data to use based on
> self.id. Here's the SkinScript I use for a similar function; I'm
> creating "virtual" instances of one ZClass, based on instances of a
> different ZClass from another Specialist. In this case, the other
> specialist is "Responses".
> 
> WITH Responses.get_data_for_code(code=self.id) COMPUTE
>subject_name,
>rater_name,
>relationship_name,
>response_code,
>process_step

Steve,

Is it possible to have a Specialist that is entirely
'virtual'? Can a Specialist be set up to use a generic
DataSkin that stores attributes persistently, without having
to define a ZClass at all?

If so, can you describe a procedure for accomplishing this?

TIA,

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

[Michael R. Bernstein]

Itai Tavor wrote:
> 
> Could I get a copy of this product? I'm trying to create a
> Rack-mountable Image class but I'm having a lot of trouble getting a
> class subclassed from Image and DataSkin to work. Having some working
> code could save me some trouble.
> 
> I only need the basic RackImage, without all the later stuff you
> added relating to Renderings.

Itai,

I am attaching a tar file that needs to be untarred in the
Products directory.

RackImage is a little rough around the edges, and still has
some cruft left over from Photo.

It is dependent on PIL, which may be unneccessary at this
point.

Please send me any modifications you make. (this will be
released GPL).

Michael.
 rackimage.tar.gz

Re: [Zope-dev] Image Archive Project (phase 2)

[Michael R. Bernstein]

"Michael R. Bernstein" wrote:
> 
> Ok, so what's next? Somehow, ArchiveImages must be made
> aware of what Renderings they have.
> 
> The ArchiveImage Specialist needs a getRenderingIds() Python
> Script, which in turn calls
> container.Renderings.getRenderingIdsFor().
> 
> Now I'm stuck. How do I select all the Renderings that have
> (for example) '001' in their id, and return just the second
> portion of the id (such as 'original' or 'thumbnail')? What
> do I need to put into the getRenderingIds and
> getRenderingIdsFor Python Scripts?

After some head scratching and some advice, I decided to use
a ZCatalog in the Renderings Specialist.

First I added a SkinScript with the following body:

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(),'/'))
WITH SELF COMPUTE
  external_id  = _.string.split(id,'_')[1],
  associated_image = _.string.split(id,'_')[0]

This ensures hat the objects will be catalogued when they
need to be, as well as establishing two computed attributes,
'external_id' and 'associated_image'.

I added both properties to the ZCatalog as FieldIndexes, and
removed all of the existing indexes except for id.

I also added 'external_id' as a meta-data field.

Now the Renderings.getRenderingIdsFor Python Script takes an
associated_image_id as a parameter, and reads as follows:

 list = []
 list =
container.Catalog({'associated_image':associated_image_id})
 list2= []
 for x in list:
 list2.append(x.external_id)

 return list2

And the main ArchiveImages Specialist has a getRenderingIds
Python Script:

 archive_image_id = context.id

 list =
container.Renderings.getRenderingIdsFor(archive_image_id)
 return list

Finally, I added the following to the index_html for the
ArchiveImages:


 


So ArchiveImages now display links to their associated
Renderings.

Any comments or suggestions for improvements gladly
accepted.

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] Image Archive Project (phase 2)

[Michael R. Bernstein]

Ok, I now have the following setup:

ArchiveImages (Specialist)
 defaultRack
  traversal (SkinScript)
 traversal_method (Python Script)
 Renderings (Specialist)
  defaultRack

The SkinScript in ArchiveImages/defaultRack simply points
__bobo_traverse__ to traversal_method.

traversal_method, in turn, checks to see if it is being
called with one of a short list of known methods of the
ArchiveImage ZClass, otherwise it returns an object in the
Renderings Specialist.

Which object, you ask? The objects in Renderings are
instances of RackImage (a class that subclasses Image and
DataSkin). Currently, I have hardwired behaviour that
instantiates a RackImage in Renderings when you create an
ArchiveImage. Assuming that the ArchiveImage is created with
an id of '001', then the RackImage is created with an id of
'001_original'.

So when the traversal_method is presented with a path of
'/ArchiveImage/001/original' it returns the object from
'/ArchiveImage/Renderings/001_original'. Thus the
ArchiveImage ZClass appears to have an 'original' attribute
that returns an image.

Here is the traversal_method Python Script:

 import string

 if name in ['index_html', 'editInstanceForm',
'editInstance']:
 return getattr(context, name)
 else:
 rendering = string.join([context.id, name],'_')
 return container.Renderings.getItem(rendering)


Ok, so what's next? Somehow, ArchiveImages must be made
aware of what Renderings they have.

The ArchiveImage Specialist needs a getRenderingIds() Python
Script, which in turn calls
container.Renderings.getRenderingIdsFor().

Now I'm stuck. How do I select all the Renderings that have
(for example) '001' in their id, and return just the second
portion of the id (such as 'original' or 'thumbnail')? What
do I need to put into the getRenderingIds and
getRenderingIdsFor Python Scripts?

TIA,

Michael Bernstein.

P.S. The (currently hardwired) Renderings instantiation code
will be delegated later to another Specialist,
RenderingDisplays.

___
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 sub-Specialist traversal

[Michael R. Bernstein]

With some help from the kind folks on #zope, this has been
solved.

"Michael R. Bernstein" wrote:
> 
> Here is what I've done:
> 
> ArchiveImages (Specialist)
>  defaultRack
>   traversal_method (Python Script)
>   traversal (SkinScript)
>  Renderings (sub-Specialist)
>   defaultRack

This was wrong in a couple of ways, here is how it needs to
be layed out:

ArchiveImages (Specialist)
 traversal_method (Python Script)
 defaultRack
  traversal (SkinScript)
 Renderings (sub-Specialist)
  defaultRack

As you can see, the Python Method needed to be moved from
within the Rack up into the Specialist.

> traversal_method has 'REQUEST, name' as parameters, and the
> following body:
> 
> return getattr(container.Renderings, name)

The body of the traversal_method needed to change in two
ways:

 if name in ['index_html', 'editInstanceForm',
'editInstance']:
 return getattr(context, name)
 else:
 return container.Renderings.getItem(name)

First, it needed to pass unmolested those methods of the
ArchiveImage that were needed. Second, Specialists
apparently don't support getattr(), so I needed to change
this to call getItem() instead.

> The 'traversal' SkinScript has the following body:
> 
> WITH SELF COMPUTE __bobo_traverse__=traversal_method

The SkinScript works fine as-is.

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] 27 million objects.

[Michael R. Bernstein]

Andy McKay wrote:
> 
> Any cataloguing and un-cataloguing of an object is expensive, c'mon you are
> changing all the indices, vocabulary and so on. You never notice it normally
> for 1 - 10 things, but run an import script of 1 and catalog each object
> as it gets added (rather than all of them at the end) and you'll notice the
> difference. (This script was cataloguing 250,000 mail messages, one at a
> time. Big no-no)

Perhaps I expressed myself poorly.

What I am watching out for is evidence that adding,
indexing, reindexing, or retreiving *a single object* (or a
small set of objects), takes longer if there are more
objects stored/indexed already.

In other words, does the time to
store/index/reindex/retreive an object change (for the
worse) depending on whether there are 10,000 objects,
100,000 objects or 10,000,000 objects stored/cataloged in
the ZODB/ZCatalog?

Previously, the fact that searching performance suffered
depending on a combination of number of total objects and
the size of the result set (irrespective of the batch size,
apparently), came to light, and has apparently been fixed.
Now searching performance scales with the number of
cataloged objects.

So, are there any non-linear gotchas waiting for me?

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 sub-Specialist traversal

[Michael R. Bernstein]

Ulrich Eck wrote:
> 
> > traversal_method has 'REQUEST, name' as parameters, and the
> > following body:
> >
> > return getattr(container.Renderings, name)
> >
> > The 'traversal' SkinScript has the following body:
> >
> > WITH SELF COMPUTE __bobo_traverse__=traversal_method
> >
> >
> 
> try:
> 
> if len(traverse_subpath) > 0:
> name = traverse_subpath[0]
> 
> return getattr(container.Renderings,name)

Nope, same error.

What should I try next?

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] ZPatterns sub-Specialist traversal

[Michael R. Bernstein]

Hello all,

I've been trying to follow the instructions for getting
subSpecialist instances to appear as directly traversable
from Specialist instances, but have not yet had any success.

Here is what I've done:

ArchiveImages (Specialist)
 defaultRack
  traversal_method (Python Script)
  traversal (SkinScript)
 Renderings (sub-Specialist)
  defaultRack

traversal_method has 'REQUEST, name' as parameters, and the
following body:

return getattr(container.Renderings, name)

The 'traversal' SkinScript has the following body:

WITH SELF COMPUTE __bobo_traverse__=traversal_method


Nevertheless, when I try to traverse an instance in the
Specialist to an instance into the subspecialist, I get an
error:

http://localhost:8080/ArchiveImages/001/002

Resource not Found

Traceback (innermost last):
  File
/usr/local/zope/2-3-1/lib/python/ZPublisher/Publish.py, line
223, in publish_module
  File
/usr/local/zope/2-3-1/lib/python/ZPublisher/Publish.py, line
187, in publish
  File /usr/local/zope/2-3-0/lib/python/Zope/__init__.py,
line 221, in zpublisher_exception_hook
(Object: 001)
  File
/usr/local/zope/2-3-1/lib/python/ZPublisher/Publish.py, line
162, in publish
  File
/usr/local/zope/2-3-1/lib/python/ZPublisher/BaseRequest.py,
line 372, in traverse
  File
/usr/local/zope/2-3-1/lib/python/ZPublisher/HTTPResponse.py,
line 547, in notFoundError
NotFound: (see above)

The 002 sub-Specialist instance exists and is accessable
normally
(http://localhost:8080/ArchiveImages/Renderings/002), so I
must be doing something wrong in the PythonScript or the
SkinScript, but I don't know what.

Any help would be appreciated,

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] 27 million objects.

[Michael R. Bernstein]

Erik Enge wrote:
> 
> The programmer solving our problems with the post codes has solved it in a
> different way than what I would've done (his method is way superior), so
> we're not ending up adding all addresses as Zope Objects.

Oh well. Does anyone else have any setups that store truly
massive (50k, 100k, 1M, you know, *lots*) numbers of
objects? Preferably stored in a BTree of some sort
(ZPatterns Rack, BTree folder, etc.). the objects can be
simple ZClasses, or almost anything else. I'm trying to find
out of there is a point where you start getting non-linear
performance penalties for additional objects (storing,
retreiving, or indexing).

Meanwhile Erik, what approach *did* your programmer take?

> Therefore, I don't have any benchmark tests available.  We are going to
> transfer some 10GB of data at a later stage though (within a month), and
> that could result in some tests being done - if so, I'll send you an
> email.  :-)

I'll look forward to it.

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] .zexp format deprecated?

[Michael R. Bernstein]

Hi all,

Someone just mentioned on the #zope IRC channel that they
saw a comment to the effect that the 'zexp format was
'deprecated'. Can anyone confirm this? what release will no
longer support the format?

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] MySQL-python-0.3.5 with ZMySQLDA

[Michael R. Bernstein]

> Mike Blake wrote:

PLEASE don't post HTML email to the list.

Thank you.

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 Image Archive Project

[Michael R. Bernstein]

"Phillip J. Eby" wrote:
> 
> At 01:45 PM 4/1/01 -0700, Michael R. Bernstein wrote:
> >
> >It seems as though the manage_upload method is supposed to
> >hand off the image data to RenderingKinds, which in turn
> >either replaces the image data in existing Renderings, or
> >creates new ones, by iterating through the rows in the
> >TinyTable.
> 
> [shudder].  No, not at *all*.  The calling pattern goes like this:
> 
> anArchiveImage.upload:
> for kind in RenderingKinds.getKindsFor(self):
> Renderings.setRenderingFor(self,kind,data)
> 
> The ArchiveImage is responsible for knowing the image data.  The
> RenderingKinds specialist is responsible for knowing what renderings should
> be made for an ArchiveImage.  The Renderings specialist is responsible for
> creating and storing a rendering, given an image and a kind of rendering to
> be made.  However, it may ask the kind object for dimensions or other
> assistance in actually creating the rendering.
> [snip]
> Don't think "RenderingKinds replaces the image data in existing
> Renderings", because that's "meddleware" - objects meddling in each others'
> business.  Renderings is responsible for renderings.  RenderingKinds is
> only responsible for knowing about *kinds*.

Ok. RenderingKinds (in my implementation) iterates through
the TinyTable, and returns a list of Kind objects.

Then, the ArchiveImage sends the list of Kinds to
Renderings. Renderings, in turn, iterates through the list
(grabbing dimension info from the Kind object) and creates
each Rendering appropriately.

> >In turn, are RenderingKinds *also* responsible for returning
> >the appropriate Rendering based on a 'size' attribute?
> 
> No.  RenderingKinds are responsible only for knowing about *kinds*, not the
> details of a particular image.  Thus, it makes sense for RenderingKinds to
> implement rules about what renderings an image *should* have, but the ones
> it *does* have are the domain of the image itself (but delegated to the
> Renderings specialist for actual implementation).

Ok.

> >are ArchiveImages supposed to access Renderings directly to
> >find whatever Renderings exist for them?  Which Specialist
> >now has a getRenderingFor(archiveImage,imageKind) method?
> 
> Renderings.  ArchiveImage should have getRendering(imageKind) which then
> calls Renderings.getRenderingFor(self,imageKind).

Mmm. I think I see, but you didn't actually answer the first
of the two questions. More below.

> >I can also see a problem with the following situation: after
> >several Archive images are created along with their
> >appropriate Renderings, the configuration information in the
> >TinyTable is changed, with new sizes added, and existing
> >sizes deleted or edited.
> >
> >I would not expect the entire image database to be resized
> >and new sizes created automatically, so the data in the
> >Renderings Specialist would be out of sync with the sizing
> >meta-data, with Renderings possibly 'orphaned', and other
> >Renderings 'missing'
> >
> >I *think* that these problems can be avoided, if the
> >Renderings Specialist is still responsible for reporting
> >what Renderings an ArchiveImage *has* (and possibly what
> >their dimensions are), and the RenderingKinds Specialist is

Here's what I meant:

Should ArchiveImage have a getRenderings(self) which in turn
calls Renderings.getRenderingsFor(self)? This should (I
think) return a list of Kinds that Renderings has stored for
a particular ArchiveImage.

> >responsible for removing orphan renderings and creating
> >missing Renderings when the Image is either uploaded again
> >or 'refreshed'.
> >
> >How would you reccomend handling this?
> 
> That depends on what the requirements are.  If you need to implement this,
> then the sensible place to do it is probably in the RenderingKind objects
> and RenderingKinds specialist.  That is, adding a RenderingKind might
> include the option to go through and create the missing renderings, and
> deleting or altering one might similarly prompt for updates.

Um. You mean for all ArchiveImages? What I meant is that you
would be able to tell an individual ArchiveImage to either
upload new data or just 'refresh' itself (manually), and a
process substantially similar to the ArchiveImage creation
process would create missing Renderings, and overwrite the
ones that already existed (just in case their dimensions
changed), and delete Renderings that no longer had an
equivalent RenderingKind. All for the individual image, not
for all images.

I can later add a batch interface to trigger this on X
images at a time, to avoid causing the server to thrash.

Does this seem reasonable?

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 Image Archive Project

[Michael R. Bernstein]

"Phillip J. Eby" wrote:
> 
> At 05:08 PM 4/1/01 -0700, Michael R. Bernstein wrote:
> >
> >I'm also assuming that RenderingKinds' defaultRack is set to
> >use 'ZPatterns: DataSkin' and be set to load by accessing
> >the 'id' attribute. Is this correct?
> 
> Well, I would create a "RenderingKind" ZClass, so as to be able to give it
> methods and to be able to distribute the class as part of the framework.

Is that strictly neccessary, or can I just have a few Python
Scripts in the RenderingKind specialist? Won't those work
just as well?

BTW, I thought that with the setup I described, I should be
able to access the settings data through the web, ie:

http://myserver.com/ArchiveImages/RenderingKinds/thumbnail/

where RenderingKinds has an index_html has a  in it. But this fails, and reports a
non-existent variable 'maxdimension'.

Obviously I'm doing something wrong, but I don't know what.

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] SkinScript Questions

[Michael R. Bernstein]

Hi all,

I had some questions about SkinScripts:

1) Are there any naming conventions for SkinScripts?

2) Is there any reason (other than factoring) to split
SkinScripts up, or is putting all your declarations in one
SkinScript ok?

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 Image Archive Project

[Michael R. Bernstein]

"Phillip J. Eby" wrote:
> 
> By the way, RenderingKinds is a sort of specialist that hasn't been
> discussed much outside of the apps Ty and I work with - the "constant"
> Specialist, one which contains application configuration or metadata rather
> than "content".  Oftentimes it's handy to simply base a Specialist on a
> TinyTable or similar product in order to set up configuration of constant
> items like RenderingKinds.  Consider the TinyTable data below:
> 
> Columns: name:string scaling:float width:int height:int rackname:string
> 
> "fullsize",1.0,0,0,"bigimages"
> "halfsize",0.5,0,0,"bigimages"
> "thumbnail",0.0,64,64,"thumbnails"

In my application, I'm only interested in specifying the
'maximum dimension' in any direction. This seems to work
better generally, because it accounts automatically for
images that are landscape or portrait oriented. So my
TinyTable only has two columns:

Columns: name:string maxdimension:int

> The RenderingKinds specialist would have a single rack, which uses
> SkinScript to pull in the data from the TinyTable (WITH
> theTinyTable[self.id] COMPUTE scaling,width,height,rackname).

The SkinScript (which I placed in the RenderingKinds
Specialist, not in it's defaultRack) has the following line
in it:

WITH sizes[self.id] COMPUTE maxdimension

I eliminated the 'rackname' column, because you reccomended
that all Renderings(RackImages) be stored in the same Rack,
for simplicity. This also seems the more flexible approach
(ie. I don't have to create management screens to add and
delete racks when the sizes change), so there is less
'hardwiring'.

Now, am I correct in assuming that the 'sizes' TinyTable
should be in the RenderingKinds Specialist?

I'm also assuming that RenderingKinds' defaultRack is set to
use 'ZPatterns: DataSkin' and be set to load by accessing
the 'id' attribute. Is this correct?

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 Image Archive Project

[Michael R. Bernstein]

"Phillip J. Eby" wrote:
> 
> At 08:59 PM 3/30/01 -0800, Michael R. Bernstein wrote:
> >
> >The terminology I'm using is ArchiveImage (for the 'Image'
> >class) and RackImage (for the 'Rendering' class).
> 
> I'd recommend a name change for RackImage, at least at the Specialist
> level.  If you don't like Renderings, then maybe RenderedImages,
> ActualImages, or some such.  Specialist names should reflect the *purpose*
> of a thing in the application rather than the nature of the thing itself.

Ah. That makes sense. Ok, so now my RackImage class is being
stored in a defaultRack of a Renderings Specialist contain
within the main ArchiveImages Specialist.

> >I think that different sizes would have the same behavioural
> >characteristics (simply an image file, really), but am less
> >sure about storage. My application will attempt to store all
> >the renderings in the ZODB, but if I want this to be
> >reusable, I have to assume that someone (including me) might
> >want to store the image data on the FS instead. If it's
> >going to be stored on the FS, it would be natural to dump
> >different sizes into separate directories, or even separate
> >partitions.
> 
> This can still be accomplished with a single specialist, if your 'id'
> format contains the necessary information to distinguish between image
> sizes/types.  If a user of your framework wants to seperate the storage,
> they can create more than one rack and have the specialist distinguish
> between them using the contents of the 'id'.  It's best to keep
> implementation simple in the reference implementation of a framework.

Ok.

> >I was thinking of a manage_upload method on the
> >ArchiveImage, that iterated through a list of sizes and used
> >an external method that imports PIL to resize the image
> >data, then passes the resized image data into the RackImage
> >manage_upload method.
> >
> >Does that seem reasonable?
> 
> It seems to me that sizing renderings should be the responsibility of the
> Renderings specialist.  That is, the ArchiveImage upload method would look
> something like this:
> 
> for imageKind in ('fullsize','thumbnail'):
> Renderings.setRenderingFor(self,imageKind,imageData)
> 
> The setRenderingFor method would take the ArchiveImage's id, tack the
> imagekind onto it, and either retrieve the current image or create a new
> one, then re-size the image according to your rules for what size fullsize
> or thumbnail is, and pass it to the current or new rendered image object.
> (A counterpart method, getRenderingFor(archiveImage,imageKind) would do a
> similar id transformation to retrieve a rendering when called by the
> ArchiveImage's getRendering() method.)
> 
> Of course, this means that the Renderings specialist has to know what
> sizes different size names mean, and that ArchiveImages have to know the
> possible sizes.  Such knowledge being spread across two specialists means
> there's a specialist missing: RenderingKinds.
>
> [snip RenderingKinds as a sub-specialist of Renderings]
> 
> Although, it may be in your framework that ArchiveImages are responsible
> for knowing which kinds of renderings they should have, and the
> RenderingKinds specialist will simply deal with implementation details such
> as how each kind is sized and which rack they're stored in within the
> Renderings specialist.
> 
> By the way, RenderingKinds is a sort of specialist that hasn't been
> discussed much outside of the apps Ty and I work with - the "constant"
> Specialist, one which contains application configuration or metadata rather
> than "content".  Oftentimes it's handy to simply base a Specialist on a
> TinyTable or similar product in order to set up configuration of constant
> items like RenderingKinds.
> [snip]
> Now, you could make a RenderingKind class that uses this data to resize an
> image.  That is RenderingKind would have a sizeImage(imageData) method that
> returned a new image of the appropriate size.  It could also have a
> rackname attribute which would tell the Renderings specialist which rack an
> image of that kind should be stored in.  The user of the application could
> reconfigure at will by changing the contents of the TinyTable.
> 
> This might be all that RenderingKind objects do in the application - resize
> images and say where to put them.  But over time, you might find additional
> uses for them.  Like for example if you had certain rules about which kinds
> of renderings should be created for certain types of ArchiveImages.

Ok, using a RenderingKinds does seem like th

[Zope-dev] [Mini-HowTo]: Multiple Selects in ZClass Edit Forms

[Michael R. Bernstein]

Problem:
---

You want your ZClass instance edit form to correctly display
the currently selected values for a multiple selection
property.

Assumptions:
---
You have a ZClass that has a multiple select property named
'format' with a value set to 'format_list'.

You have a 'format_list' lines property set where the ZClass
*instances* can acquire it.

You generated an 'Edit' type 'Property Sheet Interface' that
contains the following code:

  format
  
  

Solution:

Replace the above code with the following:

  format
  

  
  
  SELECTED >
  
  

  
  

This will correctly display the currently selected values
for your ZClass instance in the edit form, and capture the
changed values when the form is submitted, casting even
single selections to a list.

Note: If the 'format_list' lines property is set where the
Zclass instances can acquire it, but not where the ZClass
definition can acquire it, then the Property Sheet
management screen will *not* display the values. If you want
to provide a default set of values that the ZClass
definition can acquire as well as the ZClass instances (of
course you can also override this locally), set the
format_list property on the root folder.

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 Image Archive Project

[Michael R. Bernstein]

"Phillip J. Eby" wrote:
> 
> At 07:30 PM 3/30/01 -0800, Michael R. Bernstein wrote:
> >
> >Well, I want to store several versions of each image. Let's
> >take a simplified case where I want the original image and a
> >thumbnail, both of which need to appear as subobjects of the
> >ZClass with the meta-data.
> 
> Aha.  I think I understand what you're doing now.  You have an "Image" and
> you have a "Rendering".  Two classes, different behaviors.  I'm assuming
> that originals and thumbnails and whatever other renderings exist have no
> real behavioral differences and can be implemented with the same class and
> storage characteristics.

The terminology I'm using is ArchiveImage (for the 'Image'
class) and RackImage (for the 'Rendering' class).

I think that different sizes would have the same behavioural
characteristics (simply an image file, really), but am less
sure about storage. My application will attempt to store all
the renderings in the ZODB, but if I want this to be
reusable, I have to assume that someone (including me) might
want to store the image data on the FS instead. If it's
going to be stored on the FS, it would be natural to dump
different sizes into separate directories, or even separate
partitions. Two years from now, this web application could
contain around 300 Gb of images (current prices on that much
storage are about $1,000 for ten 30 Gb hard-drives, so I'm
not too worried on that score).

> >If I store all the RackImages (originals and thumbnails) in
> >one Rack, how do I differentiate between them, so that
> >'/Archive/001/thumbnail' and 'Archive/001/original' show the
> >appropriate images? It just seemed simpler to create a
> >'thumbnail' Rack and an 'original' Rack.
> 
> It sounds to me like you want an Images specialist and a Renderings
> specialist, with the latter contained within the former (because Renderings
> are only accessed by way of Images).  Your Image class should have a
> "getRendering(kind)" method which accesses the renderings specialist to
> retrieve a rendering, and it can also have a __bobo_traverse__ method that
> uses getRendering to allow traversal as you describe.  This would still be
> completely storage independent, since that's hidden in the Renderings
> specialist.  Likewise, when your Images create renderings, they'll need to
> delegate the actual creation to the Renderings specialist.

Thanks, that's *very* helpful. I'm not too certain how to
accomplish the 'getRendering(kind)' and the
'__bobo_traverse__' magic, But I'll cross that bridge a
little later.

> If you need different classes for different kinds of renderings, you'll
> need multiple racks inside the Renderings specialist, but if renderings are
> basically just a Zope Image object, you can just use a single Rack (and
> make your id values something like '001_original', '002_thumbnail', etc.
> and construct these in your getRendering() method).
> 
> >That's what I meant, sorry. The RackImages need to appear to
> >be attributes of the ZClass, and I'll use SkinScripts to
> >accomplish that.
> 
> That's really only practical if you have a fixed set of rendering types and
> names, but it'll work for retrieval.  It won't really help you with
> creation and assignment, though.  I'd suggest specialized methods on Image
> which delegate to the Renderings specialist.

I was thinking of a manage_upload method on the
ArchiveImage, that iterated through a list of sizes and used
an external method that imports PIL to resize the image
data, then passes the resized image data into the RackImage
manage_upload method.

Does that seem reasonable?

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 Image Archive Project

[Michael R. Bernstein]

"Phillip J. Eby" wrote:
> 
> At 05:27 PM 3/30/01 -0800, Michael R. Bernstein wrote:
> >Now I am working on a ArchiveImage ZClass that holds 'meta'
> >information about an image, such as the description, a date,
> >and keywords.
> >
> >I want to have one Rack for each image size that I want to
> >store.
> 
> Just out of curiousity, why do you want seperate racks for each size?  Are
> they being stored in different ways or have different behavioral
> requirements (e.g. different classes) apart from their size?  If not, there
> is probably no reason to have multiple racks.

Well, I want to store several versions of each image. Let's
take a simplified case where I want the original image and a
thumbnail, both of which need to appear as subobjects of the
ZClass with the meta-data.

If I store all the RackImages (originals and thumbnails) in
one Rack, how do I differentiate between them, so that
'/Archive/001/thumbnail' and 'Archive/001/original' show the
appropriate images? It just seemed simpler to create a
'thumbnail' Rack and an 'original' Rack.

> >I realize that I need to tie the Racks together in the
> >specialist using SkinScripts
> 
> SkinScript doesn't do anything to tie racks together or to a Specialist -
> it's just a way of describing where the data comes from/goes to for a
> particular Rack.

That's what I meant, sorry. The RackImages need to appear to
be attributes of the ZClass, and I'll use SkinScripts to
accomplish that.

> >Where do I put the separate Racks? do I create a specialist
> >for each Rack (seems unneccessary) or do I put several Racks
> >in the same Specialist?
> 
> Several in the same, if they are providing objects which fill the same role
> in your overall application.

And do the RackImages Racks go into the same Specialist as
the ZClass Rack?

> >The DTML I am using to instantiate RackImages in the Rack
> >for example, is as follows:
> >
> >
> > 
> > 
> >
> >
> >But this code only works for a Rack named defaultRack, which
> >I can obviously only have one of.
> 
> Just use the name of the rack, e.g.:
> 
> , etc.

Ok, thanks! That works (Duh).

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] ZPatterns Image Archive Project

[Michael R. Bernstein]

Hello all,

Background
--
I am building an Image Archive Zope application using
ZPatterns. I originally was trying to convert the Photo
Product to ZPatterns in such a way as to still have it work
as a normal product, but that turned out to be too complex.

So, I am building the application fresh.

So far, I have a RackImage Python product that subclasses
from Image and DataSkin which seems to work fine. I can
create, upload, view  and delete the RackImages.

Now I am working on a ArchiveImage ZClass that holds 'meta'
information about an image, such as the description, a date,
and keywords.

I want to have one Rack for each image size that I want to
store.

I realize that I need to tie the Racks together in the
specialist using SkinScripts, but I had a question that is a
bit more fundamental:

Where do I put the separate Racks? do I create a specialist
for each Rack (seems unneccessary) or do I put several Racks
in the same Specialist?

If the latter, I'm unsure how to use DTML or PythonScripts
to specify which Rack to create a new item in.

The DTML I am using to instantiate RackImages in the Rack
for example, is as follows:


 
 


But this code only works for a Rack named defaultRack, which
I can obviously only have one of.

Any advice on this would be greatly appreciated.

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] 175 Million Email Addresses for $99 (4523)

[Michael R. Bernstein]

"[EMAIL PROTECTED]" wrote:
> 
> A half-page ad in the Sunday New York Times can cost more than $50,000 and only 
>reaches 4 million people.

SpamCopped.

http://spamcop.net/sc?id=z18008689zb12fa2894091c08b658348efed77122dz

Michael Bernstein.

P.S. Join in the fun! The more people report a particular
spammer, the better the chances that their ISP will shut
them down!

___
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] Comment on CVS change

[Michael R. Bernstein]

Casey Duncan wrote:
> 
> I rarely find myself using any explicit boolean operators when I use
> Google. And even when it returns 657,340,269 pages, the ones I wanted
> tend to be in the top 30. I think "OR" searching is fine if the result
> scoring can be done intelligently somehow.

It's pretty simple. The default operator should continue to
be 'OR', but the result sorting should give precedence to
results that satisfy the 'AND' condition.

No, I don't know hoe to get it to do this. Didn't Catalog
results used to have a 'score' attribute for something like
this?

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] [OT] Zope Designer For Hire

[Michael R. Bernstein]

Hi all,

I realize this is a little off-topic, but I figured I'd give
it a shot anyway.

I am a Zope-savvy web-designer that has recently been
'downsized', and I'm looking for a new employer. I'm
located in Las Vegas, NV, and would prefer not to
relocate, but would be open to telecommuting.

Resume and URL's available on request. Please reply
off-list.

And now, back to your regularly scheduled program.

Thank you,

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

[Michael R. Bernstein]

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

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

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

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

Thanks,

Michael Bernstein.

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

Re: [Zope-dev] More ZCatalog Stuff.

[Michael R. Bernstein]

Toby Dickenson wrote:
> 
> If you are interested in a short-term hack, it is possible implement
> your own type of index and add it to an existing catalog, without
> having to modify any of the ZCatalog product.

Ok, how? Please keep in mind that I'm more of a designer and
integrator than a coder.

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] Minor typos/changes to ZCatalog.

[Michael R. Bernstein]

"R. David Murray" wrote:
> 
> On Fri, 23 Feb 2001, Michael R. Bernstein wrote:
> > As you can see by the second example, an ISBN can have
> > letters as well as numbers in it, so it cannot be
> > represented by an integer. Text indexes seem to ignore
> > 'words' that contain numbers, though.
> >
> > Any suggestions?
> 
> A field or keyword index would work.  Or you can make a very small
> change to splitter.c to stop it from ignoring numbers.
> 
> Which is something I'd like to see as a standard feature of Catalog,
> actually.  I can't think of any instances of using a text index
> where I did *not* want words with numbers indexed, and have a number
> of instances where I *do* want words with numbers indexed.  Actually,
> the same applies to pure numbers, as well.

Hmm. this seems like there ought to be a checkbox next to
the 'Add Index' form field labeled 'index numbers?'. Or
maybe a 'Text and Numbers' index as an additional index
type.

What change needs to be made to splitter.c? Do I have to
recompile Zope afterwards, or will a restart do 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] Minor typos/changes to ZCatalog.

[Michael R. Bernstein]

Erik Enge wrote:
> 
> On Fri, 23 Feb 2001, Michael R. Bernstein wrote:
> 
> > On the subject of numbers, I was wondering how to index
> > alphanumeric values like ISBN numbers.
> 
> Why can't you use FieldIndexes?

Because I'm actually Using a SkinScript to concatenate
several attributes (Author, Title, id) +into one , so that I
can index them all with a single text index. In that way, I
reduce the indexing overhead, and it's easy to search
multiple attributes for a match from a single search box.

So how do I get the text index to index the alphanumeric
ISBN values as well?

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 feature patch: kickTriggers

[Michael R. Bernstein]

Steve Alexander wrote:
> 
> I'd welcome suggestions on a better name for the method than
> "kickTriggers". :-)

Two more:

PushTheButton
PullTheLever

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] Minor typos/changes to ZCatalog.

[Michael R. Bernstein]

Chris McDonough wrote:
> 
> > Also, could anyone point me to some good documentation (reference material
> > would be best) about how the different Indexes work?  I'm having a bit of
> > a struggle with numbers, FieldIndexes and TextIndexes.
> 
> No.  ;-)  This is one of the things I'd like to get done soon.

On the subject of numbers, I was wondering how to index
alphanumeric values like ISBN numbers. They're unique
values, so perhaps some other approach than an index is
waranted, butthe simplest approach seems to be indexing them
as well. Here are some sample ISBN's:

 0201433311
 087584877X

As you can see by the second example, an ISBN can have
letters as well as numbers in it, so it cannot be
represented by an integer. Text indexes seem to ignore
'words' that contain numbers, though.

Any suggestions?

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 feature patch: kickTriggers

[Michael R. Bernstein]

Steve Alexander wrote:
>  
> I'd welcome suggestions on a better name for the method than
> "kickTriggers". :-)

Well, in keeping with the nomenclature of RuleAgents and
IndexingAgents, how about DoubleAgent (it secretly works for
another Specialist)?

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 Product as DataSkin

[Michael R. Bernstein]

Steve Alexander wrote:
> 
> Michael R. Bernstein wrote:
>  >
>  > File /home/webmaven/Products/ZPatterns/DataSkins.py, line 208, in
>  > __set_attr__ (Object: ElementWithAttributes) KeyError: (see above)
> 
> What version of ZPatterns are you using?

0.4.3b2 on Zope 2.2.0

> I certainly don't have the __set_attr__ method covering line 208 in my
> version.

In my DataSkins.py, line 208 is the one marked below:

>  def __set_attr__(self,name,val,_v_dm_=_v_dm_):
>  try:
> 208>>>   dm = self.__dict__[_v_dm_]
>  except KeyError:
>  if name=='id' and val==self.__dict__['id']: return
>  raise
> 
> If they don't, you'll get the error that you're reporting.

Well, that's the version I've got, and that is how the
__set_attr__ method reads. What do I check next?

Backtracking a bit more, line 46 in ArchiveImage.py is in
the manage_addArchiveImage method, marked below:

def manage_addArchiveImage(self, id, file, title='',
displays=None, precondition='',
   content_type='', REQUEST=None):
  """
  Add a new ArchiveImage object.
  """
   # This constructor basically ripped off from Image/File
   id, title = cookId(id, title, file)
   self=self.this()
   # First, we create the ArchiveImage without data:
46>self._setObject(id,
ArchiveImage(id,title,'',displays,content_type,precondition))
   # Now we "upload" the data.  By doing this in two steps,
we
   # can use a database trick to make the upload more
efficient.
   self._getOb(id).manage_upload(file)
   if REQUEST:
   try:url=self.DestinationURL()
   except: url=REQUEST['URL1']
   REQUEST.RESPONSE.redirect('%s/manage_main' % url)
   return id

Does this help?

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] Python Product as DataSkin

[Michael R. Bernstein]

Ok, to recap:

1) Add 'import Globals' to the start of the myClass.py file

2) Change the def __init__ in the 'class myClass' definition
to:

   def __init__(self, id, title):
   myClass.inheritedAttribute('__init__')(self, id)
   # rest of your __init__ method

3) add the following line at the end of the file (with no
indenting):

   Globals.default__class_init__(myClass)

Is this supposed to work and let me instantiate a DataSkin
derived class through the 'normal' mgmt interface? if so,
something is wrong, because I'm still getting the same
error:

--8<--
This resource may be trying to reference a
nonexistent object or variable _v_dm_

The URL may be incorrect.
The parameters passed to this resource may be incorrect.
A resource that this resource relies on may be encountering
an error.

Traceback (innermost last):
  File
/usr/local/Zope-2.2.0-src/lib/python/ZPublisher/Publish.py,
line 222, in publish_module
  File
/usr/local/Zope-2.2.0-src/lib/python/ZPublisher/Publish.py,
line 187, in publish
  File
/usr/local/Zope-2.2.0-src/lib/python/Zope/__init__.py, line
221, in zpublisher_exception_hook
  File
/usr/local/Zope-2.2.0-src/lib/python/ZPublisher/Publish.py,
line 171, in publish
  File
/usr/local/Zope-2.2.0-src/lib/python/ZPublisher/mapply.py,
line 160, in mapply
(Object: manage_addArchiveImage)
  File
/usr/local/Zope-2.2.0-src/lib/python/ZPublisher/Publish.py,
line 112, in call_object
(Object: manage_addArchiveImage)
  File /home/webmaven/Products/ArchiveImage/ArchiveImage.py,
line 46, in manage_addArchiveImage
(Object: ApplicationDefaultPermissions)
  File /home/webmaven/Products/ArchiveImage/ArchiveImage.py,
line 80, in __init__
(Object: ElementWithAttributes)
  File /home/webmaven/Products/ZPatterns/DataSkins.py, line
208, in __set_attr__
(Object: ElementWithAttributes)
KeyError: (see above)
--8<--

For your reference, line 80 in ArchiveImage.py is the first
line in the '__init__' function after the
'ArchiveImage.inheritedAttribute('__init__')(self, id)'
line, and reads:

  self.__name__=id

I don't know what to try next. Any suggestions? If I zip up
the whole Product, could you (or anyone else on the list)
take a look at it? I have a feeling I'm missing something
obvious.

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] Re: Photo Product Strangeness

[Michael R. Bernstein]

Ron Bickers wrote:
> 
> I noticed this behavior a while ago.  The author said he didn't have time to
> mess with it and it was a low priority.  I've been able to get the photos
> back the way they should be by some combination of saving properties on the
> properties screen and other such fumbling around.  I haven't bothered trying
> to figure out why it's happening, though.

I found an even more revealing scenario:

When you create a Photo in a folder, alter it's display
setings, *delete* it, and then create a new Photo in the
same folder, the new Photo will have the altered display
settings.

This tells me that the displays persistent atribute (a
tuple) is being created in the Folder's namespace, not the
Photo's. but I don't know enough to figure out where in the
source it's going wrong.

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 Product as DataSkin

[Michael R. Bernstein]

Steve Alexander wrote:
> 
> Michael R. Bernstein wrote:
> 
> > Steve Alexander wrote:
> >
> >> Is the __init__ method of DataSkin getting called?
> >>
> >> This would happen if, for example, you define an __init__ method in your
> >> class, but you don't use something like:
> >>
> >> from Globals import default__class_init__
> >>
> >> default__class_init__(yourClass)
> >>
> >> At least, I *think* that's one of the things that default__class_init__
> >> does.
> 
> Nope... I got confused. Globals.default__class_init__ sets up the security
> attributes for you class, from whatever combination of security
> declarations you've used.
> 
> In Zope 2.3) it is aliased to Globals.InitializeClass.

So, if I'm developing this on 2.2, I need to use
Globals.default__class_init__(FooClass) instead of
Globals.InitializeClass(FooClass)?

> Use it by having
> 
>   import Globals
> 
> somewhere in your class definition,

If 'import Globals' appears at the start of the FooClass.py
file, does it still need to appear in the class definition
itself?

> and
> 
>   Globals.InitializeClass(YourClassName)
> 
> at the end.

At the end on the file, or the end of the class definition?

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] Python Product as DataSkin

[Michael R. Bernstein]

"Phillip J. Eby" wrote:
> 
> At 10:47 PM 2/18/01 -0800, Michael R. Bernstein wrote:
> >
> >Hmm. So I need to refactor the 'manage_add' method inside
> >the python product into two methods, 'manage_add' which
> >would be used by the 'normal' object creation process and
> >that would also call a second 'setup' method which could be
> >called by the specialists 'myadd' method directly, bypassing
> >the 'manage_add' method entirely.
> >
> >Is that correct?
> 
> Pretty much

Ok, but in that case a simple  should at least execute without
error, and it doesn't:

Error Type: TypeError
Error Value: not enough arguments; expected 4, got 2

Traceback (innermost last):
  File
/usr/local/Zope-2.2.0-src/lib/python/ZPublisher/Publish.py,
line 222, in publish_module
  File
/usr/local/Zope-2.2.0-src/lib/python/ZPublisher/Publish.py,
line 187, in publish
  File
/usr/local/Zope-2.2.0-src/lib/python/Zope/__init__.py, line
221, in zpublisher_exception_hook
(Object: ProviderContainer)
  File
/usr/local/Zope-2.2.0-src/lib/python/ZPublisher/Publish.py,
line 171, in publish
  File
/usr/local/Zope-2.2.0-src/lib/python/ZPublisher/mapply.py,
line 160, in mapply
(Object: addArchiveImage)
  File
/usr/local/Zope-2.2.0-src/lib/python/ZPublisher/Publish.py,
line 112, in call_object
(Object: addArchiveImage)
  File
/usr/local/Zope-2.2.0-src/lib/python/OFS/DTMLMethod.py, line
167, in __call__
(Object: addArchiveImage)
  File
/usr/local/Zope-2.2.0-src/lib/python/DocumentTemplate/DT_String.py,
line 502, in __call__
(Object: addArchiveImage)
  File
/usr/local/Zope-2.2.0-src/lib/python/DocumentTemplate/DT_Util.py,
line 337, in eval
(Object: newItem(REQUEST.id))
(Info: newItem)
  File <string>, line 0, in ?
  File /home/webmaven/Products/ZPatterns/Specialists.py,
line 40, in newItem
(Object: ProviderContainer)
  File /home/webmaven/Products/ZPatterns/Rack.py, line 73,
in newItem
(Object: ProviderContainer)
  File /home/webmaven/Products/ZPatterns/Rack.py, line 135,
in createItem
(Object: ProviderContainer)
  File /home/webmaven/Products/ZPatterns/Rack.py, line 232,
in _RawItem
(Object: ProviderContainer)
TypeError: (see above)

What am I doing wrong?

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 Product as DataSkin

[Michael R. Bernstein]

Steve Alexander wrote:
> 
> Is the __init__ method of DataSkin getting called?
> 
> This would happen if, for example, you define an __init__ method in your
> class, but you don't use something like:
> 
> from Globals import default__class_init__
> 
> default__class_init__(yourClass)
> 
> (At least, I *think* that's one of the things that default__class_init__
> does. Otherwise, you'll need to make sure you call DataSkin.__init__
> from your __init__ method, probably using Acquisition.inheritedAttribute.)

This sounds like it's on the right track because I *am*
defining an __init__ method, and I don't have any code
resembling what you typed. 

Where do I put this again? Does this go in the myclass.py
file or the products __init__.py file? And where in the file
does the code in the second line get used exactly?

Sorry for being a little dense,

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 Product as DataSkin

[Michael R. Bernstein]

Philip,

I have gone spelunking into the DataSkin class source to try
to find out why subclassing from DataSkin is interfering
with 'normal' (not in a rack) instantiation of the product,
but with no success. Any assistance you could give would be
appreciated.

BTW, I think the first line needs to read:

from Products.ZPatterns.DataSkins import DataSkin

Thanks,

Michael Bernstein.

Michael Bernstein wrote:
> 
> "Phillip J. Eby" wrote:
> >
> > At 12:51 PM 2/18/01 -0800, Michael R. Bernstein wrote:
> > >
> > >What do I need to change (import/subclass) in order to use
> > >it in this way?
> >
> > from ZPatterns.DataSkins import DataSkin
> >
> > class MyClass(DataSkin,...all other bases...):
> 
> Here is the error and
> traceback from trying to instantiate the modified Product
> (through the standard mgmt interface):
> 
> This resource may be trying to reference a
> nonexistent object or variable _v_dm_
> 
> The URL may be incorrect.
> The parameters passed to this resource may be incorrect.
> A resource that this resource relies on may be encountering
> an error.
> 
> Traceback (innermost last):
>   File
> /usr/local/Zope-2.2.0-src/lib/python/ZPublisher/Publish.py,
> line 222, in publish_module
>   File
> /usr/local/Zope-2.2.0-src/lib/python/ZPublisher/Publish.py,
> line 187, in publish
>   File
> /usr/local/Zope-2.2.0-src/lib/python/Zope/__init__.py, line
> 221, in zpublisher_exception_hook
>   File
> /usr/local/Zope-2.2.0-src/lib/python/ZPublisher/Publish.py,
> line 171, in publish
>   File
> /usr/local/Zope-2.2.0-src/lib/python/ZPublisher/mapply.py,
> line 160, in mapply
> (Object: manage_addArchiveImage)
>   File
> /usr/local/Zope-2.2.0-src/lib/python/ZPublisher/Publish.py,
> line 112, in call_object
> (Object: manage_addArchiveImage)
>   File /home/webmaven/Products/ArchiveImage/ArchiveImage.py,
> line 46, in manage_addArchiveImage
> (Object: ApplicationDefaultPermissions)
>   File /home/webmaven/Products/ArchiveImage/ArchiveImage.py,
> line 79, in __init__
> (Object: ElementWithAttributes)
>   File /home/webmaven/Products/ZPatterns/DataSkins.py, line
> 208, in __set_attr__
> (Object: ElementWithAttributes)
> KeyError: (see above)

___
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 Product as DataSkin

[Michael R. Bernstein]

"Phillip J. Eby" wrote:
> 
> At 09:49 PM 2/18/01 -0800, Michael R. Bernstein wrote:
> >
> >Ok, assuming that the 'normal' instantiation is either
> >solved or a non-issue, do I need to do anything special to
> >get the newItem() method to call my products manage_add
> >method?
> 
> newItem() will not do that.  A Rack's newItem() method always takes only an
> 'id' method.  You'll need a method on the object itself that can be given
> anything else you want to give it, which you'll call from a method you
> create on the specialist, e.g. a "myAdd" method that takes all four
> parameters and then does something like:
> 
> newObject = self.newItem(id)
> newObject.setup(extraParm1,extraParm2,...)
> return newObject

Hmm. So I need to refactor the 'manage_add' method inside
the python product into two methods, 'manage_add' which
would be used by the 'normal' object creation process and
that would also call a second 'setup' method which could be
called by the specialists 'myadd' method directly, bypassing
the 'manage_add' method entirely.

Is that correct?

Is there anything else I would need to change?

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] Python Product as DataSkin

[Michael R. Bernstein]

"Phillip J. Eby" wrote:
> 
> At 12:51 PM 2/18/01 -0800, Michael R. Bernstein wrote:
> >I have an existing Python Product that I would like to use
> >as a DataSkin in a Rack.
> >
> >What do I need to change (import/subclass) in order to use
> >it in this way?
> >
> 
> from ZPatterns.DataSkins import DataSkin
> 
> class MyClass(DataSkin,...all other bases...):

Ok, assuming that the 'normal' instantiation is either
solved or a non-issue, do I need to do anything special to
get the newItem() method to call my products manage_add
method?

The manage_add method takes an id, an optional title, and an
uploaded file.

When I try passing these to newItem(), it complains that
it's getting "too many arguments, expected 2 got 4", but
when I only pass the id, it complains that "not enough
arguments; expected 4, got 2"

As far as I can determine, the fourth/second argument that
it gets in each case is 'self'.

So what do I do next?

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 Product as DataSkin

[Michael R. Bernstein]

"Phillip J. Eby" wrote:
> 
> At 12:51 PM 2/18/01 -0800, Michael R. Bernstein wrote:
> >I have an existing Python Product that I would like to use
> >as a DataSkin in a Rack.
> >
> >What do I need to change (import/subclass) in order to use
> >it in this way?
> >
> 
> from ZPatterns.DataSkins import DataSkin
> 
> class MyClass(DataSkin,...all other bases...):

Hmm. I thought I was doing it wrong. Here is the error and
traceback from trying to instantiate the modified Product
(through the standard mgmt interface):

This resource may be trying to reference a
nonexistent object or variable _v_dm_

The URL may be incorrect.
The parameters passed to this resource may be incorrect.
A resource that this resource relies on may be encountering
an error.

Traceback (innermost last):
  File
/usr/local/Zope-2.2.0-src/lib/python/ZPublisher/Publish.py,
line 222, in publish_module
  File
/usr/local/Zope-2.2.0-src/lib/python/ZPublisher/Publish.py,
line 187, in publish
  File
/usr/local/Zope-2.2.0-src/lib/python/Zope/__init__.py, line
221, in zpublisher_exception_hook
  File
/usr/local/Zope-2.2.0-src/lib/python/ZPublisher/Publish.py,
line 171, in publish
  File
/usr/local/Zope-2.2.0-src/lib/python/ZPublisher/mapply.py,
line 160, in mapply
(Object: manage_addArchiveImage)
  File
/usr/local/Zope-2.2.0-src/lib/python/ZPublisher/Publish.py,
line 112, in call_object
(Object: manage_addArchiveImage)
  File /home/webmaven/Products/ArchiveImage/ArchiveImage.py,
line 46, in manage_addArchiveImage
(Object: ApplicationDefaultPermissions)
  File /home/webmaven/Products/ArchiveImage/ArchiveImage.py,
line 79, in __init__
(Object: ElementWithAttributes)
  File /home/webmaven/Products/ZPatterns/DataSkins.py, line
208, in __set_attr__
(Object: ElementWithAttributes)
KeyError: (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] ZCatalog scalability

[Michael R. Bernstein]

Erik Enge wrote:
> 
> [Michael R. Bernstein]
> 
> | What I'm looking for is any indication that object creation time
> | and/or indexing time goes up with the number of objects already in
> | the ZODB.
> 
> Well, one thing I've already learned - which you all probably know -
> is that you do _not_ want to put index_object() in your class'
> __init__() method.  That's because the CatalogAwarness class you
> subclass does this for you in the manage_afterAdd() method.

For my 'archive' applications, I'm using a SkinScript to
index the objects as they're added instead of subclassing
from CatalogAware.

> | Will you be populating the ZODB in batches (say 100,000 objects or
> | so)?
> 
> I'll do that as a secondary solution, if doing it in one batch is too
> ineffective.

I should mention that even spliting this up into three
batches of 9 million records would *probably* give me the
indication I'm looking for, as to whether there was any
progressive performance degradation with the number of
objects.

Thanks again, Erik, and good luck!

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

[Michael R. Bernstein]

Erik Enge wrote:
> 
> [Michael R. Bernstein]
> 
> | Erik Enge wrote:
> | >
> | > I'll let you know how it goes.  (And please, do poke at me if it takes
> | > too long.)
> |
> | Ok, I'm poking :-).
> 
> Thanks.  Keep doing it till you get what you need, I truly don't
> mind.  :-)
> 
> | How did it go?
> 
> Thanks to the speed of delivery at Royal Mail in the UK, I haven't
> recieved the data yet (!).  They promised to have it too me by the
> coming friday (the 23rd, I believe).  I'll try to process all 27
> million records and give feeback to the community.
> 
> (I did a premature calculation of how long it would take to populate
> the Zope instance, and I'm guessing somewhere between 80 to 100 hours,
> meaning the feedback cannot come any sooner than Sunday, at best.)

What I'm looking for is any indication that object creation
time and/or indexing time goes up with the number of objects
already in the ZODB.

Will you be populating the ZODB in batches (say 100,000
objects or so)? If so, can you benchmark each batch, so we
can see if the batch proccessing time goes up as you
progress through the 270 batches?

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

[Michael R. 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.)

Ok, I'm poking :-).

How did it go?

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] Python Product as DataSkin

[Michael R. Bernstein]

I have an existing Python Product that I would like to use
as a DataSkin in a Rack.

What do I need to change (import/subclass) in order to use
it in this way?

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] Photo Product Strangeness

[Michael R. Bernstein]

I've been messing around with the Photo product, and I've
noticed something odd about how it handles changes to the
display sizes:

When you create several Photo objects in the same folder
(not in a ZPhotoAlbumPage), they affect each others display
sizes. For example, changing one of the display sizes in one
Photo will change the corresponding display in sibling
Photo.

Can anyone suggest how to fix 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] Using Zope for Groupware/Messaging applications

[Michael R. Bernstein]

"R. David Murray" wrote:
> 
> This means you can do things like
> have (my example) a Paradox database of books, authors, and a
> books-to-authors map, and have Author and Book objects in the system
> such that a Book has a list of its Author objects and the Author
> has a list of its Book objects, all in about 20 lines of ZSQL and
> skinscript.  Plus I have a 'long description' field that comes from
> another database table, and thumbnail and full sized images that
> are stored in Image objects in the ZODB.  All this stuff is seemlessly
> assembled into Author and Book objects by, like I said, about
> 20 lines of the skinscript and zsql.

How are you entering the data into the system? Specifically,
how are you *normalizing* the Author and book information?

I'm working on a ZPatterns based book cataloging
application, and right now I'm storing 'Book' objects with
the author names as a 'lines' property in the ZClass.

I'd like to change this so 'Author' objects are created and
stored in their own Specialist when a book is added, but I'm
not sure how.

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 )