Organizing multiple django projects/apps on 1 server
Hello all, I am pretty new to Django, and coming from a fairly "protective" environment in terms of web development. My only experience in webdev stems from my first job out of college, where I came into a very complex/robust system and did more tweaking/maintaining than creating. I am trying to broaden my horizons, and feel that my background is sort of tainting my view of how to organize my own server, especially one in which the framework used is so much different (read: better .. DRY, MVC) than what I am used to. So I created the stereotypical "blog" project, along with using pluggables such as tagging, django-syncr, etc. to further extend it. However, as I start to read around, I feel more and more that I really messed up the organization of that project. How I have it set up is like this: /mainproject (contains settings.py, etc). /mainproject/core/ (contains a bunch of core apps that are required throughout, i.e. I put the tagging and django-syncr apps here, as well as a people app for users) /mainproject/contrib/ (contains all the other apps, such as the blog app, a contact form app, etc) This has caused me a good deal of stress, as you probably can imagine. To start, I have clashing SVN repositories due to the svn checkout of tagging and django-syncr. Also, I have to add 3 separate paths to my PYTHONPATH in order to get python to find everything. As I add more sites to this server, and continued the same directory structure, I would end up needing 3 new entries on the PYTHONPATH for each project. I was thinking of changing this around, to better suit multiple django projects on one server, as well as simplify my pythonpath and repositories. /home/django/pluggables/ (contains such things as tagging, django- syncr, any other future pluggables I download) /home/django/sitename/projectname/ (contains settings.py for that site- project, templates, apps for that project, etc) /home/django/sitename/static/ (contains all static content, css, js, etc) How do you guys set up your directory structure, especially for servers that may host multiple websites using django? Is it bad form to use such a directory structure as I have currently set up? (I am guessing it is, but looking for confirmation or otherwise) Just trying to get some ideas on the most efficient, easily movable/ extensible way of organizing my projects on a shared server (shared in the sense that I have multiple sites, not a shared hosting environment per se, and movable in that how easily I could take one project and move it to a separate server). Thanks for your insight. Bryan --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Modifying Handler to support multiple customized, inheriting clients
Sorry to spam, but in re-reading my post I realized that I assumed people know what I mean by "Shared Code." Basically I would have one main code-base that will contain code that all clients inherit from. By default a client would just be running straight off that "shared" code-base, so 2 new clients will look identical until they ask for modifications. Then, clients can ask to override certain classes/functions to make changes to how things work on their instance. i.e. change how something displays on page X, or collect this extra field that is pertinent to them but not others. Then they can also ask for more drastic changes, like if one client wants an entire new page that other clients don't have. By doing this, clients can have their special features, but I can still make overall changes/bug fixes to all clients at once when I modify the "shared" code. That is what I am trying to accomplish, while still using django .. and I am not sure how to massage django to work in this scenario. On Feb 4, 1:57 pm, bbeaudreault <compbr...@gmail.com> wrote: > Note: I could just make one big app, and deploy it separately for all > my clients. But I want to be able to easily roll out big changes to > all my clients, without having to replicate code a manually across > them. That's why a Shared -> Client inheritance handler type of thing > would work perfectly here. > > On Feb 4, 1:54 pm, bbeaudreault <compbr...@gmail.com> wrote: > > > Ok, yea. Sorry for the title, it is hard to generalize this question > > enough to be short like that. > > > Anyway, at the company I work at we use mod_perl, and we have > > clients. Our code-base is set up like this: > > > Shared Code -> Client Code > > > The client code inherits and overrides shared code. So if in a > > certain script we overrode a shared function, just that client would > > see those changes. > > > So our clients go to our website like this > > :http://client.mycompany.com/client/. > > > I am working on a project in Django, and I too want to give clients > > the ability to customize their site (both override and extend) and > > towards that end, I am using my company's setup as a general template > > of what I want to do. If this got up and running, the general > > workflow would be: the client realizes something they want, they call > > up our support, ask for it, a ticket is issued to the developers, and > > we override shared code for that client. > > > Of course, my company uses Perl, and I want to use Python/Django. Two > > very different languages. My company is also kind of old, so a lot of > > how we run that handler is probably not the most up to date way of > > doing it. I know with Python I can use its built in Inheritance to > > override Class methods and such .. but I am wondering how I would best > > deal with this inside django? > > > Should I have multiple django instances running? one for each client? > > > Can I just make a separate app for each client and run under 1 django > > instance? i.e. have myproject.shared, myproject.client1, > > myproject.client2, etc > > > I appreciate any advice that you may have. Also, I tried searching > > google for modifying django handler, but I am not quite sure what > > terms I should be looking for. Is there a specific term for what I am > > trying to do, where I can read up on this sort of approach? Is there > > some standard way of running customized clients on shared code? > > > Thanks, > > > Bryan --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Modifying Handler to support multiple customized, inheriting clients
Note: I could just make one big app, and deploy it separately for all my clients. But I want to be able to easily roll out big changes to all my clients, without having to replicate code a manually across them. That's why a Shared -> Client inheritance handler type of thing would work perfectly here. On Feb 4, 1:54 pm, bbeaudreault <compbr...@gmail.com> wrote: > Ok, yea. Sorry for the title, it is hard to generalize this question > enough to be short like that. > > Anyway, at the company I work at we use mod_perl, and we have > clients. Our code-base is set up like this: > > Shared Code -> Client Code > > The client code inherits and overrides shared code. So if in a > certain script we overrode a shared function, just that client would > see those changes. > > So our clients go to our website like this > :http://client.mycompany.com/client/. > > I am working on a project in Django, and I too want to give clients > the ability to customize their site (both override and extend) and > towards that end, I am using my company's setup as a general template > of what I want to do. If this got up and running, the general > workflow would be: the client realizes something they want, they call > up our support, ask for it, a ticket is issued to the developers, and > we override shared code for that client. > > Of course, my company uses Perl, and I want to use Python/Django. Two > very different languages. My company is also kind of old, so a lot of > how we run that handler is probably not the most up to date way of > doing it. I know with Python I can use its built in Inheritance to > override Class methods and such .. but I am wondering how I would best > deal with this inside django? > > Should I have multiple django instances running? one for each client? > > Can I just make a separate app for each client and run under 1 django > instance? i.e. have myproject.shared, myproject.client1, > myproject.client2, etc > > I appreciate any advice that you may have. Also, I tried searching > google for modifying django handler, but I am not quite sure what > terms I should be looking for. Is there a specific term for what I am > trying to do, where I can read up on this sort of approach? Is there > some standard way of running customized clients on shared code? > > Thanks, > > Bryan --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Modifying Handler to support multiple customized, inheriting clients
Ok, yea. Sorry for the title, it is hard to generalize this question enough to be short like that. Anyway, at the company I work at we use mod_perl, and we have clients. Our code-base is set up like this: Shared Code -> Client Code The client code inherits and overrides shared code. So if in a certain script we overrode a shared function, just that client would see those changes. So our clients go to our website like this : http://client.mycompany.com/client/. I am working on a project in Django, and I too want to give clients the ability to customize their site (both override and extend) and towards that end, I am using my company's setup as a general template of what I want to do. If this got up and running, the general workflow would be: the client realizes something they want, they call up our support, ask for it, a ticket is issued to the developers, and we override shared code for that client. Of course, my company uses Perl, and I want to use Python/Django. Two very different languages. My company is also kind of old, so a lot of how we run that handler is probably not the most up to date way of doing it. I know with Python I can use its built in Inheritance to override Class methods and such .. but I am wondering how I would best deal with this inside django? Should I have multiple django instances running? one for each client? Can I just make a separate app for each client and run under 1 django instance? i.e. have myproject.shared, myproject.client1, myproject.client2, etc I appreciate any advice that you may have. Also, I tried searching google for modifying django handler, but I am not quite sure what terms I should be looking for. Is there a specific term for what I am trying to do, where I can read up on this sort of approach? Is there some standard way of running customized clients on shared code? Thanks, Bryan --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: DB relations and delete question
Wouldn't it depend on the type of DB? (mysql, postgresql,etc)? Or is this something enforced in django regardless of db? On Jul 3, 1:28 pm, Randy Barlow <[EMAIL PROTECTED]> wrote: > Jad wrote: > > Lets say we have Accounts that is referenced profile, group, interest > > tables. > > > If I delete the account ID 1 would the related data to that account in > > profile, group and interest table be deleted in all cases of relation? > > One to one, one to many, many to many? same question applies to > > update > > My understanding is that deletion is a cascading operation, following > all relations in the database. So use it very carefully! > > -- > Randy Barlow > Software Developer > The American Research Institutehttp://americanri.com > 919.228.4971 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: A little help with an idea
Thanks Daniel and Scott for the replies. It certainly has given me a better sense of how to implement something like this in Django, as well as an overall better understanding of Django in general. This will certainly be a fun project and I can't wait to get started on it as I learn more about the intricacies of django. Thanks again, Bryan On Jul 3, 9:18 am, "Scott Moonen" <[EMAIL PROTECTED]> wrote: > Bryan, here's one way that you might approach it: > > 1. From a model perspective, you probably want to have a model like > Account or Person or Blog that corresponds to the first component of the > URL > path. Then you can have a model like BlogPost or somesuch (maybe other > models like BlogStaticPage, BlogCalendarEntry) that has a ForeignKey > relating back to the top-level Blog model > 2. Create a single Django project and give it responsibility for your web > root. > 3. Now you can have URL dispatching and view methods that consume both > the first component of the url (/friend1) and also the blog page component > (e.g., /post-3). > 4. The tricky part is that you'll need some special logic in the view > method that pulls in the appropriate user-specific template. There are > various ways you can approach that; e.g., have paths to the view template > specified in the Blog model, or perhaps even have the view templates for a > blog contained directly within the database. > > There may be some challenges (esp. #4) with implementing this as a single > Django project, but I think that overall you'll find it a much better > solution than cloning your Django projects. > > -- Scott > > > > On Thu, Jul 3, 2008 at 8:50 AM, bbeaudreault <[EMAIL PROTECTED]> wrote: > > > Hey Daniel, > > > Thanks for the reply. ... Duh! I don't know why I didn't think of > > that. There are so many foreign aspects of this to me (yes I come > > from a mod_perl, php background). > > > I can give some more information to hopefully help me grasp this just > > that bit more. > > > Basically I am creating my own custom blog site for me and a few of my > > friends. We have wanted our own for a while, but I also have been > > wanting a project to work on so I don't want to use an already created > > one (I have a few ideas of my own that I haven't seen in others that I > > want to attempt). I started it in PHP, but then noticed django and > > decided to try a new approach to the whole thing. > > > So basically when I roll it out, the website would have no blogs on > > it, just a front page welcoming me and possibly displaying some > > statistics or news on it and allowing register/login. So if I were > > the first to create an account, I would gain access to > >www.mysite.com/bbeaudreault > > or whatever and the corresponding apps therein. If my friend > > registered they would get the same,www.mysite.com/friend1 > > > The kicker is I want them to be able to completely customize the look > > of their blog. From positioning of the different modules (like recent > > posts, calendar, etc being moved from left to right to top) to color > > scheme, to images on it, and of course disabling certain modules (if > > they don't want a calendar). Sure this may be more complicated than a > > blog has to be, but these will be added over time and will present a > > nice little project for myself in adding them as I go. > > > I guess now that I think of it more (if I am hopefully gaining a > > better grasp), when a new user is created I would have to automate an > > adding of a new url to the urls.py file. And I could probably store > > the resulting CSS from moving modules around, as well as flags for > > enabled/disabled modules in the DB for each user as well. > > > Does this sound more in line with django's design philosophy? > > > Oh, and yea I went through the tutorial, and it is great for the > > simple website kinda thing. I am just having a hard time > > extrapolating that to what I have in mind for this site (explained > > above) > > > Thanks again, > > Bryan > > > On Jul 3, 3:33 am, Daniel Hepper <[EMAIL PROTECTED]> wrote: > > > Hi Bryan, > > > > maybe I don't quite get what you are trying to do. > > > > URLs > > > likewww.mysite.com/Foo/don't<http://likewww.mysite.com/Foo/don%27t>relate > > > to filesystem paths > > > (like /home/django/Foo). They are mapped to python functions. This might > > > confuse you if you come from a PHP background. Usually you don't clone > > > project, apps or any kind of code for each user. You h
Re: A little help with an idea
Hey Daniel, Thanks for the reply. ... Duh! I don't know why I didn't think of that. There are so many foreign aspects of this to me (yes I come from a mod_perl, php background). I can give some more information to hopefully help me grasp this just that bit more. Basically I am creating my own custom blog site for me and a few of my friends. We have wanted our own for a while, but I also have been wanting a project to work on so I don't want to use an already created one (I have a few ideas of my own that I haven't seen in others that I want to attempt). I started it in PHP, but then noticed django and decided to try a new approach to the whole thing. So basically when I roll it out, the website would have no blogs on it, just a front page welcoming me and possibly displaying some statistics or news on it and allowing register/login. So if I were the first to create an account, I would gain access to www.mysite.com/bbeaudreault or whatever and the corresponding apps therein. If my friend registered they would get the same, www.mysite.com/friend1 The kicker is I want them to be able to completely customize the look of their blog. From positioning of the different modules (like recent posts, calendar, etc being moved from left to right to top) to color scheme, to images on it, and of course disabling certain modules (if they don't want a calendar). Sure this may be more complicated than a blog has to be, but these will be added over time and will present a nice little project for myself in adding them as I go. I guess now that I think of it more (if I am hopefully gaining a better grasp), when a new user is created I would have to automate an adding of a new url to the urls.py file. And I could probably store the resulting CSS from moving modules around, as well as flags for enabled/disabled modules in the DB for each user as well. Does this sound more in line with django's design philosophy? Oh, and yea I went through the tutorial, and it is great for the simple website kinda thing. I am just having a hard time extrapolating that to what I have in mind for this site (explained above) Thanks again, Bryan On Jul 3, 3:33 am, Daniel Hepper <[EMAIL PROTECTED]> wrote: > Hi Bryan, > > maybe I don't quite get what you are trying to do. > > URLs likewww.mysite.com/Foo/don't relate to filesystem paths > (like /home/django/Foo). They are mapped to python functions. This might > confuse you if you come from a PHP background. Usually you don't clone > project, apps or any kind of code for each user. You have one project > which consists of several apps, the information for each user is taken > from the database. > > Have you gone through the > tutorial?http://www.djangoproject.com/documentation/tutorial01/ > > Maybe you can explain what kind of site you have in mind if you really > think you have to clone apps or projects. > > Regards, > Daniel > > Am Mittwoch, den 02.07.2008, 21:42 -0700 schrieb bbeaudreault: > > > Hello all, > > > I just recently started playing around with django, and I am > > interested in using it to create a site I have in mind. I would > > appreciate any help in understanding if I have wrapped my head around > > the idea of projects and apps properly. > > > Basically, the site would have a main page that displays generic info > > from the DB and allows uers to login/register. > > > When a new user registers, it would create a new subfolder of the > > domain, which would be a clone of some django app/project (the part I > > dont get). > > > So, if I understand this correctly (and I probably don't :) ), I would > > have the following: > > > /home/django/website (would contain the basic info from the DB, > > registering/logging in, etc) > > /home/django/default (would contain a bunch of apps for the various > > functions a user would have access to) > > > So let's say the user "Foo" registers .. I would clone the default > > project to > > > /home/django/Foo > > > so the person would be able to access their specific site > > atwww.mysite.com/Foo/. > > > Now hopefully you understand where I am going with this, whether or > > not I have it correctly. Now, the other way I thought this might > > happen is like this, with 1 parent project and a bunch of apps and sub- > > apps that are all cloned instead of separate projects > > > /home/django/mysite (the default site, would contain such apps as > > "login" or whatever) > > /home/django/mysite/default (an app inside mysite project, containing > > various sub-apps?) > > /home/django/mysite/Foo (the default app was cloned to a new app named > > after the user) > > > Now, I am having a hard time figuring out which wa
A little help with an idea
Hello all, I just recently started playing around with django, and I am interested in using it to create a site I have in mind. I would appreciate any help in understanding if I have wrapped my head around the idea of projects and apps properly. Basically, the site would have a main page that displays generic info from the DB and allows uers to login/register. When a new user registers, it would create a new subfolder of the domain, which would be a clone of some django app/project (the part I dont get). So, if I understand this correctly (and I probably don't :) ), I would have the following: /home/django/website (would contain the basic info from the DB, registering/logging in, etc) /home/django/default (would contain a bunch of apps for the various functions a user would have access to) So let's say the user "Foo" registers .. I would clone the default project to /home/django/Foo so the person would be able to access their specific site at www.mysite.com/Foo/. Now hopefully you understand where I am going with this, whether or not I have it correctly. Now, the other way I thought this might happen is like this, with 1 parent project and a bunch of apps and sub- apps that are all cloned instead of separate projects /home/django/mysite (the default site, would contain such apps as "login" or whatever) /home/django/mysite/default (an app inside mysite project, containing various sub-apps?) /home/django/mysite/Foo (the default app was cloned to a new app named after the user) Now, I am having a hard time figuring out which way is the right way, or if it is even possible to have "sub-apps" ... Should I be working with separate projects here, or separate apps within 1 parent project. The actual cloning process is probably a problem for another day, but I am really just looking for some guidance or information as to which of these methods is possible/preferred. Thanks, and if I haven't explained myself properly please feel free to ask for clarification. Like I said, I am still trying to grok the whole thing. -Bryan --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
