I getting started with Django. I want to build a work_manager website with the following content:
hour calculation - enter shifts per day and can view the hours per day, week and month.
shift for each week(maybe a month too) - view table for all the schedules of the employees.
salary calculation per employee for month.
And maybe in the future more things.
For start I have this DB structures:
Now, my question is what is the recommended way to organize the project?
I searched here and find some people the recommended putting all in one app because strong relations between the models can cause problems if you split into several apps.
And some other people recommended to split it that each I can explain each app with one sentence (like I did here up).
So, what is the best practice for that? If to split so how to arrange the models?
Thank You!
it depend on you requirement.
if you want to reuse this app to some other project. then splitting is very good idea.
splitting a project in multiple app are very easy to maintain. if you want to add some more functionality to your app it will be easy for you. only draw back i see in splitting multiple app is it increase burden of importing models and other stuff.
other hand if you put every thing in one app it will also work very well. but it will be tough to maintain and scale n future.
my suggestion is to split app as many as possible.
Related
Background
I'm a personal trainer and trying to build an app that tracks whether or not my clients are working on their daily habits (and bugs them about it at a chosen time every day). I'd love to hear if any of you all have ideas on how to structure this as I'm new to both Django and coding in general.
Models
I currently have two models: Habits and Checks.
Habits represent "What are you working on improving?" and have a ForeignKey to a user.
Checks represent "Did you complete your habit today?" and have a ForeignKey to a habit.
Current status
There is a nice solution where you create all the Checks for a Habit based on it's end date, but I'm trying to structure this with an indefinite end date because, as a coach, then I can show hard data when someone isn't making progress. Though I am still willing to accept that maybe this app would work better if habits had deadlines.
I wrote a custom manage.py script that Heroku runs automatically at the same time every day, but that doesn't scale with users' individual time zones. I run it manually on my local computer.
I originally tried getting it to work with Celery but that did not go well on my Windows machine.
Should I push the script out a day or week in advance and hide the days that are in the future?
Should I avoid the script and just create a year's worth of rows and hope they don't want to track it for more than a year?
Is there a better option?
Help requested
The two issues I'm having at this point:
How can I have a Check created for each day? Is there a better way than what I've done already?
How can I make the timezone for each day relative to the user?
I've an app which is growing pretty big, doing too much thing as a single app, so I'd like to split it in 2 or 3 "sub-apps"
The problem is that there are a dozen of models which are linked to each other (foreing key, manytomanyfields, etc.)
I've read LOTS of times that apps should be self-consistent, so, are there any best practices to split a big app in several ones linked to each other?
--> how bad is importing models from other apps?
I didn't hear about a best practice solution, but here's what I would usually do, and I split apps a lot:
Step 0 - When is an app "too big"?:
An app should be an (independent) logical unit. Independent is actually misleading, of course you can have dependencies like django.conrib.auth, what you should have tho are cross dependencies. They will eventually lead to looping imports. That being said, you app can grow quite large, with is totally fine.
If you having problems organizing your code, I may remind you of the fact that every module can be build as a package. You simply split your models.py into models/__init__.py and models/LOGICAL_UNITS.py.
The only reason why you should split an app is because you can, not because you want to ;)
Step 1 - Overview
Use django_extensions' graph printing capabilities.
This should give you a good overview an might help you to find so called "communities". Groups of models that have strong cross dependencies.
Those communities usually make a pretty good app.
Step 2 - Naming:
If you cant find a name for you're new application, it probably isn't one.
I have intended to have an app. where I want to have different things having relations with each other and want to know that whether I should have them as just different models or as differnt apps. Obviously if this is student, teacher in LMS then they are necessary component of LMS while if this is Job, Professional and Company then there can be different things associated with a job , a professional can have his full profile with different features, company can have different directory listing e.t.c. like features.
So Company and professionals who are users also should be as diff. apps. and job as different app.? Will this way be fine? as Jobs app. don't always everywhere need to have professional data or employer all data other than just name. So it seems like it is more convenient to have them as diff. apps, so that it can be used somewhere else.So is that right way?
Or
As I also want this project to be flexible so will the above make it more complex? And should I just treat them as diff. models instead of diff. apps. as Company and Professional are users , for which django gives Profile features also. So is this right way?
Which way is better one?
thanks in advance.
There is no exact answer here, so it's my opinion.
It is always good to have several apps rather than one big app. Reasons:
apps becomes smaller and it's easier to maintain small pieces of code;
project structure becomes more clear, I just need to look at the file manager to see main parts of the project;
interaction between apps become explicit: easy to test and prevent unnecessary coupling.
Not every Django app should be pluggable. It's ok to have two apps that depend on each other (if you aren't going to distribute them seperately). It's like having two dependent functions: nothing is wrong with it.
I work for a university, and in the past year we finally broke away from our static HTML site of several thousand pages and moved to a Drupal site. This obviously entails massive amounts of data entry.
What if you're already using a CMS and are switching to another one that better suits your needs? How do you minimize the mountain of data entry during such a huge change? Are there tools built for this, or some best practices one should follow?
The Migrate module for Drupal would provide a big help. The Economist.com data migration to Drupal will give you an overview of the process.
The video from the Migration: not just for the birds presentation at Drupalcon DC 2009 is probably somewhat out-of-date, but also gives a good introduction.
Expect to have to both pre-process and post-process your data manually, whatever happens. Accept early on that your data is likely to be in a worse state than you think it is: fields will be misused; record-to-record references (foreign keys) might not be implemented properly, or at all; content is likely to need weeding and occasionally to be just bad or incorrect.
Check your database encoding. Older databases won't be in Unicode encodings, and get grumpy if you have to export data dumps and import them elsewhere. Even then, assume that there'll be some wacky nonprintable characters in your data: programs like Word seem to somehow inject them everywhere, and I've seen... codepoints... you people wouldn't believe. Consider sweeping your data before you even start (or even sweeping a database dump) for these characters. Decide whether or not to junk them or try to convert them in the case of e.g. Word "smart" punctuation characters.
It's very difficult to create explicit data structures from implied one. If your incoming data has a separate date field, you can map that to a date field; if it has a date as part of a big lump of HTML, even if that date is in a tag with an id attribute, simple scripting won't work. You could use offline scripting with BeautifulSoup or (if your HTML's a bit nicer) the faster lxml to pre-process your data set, extract those implicit fields, and save them into an implicit format. Consider creating an intermediate database where these revisions are going to go.
The Migrate module is excellent, but to get really good data fidelity and play more clever tricks you might need to learn about its hook system (Drupal's terminology for functions following a particular naming scheme) and the basics of writing a module to put these hooks in (a module is broadly just a PHP file where all the functions begin with the same text, the name of the module file.)
All imported content should be flagged for at least a cursory check. You can do this by importing it with status=0 i.e. unpublished, and then create a view with the Views module to go through the content and open it in other tabs for checking. Views Bulk Operations lets you have a set of checkboxes alongside your view items, so you could approve many nodes at once.
Expect to run and re-run and re-run the import, fixing new things every time. Check ten, or twenty items, as early as possible. If there are any problems, check ten or twenty more. Fix and repeat the import.
Gauge how long a single import run is likely to take. Be pessimistic: we had an import we expected to take ten hours encounter exponential slowdown when we introduced the full data set; until we finally fixed some slow queries, it was projected to take two weeks.
If in doubt, or if you think the technical aspects of the above are just going to take more time than the work itself, then just hire temps to do the data. But you still need decent quality controls, as early as possible during their work. Drupal developers are also for hire: try your country's relevant IRC channel, or post a note in a relevant groups.drupal.org group. They're more expensive than temps but they usually write better PHP...! Consider hiring an agency too: that's a shameless plug, as I work for one, but sometimes it's best to get experts in for these specific jobs.
Really good imports are always hard, harder than you expect. Don't let it get you down!
Migrate + table wizard (and schema + views) is the way to go. With table wizard you can expose any table to drupal and map fields accordingly using migrate.
Look here for a detailed walktrough:
http://www.lullabot.com/articles/drupal-data-imports-migrate-and-table-wizard
You'll want to have an access to existing data from django. This helps me a lot with migrating: http://docs.djangoproject.com/en/1.2/howto/legacy-databases/ . With correct model definitions you'll have full django power including the admin. In fact, I'm using django just as admin backend for several legacy php projects - django's admin can easily outachieve a lot of custom hand-written admin scripts.
Authorization should remain the same. Users should be able to login with their credentials but it is hard to write a migration script for auth data because password hashing schemas may be different and there is no way to convert between them without knowing plain passwords. Django provides a way to support different sources of auth so you can write Drupal auth backend: http://docs.djangoproject.com/en/1.2/topics/auth/#writing-an-authentication-backend
There is no need to do the full rewrite. If some parts are working fine they can still be powered by Drupal. New code can written using Django with same UI. Routing between old and new parts can be performed by web server url rewriting. Both django and drupal parts can be powered by the same DB.
I an building a kind of social network (think of it as last.fm, but gaming related). I want to have a homepage which will feature:
site news, announcements etc. in the main part
featured items in the right sidebar
player of the week in the right sidebar
I am trying to think of a way not to be hand coding these every time they need to change, which I understand is terrible design. However, I can't think of much.
I realize I need some kind of simple blog engine for the site news and such, but what about the featured content in the sidebar? Should there be a table in the database containing the featured items of the week? I think that will pollute my models.py with unnecessary stuff.
Please share any ideas.
There are lots of ready-to-go solutions ie.
Pinax - great package of reusable apps,
Django CMS - not so great, but could be useful.
Django's static pages - for basic stuff :)
I'd try pinax first - it has all of what you need.
As for your featured stuff - it all depends on what exactly you need, on your content.
If you need something special you'd probably finish up writing this stuff by yourself,
or overriding parts of ready-to-go solutions.
Featured Items and Player of the Week will depend (usually) on your project specific Player / Item models. It shouldn't take long to program these small pieces.
As far as news, there are quite a few different solutions out there. Here's one that I've created (because I can't think of a better one off hand):
http://github.com/monokrome/django-news/
The best bet with django is to find the smaller apps you might be able to leverage, and then write your own project with your custom wants/needs in mind.