On Apr 28, 12:25 pm, Ben Bangert <[email protected]> wrote:
> The key difference between Django style re-use and repoze.bfg/Zope
> style re-use is how much life is going to suck down the road
> maintaining the apps. When you consider how Django approaches it, it
> seems like this will be a pain unless you're a DVCS master and are
> sure to use it because say you have:
>
> Site 1:
> - Comments app
> - Reviews app
>
> Site 2:
> - Comments app
> - Reviews app
> - Articles app
>
> Technically each 'app' in Django is just a sub-dir, so if you have 2+
> sites, and you make a huge set of improvements to the Reviews app,
> odd's are each site project itself is in its own version repository,
> each app *itself* is merely in the larger project. So it becomes a bit
> of a hassle ensuring that your Reviews app is up to date on each site,
> and upgrading individual app's is problematic.
I am not sure how applicable this will be to Pylons (and I know
nothing about Zope), but here is how I solved the said problem in
pysmvt:
The simplest project would have one application (myapp) and the said
application would have at least one module. All views (controllers)/
templates/routes reside in the module, which we will call default,
which is stored in the modules directory of the application
directory. The base myapp directory must be on the python path so
that it could be imported using 'import myapp'.
Now, lets say you want to add a news module to myapp. If you are
building it from scratch, just create a directory like .../myapp/
modules/news, with the appropriate files and directories, and start
coding. Adjust news/settings.py or myapp/settings.py to have the
appropriate routes, and you are off and running.
However, lets say that the news module already exists and you want to
use it in myapp. Instead of creating the news directory manually,
make it an SVN external (or equivalent). Ah, but what happens if you
need to customize news in a way you wouldn't want to commit to the
main news module's trunk? Enter supporting applications.
Create a new application, supportingapp. It doesn't even really need
a setup file or anything, it just needs to be on the python path and
have a modules directory. Now, use SVN externals on the supportingapp/
modules directory so that the news module is installed there. In
myapp/settings.py, make a single entry so that the framework knows
that myapp is using supporting app as a supporting application. The
framework will now do hierarchical based imports looking at the main
app first and then recursing into the supporting app(s) to find
objects. So if the routing says '/news/list' maps to the NewsList
view in the news module, then myapp will be searched first and when it
isn't found, supportingapp will be searched, found, and displayed.
Now, if you need to customize NewsList, you simply create a news
module in myapp with a NewsList view and it will automatically
override the NewsList view from supportingapp.
Enter, myapp2, a different app that also needs to use the non-modified
version of the news module. No problem, just tell myapp2 to use
supportingapp as a supporting application. If a bug is found in the
news module, it can be fixed in both applications by simply updating
'.../supportingapp/modules/news'.
I have found the concept of supporting (i.e. stacked) applications
with inheritance to be helpful on a number of different levels. Since
you don't have to use it, or even know about it, it is very easy to
create a basic application. But the inheritance structure gives a lot
of power and flexibility down the road.
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
