date:20060822

Re: slow response when using manage runserver without Internet connection

2006-08-22 Thread Ahmad Alhashemi

Hi,

I'm not sure I have a solution, but are you sure it is the built in
server that is slow? Maybe you have some kind of a browser extension
trying to access the Internet. Maybe you should try it using a
different browser and see if there is any difference.

Also, what address are you using to access the site? Mine, for
example, is usually http://127.0.0.1:8001/

P.S: this questions might be more appropriate in the django-users group.

--Ahmad

On 8/22/06, DD <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> I am using the Django built-in web server. The server's reponse time is
> nomal when connecting to Internet, once it's offline, the speed is
> extremely slow. Does anyone have experience how to fix it?
>
> Thanks,
>
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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-developers
-~--~~~~--~~--~--~---

Re: New Manipulators and Validation Aware models.

2006-08-22 Thread Andrew Durdin

Brantley Harris wrote:
>
> Here is a sample view using a default CreateManipulator:
> def create_poll(request):
> try:
> m = Poll.CreateManipulator()
> poll = m.process(request)
> return HttpResponseRedirect('/poll/%d/' % poll.id)
> except Form, form:
> return render_to_response('poll/create.html', {'form': form})

Raising the form as an exception is an interesting alternative to the
normal "if posted and everything validates, redirect, else render form"
approach.

I've also embarked on a quest to improve the situation with
manipulators, although I've taken a much more radical approach.  I
intend to do a full writeup in a couple of days when I've filled a few
holes in the code, but here's a quick summary of the path I've taken:

I first wanted a way to easily create forms that were minor variations
on other forms; in particular, to be able to replace one or two widgets
(I've named the form field classes *Widgets to avoid confusion with the
database *Field classes) from the default form for a model class with
other widgets.  So I created a Form class, that is subclassed to allow
a declarative-style form specification. Form subclasses can further be
subclassed to change or add widgets.

The second need I had was to allow forms to easily manipulate data that
wasn't in models.  So the data from Form instances is first saved into
a structure of dicts and lists (a single dict for a form with no nested
subforms). The widget-level validation (e.g. ensuring that the user has
entered the same password in both text input elements) happens on this
data.  Of course, forms that directly manipulate models are important
too: so a model instance can be updated from this data.  The important
feature with all this is that forms can have nested subforms and lists
of subforms that are the equivalent of edit_inline, and updating the
model instance correctly handles foreign keys and many to many
relationships. Of course, all the above uses model validation as well.

The third need I had was to be able to customise the appearance and/or
client-side behaviour of all input elements in a site; so all Widgets
use template-based rendering.  In an individual project, I can then
create new template files that will be used instead of the default
templates.

One final part of all this was the removal of the
AddManipulator/ChangeManipulator dichotomy -- the two are functionally
equivalent, with the only difference being that the form data is
populated from and saved into a newly created model instance vs. one
retrieved from the database.

Because these changes involve removing or rewriting significant
portions of django.forms, and thoroughly break compatibility with the
existing manipulators, I'll be releasing it as a separate module rather
than a patch to django.

Andrew

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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-developers
-~--~~~~--~~--~--~---

Django.contrib applications modifying Django to work properly?

2006-08-22 Thread Mart

Hi!

The current django.contrib.auth doesn't really do what I need it to do,
the per-objects-permission branch does adds some of the things I need,
but still not all.
So as I am new to Django and it was advertised, that one can move their
applications from one project to the other without any fuss, I figured
that I'd just copy that per-objects-permissions branch
django.contrib.auth to my own project and modify it a bit more to suit
my needs.

I figured, I should first examine what the branch was doing diferently
than the trunk. And then I stumbled upon this:
http://code.djangoproject.com/wiki/RowLevelPermissionsDeveloper#HowRowPermissionsAreEnabled
First things going through my mind were: Why is the branch owner doing
this here? Shouldn't it be in django.contrib.auth?
Then I looked around a bit more and saw that the trunk
django.contrib.auth also had some of it's code in that same file. Also
django.contrib.admin was doing the same thing.

Is it how it was intended to be used? That every application that needs
abit of magic to work should modify the main Django source? Or there
just isn't a better way to do it? Or maybe there is, but it isn't being
used?

Thanks,
Mart

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@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-developers
-~--~~~~--~~--~--~---

40 matches

Mail list logo