[Web-SIG] Announcing bobo

[Jim Fulton]

Bobo is a light-weight framework for creating WSGI web applications.

It's goal is to be easy to use and remember. You don't have to be a
genius.

It addresses 2 problems:

- Mapping URLs to objects

- Calling objects to generate HTTP responses

Bobo doesn't have a templateing language, a database integration layer,
or a number of other features that can be provided by WSGI
middle-ware or application-specific libraries.

Bobo builds on other frameworks, most notably WSGI and WebOb.

To learn more. visit: http://bobo.digicool.com

Jim

--
Jim Fulton
Zope Corporation

_______________________________________________
Web-SIG mailing list
Web...@python.org
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe: http://mail.python.org/mailman/options/web-sig/python-web-sig-garchive-9074%40googlegroups.com

[Etienne Robillard]

Nothing very new here. At least next time try to be a little more
creative, otherwise this is getting slightly boring and repetitive...

Regards,

-- Etienne

Jim Fulton wrote:
> Bobo is a light-weight framework for creating WSGI web applications.
>
> It's goal is to be easy to use and remember. You don't have to be a genius.
>
> It addresses 2 problems:
>
> - Mapping URLs to objects
>
> - Calling objects to generate HTTP responses
>
> Bobo doesn't have a templateing language, a database integration layer,
> or a number of other features that can be provided by WSGI
> middle-ware or application-specific libraries.
>
> Bobo builds on other frameworks, most notably WSGI and WebOb.
>
> To learn more. visit: http://bobo.digicool.com
>
> Jim
>
> --
> Jim Fulton
> Zope Corporation

--
Etienne Robillard <robillar...@gmail.com>
Green Tea Hackers Club <http://gthc.org/>
Blog: <http://gthc.org/blog/>
PGP Fingerprint: AED6 B33B B41D 5F4F A92A 2B71 874C FB27 F3A9 BDCC

"L'imagination est plus importante que le savoir"

-- Albert Einstein

[Sergey Schetinin]

On 2009-06-16, Etienne Robillard <robillar...@gmail.com> wrote:
>
> Nothing very new here. At least next time try to be a little more
> creative, otherwise this is getting slightly boring and repetitive...
>

I think that's a bit rough, but indeed there are quite a few
frameworks / components that do this thing and I kind of don't get why
people want to write their apps that way. I wonder if Jim or anyone
else could explain the rationale behind all these URL routing
libraries. Nobody minds calling functions from other functions --
that's basics of programming, but for some reason URL dispatching is
seen as something different. Why?

This is not a criticism, I just really would like to understand this.

-Sergey

[Martijn Faassen]

Hey,

On Tue, Jun 16, 2009 at 4:51 PM, Etienne
Robillard<robillar...@gmail.com> wrote:
>
> Nothing very new here. At least next time try to be a little more
> creative, otherwise this is getting slightly boring and repetitive...

It's a bit rich to call Jim Fulton uncreative concerning web
development. I suggest you delve into the history of Python web
development for a bit. Of course back in '97 there was more to invent
than there is today.

Regards,

Martijn

[P.J. Eby]

At 05:19 PM 6/16/2009 +0200, Martijn Faassen wrote:
>Hey,
>
>On Tue, Jun 16, 2009 at 4:51 PM, Etienne
>Robillard<robillar...@gmail.com> wrote:
> >
> > Nothing very new here. At least next time try to be a little more
> > creative, otherwise this is getting slightly boring and repetitive...
>
>It's a bit rich to call Jim Fulton uncreative concerning web
>development. I suggest you delve into the history of Python web
>development for a bit. Of course back in '97 there was more to invent
>than there is today.

Surely Etienne is joking, since anybody who knows Python web
development should know that Bobo was actually the first Python web
framework ever developed, 12 years ago, and that it invented quite a
lot of the things found in Python web frameworks today, not to
mention being the forerunner of all things Zope.

It's rather nice to see it back, reincarnated on today's egg/WSGI
infrastructure. The original Bobo was what convinced me to become a
Python programmer 12 years ago. (...after I realized that a
Bobo-equivalent framework could not be implemented in Perl without
far greater wizardry than I was capable of managing, while in Python
it was nearly trivial to do so. I left Perl and never looked back.)

[Etienne Robillard]

Martin,

I don't care about '97, pretty much.

I think that if this Jim guy has lots of experience then at least he
could not pretend that other people works are made by/for geniuses,
which is probably untrue anyway.

There's other ways to advertise a open source project. One method
is to discriminate other projects, thus making it's own work appears
better in some ways or another. Of courses this has nothing to do in
being a genius.. You don't have to be a genius to copy-and-paste things.

regards,

Etienne

Martijn Faassen wrote:
> Hey,
>
> On Tue, Jun 16, 2009 at 4:51 PM, Etienne
> Robillard<robillar...@gmail.com> wrote:
>> Nothing very new here. At least next time try to be a little more
>> creative, otherwise this is getting slightly boring and repetitive...
>
> It's a bit rich to call Jim Fulton uncreative concerning web
> development. I suggest you delve into the history of Python web
> development for a bit. Of course back in '97 there was more to invent
> than there is today.
>
> Regards,
>
> Martijn
>

--
Etienne Robillard <robillar...@gmail.com>
Green Tea Hackers Club <http://gthc.org/>
Blog: <http://gthc.org/blog/>
PGP Fingerprint: AED6 B33B B41D 5F4F A92A 2B71 874C FB27 F3A9 BDCC

[Aaron Watters]

> Nobody minds calling functions from other
> functions --
> that's basics of programming, but for some reason URL
> dispatching is
> seen as something different. Why?

I don't know, but every time I see a strange
data structure with regular expressions in it that
is supposed to define my web application URL structure,
my skin crawls.

I think the simplicity of FILE_PATH==URL is one
of the main reasons for the popularity of PHP --
other than that I can't think of any excuse for PHP.
If python had a framework that had a simple and
straightforward organization 5 to 10 years ago I don't
think either PHP or Ruby/Rails would have ever evolved.

BTW, this was one of the primary reasons I created
WHIFF -- I wanted a structure where I just dropped
files into a directory and they were automatically
treated as applications or middlewares with an
URL derived from the file path with associated services
which could be combined in a natural fashion...
There wasn't anything like that available, so I had
to create it.

-- Aaron Watters

===
http://aaron.oirt.rutgers.edu/myapp/amcharts/doc
http://aaron.oirt.rutgers.edu/myapp/docs/W1500.whyIsWhiffCool
less is more.

[Martijn Faassen]

Hey,

On Tue, Jun 16, 2009 at 6:15 PM, Etienne
Robillard<robillar...@gmail.com> wrote:
> I don't care about '97, pretty much.

Those who do not learn from history are destined to repeat it. :)

> I think that if this Jim guy has lots of experience then at least he
> could not pretend that other people works are made by/for geniuses,
> which is probably untrue anyway. There's other ways to advertise a open source project

I think you misread him. He said it the goal is for it to be simple,
he didn't say other people's works are complicated. Besides; I think
Jim would be the first to admit that some of his other works are
actually a bit harder to understand for other people. Zope 2 and Zope
3, which Jim both designed, are considered by many to be more than a
little bit intimidating.

> One method
> is to discriminate other projects, thus making it's own work appears
> better in some ways or another. Of courses this has nothing to do in
> being a genius.. You don't have to be a genius to copy-and-paste things.

You're reading things that Jim didn't write anywhere as far as I know.
He doesn't compare Bobo with anything else. He just states what the
goal is. What he does say is that he built Bobo on other people's
work, giving it credit.

Regards,

Martijn

[Nathan Yergler]

On Tue, Jun 16, 2009 at 9:15 AM, Etienne
Robillard<robillar...@gmail.com> wrote:
>
> Martin,
>
> I don't care about '97, pretty much.
>
> I think that if this Jim guy has lots of experience then at least he
> could not pretend that other people works are made by/for geniuses,
> which is probably untrue anyway.

How do you know that Jim believes this? I don't see anything in his
initial announcement (or in skimming the documentation) that implies
you should choose Bobo over any other framework.

>
> There's other ways to advertise a open source project. One method
> is to discriminate other projects, thus making it's own work appears
> better in some ways or another. Of courses this has nothing to do in
> being a genius.. You don't have to be a genius to copy-and-paste things.
>

