Re: Django structure

[Raphael Michel]

Hi,

I'll leave it to others to give recommendations on how you SHOULD
organizer your project. However, I can help you with the technical
question.

Am Sun, 8 Mar 2015 11:53:09 -0700 (PDT)
schrieb Gabriel Klein :
> My question is how to shared models across apps? 

You can use models across apps without any problems, just as you would
inside the same app:

from otherapp.models import MyModel

Raphael

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/20150308202624.6e3ae839%40kvothe.
For more options, visit https://groups.google.com/d/optout.


pgpu4C2cwPdAy.pgp
Description: Digitale Signatur von OpenPGP

Re: Django structure

[Gabriel Klein]

Thank you Ilya,

What you said make a lot of senses. 

On Sunday, March 8, 2015 at 10:36:27 PM UTC-3, Ilya Kazakevich wrote:
>
> There are 2 types of Apps in Django: 
> 1) reusable one with clear, documented interface
> 2) not reusable one, because it depends on current project heavily.
>
> Ideally, project consists of several reusable-apps, and project-specific 
> data is stored in project-specific places like URLConf or filesystem 
> templates.
> But in real life, project may have one or more non-reusable app tied to 
> this project heavily. If you have app with specific business-logic you do 
> not want to share it. If you have app with generic logic (forum, shop, 
> email system, template engine, orm system, new field type, a pack of tags 
> etc) -- you need to make it shareable. 
>
> It is like modules in python: you have reusable packages and modules, but 
> you almost always have "yourfile.py" script which is not reusable. But you 
> should do your best to make this file as small as possible by making most 
> of your code reusable and moving it to sharable packages and modules.
>
> Actually, this is not only about Python: in OSes you have execution binary 
> and .so files (if you are *nix user) or .exe file and .dll files (if you 
> are windows user).
> .so/.dlls are reusable, but .exe (or executable) is not. 
>
> I think you should start with 4 apps:
> 1) user management
> 2) business logic (models and other staff used both in front-end and 
> back-end)
> 3) front-end with front-end specific code
> 4) backend with back-end specific.
>
> Back and front may depend on business, but not on each other, and business 
> does not depend on anything.
> You should be able to throw backend away, and totaly rewrite it, and be 
> sure front-end and business logic is not affected.
> Speaking in MVC term here, your business is Model, and Front and Back are 
> both views. You may even need to create some new view, like portal which is 
> not frontend nor backend,
>
> You then try to fetch some "generic" parts from you apps. For example you 
> may find that you use views/templates/tags to display some business data in 
> fancy way. You may move it to business-logic part, to share between 
> front-end and back-end.
> Or you may find that you just created, say, email blast engine, or report 
> engine, that can be used even with out of your business logic, in totaly 
> different project! You then move it to separate app, and make it public to 
> reuse in other projects.
>
> Splitting code into modules (units, packages) is one of the hardiest 
> things in software architecutre. It is ok to refactor existing projects 
> changing modules structure, because you never know if your layout is good 
> until you try to support such project. 
>
> Ilya.
>
> On Sunday, March 8, 2015 at 9:56:51 PM UTC+3, Gabriel Klein wrote:
>>
>> Hi there,
>>
>> I'm going to start a big project using Django.
>> It will have 3 main sections: 
>>
>> - A "Frontend" section:
>> Where the user will consult the data.
>> - A "Backend" section:
>> Where the ETL and Admins will organize the data
>> - A User Management section:
>> Where I'll manage user permission, Oauth for my APIs
>>
>> I'm aware that Django recommend to break down your project into a 
>> multitude of apps with a very small scope.
>> While my User Management section should be simple enough to be on his own 
>> app my two other sections "Frontend" and "Backend" come with a fairly 
>> complex snowflake schema (about 15 tables) and sometime with cross 
>> dependencies between apps. They also come with complex business logic that 
>> can be break down to smaller apps.
>>
>> My question is how to shared models across apps? 
>> I was thinking creating a app only to cary my complex models?
>>
>> This app can be now reuse within smaller app doing backend or fronted 
>> jobs.
>>
>> Any advice will be welcome.
>>
>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/4ec5e172-352d-4854-8d19-d0eafff7ad24%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django structure

[Ilya Kazakevich]

There are 2 types of Apps in Django: 
1) reusable one with clear, documented interface
2) not reusable one, because it depends on current project heavily.

Ideally, project consists of several reusable-apps, and project-specific 
data is stored in project-specific places like URLConf or filesystem 
templates.
But in real life, project may have one or more non-reusable app tied to 
this project heavily. If you have app with specific business-logic you do 
not want to share it. If you have app with generic logic (forum, shop, 
email system, template engine, orm system, new field type, a pack of tags 
etc) -- you need to make it shareable. 

