Maciej Bliziński | 1 Dec 01:50 2006
Picon

Re: Django + FastCGI Problems


Mike,

I was experiencing the same problems: incomplete headers and timeouts.
I did a simple trick that made my Django application run smoothly.
Perhaps you can try the same thing (it requires simple changes). I
described it on my blog:

http://automatthias.wordpress.com/2006/12/01/django-on-dreamhost-incomplete-headers/

I haven't thoroughly verified it, it's an ongoing investigation. Maybe
you could try the same thing. I'd like to know if it works for other
people as well.

Cheers,
Maciej

--~--~---------~--~----~------------~-------~--~----~
 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 <at> googlegroups.com
To unsubscribe from this group, send email to django-users-unsubscribe <at> googlegroups.com
For more options, visit this group at http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---

tchoukharev | 1 Dec 02:00 2006
Picon

Re: Why not Django


Victor Ng wrote:

> If user A and user B are editting the same records and you enter a
> race where they do this:
>
> A) retrieve record

Here you mean SELECT FOR UPDATE, right?

> B) retrieve record

Same here, right?

> A) delete record
> B) update record

As SELECT FOR UPDATE starts a transaction, these two
are in concurrent transactions, right?

> The select for update that user B uses will succeed since the select
> will simply return 0 rows.  The update will succeed because 0 rows are
> updated successfully.

The update will not be tried if its SELECT FOR UPDATE returns 0 rows,
since there is nothing to update. The UPDATE will be made only if
SELECT FOR UPDATE returns exactly 1 row. Otherwise the transaction
is rolled back and the client informed that he needs to try again (and
why). The transaction is commited after the last table is UPDATED.
On any error the transaction is rolled back.
(Continue reading)

noods | 1 Dec 02:36 2006
Picon

Dynamically modifying AdminOptions


Hi all,

I'm trying to create a custom field which will automatically include
some required JavaScript libraries in the admin interface, without
having to modify contrib.admin. Currently I have a custom model field
defined as follows:

class RichTextField(models.TextField):
    "A rich text editor field which provides a WYSIWYG editor
component."
    def contribute_to_class(self, cls, name):
        # Automatically add TinyMCE JavaScript libraries.
        opts = cls._meta
        opts.admin.js.append('js/tiny_mce/tiny_mce.js')
        opts.admin.js.append('js/tiny_mce/textareas.js')

    def get_manipulator_field_objs(self):
        return [common_forms.RichTextField]

My idea was to have the field automatically append the required
JavaScript libs to the model AdminOptions js list so this would handle
everything for me, but I seem to be having some issues. I get the
following exception:

'NoneType' object has no attribute 'js'

on the first append() line, but if I do a trace print on opts.admin.js
it gives me the contents of the js list as defined in the model admin
opts, and reports it is of type list. I'm not sure why it won't let me
(Continue reading)

noods | 1 Dec 02:47 2006
Picon

Re: Dynamically modifying AdminOptions


Oops, I made an error copying my code across. I forgot to call the
parent class' contribute_to_class method:

class RichTextField(models.TextField):
    "A rich text editor field which provides a WYSIWYG editor
component."
    def contribute_to_class(self, cls, name):
        # Automatically add TinyMCE JavaScript libraries.
        opts = cls._meta
        opts.admin.js.append('js/tiny_mce/tiny_mce.js')
        opts.admin.js.append('js/tiny_mce/textareas.js')
        super(RichTextField, self).contribute_to_class(cls, name)

    def get_manipulator_field_objs(self):
        return [common_forms.RichTextField]

--~--~---------~--~----~------------~-------~--~----~
 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 <at> googlegroups.com
To unsubscribe from this group, send email to django-users-unsubscribe <at> googlegroups.com
For more options, visit this group at http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---

Victor Ng | 1 Dec 03:17 2006
Picon

Re: Why not Django


On 11/30/06, tchoukharev <at> mail.ru <tchoukharev <at> mail.ru> wrote:
>
> Victor Ng wrote:
>
> > If user A and user B are editting the same records and you enter a
> > race where they do this:
> >
> > A) retrieve record
>
> Here you mean SELECT FOR UPDATE, right?

No, I mean SELECT.

The use case is two users are viewing the same record, and they both
go to update the same record.

That means the view code would SELECT the records into the view.  I'm
assuming you're doing SELECT FOR UPDATE and UPDATE on the POST
request/response cycle.  If you're actually doing a SELECT FOR UPDATE
on the initial request, I can't see how you're holding on to your
connection between request response cycles.

