The site I am building includes a homepage composed of panels of summarised tabular data from applications within the Django project.
What is the recommended way of building these types of pages. In other MVC style frameworks this is usually handled by each application providing a summary view, each of these views is rendered into the panels to compose the page.
This makes a lot of sense as each sub view can then be cached individually, logic related to the particular summary is contained within the application and better follows the DRY mantra.
Is there general consensus on this?
Write template tags for each section, and assemble them in the appropriate template.
Related
My friend with very little coding experience began making a business site and passed it on to me. Currently, it is mostly static html and css files but I want to take what he has and build on it using Django because I will be adding features like user login/auth and checkout. I was wondering what the best thing to do with all these html and css files are and how I might go about fitting it to Django framework.
All of the content on these pages will be static but I could imagine in the future once I add a login, the header might be different to show whether or not a user is logged in. Would I need to make separate apps for each page, include them all in one app, or just put them all in the static folder?
Would I need to make separate apps for each page
Assuming you are referring to django apps. Then No, you do not need to create a separate application for each page. django apps are a way to organize individual pieces of your projects.
To gain the most out of django, I would suggest looking into the Django Template Engine to improve the html (blocks, include and extend etc) and make it more readable and future proof ( urls, media, forms)
just put them all in the static folder?
I'm not sure you'd be able to get away with it being in the static folder, Static files in django are used for CSS and Media files such as images, videos etc. To render a template in django you need use render() or TemplateView
I hope this helps clear up some of your doubts.
Django is a Model-View-Template (MVT) framework where you create templates (HTML files) and use Jinja syntax there to display the data passed from Django views. You don't need to create apps for each page, instead, you can define functions in an app's views.py file and then reference that view from the corresponding path (URL) from the urls.py file.
You can create a main HTML template that will be extended by each sub-page. And applying your logic to your main template's header (i.e. if/else) in the main template will affect your all pages.
My recommendation is that you should first study the Django docs carefully and understand at least it's basics before starting the migration of the HTML site to Django. Django has one of the best documentation available for software on the Internet and you should be grasping the basics very quickly if you have a little programming background.
Suppose you are building a Google website. (ok big dream)
Google has web search/youtube/email/news/etc ..
For this site, I'd like to structure my django directory like
Google/
search
youtube
email
news
and so on.
How do I structure such a site?
Create an app for each even though I'm not expecting to publish any of the category as an app?
Where would a common stuff (such as user model, utility modules, decorators..) would go, create a common_app?
Applications are reusable components for a django project that revolve around a central purpose. Applications don't need to map directly to your url structure of the website. While there is a standard structure for a django application to tie in with some of the management commands, such as tests.py, models.py, static files at /static/ you don't need to have any of it to be an application. For example, South is a popular django application used to provide database migrations. It adds a few management commands to manage.py.
When you are adding functionality and it doesn't map directly to the purpose of the application, just create a new one. So instead of thinking of it a a common_app, think about what the purpose of the application would be and how it might be utilized by your other applications.
In my projects, I tend to create a base application to handle the base template and static assets that are used in the base template. I'll create an accounts application to handle the user model and implement things like password reset. To deal with global notifications from any part of my site, I'll create an alerts application. The list can go on for a lot of the common functionality, but it's grouped in a way that revolves around a function and written as if it would be distributed.
So, in your specific case, you'll likely have at least an application for each of the domains such as search, youtube, email, and news, but also an application for each common component you might want to use across your core domains.
I am almost done developing a Django project (with a few pluggable apps).
I want to offer this project as a SaaS (something like basecamp).
i.e: project1.mysaas.com , project2.mysaas.com etc
I seek your expertise in showing me the path.
Ways I have thought of are:
1 use Sites to define site specific settings.py
2 a middleware to detect request then set settings accordingly
3 create Django project (taking in pluggable apps) for each site
Thanks.
btw, i am a total newbie.
Your requirements aren't at all clear but I'll assume you aren't doing anything tricky and also assume your "project1", "project2" are customer names which won't need any special branding.
First, about your ideas:
You probably won't need to use the sites framework unless each site is branded differently. The site framework works well doing what it was designed to do, which is present different views of a common set of data.
This would work but probably is not the best approach IMO.
This is unmanageable.
Now, this is a really hard topic because there are so many issues. A decent place to start reading is the High Scalability Blog and especially relevant for you would be the post on 37signals Architecture.
Finally, here's what I am doing in a small SaaS app (that doesn't need extreme scalability):
Use the sites framework (because user pages will be branded by the partner/reseller and each partner has a unique login page)
Use mod_wsgi to minimize resource usage from all the Django instances.
Instead of middleware I put a common code at the top of every view that identifies the company of the user. I need this for logic in the views which is why I don't think it's useful in middleware.
I'm not familiar with django
conventions at all so if you do
provide advice could you be specific
Considering my homepage would contain components of articles:
In Zend, in my IndexController I would create models and populate the view with articles and data. What's a convention/structure I could use for the homepage view ( should I create a separate directory for home, dump a view.html file in it? or do I create a sub-application? ), how would you set your django structure up to accommodate this?
The basic component of a Django project is the application. Each app contains models, views, templates, template tags, and filters relevant to its portion of the project. The index view imports/uses resources from other apps to get its work done. Think of the homepage as parts brought into a whole, and put each independent part in its own application.
Plone has a beautiful search box with a "Google suggest" like functionality for its site. It even indexes uploaded documents like PDFs. Does anyone know of a module that can provide this kind of functionality in a Django site?
Plone implements it's LiveSearch feature by maintaining a separate metadata table of indexed attributes (fields such as last modified, creator, title are copied from the content objects into this table). Content objects then send ObjectAdded/ObjectModified/ObjectRemoved events, and an event subscriber listens for these events and is responsible for updating the metadata table (in Django events are named signals). Then there is a Browser View exposed at a fixed URL that searches the metadata and returns the appropriate LiveSearch HTML, and finally each HTML page is sent the appropriate JavaScript to handle the autocomplete AJAX functionality to query this view and slot the resulting HTML results into the DOM.
If you want your LiveSearch to query multiple Models/Content Types, you are likely going to need to send your own events and have a subscriber handle them appropriately. This isn't necessary for a smaller data sets or lower traffic sites, where the performance penalty for doing multiple queries for a single search isn't a concern (or you only want to search a single content type) and you can just do several queries from your View.
As for the JavaScript side, you can roll-your-own or use an existing JavaScript library. This is usually called autocomplete in the JS library. There is YUI autocomplete and Scriptaculous autocomplete for starters, and likely lots more JavaScript autocomplete implementations out there. Plone uses KSS for it's JavaScript library, the KSS livesearch plugin is a good place to start if looking for example code to pluck from.
http://pypi.python.org/pypi/kss.plugin.livesearch
And a tutorial on using KSS with Django:
http://kssproject.org/docs/tutorial/kss-in-django-with-kss-django-application
KSS is quite nice since it cleanly separates behaviour from content on the client side (without needing to write JavaScript), but Scriptaculous is conceptually a little simpler and has somewhat better documentation (http://github.com/madrobby/scriptaculous/wikis/ajax-autocompleter).