It is like modules in python: you have reusable packages and modules, but 
you almost always have "yourfile.py" script which is not reusable. But you 
should do your best to make this file as small as possible by making most 
of your code reusable and moving it to sharable packages and modules.

Actually, this is not only about Python: in OSes you have execution binary 
and .so files (if you are *nix user) or .exe file and .dll files (if you 
are windows user).
.so/.dlls are reusable, but .exe (or executable) is not. 

I think you should start with 4 apps:
1) user management
2) business logic (models and other staff used both in front-end and 
back-end)
3) front-end with front-end specific code
4) backend with back-end specific.

Back and front may depend on business, but not on each other, and business 
does not depend on anything.
You should be able to throw backend away, and totaly rewrite it, and be 
sure front-end and business logic is not affected.
Speaking in MVC term here, your business is Model, and Front and Back are 
both views. You may even need to create some new view, like portal which is 
not frontend nor backend,

You then try to fetch some "generic" parts from you apps. For example you 
may find that you use views/templates/tags to display some business data in 
fancy way. You may move it to business-logic part, to share between 
front-end and back-end.
Or you may find that you just created, say, email blast engine, or report 
engine, that can be used even with out of your business logic, in totaly 
different project! You then move it to separate app, and make it public to 
reuse in other projects.

Splitting code into modules (units, packages) is one of the hardiest things 
in software architecutre. It is ok to refactor existing projects changing 
modules structure, because you never know if your layout is good until you 
try to support such project. 

Ilya.

On Sunday, March 8, 2015 at 9:56:51 PM UTC+3, Gabriel Klein wrote:
>
> Hi there,
>
> I'm going to start a big project using Django.
> It will have 3 main sections: 
>
> - A "Frontend" section:
> Where the user will consult the data.
> - A "Backend" section:
> Where the ETL and Admins will organize the data
> - A User Management section:
> Where I'll manage user permission, Oauth for my APIs
>
> I'm aware that Django recommend to break down your project into a 
> multitude of apps with a very small scope.
> While my User Management section should be simple enough to be on his own 
> app my two other sections "Frontend" and "Backend" come with a fairly 
> complex snowflake schema (about 15 tables) and sometime with cross 
> dependencies between apps. They also come with complex business logic that 
> can be break down to smaller apps.
>
> My question is how to shared models across apps? 
> I was thinking creating a app only to cary my complex models?
>
> This app can be now reuse within smaller app doing backend or fronted jobs.
>
> Any advice will be welcome.
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/1e837f28-285e-4754-bf5c-2b3ddb77e614%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Django structure

[Gabriel Klein]

Hi there,

I'm going to start a big project using Django.
It will have 3 main sections: 

- A "Frontend" section:
Where the user will consult the data.
- A "Backend" section:
Where the ETL and Admins will organize the data
- A User Management section:
Where I'll manage user permission, Oauth for my APIs

I'm aware that Django recommend to break down your project into a multitude 
of apps with a very small scope.
While my User Management section should be simple enough to be on his own 
app my two other sections "Frontend" and "Backend" come with a fairly 
complex snowflake schema (about 15 tables) and sometime with cross 
dependencies between apps. They also come with complex business logic that 
can be break down to smaller apps.

My question is how to shared models across apps? 
I was thinking creating a app only to cary my complex models?

This app can be now reuse within smaller app doing backend or fronted jobs.

Any advice will be welcome.


-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/c4e2fc52-0879-4216-bb57-0670a8da5636%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: django structure and basic flow

[Daniel Hepper]

> I am confused that different tutorial gives different method of doing
> things. I want to know how to setup basic cms site,
> what folder should I create, sometime people create apps, sometimes
> they don't.

There are different ways to structure your project, but if you want to
use the database you have to create at least one app which you add to
INSTALLED_APPS in the settings. You can split the functionality in
multiple apps for easier reuse (often called reusable apps), but
keeping it in one app is simpler in the beginning.

> How do I put this in order?
> 1.url
> 2. view
> 3.model
> 4. template
> 5. admin
> 6. settings

I suggest to closely follow the official tutorial on djangoproject.com
and to use the "django-admin.py startproject" and "python manage.py
startapp" commands. They will create an initial structure to get you
started.

A word of caution: the recommended project structure changes from the
current Django 1.3 to the upcoming Django 1.4. Make sure you look at
the right version of the documentation.

-- Daniel

-- 
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.

django structure and basic flow

[Lewis]

I am confused that different tutorial gives different method of doing
things. I want to know how to setup basic cms site,
what folder should I create, sometime people create apps, sometimes
they don't.

How do I put this in order?
1.url
2. view
3.model
4. template
5. admin
6. settings

