repoze.bfg

[Chris McDonough]

I've been working on a new web framework named (provisionally) repoze.bfg.

The relevant README is here: http://svn.repoze.org/repoze.bfg/trunk/README.txt

It is essentially a "Zope lite".  It is Zope-ish in that:

  - it uses a lot of Zope libraries and concepts (interfaces, some CA constructs,
    ZCML)

  - it uses graph-traversal-based URL dispatch.

  - by default it provides ZPT (actually z3c.pt) templates.

  - it provides built-in authorization facilities based on permissions
    and users/groups.

It is unlike Zope (variously 2 or 3) inasmuch as:

  - It uses a different publisher and authorization model.

  - It is heavily dependent on WSGI.

  - Its equivalent of the publisher doesn't attempt to traverse into
    *code* stored in the object graph.  All code is on the filesystem.
    The only thing in the object graph is "model" data.

  - It doesn't attempt to provide any server functionality.  This duty is
    left over to WSGI.

  - It doesn't provide *authentication* functionality (just authorization
    functionality).  Authentication is left up to upstream server/middleware
    (e.g. repoze.who).

  - It's not meant to be "plugged in to".  A repoze.bfg application is not
    a plugin to repoze.bfg (e.g. it's not a Zope2 Product).  Instead, a
    repoze.bfg application is just a Python package that happens to use
    repoze.bfg facilities.

  - The graph root is not effectively assumed to be a ZODB database.

  - It provides no built-in through-the-web management interface.

It's unlike Grok inasmuch as:

  - It doesn't try to hide ZCML for configuration.

If I were to characterize it succintly and informally, I migh say it's a bit
like Django built around graph traversal dispatch instead of URL-based dispatch.

Speed is a priority.  A "hello world" template is currently clocking in at
around 550 req/sec on my MacBook (including security lookups).

It's my intent to continue to develop it, along with a package named
"repoze.lemonade", which will integrate repoze.bfg with ZODB and provide various
persistence-related features (folders, object events, indexing and so forth).

In any case, I thought maybe some folks would be interested in
using/contributing to it.  It can be checked out via:

svn co http://svn.repoze.org/repoze.bfg/trunk/

Thanks,

- C


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Plone-developers mailing list
Plone-developers@...
https://lists.sourceforge.net/lists/listinfo/plone-developers

[Martin Aspeli]

Chris McDonough wrote:

I've been working on a new web framework named (provisionally) repoze.bfg.

The relevant README is here: http://svn.repoze.org/repoze.bfg/trunk/README.txt

Why? :-)

Martin

[Chris McDonough]

Just scratching an itch.

Martin Aspeli wrote:

>
>
> Chris McDonough wrote:
>> I've been working on a new web framework named (provisionally) repoze.bfg.
>>
>> The relevant README is here:
>> http://svn.repoze.org/repoze.bfg/trunk/README.txt
>>
>
> Why? :-)
>
> Martin
>

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Plone-developers mailing list
Plone-developers@...
https://lists.sourceforge.net/lists/listinfo/plone-developers

[Martin Aspeli]

Chris McDonough wrote:

Just scratching an itch.

Which one? :-p

Seriously, though, it looks interesting. I'm curious when you think it may be useful.

Martin

[Paul Everitt-3]

Martin Aspeli wrote:

>
>
> Chris McDonough wrote:
>> Just scratching an itch.
>>
>
> Which one? :-p
>
> Seriously, though, it looks interesting. I'm curious when you think it may
> be useful.

I think of it like this: for people that like Python a lot, and like
Python web frameworks, and want to re-use stuff from that world (Paste,
WebOb, FormEncode, etc.), but might also like the technologies of Zope.
  As opposed to keeping Zope basically intact and bolting on modern Python.

Stated differently, if you were going to use modern Python as the
starting point, and then do the best parts of Bobo/Zope, while leaving
out the bad stuff, this *might be* what you'd get.  (All of that is
subjective, of course.)

