> I have two sites I want to convert to Pylons. Each site is just a
> collection of independent components which could conceivably be
> separate WSGI applications. But the sites handle authentication,
>
> Pylons has a one-level structure. It doesn't really work to create a
> Pylons project inside another, and the config file would have to be at
>
> I'm also not sure I want a large number of tiny Pylons applications to
> keep track of. On the other hand, I need "bundles" of controllers,
> views, models, lib modules, and static files -- and that's what a
> Pylons application is.
this is one of my major gripes not with the model/view/controller
(MVC) pattern itself, but the way it is currently supposed to be
implemented in current web frameworks such as ruby on rails or pylons
and i guess in a good many others too.
each time i define a certain component, be it as simple as one webform
or as complex as a signup or purchase finalisation i end up spreading
the procedural, declarative and narrative aspects of such a unit of
concern over the entire web application's domain: javascripts and
images go into .../public, the html templating into .../templates, the
controller(s) needed to handle requests into .../controllers, and so
on. try to port that to another web application, and you'll have to go
hunting.
i have come more and more to the conclusion that this way of sorting
out files is detrimental to a modularized, project- or concern-
oriented way of programming. it reminds me of window's standard home
directory layout: there is 'my music' and 'my pictures' and 'my
documents', but clearly what i prefer to have is to keep all the files
that connect to a specific event, project or person together in a
single, possibly structured location.
i have tried before and was successful to a certain point to reverse
pylon's standard layout. the keys to doing just that are, i believe,
in .../config/environment.py. there is a path variable set that one
can modify to read, for example,
paths = {
'root_path': root_path,
'controllers': _osp.join( root_path, 'modules' ),
'templates': [ _osp.join( root_path, path ) for path in
( 'modules', ) ],
'static_files': _osp.join( root_path, 'modules' )
}
so then all the stuff is being looked for under a new directory .../
modules (even that one is not strictly needed; putting everything
right under the spplication's folder should be fine, too). the problem
with this setup is that now *everything* has become public. we
certainly do not want to hand out our templates and configurations out
to the public, so we have to somehow prevent that.
as far as i can see, there are two places to keep secrets secret, and
there are two ways to achieve that. the two places are (1) pylon's
middleware and/or routing configuration, and (2) apache configuration
if you use that one. the two ways to keep things from being world-
accessible are (A) file-type based, or (B) location based (there is
still the possibility (C) to list either all public or else all
private files in a configuration, but you probably don't want to do
that; and (D) require any public files not to have filenames that
start with an underscore and not be in a directory hierarchy where any
directory name starts with an underscore).
how to do (1) (keeping files from being served using middleware or
routes) i don't know, maybe some kind reader cares to comment. doing
(2) is not so difficult: for example, using mod_rewrite you can deny
access to resources that match certain textual criteria; as mentioned,
we can look at (A) the filename extension (i.e. allow *.jpg, *.gif,
*.png, *.html, *.css, ...; disallow *.py, *.mako.html, ...) or (B)
require the published file have a portion like /public/ in their name:
then images, style sheets and javascripts can still go into a
specialized folder, but this time one that is local to a given
functional unit.
the layout could look like this (in reality there would be many more
modules, of course; also, i skipped the .../modules folder):
#========================================================
myapp/
#------------------------------------------------------
# globally public files
public/
jquery.1.2.1.js # JS library, always needed
main.css # site style sheet
#------------------------------------------------------
# a checkout module
checkout/
#....................................................
# private part
checkout.py # the controller
checkout1.mako.html # page1 of checkout
checkout2.mako.html # page2 of checkout
foo.partial.mako.html # a partial template
#....................................................
# public part
public/
foocart.js # client-side functionality
cart.png # image resource
foocart.css # cart-specific styles
i am going to implement this in a little while from now, so i am
really keen on hearing opinions about this schema.
_wolf
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