Again, this seems to be a stretch. Jim simply sent a message letting
people know about Bobo. I for one appreciate that, as it's useful for
me to have different tools in my toolkit for approaching different
problems. Bobo may share features (or non-features) with other
frameworks (web.py comes to mind) but that doesn't mean it's "copy and
paste".

This feels like an ad hominem argument which is both surprising and
unproductive.

Nathan

> regards,
>
> Etienne
>
>
> Martijn Faassen wrote:
>> Hey,
>>
>> On Tue, Jun 16, 2009 at 4:51 PM, Etienne
>> Robillard<robillar...@gmail.com> wrote:
>>> Nothing very new here. At least next time try to be a little more
>>> creative, otherwise this is getting slightly boring and repetitive...
>>
>> It's a bit rich to call Jim Fulton uncreative concerning web
>> development. I suggest you delve into the history of Python web
>> development for a bit. Of course back in '97 there was more to invent
>> than there is today.
>>
>> Regards,
>>
>> Martijn
>>
>
>
> --
> Etienne Robillard <robillar...@gmail.com>
> Green Tea Hackers Club <http://gthc.org/>
> Blog: <http://gthc.org/blog/>
> PGP Fingerprint: AED6 B33B B41D 5F4F A92A  2B71 874C FB27 F3A9 BDCC
> _______________________________________________
> Web-SIG mailing list
> Web...@python.org
> Web SIG: http://www.python.org/sigs/web-sig

> Unsubscribe: http://mail.python.org/mailman/options/web-sig/nathan%40yergler.net

[Duncan M. McGreggor]

Jim Fulton wrote:
> Bobo is a light-weight framework for creating WSGI web applications.
>
> It's goal is to be easy to use and remember. You don't have to be a genius.
>
> It addresses 2 problems:
>
> - Mapping URLs to objects
>
> - Calling objects to generate HTTP responses
>
> Bobo doesn't have a templateing language, a database integration layer,
> or a number of other features that can be provided by WSGI
> middle-ware or application-specific libraries.
>
> Bobo builds on other frameworks, most notably WSGI and WebOb.
>
> To learn more. visit: http://bobo.digicool.com
>
> Jim
>
> --
> Jim Fulton
> Zope Corporation

Thanks Jim!

d

[Martijn Faassen]

Hey,

On Tue, Jun 16, 2009 at 6:27 PM, Aaron Watters<arw...@yahoo.com> wrote:
[snip]

> If python had a framework that had a simple and
> straightforward organization 5 to 10 years ago I don't
> think either PHP or Ruby/Rails would have ever evolved.

5 years ago would've been far too late for PHP. Even 10 years ago; PHP
has been around since '95 and I think was fairly popular quite soon.
Even Rails goes back to '04 - not sure when it got really popular.

(anyway, I know you were around back then and before me, I just like history)

In general, I don't think there's anything that could stop people from
creating their own new web frameworks. :) At best we can aim to reuse
bits and pieces and work towards making that easier.

Regards,

Martijn

[Senthil Kumaran]

On Tue, Jun 16, 2009 at 12:15:29PM -0400, Etienne Robillard wrote:
> I think that if this Jim guy has lots of experience then at least he
> could not pretend that other people works are made by/for geniuses,
> which is probably untrue anyway.

Hey, I don't understand why are being so negative with your comments.
Does not sound good. I surely dont know what your contributions are,
but I do know what Jim Fulton's contributions are.

--
Senthil

[Etienne Robillard]

Hey, don't you people know that you could use a more polite word
than "Hey" to salute people ?

I'm just telling my own views. If you disagree then please say something
more meaningful than this. Who cares what you know.

Senthil Kumaran wrote:
> On Tue, Jun 16, 2009 at 12:15:29PM -0400, Etienne Robillard wrote:
>> I think that if this Jim guy has lots of experience then at least he
>> could not pretend that other people works are made by/for geniuses,
>> which is probably untrue anyway.
>
> Hey, I don't understand why are being so negative with your comments.
> Does not sound good. I surely dont know what your contributions are,
> but I do know what Jim Fulton's contributions are.
>
>

--

Etienne Robillard <robillar...@gmail.com>
Green Tea Hackers Club <http://gthc.org/>
Blog: <http://gthc.org/blog/>
PGP Fingerprint: AED6 B33B B41D 5F4F A92A 2B71 874C FB27 F3A9 BDCC

[Etienne Robillard]

I recommend you quit using latin to try looking smarter. ;)

I do I'm discouraged to see so much adversion between Python web
frameworks fighting for the same goal.

To say that "you don't to be a genius" implies that all other web
frameworks are made for geniuses, which is probably offending for
less-mature projects. Of courses I might have misread or taking for
granted that this was a totally new project..

My apologies then to Jim... ;)

Regards,

Etienne

Unsubscribe: http://mail.python.org/mailman/options/web-sig/python-web-sig-garchive-9074%40googlegroups.com

[Senthil Kumaran]

On Tue, Jun 16, 2009 at 12:51:48PM -0400, Etienne Robillard wrote:
> Hey, don't you people know that you could use a more polite word
> than "Hey" to salute people ?
>
> I'm just telling my own views. If you disagree then please say something
> more meaningful than this. Who cares what you know.

Sorry for that. I wrote that immediately after reading your response.

Others have responded more appropriately.

Thank you,
Senthil

[Jason Briggs]

Typical. The first time I make the effort to reply to the list, I reply-to-sender rather than to-list.  I'm a muppet.

Anyway, reply below....

Begin forwarded message:

From: Jason Briggs <jasonr...@gmail.com>

Date: 16 June 2009 20:04:46 BST

To: Etienne Robillard <robillar...@gmail.com>

Subject: Re: [Web-SIG] Announcing bobo

"Ad hominen" isn't using latin to look smart.  It's a common-term description of a type of argument... which just happens to be latin.

You probably already knew that, but based on your previous emails I wasn't sure -- so just for your info.

J

[C. Titus Brown]

Hey all,

I think we can pretty safely ignore Etienne as either a troll or an
unnecessarily rude person.

Has anyone looked at Bobo yet? I'd be interested in comparisons between
it and Quixote, which is what I've mostly used in the past. I believe
that Bobo begat Zope, which begat Quixote as (I thought) an attempt to
return to Bobo-style programming, and so I'm curious about what sort of
choices Bobo has made.

thanks,
--titus
--
C. Titus Brown, c...@msu.edu

[Etienne Robillard]

Pfft, I bet this thread would have never happened without my initial
intervention. Likewise, I think you're just using this thread for your
own interests, disregarding my own arguments on why web frameworks are
so hard to cope with.

If you want to start a thread for Bobo, please switch mailing-list or
create a new thread, as all I wanted was to tell Jim my disappointement
regarding Bobo, and I still think its not very revolutionary.

Regards,

Etienne

C. Titus Brown wrote:
> Hey all,
>
> I think we can pretty safely ignore Etienne as either a troll or an
> unnecessarily rude person.
>
> Has anyone looked at Bobo yet? I'd be interested in comparisons between
> it and Quixote, which is what I've mostly used in the past. I believe
> that Bobo begat Zope, which begat Quixote as (I thought) an attempt to
> return to Bobo-style programming, and so I'm curious about what sort of
> choices Bobo has made.
>
> thanks,
> --titus

--

Etienne Robillard <robillar...@gmail.com>
Green Tea Hackers Club <http://gthc.org/>
Blog: <http://gthc.org/blog/>
PGP Fingerprint: AED6 B33B B41D 5F4F A92A 2B71 874C FB27 F3A9 BDCC

[David Stanek]

On Tue, Jun 16, 2009 at 5:53 PM, Etienne
Robillard<robillar...@gmail.com> wrote:
>
> If you want to start a thread for Bobo, please switch mailing-list or
> create a new thread, as all I wanted was to tell Jim my disappointement
> regarding Bobo, and I still think its not very revolutionary.
>

Depends on what you mean by revolutionary. I am in the framework
hating camp. This back to basics style framework is what I like to
see. Frameworks like Django, TurboGears and Zope just don't allow me
to do what I want.

--
David
blog: http://www.traceback.org
twitter: http://twitter.com/dstanek