from the tutorial I see,
http://www.youtube.com/watch?v=8bnyOb72p_4&feature=BFa&list=PL385A53B00B8B158E&lf=plcp

Is that the way to structure the project?

is there anyone can help and guide me. just want to create people to
input on admin and output on the template?

-- 
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: Django structure and git as VCS

[Piotr Zalewa]

Thanks Brian,

It looks like it will manage the git repositories for me. It might be a
good idea, but I think I'll keep it it "custom" build. I (wishful
thinking) don't use Apache, etc.

On 10/07/10 13:56, Brian Bouterse wrote:
> Maybe not an exact answer to your question, but we do something kind of
> similar to what you are describing.  Basically, we have app authors
> (both frontend and backend) work with their app in their own repo and
> publish them into this repository .  Then
> we use Opus  to deploy them onto our
> servers since it is connected to the app repository where their apps are
> published Opus provides a self service deployment interface.  You can
> even test your deployments on our sandbox servers
> .
> 
> Brian
> 
> On Thu, Oct 7, 2010 at 8:25 AM, Piotr Zalewa  > wrote:
> 
>  Hi,
> 
> I'm working on defining the structure of an application
> It will have quite a few apps, with few of them opensourced.
> 
> I was thinking how to make it easier for people involved into the
> project.
> In essence front-end developer should work on one repository only -
> that's also goes quite nicely with app portability and would also help
> if an idea about whitelabelling the project could come to someone's
> mind.
> Other apps will be installed via pip under the virtual environment and
> will be a separate repositories in git.
> Back-end devs then will work each one on the application back-end and on
> the front-end application, to provide some changes to the functionality.
> 
> Basically:
> project - one repository
> front-end app - one repository
> apps - a repository for each one.
> 
> I'd like to implement a slightly modified V.Dressen's model of the
> workflow - in draft explained here:
> https://wiki.mozilla.org/Labs/Jetpack/FlightDeck/Code_Workflow on each
> of the repositories
> 
> Do you think it's best structure?
> And, quite important, will it not look like a mess for an "average"
> developer?
> 
> Piotr
> 
> --
> blog  http://piotr.zalewa.info
> jobs  http://builder.mozillalabs.com, http://jsfiddle.net
> twit  http://twitter.com/zalun
> 
> 
> --
> 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.
> 
> 
> 
> 
> -- 
> Brian Bouterse
> ITng Services
> 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Django users" group.
> To post to this group, send email to django-us...@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.


-- 
blog  http://piotr.zalewa.info
jobs  http://webdev.zalewa.info
twit  http://twitter.com/zalun
face  http://facebook.com/zaloon

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@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: Django structure and git as VCS

[Brian Bouterse]

Maybe not an exact answer to your question, but we do something kind of
similar to what you are describing.  Basically, we have app authors (both
frontend and backend) work with their app in their own repo and publish them
into this repository .  Then we use
Opusto deploy them onto our servers
since it is connected to the app repository
where their apps are published Opus provides a self service deployment
interface.  You can even test your deployments on our sandbox
servers
.

Brian

On Thu, Oct 7, 2010 at 8:25 AM, Piotr Zalewa  wrote:

>  Hi,
>
> I'm working on defining the structure of an application
> It will have quite a few apps, with few of them opensourced.
>
> I was thinking how to make it easier for people involved into the project.
> In essence front-end developer should work on one repository only -
> that's also goes quite nicely with app portability and would also help
> if an idea about whitelabelling the project could come to someone's mind.
> Other apps will be installed via pip under the virtual environment and
> will be a separate repositories in git.
> Back-end devs then will work each one on the application back-end and on
> the front-end application, to provide some changes to the functionality.
>
> Basically:
> project - one repository
> front-end app - one repository
> apps - a repository for each one.
>
> I'd like to implement a slightly modified V.Dressen's model of the
> workflow - in draft explained here:
> https://wiki.mozilla.org/Labs/Jetpack/FlightDeck/Code_Workflow on each
> of the repositories
>
> Do you think it's best structure?
> And, quite important, will it not look like a mess for an "average"
> developer?
>
> Piotr
>
> --
> blog  http://piotr.zalewa.info
> jobs  http://builder.mozillalabs.com, http://jsfiddle.net
> twit  http://twitter.com/zalun
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To post to this group, send email to django-us...@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.
>
>


-- 
Brian Bouterse
ITng Services

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@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.

Django structure and git as VCS

[Piotr Zalewa]

 Hi,

I'm working on defining the structure of an application
It will have quite a few apps, with few of them opensourced.

I was thinking how to make it easier for people involved into the project.
In essence front-end developer should work on one repository only -
that's also goes quite nicely with app portability and would also help
if an idea about whitelabelling the project could come to someone's mind.
Other apps will be installed via pip under the virtual environment and
will be a separate repositories in git.
Back-end devs then will work each one on the application back-end and on
the front-end application, to provide some changes to the functionality.

