speaking of integration ...

[Milan Andric]

If I was going to make my app "Pinax pluggable" is there another app
out there that I should use as a prototype? I imagine there are some
apps that are better integrated with Pinax than others. Do you have a
favorite app that has some of these happy patterns in usage?

Do folks see value in providing some documentation for this or is the
recommendation to just download pinax and make sure your app works? I
will collect together with my findings and draft a document about
this.

Thanks for your input,

--Milan

[flo...@gmail.com]

Seems to me that the best guidelines to follow are those set by James
Bennett. To learn more, watch his DjangoCon presentation here:
http://www.youtube.com/watch?v=A-S0tqpPga4

-Eric Florenzano

[bobhaugen]

Milan,

I created a Pinax-pluggable app: http://cloud27.com/swaps/

I'll be at the upcoming Django Chicago meetup, which I think you will
attend too, We can talk.

The code for Swaps is here: http://code.google.com/p/django-social-economics/

I made a few mistakes, including putting more than one app in that
project.

There's a patch here http://code.google.com/p/django-social-economics/downloads/list
that includes everything I needed to do to integrate with Pinax for
the first time.

After that, somebody on the Pinax crew duplicated all the Swaps
templates under Pinax, which has caused some problems, as you can see
here:
http://code.google.com/p/django-hotclub/issues/detail?id=54

I think that duplication was a mistake, but so far, it has not hit the
priority queue to be changed.

So in short, I would not promote Swaps as a model to emulate, but you
might learn something from my experience.

[Milan Andric]

Thanks all for the hints folks.

So I noticed in James Bennett's reuseable apps talk he says a couple things about templates:

1) Set a default template name but allow it to be overridden.

2) Templates are nearly impossible to make portable because of
 block structure, inheritance, tag libraries etc

So I've taken the liberty of documenting a couple of patterns related to templates and media that are fairly visible out there in the Django ecosystem.   My hopes are this leads to apps that are *more* pluggable or gives a good starting place for newbies.  Note this does not address the template block and inheritance conventions, which is a more difficult problem and one I'd like to address someday.

==Project layout==

myproject/
    templates/   
          base.html [1]
          wiki/
               base.html [2]
    media/
          wiki ->  /your/app/path/wiki/media/wiki  [3]
    settings.py
          INSTALLED_APPS=('wiki', ... , )  
          WIKI_MEDIA_URL = '/media/wiki' [4]

Django projects can live wherever you would like them to.  Use your project directory to configure your site's settings and urls of the application.

[1] Your friendly neighborhood base html layout.

[2] The wiki app comes with it's own base template. you can override that by creating a  wiki/base.html with one line in it: {% extends 'base.html' %}.

[3] In order for the wiki media to be found you need to link it into the main project media directory.  in unix we can use a symlink.

[4] You can easily customize where the media for the wiki app lives.

==Application Layout==

A Django application needs to be on the python path so imports will work.

wiki/
         forms.py
         views.py
         models.py
         templates/
                    wiki/
                        edit_page.html
                        list_index.html
                        base.html [5]

         media/ [6]
                     wiki/
                             js/
                             css/
                             img/

[5] Package your app with a base.html so if someone wants to run the standalone app as is, it "works out of the box".  If they don't like it then override as noted above in [2].

[6] Package your app with media so it "works out of the box".

One thing that becomes evident is it would be handy to have a base.html template that app developers can use that has all the block names pre defined, just as a starting point.

This might be obvious to the seasoned of folks, but those new to the game might find it useful.  From what I can tell about reuseable apps, the difficulty is in integrating the templates and media.  Let me know what you think.  Hope this helps.

--
Milan

[Eric Drechsel]

I posted in a separate thread without seeing this about making Pinax's
default templates' menu system completely pluggable. It's really
close, you just copy/modify site_base.html, but each tab in the main
nav needs a line of CSS. It'd be nice if this could go away.

[James Tauber]

On Sep 18, 2008, at 4:55 PM, Eric Drechsel wrote:
> I posted in a separate thread without seeing this about making Pinax's
> default templates' menu system completely pluggable. It's really
> close, you just copy/modify site_base.html, but each tab in the main
> nav needs a line of CSS. It'd be nice if this could go away.

Well, one approach would be to generate the CSS (or that part of it)

There are a number of db-driven nav solutions that we could include in
Pinax although they aren't appropriate for all sites -- I don't really
like db-driven nav although I recognize it makes sense if you want to
enable changing navigation via the web (which is appropriate for some
sites, but not others)

James

[Eric Drechsel]

I was thinking more along the lines of a way for an app to provide
menu fragments in a way that is complementary to the url mapping
system, perhaps by having an extra file "menu.py".

I guess an application-level menu.py could "plant" the various
fragments in the total navigation, possibly modifying them.

A similar pattern is used in Drupal's menu system, which also provides
url mapping. Menus are provided by hook_menu implementations (hooks
are the dominant paradigm in Drupal, but it's the same idea).

Perhaps some sort of DB integration could be provided as an addon app?