[Alan Kennedy]

[Etienne]

> If you want to start a thread for Bobo, please switch mailing-list or
> create a new thread, as all I wanted was to tell Jim my disappointement
> regarding Bobo, and I still think its not very revolutionary.

I completely disagree; this is definitely the appopriate list for
discussing web frameworks and new approaches. There is no perfect
framework in python, or any other language. It is only with the
introduction, discussion, acceptance and assimilation of new ideas
that we all move forward together.

Jim has the longest history of all in Python web frameworks; he
created the very concept. He founded and built the entire Zope
community; I will always listen to what he has to say.

I wish you the best of luck with your own web framework, notmm

http://gthc.org/projects/notmm/0.2.12/

Which seems to have some potential, but currently lacks community support.

http://gthc.org/community/

I'm looking forward to Europython, where I know I'll be meeting some
great python folks, and hopefully some of us will get to continue our
WSGI revision discussions.

All the best,

Alan.

[William Dode]

On 16-06-2009, Etienne Robillard wrote:
>
> Pfft, I bet this thread would have never happened without my initial
> intervention. Likewise, I think you're just using this thread for your
> own interests, disregarding my own arguments on why web frameworks are
> so hard to cope with.
>
> If you want to start a thread for Bobo, please switch mailing-list or
> create a new thread, as all I wanted was to tell Jim my disappointement
> regarding Bobo, and I still think its not very revolutionary.

Imho you just describe your mistake ! You should start an other thread
to discuss about the number of web framework instead of focus specialy
on bobo.

In fact, web framework like bobo is an answer to this problem (the
number of framework). Like you said there is nothing revolutionary, it
use other components (paste and webob), it means that we begin to stop
to reinvent the wheel and search for the concensus on the smaller
efficient framework. And this is really fine !

--
William Dodé - http://flibuste.net
Informaticien Indépendant

[Noah Gift]

+1 Bobo.  I like stuff Jim writes.

--
Cheers,

Noah

[Jim Fulton]

On Jun 16, 2009, at 12:39 PM, Martijn Faassen wrote:
...

> He said it the goal is for it to be simple,
> he didn't say other people's works are complicated.

Yup, however I can see how "You don't have to be a genius" could be
construed as implying that you do have to be a genius to use other
frameworks. It was intended to be a play on the name "bobo", which
can be translated as "idiot" in Spanish. I absolutely don't want to
bad-mouth other frameworks. I've removed this unnecessary sentence
from the PyPI page and from the packages long description in subversion.

Jim

--
Jim Fulton
Zope Corporation

[Chris Withers]

Hey Jim,

Jim Fulton wrote:
> Bobo is a light-weight framework for creating WSGI web applications.

Do you know if there are plans/possibilities to make the routing part of
Bobo available for other frameworks and/or in a non-decorator fashion?

cheers,

Chris

--
Simplistix - Content Management, Zope & Python Consulting
- http://www.simplistix.co.uk

[Jim Fulton]

On Jun 16, 2009, at 11:02 AM, Sergey Schetinin wrote:
...

> indeed there are quite a few
> frameworks / components that do this thing and I kind of don't get why
> people want to write their apps that way. I wonder if Jim or anyone
> else could explain the rationale behind all these URL routing
> libraries. Nobody minds calling functions from other functions --
> that's basics of programming, but for some reason URL dispatching is
> seen as something different. Why?
>
> This is not a criticism, I just really would like to understand this.

Fair enough. I'm not sure I understand your question. You need some
way of mapping URLs onto Python objects that handle them. You can do
this on a case by case basis by inspecting a URL and doing some sort
of ad hoc dispatch in your application. Is that what you mean by
"calling functions from other functions"? I've found it useful to
have a standard mechanism for this that you can use over and over
without reinventing it each time.

In the original bobo (aka "python object publisher") that I wrote in
'96, I mapped URLs onto object names in modules. Later, I extended
this to use object keys and this grew into a traversal model. There
were some difficulties with this approach:

- I needed some way to decide which objects should be URL accessible.
This led to some less than optimal rules.

- The traversal model mapped well onto an object database, but not so
well onto relational models.

Many people have taken the approach of providing an explicit separate
(from code) mechanism of mapping URLs onto their Python objects.
Usually, this involves having a table mapping URL patterns of some
sort onto object identifiers. I like explicit. :)

BTW, Chris McDonough provides a nice comparison of traversal and what
he calls "URL Dispatch" based on a mapping table (Pylons routes) in:

http://docs.repoze.org/bfg/narr/urlmapping.html#differences-between-traversal-and-url-dispatch

One of my goals with bobo is express web applications with Python as
much as practical. While bobo does support the ability to provide an
external mapping, I definitely wanted to be able to express the
mapping in the code. One of the advantages of recreating bobo in the
21st century is that I get to use Python decorators, which provide a
way to be very explicit about which objects are available to handle
URLs. (Other web frameworks use decorators for this purpose too. Bobo
is *not* revolutionary in any way. :)

I find the route syntax used by Rails and Pylons to be very
appealing. It uses fairly simple path patterns with placeholders. It
doesn't use regular expressions. I don't personally care for the
controller+action model used by Rails and borrowed by Pylons, so,
after looking at using Pylon's routes implementation, which I took a
lot of inspiration from, I went with a slightly different model.
Basically, a route maps onto an object and when a URL matches a route,
we call the object. (Of course, there are other details, but they're
covered by the bobo documentation.)

I hope this helps and that I haven't totally misunderstood your
original question.

Jim

--
Jim Fulton
Zope Corporation

[Jim Fulton]

On Jun 17, 2009, at 5:12 AM, Chris Withers wrote:

> Hey Jim,
>
> Jim Fulton wrote:
>> Bobo is a light-weight framework for creating WSGI web applications.
>
> Do you know if there are plans/possibilities to make the routing
> part of Bobo available for other frameworks

I'm working on another project, bozo, to facilitate using bobo
resources in Zope and use Zope components with bobo applications.

> and/or in a non-decorator fashion?

Bobo provides a mechanism to express routes separately from your
Python code. Of course, Pylons also provides a route scheme that
doesn't use decorators. repose.bfg integrates Pylons routes with
other WSGI and Zope frameworks.

Jim

--
Jim Fulton
Zope Corporation

[Aaron Watters]

Re Jim's summary of URL routing
> ...I hope this helps ...

It helped me. Interesting summary. Thanks.
I'm all for making things as simple and explicit
as possible (at least as an optional or default behavior)
and it looks like Bobo is much better
than many other approaches in supporting simple
and explicit URL routing.

Thanks again, Jim.

-- Aaron Watters
http://aaron.oirt.rutgers.edu/myapp/docs/W1500.whyIsWhiffCool#Header6
http://aaron.oirt.rutgers.edu/myapp/amcharts/doc

===
Everything should be as simple as possible.
But not simpler.
-- Einstein

[Bill Janssen]

Jim Fulton <j...@zope.com> wrote:

> I'm working on another project, bozo, to facilitate using bobo
> resources in Zope and use Zope components with bobo applications.

Good names, Jim.

Bill

[Sergey Schetinin]

On 2009-06-17, Jim Fulton <j...@zope.com> wrote:
> On Jun 16, 2009, at 11:02 AM, Sergey Schetinin wrote:
> ...
> > indeed there are quite a few
> > frameworks / components that do this thing and I kind of don't get why
> > people want to write their apps that way. I wonder if Jim or anyone
> > else could explain the rationale behind all these URL routing
> > libraries. Nobody minds calling functions from other functions --
> > that's basics of programming, but for some reason URL dispatching is
> > seen as something different. Why?
> >
> > This is not a criticism, I just really would like to understand this.
> >
>
>
> Fair enough. I'm not sure I understand your question. You need some way
> of mapping URLs onto Python objects that handle them. You can do this on a
> case by case basis by inspecting a URL and doing some sort of ad hoc
> dispatch in your application. Is that what you mean by "calling functions
> from other functions"? I've found it useful to have a standard mechanism
> for this that you can use over and over without reinventing it each time.