I also like that it is: very small (conceptually and code-wise), very
very fast, and you don't get the fighting-the-framework feeling.

--Paul


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Plone-developers mailing list
Plone-developers@...
https://lists.sourceforge.net/lists/listinfo/plone-developers

[Chris McDonough]

Martin Aspeli wrote:
>
>
> Chris McDonough wrote:
>> Just scratching an itch.
>>
>
> Which one? :-p

The really awful itchy one one where I need to wrap my brain around reams of
highly overgeneralized code, sacrifice chickens, and mentally elide the 3/4 of
the system I don't use in order to do simple things without losing all the good
bits.

> Seriously, though, it looks interesting. I'm curious when you think it may
> be useful.

It's useful now.  We're dogfooding:  http://repoze.org/ is running via
"repoze.virginia", the first production BFG application.

http://svn.repoze.org/repoze.virginia/trunk/

- C

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Plone-developers mailing list
Plone-developers@...
https://lists.sourceforge.net/lists/listinfo/plone-developers

[Malthe Borch-2]

Chris McDonough wrote:
> I've been working on a new web framework named (provisionally) repoze.bfg.

This looks very interesting; I'd be curious to see if this could be
useful for Vudo. I'd like it very much if Vudo could sit on top of a
more general framework (not just the Zope 3 libraries).

Early on, the idea was that this could be Grok, but it quickly turned
out that Grok makes too many assumptions for our use.

I recently pasted a basic Pylons application and it gives you something
that I think would be attractive in a Zope/Vudo/Bfg-based setup: A
canonical directory structure, e.g.

./templates
./routers
./config

etc. (can't remember the details)

Perhaps this could benefit the following scenario:

-- Set me up with a new Zope/Vudo/Bfg-application and give me some
starting points.

If Bfg can provide the lower layer, then I think Vudo will be great for
providing the higher layers, e.g.

-- skinning
-- content types and widgets
-- authoring
-- admin

\malthe

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Plone-developers mailing list
Plone-developers@...
https://lists.sourceforge.net/lists/listinfo/plone-developers

[Wichert Akkerman]

Previously Malthe Borch wrote:

> Chris McDonough wrote:
> > I've been working on a new web framework named (provisionally) repoze.bfg.
>
> This looks very interesting; I'd be curious to see if this could be
> useful for Vudo. I'd like it very much if Vudo could sit on top of a
> more general framework (not just the Zope 3 libraries).
>
> Early on, the idea was that this could be Grok, but it quickly turned
> out that Grok makes too many assumptions for our use.
>
> I recently pasted a basic Pylons application and it gives you something
> that I think would be attractive in a Zope/Vudo/Bfg-based setup: A
> canonical directory structure, e.g.
>
> ./templates
> ./routers
> ./config

templates - page templates
controllers - the pylons-version of views. sort-of.
config - everything related to the appplication configuration
lib - all our utilities
models - data models
public - static web content


Wichert.

--
Wichert Akkerman <wichert@...>    It is simple to make things.
http://www.wiggy.net/                   It is hard to make things simple.

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Plone-developers mailing list
Plone-developers@...
https://lists.sourceforge.net/lists/listinfo/plone-developers

[Chris McDonough]

Malthe Borch wrote:

> Chris McDonough wrote:
>> I've been working on a new web framework named (provisionally) repoze.bfg.
>
> This looks very interesting; I'd be curious to see if this could be
> useful for Vudo. I'd like it very much if Vudo could sit on top of a
> more general framework (not just the Zope 3 libraries).
>
> Early on, the idea was that this could be Grok, but it quickly turned
> out that Grok makes too many assumptions for our use.
>
> I recently pasted a basic Pylons application and it gives you something
> that I think would be attractive in a Zope/Vudo/Bfg-based setup: A
> canonical directory structure, e.g.
>
> ./templates
> ./routers
> ./config
>
> etc. (can't remember the details)

Sure.  I think one of us (maybe Paul?) signed up to write a PasteScript template
to lay out a directory structure something like this.

We don't currently provide an easy way to serve out a static directory full of
content.  We'd need to add that (or decide not to add it in favor of letting a
separate "resource" server serve the static stuff).

> Perhaps this could benefit the following scenario:
>
> -- Set me up with a new Zope/Vudo/Bfg-application and give me some
> starting points.
>
> If Bfg can provide the lower layer, then I think Vudo will be great for
> providing the higher layers, e.g.
>
> -- skinning
> -- content types and widgets
> -- authoring
> -- admin

Sounds good to me.

The plans are to keep BFG mostly policy-agnostic save for
the very basics (graph traversal, a default templating language, and a calling
and response convention for views).

I had planned to create another package named repoze.lemonade which:

  - Wired in ZODB

  - Defined base classes for folderish and leafish types.

  - Had an object add/remove/move event model.

  - Did indexing of content.

It sounds like Vudo could either build on top of that or just *be* that.  It
might be better to continue layering stuff, I suppose, without going "straight
to the content management layer".  Would it be appropriate for Vudo to build on
something like that?

What would Vudo need out of a framework?

- C

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Plone-developers mailing list
Plone-developers@...
https://lists.sourceforge.net/lists/listinfo/plone-developers

[Martin Aspeli]

Chris McDonough wrote:

We don't currently provide an easy way to serve out a static directory full of
content.  We'd need to add that (or decide not to add it in favor of letting a
separate "resource" server serve the static stuff).

