Re: Reviews of pluggable apps? (Sphene Community Tools)
Not exactly what you ask, but below are two pages which compare forum apps and cms apps quite extensively; http://code.djangoproject.com/wiki/ForumAppsComparison http://code.djangoproject.com/wiki/CMSAppsComparison Regards, Polat Tuzla On Mar 10, 3:01 pm, Gok Mop wrote: > Hi, > > Can anyone point me to a site where I can find reviews or futher > information about pluggable apps available for Django? > > I found Sphene Community Tools (which looks like what I want for user > discussion forums, user profiles, and several other things) but it's > difficult to find any competition to that module, and it's also > difficult to tell whether it's fresh and actively maintained. Before > I drink the kool-aid and go that route, I'd like to know that it's > fairly solid. > > Thanks --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Django/Apache/wsgi problems -- help!
I'm glad to hear that everything is solved. > One more question: in what sense did you mean that MEDIA_ROOT > "is for file uploads"? I have not begun working on file uploads > yet, but I will need that, and I see there is documentation on it > which talks about several configurable options. Did you mean that > MEDIA_ROOT is the default location for uploaded files? Yes. Django uses MEDIA_ROOT as the root path for the upload_to parameter for FileField and ImageField. It defines the root of the directory tree where the files should be stored. It is typically the place where you will want to make publicly available through your web server. MEDIA_URL is used when constructing url values for such fields. > Thanks again for your help -- you saved my bacon! :) > Steve You are welcome. Regards, Polat Tuzla > > Polat Tuzla wrote: > > Also the /admin/ url gives > >> an internal error, which in apache's errlog shows a traceback > >> that ends in "OperationalError: no such table: django_session". > > > This is most probably due to the fact that you did not set your > > DB_NAME variable with the full path of your .db file. And sqlite3 is > > creating a new .db file as it cannot access the real one. > > That is: > > Instead of > > DATABASE_NAME = 'dev.db' > > you should set it as > > DATABASE_NAME = '/path/to/db/file/mydbfile.db' > > > And for the vhost configuation let me write down what works for me: > > > ServerNamewww.mysite.com > > ServerAlias *mysite.com > > Alias /media/admin /usr/lib/python2.5/site-packages/django/contrib/ > > admin/media > > > > Order allow,deny > > Allow from all > > > > Alias /media /path/to/project/site_media > > > > Order allow,deny > > Allow from all > > > > > WSGIScriptAlias / /path/to/project/apache/my.wsgi > > > WSGIDaemonProcess mysite.com user=myuser group=www-data threads=25 > > WSGIProcessGroup mysite.com > > > And set the configuration variables accordingly as: > > MEDIA_ROOT = '/path/to/project/site_media/' #this is for file > > uploads > > MEDIA_URL = "http://mysite.com/media/"; > > ADMIN_MEDIA_PREFIX = '/media/admin/' > > >> (I also have MEDIA_ROOT set -- is it necessary to have both??) > > Yes it is. At least in this configuration I am demonstrating. > > > Hope this helps. > > Regards, > > > Polat Tuzla --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Django/Apache/wsgi problems -- help!
Also the /admin/ url gives > an internal error, which in apache's errlog shows a traceback > that ends in "OperationalError: no such table: django_session". This is most probably due to the fact that you did not set your DB_NAME variable with the full path of your .db file. And sqlite3 is creating a new .db file as it cannot access the real one. That is: Instead of DATABASE_NAME = 'dev.db' you should set it as DATABASE_NAME = '/path/to/db/file/mydbfile.db' And for the vhost configuation let me write down what works for me: ServerName www.mysite.com ServerAlias *mysite.com Alias /media/admin /usr/lib/python2.5/site-packages/django/contrib/ admin/media Order allow,deny Allow from all Alias /media /path/to/project/site_media Order allow,deny Allow from all WSGIScriptAlias / /path/to/project/apache/my.wsgi WSGIDaemonProcess mysite.com user=myuser group=www-data threads=25 WSGIProcessGroup mysite.com And set the configuration variables accordingly as: MEDIA_ROOT = '/path/to/project/site_media/' #this is for file uploads MEDIA_URL = "http://mysite.com/media/"; ADMIN_MEDIA_PREFIX = '/media/admin/' > (I also have MEDIA_ROOT set -- is it necessary to have both??) Yes it is. At least in this configuration I am demonstrating. Hope this helps. Regards, Polat Tuzla --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Differen unicode behaviour between mac os x and linux
Thanks a lot for your responses. I managed to track down the problem further with the help of the information you provided. In my wsgi script I have: sys.stdout = sys.stderr (So that's the reason why output is redirected to error files as Graham mentioned.) My view file is: # coding=utf-8 ... def home(request): print u"İşÖ" Both of the machines have default encoding of 'ascii'. Linux box have mod_wsgi 2.3 installed. 1- When running on the Mac OS X box as development sever (./manage.py runserver) the view prints "İşÖ" as expected 2- When running on the Linux box as development sever (./manage.py runserver) the view prints "İşÖ" as expected, too 3- When running on the Linux box on apache+mod_wsgi, the print statement raises "UnicodeEncodeError: 'ascii' codec can't encode character u'\u0130' in position 0: ordinal not in range(128)" This leads me to the conclusion that it's related to mod_wsgi and one should not try to 'print' unicode strings within it. Although I can't understand the exact reason event after your explanations, I wanted to mention my findings, for future reference for anyone who comes across the same problem. Regards, Polat Tuzla On Feb 17, 12:48 pm, Graham Dumpleton wrote: > On Feb 17, 3:01 pm, Malcolm Tredinnick > wrote: > > > > I think I should have clarified some more facts about my setup. > > > 1- On mac, django is running on dev mode, so stdout is the console. On > > > linux, it'smod_wsgi, so stdout is redirected to apache error log > > > files, on which I'm issuing a "tail -f" thorough ssh. > > > I was a little surprised that stdout was redirected to the error logs in > > mod_wsgi, but it seems that that is indeed the case. > > In default configuration mod_wsgi does not send stdout to the Apache > error logs. In fact if you try and output to stdout mod_wsgi will > complain and raise an exception. This is because mod_wsgi deliberately > restricts writing to stdout to discourage people using 'print' for > debug. This is done because by doing so you make your WSGI application > less portable. In particular, your WSGI application would break in a > WSGI hosting mechanism which uses stdout to communicate the response > back to the web server. Such a mechanism is used for CGI-WSGI bridges. > > Thus, if stdout is going to the Apache error logs it is because the > user made a conscious decision to redirect it there by disabling the > mod_wsgi restriction on using stdout. This can be done by using > WSGIRestrictStdout directive, or explicitly reassigning sys.stdout to > be sys.stderr. > > All this stuff about stdout is described in: > > http://code.google.com/p/modwsgi/wiki/ApplicationIssues#Writing_To_St... > http://code.google.com/p/modwsgi/wiki/DebuggingTechniques > > > I don't know what > > mod_wsgi might be doing to character encoding on output (maybe nothing, > > but maybe that's playing a role). > > Uses: > > PyArg_ParseTuple(args, "s#:write", &msg, &len) > > so presumably the default encoding. If the default encoding isn't > UTF-8, then you may have problems in trying to outputUnicodestrings > if it cannot be represented in whatever default encoding is. This > would likely result in exception and so perhaps what you are seeing. > > > However, instead of using print, I > > would recommend using Python's logging module and sending the results to > > a dedicated logging file. > > > Apache error logs aren't a great place for audit-style logging, since > > there's so much other (Apache-specific) stuff in there. > > If the integrity of the information being logged is important, then I > also would be recommending logging to your own files. > > The mapping of sys.stderr to Apache error logging mechanism should be > seen as more of a failsafe default for minor logging. If you need a > more serious logging system, implement your own. > > Mapping to Apache error logging mechanism has a couple of > shortcomings, plus a bug in mod_wsgi 2.3. The bug stems from fact that > it is trying to force data into a C API call that takes NULL > terminated C strings. Forgot about that aspect of it so it is > currently truncating at any embedded null in something which is > logged. So, okay if text, but shove binary data down it and it will > not be happy. This is addressed in mod_wsgi 3.0. All it can do though > is interpret an embedded null as if it was a newline because Apache > logging API doesn't understand concept of length. > > The reason that Apache logging API is used rather than just stuffing > it direct into file descri
Re: Differen unicode behaviour between mac os x and linux
Thanks a lot for your reply Malcolm.
It's OK if I don't understand the reason of different behaviours, but
I must find a proper way of writing log files on the linux server.
I think I should have clarified some more facts about my setup.
1- On mac, django is running on dev mode, so stdout is the console. On
linux, it's mod_wsgi, so stdout is redirected to apache error log
files, on which I'm issuing a "tail -f" thorough ssh.
2- If I test the same code in the djang shell, the two boxes behave
the same.
To sum up, my main problem is error raising print statements on
production server, causing Http 500 responses, while they perfectly
work on the local box. And I can't remove the print statements due to
logging requirements.
What's the proper way of 'printing' a model object?
print u"%s" % request.user
raises UnicodeEncodeError as I previously mentioned.
Regards,
Polat Tuzla
On Feb 17, 4:15 am, Malcolm Tredinnick
wrote:
> On Mon, 2009-02-16 at 17:55 -0800, Polat Tuzla wrote:
> > Hi,
> > I've the same django app deployed to my local mac os x and linux
> > server. I print the username in my view function to the standart
> > output:
> > def my_view(request):
> > print request.user
>
> > On mac it prints:
> > İşÖ
>
> > which is what i expect. But on linux it prints:
> > \xc4\xb0\xc5\x9f\xc3\x96
>
> I'm not quite sure why the Linux system doesn't display characters,
> although the data is correct. However, it's almost certainly terminal
> related: at some point Python has to format the result in a fashion that
> can be displayed on the terminal ("in the terminal application" would be
> a bit more appropriate to today's implementations, I guess) and your
> Linux and Mac systems don't necessarily coincide in their capabilities.
> Most Linux setups will be fine, but there are reasons why it might be
> restricted to something like, say, only ASCII (accessing via telnet or
> ssh with restricted negotiation, for example).
>
> You are asking Python to use the __str__ method on the model. Unless you
> somehow tell it that the result should be a unicode object, it will
> assume a str. Django uses the User.__unicode__ method and UTF-8 encodes
> it. The Linux output you're seeing is consistent with this: it's the
> UTF-8 encoding of the original string.
>
>
>
> > If I change my view code as:
> > def my_view(request):
> > print u"%s" % request.user
>
> > On mac it prints the same as before:
> > İşÖ
>
> > But on linux it raises a UnicodeEncodeError:
> > UnicodeEncodeError: 'ascii' codec can't encode characters in
> > position 0-2: ordinal not in range(128)
>
> This would be consistent with your terminal not supporting something
> like UTF_8 output -- or, rather, with Python thinking that the output
> has to be displayed in ASCII.
>
> Don't get too hung up on the results of print output (I realise it might
> hamper some debugging approaches, but it's the debugging approach that
> is causing the problem here, not some bigger issue). There's a big
> variable involved -- terminal encoding type -- that isn't present in
> normal code execution.
>
> Regards,
> Malcolm
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---
Differen unicode behaviour between mac os x and linux
Hi, I've the same django app deployed to my local mac os x and linux server. I print the username in my view function to the standart output: def my_view(request): print request.user On mac it prints: İşÖ which is what i expect. But on linux it prints: \xc4\xb0\xc5\x9f\xc3\x96 If I change my view code as: def my_view(request): print u"%s" % request.user On mac it prints the same as before: İşÖ But on linux it raises a UnicodeEncodeError: UnicodeEncodeError: 'ascii' codec can't encode characters in position 0-2: ordinal not in range(128) So, these are two cases of different behaviour. Databases in both of the machines are mysql, and the auth_user tables in both machines have a charset of utf8. Could somebody tell what would be the reason? Thanks --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Convert iso-8859-1 queryset to utf-8
You may also want to make sure that you know whether your Flash/ ActionScript components require UTF-8 with BOM (Byte-order Mark) or not. Let me try to explain more clearly: In my case, I had i18n problems when a flash component rendered my utf-8 encoded templates. I had saved my templates as utf-8, had set the response headers as: response = HttpResponse(mimetype='text/xml; charset=utf-8') Nevertheless all of the characters that are out of ascii range were not displayed correctly. It turned out to be that my text editor (TextMate) was saving the file as UTF-8 without BOM for some good reasons. (http://blog.macromates.com/2005/handling-encodings-utf-8/) And the flash component required UTF-8 with BOM in order to display correctly. So I had to save my xml templates in an other text editor. Regards, Polat Tuzla On Jan 21, 1:55 pm, Anders wrote: > My django site uses iso-8859-1 as default output of all the web pages > (due to ssi intergration with other iso-8859-1 pages). > > So I have set: > DEFAULT_CHARSET = 'iso-8859-1' > FILE_CHARSET = 'iso-8859-1' > > and this works fine for alle the pages I serve. > > But now I have to serve an xml output for use with actionscript in a > Flash. This xml should be UTF-8 encoded. > > Is there som way I can convert the queryset to utf-8 so that this will > work? Or can I convert each string as I output it in the template > (yeah, I use the template to create xml - not good, I know). > > In addition the render_to_response uses the default charset, is is > possible to override this default and use UTF-8? > > Thnx > Anders --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Circular imports between managers and models
Yes, indeed! It's the models.Manager I'm talking about. I tried to keep my example short and easily comprehensible without code snippets, but i think I've achieved the opposite. Sorry for any inconvenience. Polat Tuzla On Jan 6, 3:37 pm, bruno desthuilliers wrote: > On 6 jan, 14:08, Lee Braiden wrote: > > > > > On Tue, 2009-01-06 at 04:42 -0800, Polat Tuzla wrote: > > > Hi, > > > Suppose I have two classes in "models.py", namely A and B. And there > > > is the manager for B as BManager in "managers.py". BManager makes use > > > of clas A. > > > > This situation leads to circular imports between "managers.py" and > > > "models.py" for which I can't find a solution. > > > > Assuming that I need to separate models and manager into different > > > files, so merging them is not an option, are there any best practices > > > or do you have any other suggestions? > > > No expert on Django, and it's hard to tell what your GOAL is from this > > description, but you might want I'd write something like this: > > > class Employee(models.Model): > > name = models.CharField(...) > > > class Manager(Employee): > > manager_stuff... > > I think the OP is talking about > models.Managers:http://docs.djangoproject.com/en/dev/topics/db/managers/ > > !-) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Circular imports between managers and models
Thank you very much for both of your responses. Local imports solved my problem. I had previously tried this without success, apparently there was another mistake in the code. Upon Bruno's suggestion I gave it another try, and it worked! The reason why I need to separate models and managers into different files is that they have simply grown to thousands of lines. Regards, Polat Tuzla On Jan 6, 3:21 pm, bruno desthuilliers wrote: > On 6 jan, 13:42, Polat Tuzla wrote: > > > Hi, > > Suppose I have two classes in "models.py", namely A and B. And there > > is the manager for B as BManager in "managers.py". BManager makes use > > of clas A. > > > This situation leads to circular imports between "managers.py" and > > "models.py" for which I can't find a solution. > > > Assuming that I need to separate models and manager into different > > files, so merging them is not an option, are there any best practices > > or do you have any other suggestions? > > The import statement works fine in a method too. > > class BManager(...): > def some_method(self): > from models import A > # code here > > But I have hard time understanding why you couldn't put models and > managers in the models file... --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Circular imports between managers and models
Hi, Suppose I have two classes in "models.py", namely A and B. And there is the manager for B as BManager in "managers.py". BManager makes use of clas A. This situation leads to circular imports between "managers.py" and "models.py" for which I can't find a solution. Assuming that I need to separate models and manager into different files, so merging them is not an option, are there any best practices or do you have any other suggestions? Thanks, Polat Tuzla --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: How to populate a form field with a Select widget
A formatting error occurred while I did my previous post.
Please make sure that you notice the parentheses at the last line of
the code snippet, which were actually meant to be at the end of the
previous line.
Regards,
Polat
On Dec 29, 1:03 pm, Polat Tuzla wrote:
> You can do it as follows:
>
> class MyForm:
> CHOICES = ( ('P', 'Pending'), ('A', 'Active'), ('D', 'Done'))
> status = forms.ChoiceField(choices=CHOICES,widget=forms.Select
> ())
>
> Regards,
> Polat
>
> On Dec 29, 5:13 am, "Aaron Lee" wrote:
>
>
>
> > I would like to populate a form field which uses a Select widget with
> > choices in views.py.
> > I understand I can pass the initial arg to the form but I couldn't find the
> > correct value to pass.
>
> > The choices is a list of tuple
> > CHOICES = ( ('P', 'Pending'), ('A', 'Active'), ('D', 'Done'))
>
> > Any hints?
>
> > -Aaron
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---
Re: How to populate a form field with a Select widget
You can do it as follows:
class MyForm:
CHOICES = ( ('P', 'Pending'), ('A', 'Active'), ('D', 'Done'))
status = forms.ChoiceField(choices=CHOICES,widget=forms.Select
())
Regards,
Polat
On Dec 29, 5:13 am, "Aaron Lee" wrote:
> I would like to populate a form field which uses a Select widget with
> choices in views.py.
> I understand I can pass the initial arg to the form but I couldn't find the
> correct value to pass.
>
> The choices is a list of tuple
> CHOICES = ( ('P', 'Pending'), ('A', 'Active'), ('D', 'Done'))
>
> Any hints?
>
> -Aaron
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---
Re: request parsing
django-attachments application at the http://github.com/korpios/django-chicago/tree/master is a good example that has a model (Attachment) with a file field and a form that is driven by the model (AttachmentForm). For forms with other types of fields including an image field you can check out django-profile application at http://code.google.com/p/django-profile/. For almost anything you could imagine, you should check out http://pinaxproject.com On Dec 10, 8:16 am, Vicky <[EMAIL PROTECTED]> wrote: > hey can u plse attach and sent me a sample project that uses forms if > possible. I need to knw wr anw hw to create forms, should we include > anything in settings.py or urls.py? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: request parsing
File uploading is explained in detail at
http://docs.djangoproject.com/en/dev/topics/http/file-uploads/
In short you create a form consisting of a file field:
class UploadFileForm(forms.Form):
title = forms.CharField(max_length=50)
file = forms.FileField()
then write a view function to save it:
def upload_file(request):
if request.method == 'POST':
form = UploadFileForm(request.POST, request.FILES)
if form.is_valid():
f = request.FILES['file']
destination = open('some/file/name.txt', 'wb+')
for chunk in f.chunks():
destination.write(chunk)
destination.close()
...
Hope this helps.
On Dec 9, 11:30 am, Vicky <[EMAIL PROTECTED]> wrote:
> If we send a file by post method to a django function how can we
> separate the file from the request?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---
Re: Admin page doesn't show calendar popup
Please follow the django documentation, section named 'Install the Django code'. It's located here: http://www.djangoproject.com/documentation/install/ Make sure that you follow the part 'Installing the development version'. And don't forget to 'Remove any old versions of Django' before installing a new version. On Apr 20, 8:27 pm, chiefmoamba <[EMAIL PROTECTED]> wrote: > Hi, > > I had the same problem earlier - 0.96 on Leopard. How do you switch to > trunk? > > Thanks, > > Ed > > On Apr 20, 4:53 pm, sinker <[EMAIL PROTECTED]> wrote: > > > Switching to trunk WORKED. Thank you so much! > > > On Apr 19, 7:42 am, Polat Tuzla <[EMAIL PROTECTED]> wrote: > > > > I got the same problem with the version 96.1 on Mac. > > > Then switched to trunk and everything went OK. > > > Unfortunately can't tell you why this happened, as I did not bother to > > > investigate the problem further. > > > Just switch to using trunk if that suits you, and you will have the > > > calendar pop ups. > > > > On Mar 30, 8:39 am, Hoolio <[EMAIL PROTECTED]> wrote: > > > > > I just installed Django 96.1 on my Mac. When I follow the tutorial > > > > and get to the Admin page, the calendar pop ups don't show up. Is > > > > there a problem with the install. I'm using Leopard. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Admin page doesn't show calendar popup
I got the same problem with the version 96.1 on Mac. Then switched to trunk and everything went OK. Unfortunately can't tell you why this happened, as I did not bother to investigate the problem further. Just switch to using trunk if that suits you, and you will have the calendar pop ups. On Mar 30, 8:39 am, Hoolio <[EMAIL PROTECTED]> wrote: > I just installed Django 96.1 on my Mac. When I follow the tutorial > and get to the Admin page, the calendar pop ups don't show up. Is > there a problem with the install. I'm using Leopard. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Two sites, one django project
CSS swapping via settings file seems like good idea. Thanks for that.. But when it comes storing messages in the database: I don't think it's feasible. By messages I mean almost all of the strings throughout the source; page titles, headers in templates, error messges that are added to user message set in views, even "verbose name"s of models. I think I'll have to use a custom template loader as mentioned above, but still in this case, I'll have to duplicate the templates between the two sites. Thank you all, for the suggestions. On Apr 10, 3:33 pm, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: > Maybe I'm over simplyfying this ... but why not just swap out the css > file you are using based on a setting you can change in your > settings.py fileas well as modify the database you are calling in > your settings.py file, and store your messages in a table... where the > data would be different in each database? > > On Apr 10, 6:10 am, Tim Sawyer <[EMAIL PROTECTED]> wrote: > > > Came across this the other day, never used it. > > >http://code.google.com/p/django-databasetemplateloader/ > > > It seems to allow you to store templates in the database, so could this be > > used together with the sites framework to skin your sites differently? > > > Tim. > > > On Thursday 10 Apr 2008, Polat Tuzla wrote: > > > > Hi, > > > I'd like to build two sites, say, two polls sites, each having their > > > own domain name. Their functionalities are almost exactly the same. > > > They're different only by theme. By theme, I mean both the site design > > > (visual theme) and the site messages. For example one is for polls > > > about music and the other is about videos. > > > > I'd like to be able to use the same source code (i.e same django > > > project) for running both of these sites for the ease of maintenance. > > > This may be by running either a single instance of django, or two. But > > > again, I'd prefer single instance for the ease of administration. This > > > would also let me have a single sign-on functionality as a side > > > effect. > > > > The site message strings are scattered in models, views and template > > > files. I don't want to duplicate any of these codes just for the sake > > > of alternating between different messages. I tried to find a way out, > > > by using sites framework, but wasn't able to without actually > > > duplicating views and templates. > > > Another option was using i18n, and two different translation files > > > between two django instances. But this only works for languages other > > > than English, I guess. > > > > What exact way of achieving this would you suggest me? > > > I've been doing research on this for quite a long time, but really > > > could not come up with a solution. Any suggestion is greatly > > > appreciated, even those like "don't do this, duplicate the project" :) > > > Thanks, --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Two sites, one django project
Hi, I'd like to build two sites, say, two polls sites, each having their own domain name. Their functionalities are almost exactly the same. They're different only by theme. By theme, I mean both the site design (visual theme) and the site messages. For example one is for polls about music and the other is about videos. I'd like to be able to use the same source code (i.e same django project) for running both of these sites for the ease of maintenance. This may be by running either a single instance of django, or two. But again, I'd prefer single instance for the ease of administration. This would also let me have a single sign-on functionality as a side effect. The site message strings are scattered in models, views and template files. I don't want to duplicate any of these codes just for the sake of alternating between different messages. I tried to find a way out, by using sites framework, but wasn't able to without actually duplicating views and templates. Another option was using i18n, and two different translation files between two django instances. But this only works for languages other than English, I guess. What exact way of achieving this would you suggest me? I've been doing research on this for quite a long time, but really could not come up with a solution. Any suggestion is greatly appreciated, even those like "don't do this, duplicate the project" :) Thanks, --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
