Re: Silva2.3 / NotYet exception

Andrew Altepeter <[email protected]> Wed, 21 Sep 2011 11:02:16 -0500
Newsgroups gmane.comp.web.zope.silva.devel
Message-ID <CAEssFdD+ZOMtY-9MEgGSBGxYno=WaUQde5KxrK9PLt6wtr2ebQ@mail.gmail.com>
--===============8480633812221811605==
Content-Type: multipart/alternative; boundary=000e0cd352063a5f0204ad75b362

--000e0cd352063a5f0204ad75b362
Content-Type: text/plain; charset=ISO-8859-1

>
>   In SilvaNews, viewers are linked to filters using references (that
> doesn't break if you move around filters, and that manage deletion cases and
> so on).
>
>   Reading from the traceback, I see it is a code source, I would say that
> the hardcoded path to the viewer as a parameter has at least two time the
> same ZODB object in its path (seems to be admissions here with
> ..../admissions/visit/events/admissions/cas-admissions-events-viewer). I
> would rather fix that parameter than something else (we would need to have
> something that clean the acquisition path to do it automatically).
>

Actually stepping through with the debugger I see it isn't a problem getting
the filters.  The problem is when the InlineViewer uses
'model.restirctedTraverse(viewer_path)' to actually get the viewer (a.k.a.
provider).  There is an acquisition 'loop' in the path, such that the aq
chain for the news viewer contains the publication twice, see:

So the model is at /silva/cas/admissions/index
The viewer_path is 'admissions/cas-admissions-events-viewer'
The viewer is a /silva/cas/admissions/cas-admissions-events-viewer

The aq_chain for this provider is:
aq_chain(provider)
[<AgendaViewer at /silva/cas/admissions/cas-admissions-events-viewer>,
<Publication at /silva/cas/admissions used for
/silva/cas/admissions/visit/index>, <Page at
/silva/cas/admissions/visit/index>, <Folder at /silva/cas/admissions/visit>,
<Publication at /silva/cas/admissions>, <Publication at /silva/cas>, <Root
at /silva>, <Application at >, <ZPublisher.BaseRequest.RequestContainer
object at 0xcf9d5ec>]

The problem, I think, is the second item in the list: <Publication at X used
for Y> (this publication appears farther down the chain as well.) Attempting
to use aq_inner as well, i.e. aq_chain(aq_inner(provider), yields the same
chain.

If I instead re-acquire the viewer from the root, i.e.:
aq_chain(provider.restrictedTraverse(provider.getPhysicalPath()))

I get a clean aq_chain, and no NotYet errors.  To me, I read this a problem
resulting from the use of restrictedTraverse (or unrestrictedTraverse for
that matter).

I'm not sure what the best means is to adjust the code.  Ideas?

>
>   Hopefully in Silva 3.0, you have a reference field for code sources, so
> this doesn't happen anymore.
>
Man, I can't wait for those reference fields!

Thanks,
Andy

--000e0cd352063a5f0204ad75b362
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">=A0=A0In SilvaNe=
ws, viewers are linked to filters using references (that doesn&#39;t break =
if you move around filters, and that manage deletion cases and so on).<br>

<br>
 =A0 Reading from the traceback, I see it is a code source, I would say tha=
t the hardcoded path to the viewer as a parameter has at least two time the=
 same ZODB object in its path (seems to be admissions here with ..../admiss=
ions/visit/events/admissions/cas-admissions-events-viewer). I would rather =
fix that parameter than something else (we would need to have something tha=
t clean the acquisition path to do it automatically).<br>
</blockquote><div><br></div><div>Actually stepping through with the debugge=
r I see it isn&#39;t a problem getting the filters. =A0The problem is when =
the InlineViewer uses &#39;model.restirctedTraverse(viewer_path)&#39; to ac=
tually get the viewer (a.k.a. provider). =A0There is an acquisition &#39;lo=
op&#39; in the path, such that the aq chain for the news viewer contains th=
e publication twice, see:</div>
<div><br></div><div>So the model is at /silva/cas/admissions/index</div><di=
v>The viewer_path is &#39;admissions/cas-admissions-events-viewer&#39;</div=
><div>The viewer is a /silva/cas/admissions/cas-admissions-events-viewer</d=
iv>
<div><br></div><div>The aq_chain for this provider is:</div><div>aq_chain(p=
rovider)</div><div><div>[&lt;AgendaViewer at /silva/cas/admissions/cas-admi=
ssions-events-viewer&gt;, &lt;Publication at /silva/cas/admissions used for=
 /silva/cas/admissions/visit/index&gt;, &lt;Page at /silva/cas/admissions/v=
isit/index&gt;, &lt;Folder at /silva/cas/admissions/visit&gt;, &lt;Publicat=
ion at /silva/cas/admissions&gt;, &lt;Publication at /silva/cas&gt;, &lt;Ro=
ot at /silva&gt;, &lt;Application at &gt;, &lt;ZPublisher.BaseRequest.Reque=
stContainer object at 0xcf9d5ec&gt;]</div>
</div><div><br></div><div>The problem, I think, is the second item in the l=
ist: &lt;Publication at X used for Y&gt; (this publication appears farther =
down the chain as well.) Attempting to use aq_inner as well, i.e. aq_chain(=
aq_inner(provider), yields the same chain.</div>
<div><br></div><div>If I instead re-acquire the viewer from the root, i.e.:=
</div><div>aq_chain(provider.restrictedTraverse(provider.getPhysicalPath())=
)</div><div><br></div><div>I get a clean aq_chain, and no NotYet errors. =
=A0To me, I read this a problem resulting from the use of restrictedTravers=
e (or unrestrictedTraverse for that matter).</div>
<div><br></div><div>I&#39;m not sure what the best means is to adjust the c=
ode. =A0Ideas?</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><br>
 =A0 Hopefully in Silva 3.0, you have a reference field for code sources, s=
o this doesn&#39;t happen anymore.<br></blockquote><div>Man, I can&#39;t wa=
it for those reference fields!</div><div><br></div><div>Thanks,</div><div>
Andy</div><div><br></div></div><br>

--000e0cd352063a5f0204ad75b362--

--===============8480633812221811605==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
silva-dev mailing list
silva-dev-IAPFreCvJWM6s/[email protected]
https://lists.infrae.com/mailman/listinfo/silva-dev

--===============8480633812221811605==--