[Grok-dev] Towards a new publisher

[Justin A Ryan]

Howdy..

I know I'm joining this late, but I have talked a bit with Souheil recently
on IRC about this ongoing discussion.

The first thing he told me is there was talk about using WebOb, which makes
obvious sense..

I'll try to trim this to what I have commentary on, seems like a good point
to comment..

Chris McDonough wrote:

>
> FTR, here's a "if I had it to do all again" list:
>
> - I would totally decouple the call signature of view callables from
>  the adaptation arguments used to find the callable.  This is
>  the case in BFG right now: the code which finds a BFG view callable
>  is actually a named adapter with three provides arguments
>  at the moment, but we don't use getMultiAdapter to both find
>  and call the view; we just use adapters.lookup to find one, then
>  call it with arguments that make more sense.  The view callables
>  themselves accept either (context, request) or just (request,).
>
>
Def an interesting idea to lighten the views..


>
> - I would build BFG atop a subsystem that allowed use by frameworks
>  with simpler view lookup requirements.
>  http://bitbucket.org/chrism/marco is such a system.  Then I'd build
>  BFG atop that and try to convince other framework authors (Pylons,
>  etc) to share the same subsystem.
>
>
+1 to this..

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.

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.


> On Tue, 2010-05-18 at 19:40 +0200, Martijn Faassen wrote:
> > Hi there,
> >
> > Souheil CHELFOUH wrote:
> > > I'm very enthousiastic about that.
> > > My only thought is that, we should start designing it and, if we find,
> > > along the way that it looks like things we can take from other
> > > projects, so be it.
> >
> > Here are some of my design thoughts:
> >
> > * no need to support the APIs of the current publisher
> >
>

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.


> > * retain model/view separation
> >
> > * should it be adaptation of (request, context) instead of (context,
> > request)? (see ChrisM's blog)
> >
>




> > * expand views with predicates
> >
> > * explore functions as views
> >
>

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.

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.


> >
> > * everything in a reusable package. This is enough to create web apps.
> >
>

Rawk on this, for sure!

Agree with many of Martijn's other points here, just don't want to +1 the
whole thing and text flood the list.

One other very important thing... I would make the base system work
> without any need for thread locals.  If I continued to use the ZCA, this
> change would imply that there would always be a "registry" (ZCA registry
> object) attached to the request and programmers would be expected to use
> it; the global ZCA API would not work.
>
>
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.zope.org/pipermail/grok-dev/attachments/20100522/a2d515a0/attachment.html