I'am a green hands in web backend and recently I have a problem about designing system-message module in my django project.
Consideration of expansibility, I don't store indexes using ForeignKey or concrete fields of exact object because it's difficult to predict what messages will carry. Then I can only make it in a easy way. I add four fields:receiver_id, time,readflag and content(str). But content is text/html type and it's inflexible to modify in frontend.
Thus I wanner see the common way to solve this problem.
Sincere thanks!
Related
I need to create a one-to-one relationship between a Game and a Site - each game happens in one site. In my database, site is an attribute of the Game object which points to a Site object.
I couldn't find much on the internet about this, these are my ideas:
GET /game/<game_id>/site
Gets a game's site, hiding the site id.
POST /game/<game_id>/site
Creates a game's site, this is only used once when creating the game.
PUT /game/<game_id>/site
Updates a game's site
DELETE /game/<game_id>/site
Deletes a game's site.
But what if someone wants to get a list of all the sites? Should I add a /sites URI and have the get method for the Site object detect whether a game_id has been passed in? Should I also let people access a site by /sites/<site_id> Or should I let the client populate their own list of sites by iterating over all games? Finally, I usually have an 'href' attribute for each object which is a link back to itself. If I went with the above design (incl. the /sites/ URI), do I link to /game/<game_id>/site or /sites/<site_id>? Should there be two places to access the same info?
Am I on the right track? Or is there a better way to model one-to-one relationships in REST?
If it matters, I'm using Flask-RESTful to make my APIs.
Your ideas make a lot of sense.
The big distinction is whether or not a site can exist independently of a game. It sounds like it can. For example, two games may point to the same site.
As far as I understand with RESTful API design, there isn't a problem with exposing the same site resource through both /game/<game_id>/site and through /sites/<side_id>. But REST encourages you to link data through hypermedia.
Exposing the site in two different places could complicate things, since you'd then expect to be able to interact with site objects through both of those URLs.
My recommendation to keep your structure explicit and simple would be:
Have a collection of site resources at /sites
Expose site resources at /site/<site_id>
Use a link object from a game to a site. See Thoughts on RESTful API design by Geert Jansen.
Following the link object design, your game resource representation would include something like this:
{
"game_id": 10,
...,
"link": {
rel: resource/site
href: /api/sites/14
}
}
Without more design work, this would mean you'll make a second call to get the site's information. Every design has its compromises :)
Maybe this isn't the correct place to ask, but I asked this question on Joomla forums and did not get any answers. If someone can help me or at least point me in the right direction, I would really appreciate.
My question is: In a Joomla 2.5 website, I want to create two different kinds of forms for registering users. Maybe "registering" isn't the correct term. I want to create something like a very simple database which will hold records for two kinds of users:
- one which will be interested in working in projects, so in this case the form will have more fields and specific details to fill
- one which will be interested only in receiving newsletters from the site, and in this case only basic contact information will be required.
I did some research and found an extension named AcyMailing which can handle the newsletters for example, but I need to have all my potential users registered as Joomla users. I would like to avoid that if possible. If not, how can I differentiate the two kinds of users on registration, so the visitor can choose which option he wants and in this case, add more information to the registering process, if possible.
I'm not very experienced with Joomla, but since the site in question is already implemented using it, I don't have much choice.
Thanks in advance!
Chronoforms. Most definitely here would be a great use for their AWESOME free component. Your forms can work as registration forms (should you desire that); or can also just be free standing forms that log the information filled out on them to your database which you can later use however you would like (i.e. compiling a mailing list or something of that sort).
The form wizard makes it almost bullet proof, then you can have a form for 1 type of user to fill out, and a form for a different user build different ways.
That will get you the data - in order to mass mail those people you'll need a way to extract their emails out of the database (or find an email component that will let you email based on certain fields in the database or what have you); but it's totally possible and would be easily done I think with 1 simple mySQL query on your database table created by chronoforms.
In terms of something that will solve your issue quickly and get you the info you're looking for in two separate ways - chronoforms will do that exactly.
I have a set of top-level configuration data fields that I want to be able to set within django admin for each deployment of my django app. I only want one set of these.
Example fields: site_logo, contact_person, address, facebook_url, twitter_url
The problem is that Django Admin is geared towards tables (lists) of models, so its not a good fit for this type of singular configuration model. I really only want one of these models to exist for the whole site, and to be able to click into it from admin and edit the various fields.
It seems i've come across a 3rd party app in the past to accomplish this but can't find it anywhere. Part of the problem is I'm finding it difficult to find the right words to google. Any ideas?
It looks like django-values will do what you're looking for.
Other possible contenders:
http://github.com/sciyoshi/django-dbsettings (doesn't look maintained)
http://github.com/jqb/django-settings
Have a look at django-livesettings it sounds like it might fit.
Not that i have used it, but i have heard good things about django-constance.
And there are even some more options listed in the Configuration-Grid on Django Packages.
I'm going to be honest: this is a question I asked on the Django-Users mailinglist last week. Since I didn't get any replies there yet, I'm reposting it on Stack Overflow in the hope that it gets more attention here.
I want to create an app that makes it easy to do user friendly,
multiple / mass file upload in your own apps. With user friendly I
mean upload like Gmail, Flickr, ... where the user can select multiple
files at once in the browse file dialog. The files are then uploaded
sequentially or in parallel and a nice overview of the selected files
is shown on the page with a progress bar next to them. A 'Cancel'
upload button is also a possible option.
All that niceness is usually solved by using a Flash object. Complete
solutions are out there for the client side, like: SWFUpload
http://swfupload.org/ , FancyUpload http://digitarald.de/project/fancyupload/
, YUI 2 Uploader http://developer.yahoo.com/yui/uploader/ and probably
many more.
Ofcourse the trick is getting those solutions integrated in your
project. Especially in a framework like Django, double so if you want
it to be reusable.
So, I have a few ideas, but I'm neither an expert on Django nor on
Flash based upload solutions. I'll share my ideas here in the hope of
getting some feedback from more knowledgeable and experienced people.
(Or even just some 'I want this too!' replies :) )
You will notice that I make a few assumptions: this is to keep the
(initial) scope of the application under control. These assumptions
are of course debatable:
All right, my idea's so far:
If you want to mass upload multiple files, you are going to have a
model to contain each file in. I.e. the model will contain one
FileField or one ImageField.
Models with multiple (but ofcourse finite) amount of FileFields/
ImageFields are not in need of easy mass uploading imho: if you have a
model with 100 FileFields you are doing something wrong :)
Examples where you would want my envisioned kind of mass upload:
An app that has just one model 'Brochure' with a file field, a
title field (dynamically created from the filename) and a date_added
field.
A photo gallery app with models 'Gallery' and 'Photo'. You pick a
Gallery to add pictures to, upload the pictures and new Photo objects
are created and foreign keys set to the chosen Gallery.
It would be nice to be able to configure or extend the app for your
favorite Flash upload solution. We can pick one of the three above as
a default, but implement the app so that people can easily add
additional implementations (kinda like Django can use multiple
databases). Let it be agnostic to any particular client side solution.
If we need to pick one to start with, maybe pick the one with the
smallest footprint? (smallest download of client side stuff)
The Flash based solutions asynchronously (and either sequentially or
in parallel) POST the files to a url. I suggest that url to be local
to our generic app (so it's the same for every app where you use our
app in). That url will go to a view provided by our generic app.
The view will do the following: create a new model instance, add the
file, OPTIONALLY DO EXTRA STUFF and save the instance.
DO EXTRA STUFF is code that the app that uses our app wants to run.
It doesn't have to provide any extra code, if the model has just a
FileField/ImageField the standard view code will do the job.
But most app will want to do extra stuff I think, like filling in
the other fields: title, date_added, foreignkeys, manytomany, ...
I have not yet thought about a mechanism for DO EXTRA STUFF. Just
wrapping the generic app view came to mind, but that is not developer
friendly, since you would have to write your own url pattern and your
own view. Then you have to tell the Flash solutions to use a new url
etc...
I think something like signals could be used here?
Forms/Admin: I'm still very sketchy on how all this could best be
integrated in the Admin or generic Django forms/widgets/...
(and this is were my lack of Django experience shows):
In the case of the Gallery/Photo app:
You could provide a mass Photo upload widget on the Gallery detail
form. But what if the Gallery instance is not saved yet? The file
upload view won't be able to set the foreignkeys on the Photo
instances. I see that the auth app, when you create a user, first asks
for username and password and only then provides you with a bigger
form to fill in emailadres, pick roles etc. We could do something like
that.
In the case of an app with just one model:
How do you provide a form in the Django admin to do your mass
upload? You can't do it with the detail form of your model, that's
just for one model instance.
There's probably dozens more questions that need to be answered before
I can even start on this app. So please tell me what you think! Give
me input! What do you like? What not? What would you do different? Is
this idea solid? Where is it not?
Thank you!
I just released a simple app for this about a month ago: django-uploadify.
It's basically a Django template tag that acts as a wrapper for the very nifty Uploadify (requires jQuery). Using it is as simple as adding this to your template...
{% load uploadify_tags }{% multi_file_upload ‘/upload/complete/url/’ %}
The tag will fire events (1 per file) on both the client-side and server-side (Django signal) to indicate when an incoming file has been received.
For example, assuming you have a model 'Media' that handles all user-uploaded files...
def upload_received_handler(sender, data, **kwargs):
if file:
new_media = Media.objects.create(
file = data,
new_upload = True,
)
new_media.save()
upload_recieved.connect(upload_received_handler, dispatch_uid=‘whatever.upload_received’)
Check out the wiki for info on how to set it up and create the signal handlers (client/server).
About your conceptual implementation from above, here's a few points of consideration:
Having the app automatically create the "File Model" instance probably isn't as robust as people may already have their own models they're working with
If you want to implement any type of security or authentication, you need an open system and less of an 'auto-create' type
I really think signals/events are the way to handle this, and also handle the 'DO OTHER STUFF' part of what you mentioned.
My conclusion was that multi-upload can never really be a form widget in the sense that Django implements form widgets. 1 file will most likely be represented by 1 model instance (with some exceptions), which means that we end up with a situation where 1 widget can represent N model instances. However Django is setup so that a widget represents 1 value for 1 field in 1 instance. It just doesn't fit for the majority of use-cases to have it as a widget (hence why I went the template tag route).
I have created an article site, where articles are published in several languages. I am using transmeta (http://code.google.com/p/django-transmeta/) to support multiple languages in one model.
Also I am using generic comments framework, to make articles commentable. I wonder what will happen if the same article will be commented in one language and then in another. Looks like all comments will be displayed on both variants....
The question actually is:
Is there a possibility to display only comments submitted with current language of the article?
I tried the approach of transmeta for translation of dynamic texts and I had the following experience:
You want another language, you need to change the database model which is generally undesirable
You need every item in both languages, which is not flexible
You have problems linking with other objects (as you point out in your question)
If you take the way of transmeta you will need two solutions:
The transmeta solution for translating fields in a model
For objects connected to a model using transmeta you will need an additional field to determine the language, say CharField with "en", "de", "ru" etc.
These were major drawbacks that made me rethink the approach and switch to another solution: django.contrib.sites. Every model that needs internationalization inherits from a SiteModel:
class SiteModel(models.Model):
site = models.ForeignKey(Site)
Every object that would need transmeta translation is connected to a site. Every connected object can determine its language from the parent object's site attribute.
I basically ran the wikipedia approach and had a Site object for every language on a subdomain (en., de., ru.). For every site I started a server instance that had a custom settings file which would set the SITE_ID and the language of the site. I used django.contrib.sites.managers.CurrentSiteManagerto display only the items in the language of the current site. I also had a manager that would give you objects of every language. I constructed a model that connects objects of the same model from different languages denoting that they are semantically the same (think languages left column on wikipedia). The sites all use the same database and share the same untranslated User model, so users can switch between languages without any problem.
Advantages:
Your database schema doesn't need to change for additional languages
You are flexible: add languages easily, have objects in one language only etc.
Works with (generic) foreign keys, they connect to an object and know what language it is. You can display the comments of an object and they will be in one language. This solves your problem.
Disadvantages:
It's a greater deal to setup: you need a django server instance for every site and some more glue code
If you need e.g an article in different languages, you need another model to connect them
You may not need the django Site model and could implement something that does the same without the need of multiple django server instances.
I don't know what you are trying to build and what I described might not fit to your case, but it worked out perfectly for my project (internationalized community platform built upon pinax: http://www.bpmn-community.org/ ). So if you disclose some more about your project, I might be able to advise an approach.
To finally answer your question: No, the generic comments will not work out of the box with transmeta. As you realised you will have to display comments in both languages for the article that is displayed in one language. Or you will have to hack into the comments and change the model and do other dirty stuff (not recommended). The approach I described works with comments and any other pluggable app.
To answer your questions:
Two Django instances can share one database, no problem there.
If you don't want two Django instances, but one, you will have to do the following: A middleware checks the incoming request, extracts desired language from URL (en.example.com or example.com/en/ etc.) and saves the language preference in the request object. The view will have to take the request object with the language and take care of the filtering of objects accordingly. Since there is no dedicated server for the language (like in the sites approach where the language is stored in the settings.py file), you can only get the language from the request and you will have to pass attributes from the request object to Model managers to filter objects.
You could try to fake a global language state in the django application with an approach like threadlocals middleware, however I don't know if this plays out nicely with django I18N engine (which is also does some thread magic).
If you want to go big with your site in multiple languages, I recommend going for the sites-approach.