I am working on a Django application which is going to be deployed to Heroku (on their Cedar stack). A limitation of this is that we cannot write to disk. However, Django translations reside in .po files, and therefore the client will be unable to change the translations on the live site without involving a developer (which is not ideal).
The alternative solution therefore seems to be to store the translations in either an RDBMS, Mongo, Redis etc etc.
Is there any sensible way of achieving this? Is it even a good idea? (I wouldn't want to hit the DB for every translation!)
Edit: There seem to be lots of Django apps out there for translating text which is stored in a DB, but not for actually storing the translations themselves in a DB.
What I think about Django translations and translations stored in the files in general - this is for the parts which will not change and is not dynamic. Like constants you have in the website. And if you have dynamic text, which could be and must be edited when the website is running - I would say this is the same thing as normal content (blog entry, comments and so on).
So you can just develop simple module "site parts", with the template tag, which will grab the right thing for you from DB. Like from template you can call { get_site_part example }. And then you can edit those parts from admin interface.
I would not recommend to store dynamic content to the system files. If you worry about hitting database every time you need this - then caching should help here also you can develop smart template tag and grab all the site parts you need in one query. Then it will be nothing different from just simply loading blog entry or the comment for it.
Maybe I'm wrong, so this is just my 2c on this topic :)
Ignas
Related
I have a fairly large django project consisting of several individual apps. I am farming out some of the front-end work (CSS, HTML tweaks) to people who aren't over-familiar with django. To that end I'd like to generate a list of templates for each URL pattern any given engineer is working on. This will save much time that would otherwise be spent manually tracking down the templates used during a view's render phase.
For example, if Bob is working on URLs beginning with /accounts/ then I'd like to generate a list of all the templates used by any view that handles requests to those URLs.
My initial thought is to use something in the test framework since that has access to the templates rendered during a request. However, I can't guarantee that all URLs or views will be exercised (sadly I don't have 100% test coverage), and a missed template is unlikely to be noticed. I don't mind writing a set of tests that simply exercise each view, but don't want to duplicate existing efforts. Also certain views require POSTed data or authentication to function correctly - although I suspect that's an issue I'll have to face no matter what approach is used.
Are there any utilities or snippets that will do what I need?
django-debug-toolbar is a must for developing with Django, It includes a panel detailing all templates used during a request.
I've found the SQL panel is the most helpful for improving page load times as it details slow and duplicate queries.
It can slow down requests when enabled, disabling all panels but those that you use helps.
I am building an application that allows a user to browse html templates. The html template will be displayed in a preview area (source code will be obfuscated), and although the template will contain inline CSS/JS, there will also be the odd linked image asset.
For this reason, I thought it might be best for me to just store them as a library of folders, and retrieve the flat file from my server for display, as opposed to storing the HTML in the database and having to organise the external assets too.
My question is: Where in the CakePHP directory structure, is the best home for these files? I'd rather keep them above the webroot, and I'm thinking View.
Any ideas? Thanks.
I would suggest that you keep all the out-of-cakephp-framework related files, stored under the webroot.
My suggestion is the following directory structure for saving the html template as well as the css and js related files.
/webroot/files/templates/<template-project-name>/<the-actual-file>.html
Any external css, would then be under
/webroot/css/templates/<template-project-name>/<the-actual-css>.css
And the JS libraries would be under
/webroot/js/templates/<template-project-name>/<the-actual-js>.js
Use a seperate layout file (call it preview_layout.ctp) which simply renders
the template file as it is.
Hope it helps
Why do you want to store them above the webroot, when they are publicly-viewable assets? My gut feeling is that they really belong in the webroot or in the database. I would pick one or the other.
If you must store them above the webroot, I guess the best thing might be to store them as elements.
app/View/Elements/your_templates/
And that way, you can load it into the preview area of your View using:
echo $this->element('your_templates/template');
Edit:
Honestly, the suggestion of elements is not what I would recommend, I'm just trying to offer you different suggestions. It would be terribly bad practice and I think it will be more messy and problematic than it's worth.
As for the image files, put them in the webroot, regardless of where you choose to store the HTML templates. You can't stop people downloading the images once they are viewing them in their browser anyway.
I'm looking at porting a custom-written PHP CMS into Django. One of the features the CMS currently has is an image upload function. I write an article, tag it with information, then choose a photo for it. If the system has any photos which have been added to articles with tags in common with the new one, it will suggest the photo for that article too. If there are no matches then a new image can be added.
In case this doesn't make sense, let's say I tag an article as Bruce Springsteen, The Beatles and Led Zeppelin. Next time I add an article with the tag The Beatles, it should suggest I use the image added for the first article.
What would be the best Django-applicable way to implement this? I've looked at the Photologue app and have integrated it, and I know it has tagging support (the problem here is that I'm using django-taggit, whereas Photologue supports django-tagging). One approach could be simply building it myself -- when a user uploads an article, I run a hook after they save it to associate the tags with the image. I'm just not sure how to then autosuggest an image in the admin tools based on that info.
Any ideas/approaches greatly appreciated.
This is almost certainly something you're going to have to build yourself. Django has a moderate number of libraries out there (that you've clearly already found). Unlike other solutions, it doesn't have a lot of things that get you 100% to your desired solution (whereas something like Drupal might get you 100% of the way there).
What you will probably need to do (at a high level) is something like this:
Create an AJAX view that takes the current tags as an argument and does a query on the existing posts to see what tags match and returns images from those posts.
Use jQuery/javascript on your view to call your AJAX view on the page as tags are added
Use jQuery to update a <div> on your page and show all the images that your view returned
Here is a similar example that might help get you started.
You might look into django-ajax as a helper library for your requests, but it definitely isn't necessary.
The hook between the your image module and any other django module can be implemented using django's contenttypes framework which also provides some useful instance methods for returning related/hooked objects.
I've localized my site following the documentation.
Now, I've wanted to test this through the browser. But, I seem not to be able to figure out how this is done.
I am using FF and in preference / content / languages, added 'es'. I also moved it to the top of the languages list.
Then when I go to the site, I don't see anything translated.
What am I missing?
Thanks
Eric
Django stores the language code in the cookie for each user. You'll probably want to make use of Django's set_language view, perhaps at least in your development environment, because it's quicker than deleting cookie entries or destroying sessions. I used it to write a custom view that switches between the base language and another one to snoop through the site just to be 100% sure I'm translating everything.
If that still doesn't work, might want to make sure you've added it to the list of LANGUAGES and that you've added the django.middleware.locale.LocaleMiddleware to your list of middleware, because it's responsible for parsing Accept-Language from request headers.
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).