<div dir="ltr">Bonsoir,<br><div><div class="gmail_extra"><br><br><div class="gmail_quote">2014-07-09 21:42 GMT+02:00 Christophe de Vienne <span dir="ltr"><<a href="mailto:christophe@unlish.com" target="_blank">christophe@unlish.com</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello Paul,<br>
<br>
Thanks for sharing your wisdom with us, it will certainly help us to<br>
succeed in our attempt to breed CubicWeb and Pyramid !<br>
<br>
Le 08/07/2014 15:29, Paul Everitt a écrit :<br>
<div class="">> Hi everybody, I'm Paul, one of the Pyramid guys. Nicolas and I know each other from way back, first met him at Saarbrucken in 2002.<br>
><br>
> I told Nicolas I would give some comments on places to use Pyramid as a framework-framework. I'm not a Pyramid superhero nor do I know anything about CubicWeb. But I do give Pyramid training and have collected some material for a Pyramid Add-on Developer Guide.<br>

><br>
> Rather than one big email, I'll try to pick some individual topics, starting with render_view:<br>
><br>
>   <a href="https://bitbucket.org/unlish/pyramid_cubicweb/src/07089fd649afaf50e0d0aee01be19100965c9b02/pyramid_cubicweb/__init__.py?at=default#cl-85" target="_blank">https://bitbucket.org/unlish/pyramid_cubicweb/src/07089fd649afaf50e0d0aee01be19100965c9b02/pyramid_cubicweb/__init__.py?at=default#cl-85</a><br>

><br>
> There might be some better ways to approach this, but first I need some background on the intent. It looks like CubicWeb has a registry. Pyramid does also. In the beginning, of course, you won't look at switching away from your registry.<br>

<br>
</div>The cubicweb registry will probably stay in the long term because it<br>
handle things that are not purely web related, like database hooks. As<br>
such, it may be used from outside a web application, like a shell<br>
script, and it should remain usable without pyramid at all.<br>
<br>
That said, at one point we will want to dig into the two registries and<br>
evaluate how much they have in common.<br>
<div class=""><br></div></blockquote><div><br></div><div>Agreed.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">
<br>
> The comment for render_view says:<br>
><br>
>     # XXX The select() function could, know how to handle a pyramid<br>
>     # request, and feed it directly to the views that supports it.<br>
>     # On the other hand, we could refine the View concept and decide it works<br>
>     # with a cnx, and never with a WebRequest<br>
><br>
> It then looks like you head over into CubicWebLand to manage the request and return a response.<br>
<br>
</div>Somehow yes, but direct management of the request and response by the<br>
views is a point that needs discussions and decisions to be made.<br>
<br>
The way I see them, views can be (and are) used to build web response<br>
content, but they can be used to do other things. For example we use<br>
them to build email content, or xml/json/rdf/(and more) representations<br>
of the datas.<br>
<br>
We could describe them as an adaptive templating system : views uses<br>
each others to build a consistent representation of a dataset, and the<br>
predicate-based selectors allow to override a view for specific cases.<br>
<br>
So having them handling directly manage the request and return a<br>
response seems not right to me.<br></blockquote><div><br></div><div>Just trying to say the same thing, with almost the same words :)<br></div><div><br></div><div>In CubicWeb, there's a standard (but somewhat replaceable) stack of objects dedicated to<br>
the handling of the request. They define an "internal world" where many things like<br></div><div>http direct response and return code handling, form marhsalling, default html template/layout system, <br>etc... are boilerplated away. <br>
<br>In this world live "views" and other ui "components" which are specialized<br></div><div>to the various rendering aspects of data structured according to a Yams schema.<br></div><div>Even "controllers" live within the comfortable bounds of this world.<br>
<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
That said they often generate web-oriented content, and do that<br>
depending on inputs found in the request. They also need to inject<br>
resource dependencies into the response, like css of js links.<br>
<br>
Because of that, they hardly can take a single connection do their job.<br></blockquote><div><br></div><div>Because of composition through ajax ?<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

We may need to make a distinction between "basic" views and "web" views,<br>
or define a simple api (some 'context' argument ?) to push relevant<br>
informations into them.<br></blockquote><div><br></div><div>There's a "pageid" notion that maybe matches your "basic" vs "web" views. Or not.<br></div><div>Can you expand ?<br></div><div>
 </div>Regards,<br></div><div class="gmail_quote">Aurélien<br></div></div></div></div>