I guess didn't state my question properly, sorry. Let me explain what
I meant by "calling functions" analogy. My point is that when we
define a piece of functionality (as a function, class or whatever) we
don't say where to use it. I mean, we may define functions as "take
data from a this argument, process and return" and it's up to the
caller to pass that data into the function, function doesn't say where
that should come from or where in the rest of code should its body be
injected or anything like that. So function is a definition of
functionality and it is being called from somewhere else, the called
should know as little as possible about the caller and its place
relative to other calls its caller makes. At least that seems to be
the advice for good software design.

When considering webapps and what urls they should handle it seems
like the same should apply -- webapps define contained blocks of
functionality and the task of placing them somewhere in URL-space
belongs to the "caller" which in this case would be a configuration or
serving script or, most often, a parent application. Sure, this
requires inspecting the URL, or as you said, "ad-hoc dispatching". I
think that misrepresents this approach because all it boils down to is
a series of if's, maybe a dictionary lookup and possibly regexp
matching is some cases (I personally never had to use that for URL
dispatch though). If we were to look at a similar approach in a
different context, I don't think it would be fair to call a series of
if/elifs "ad-hoc logic", so it's the same thing here.

But let's go back to bobo, I can see how URL paths derived from file
and function names are nice and make sense, but I'm not as thrilled
with declaring the app path in a decorator. When looking at it from
the perspective of "caller defines when and how the subroutine is
called" I see that the entire (and very useful) level of abstraction
is gone -- the application path is defined right where the application
itself is defined. It's almost like declaring a piece of code and
saying "just inject this into file X at line Y" -- not pretty.
However, I have to admit, that if taken as an iterative improvement
over file/function name it looks very reasonable.

> In the original bobo (aka "python object publisher") that I wrote in '96, I
> mapped URLs onto object names in modules. Later, I extended this to use
> object keys and this grew into a traversal model. There were some
> difficulties with this approach:
>
> - I needed some way to decide which objects should be URL accessible. This
> led to some less than optimal rules.
>
> - The traversal model mapped well onto an object database, but not so well
> onto relational models.
>
> Many people have taken the approach of providing an explicit separate (from
> code) mechanism of mapping URLs onto their Python objects. Usually, this
> involves having a table mapping URL patterns of some sort onto object
> identifiers. I like explicit. :)

I like explicit too, and I like decoupled as well :) By giving up the
"manual" dispatching to some libraries people seem to dig themselves a
hole without even realizing it. There's so little code saved by doing
this, that I don't get it -- some of very useful features are given up
and it doesn't look like a tradeoff -- just giving control up without
a reason. ISTM that the reason is that this "manual dispatch" thing
seems more complex than it is in reality.

To some extent, various routing libraries make sense because they
provide some level of extensibility, you know, like generic functions
vs. series of ifs. But given how they are used -- one global routing
object usually -- the need for that extensibility wouldn't be there if
not this initial design.

In my view, this kind of routing also has the same flaw as the one I
see in bobo -- tight coupling. Apps know exactly what arguments they
want to get and those are directly "plugged" into data output of path
pattern used in the URL router.

So basically there's a way to do dispatch with things like URLMap from
Paste and other similarly minimal dispatch mechanisms that just plug
one into another any way you wish and effortlessly and they are pretty
much extensible as it gets -- they can be updated from anywhere in
code. This is a very simple alternative to the routing libraries that
I don't see used much. At the same time the problems with the popular,
routing approach make people write more and more of those hoping to
fix the problems that are actually inherent to the design. IMO anyway.

I guess I'd better give some examples of how I think the URL dispatch
"should be done", but I'm spent for today, sorry :) Maybe later, if
this discussion will continue.

Anyway, that was a long-winded way of asking a question you've already
answered. Thanks.

Also, love the bobo/bozo naming :)

> BTW, Chris McDonough provides a nice comparison of traversal and what he
> calls "URL Dispatch" based on a mapping table (Pylons routes) in:
>
>
> http://docs.repoze.org/bfg/narr/urlmapping.html#differences-between-traversal-and-url-dispatch
>
> One of my goals with bobo is express web applications with Python as much
> as practical. While bobo does support the ability to provide an external
> mapping, I definitely wanted to be able to express the mapping in the code.
> One of the advantages of recreating bobo in the 21st century is that I get
> to use Python decorators, which provide a way to be very explicit about
> which objects are available to handle URLs. (Other web frameworks use
> decorators for this purpose too. Bobo is *not* revolutionary in any way. :)
>
> I find the route syntax used by Rails and Pylons to be very appealing. It
> uses fairly simple path patterns with placeholders. It doesn't use regular
> expressions. I don't personally care for the controller+action model used
> by Rails and borrowed by Pylons, so, after looking at using Pylon's routes
> implementation, which I took a lot of inspiration from, I went with a
> slightly different model. Basically, a route maps onto an object and when a
> URL matches a route, we call the object. (Of course, there are other
> details, but they're covered by the bobo documentation.)
>
> I hope this helps and that I haven't totally misunderstood your original
> question.
>
>
> Jim
>
> --
> Jim Fulton
> Zope Corporation
>
>
>

--
Best Regards,
Sergey Schetinin

http://s3bk.com/ -- S3 Backup
http://word-to-html.com/ -- Word to HTML Converter

[Aaron Watters]

--- On Wed, 6/17/09, Sergey Schetinin <mal...@gmail.com> wrote:

> When considering webapps and what urls they should handle
> it seems
> like the same should apply -- webapps define contained
> blocks of
> functionality and the task of placing them somewhere in
> URL-space
> belongs to the "caller" which in this case would be a
> configuration or
> serving script or, most often, a parent application.

So you seem to be suggesting that a web component
should not be aware of its URL in the same sense
that an object is not aware of
its variable name in the scope of the application
that is using the object. Is that right?

In particular you should be able to assign a
component to any URL in the same sense that you
can give an object any name. You should also
be able to build relocatable URL trees which can
be "mounted" anywhere in the "calling" application
suite. Do I catch your meaning correctly?

It's not clear to
me whether Bobo allows or disallows this
(I think whiff, and standard cgi, for two examples,
support this sort of url handling).

-- Aaron Watters
http://aaron.oirt.rutgers.edu/myapp/docs/W1500.whyIsWhiffCool
===
Emacs Makes A Computer Slow

[Sergey Schetinin]

On 2009-06-18, Aaron Watters <arw...@yahoo.com> wrote:
>
>
>
> --- On Wed, 6/17/09, Sergey Schetinin <mal...@gmail.com> wrote:
>
> > When considering webapps and what urls they should handle
> > it seems
> > like the same should apply -- webapps define contained
> > blocks of
> > functionality and the task of placing them somewhere in
> > URL-space
> > belongs to the "caller" which in this case would be a
> > configuration or
> > serving script or, most often, a parent application.
>
>
> So you seem to be suggesting that a web component
> should not be aware of its URL in the same sense
> that an object is not aware of
> its variable name in the scope of the application
> that is using the object. Is that right?
>
> In particular you should be able to assign a
> component to any URL in the same sense that you
> can give an object any name. You should also
> be able to build relocatable URL trees which can
> be "mounted" anywhere in the "calling" application
> suite. Do I catch your meaning correctly?

Spot on.

> It's not clear to
> me whether Bobo allows or disallows this
> (I think whiff, and standard cgi, for two examples,
> support this sort of url handling).

Generally, I think "allowing" it is not enough, I'd prefer it to be
*expected*, not just supported. Certainly if one wants to write their
own apps this way there are plenty ways to do that, I'm just a bit sad
that the default solution in Python webdev seems to be "bring in
inflexible stuff you don't need" (not a stab at anything in
particular, just something that seems to be the consensus ATM). I
think one of the reasons for that is that you can't have a big website
and screencasts to woo the newcomers and "good docs" and whatnot about
writing a series of ifs, can you? Unlike the frameworkey stuff.

I'd go to the Series-Of-Ifs-CON if there was one, though :)

--
Best Regards,
Sergey Schetinin

http://s3bk.com/ -- S3 Backup
http://word-to-html.com/ -- Word to HTML Converter

[Martijn Faassen]

Hey,

On Thu, Jun 18, 2009 at 3:55 AM, Sergey Schetinin<mal...@gmail.com> wrote:
[snip]

>>  In particular you should be able to assign a
>>  component to any URL in the same sense that you
>>  can give an object any name.  You should also
>>  be able to build relocatable URL trees which can
>>  be "mounted" anywhere in the "calling" application
>>  suite.  Do I catch your meaning correctly?
>
> Spot on.