Paste has an app for this. You can use a composite app to have this "mounted" onto a particular path.

I had planned to create another package named repoze.lemonade which:

  - Wired in ZODB

  - Defined base classes for folderish and leafish types.

  - Had an object add/remove/move event model.

  - Did indexing of content.

This would definitely be needed before this would be useful to the people who are using Zope today. :)

It sounds like Vudo could either build on top of that or just *be* that.  It
might be better to continue layering stuff, I suppose, without going "straight
to the content management layer".  Would it be appropriate for Vudo to build on
something like that?

I would be careful not to build a framework that's also a CMS (or the other way around) into one layer.

Martin

[Yuri-11]

Martin Aspeli ha scritto:

>
> Chris McDonough wrote:
>  
>> We don't currently provide an easy way to serve out a static directory
>> full of
>> content.  We'd need to add that (or decide not to add it in favor of
>> letting a
>> separate "resource" server serve the static stuff).
>>
>>    
>
> Paste has an app for this. You can use a composite app to have this
> "mounted" onto a particular path.
>
>
>
>  
>> I had planned to create another package named repoze.lemonade which:
>>
>>   - Wired in ZODB
>>
>>   - Defined base classes for folderish and leafish types.
>>    

Mmmm:

http://limi.net/articles/composite-pages-listings-and-content-proxies
http://limi.net/articles/improve-plones-handling-of-rich-media

kill the folders! :)

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Plone-developers mailing list
Plone-developers@...
https://lists.sourceforge.net/lists/listinfo/plone-developers

[Chris McDonough]

Martin Aspeli wrote:

>
>
> Chris McDonough wrote:
>> We don't currently provide an easy way to serve out a static directory
>> full of
>> content.  We'd need to add that (or decide not to add it in favor of
>> letting a
>> separate "resource" server serve the static stuff).
>>
>
> Paste has an app for this. You can use a composite app to have this
> "mounted" onto a particular path.

It sure does.

>> I had planned to create another package named repoze.lemonade which:
>>
>>   - Wired in ZODB
>>
>>   - Defined base classes for folderish and leafish types.
>>
>>   - Had an object add/remove/move event model.
>>
>>   - Did indexing of content.
>>
>
> This would definitely be needed before this would be useful to the people
> who are using Zope today. :)

We're using both it and Zope, and it's already useful without any ZODB or
persistence, or indexing in sight.

But almost certainly for folks who build solutions with Plone the above is true,
though.

