Re: [Zope-dev] Re: Refresh trashes acquisition

[Lennart Regebro]

From: "Ross Boylan" <[EMAIL PROTECTED]>
> I thought this list was for developers, including product developers,
> while the other was for zope users.  Isn't that the case?

Nope, but its hould be for product developers, because there isn't one. :-)

> It seems natural to allow some of these options to be specified at a
> high level of containment.  For example, one might have a preferred
> numbering style for questions and another for responses that are set at
> the level of the Ballot (or even higher, possibly).  Then, if you
> wanted to, you could override these lower down.

Yup. And you can to that by setting and acquiring properties. No problemo.

> This style of containment and optional overriding seemed to me exactly
> what acquisition was all about, so I tried to do it with acquisition.
> But it didn't work.

I haven't really understood what didn't work, because I have been on
vacation and not following this thread very closely...

> Based on previous responses, I've implemented a containment hierarchy
> by hand.

"By hand"? You mean that instead of having your objects being Zope objects
added from the Add drop down box, they are pure python objects and added
only by code?



___
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] Refresh trashes acquisition

[Myroslav Opyr]

Gary Speer wrote:

 > I strongly encourage you to switch to the [EMAIL PROTECTED]
 >  mailing list

Why?

 > as this one is dedicated to next-generation product enhancement as
 > opposed to peer user assistance.

Reason rejected... Question was technical and was dedicated to zope-dev
list.

 > The approach you are taking seems a bit convoluted and I, for one, do
 > not understand the business/project objectives reason to construct the
 > objects as you do and create the acquisition cvhallenge you hope to 
solve.

Of course there are questions of software design and questions of
implementation. There is probability that design is not perfect but
technical question remains. Even with poor (Ross, note, I do not tell
that it is now)design there should not be technical problem with
implementation.

 >   Perhaps you can elaborate on the goal you hope to accomplish so
 > others can suggest the better tools and object containment structure
 > to use.  It seems earlier design decisions have taken you to solving
 > issues that might not exist with an alternative,
 > more-naturally-zope-like approach.

As the question appears they should be solved and Ross asked community
to help.

m.

P.S. It is really interesting what X-Spam-Status this message will get
;) the one of Gary had 3.2 :) Maybe there is a sense to lower threshold
from 5.0 to 3.0 ;)
-- 
Myroslav Opyr
zope.net.ua  ° Ukrainian Zope Hosting
e-mail: [EMAIL PROTECTED] 
cell: +380 50.3174578



___
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: Refresh trashes acquisition

[Ross Boylan]

On Thu, Jul 25, 2002 at 12:09:35PM -0700, Gary Speer wrote:
> Dear Ross - 
> I strongly encourage you to switch to the [EMAIL PROTECTED] mailing list as this one is 
>dedicated to next-generation product enhancement as opposed to peer user assistance.

I thought this list was for developers, including product developers,
while the other was for zope users.  Isn't that the case?

> 
> The approach you are taking seems a bit convoluted and I, for one, do not understand 
>the business/project objectives reason to construct the objects as you do and create 
>the acquisition cvhallenge you hope to solve.  Perhaps you can elaborate on the goal 
>you hope to accomplish so others can suggest the better tools and object containment 
>structure to use.  It seems earlier design decisions have taken you to solving issues 
>that might not exist with an alternative, more-naturally-zope-like approach.
> 
> Gary
> 

I suspect you are right that I may be going about this in an un-Zope
like way, so let me describe the goals at a slightly higher level.  My
immediate goal is to be able to do votes for a non-profit organization
I'm in.  Existing tools that I have found (include both non-Zope
things and the Zope Poll product) are not quite flexible enough.  For
example, I want to have several question in one poll (eliminatess most
of the non-Zope things) and I want to be able to have people rank
alternatives for some of the questions (Poll product doesn't have
this).

I'm trying to make something that has lots of little bits that can be
combined flexibly.  For example, one can combine a particular style of
question (yes/no vs ranking) with a way of tabulating the votes
(instant-run-off vs ranked pairs for ranked questions).

The part that's giving me trouble relates to how subitems are
handled.  Questions are subitems of a Ballot, and Response are
subitems of Questions.  There are two choices
1) what order should the items be presented in (e.g., original order
or a random order)?
2) how should they be labelled?  This in turn has two parts: do you
want arabic, roman, or letters for the labels, and what decoration
around that do you want--e.g., "Question xxx:" vs "Issue xxx)".

It seems natural to allow some of these options to be specified at a
high level of containment.  For example, one might have a preferred
numbering style for questions and another for responses that are set at
the level of the Ballot (or even higher, possibly).  Then, if you
wanted to, you could override these lower down.

Specifically, each question determines how to number its responses,
but the style it uses for numbering the responses will typically come
from a higher level.

This style of containment and optional overriding seemed to me exactly
what acquisition was all about, so I tried to do it with acquisition.
But it didn't work.  Based on previous responses, I've implemented a
containment hierarchy by hand.  This works.  Almost surely there is a
better way.