This is what object traversal (as in Zope) tends to allow. While each
individual URL tree (i.e. object structure) might have various
expectations concerning relative URLs, they can be combined together
by putting the right types of objects together. This allows the
composition of larger web apps out of smaller components without there
having to be a global map of how URLs map at all.

Regards,

Martijn

[Jim Fulton]

(Note that this discussion is getting rather dense. I suggest reading
my reply all the way through befor responding to individual points. :)

But software still lives in a namespace. You usually assign a
function a name in a module or package. It often depends on other
functionality being available under specific names. In web
applications, we often need to know where other components are in the
URL space. OTOH, often a function doesn't depend on it's name and
you feel that a web application shouldn't care about it's URL. I get
that. :)

> When considering webapps and what urls they should handle it seems
> like the same should apply -- webapps define contained blocks of
> functionality and the task of placing them somewhere in URL-space
> belongs to the "caller" which in this case would be a configuration or
> serving script or, most often, a parent application.

OK, so you expect there to be a URL mapping, typically accomplished
via some configuration mechanism outside the code. Most routing
systems either require or allow this.

> Sure, this
> requires inspecting the URL, or as you said, "ad-hoc dispatching". I
> think that misrepresents this approach because all it boils down to is
> a series of if's, maybe a dictionary lookup and possibly regexp
> matching is some cases (I personally never had to use that for URL
> dispatch though). If we were to look at a similar approach in a
> different context, I don't think it would be fair to call a series of
> if/elifs "ad-hoc logic", so it's the same thing here.

I wasn't trying to represent what you said. I was just guessing at
what you said. So you don't mind routing systems that are configured
through routing tables outside the code. (?)

> But let's go back to bobo, I can see how URL paths derived from file
> and function names are nice and make sense, but I'm not as thrilled
> with declaring the app path in a decorator. When looking at it from
> the perspective of "caller defines when and how the subroutine is
> called" I see that the entire (and very useful) level of abstraction
> is gone -- the application path is defined right where the application
> itself is defined. It's almost like declaring a piece of code and
> saying "just inject this into file X at line Y" -- not pretty.

Again, I get that you want to separate URL from the code, but I don't
agree with your analogy. This may not matter.

Something to note is that the paths used in bobo are often not
absolute. If you use subroutes, http://bobo.digicool.com/index.html#subroutes
, then the paths used will be relative to a position in a URL tree.
In the referenced section, the paths in the Document and Folder
resources are relative to the URLs used to access a document or folder.

