My app does roughly the same thing and is organised as thus:
- each module has its own app (invoices, emails, stuff_we_sell...).
The app contains the models with most of the business logic and the
managing views (for our own use)
- a separate client access module that wraps around some of the
managing views, sometimes using simpler templates, and always doing
the extra security checks ("can this client access this particular
invoice").
It's roughly 30k lines of python + templates and the existing
framework seems adequate to handle this use case. One pattern I've
used a lot is simply doing my security checks in the client app then
calling the view from the business app.
One thing that I think is worth mentionning is that the generic CRUD
is common to the business and client sides. I just run per-instance
security checks based on who's connected (permissions for business
users, and "ownership" for client users). On top of that a custom
login middleware forbids client users from accessing most of the URL
space (they're mostly sandboxed into the client module's urls).
In short, I think this thread should be in django-users :)
Hope that helps,
Philippe
On Jun 21, 7:11 am, M Rotch <planetra...@gmail.com> wrote:
> I'm sorry. My example is a bit misleading (actually a confusing mess),
> but the reason for splitting off models into separate was just my idea
> of a means to an end but probably is a bad solution. I should have
> started with my business problem instead of mingling my solution into
> the explanation.
>
> Let me start again in a less convoluted manor.
>
> The software I started on this month has businesses (which pay to use
> the software) and it has clients (which are clients of those
> businesses). The business has one interface athttp://manage.example.com
> and the client has a whole different interface (completely different
> design and different functionality) athttp://clients.example.com.
> Let's say you have a model ModelXYZ. ModelXYZ instances belong to a
> client of a business. The client can create, read, update, or delete
> their ModelXYZ instances. The business who owns the client can also
> CRUD their client's ModelXYZ instances.
>
> The problem is that the views and templates a business is using while
> editing their client's ModelXYZ instances are completely different
> from the views and templates that are used by the client to edit the
> same ModelXYZ instance. The logical thing for me seemed to create a
> separate app for businesses and one for clients, but I ran into 2
> things that made me reconsider: #1) For each set of related models I
> have to have 2-3 apps (1 for models, 1 for business access, and 1 for
> client access (unless I decide to put business access into the same
> app as the models which leads to just two apps)) and #2) Naming
> conventions are a mess this way. If I have a ModelXYZ (and a few other
> related models), I might have an app called projects/apps/xzy (which
> contains models) and two sub-folders of this app; one called project/
> apps/xyz/client/, and one called project/apps/xyz/business. Perhaps
> this isn't so bad. What's your thought. Am I over thinking this, or do
> you think my solution makes any more sense than after reading my
> previous post?
>
> Thanks
> Mark
>
> On Jun 20, 9:52 pm, Russell Keith-Magee <russ...@keith-magee.com>
> wrote:
>
> > On Mon, Jun 21, 2010 at 10:07 AM, M Rotch <planetra...@gmail.com> wrote:
> > > I just have a few practical ideas that I want to lay out, pertaining
> > > to loose coupling.
>
> > > I've worked with Django for a while and one of the things I love is
> > > that you can do things your own way, instead of having the
> > > constricting requirements that "convention over configuration" brings
> > > (like in Rails). Django does enlists a few "convention" requirements
> > > if you want to make things easy and automatic. This is fine unless you
> > > need to do it the non-automatic way (larger applications bring this
> > > need up).
>
> > > There are a few areas where this comes up but I'll only touch on the
> > > most obvious:
>
> > > When you're building an application that has many related data models
> > > and different types of users that have many views which access data
> > > from multiple apps, it becomes really easy to forget where you put
> > > certain models and seems disorganized.
>
> > > Splitting things up into more and more apps doesn't fix the problem,
> > > because having apps that only serve as a host for views and apps that
> > > only serve as a host for models makes a mess in larger applications.
> > > What does fix the problem is keeping a taxonomy that makes sense for
> > > your business; data models based on where they belong and views based
> > > on who/what they're for (e.g. data models in ``project/data/company/
> > > models.py``, views that access those models in ``project/views/clients/
> > > tickets.py`` and ``project/views/company/dashboard.py``).
>
> > > My proposal (This solution could be way off but I'm really wanting to
> > > hear what others think about the problem in general):
>
> > My immediate reaction is that this is a solution to a problem that
> > shouldn't exist in practice. If you're in a situation where you have
> > an need to split up your models file for organization purposes, your
> > app is probably getting too large, and you should be considering how
> > to split your application into smaller independent parts. If splitting
> > your project into smaller apps doesn't seem like a feasible solution,
> > then I strongly suspect that you need to look closer at how you are
> > modelling the data in your project.
>
> > In all the projects that I curate, I very rarely reach a situation
> > where I've had a desire to split models.py into smaller files; the
> > only exceptions are applications that I know I *should* refactor into
> > different apps, but haven't got around to it yet.
>
> > I haven't seen your project or code, though, so it is possible that
> > this just a limitation of my own experience.
>
> > > Create a way to manually register a model instead of simply scanning
> > > for models.py in each installed app. The current ``"myapp.MyModel"``
> > > way of accessing models for foreign keys could be replaced with model
> > > naming much the same way that views can be named. Being able to name
> > > your models and accessing them by name seems better anyways because
> > > then your class name could change but the models "name" would remain
> > > the same, making code changes easier.
>
> > The first alarm bell that goes off here is backwards compatibility. We
> > can't arbitrarily change the way we refer to models; if we're going to
> > add new features, those features need to be consistent and compatible
> > with existing features.
>
> > The second alarm bell is the potential for namespacing issues. You
> > seem to be suggesting that the registered name of a model should be
> > completely divorced from the class name (and presumably, the module
> > path). One of the advantages to tying the namespacing structure to the
> > app structure is that you largely avoid namespacing collisions. If you
> > separate these concerns, you suddenly have a bunch of new namespacing
> > problems (e.g., two separate apps that register "user.profile" as a
> > model name). This doesn't fill me with confidence.
>
> > It's also worth nothing that there is some potential overlap with one
> > of the GSoC projects that is currently underway. I don't expect that
> > the App Loading GSoC project will actually be implementing any of the
> > features you are describing here, but they are playing in very similar
> > sandboxes, so if you were to start writing code in this area, I would
> > expect you to be stepping on toes. This isn't necessarily a reason to
> > avoid working on this, but it is worth keeping under consideration.
>
> > In summary -- I'm sorry to say that my reaction to this proposal is
> > "meh". In my experience, I haven't experienced this problem as
> > anything other than a reflection of a need for internal refactoring;
> > and the proposal you have made (so far) has a lot of loose ends that
> > need fleshing out.
>
> > Yours,
> > Russ Magee %-)
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
