Re: FlatPage and Internationalization
I've implemented similar system. Only I have used MyFlatPage and MyFlatPageTranslation models, because it makes easier to locate and translate pages in the admin interface. On 9 нояб, 15:25, DvD <[EMAIL PROTECTED]> wrote: > Hi everyone, > lately i was trying to internationalize a wesite which had flatpages, > but i also needed to translate those pages so i came up with this idea > to get site specific AND language specific flatpages. > > I put on the FlatPage class this attribute: > > > language= models.CharField(maxlength= 7, choices= settings.LANGUAGES) > > > and in the view i modified this line > > > f = get_object_or_404(MyFlatPage, url__exact=url, > sites__id__exact=settings.SITE_ID) > > > to look like this > > > if = get_object_or_404(MyFlatPage, url__exact=url, > sites__id__exact=settings.SITE_ID, language= request.LANGUAGE_CODE) > > > What do you think? With this changes, you'll be able to retrieve site > specific and language specific flatpages. > > While i was thinking about, it 've been wondering why no one else ever > thought about it and I thought it'd been a good idea to share this > code. > > What do you think? Could it be an upgrade for django flatpages module? > Did I miss something or someone else already thought about it? > Let me know. > > Cheers, > David --~--~-~--~~~---~--~~ 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: YAFU: Yet Another File Upload app...
Hello, Thanks for your contribution. There's a similar functionality in Django Trac #2070 and #4165. #2070 contains patch with an implementation of streaming file uploads. This seems to be working. #4165 contains middleware and javascript that implement file upload progress monitoring for the Django admin interface. Unfortunately, this code is very unreliable, especially Javascript. Sorry guys, whoever wrote the Javascript part, but it is a real mess. I've implemented a much nice version using jQuery progress bar and jQuery modal windows, but it's a part of commercial project so I'm afraid I cannot share. Currently my Javascript upload monitor it uses middleware from #4165 but I plan to replace it with my own version as this middleware sometimes report bogus data. So, it is possible to implement file upload progress monitor without external CGI script and IFRAMEs. Just apply #2070 (it looks more polished than patches from #4165), implement simple middleware that will track file uploading progress, and a tiny Javascript that will ask middleware about progress using XMLHttpRequest. Eugene On 7 нояб, 19:55, Dustin Lang <[EMAIL PROTECTED]> wrote: > Hi, > > It didn't seem like any of the current Django file upload apps provided > exactly > the functionality I needed, so I hacked my own. If the community is > interested, I can try to polish it a bit and contribute it. > > We deal with large uploads - up to hundreds of megabytes - so I wanted the > following: > > -the server should not keep the whole file in memory while the upload is > progressing: it should stream to disk > > -the server shouldn't have to copy the streamed data: it should only write the > uploaded file once > > -the user must get some feedback (a progress meter, or whatever) while the > upload is progressing > > I wrote some code that accomplishes this. You can see an ugly demo > at:http://oven.cosmo.fas.nyu.edu:/upload-demo/ > > It works as follows: > > -There is a python CGI program that accepts the upload. It's not a Django > view > because it needs to stream the input as it comes in from the network; it runs > as a normal mod_python handler. > > -This CGI program parses the multipart/form-data input, looking for an > "upload_id" field (which tells it which temp file to write the uploaded file > to), and then looks for the file data itself and streams that to disk. At the > end of the upload, it produces a dictionary of the "normal" form fields and an > object representing the uploaded file. > > -We have a "main" form with several fields, and within that HTML page there > are > two IFRAMEs. The first one contains an "upload" form: it requests a form > which > has a hidden "upload_id" field and a file input element (and a hidden submit > button). The second IFRAME contains an (initially hidden) upload progress > meter. > > -If the user submits the "upload" form (by hitting ENTER in the file input > dialog), some Javascript gets triggered which displays the upload progress > meter. (The upload progress meter is a snazzy little AJAX dealie - quite nice > but its CSS needs some attention). If the file is empty or some other error > occurs, the progress meter shows an error message. > > -When the file upload starts, the CGI writes "Upload in progress..." and when > if it finishes successfully, it writes a hidden element. Some > Javascript > notices that the upload form's IFRAME finished loading, and it looks for that > to ensure that the upload was successful. If so, it grabs the > "upload_id", saves it in a hidden field in the main form, and submits the main > form. > > -The main form goes to a normal Django view, and it can use the "upload_id" to > pull a reference to the file out of a database. > > I know it sounds overly complicated, but it seemed to be necessary to achieve > the user experience and server-side requirements I had. > > Before it's ready for prime-time, it will need some fixes: > > -the form-multipart parsing is currently hacky; the RFC should get translated > into regular expressions > > -the upload form handler currently doesn't really do anything with the other > form fields - it should store them in a database. > > -there's not a lot of checking of upload_id values - one could easily add some > rules that only upload_ids that have been generated by the server can be > uploaded; and that it's invalid to try to re-upload a file; or that only > authenticated users are allowed to upload files. > > -I'm new to python and Django, so I'm sure there is a lot of polishing that > could be done. > > -I tried to work out a solution that didn't require two IFRAMES (one for the > file form, one for the progress meter), but couldn't get it to work. > > Anyway, let me know if you're interested in this code and I'll bundle it up if > anyone is. > > Cheers, > dstn. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group.
Re: Large streaming uploads (#2070) doesn't work for me at all
> If you run Django with its standalone development server do you see > the same behaviour? Ie., does the Django process blow out in size? > > Unless you are bound to mod_python because of other code which uses > its APIs directly, then also consider trying to host Django under > mod_wsgi (http://www.modwsgi.org) to see if it exhibits the same > problem. > > Doing both these things would help to highlight whether this is a > Django issue, a mod_python issue or a general Apache problem with your > configuration. Thanks for your suggestions. Problem doesn't occur when I use development server or mod_wsgi, so it is clearly a mod_python bug. Unfortunately, I don't have time currently to investigate why it happens. Now I hit another problem though. Seems that #2070 patch is seriously outdated. django/core/validators.py is not touched by it, and this causes exception: Traceback (most recent call last): File "/var/lib/python-support/python2.5/django/core/handlers/base.py" in _real_get_response 81. response = callback(request, *callback_args, **callback_kwargs) File "/var/lib/python-support/python2.5/django/contrib/admin/views/ decorators.py" in _checklogin 55. return view_func(request, *args, **kwargs) File "/var/lib/python-support/python2.5/django/views/decorators/ cache.py" in _wrapped_view_func 39. response = view_func(request, *args, **kwargs) File "/var/lib/python-support/python2.5/django/contrib/admin/views/ main.py" in change_stage 332. errors = manipulator.get_validation_errors(new_data) File "/var/lib/python-support/python2.5/django/oldforms/__init__.py" in get_validation_errors 61. errors.update(field.get_validation_errors(new_data)) File "/var/lib/python-support/python2.5/django/oldforms/__init__.py" in get_validation_errors 378. self.run_validator(new_data, validator) File "/var/lib/python-support/python2.5/django/oldforms/__init__.py" in run_validator 368. validator(new_data.get(self.field_name, ''), new_data) File "/var/lib/python-support/python2.5/django/oldforms/__init__.py" in isValidImage 713. validators.isValidImage(field_data, all_data) File "/var/lib/python-support/python2.5/django/core/validators.py" in isValidImage 180. content = field_data['content'] KeyError at /admin/account/pokerroom/5/ 'content' I'll try to post this to the Django Trac again. Eugene --~--~-~--~~~---~--~~ 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: Large streaming uploads (#2070) doesn't work for me at all
On 4 нояб, 07:05, Graham Dumpleton <[EMAIL PROTECTED]> wrote: > You might at least try mod_python 3.3.1 instead of the older > mod_python 3.2.10. The newer version fixes a lot of problems including > memory leaks. Hello Graham, Compiled and installed 3.3.1. Exactly the same result! Apache consumes all free memory in seconds, at which point I kill the httpd process before the kernel OOM handler will randomly select its victim. I cannot report this to the Django Trac, because it says my message looks like spam. I've tried rewriting but that didn't help. How are people supposed to report bugs? Posting them to the developers list? Eugene --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Large streaming uploads (#2070) doesn't work for me at all
Hello, I've applied patch from #2070 and I have disastrous result. I'm trying to upload a 12Mb PNG file. Apache starts eating memory rapidly, consuming several Gb in seconds and I have to kill it (if I have enough time to log in as root and find pid of the httpd process). I'm using Django trunk (rev. 6638, had to patch fields.py manually as patch cannot find context, it was easy, though), python 2.5.1, mod- python 3.2.10, apache 2.2.3 on 64 bit Ubuntu 7.04. Does this patch work for anyone with similar configuration? 12Mb is small enough to fit in memory, why apache consumes 2Gb while storing it and still fails... Mystery. Eugene --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Large streaming uploads (#2070) doesn't work for me at all
Hello, I've applied patch from #2070 and I have disastrous result. I'm trying to upload a 12Mb PNG file. Apache starts eating memory rapidly, consuming several Gb in seconds and I have to kill it (if I have enough time to log in as root and find pid of the httpd process). I'm using Django trunk (rev. 6638, had to patch fields.py manually as patch cannot find context, it was easy, though), python 2.5.1, mod- python 3.2.10, apache 2.2.3 on 64 bit Ubuntu 7.04. Does this patch work for anyone with similar configuration? 12Mb is small enough to fit in memory, why apache consumes 2Gb while storing it and still fails... Mystery. Eugene --~--~-~--~~~---~--~~ 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: Sharing code between two projects
Hello, Thank you, must have thought about it... Probably need some rest, now it seems so obvious a solution. Eugene On 4 июл, 15:56, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > On Wed, 2007-07-04 at 04:34 -0700, Eugene Morozov wrote: > > Hello, > > I have two projects, they were developed independently. They will be > > run on the same server and have many things in common (notably some > > models and templatetags). > > > While I can import models from another project if it is on PYTHONPATH, > > I cannot find a way to share templatetags. I don't want to copy them, > > because maintaining costs would become higher (need to remember to > > apply bug fixes in both places, for example). > > > Is there a way to import templatetags from another project? > > Reuse is much easier once you think in terms of applications, rather > than projects. A project is just a collection of applications (really, > it's just a settings file and maybe a root URLConf). So you can easily > share an application in two projects, since applications can be imported > from anywhere on your Python path, as you've noted. > > So, if you *only* want to share the template tags and nothing else from > their current application, make a new application that only contains > those template tags. Then you can install that application into both > projects (by including the import path in INSTALLED_APPS in each > project's settings file) and the code will be shared as you would > expect. As mentioned in a thread earlier today on this list, loading a > template tag in a template will cause all the installed apps to be > searched for that template tag file, so you don't need to worry about > keeping the tags right next to the templates they are used in. > > > Django is really great framework, but I have a gut feeling that Django > > support for code reuse is significantly worse, than, say, in Plone/ > > Zope 3. Though it might be because of my relative inexpirience in > > Django. > > It's due to your inexperience, I suspect. Almost everything in Django > operates through normal Python imports, so you can share any code that > is on your Python path. The only real constraints are that template tags > are loaded from a directory called templatetags/ that must live in an > application directory and models must live in a module called "models". > Everything else is free-form and entirely under your control. > > Regards, > Malcolm > > -- > Depression is merely anger without > enthusiasm.http://www.pointy-stick.com/blog/ --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Sharing code between two projects
Hello, I have two projects, they were developed independently. They will be run on the same server and have many things in common (notably some models and templatetags). While I can import models from another project if it is on PYTHONPATH, I cannot find a way to share templatetags. I don't want to copy them, because maintaining costs would become higher (need to remember to apply bug fixes in both places, for example). Is there a way to import templatetags from another project? Django is really great framework, but I have a gut feeling that Django support for code reuse is significantly worse, than, say, in Plone/ Zope 3. Though it might be because of my relative inexpirience in Django. I would be very grateful if someone will point me to pages/blog entries about how to write Django apps with reusability in mind. Eugene --~--~-~--~~~---~--~~ 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: Development times
Thanks. In my project I've spent many hours learning Django, trying to correctly implement support for i18n for everything from models to templates (ended up using django-multlingual) and writing unit tests (although I don't have a 100% coverage, far from it). The site I'm building uses almost every feature of Django, some third- party apps (most notably django-multilingual and django-tagging), and custom templatetags, filters and middleware that I've written specifically for it. I guess if I'd need to build a second site, I'll do it much more quickly. Eugene On 21 июн, 05:15, Bryan Veloso <[EMAIL PROTECTED]> wrote: > I've only developed two sites, a blog and a dynamic scoreboard, having > no prior python experience. > > The blog took about 4 weeks, with a lot of help, and it's still not > done due to some limitations I've hit with the framework (or > limitations in my own knowledge). > The scoreboard I just finished an "alpha" of, and that took me less > than 2 weeks. :) > > On Jun 20, 2:00 pm, Eugene Morozov <[EMAIL PROTECTED]> wrote: > > > Hello, > > I'm interested how much time it took to develop some Django sites. > > Just curious to compare my performance against others. > > > Currently, I have developed only a single Django site (it is very > > complex and is actually only 90% ready). It took two months to > > develop, I have detailed log created using beautiful gtimelog program. > > Although I've started using it in the middle of the project, so I > > don't have exact data how much time I spent on models, logic or HTML > > layout (the lest interesting and most time-consuming part of the > > project). > > Eugene --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Development times
Hello, I'm interested how much time it took to develop some Django sites. Just curious to compare my performance against others. Currently, I have developed only a single Django site (it is very complex and is actually only 90% ready). It took two months to develop, I have detailed log created using beautiful gtimelog program. Although I've started using it in the middle of the project, so I don't have exact data how much time I spent on models, logic or HTML layout (the lest interesting and most time-consuming part of the project). Eugene --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
gettext_lazy and string interpolation
Hello, What is the correct way to use gettext_lazy with string interpolation? Aren't there built-in facilities for this in the Django? Eugene --~--~-~--~~~---~--~~ 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: Jasper Reports
On 12 июн, 04:53, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: > Has anyone successfully used Jasper Reports on the server being called > from a Django view? I've implemented a Jasper server in Jython. It listens on some network port and generates Jasper reports based on data incoming from socket. The data was sent by a Django application. This was work for hire, so I cannot share the sources. But it is really easy to use Jasper within Jython. And if it is possible to run Django under Jython, the task would become even simpler. Eugene --~--~-~--~~~---~--~~ 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: Unicode-branch: testers wanted
On 24, 17:06, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
> Hi folks,
>
> The unicode branch, [1], is now at a point where it is essentially
> feature-complete and could do with a bit of heavy testing from the wider
> community.
>
> So if you have some applications that work against Django's current
> trunk and would like to try them out on the unicode branch, I'd
> appreciate your efforts. The porting effort should be very minimal
> (almost zero, in many cases).
Hello,
I've checked out unicode branch today and immediately found two bugs.
This code doesn't work:
def __unicode__(self):
langs = dict(settings.LANGUAGES)
return _("%s text of the page %s") % (langs[self.language],
self.page.url)
(I get TypeError: unsupported operand type(s) for %: '__proxy__' and
'tuple')
The second bug is actually the unicode bug that was present in non-
unicode django and still persists in unicode branch. Unicode data
fetched from postgresql using psycopg2 is invalid under some
circumstances. I'll provide more details when I'll have time.
Eugene
>
> For code that is only meant to work with ASCII data, there are probably
> no changes required at all. For code that is meant to work with all
> kinds of input (essentially, arbitrary strings), there are a few quick
> porting steps required.
>
> See [2] for the short list (5 steps, maximum!) of changes you might need
> to make. For more detailed information, have a read through the
> unicode.txt document in the docs/ directory of the branch.
>
> Any bugs you find should be filed in Trac. Put "[unicode]" at the start
> of the summary title so that I can search for them later. No need to put
> any special keywords or anything like that in (the "version" field
> should be set to "other branch", if you remember).
>
> A couple of things to watch out for when you're testing:
>
> (A) Strings that seem to mysteriously disappear, but when you
> examine the source, you see something like
> "".
> These shouldn't be too common and will mostly be restricted to
> places like the admin interface that do introspection.
>
> (B) Translations that happen too early. If you have translations
> available and use your app in a language that is different from
> the LANGUAGE_CODE setting, watch out for any strings that are
> translated into LANGUAGE_CODE, instead of your current locale.
> This is a sign that ugettext() is being used somewhere that
> ugettext_lazy() should be used.
>
> (C) If you're using Python 2.3, look for strings that don't make
> much sense when printed. That is a sign that a bytestring is
> being used where a unicode string was needed (not your fault;
> it's an oversight in Django). Python 2.3 has some
> "interesting" (I could use nastier words) behaviour when it
> tries to interpolate non-string objects into unicode strings (it
> doesn't call the __unicode__ method!!) and we have to work
> around them explicitly. I think I've got most of them, but I'll
> bet I have overlooked some.
>
> Most bugs that people are finding at the moment fit into one of these
> categories and they are very easy to fix once we find them. I've tried
> to nail most of them in advance, but you can probably imagine how
> exciting it is to read every line of source code and try to find all the
> strings that are in a precise form that need changing. My attention may
> have drifted from time to time.
>
> Have realistic expectations about this branch, too. It is meant to be as
> close to 100% backwards-compatible as we can make it. So, for example,
> usernames still have to use normal ASCII alphabetic characters, etc.
> Similarly, the slugify filter still behaves as it did before. At some
> point it will be extended to handle a _few_ more non-ASCII characters,
> but it's never going to be a full transliteration function. They are the
> two big items I expect people would otherwise try to extend beyond what
> is intended. There may be others and I'm sure we'll discover what they
> are as the questions pop up.
>
> [1]http://code.djangoproject.com/wiki/UnicodeBranch
> [2]http://code.djangoproject.com/wiki/UnicodeBranch#PortingApplicationsT...
>
> 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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---
Re: Template question
On 2 июн, 17:37, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
> On Sat, 2007-06-02 at 06:07 -0700, Eugene Morozov wrote:
> > Hello,
> > I have a question which might be trivial to answer, but I didn't found
> > answer by scanning the docs.
> > In my base template I have defined inset block:
> >
> > {% block inset %}{% endblock %}
> >
> > I want to remove tags if derived template
> > doesn't fill in the inset block. Of course I can add the tags to all
> > inset blocks in the derived templates, but this would look bad and
> > contradict DRY principle.
>
> No, there isn't any builtin way to do this. Is having an empty
> element really a problem?
Thanks for answer. The problem is that the div has borders and it
messes design a little bit when it's empty.
Eugene
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Another suggestion for django-multilingual
Hello, I found another deficiency in django-multilingual. I'm sure that on many sites, including the one I'm developing now, there would be one primary language for content and translations will appear slowly after the content in the primary language is published. I want to display content in primary language if there's no translation for currently selected language. Unfortunately, there's no such a feature in django- multilingual and implementing it would require learning django ORM internals. Eugene --~--~-~--~~~---~--~~ 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: Django, Postgres and Core Dumps
Hello, Here it is: https://bugs.launchpad.net/bugs/108067 I've planned to make a public repository with fixed packages, but I'm too busy for this. Anyway, you can take Feisty package, replace source code with downloaded 2.0.6 source code from psycopg site, bump version number in debian changelog and build the new package. It's easy, I've done it in less than 10 minutes. Eugene On 26 май, 16:54, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > On Sat, 2007-05-26 at 12:42 +0000, Eugene Morozov wrote: > > python-psycopg2 package in Ubuntu Feisty for x86-64 is completely > > broken. I've reported it in the Launchpad on the next day after > > release, but maintainer is still reluctant to apply patch which should > > fix 64 bit issues. > > Ha ha! Problem understood, at least then. > > Do you have a Launchpad bug number for this, Eugene (or, better, a URL)? > It'd be nice to know so that we can point others to it if they hit the > same problems. > > 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Django, Postgres and Core Dumps
python-psycopg2 package in Ubuntu Feisty for x86-64 is completely broken. I've reported it in the Launchpad on the next day after release, but maintainer is still reluctant to apply patch which should fix 64 bit issues. I've solved the problem by downloading upstream beta version and compiling a custom package from it. Eugene On 26 май, 07:51, "Grant D. Watson" <[EMAIL PROTECTED]> wrote: > I'm a newbie to Django. It looks amazing, and I've > decided to give it a whirl, but when I try a syncdb on > my new project I get a core dump; the only things I've > changed in settings.py are ADMINS and DATABASE_*. > Given the context I assume it's something to do with > the psycopg2 library and Django? > > I'm running Ubuntu Feisty (amd64) with repository > versions of Python (2.5.1c1), PostgreSQL (8.2.4) and > python-psycopg2 (2.0.1.5-6). I'm using Django 0.96 > installed with setup.py. > > I suspected the sameuser identification for Postgres > was causing problems, but I changed it to md5 with no > luck. > > I wasn't able to find anything terribly helpful on the > web or in the list archives. Does anybody know what > might be causing this? > > Grant D. Watson, <[EMAIL PROTECTED]> > > > Shape > Yahoo! in your own image. Join our Network Research Panel today! > http://surveylink.yahoo.com/gmrs/yahoo_panel_invite.asp?a=7 --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Middleware tests location
Hello, I have a custom middleware class that would be used project-wide. I've put it in the 'middleware' subdirectory of my project because it doesn't really belong to any app. The question is where to put tests for such code that exists outside of any application? Django default test runner only runs tests for installed applications. Should I write custom test runner, or create a fake application that will consolidate tests for all project libraries? Eugene --~--~-~--~~~---~--~~ 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: Another problem with django-multilingual
Hello,
Thank you for fixing the bug so quickly. But if you'll add
'i18n.multilingual' to the list of installed apps in the settings.py
in the example I've attached to #22, then "manage.py runserver" or
"manage.py syncdb" commands stop working with exception
"AttributeError: 'module' object has no attribute 'multilingual'"
Eugene
On 23 май, 00:06, "[EMAIL PROTECTED]"
<[EMAIL PROTECTED]> wrote:
> Hi Eugene,
>
> On May 22, 5:44 pm, Eugene Morozov <[EMAIL PROTECTED]> wrote:
>
> > I'm trying to use django-multilingual for multilingual site, instead
> > of reinventing the wheel. But in admin interface I get:
> > "Something's wrong with your database installation. Make sure the
> > appropriate database tables have been created, and make sure the
> > database is readable by the appropriate user." for every translatable
> > model.
>
> A knee-jerk question here is: did you remember to run syncdb after
> creating the translatable models? If you did, try again and make sure
> there were no validation errors.
>
> > slug = models.SlugField(prepopulate_from=("name",))
>
> The prepopulate_from parameter contains a nonexistant field name (you
> probably wanted to use "title" instead), but apparently Django does
> not validate it. I just pasted your Entry model into one of apps in
> my testproject, added missing models (Author, Blog and Picture) and it
> simply worked for me.
>
> If syncdb does not help, then please try to create a minimal test app
> for the problem and post it to django-multilingual bug tracker (http://
> code.google.com/p/django-multilingual/).
>
> -mk
--~--~-~--~~~---~--~~
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: Another problem with django-multilingual
In addition to this issue, I'm getting SQL errors on attempts to save
multilingual objects, because of such invalid constructs:
LEFT JOIN blog_blogtranslation AS blog_blogtranslation_zh-cn ON
((blog_blogtranslation_zh-cn.master_id = blog_blog.id) AND
(blog_blogtranslation_zh-cn.language_id = 38))
Aliases must be quoted by django, but they aren't. I've tried to find
what causes this quoting error but gave up after two hours... Need to
get some sleep.
Did anyone attempted to use django-multilingual?
Eugene
On 22 май, 19:44, Eugene Morozov <[EMAIL PROTECTED]> wrote:
> Hello,
> I'm trying to use django-multilingual for multilingual site, instead
> of reinventing the wheel. But in admin interface I get:
> "Something's wrong with your database installation. Make sure the
> appropriate database tables have been created, and make sure the
> database is readable by the appropriate user." for every translatable
> model. For example, I have a model for blog entry:
>
> class Entry(models.Model):
> author = models.ForeignKey(Author, related_name="entries")
> blog = models.ForeignKey(Blog, related_name="entries")
> pictures = models.ManyToManyField(Picture, blank=True,
> related_name="entries")
> comments_allowed = models.BooleanField(_("Comments allowed"))
> posted = models.DateTimeField(_("Date posted"), auto_now_add=True)
>
> class Translation(multilingual.Translation):
> title = models.CharField(_("Title"), maxlength=250,
> help_text=_("Title of the entry"))
> slug = models.SlugField(prepopulate_from=("name",))
> body = models.TextField(_("Body"))
>
> As you see, it has both translatable and non-translatable fields. I'm
> running Django-0.96 on python2.5. I use psycopg2 db adapter.
> Eugene
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Another problem with django-multilingual
Hello,
I'm trying to use django-multilingual for multilingual site, instead
of reinventing the wheel. But in admin interface I get:
"Something's wrong with your database installation. Make sure the
appropriate database tables have been created, and make sure the
database is readable by the appropriate user." for every translatable
model. For example, I have a model for blog entry:
class Entry(models.Model):
author = models.ForeignKey(Author, related_name="entries")
blog = models.ForeignKey(Blog, related_name="entries")
pictures = models.ManyToManyField(Picture, blank=True,
related_name="entries")
comments_allowed = models.BooleanField(_("Comments allowed"))
posted = models.DateTimeField(_("Date posted"), auto_now_add=True)
class Translation(multilingual.Translation):
title = models.CharField(_("Title"), maxlength=250,
help_text=_("Title of the entry"))
slug = models.SlugField(prepopulate_from=("name",))
body = models.TextField(_("Body"))
As you see, it has both translatable and non-translatable fields. I'm
running Django-0.96 on python2.5. I use psycopg2 db adapter.
Eugene
--~--~-~--~~~---~--~~
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: adding XSLT templating to Django
On 12 май, 17:08, Nic James Ferrier <[EMAIL PROTECTED]> wrote: > Eugene Morozov <[EMAIL PROTECTED]> writes: > > Sorry, I don't get the point. I think that XSLT is a way to separate > > presentation from data. But your json looks like some kind of HTML. I > > don't understand how this is better than existing Django templates. > > It has several advantages: > > - there is proper separation between data and style, my JSON doesn't > include any stylistic information, only stuff that describes the data I still think that your example is not the best. "div" and "span" has no semantic meaning, they're just HTML placeholders. > - the JSON template *is* python, you can pretty much do anything with > it: you can separate bits of the rendering with different methods, > you can test it outside of Django, you can pass it around and > process it with Python quite naturally. This is valid point. > > - you get JSON output if you want it, direct from your view This is valid point, too. > - you get to use XSLT to turn the JSON into anything you want... you > need Atom from a resource as well as HTML? Just have 2 different > stylesheets but the same JSON. I think it is possible with plain Django templates, too. Just define 2 different templates. Your small framework could be really useful in some situations, I was just thinking about how to apply my XSLT knowledge to ease web development tasks. But I think that need better examples really showing benefits of XSLT approach. I was turned off by those HTML elements in JSON data immediately. Maybe this is just my personal opinion. Eugene --~--~-~--~~~---~--~~ 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: adding XSLT templating to Django
Hello Nic,
On 11 май, 13:23, Nic James Ferrier <[EMAIL PROTECTED]>
wrote:
> def user_alerts(request, user_name):
> me = get_object_or_404(User, username=user_name)
> alerts = Alert.objects.filter(user=me, seen=False)
> return tfxslt.send_json(HttpResponse(),
> { "div":
> [ { "abbr":
> { "@title": alert.created,
> "span": alert.message }} for alert in
> alerts]},
> xslt="user_alerts")
>
Sorry, I don't get the point. I think that XSLT is a way to separate
presentation from data. But your json looks like some kind of HTML. I
don't understand how this is better than existing Django templates.
I know and use XSLT but usually for converting between different XML
formats.
Eugene
--~--~-~--~~~---~--~~
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: django i18n and google bots
I think there's no other solution as to use language designator in URLs and placing language links on the main page. There's no way Google or any other bot can crawl the site several times with different cookies or something. Currently I'm redoing site in Django that suffers the same problem and it was a design decision to use googlebot-friendly urls. Eugene On 2 май, 12:16, Phil <[EMAIL PROTECTED]> wrote: > Guys, > > I use the i18n framework of django to offer my site content in two > language: French and English. As the language preference is kept in a > cookie, all the URLs of my site are therefore language agnostic. All > is working fine. > > But, when the googlebots hits my site, they only hit the French- > translated content! > I checked the cached version of the site in google and all the pages > are in French. > > Has somebody already given some thoughts on this and found a solution, > or do I will have to change my URLs as to have to sets, one in English > and one in French > (http://www.mysite.com/path/to/url/fr/andhttp://www.mysite.com/path/to/url/en/) > or something equivalent ? > > Phil. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Django for complex websites
Hello, I have a Zope background and new to Django and mainly interested how people build large websites with it. Imagine a portal with many kinds of sections: blogs, forums, articles, faqs, etc. Building such site on Zope platform is more or less straightforward. As underlying storage is an object oriented database, every page is an object. Different sections can exhibit different behavior because they're different objects. Very simple. If you need to build a sitemap or menu or breadcrumbs, you can travel the objects tree and build it. You can attach a new page (section) with arbitrary functionality to any node of the site tree with no effort. On the other hand, Django uses ORM and this means that each site section must be separate application with corresponding database and URL mappings. It seems to me that building large site with different kinds of sections would be harder in Django. There would be code duplication and too much manual work to maintain url mappings and hardcoded hierarchy. I don't want to start Zope vs Django flame. I just want to know what approaches people use for building large sites on Django. Thanks in advance, Eugene --~--~-~--~~~---~--~~ 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: Django unit tests and unicode problem
Hmm, I've figured how to inspect context in the test by reading django
sources.
But that didn't help greatly, because context['translation'].content
(translation is a model for translated pages content) still returns
doubly encoded utf-8 data. By the way, the page in browser is rendered
correctly. Does anyone has suggestions how to test i18n features in
Django apps?
Eugene
On 29 апр, 17:07, Eugene Morozov <[EMAIL PROTECTED]> wrote:
> Hello,
> I'm new to django (using it only for two weeks and I was reading
> django tutorial, documentation and book for the first week).
>
> I'm writing unit tests for my CMS similar to built-in flatpages CMS,
> but with builtin i18n features and other things required for full-
> fledged CMS.
>
> I cannot use standard django test client because it doesn't work with
> middleware intercepting 404 errors (I didn't investigate why, because
> I've thought that testing view manually would be easier).
> Unfortunately, I was wrong. When I'm trying to test i18n features,
> response.content returns non-ascii text *doubly* encoded in utf-8.
> First invocation of response.content.decode('utf-8') returns unicode
> object that contains utf-8 encoded original string. I can find some
> tricky way to decode unicode object again using struct module or
> something, but I don't understand why django encodes content twice.
> And how test client gains access to template context.
>
> Will look at the sources meanwhile, but would be very grateful if
> someone will explain.
> Eugene
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Django unit tests and unicode problem
Hello,
I'm new to django (using it only for two weeks and I was reading
django tutorial, documentation and book for the first week).
I'm writing unit tests for my CMS similar to built-in flatpages CMS,
but with builtin i18n features and other things required for full-
fledged CMS.
I cannot use standard django test client because it doesn't work with
middleware intercepting 404 errors (I didn't investigate why, because
I've thought that testing view manually would be easier).
Unfortunately, I was wrong. When I'm trying to test i18n features,
response.content returns non-ascii text *doubly* encoded in utf-8.
First invocation of response.content.decode('utf-8') returns unicode
object that contains utf-8 encoded original string. I can find some
tricky way to decode unicode object again using struct module or
something, but I don't understand why django encodes content twice.
And how test client gains access to template context.
Will look at the sources meanwhile, but would be very grateful if
someone will explain.
Eugene
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Django unit tests and unicode problem
Hello,
I'm new to django (using it only for two weeks and I was reading
django tutorial, documentation and book for the first week).
I'm writing unit tests for my CMS similar to built-in flatpages CMS,
but with builtin i18n features and other things required for full-
fledged CMS.
I cannot use standard django test client because it doesn't work with
middleware intercepting 404 errors (I didn't investigate why, because
I've thought that testing view manually would be easier).
Unfortunately, I was wrong. When I'm trying to test i18n features,
response.content returns non-ascii text *doubly* encoded in utf-8.
First invocation of response.content.decode('utf-8') returns unicode
object that contains utf-8 encoded original string. I can find some
tricky way to decode unicode object again using struct module or
something, but I don't understand why django encodes content twice.
And how test client gains access to template context.
Will look at the sources meanwhile, but would be very grateful if
someone will explain.
Eugene
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