An innovation in bobo, I think, is that it combines routes and
traversal ("URL Dispatch" and traversal in http://docs.repoze.org/bfg/narr/urlmapping.html#differences-between-traversal-and-url-dispatch)

> However, I have to admit, that if taken as an iterative improvement
> over file/function name it looks very reasonable.

I'm not sure what you're referring to here.

Nothing is given up. You can still configure paths externally if you
want. (I'll have more to say on this below.)

> To some extent, various routing libraries make sense because they
> provide some level of extensibility, you know, like generic functions
> vs. series of ifs. But given how they are used -- one global routing
> object usually -- the need for that extensibility wouldn't be there if
> not this initial design.

I don't understand what extensibility you're referring to here or if
this has anything to do with your objection to specifying paths in the
code.

Note that bobo doesn't require a global routing object. Bobo provides
various ways of knitting URL trees together by having resources invoke
other resources, as is done in the document-tree example referenced
above.

> In my view, this kind of routing also has the same flaw as the one I
> see in bobo -- tight coupling. Apps know exactly what arguments they
> want to get

I'm confused. Generally, Python functions know what arguments they
want to get. What does this have to do with routing?

> and those are directly "plugged" into data output of path
> pattern used in the URL router.

Sorry, I can't parse this. :)

> So basically there's a way to do dispatch with things like URLMap from
> Paste and other similarly minimal dispatch mechanisms that just plug
> one into another any way you wish and effortlessly and they are pretty
> much extensible as it gets -- they can be updated from anywhere in
> code.

Can you explain how you see this as different from:
http://bobo.digicool.com/more.html#configured-routes
?

> This is a very simple alternative to the routing libraries that
> I don't see used much. At the same time the problems with the popular,
> routing approach make people write more and more of those hoping to
> fix the problems that are actually inherent to the design. IMO anyway.

I still don't understand what you perceive these inherent problems to
be.

On Jun 17, 2009, at 9:55 PM, Sergey Schetinin wrote:

> On 2009-06-18, Aaron Watters <arw...@yahoo.com> wrote:
>>
>>
>>
>> --- On Wed, 6/17/09, Sergey Schetinin <mal...@gmail.com> wrote:
>>

>>> When considering webapps and what urls they should handle
>>> it seems
>>> like the same should apply -- webapps define contained
>>> blocks of
>>> functionality and the task of placing them somewhere in
>>> URL-space
>>> belongs to the "caller" which in this case would be a
>>> configuration or
>>> serving script or, most often, a parent application.
>>
>>

>> So you seem to be suggesting that a web component
>> should not be aware of its URL in the same sense
>> that an object is not aware of
>> its variable name in the scope of the application
>> that is using the object. Is that right?
>>

>> In particular you should be able to assign a
>> component to any URL in the same sense that you
>> can give an object any name. You should also
>> be able to build relocatable URL trees which can
>> be "mounted" anywhere in the "calling" application
>> suite. Do I catch your meaning correctly?
>
> Spot on.
>

>> It's not clear to
>> me whether Bobo allows or disallows this

It does.

http://bobo.digicool.com/more.html#configured-routes

> Generally, I think "allowing" it is not enough, I'd prefer it to be
> *expected*, not just supported.

To some degree, this is the approach that Zope 3 took, It (strongly)
encourages you to separate application implementation from
configuration. This was motivated by a well-intentioned desire for
the kind of flexibility I think you're advocating. The result was
elegant but hard to deal with. I think it's great to have this
flexibility when you need it, but in my experience, 99% of web
applications don't need this sort of flexibility and the methods
needed to support the flexibility become a tax.

My design for bobo is based on the assumption that most people don't
need a lot of flexibility while some do, where the former is the
common case. It tries to make simple applications very easy to
create, without making it hard to address more complex requirements.
I feel good about bobo's ability to deal with simple applications.
Time will tell if it accommodates more complex applications. :)

This discussion falls into the larger debate of configuration vs
convention and explicit vs implicit. I tend to prefer explicit, but
am wary of systems that require a lot of configuration (having built
one :). Most systems try to strike some balance, as does bobo.

Jim

--
Jim Fulton
Zope Corporation

[Etienne Robillard]

Hi,

It is suggested that most web frameworks authors aims at a very (wide?)
audience and bet that most peoples are bozos, clowns, or idiots. I think
this rationale might work in some cases, because users of thoses
frameworks indeed might not have all those hard-core technical
knowledges about, say, URL routing, WSGI or even schema migration.

However, is that the preferred way to design web frameworks or should we
assume that the "user" is foremost an intelligent and respectful
"developer" ?

My hypothesis is that web frameworks can sometimes negatively influence
a programmer efficiency to resolve a simple programming problem. I think
this is particulary true when web frameworks are made restrictive: the
available solutions are largely influenced by/for popular or
community-accepted scenarios, thus shadowing or putting in the dark
unconventional solutions.

In a sense, this is perhaps an ethical problem for web framework authors
and not very related to web programming in general..

Lastly, I don't know really if most people have "complex requirements".
In my experience however "basic requirements" are still largely not
understood by popular "full-stack" web frameworks.

Best regards,

Etienne

Jim Fulton wrote:

> http://mail.python.org/mailman/options/web-sig/robillard.etienne%40gmail.com
>
>

--
Etienne Robillard <robillar...@gmail.com>
Green Tea Hackers Club <http://gthc.org/>
Blog: <http://gthc.org/blog/>
PGP Fingerprint: AED6 B33B B41D 5F4F A92A 2B71 874C FB27 F3A9 BDCC

[Sergey Schetinin]

Well, the app needs to know where its children are located and it
controls that. If the app needs to know its siblings' paths I think
that should be parametrized. That way, the parent can set up its
components that they know where to find each other but there's still
flexibility to it. Conventional paths work too, but there's plenty of
code reuse lost as a result.

Imagine a web forum app. The top level app is the topic list, there
are "discussion thread" apps that it exposes at some paths, those apps
would want to know the URL of the topic list so that they can link to
it. They may assume that it's one level up or they might actually have
a way to define where they are. In the latter case when the forum app
created its children, it would have let the children know that it is
their parent.

Now consider someone writing a blog app for example, there are apps
that represent specific blog entries and it would be nice to be able
to reuse the "forum thread" component and expose it at a subpath, for
example as /blog/entry-name/discussion. If we were not just using
conventional paths in the implementation of that thread app we could
just tell it that it should refer to its parent as a "blog entry X" or
something. The point is that decoupling is a good enough thing to be
worth at least few extra lines of code. If the forum app was using
some routing library, things would be much more complicated -- it's no
longer a matter of a few lines of code but a major PITA.

>
> > When considering webapps and what urls they should handle it seems
> > like the same should apply -- webapps define contained blocks of
> > functionality and the task of placing them somewhere in URL-space
> > belongs to the "caller" which in this case would be a configuration or
> > serving script or, most often, a parent application.
> >
>
> OK, so you expect there to be a URL mapping, typically accomplished via
> some configuration mechanism outside the code. Most routing systems either
> require or allow this.
>
>
> > Sure, this
> > requires inspecting the URL, or as you said, "ad-hoc dispatching". I
> > think that misrepresents this approach because all it boils down to is
> > a series of if's, maybe a dictionary lookup and possibly regexp
> > matching is some cases (I personally never had to use that for URL
> > dispatch though). If we were to look at a similar approach in a
> > different context, I don't think it would be fair to call a series of
> > if/elifs "ad-hoc logic", so it's the same thing here.
> >
>
> I wasn't trying to represent what you said. I was just guessing at what you
> said. So you don't mind routing systems that are configured through routing
> tables outside the code. (?)

As long as all the routing system does is match a prefix, no parameter
extraction, no regexp nonsense -- it's ok. However that makes it so
small nobody would bother calling it anything, certainly not "routing
system". Regarding configuration of these things -- I don't see any
need to bring in anything but straight Python for this, but that's
irrelevant.

> > But let's go back to bobo, I can see how URL paths derived from file
> > and function names are nice and make sense, but I'm not as thrilled
> > with declaring the app path in a decorator. When looking at it from
> > the perspective of "caller defines when and how the subroutine is
> > called" I see that the entire (and very useful) level of abstraction
> > is gone -- the application path is defined right where the application
> > itself is defined. It's almost like declaring a piece of code and
> > saying "just inject this into file X at line Y" -- not pretty.
> >
>
> Again, I get that you want to separate URL from the code, but I don't agree
> with your analogy. This may not matter.
>
> Something to note is that the paths used in bobo are often not absolute.
> If you use subroutes,

> http://bobo.digicool.com/index.html#subroutes, then the

> paths used will be relative to a position in a URL tree. In the referenced
> section, the paths in the Document and Folder resources are relative to the
> URLs used to access a document or folder.
>
> An innovation in bobo, I think, is that it combines routes and traversal
> ("URL Dispatch" and traversal in
> http://docs.repoze.org/bfg/narr/urlmapping.html#differences-between-traversal-and-url-dispatch)
>
>
>
> > However, I have to admit, that if taken as an iterative improvement
> > over file/function name it looks very reasonable.
> >
>
> I'm not sure what you're referring to here.
>

I meant that bobo decorators seem a natural development to a system
that would assign URLs based on file and function names.

The bobo apps consume data output of bobo url parser, which is a
restriction that has nothing to do with the webapp functionality
itself. It might make sense to use some data from a parent webapp, but
it would need to be passed in a roundabout way. That's tight coupling
I was referring to.

Take the "forum topic" as blog entry discussion -- it's non-trivial if
the topic id in the database is taken from the URL path. There are all
kinds of reuse possibilities lost just by collapsing this level of
abstraction (path -> app mapping). Even if there are ways to
reconfigure the default mapping -- one ends up working against all the
routing stuff original developers of the component put in, unwinding
the tangle of tightly coupled implementation. Which is usually not
worth it.

> > So basically there's a way to do dispatch with things like URLMap from
> > Paste and other similarly minimal dispatch mechanisms that just plug
> > one into another any way you wish and effortlessly and they are pretty
> > much extensible as it gets -- they can be updated from anywhere in
> > code.
> >
>
> Can you explain how you see this as different from:
> http://bobo.digicool.com/more.html#configured-routes
> ?

It's bobo-specific.

How would one use those apps from non-bobo app? How would one put
non-bobo app into those mappings? I suppose there are ways to unwrap
and rewrap things, but wouldn't it be nice if we could finally just do
things like

from somebody_else.forum import ForumApp
urlmap['/forum'] = ForumApp(db_config=...)

The point is that we can, thanks to WSGI, only if people were writing
their stuff the boring way and not build walled gardens that make one
thing easy and a thousand others impossible.

This sounds accusatory, but please don't take it that way. I'm just
voicing my opinion on the problem in python webdev that annoys many
people I believe. Unless you share that feeling there's no need to
take it into account.

I suppose the reason is that this separating the configuration was
implemented as yet more stuff. My idea of configurable webapps is to
pass configuration at instantiation. No extra code. IMO, the more
complex configuration systems are needed when there's a need to
penetrate though levels of framework crust (hello tight coupling)
which is another thing I argue shouldn't be there.

> My design for bobo is based on the assumption that most people don't need a
> lot of flexibility while some do, where the former is the common case. It
> tries to make simple applications very easy to create, without making it
> hard to address more complex requirements. I feel good about bobo's ability
> to deal with simple applications. Time will tell if it accommodates more
> complex applications. :)

As I said, your reply did explain how you see bobo and its purpose,
and it makes complete sense. None of what I said is specifically about
bobo, just general trends in python webdev.

> This discussion falls into the larger debate of configuration vs convention
> and explicit vs implicit. I tend to prefer explicit, but am wary of systems
> that require a lot of configuration (having built one :). Most systems try
> to strike some balance, as does bobo.
>
>
> Jim
>
> --
> Jim Fulton
> Zope Corporation
>
>
>

--
Best Regards,
Sergey Schetinin

http://s3bk.com/ -- S3 Backup
http://word-to-html.com/ -- Word to HTML Converter

[P.J. Eby]

At 02:46 AM 6/19/2009 +0300, Sergey Schetinin wrote:
>but wouldn't it be nice if we could finally just do
>things like
>
>from somebody_else.forum import ForumApp
>urlmap['/forum'] = ForumApp(db_config=...)

The Folder example in the bobo docs does basically that, actually.

I think perhaps you've misunderstood what Bobo does; it not only
provides a framework for fixed mappings, it also provides the basis
for doing flexible mappings. In fact, that's what subroute parameters are for.

So you could implement your urlmap above more or less like this:

@bobo.scan_class
class UrlMap(dict):

@bobo.subroute('/:name')
def subitem(self, name):
try:
return self[name]
except KeyError:
...

Although you'd probably need a __setitem__ that split on '/' and
created sub-UrlMap instances if they don't already exist, but you get
the idea I hope.

Bobo's basic design, IOW, allows you to make pretty much any other
design you like, but is very simple for relatively straightforward subtrees.

Also, AFAICT, *all* bobo paths are relative paths treating the
enclosing module or instance as a mount point, and there is nothing
stopping you from mounting such objects at whatever locations you like.

What bobo lacks (that would be nice) is a way to figure out what URL
to address a specified object by, since the very flexibility that
allows objects to have more than one name, also means that there is
no obvious way to find what name to use for an object.

[Sergey Schetinin]

On 2009-06-19, P.J. Eby <p...@telecommunity.com> wrote:
> At 02:46 AM 6/19/2009 +0300, Sergey Schetinin wrote:
>
> > but wouldn't it be nice if we could finally just do
> > things like
> >
> > from somebody_else.forum import ForumApp
> > urlmap['/forum'] = ForumApp(db_config=...)
> >
>
> The Folder example in the bobo docs does basically that, actually.
>
> I think perhaps you've misunderstood what Bobo does; it not only provides a
> framework for fixed mappings, it also provides the basis for doing flexible
> mappings. In fact, that's what subroute parameters are for.
>
> So you could implement your urlmap above more or less like this:
>
> @bobo.scan_class
> class UrlMap(dict):
>
> @bobo.subroute('/:name')
> def subitem(self, name):
> try:
> return self[name]
> except KeyError:
> ...

Oh wait, I meant urlmap to be

from paste.urlmap import URLMap
urlmap = URLMap()
...

Should have written that in the first place, sorry.

> Although you'd probably need a __setitem__ that split on '/' and created
> sub-UrlMap instances if they don't already exist, but you get the idea I
> hope.
>
> Bobo's basic design, IOW, allows you to make pretty much any other design
> you like, but is very simple for relatively straightforward subtrees.
>
> Also, AFAICT, *all* bobo paths are relative paths treating the enclosing
> module or instance as a mount point, and there is nothing stopping you from
> mounting such objects at whatever locations you like.

I think they are, but that's not separate enough from implementation
for me :) The problem is that if one were to actually separate this
mapping completely there's suddenly nothing to the library anymore :)
(I'm exaggerating, but it's not that far from truth).

