<div class="gmail_quote"><div>Howdy..</div><div><br></div><div>I know I'm joining this late, but I have talked a bit with Souheil recently on IRC about this ongoing discussion.</div><div><br></div><div>The first thing he told me is there was talk about using WebOb, which makes obvious sense..</div>
<div><br></div><div>I'll try to trim this to what I have commentary on, seems like a good point to comment..</div><div><br></div><div>Chris McDonough wrote: </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
FTR, here's a "if I had it to do all again" list:<br>
<br>
- I would totally decouple the call signature of view callables from<br>
the adaptation arguments used to find the callable. This is<br>
the case in BFG right now: the code which finds a BFG view callable<br>
is actually a named adapter with three provides arguments<br>
at the moment, but we don't use getMultiAdapter to both find<br>
and call the view; we just use adapters.lookup to find one, then<br>
call it with arguments that make more sense. The view callables<br>
themselves accept either (context, request) or just (request,).<br>
<br></blockquote><div><br></div><div>Def an interesting idea to lighten the views..</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
- I would build BFG atop a subsystem that allowed use by frameworks<br>
with simpler view lookup requirements.<br>
<a href="http://bitbucket.org/chrism/marco" target="_blank">http://bitbucket.org/chrism/marco</a> is such a system. Then I'd build<br>
BFG atop that and try to convince other framework authors (Pylons,<br>
etc) to share the same subsystem.<br>
<br></blockquote><div><br></div><div>+1 to this..</div><div><br></div><div>I think that Zope tech would be more attractive if a Python web app's entire UI / front-end didn't have to be redone to use it. I love TAL, but we've got genshi and ten other template systems, if people want to use that, that's another convo. I am often concerned that while Django is very popular, it appeals more in its' initial tutorials than for long-term use. Really complicated things sometimes have to happen to combine related, but separately developed Django apps.</div>
<div><br></div><div>BFG is an opportunity for me to promote this outlook for people developing new applications, but there's a ton of people out there using Django, Pylons, TurboGears, etc.. All embrace very similar concepts and it would probably make life easier for a lot of Zope-oriented devs if we could at least reuse some skills we use to launch our own projects, when looking for a buck from the man.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
On Tue, 2010-05-18 at 19:40 +0200, Martijn Faassen wrote:<br>
> Hi there,<br>
><br>
> Souheil CHELFOUH wrote:<br>
> > I'm very enthousiastic about that.<br>
> > My only thought is that, we should start designing it and, if we find,<br>
> > along the way that it looks like things we can take from other<br>
> > projects, so be it.<br>
><br>
> Here are some of my design thoughts:<br>
><br>
> * no need to support the APIs of the current publisher<br>
><br></blockquote><div><br></div><div>Absolutely not. WSGI came in without anyone noticing, so even though some pain would be acceptable, I am not sure this would cause much in the long run.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
> * retain model/view separation<br>
><br>
> * should it be adaptation of (request, context) instead of (context,<br>
> request)? (see ChrisM's blog)<br>
><br></blockquote><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
> * expand views with predicates<br>
><br>
> * explore functions as views<br>
><br></blockquote><div><br></div><div>Sure, this is really a major difference with other frameworks and at the end of the day, a callable class, or a function as view, there isn't a major bit of difference. I think when applications grows, the current Zope approach makes sense, but over the life of Grok and other projects which try to make Zope tech more approachable, I don't think we've found that much of anything can counter what people achieve in their first day with another framework.</div>
<div><br></div><div>I've met tons of people 30, 60, 90 days, even further into projects where they limited themselves on the first day. I think if a frontend built in another framework could be grafted onto a zope app, it would make it very easy to grab people once the fifth day with Django or whatever becomes a pain, or at least somewhere in that first 90 days, ideally the first 30.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
><br>
> * everything in a reusable package. This is enough to create web apps.<br>
><br></blockquote><div><br></div><div>Rawk on this, for sure!</div><div><br></div><div>Agree with many of Martijn's other points here, just don't want to +1 the whole thing and text flood the list.</div><div><br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
One other very important thing... I would make the base system work<br>
without any need for thread locals. If I continued to use the ZCA, this<br>
change would imply that there would always be a "registry" (ZCA registry<br>
object) attached to the request and programmers would be expected to use<br>
it; the global ZCA API would not work.<br><br></blockquote><div><br></div><div>this is an interesting idea. I have definitely found BFG's alternate usage of the CA one of it's more interesting design decisions. I'm on the fence for a number of reasons, but I can't see opposing this.</div>
</div>