vic

--~--~---------~--~----~------------~-------~--~----~
 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 <at> googlegroups.com
To unsubscribe from this group, send email to django-users-unsubscribe <at> googlegroups.com
For more options, visit this group at http://groups.google.com/group/django-users?hl=en
(Continue reading)

Istvan Albert | 1 Dec 03:57 2006
Picon

Re: Why not Django


Fredrik Lundh wrote:

> that's probably because they're scientists, and have a pretty good
> understanding of basic math

I think the main reason might be that when they get it wrong they don't
have to pay the difference from their own pocket. 

i.

--~--~---------~--~----~------------~-------~--~----~
 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 <at> googlegroups.com
To unsubscribe from this group, send email to django-users-unsubscribe <at> googlegroups.com
For more options, visit this group at http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---

James Bennett | 1 Dec 04:07 2006
Picon

Re: Re: Why not Django


On 11/30/06, Istvan Albert <istvan.albert <at> gmail.com> wrote:
> I think the main reason might be that when they get it wrong they don't
> have to pay the difference from their own pocket.

Depends.

The engineers will tell you it's within tolerance for the system.
The scientists will tell you it's experimental error and can be disregarded.
The mathematicians will tell you that they can't be bothered to solve
this because it's trivial.

And the programmers will tell you it's a feature ;)

Now, does anybody want to talk about Django?

--

-- 
"May the forces of evil become confused on the way to your house."
  -- George Carlin

--~--~---------~--~----~------------~-------~--~----~
 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 <at> googlegroups.com
To unsubscribe from this group, send email to django-users-unsubscribe <at> googlegroups.com
For more options, visit this group at http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---

Brian Beck | 1 Dec 04:22 2006
Picon

Re: Simple CAS 1.0 authentication


Alright, I'm gonna throw a question out there, maybe someone can help.

As shown above I can intercept the admin index page in order to not
display the login form which doesn't make sense for CAS authentication.
 However, this only works if the user needs to be authenticated and
requests the index page.  If they go directly to /admin/auth/user/ for
example, and aren't authenticated yet, it will show the login form.  I
don't want to duplicate every view in admin like I did for the index
(which just happened to be easy).  But if I had a way to intercept
every admin/ URL, do the custom authentication, then let Django
continue processing URLs (so that it would also reach
django.contrib.admin.urls), it would work.  I realize that the Root
View proposal would probably make this easy, but is it currently
possibly to tell a view to return to the URL processing phase?  Is this
a sign that my app should be middleware instead?

--~--~---------~--~----~------------~-------~--~----~
 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 <at> googlegroups.com
To unsubscribe from this group, send email to django-users-unsubscribe <at> googlegroups.com
For more options, visit this group at http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---

Alan Green | 1 Dec 04:32 2006

Re: Re: Why not Django


On 12/1/06, James Bennett <ubernostrum <at> gmail.com> wrote:

> Now, does anybody want to talk about Django?

Yes!

Is anyone writing financial or money-handling applications in Django?
Any particular issues or "gotchas" the world should know about?

a

--~--~---------~--~----~------------~-------~--~----~
 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 <at> googlegroups.com
To unsubscribe from this group, send email to django-users-unsubscribe <at> googlegroups.com
For more options, visit this group at http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---

Brian Beck | 1 Dec 05:31 2006
Picon

Registering defaults for custom settings


Hi,

If I'm developing middleware or an app that I want a user to be able to
configure in their settings.py, how should I go about setting defaults
in there?  I checked out django.conf, and it just looks like
global_settings.py registers the defaults for every possible module
included with Django.

So for my CAS module for example, I want some values available in
settings.py like CAS_SERVICE_URL and such, and these should have
defaults (even if they're None) so I can always access
settings.CAS_SERVICE_URL.

Here's how I'm doing it now:
defaults = {'CAS_POPULATE_USER': None,
            'CAS_LOGIN_URL': '/accounts/login/',
            'CAS_LOGOUT_URL': '/accounts/logout/',
            'CAS_SERVICE_URL': None,
            'CAS_REDIRECT_FIELD_NAME': 'next',
            'CAS_REDIRECT_URL': '/',
            }

for key, value in defaults.iteritems():
    try:
        getattr(settings, key)
    except AttributeError:
        setattr(settings, key, value)

So now if another app does 'from django.conf import settings', will
(Continue reading)


Gmane