> What bobo lacks (that would be nice) is a way to figure out what URL to
> address a specified object by, since the very flexibility that allows
> objects to have more than one name, also means that there is no obvious way
> to find what name to use for an object.
>
>

--
Best Regards,
Sergey Schetinin

http://s3bk.com/ -- S3 Backup
http://word-to-html.com/ -- Word to HTML Converter

[Sergey Schetinin]

On 2009-06-19, P.J. Eby <p...@telecommunity.com> wrote:

> So you could implement your urlmap above more or less like this:
>
> @bobo.scan_class
> class UrlMap(dict):
>
> @bobo.subroute('/:name')
> def subitem(self, name):
> try:
> return self[name]
> except KeyError:
> ...
>
> Although you'd probably need a __setitem__ that split on '/' and created
> sub-UrlMap instances if they don't already exist, but you get the idea I
> hope.

Also, I actually have my version of URLMap (with dispatching on host
and protocol removed and with indexing instead of prefix scan):
http://code.google.com/p/pasteob/source/browse/trunk/pasteob/__init__.py#170

PathMap.__getitem__ method can be ignored as it's used for inspection
only, not when actually dispatching.

[Jim Fulton]

On Jun 18, 2009, at 8:30 AM, Etienne Robillard wrote:
> It is suggested that most web frameworks authors aims at a very
> (wide?)
> audience and bet that most peoples are bozos, clowns, or idiots. I
> think
> this rationale might work in some cases, because users of thoses
> frameworks indeed might not have all those hard-core technical
> knowledges about, say, URL routing, WSGI or even schema migration.

I won't speak for other frameworks, but bobo's target audience is
"idiots" in the same sense that the popular "idiot's guides" and
"dummies" books are aimed at idiots and dummies. Of course, these
books and bobo aren't *really* aimed at idiots or dummies (or bozos or
clowns -- well maybe clowns). They're aimed at people who don't really
want hard-core knowledge. They want to learn something quickly so that
they can get things done. In my experience, many people writing web
applications want to focus on their applications. They aren't really
interested in nitty-gritty plumbing details, they just want to get
their application working well. For many people, web development
isn't their full time job. It's one of many things they do and they
don't want to have a lot to remember or re-learn. Many full-time web
developers have more interesting things to focus on that publishing
mechanics. I know I do.

Jim

--
Jim Fulton
Zope Corporation

_______________________________________________
Web-SIG mailing list
Web...@python.org
Web SIG: http://www.python.org/sigs/web-sig

Unsubscribe: http://mail.python.org/mailman/options/web-sig/python-web-sig-garchive-9074%40googlegroups.com

[Chris Withers]

Jim Fulton wrote:
>
> I'm working on another project, bozo, to facilitate using bobo resources
> in Zope and use Zope components with bobo applications.

Cool, hopefully bozo can be used for non-Zope applications too :-)

>> and/or in a non-decorator fashion?
>
> Bobo provides a mechanism to express routes separately from your Python
> code.

Oh, I missed this... where is this documented?

> Of course, Pylons also provides a route scheme that doesn't use
> decorators.

yeah, but I have an inkling that I'll prefer bobo's routing ;-)
(particularly if I can put the routes in a persistent storage mechanism
rather than having to have them in code or config files)

Chris

--
Simplistix - Content Management, Zope & Python Consulting
- http://www.simplistix.co.uk

[Jim Fulton]

On Jun 19, 2009, at 11:27 AM, Chris Withers wrote:

> Jim Fulton wrote:
>> I'm working on another project, bozo, to facilitate using bobo
>> resources in Zope and use Zope components with bobo applications.
>
> Cool, hopefully bozo can be used for non-Zope applications too :-)

bozo.component will be. It will provide a type-based resource-
dispatch mechanism for bobo applications using zope.component. Of
course, zope.component can be used for non-Zope-based applications.

bozo.reuse is specifically geared to zope/bobo interoperability.
Discussion on that should happen over on the zope-dev list.

>>> and/or in a non-decorator fashion?
>> Bobo provides a mechanism to express routes separately from your
>> Python code.
>
> Oh, I missed this... where is this documented?

http://bobo.digicool.com/more.html#configured-routes

Jim

--
Jim Fulton
Zope Corporation

[Graham Dumpleton]

2009/6/20 Jim Fulton <j...@zope.com>:

>
> On Jun 18, 2009, at 8:30 AM, Etienne Robillard wrote:
>>
>> It is suggested that most web frameworks authors aims at a very (wide?)
>> audience and bet that most peoples are bozos, clowns, or idiots. I think
>> this rationale might work in some cases, because users of thoses
>> frameworks indeed might not have all those hard-core technical
>> knowledges about, say, URL routing, WSGI or even schema migration.
>
>
> I won't speak for other frameworks, but bobo's target audience is "idiots"
> in the same sense that the popular "idiot's guides" and "dummies" books are
> aimed at idiots and dummies.  Of course, these books and bobo aren't
> *really* aimed at idiots or dummies (or bozos or clowns -- well maybe
> clowns). They're aimed at people who don't really want hard-core knowledge.
> They want to learn something quickly so that they can get things done.  In
> my experience, many people writing web applications want to focus on their
> applications.  They aren't really interested in nitty-gritty plumbing
> details, they just want to get their application working well.  For many
> people, web development isn't their full time job.  It's one of many things
> they do and they don't want to have a lot to remember or re-learn. Many
> full-time web developers have more interesting things to focus on that
> publishing mechanics. I know I do.

Personally I believe 'bobo' would be a good alternative for the people
who currently get drawn to the simplicity of 'publisher' in
mod_python, especially if things are setup within Apache such that all
they need to do is drop the bobo script file into their existing
Apache document directories like they can now with 'publisher'. This
way all the high level URL dispatch to specific bobo scripts is done
for them and they don't have to care about it. With the provision of
the request object, they can just get on with coding their
application, adding any custom URL dispatching within the script file
as needs be. Work in a way of automatically handling application
process reloading when they make changes, and you start to approach
the ease of doing things that PHP developers are so used to, and for
which they cannot work out why Python is so hard in comparison.

Graham

[C. Titus Brown]

Hey all,

I think we can pretty safely ignore Etienne as either a troll or a

rather rude person.

Has anyone looked at Bobo yet? I'd be interested in comparisons between
it and Quixote, which is what I've mostly used in the past. I believe
that Bobo begat Zope, which begat Quixote as (I thought) an attempt to
return to Bobo-style programming, and so I'm curious about what sort of
choices Bobo has made.

thanks,
--titus
--
C. Titus Brown, c...@msu.edu

[Jason Briggs]

Typical. The first time I make the effort to reply to the list, I reply to sender rather than to list.  I'm a muppet.

Anyway, reply below....

Begin forwarded message:

From: Jason Briggs <jasonr...@gmail.com>

Date: 16 June 2009 20:04:46 BST

To: Etienne Robillard <robillar...@gmail.com>

Subject: Re: [Web-SIG] Announcing bobo

"Ad hominen" isn't using latin to look smart.  It's a common-term description of a type of argument... which just happens to be latin.

