On Nov 21, 2007 4:27 AM, Graham Higgins <[EMAIL PROTECTED]> wrote:
> It may be that an effective, well-designed framework (e.g. Pylons)
> gives developers such a wide range of possible approaches to
> developing an app that the idea of hacking on a pre-published generic
> app is less appealing than the idea of hacking it up oneself from
> scratch.
>
> Or, it may be that there just isn't enough critical mass in the
> userbase ATM to sustain the development of a generic app.
>
> Or, we're maybe we're trying to work at the wrong level. I've
> recently added ElixirGenXML to my stack of interesting things to fire
> up and test, perhaps that's the level at which we should be working.
> But even so, a simple thought experiment brings a dash of cool
> rationality: someone produces a spec of a Wordpress-alike blog for
> Pylons. How many folks are likely to rush to join the development team?
The problem is modularity. I may not be interested in TurboLog,
Docudo, Plone, TRAC, pyBlosxom, etc in their entirety, but I'd like to
use components from them if they were easily extractable, or even
smaller functions to do certain tasks. That is the essence of Paste
and Pylons, so it would be nice to extend this to a richer set of
tools. For instance, we've talked about embedding wikis or a
TRAC-like project manager into our sites eventually. Maybe we don't
want all of Plone but that WYSIWYG text area that automatically
recognizes formatted Word text would be useful. Things like that.
Some users want a complete blog system ready to embed. Others want to
take certain features and plug them into their own blog system, or
even their not-really-a-blog system.
> I got quite a lot of illumination from Ben's ruminations on how the
> early adopters of Pylons took it in a different direction to that
> which the dev team initially anticipated.
I'm curious about this. What do you mean?
> As Pylons gains more
> traction and exposure, the ratio between developers-doing-it-for-
> themselves and, ah, "deployers" will change and we'll probably see a
> lot more calls/bleats for deployer-friendly features like TG's DB
> browser (which people perceive as flattening the learning curve) and
> ready-built apps that can be deployed out of the box.
We've got two or three types of users. One is the hacker type who
prefers low-level tools like Paste, but found Pylons too convenient to
ignore. These are people who might otherwise build their sites from
scratch (SimpleHTTPServer, web.py).
At the other extreme is the stereotypical "Brian" who wants something
high-level that works out of the box, with AJAX, authentication, form
widgets, DB browser, admin interface, and all the other gee-whiz
features. These are the people who might otherwise choose Rails,
Django, PHP, Java, etc. These people have generally passed up on
Pylons because the features and ease-of-use aren't quite there yet.
Then there's people in between who like Pylons' modularity for
philosophical reasons, and/or also appreciate the add-ons (auth,
internationalization, documentation, a future blog plugin, etc).
Probably the majority of users fall into this category.
Deployer-friendly features are of interest to both the second two
groups, so there will continue to be increasing calls for those,
although not in the Pylons core. However, calls for these are not
new; they've been rumbling for at least a year. The developers have
always responded, "That's a great idea but we don't have time to do it
right now."
It's generally assumed that these will be available in a year or so.
The most exciting thing to happen is TG's new interoperability with
Pylons because it brings some of these features ready-made. Even more
interesting is the @expose decorator added to Pylons-dev, which brings
some of TG's output-mode flexibility to Pylons. It's interesting in
the sense of, "If they can do this, what next?"
> OTOH, we do seem to be presented with an opportunity to lay down some
> best practice principles for integrating multiple apps in a single
> Pylons stack (at arbitrary levels in the cascade), mainly in terms of
> providing integrated cross-app support for user admin, prefs and
> privs --- a topic which, up to now, every app developer has felt free
> to address independently.
Thus coming back to the question I raised earlier, how to embed a
Pylons app in a Pylons app. One can embed at several different
levels, so there are multiple answers to this. paste.urlmap,
paste.cascade, route to a WSGI controller, have a stub controller that
imports a Pylons app and uses make_app as a pseudo-controller. All of
these seem viable but none have been well tested among the userbase.
> Unfortunately, it rather requires a stable
> and commonly-accepted auth'n'auth solution, something which has yet
> to emerge from the mix, IMO.
AuthKit is trying to be that for Pylons, and for WSGI generally. But
some sites also need to span non-WSGI and non-Python components. And
ultimately you need a top-level authority for
authentication/logging/sessions, something that all the compnents can
"subscribe" to. It seems like the best answer now is to do this in
middleware.py, because if you composite at the Paste config level or
Apache you can't use a nice Pylons auth or logging feature.
I'm also really wondering about Repoze. Plone advocates are quite
excited about it, as bringing a new generation of mix n match which
will make the choice of framework irrelevant, or bring about the
demise of standalone frameworks. I still don't quite understand it,
or how much of the hype is really true vs Zope groupthink ("everybody
wants Zope, they just don't realize it yet"). For us the question is
more, will it help us embed Zope-using components? The other question
is, will it sweep Pylons away? What, if anything, should we do for
Pylons 1.0 to be more compatible with this? But it certainly sounds
like a major breakthrough for Plone in any case. Plone has been stuck
at Zope 2 due to the enormous work of upgrading. But it sounds like
Plone will get Zope 3 and WSGI in one fell swoop, which would
certainly make me more favorable toward Pone.
The only concrete advantage in Repoze that I've seen for non-Zope
components is, "allow for systems that participate in a WSGI pipeline
to make use of the existing two-phase commit transaction management
provided by the ZODB transaction package." Um, that assumes one needs
two-phase committing and versioning and an object database, doesn't
it? Not quite revolutionary.
http://www.oreillynet.com/onlamp/blog/2007/11/grok_repoze_and_wsgi_beg_the_q_1.html
--
Mike Orr <[EMAIL PROTECTED]>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"pylons-discuss" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/pylons-discuss?hl=en
-~----------~----~----~----~------~----~------~--~---