>> It sounds like Vudo could either build on top of that or just *be* that.
>> It
>> might be better to continue layering stuff, I suppose, without going
>> "straight
>> to the content management layer".  Would it be appropriate for Vudo to
>> build on
>> something like that?
>>
>
> I would be careful not to build a framework that's also a CMS (or the other
> way around) into one layer.

Ya think? ;-)

- C

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Plone-developers mailing list
Plone-developers@...
https://lists.sourceforge.net/lists/listinfo/plone-developers

[Martijn Faassen-2]

Hey,

Chris McDonough wrote:
[snip]
> It's unlike Grok inasmuch as:
>
>  - It doesn't try to hide ZCML for configuration.

Hiding is the wrong word. Grok doesn't hide ZCML for configuration. It
simply replaces ZCML with a different configuration mechanism that I for
one think is an improvement. One that you could easily start using with
grokcore.component, I may add. You can mix and match with ZCML-based
configuration as you please.

That brings me to another difference with Grok: your framework is also
unlike Grok inasmuch it's incompatible with Zope 3, correct?

Regards,

Martijn


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Plone-developers mailing list
Plone-developers@...
https://lists.sourceforge.net/lists/listinfo/plone-developers

[Martijn Faassen-2]

Malthe Borch wrote:

> Chris McDonough wrote:
>> I've been working on a new web framework named (provisionally)
>> repoze.bfg.
>
> This looks very interesting; I'd be curious to see if this could be
> useful for Vudo. I'd like it very much if Vudo could sit on top of a
> more general framework (not just the Zope 3 libraries).
>
> Early on, the idea was that this could be Grok, but it quickly turned
> out that Grok makes too many assumptions for our use.

You're using Zope 3, right? Zope 3 makes the same set of assumptions
Grok does, with very minor differences indeed.

Could you be more explicit about what exactly in Grok was making too
many assumptions?

Wasn't it simply a case of different tastes, instead of assumptions that
get in the way?

Regards,

Martijn


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Plone-developers mailing list
Plone-developers@...
https://lists.sourceforge.net/lists/listinfo/plone-developers

[Chris McDonough]

Martijn Faassen wrote:

> Hey,
>
> Chris McDonough wrote:
> [snip]
>> It's unlike Grok inasmuch as:
>>
>>  - It doesn't try to hide ZCML for configuration.
>
> Hiding is the wrong word. Grok doesn't hide ZCML for configuration. It
> simply replaces ZCML with a different configuration mechanism that I for
> one think is an improvement. One that you could easily start using with
> grokcore.component, I may add. You can mix and match with ZCML-based
> configuration as you please.

Thanks for the clarification.

> That brings me to another difference with Grok: your framework is also
> unlike Grok inasmuch it's incompatible with Zope 3, correct?

Correct, if you're talking about using the Z3 publisher, although repoze.bfg is
based on zope.component and zope.interface internally.

- C


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Plone-developers mailing list
Plone-developers@...
https://lists.sourceforge.net/lists/listinfo/plone-developers

[Martijn Faassen-2]

Hey,

Chris McDonough wrote:
[snip]
> Correct, if you're talking about using the Z3 publisher, although repoze.bfg is
> based on zope.component and zope.interface internally.

I wasn't primarily thinking about the publisher, more about such things
like existing utilities, events, existing content types and so on.

Regards,

Martijn


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Plone-developers mailing list
Plone-developers@...
https://lists.sourceforge.net/lists/listinfo/plone-developers

[Malthe Borch-2]

Martijn Faassen wrote:
> Could you be more explicit about what exactly in Grok was making too
> many assumptions?

