headers
Ian Bicking | 28 Jul 2003 04:30
Gravatar

To review our status...

We've had a bunch of new subscribers in the last week, but no real
discussion.  I blame this on summer (at least that's my excuse :)

Anyway, I thought I'd remind people what we'd talked about.  Three
things I can think of:

* Create an example application using each of the frameworks, to allow
readers to compare code and style, and probably also as something to
fiddle with when doing an evaluation.  The two (similar) ideas that
seemed to have some support were a discussion board and a sort of mini
blog.  Both are actually fairly similar, when you think about it. 
Andrew suggested we have a common module which does stuff like
persistence, so the applications can be easier... and maybe he
volunteered to write this as well, I wasn't sure.  This would be
possible first step towards making a more presentable website about
Python web programming.

* Work at more cross-framework libraries, like for form processing,
permission systems, etc.  What this actually means is fairly vague
(though perhaps if someone has a specific project in mind...)

* Defining a common foundation upon which to build higher-level
frameworks.  This would mean defining a common request/response
interface (using adapters to match the already-existing request/response
interfaces).  Combined with an interface for the entry point, this would
allow more heterogeneous environments, a more robust and clear
installation procedure, and perhaps lay the ground for further
integration.  Zope 3's Publisher interfaces were proposed as a potential
starting point (not to be in any way confused with Zope 2 ;).
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ian Bicking | 28 Jul 2003 05:34
Gravatar

Re: To review our status...

On Sun, 2003-07-27 at 22:05, Aaron Held wrote:
> I volunteer to work on the Webware blog / news site.
> 
> I have been setting up PHPNuke (www.ManalapanSoccerClub.com) based sites 
> for clubs and just started hacking away Drupal 
> (http://www.CluesForDemocrats.org <- Not visited by the layout fairy yet 
> -  come to think of it it has not been visited by the content or QA 
> fairy either, but it will in a month or so).

I think most people are envisioning demo applications that aren't really
full applications, but a sort of bare minimum that's simple and yet is
representative of a more substantial application.

> For a common persistence layer I would like to go MySQL & dbAPI (with 
> all of the SQL in a single class), but I am open to something like 
> SQLObjects ot ZODB.  I think its important to put together a User class 
> first w/ a common backend first.

On a technical note, I think it shouldn't require a database server to
run the application -- even when a database server is available, it
still requires some effort to install a new application using that
database (or requires a sophisticated interactive install procedure,
which is well outside of the scope of this application).  It would be
better to use flat files, or some other mechanism that can either be
bundled, or is already included in the standard library.

Though most web applications use a database, usually in a rather central
manner, so it wouldn't be very representative to not use a database. 
Either way, though, the persistence probably won't be directly exposed,
so to make the whole thing more accessible it would be nice to avoid a
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ian Bicking | 28 Jul 2003 09:12
Gravatar

Re: Interface spec (ib0.1)

On Sun, 2003-07-20 at 13:41, Phillip J. Eby wrote:
> Further, let's say I wanted to make a publication that supported the 
> interfaces you proposed:
> 
> from zope.publisher.base import DefaultPublication
> from zope.publisher.publish import publish
> 
> 
> class PyWebPublication(DefaultPublication):
> 
>      # we implement IPublication, and the ib0.1 'ITransaction'
> 
>      def __init__(self, request, parser):
>          # We assume request is a Zope request instance
>          request.setPublication(self)
>          self.request = request
>          self.response = request.response
>          self.parser = parser
>          publish(request)
> 
>      def getApplication(self, request):
>          # use an empty list to accumulate names in
>          return []
> 
>      def traverseName(self, request, ob, name, check_auth=1):
>          # accumulate names in the traverse object
>          ob.append(name)
>          return ob
> 
>      def callObject(self, request, ob):
(Continue reading)

Permalink | Reply | 0 comments |
headers
Phillip J. Eby | 28 Jul 2003 16:39
Gravatar

Re: Interface spec (ib0.1)

At 02:12 AM 7/28/03 -0500, Ian Bicking wrote:
>On Sun, 2003-07-20 at 13:41, Phillip J. Eby wrote:
>
> > While it's a little awkward to accumulate the path and then shove it whole
> > into the path parser, it's also crystal clear that you *can* do it, and
> > how.  It also, I think, demonstrates that to some extent the Zope 3 
> pattern
> > for this is rather more flexible, or at least more extensible in a
> > fine-grained way, than your proposal.
>
>I just sat down and starting thinking about this, and I disagree.

I'm not sure what part you disagree with.  By "more flexible", I meant, 
it's easier to adapt Zope 3 to incorporate a "non-publishing" approach, 
than to adapt your proposal to a publishing approach.  I still think that's 
true, even if in some small part it's because your proposal isn't 
implemented yet.  ;)

>Maybe
>there's some tricks that can be used with traversal that I'm not
>thinking about, but traversal to me feels like a bad method -- it puts
>the loop in the publish method,

I thought I explained, but maybe I didn't.  The loop is in the Request 
object.  That's because depending on the incoming protocol (XMLRPC vs. 
WebDAV vs. web browser), the request info may be interpreted 
differently.  For example, a web browser wants to end up with a default 
method when you have a trailing /, but WebDAV wants to access a container.

Note also that for example the 'callTraversalHooks()' method of the
(Continue reading)

Permalink | Reply | 0 comments |

Gmane