Cross-Project code sharing...modules/plugins what does Pylons use?
rcs_comp
I am new to the Python web-programming world and trying to decide on
frameworks. I was really impressed with Django, but ran into some
problems with IIS hosting. Since Pylons had really nice install
instructions for IIS, I started to take a look and I like the
philosophy. The WSGI from the ground up mentality seems to be a real
plus.
However, I have run across a show stopper for me with Pylons unless I
have missed something in the documentation. Does Pylons support some
kind of module/plugin architecture that will allow me to develop "plug-
in" functionality across Pylons projects? What would be called in
Django an "app".
For example, I would like to have a "news", "blog", and "calendar"
module that I can plug into different applications. The goal is to
have everything for the module contained in one subdirectory including
any configuration, routing, templates, controllers, model, etc. So,
something like this:
/modules/news/...
/modules/calendar/...
/modules/blog/...
Thanks.
Shannon -jj Behrens
I'm sure others will say something different, but my approach has
always been to simply run multiple apps on separate subdomains.
Subdomains are free ;) In the past, I had login.foxmarks.com,
my.foxmarks.com, and www.foxmarks.com. Each of the apps were
completely separate, but I used Genshi to create a common look and
feel.
-jj
--
I, for one, welcome our new Facebook overlords!
http://jjinux.blogspot.com/
Wichert Akkerman
> However, I have run across a show stopper for me with Pylons unless I
> have missed something in the documentation. Does Pylons support some
> kind of module/plugin architecture that will allow me to develop "plug-
> in" functionality across Pylons projects? What would be called in
> Django an "app".
No: the way pylons is setup it will only look for controllers and
templates in a single package. That is not terribly hard to fix but I'm
not sure if that is a design goal for pylons.
Wichert.
--
Wichert Akkerman <wic...@wiggy.net> It is simple to make things.
http://www.wiggy.net/ It is hard to make things simple.
Jose Galvez
Jose
Wichert Akkerman
> how is this essentially different from tosco widgets? or just making a
> python module that you put someplace in your python path for your pylons
> app to find?
Because your add-ons may want to do things like add a new controller,
replace a template, etc.
Mike Orr
You can make a Pylons application for each component, and then tie
them into the parent app via a pseudo-controller. (I.e., replace the
controller class with your WSGI app instance, but keep the controller
name.) Set full_stack=False in the subapplication; you may also want
to comment out the error middleware. I haven't seen anyone do it but
it theoretically should work. You may have to a little bit to pass
the config dict.
--
Mike Orr <slugg...@gmail.com>
Jonathan Vanasco
necessary templates and controllers.
I intensely dislike how the modular approach compartmentalizes the
routing and model. If something is affecting the routing & model,
IMHO, it's not a plugin - its a standalone app.
At FindMeOn, we're currently finishing up "Open Social Network - In A
Box" , basically a toolkit for building social media webapps under
pylons. The design we're running with right now... is a core model/
controller/lib which the main Pylons app inherits. Instead of
creating a new 'module/blog', you just create blog_controller.py,
which can be as simple as
from inabox.controllers.blog_contoller import BlogController as
OpenSocialNetworkBlogController
clas BlogController( OpenSocialNetworkBlogController ):
pass
Mike Orr
from myinnerapp.config.middleware import make_app
OuterController = make_app(config["global_conf"], full_stack=False,
**config["app_conf"])
This would push another config onto of pylons.config, but since it's
the same as the parent's config that shouldn't make a difference.
As for the other middleware changes, I was misremembering. The error
middlewares are already under "if asbool(full_stack)". What I had
suggested earlier was that SessionMiddleware and CacheMiddleware also
belong under that 'if' so that the outermost one is used.
RoutesMiddleware, I'm not sure (see below).
On Sat, May 24, 2008 at 12:44 PM, Jonathan Vanasco
<jona...@findmeon.com> wrote:
>
> I *really* like how the modular approach can compartmentalize the
> necessary templates and controllers.
>
> I intensely dislike how the modular approach compartmentalizes the
> routing and model. If something is affecting the routing & model,
> IMHO, it's not a plugin - its a standalone app.
Well, it affects the routing only in the sense that the subapp parses
the rest of the URL -- as it should. If the route is defined as
/subapp/*path_info (a magic name), this should set up PATH_INFO for
the subapp. On the other hand, I'm not sure whether you can nest
RouteMiddlewares and RouteMaps or not. How would url_for know which
set of routes to choose? It just takes somebody to do this and figure
out what works. (The Routes 2 structure I have in mind should help
with this. The middleware puts a request-specific URL generator in
the WSGI environ, which Pylons mounts onto 'pylons.url' -- a
StackedObjectProxy like pylons.request. This should allow the inner
app to see its own URL generator, and the outer app its own.)
As for the model, I forgot about that. That is a bit of a hassle, to
get multiple models to share the same database and connection pool.
Which just means we have to figure out the right standard
configuration for it. One way would be for the top-level
environment.py to set up the engine as normal and then call the
subapp's init_model(). Another way would be for the top
environment.py to initialize its own model, then put the engine in the
config for the subapp to use. That means the subapp would have to
anticpate this happening, though it could check for an engine object
first, and if none was there create its own engine.
> The design we're running with right now... is a core model/
> controller/lib which the main Pylons app inherits.
It will be interesting to see this structure. Certainly, the
controller does not have to use the global templates directory or
render method; if it uses its own templates stored its own way, that
works too.
But then that gets into the issue of the site template. If the inner
app should be shown within the global header and sidebar, then you'd
have to inherit the site template -- which doesn't work well across
apps, plus you'd have to know what variables to set for the site
template. Or the outer app could have a controller ACTION (not a
whole controller) that calls the inner app to get the page content,
and then plugs that into its template. The action could emulate a
WSGI server, possibly using WebOb's application-wrapper for
convenience.
I definitely think there's a huge potential for autonomous Pylons app
components, if we can just figure out the details. Then you could
plug a Pylons wiki or calendar or shopping cart or ticket manager into
a Pylons app in five minutes.
--
Mike Orr <slugg...@gmail.com>
rcs_comp
Pylons will not work for my projects. The need to develop components
that fit easily and natively into the larger application is a must.
Its disappointing though, b/c I was really liking the philosophy
behind Pylons. Keep up the good work. IMO, this is a must for any
robust framework and I hope Pylons incorporates this functionality
into its framework philosophy some day.
Philip Jenvey
On May 24, 2008, at 6:37 AM, rcs_comp wrote:
>
> For example, I would like to have a "news", "blog", and "calendar"
> module that I can plug into different applications. The goal is to
> have everything for the module contained in one subdirectory including
> any configuration, routing, templates, controllers, model, etc. So,
> something like this:
>
> /modules/news/...
> /modules/calendar/...
> /modules/blog/...
If these are in fact separate applications, you can make each one its
own Pylons app. Then you might also have a common package of code
shared between all three (this would be a separate egg).
Then at deployment time you can combine them into one composite
application with Paste URL map, via the ini file:
http://pythonpaste.org/deploy/#composite-applications
--
Philip Jenvey
rcs_comp
> If these are in fact separate applications, you can make each one its
> own Pylons app. Then you might also have a common package of code
> shared between all three (this would be a separate egg).
>
> Then at deployment time you can combine them into one composite
> application with Paste URL map, via the ini file:
>
> http://pythonpaste.org/deploy/#composite-applications
Thanks for the reply. I guess I am not familiar enough with Pylons to
know exactly what you mean by "application." However, I don't think I
intend for my modules to be applications in and of themselves. For
example, I don't want to have to worry about defining DB connections,
having decorator templates (i.e. the look that is shared across all
pages), etc. per module. Rather, I would envision a module using the
DB connection the application defined (even though it would have its
own tables / database objects, etc.) and having generic template
blocks that fit into the overall look of the site that is defined at
the application level.
Cliff Wells
On Sat, 2008-05-24 at 16:21 -0700, Mike Orr wrote:
> But then that gets into the issue of the site template. If the inner
> app should be shown within the global header and sidebar, then you'd
> have to inherit the site template -- which doesn't work well across
> apps, plus you'd have to know what variables to set for the site
> template. Or the outer app could have a controller ACTION (not a
> whole controller) that calls the inner app to get the page content,
> and then plugs that into its template. The action could emulate a
> WSGI server, possibly using WebOb's application-wrapper for
> convenience.
Long ago the topic of portlet-style sites came up on this list and Ian
suggested using a subrequest and paste.recursive. Wouldn't a web helper
that could do a subrequest be a possible solution? Rather than the
plugin inheriting the site template, the site template would perform a
subrequest to retrieve the plugin's html.
Regards,
Cliff
Mike Orr
It could. I'm not really a fan of subrequests, seems like a lot of
overhead. But in some cases it may be the simplest solution.
--
Mike Orr <slugg...@gmail.com>
Cliff Wells
As I understand it, paste.recursive turns local subrequests into a
function call(s) rather than actually making another HTTP request. So
there will undoubtedly be a small amount of additional overhead, but not
as much as a full subrequest would normally incur.
Cliff
Jonathan Vanasco
On May 24, 7:21 pm, "Mike Orr" <sluggos...@gmail.com> wrote:
> Well, it affects the routing only in the sense that the subapp parses
> the rest of the URL -- as it should. If the route is defined as
> /subapp/*path_info (a magic name), this should set up PATH_INFO for
> the subapp. On the other hand, I'm not sure whether you can nest
> RouteMiddlewares and RouteMaps or not. How would url_for know which
> set of routes to choose?
A) Encode everything by hand into /config/routing.py
B) Encode a dispatch to the 'plugin' on /config/routing.py - have the
plugin handle everything itself
C) Have the plugin 'register' on initialization, and populating the
Map object from routing.py with its own code.
I think A is the best option. Others disagree.
B requires you to use dome dumb/catchall urls in your app, and proxies
things off like they're a separate app. ( ie everything under /
calendar goes to the cal module )
C is neat for your own plugins, but can get messy and untrusting with
public modules.
IIRC, Django and Rails use B and Catalyst and Mason use C. I haven't
looked at any of those in a while though.
> As for the model, I forgot about that. That is a bit of a hassle, to
> get multiple models to share the same database and connection pool.
a bit of a singleton mentality.
My main issue with the 'modular' approach and models, is that you run
the risk of having class and db table overlap. You also have to
coordinate models across each module and the large main app. I've yet
to see this done well in any system that is 'open'... the only times
this seems to work out well is when the you some sort of gatekeeper
who enforces strict rules for module submission.
> I definitely think there's a huge potential for autonomous Pylons app
> components, if we can just figure out the details. Then you could
> plug a Pylons wiki or calendar or shopping cart or ticket manager into
> a Pylons app in five minutes.
We're kind of trying to do that cross-platform with
SocialMediaStandards.org -- consolidating what all the basic models
and controllers are in social media apps, so that people can quickly
integrate into an applications tablespace or API with new social media
functionality.