You probably already knew that, but based on your previous emails I wasn't sure -- so just for your info.

J

On 16 Jun 2009, at 18:38, Etienne Robillard wrote:

I recommend you quit using latin to try looking smarter. ;)

I do I'm discouraged to see so much adversion between Python web
frameworks fighting for the same goal.

To say that "you don't to be a genius" implies that all other web
frameworks are made for geniuses, which is probably offending for
less-mature projects. Of courses I might have misread or taking for
granted that this was a totally new project..

My apologies then to Jim... ;)

Regards,

Etienne

This feels like an ad hominem argument which is both surprising and

unproductive.

Nathan

[Brian Sutherland]

On Thu, Jun 18, 2009 at 01:42:32AM +0300, Sergey Schetinin wrote:
> But let's go back to bobo, I can see how URL paths derived from file
> and function names are nice and make sense, but I'm not as thrilled
> with declaring the app path in a decorator. When looking at it from
> the perspective of "caller defines when and how the subroutine is
> called" I see that the entire (and very useful) level of abstraction
> is gone -- the application path is defined right where the application
> itself is defined. It's almost like declaring a piece of code and
> saying "just inject this into file X at line Y" -- not pretty.
> However, I have to admit, that if taken as an iterative improvement
> over file/function name it looks very reasonable.

Seems like this style of declaring routes may be more like what you
want:

http://bobo.digicool.com/more.html#configured-routes

--
Brian Sutherland

[Aaron Watters]

[whoops: graham, I meant to 'reply all', sorry for repeat]

--- On Sat, 6/20/09, Graham Dumpleton <graham.d...@gmail.com> wrote

> Personally I believe 'bobo' would be a good alternative for
> the people
> who currently get drawn to the simplicity of 'publisher'

It's not clear to me whether bobo has
the "just drop a file or directory in
the parent directory and it works"
property like PHP, modpy/publisher, vanilla CGI,
and WHIFF do.

Does it, Jim?

I implemented WHIFF primarily
because I wanted this property (and some others).

WHIFF generalizes the "droppable file or directory" concept
to allow an "application" to implement a fragment of a page
or a middleware easily as well.

Please see

http://aaron.oirt.rutgers.edu/myapp/docs/W1100_1050.Grading
http://aaron.oirt.rutgers.edu/myapp/docs/W1100_1200.wwiki

for examples of how this works in WHIFF.

-- Aaron Watters

===
% man woman
Segmentation fault.

[Graham Dumpleton]

2009/6/22 Aaron Watters <arw...@yahoo.com>:

>
> [whoops: graham, I meant to 'reply all', sorry for repeat]
>
> --- On Sat, 6/20/09, Graham Dumpleton <graham.d...@gmail.com> wrote
>> Personally I believe 'bobo' would be a good alternative for
>> the people
>> who currently get drawn to the simplicity of 'publisher'
>
> It's not clear to me whether bobo has
> the "just drop a file or directory in
> the parent directory and it works"
> property like PHP, modpy/publisher, vanilla CGI,
> and WHIFF do.
>
> Does it, Jim?

I already emailed Jim separately some days back to show exactly how
this can be done using Apache/mod_wsgi 3.0. I was going to blog about
how it is done, but been tied up on getting some other stuff out of
the way.

In other words, bobo doesn't need to support that sort of mechanism
directly as Apache/mod_wsgi makes it a reasonably trivial thing to do.

Graham

> I implemented WHIFF primarily
> because I wanted this property (and some others).
>
> WHIFF generalizes the "droppable file or directory" concept
> to allow an "application" to implement a fragment of a page
> or a middleware easily as well.
>
> Please see
>
> http://aaron.oirt.rutgers.edu/myapp/docs/W1100_1050.Grading
> http://aaron.oirt.rutgers.edu/myapp/docs/W1100_1200.wwiki
>
> for examples of how this works in WHIFF.

[Aaron Watters]

--- On Sun, 6/21/09, Graham Dumpleton <graham.d...@gmail.com> wrote:

> In other words, bobo doesn't need to support that sort of
> mechanism
> directly as Apache/mod_wsgi makes it a reasonably trivial
> thing to do.

Nice!

Ideally the same mechanism should work for other WSGI
implementations, and the same mechanism should also work
for "dropping" (fragments of) applications into another
bobo application.

For example you can "drop in" middleware
support for amCharts
flash charts into any whiff application by adding
an import statement to an __init__.py file, as described
here

http://aaron.oirt.rutgers.edu/myapp/amcharts/doc

-- Aaron Watters

===
% if i had a ( for every $ bush spent, how many ('s would i have?
too many ('s.

[Jim Fulton]

On Jun 21, 2009, at 7:06 PM, Aaron Watters wrote:

>
> [whoops: graham, I meant to 'reply all', sorry for repeat]
>
> --- On Sat, 6/20/09, Graham Dumpleton <graham.d...@gmail.com>
> wrote
>> Personally I believe 'bobo' would be a good alternative for
>> the people
>> who currently get drawn to the simplicity of 'publisher'
>
> It's not clear to me whether bobo has
> the "just drop a file or directory in
> the parent directory and it works"
> property like PHP, modpy/publisher, vanilla CGI,
> and WHIFF do.
>
> Does it, Jim?

No more than any other WSGI application does, except that it is pretty
light weight, so it is practical to run it using CGI. As Graham
pointed out, he's created a cool extension to mod_wsgi that makes it
easy to "drop in" bobo source files. I designed bobo so that source
files can be pretty self contained (e.g. not requiring external
configuration) which probably helps make this story work well.

Jim

--
Jim Fulton
Zope Corporation

[Etienne Robillard]

Hey Jim,

Thanks for that. I'm sorry that I've been rude
with you and realize my mistake. I didn't know you were engaged with
Zope from a long time. Yet I'm still mostly a Python rookie after all...

The problem of wording in Python web frameworks is not quite related
to bobo or anything else, I think... It's just that I'm often
tired of seeing so much competition in similar Python projects, when the
goal (I suppose) should be to share along, and learn stuff...

I'll dig further down on Bobo. Thanks for announcing this.

Please accept my apologies,

Sincerely,

- Etienne

Jim Fulton wrote:
>
> On Jun 16, 2009, at 12:39 PM, Martijn Faassen wrote:
> ...
>> He said it the goal is for it to be simple,
>> he didn't say other people's works are complicated.
>
> Yup, however I can see how "You don't have to be a genius" could be
> construed as implying that you do have to be a genius to use other
> frameworks. It was intended to be a play on the name "bobo", which can
> be translated as "idiot" in Spanish. I absolutely don't want to
> bad-mouth other frameworks. I've removed this unnecessary sentence
> from the PyPI page and from the packages long description in subversion.

>
> Jim
>
> --
> Jim Fulton
> Zope Corporation
>
>
>

--
Etienne Robillard <robillar...@gmail.com>
Green Tea Hackers Club <http://gthc.org/>
Blog: <http://gthc.org/blog/>

PGP Fingerprint: 178A BF04 23F0 2BF5 535D 4A57 FD53 FD31 98DC 4E57

[Jim Fulton]

On Wed, Oct 28, 2009 at 9:12 AM, Etienne Robillard
<robillar...@gmail.com> wrote:
>
> Hey Jim,
>
> Thanks for that. I'm sorry that I've been rude
> with you and realize my mistake. I didn't know you were engaged with
> Zope from a long time. Yet I'm still mostly a Python rookie after all...

I suggest not being rude no matter who you're talking to. :)

> The problem of wording in Python web frameworks is not quite related
> to bobo or anything else, I think... It's just that I'm often
> tired of seeing so much competition in similar Python projects, when the
> goal (I suppose) should be to share along, and learn stuff...
>
> I'll dig further down on Bobo. Thanks for announcing this.
>
> Please accept my apologies,

Sure. Thanks.

Jim

--
Jim Fulton

[Malthe Borch]

On 6/17/09 11:12 AM, Chris Withers wrote:
> Do you know if there are plans/possibilities to make the routing part of
> Bobo available for other frameworks and/or in a non-decorator fashion?

FWIW, a bobo/bfg-compatible router is provided with Otto [1]. It borrows
some code from bobo, but is slightly more versatile. Same (good)
performance.

- [1] http://www.ottohttp.org/docs/1.2/