Basically:
project - one repository
front-end app - one repository
apps - a repository for each one.

I'd like to implement a slightly modified V.Dressen's model of the
workflow - in draft explained here:
https://wiki.mozilla.org/Labs/Jetpack/FlightDeck/Code_Workflow on each
of the repositories

Do you think it's best structure?
And, quite important, will it not look like a mess for an "average"
developer?

Piotr

-- 
blog  http://piotr.zalewa.info
jobs  http://builder.mozillalabs.com, http://jsfiddle.net
twit  http://twitter.com/zalun


-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@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: customizing django structure

[Lee Connell]

thanks karen!

On Apr 9, 12:37 pm, "Karen Tracey" <[EMAIL PROTECTED]> wrote:
> On Wed, Apr 9, 2008 at 8:44 AM, Lee Connell <[EMAIL PROTECTED]> wrote:
>
> > Hello All,
>
> > I am trying to customize django to fit into a directory structure that
> > makes sense for me and the project I am working on.  Below is how
> > django looks by default, underneath that is how I would like it.  Is
> > this possible and how? I was having such a problem trying to get
> > "python manage.py runserver --settings=lib.settings.  It would not
> > work for me. thanks!
>
> manage.py is a convenience script provided to set things up based on the
> recommended structure.  In particular it assumes settings.py is in your
> project directory.  If you want to deviate from that, then you can't use
> manage.py.  Instead (as the error message from manage.py tries to indicate)
> you could use django-admin.py and pass in the settings location.
> django-admin.py, though, doesn't automatically add your project's directory
> to the python path, so you will need to do that yourself.
>
> In short if you want to deviate from the recommended structure, you can't
> use the provided convenience script.  But it really isn't that hard to
> create your own that assumes your desired structure instead of the
> recommended one.
>
> Karen
>
>
>
> > myapp:
> >__init__.py
> >manage.py
> >urls.py
> >settings.py
>
> >myproj1:
> >__init__.py
> >models.py
> >views.py
> > ---
>
> > myapp:
> >__init__.py
> >manage.py
>
> >lib:
> >__init__.py
> >settings.py
>
> >web:
> >__init__.py
> >urls.py
>
> >templates:
> >__init__.py
> >mytmpl.html
>
> >db:
> >__init__.py
>
> >myproj1:
> >__init__.py
> >models.py
> >views.py
--~--~-~--~~~---~--~~
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: customizing django structure

[Karen Tracey]

On Wed, Apr 9, 2008 at 8:44 AM, Lee Connell <[EMAIL PROTECTED]> wrote:

>
> Hello All,
>
> I am trying to customize django to fit into a directory structure that
> makes sense for me and the project I am working on.  Below is how
> django looks by default, underneath that is how I would like it.  Is
> this possible and how? I was having such a problem trying to get
> "python manage.py runserver --settings=lib.settings.  It would not
> work for me. thanks!
>

manage.py is a convenience script provided to set things up based on the
recommended structure.  In particular it assumes settings.py is in your
project directory.  If you want to deviate from that, then you can't use
manage.py.  Instead (as the error message from manage.py tries to indicate)
you could use django-admin.py and pass in the settings location.
django-admin.py, though, doesn't automatically add your project's directory
to the python path, so you will need to do that yourself.

In short if you want to deviate from the recommended structure, you can't
use the provided convenience script.  But it really isn't that hard to
create your own that assumes your desired structure instead of the
recommended one.

Karen


>
> myapp:
>__init__.py
>manage.py
>urls.py
>settings.py
>
>myproj1:
>__init__.py
>models.py
>views.py
> ---
>
> myapp:
>__init__.py
>manage.py
>
>lib:
>__init__.py
>settings.py
>
>web:
>__init__.py
>urls.py
>
>templates:
>__init__.py
>mytmpl.html
>
>db:
>__init__.py
>
>myproj1:
>__init__.py
>models.py
>views.py
>
> >
>

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

customizing django structure

[Lee Connell]

Hello All,

I am trying to customize django to fit into a directory structure that
makes sense for me and the project I am working on.  Below is how
django looks by default, underneath that is how I would like it.  Is
this possible and how? I was having such a problem trying to get
"python manage.py runserver --settings=lib.settings.  It would not
work for me. thanks!

myapp:
__init__.py
manage.py
urls.py
settings.py

myproj1:
__init__.py
models.py
views.py
---

myapp:
__init__.py
manage.py

lib:
__init__.py
settings.py

web:
__init__.py
urls.py

templates:
__init__.py
mytmpl.html

db:
__init__.py

myproj1:
__init__.py
models.py
views.py

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---