Sorry if the answer to this question is completely obvious, but...
I just watched the Djangocon Pinax video, and it looks like Pinax
could provide a nice base platform for a social networking site that
I'm working on. After all, it already includes lots of the individual
apps that I was looking at including. However, I haven't seen any
description or documentation of how to incorporate one's particular
domain-specific objects into Pinax in such a way that it will play
nicely with others. James mentioned "django-things" in the video, but
there's no there there.
It's relatively easy to download Pinax and get it running, but then
what?
That is, while I am comfortable with Django in general, I'm not seeing
how to connect the dots in this particular situation.
On Thu, Sep 25, 2008 at 4:25 PM, Jason Mayfield <jwmayfi...@gmail.com> wrote:
> Sorry if the answer to this question is completely obvious, but...
> I just watched the Djangocon Pinax video, and it looks like Pinax > could provide a nice base platform for a social networking site that > I'm working on. After all, it already includes lots of the individual > apps that I was looking at including. However, I haven't seen any > description or documentation of how to incorporate one's particular > domain-specific objects into Pinax in such a way that it will play > nicely with others. James mentioned "django-things" in the video, but > there's no there there.
Jason, I for one don't understand what you mean by domain-specific-objects. Can you enlighten us a little, maybe I'm not the only one.
The idea is you have to integrate your application with Pinax. Pinax has established some conventions that work in 20+ apps, but if you develop something then you have to make it Pinax compatible so it will work like the other apps.
> Jason, I for one don't understand what you mean by > domain-specific-objects. Can you enlighten us a little, maybe I'm not > the only one.
It's a phrase used by James in his presentation at Djangocon to describe the specific thing that you're socially-networking about. For instance, for Quisition, it's flashcards. It's the layer that you put on top of Pinax.
> The idea is you have to integrate your application with Pinax. Pinax > has established some conventions that work in 20+ apps, but if you > develop something then you have to make it Pinax compatible so it will > work like the other apps.
This may be what I'm trying to do, although it doesn't feel right. Is there any actual description anywhere of these conventions? What I've seen so far is folks saying that there are some, but never quite what they are. I may be looking in the wrong place.
On Fri, Sep 26, 2008 at 12:50 PM, Jason Mayfield <jwmayfi...@gmail.com> wrote:
> On Sep 26, 2008, at 3:10 PM, Milan Andric wrote:
>> Jason, I for one don't understand what you mean by >> domain-specific-objects. Can you enlighten us a little, maybe I'm not >> the only one.
> It's a phrase used by James in his presentation at Djangocon to > describe the specific thing that you're socially-networking about. > For instance, for Quisition, it's flashcards. It's the layer that you > put on top of Pinax.
>> The idea is you have to integrate your application with Pinax. Pinax >> has established some conventions that work in 20+ apps, but if you >> develop something then you have to make it Pinax compatible so it will >> work like the other apps.
> This may be what I'm trying to do, although it doesn't feel right. Is > there any actual description anywhere of these conventions? What I've > seen so far is folks saying that there are some, but never quite what > they are. I may be looking in the wrong place.
At this point in time the conventions are in the code. ;) So you have to find another app to prototype your app from. I think wikiapp is pretty well designed, but that's just my opinion. I'd recommend taking a look at the popular apps and making a judgment call on which one looks most mature. Then model your app after that.
Pinax is under heavy development at the moment, especially with all the changes from Django 1.0. So the best way to get answers at the moment is the IRC channels; #pinax and #django-hotclub.
Where in the folder structure should one put their own additional apps
where it won't get in the way of the rest of the internal and external
apps in the SVN repository?
> Where in the folder structure should one put their own additional apps
> where it won't get in the way of the rest of the internal and external
> apps in the SVN repository?
Actually, let me clarify that a bit more. I know applications can
live anywhere, but what do people tend to do when working with Pinax?
Not only in regards to their own apps, but also media and templates?
I know all of those things can live anywhere, but it's nice to have
all the files for a site live in or near the same area on the
filesystem.
I'm also interested in hearing about how other people incorporate all
the bits and pieces they use for a particular site into a repository
for deployment.
On Sep 29, 2008, at 8:49 PM, Trey Piepmeier wrote:
>> Where in the folder structure should one put their own additional >> apps >> where it won't get in the way of the rest of the internal and >> external >> apps in the SVN repository?
> Actually, let me clarify that a bit more. I know applications can > live anywhere, but what do people tend to do when working with Pinax? > Not only in regards to their own apps, but also media and templates? > I know all of those things can live anywhere, but it's nice to have > all the files for a site live in or near the same area on the > filesystem.
For cloud27 we just have our own project containing urls.py, settings.py, site_media and templates and don't use the 'pinax' directory. Everything else we use exactly as is.
On Mon, Sep 29, 2008 at 7:49 PM, Trey Piepmeier <tpiepme...@gmail.com> wrote:
>> Where in the folder structure should one put their own additional apps >> where it won't get in the way of the rest of the internal and external >> apps in the SVN repository?
> Actually, let me clarify that a bit more. I know applications can > live anywhere, but what do people tend to do when working with Pinax? > Not only in regards to their own apps, but also media and templates? > I know all of those things can live anywhere, but it's nice to have > all the files for a site live in or near the same area on the > filesystem.
> I'm also interested in hearing about how other people incorporate all > the bits and pieces they use for a particular site into a repository > for deployment.
I would probably put it in the pinax/ directory unless it's a "standalone" or "pluggable" app. From what I gather Pinax is just a Django project and thusly can be composed simply of a settings.py and urls.py file. Pinax aims to be that simple one day. The apps that are still inside of pinax/ are still in the "incubator" as some have termed it.
I don't see anything wrong with putting your own apps that you are working on in pinax/ until they are ready to live in their own separate apps directory/custom site-packages folder. I just had a peak and that's what these docs (fresh off the presses) suggests, so I may have guessed right. http://pinaxproject.com/docs/customization.html
I had a related post last week as well which might prove useful, relating to template and media dirs.
The developers are still working on documentation and breathing life into Pinax, part of that is developing formalized conventions, which have yet to fully emerge.
That sounds great. The new official documentation is exactly what I
was looking for. Thanks!
The only thing I would be slightly concerned about is that things
inside the pinax/ folder are changing so often, that I won't get all
the hotness without manually adding it back in.
> For cloud27 we just have our own project containing urls.py,
> settings.py, site_media and templates and don't use the 'pinax'
> directory. Everything else we use exactly as is.
No pinax/ directory at all. Interesting. So the whole point of that
directory is just to show an example of what can be done? Any
development of Pinax proper is outside of that?
Then there's several ways to deal with the libs/ directory so all the apps and pinax are on your python path. Take your pick. If you use the mod_wsgi deploy script from the pinax/deploy/pinax.wsgi then your paths get setup with modifications to sys.path. http://code.google.com/p/django-hotclub/source/browse/trunk/pinax/dep...
> Definitely keep it out of your public_html directory. Something like:
OK, that example was a little confusing. In my setup (based on the wisdom of the guides on articles.slicehost.com), all of my sites live in /home/username/public_html/, but the VirtualHost information for each site is configured to point to /home/username/public_html/<domain.name>/public/ or similar (with other folders adjacent to public/ such as log/). So I'm not actually talking about putting the Django project in the DocumentRoot or anything foolish like that.
That being said, are you saying that once I make a copy of the django-hotclub/pinax folder to use for my own project, it should live in
On Sep 29, 2008, at 9:57 PM, Trey Piepmeier wrote:
> No pinax/ directory at all. Interesting. So the whole point of that > directory is just to show an example of what can be done? Any > development of Pinax proper is outside of that?
There's not actually much under that directory -- only starter templates and icons and CSS under site_media. If you're building your own site you'd want to modify those anyway. All the reusable code is under separate directories.
To: echo "ROOT_URLCONF = '[name_of_project].urls'" > localsettings.py
You don't need to copy all of settings.py to localsettings.py ... just specify the overrides. Similarly other settings would get modified. The localsettings trick is one that makes the production/development switch easier as well. Typically localsettings.py does not going into your repo, while settings.py does.
> To: > echo "ROOT_URLCONF = '[name_of_project].urls'" > localsettings.py
> You don't need to copy all of settings.py to localsettings.py ... just > specify the overrides. Similarly other settings would get modified. > The localsettings trick is one that makes the production/development > switch easier as well. Typically localsettings.py does not going into > your repo, while settings.py does.