___
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] Refresh trashes acquisition

[Gary Speer]

Dear Ross - 
I strongly encourage you to switch to the [EMAIL PROTECTED] mailing list as this one is 
dedicated to next-generation product enhancement as opposed to peer user 
assistance.
 
The approach you are taking seems a bit convoluted 
and I, for one, do not understand the business/project objectives reason to 
construct the objects as you do and create the acquisition cvhallenge you hope 
to solve.  Perhaps you can elaborate on the goal you hope to accomplish so 
others can suggest the better tools and object containment structure to 
use.  It seems earlier design decisions have taken you to solving issues 
that might not exist with an alternative, more-naturally-zope-like 
approach.
 
Gary
 
 
Message: 2Date: Wed, 24 Jul 2002 13:05:59 -0700To: "Matthew T. 
Kromer" <[EMAIL PROTECTED]>Cc: Ross 
Boylan <[EMAIL PROTECTED]>, 
[EMAIL PROTECTED]Subject: Re: 
[Zope-dev] Refresh trashes acquisitionFrom: Ross Boylan <[EMAIL PROTECTED]>On 
Wed, Jul 24, 2002 at 10:38:44AM -0400, Matthew T. Kromer wrote:> Ross 
Boylan wrote:> > >I find that when I refresh my product it 
destroys some of the> >containment relationships.  Things start 
failing, and as far as I can> >tell the only recovery is to completely 
rebuild the object.> >> >This is a big problem, and if 
anyone could explain what is going on> >and how to avoid it I would 
appreciate it.> >> >Here is the result of aq_chain before 
the refresh:> >[,> 
>, > >8dfc870>, <__FactoryDispatcher__ instance at 
8e73770>,> >, 
> >> >and after> 
>[]> > > 
>> [...]> > > > >> > Hmm, 
while what you're referring to is "refresh" in the sense of a > product 
reload, it's important to first state that *no* acquisition is > expected 
to survive between transactions.> > Each transaction must 
separately acquire its objects; if you try to pass > wrapped objects 
between transactions or threads you're going to end up > in 
trouble.> > Secondly, when a product is refreshed, the 
extensionclass module will > probably create new base classes for any 
ExtensionClass derived class > file.  I dont *think* you can get 
much mileage out of knowing the id > (address) of a class now, but be 
aware that a refresh will likely cause > that address to change.  I 
have seen some bizarre errors where module > "constants" changed because 
of a reload, and "is" tests broke because > "is" tests the object 
address.> > None of this is explicitly what you're asking about -- 
but I think what > you're trying to do is in violation of the "no wrapped 
objects should be > stored past a transaction boundary" rule.> 
> However, I may be misreading your question too -- which is why I 
mention > those two rules above so YOU can see if they make sense in your 
context.> The first point is definitely relevant, and explains 
why I am havingproblems.  It's surprising what I'm doing is workign at 
all!  Theclass redefinition in the second point might explain some of 
thetiming of the problems, but it's the instances, not the classes that 
Iam interested in.The acquisition I want to do is in the object 
containment hierarchy,but URL of the request will also have this 
hieararchy.  Isthere some way I can grab it at the appropriate 
time?Your comments also clarify a point that was unclear to me from 
thedocumentation on acquisition.  The documents refers to the 
objectcontainment hierarchy and the request path hierarchy, and 
recommendkeeping them consistent.  But I didn't understand which 
hierarchy itused if they weren't.  Apparently only the request path 
matters.It may be helpful to say more about the exact relations in my 
case:[indentation indicates containment in this diagram; capital 
lettersare for objects]B  ballot  Q1  
question   R1a response   R1b 
response   SR  suborder of 
responses  see below for 
suborders R1a R1b (same 
objects as the R1's above)  Q2  question ...  NQ  
"namestyle" of questions (determines labeling)  NR  namestyle of 
responses  SQ  suborder of questions (sequential, random, 
...)   this suborder contains a list of the same questions Q1, Q2, 
etc   that the ballot B holds.   It also the name of 
the namestyle, to be acquired from the container.Generally, B and maybe Q 
will be in my request path, and the otheritems are not.I ask the 
suborders for list of items, so they give me back a list ofQ's or R's.  
The items in those lists were the ones I was trying towrap.At the 
most extreme case, I get a response R from the suborder list ofa question Q, 
and I get the Q from the suborder of the ballot.  So I'ttwo levels 
removed from my original context, the ballot B, that hasthe namestyle I'm 
trying to acquire.  The suborder on the Questionneeds to acquire the 
namestyle from the Ballot.Finally, I may be making an overly 
conservative assumption aboutObjectManagers.  Without it, the suborders 
would not need to hold ontoobject references.  It's easiest to explain 
this with a specificexample.  I want to be able to recover the original 
order questionswere entered into t