First a word on terminology: I mean Grok, the framework, not the
declarative extensions to the component architecture (which I simply
haven't gotten to yet).

We felt that Grok was too much about object publishing; there's a model
and a view for that model (and that view has a template). This didn't
fit so well into our approach.

On Vudo, the view is always a "layout". It's then up to the layout to
provide regions in which you can plug in a "region content provider".
Typically, you'd plug in at least the following:

-- Title provider: Renders the title of the page (in <title></title>)
-- Content provider: Renders the content of the page as widgets

There are many more options to this scheme. You could plug in a portlet
manager, or a viewlet manager or a global navigation.

Next, we didn't want to use ZODB, because we wanted to try something
completely different. So now we've written Dobbin which pretty much
emulates ZODB, but on a SQL storage (so much for trying something new).

I like Grok and I think it's great for writing Zope *applications*; but
we didn't find it such a good match for Vudo. I still want to try
grokcore.component because there are some obvious candidates for
declarative component setup in a system like ours (content-types,
widgets, forms, etc.).

\malthe




-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Plone-developers mailing list
Plone-developers@...
https://lists.sourceforge.net/lists/listinfo/plone-developers

[Brandon Craig Rhodes]

Malthe Borch <mborch@...> writes:

> On Vudo, the view is always a "layout". It's then up to the layout to
> provide regions in which you can plug in a "region content provider".
> Typically, you'd plug in at least the following:
>
> -- Title provider: Renders the title of the page (in <title></title>)
> -- Content provider: Renders the content of the page as widgets
>
> There are many more options to this scheme. You could plug in a portlet
> manager, or a viewlet manager or a global navigation.

Someone mentioned Vudo to me last week.  I said that I was tempted to
write an extension to Grok that lets you create a "grok.Layout" template
that maybe is inherited throughout your whole site if you don't specify
otherwise, and then a "grok.View" on an object would just generate
content for the "main" pane inside of that layout, and viewlets could
keep working like they do today but fill in other parts of the layout.

This is kind of how people look to be doing things today with the
viewlets revolution that's going on in Grok land; look at:

 http://svn.zope.org/Grokstar/trunk/src/grokstar/blog.py?rev=87483&view=auto

and note how many of the "grok.View" objects are specifying the same
dratted template, over and over again, and then rely on viewlets to
actually fill in the varying parts of each page that change with the
content.  It struck me as a situation that is just crying out for a
"grok.Layout" local utility that provides the template everywhere under
a part of a site automatically, so that the "grok.template(...)"
declaration does not have to get repeated so incessantly.

It really looks to me like Grok best-practices are evolving towards a
layout-centric, rather than a macro-centric, approach, and that
something like the Vudo approach would make this all easier to manage.

Do I sound on-target, or like I'm missing something?

--
Brandon Craig Rhodes   brandon@...   http://rhodesmill.org/brandon

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Plone-developers mailing list
Plone-developers@...
https://lists.sourceforge.net/lists/listinfo/plone-developers

[Chris McDonough]

Martijn Faassen wrote:
> Hey,
>
> Chris McDonough wrote:
> [snip]
>> Correct, if you're talking about using the Z3 publisher, although repoze.bfg is
>> based on zope.component and zope.interface internally.
>
> I wasn't primarily thinking about the publisher, more about such things
> like existing utilities, events, existing content types and so on.

Most of those would work.

We don't implement local site managers, but we do use a normal component
registry, so if you've got a global utility that you'd like to use, you'd just
put its registration into the configure.zcml, make sure you had the right
package on the filesystem to handle that registration.

... Speaking of site managers, if you'd like to be able to use more than one
separtely-configured grok application in a process (given that you can't right
now because the global registry is a singleton), you might want to steal this
hack. I myself stole the idea from Stephan's z3c.baseregistry:
http://svn.repoze.org/repoze.bfg/trunk/repoze/bfg/registry.py

Sending events would of course work.  We don't have any event *listeners*, of
course, so it would be pointless to send, e.g. object events.  That said,
"contenty" stuff is not really the job of repoze.bfg, but of a higher-layer
framework.  repoze.bfg is about traversing the content graph and publishing
views and templates.  Everything else is the domain of the "application".

Existing content types would work to the extent that you'd just use them as data
in the ZODB, allowing bfg to traverse the ZODB as the root.  This is also the
domain of the "application" in terms of bfg.

- C


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Plone-developers mailing list
Plone-developers@...
https://lists.sourceforge.net/lists/listinfo/plone-developers