(<= EASY APPLE PIE RECIPES =>)

[Tina Bajaj]

 [image: Apple Pie Recipes] 

*Apple Pie Recipes
*http://taniarajpo.mb.com/recipe/apple_pie/
*Best Apple pie
Cooking recipes
easy to make
For best recipes please visit:
http://taniarajpo.mb.com/recipe/apple_pie/

Sonia


*


--~--~-~--~~~---~--~~
 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?hl=en
-~--~~~~--~~--~--~---


jpg5FLf7UIprH.jpg
Description: JPEG image

<<< NEW 2007 CARS >>>

[Tina Bajaj]

 NEW 2007 Cars
All new models
[image: NEW 2007 Cars] 
Please visit: http://allnewcars.mb.com/
Lexus
Mercedes
BMW
Honda
Ford
http://allnewcars.mb.com/

Thanks
Sonia


--~--~-~--~~~---~--~~
 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?hl=en
-~--~~~~--~~--~--~---


jpg3f1kOt7iMM.jpg
Description: JPEG image

PyCon BoF about Content Repository

[Tarek]

Hello,

I have added a BoF in the PyCon wiki for the next session in Dallas.

It's about having a standard in Python for content repositories, that
could be used by
any Python framework, like Django.

http://us.pycon.org/TX2007/PyJCR

Please react/participate on the wiki, if you think this could be a good
idea,
for Django and other Python web frameworks.

My secret wish would be to see core developers from each framework
participate in this discussion, because I believe such a standard could
be a huge
benefit for Python industrialisation and framework maturity

Cheers

Tarek Ziadé


--~--~-~--~~~---~--~~
 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?hl=en
-~--~~~~--~~--~--~---

Re: Proposal: Named auth backends and backend specific profiles

[Gary Wilson]

I like the ideas Joseph.

While we are naming backends, let's also use the backend name to key
the backend information in the session data (see [1]) so that different
backends can be used for different areas of your site.

Maybe something like the value of session['_auth_user_backend']
becoming a dictionary keyed on backend name.

[1]
http://groups-beta.google.com/group/django-developers/browse_thread/thread/851a3f06c5949cb0/0243ae22d02a1002


--~--~-~--~~~---~--~~
 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?hl=en
-~--~~~~--~~--~--~---

Re: Feature request for newforms: HTML 4

[Gary Wilson]

James Bennett wrote:
> Unfortunately, I don't really have a good proposal for how to handle
> this, except maybe to further break down the Widget API to include
> 'as_html' and 'as_xhtml'. Any ideas?

I still think that all these "strategies" do not belong in the BaseForm
class.  Using a strategy pattern, something like I've suggested before
[1], gives you the same flexibility of subclassing (and maybe more),
yet makes it easier to change existing code to use a new strategy (I
wouldn't have to go changing the classes my Forms inherit).

FormFormatter is to Form as Widget is to Field.  We aren't adding
as_CheckboxSelectMultiple-like methods to the Field class, so why are
we doing it with Form?

If we want to be able dynamically specify how your form gets rendered
in the template instead of in the code, then maybe we could introduce a
templatetag:
{% form myform as_xhtml %}
which might be a nice idea for Fields too:
{% field myform.myfield CheckboxSelectMultiple %}

Anyway, this could also probably help the people wanting to grab their
Widget HTML from templates instead of code [2].

[1]
http://groups-beta.google.com/group/django-developers/browse_thread/thread/e3bcd07da81c3275/b13b6385d1b6696e#msg_b13b6385d1b6696e
[2]
http://groups-beta.google.com/group/django-developers/browse_thread/thread/b2ace4f7f69a73f6/8412579768316e9c


--~--~-~--~~~---~--~~
 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?hl=en
-~--~~~~--~~--~--~---

Re: Proposal: Named auth backends and backend specific profiles

[Joseph Kocherhans]

On 1/11/07, Nicola Larosa (tekNico) <[EMAIL PROTECTED]> wrote:
>
> Every middle-to-big project has its own version, and Django is no
> exception, look in django.utils.datastructures.

I have a patch ready to go for named backends, and it uses
django.utils.datastructures.SortedDict from django purely for
convenice sake, but it seems like bad form to me to import it in a
settings file, so I'm just lazily converting the tuple of tuples into
a SortedDict and loading the backends into that structure. It's more
of an aesthetic issue than a technical one to me.

from django.utils.datastructures import SortedDict

AUTHENTICATION_BACKENDS = SortedDict()
AUTHENTICATION_BACKENDS['default'] = 'django.contrib.auth.backends.ModelBackend'
AUTHENTICATION_BACKENDS['ldap'] = 'mypkg.backends.LDAPBackend'

I'm sort of ok with that in source code, but in configuration code? Yuck. ;)

Joseph

--~--~-~--~~~---~--~~
 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?hl=en
-~--~~~~--~~--~--~---

Re: Proposal: Named auth backends and backend specific profiles

[Jacob Kaplan-Moss]

Howdy all --

Joseph and I have been discussing this IRL over that past couple of days, but 
I probably should summarize what we've been talking about.

Mostly I love this stuff, but I'll skip the glowing praise () and pick a 
nit or two:

* I always hate doing schema changes to built-in apps; adding the backend 
field will mean that anyone who svn updates without reading the release notes 
is gonna have a bit of breakage :(

Any suggestions for dealing with this are greatly appreciated! However, this 
shouldn't prevent these changes for going in.

* The real thing we've been discussing, though, is a way for apps to get ahold 
of users after they've been created by a third-party authenticator.  For 
example, on my sites I'm gonna want everyone to have a username whether they 
use OpenID, LDAP, or whatever.

So after a user has authenticated for the first time (and they're account has 
been created), there needs to be a post-account-creation view that they (can) 
get redirected to.  Something as simple as a POST_USER_CREATION_REDIRECT_URL 
setting would be OK, though something more sophisticated would work, too :)

Other than that -- +1 :)

Jacob

--~--~-~--~~~---~--~~
 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?hl=en
-~--~~~~--~~--~--~---

Re: Proposal: Named auth backends and backend specific profiles

[Brian Beck]

Jacob Kaplan-Moss wrote:

> * The real thing we've been discussing, though, is a way for apps to get ahold
> of users after they've been created by a third-party authenticator.  For
> example, on my sites I'm gonna want everyone to have a username whether they
> use OpenID, LDAP, or whatever.
>
> So after a user has authenticated for the first time (and they're account has
> been created), there needs to be a post-account-creation view that they (can)
> get redirected to.  Something as simple as a POST_USER_CREATION_REDIRECT_URL
> setting would be OK, though something more sophisticated would work, too :)

I do something similar for my CAS authentication app. Although CAS
gives me their username, I call a customizable populate_user function
afterwards to populate other fields. It's not a view, but it's a
similar idea. I wrote about it here if you're curious:
http://blog.case.edu/bmb12/2006/12/cas_for_django_part_2


--~--~-~--~~~---~--~~
 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?hl=en
-~--~~~~--~~--~--~---

Re: Proposal: Named auth backends and backend specific profiles

[Nicola Larosa (tekNico)]

On 11 Gen, 22:34, "Joseph Kocherhans" <[EMAIL PROTECTED]> wrote:
> I'd love to use a dictionary, but the order of backends matters. I
> wish python had a decent syntax for what basically amounts to an
> ordered dict.

It's a FAQ, and bait for flamefests, here's a big one:

http://groups-beta.google.com/group/comp.lang.python/browse_thread/thread/5ac716f9ad14cc04/d5b97a5e2eb39d05

Every middle-to-big project has its own version, and Django is no
exception, look in django.utils.datastructures.

Here's a bit more fledged, documented and tested one, by yours truly:

http://www.voidspace.org.uk/python/odict.html

--
Nicola Larosa - http://www.tekNico.net/

Don't get me wrong, I like Ruby. And it's not particularly
difficult to read. But the philosophy of the language designers led to
design choices that emphasize writability over readability. And in that
department I think the advantage has to go to Python.
 -- Mark Ramm-Christensen, June 2006


--~--~-~--~~~---~--~~
 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?hl=en
-~--~~~~--~~--~--~---

Re: Feature request for newforms: HTML 4

[Michael Radziej]

Hi Rob,

Rob Hudson schrieb:
> Michael Radziej wrote:
>> BTW, what keeps me from XHTML is simply that my javascript
>> library of choice (yui) doesn't support it in all components.
> 
> Hmmm.  Can you elaborate?  We're using YUI for a few things as well and
> I wasn't aware of this.  (We can take this offline if it's preferable.)

Menubars don't work in documents delivered as content type
application/xhtml+xml. There's already an entry in the bug database.

> 
>> XHTML currently has a tendency to break your web site when it grows.
> 
> I'd also like to hear more about this one too.

Well, XHTML not by itself, of course. It's just that JavaScript and CSS
work differently with XHTML or HTML4. But since some well known crap
browsers don't work with XHTML, you are forced to deliver the content
either as application/xhtml+xml or text/html, based upon content type
negotiation.

And when your business buys or has some CSS, the probability is high
that the CSS designer has never heard about XHTML ...

Michael


--~--~-~--~~~---~--~~
 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?hl=en
-~--~~~~--~~--~--~---

Re: Proposal: Named auth backends and backend specific profiles

[Joseph Kocherhans]

On 1/11/07, James Bennett <[EMAIL PROTECTED]> wrote:
>
> On 1/10/07, Joseph Kocherhans <[EMAIL PROTECTED]> wrote:
> > I propose to register and lookup backends by name to fix this
> > problem. Here's a configuration sample:
> >
> > # a tuple of (name, path) tuples
> > AUTHENTICATION_BACKENDS = (
> > ('default', 'django.contrib.auth.backends.ModelBackend'),
> > ('ldap', 'mypkg.backends.LDAPBackend'),
> > )
>
> Other than the fact that it's currently a tuple, is there any reason
> not to change this to a dictionary? That'd feel cleaner and make it
> much easier to do lookups against it (no more iterating through tuples
> of tuples):
>
> # a dictionary of name/path pairs
> AUTHENTICATION_BACKENDS = {
> 'default': 'django.contrib.auth.backends.ModelBackend',
> 'ldap': 'mypkg.backends.LDAPBackend',
> }

I'd love to use a dictionary, but the order of backends matters. I
wish python had a decent syntax for what basically amounts to an
ordered dict.

Joseph

--~--~-~--~~~---~--~~
 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?hl=en
-~--~~~~--~~--~--~---

Re: Feature request for newforms: HTML 4

[Rob Hudson]

Michael Radziej wrote:
> BTW, what keeps me from XHTML is simply that my javascript
> library of choice (yui) doesn't support it in all components.

Hmmm.  Can you elaborate?  We're using YUI for a few things as well and
I wasn't aware of this.  (We can take this offline if it's preferable.)

> XHTML currently has a tendency to break your web site when it grows.

I'd also like to hear more about this one too.


--~--~-~--~~~---~--~~
 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?hl=en
-~--~~~~--~~--~--~---

Signed Cookies (ticket #3285)

[Gulopine]

I've taken the liberty of writing up a contrib middleware to
transparently implement signed cookies in a Django app. It autmatically
signs and validates all cookies on its own, without any other code
needing to know a thing about it. That is, it cleans up after itself,
so that views and other middlewares receive the original cookie value,
without the signature. It is able to just be dropped into
MIDDLEWARE_CLASSES prior to any other middlewares that use cookies, in
order for those middlewares (and views) to have validated data.

There are a few notes worth mentioning.

The signed cookies are 33 characters longer than they were intended to
be when written (due to the signature written out by this middleware).
This technically does impose a slight increase in bandwidth on each
subsequent user request, and can also become a more serious problem if
the cookie is exceptionally long (since the signature might push it
over a browser's cookie length limit).

This can be avoided for middlewares that use cookies, by placing those
middlewares ahead of this one in MIDDLEWARE_CLASSES. Of course, this
means that those middlewares will not receive signature validation, and
must therefore remain suspicious of the cookies' values.

Another side-effect of the above action is that any cookies generated
outside this middleware's control (e.g., prior to it in
MIDDLEWARE_CLASSES) will be removed from request.COOKIES once this
middleware is processed (note that this will not remove it from the
client's browser, just from the HttpRequest instance). Therefore, any
cookie-using middlewares processed before this one must store their
cookies' values elsewhere if they are to be used by views.

Thankfully, SessionMiddleware can safely be placed prior to
SignedCookiesMiddleware in MIDDLEWARE_CLASSES, since it:
 - only stores an ID, which is already presumed safe enough, without
signing
 - adds a separate session object to the request, so views don't need
the session ID anyway
 - adds the session ID to the session object anyway, just in case a
view wants to use it

My recommendation, therefore (and yeah, this is probably all
unnecessary anyway), is that SignedCookiesMiddleware be placed after
SessionMiddleware, but before any others that use cookies. This will
allow session cookies to avoid the 33-character overhead, while still
protecting the rest of the cookie operations.

I appreciate any feedback that can be offered, and I'd like to thank
you all for giving me such a great framework to work with!


--~--~-~--~~~---~--~~
 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?hl=en
-~--~~~~--~~--~--~---

Re: New newforms code

[Paul Smith]

Adrian Holovaty wrote:
> On 1/10/07, Mikko Ohtamaa <[EMAIL PROTECTED]> wrote:
> > I have toyed around with newforms a bit.
> >
> > We should subclass Widget to TemplateWidget and then rebuild all widget
> > class hierarchy usingTemplateWidget based widgets. I'd rather throw
> > away the current widgets outputting HTML in Python code once for all.
> > Otherwise you'd need to override Field default widgets always.
> >
> > I don't see any drawback for template based widgets expect that running
> > template engine consumes more CPU cycles. But if that's a problem for
> > someone, I am willing to buy him/her a new server :)
>
> I see a huge drawback in offloading widget rendering to the template
> system -- it couples the forms library to the template system. Ideally
> the newforms library, when solidified, would be distributed as a
> standalone package that doesn't require the rest of Django.
>
> What if, instead of using the template system, we just provided a
> better hook for specifying display? But before you answer that
> question, please tell me this: How does the current Widget system
> prevent you from doing what you want to do? I'm still having trouble
> understanding your problem. The more concrete your example, the
> better.
>
> Adrian
>
> --
> Adrian Holovaty
> holovaty.com | djangoproject.com


Newforms is new and in-development - groking newforms' basic premise is
a lot easier than sniffing out the right design patterns to make it
work in the real world. Maybe Mikko is looking to customise Widgets
with templates in order to accomplish things that you had envisioned
doing by, say, overriding as_ul() to use Django templates? I think a
lot of these kinds of things will become a lot clearer as the docs get
filled out.

--Paul


--~--~-~--~~~---~--~~
 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?hl=en
-~--~~~~--~~--~--~---

Re: Should Django be HTML agnostic?

[Rob Hudson]

I think it's in the other thread, but what's the reason for wanting to
decouple forms from templates?  I can think of 2 reasons:

1) Decoupling means you can change the way templates work and not have
to update the forms code.  Counter argument: If you change the way
templates work you'd break a lot more than forms so this will likely be
a non-BC thing to do anyway.  In and of itself, this isn't a great
argument against keeping things decoupled.

2) Allow the form widgets to be used outside of Django.  If this is the
case, could it be that Django defaults to importing django.templates.
If that errors out, use standard Python Template Strings as a fall
back?


Another question. What would it look like if form HTML output type was
a config setting?

DEFAULT_HTML_DOCTYPE = "HTML4"

Then Django supports the common ones: XHTML and HTML4 (and others when
they come along).  It's extra code for every HTML type but it keeps
things decoupled.

This still doesn't accomplish letting designers design forms by
changing templates, which I think is a good argument for widget
templates.

-Rob


--~--~-~--~~~---~--~~
 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?hl=en
-~--~~~~--~~--~--~---

Re: Proposal: Named auth backends and backend specific profiles

[James Bennett]

On 1/10/07, Joseph Kocherhans <[EMAIL PROTECTED]> wrote:
> I propose to register and lookup backends by name to fix this
> problem. Here's a configuration sample:
>
> # a tuple of (name, path) tuples
> AUTHENTICATION_BACKENDS = (
> ('default', 'django.contrib.auth.backends.ModelBackend'),
> ('ldap', 'mypkg.backends.LDAPBackend'),
> )

Other than the fact that it's currently a tuple, is there any reason
not to change this to a dictionary? That'd feel cleaner and make it
much easier to do lookups against it (no more iterating through tuples
of tuples):

# a dictionary of name/path pairs
AUTHENTICATION_BACKENDS = {
'default': 'django.contrib.auth.backends.ModelBackend',
'ldap': 'mypkg.backends.LDAPBackend',
}


-- 
"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 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?hl=en
-~--~~~~--~~--~--~---

Re: Should Django be HTML agnostic?

[James Bennett]

On 1/11/07, Waylan Limberg <[EMAIL PROTECTED]> wrote:
> It should be easy to see that passing final_attrs into Andrew's
> template would give the desired result (perhaps with a few
> adjustments. It shouldn't be to hard for someone to hack up such a
> variation. Then when defining the form, just point to the custom
> widgets.

What worries me about this is that it becomes not a case of
configuration, but a case of "rewrite the widget classes and never use
the built-in versions". Which isn't something I particularly want to
do in order to coerce HTML4 out of newforms.

-- 
"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 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?hl=en
-~--~~~~--~~--~--~---

to_field/from_field in ManyToManyFields?

[Brian Beck]

Am I being boneheaded, or should ManyToManyFields support to_field and
from_field attributes with the semantics of ForeignKey's to_field?  It
seems like if ForeignKey supports it then it should be possible in
ManyToManyFields as well...


--~--~-~--~~~---~--~~
 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?hl=en
-~--~~~~--~~--~--~---

Re: New newforms code

[Gary Doades]

Adrian Holovaty wrote:
> On 1/10/07, Mikko Ohtamaa <[EMAIL PROTECTED]> wrote:
> 
> I see a huge drawback in offloading widget rendering to the template
> system -- it couples the forms library to the template system. Ideally
> the newforms library, when solidified, would be distributed as a
> standalone package that doesn't require the rest of Django.
> 
> What if, instead of using the template system, we just provided a
> better hook for specifying display? But before you answer that
> question, please tell me this: How does the current Widget system
> prevent you from doing what you want to do? I'm still having trouble
> understanding your problem. The more concrete your example, the
> better.

I think the main problem is that the current mechanism requires the 
developer to use *code* to change the way the widget is presented. The 
Django documentation goes some way to explain that web designers only 
need to know the template system to lay out the data that the 
programmers have provided for them via code. If we now say that we need 
to know how to program in python to change the presentation it breaks 
that paradigm somewhat.

I've just been using the CheckboxSelectMultiple widget to display a list 
of checkboxes for selection of months. We would like to lay them out as 
3 rows of 4 checkboxes. My template designer can't do this. I have to 
alter the code. The *functionality* of CheckboxSelectMultiple is just 
fine, I don't need to alter it, just the HTML output.

If the widgets were driven by template fragments, a bit like inclusion 
tags, then the designer could give me a template fragment to assign to 
that widget to get the presentation desired.

Previously I was looking at TurboGears widgets. This works very well by 
each widget having a default template fragment, but also having the 
ability to change the presentation by assigning just a different 
template fragment and not touching the code.

Regards,
Gary.

--~--~-~--~~~---~--~~
 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?hl=en
-~--~~~~--~~--~--~---

Re: Should Django be HTML agnostic?

[Waylan Limberg]

On 1/11/07, Waylan Limberg <[EMAIL PROTECTED]> wrote:

> However, if there was a way to pass final_attrs for each
> field in a form to the template (perhaps as an optional behavior),
> that would give template authors complete control over the layout of
> their forms.

I thing I approached that kind of backwards. Let me try another way:

So summarize the basics that everyone already knows: Currently, if a
Form instance is passed in the context to the template as `form`, if
we have:

{{ form }}

The entire form gets rendered (using as_table()). If we do:

{{ form.as_p }}

Then the whole form gets rendered using as_p(). Yet, for finer grained
control, if we do:

{{ form.field1 }}
{{ form.field2 }}
{{ form.field3 }}

or, perhaps more simply:

{{ for field in form }}
{{ field }}
{{ endfor }}

Then each field gets rendered with any surrounding html defined only
in the template.

 Why not take that a step further and allow something like this:

{{ for field in form }}
 {{ ifequal "text" field.input_type }}
   
 {{ endif }}
{{ endfor }}

or perhaps:




-- 

Waylan Limberg
[EMAIL PROTECTED]

--~--~-~--~~~---~--~~
 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?hl=en
-~--~~~~--~~--~--~---

Re: Proposal: Named auth backends and backend specific profiles

[Scott Paul Robertson]

On Wed, Jan 10, 2007 at 01:10:03PM -0600, Joseph Kocherhans wrote:
> 
> 1. Named auth backends
> 
> Right now, user logins are coupled to the actual location of an auth
> backend. The python dotted path of the backend is stored in the user's
> session when they login. If you were to move the backend to a
> different module, any user who was logged in via that backend would
> get a 500 the next time they tried to view a page because the class
> corresponding to the dotted path in their session would no longer
> exist. I propose to register and lookup backends by name to fix this
> problem. Here's a configuration sample:
> 
> # a tuple of (name, path) tuples
> AUTHENTICATION_BACKENDS = (
> ('default', 'django.contrib.auth.backends.ModelBackend'),
> ('ldap', 'mypkg.backends.LDAPBackend'),
> )
> 
> This will allow you to change to a different backend class, or move it
> to a different module or package without breaking your existing logins
> since they will be looked up by name rather than by path.

This is a problem I've run into myself, when I switched from having my
LDAP backend in my app, to running it as a patch (#2507). Currently I'm
assigning the new backend the old one's name so old session cookies
still work.

In other words, +1 on this.

> 
> 2. Link users to their backends
> 
> Adding a 'backend_name' field to django.contrib.auth.models.User would
> allow us to tie a user object to a specific backend when it is
> created. This would be a choice field with the choices populated from
> AUTHENTICATION_BACKENDS. It would allow us to use default django users
> and look them up by the type of backend they are tied to. (i.e. give
> me all OpenID users, give me all ldap users, etc.) This depends on
> point one, and makes the next proposal possible.
> 

+1. The LDAPBackend in trac currently makes a User object when a user first
authenticates, and provides a random default password. This is so if
someone tries to authenticate and fails and the next backend is the
Model backend, the person can't login with a static default password. It
would be nice to not have to worry about that.

> 
> 3. Store backend specific user profiles
> 
> I also propose to extend the AUTH_PROFILE_MODULES pattern to support
> backend specific profiles. This would depend on both of the previous
> points. Here's a configuration example:
> 
> BACKEND_PROFILE_MODULES = {
> 'ldap': 'mypkg.models.LDAPProfile',
> }
> 
> And to get the backend specific profile for a user:
> 
> user.get_backend_profile()
> 
> get_backend_profile() would user user.backend_name and
> BACKEND_PROFILE_MODULES to return the appropriate profile model.
> 

+1

> 
> 4. Dealing with username
> 
> Things like OpenID don't require a username, but the default
> django.contrib.auth User model does. We could hack something together
> in an OpenID backend to make up a unique username, but that seems kind
> of silly since we just don't need it. To fix this, the required=True
> attribute of the username field should be removed and a custom
> validator should take it's place. This validator should look at the
> new user.backend_name field to determine if the *backend* requires a
> username field. If backend_name is not available in the validators
> all_data argument, the validator will assume that username is
> required. My initial thinking is that an attribute named
> username_required or something similar could be checked on the backend
> object. To indicate that username is *not* required, you'd just set
> that attribute on your backend class. For instance:
> 
> class OpenIDBackend(object):
> username_required = False
> 
> def authenticate(request=None):
> # validate the openid server response and return a user
> 

+1

-- 
Scott Paul Robertson
http://spr.mahonri5.net
GnuPG FingerPrint: 09ab 64b5 edc0 903e 93ce edb9 3bcc f8fb dc5d 7601


pgpMe4PdWopg4.pgp
Description: PGP signature

Re: Should Django be HTML agnostic?

[Waylan Limberg]

On 1/11/07, Andrew Durdin <[EMAIL PROTECTED]> wrote:
>
> Rob Hudson wrote:
> >
> > 1. Display code should be separate from logic. Ideally, all HTML would
> > be in template files that one could override if need be in their own
> > template directory, just like the admin templates. If django.forms did
> > this, that would be great.
>
> The forms framework I wrote out of frustration with django.[old]forms
> did this.  I ended up with a number of tiny one-line templates. The
> template for a TextField, for example, was:
>
>  size="{{ size|escape }}" value="{{ data|escape }}" {% if maxlength
> %}}maxlength="{{ maxlength|escape }}"{% endif %}{% if widget.readonly
> %} readonly="readonly"{% endif %}{% if widget.disabled %}
> disabled="disabled"{% endif %}/>
>
Well if we look at the render method of a basic Input widget [1]:

74  def render(self, name, value, attrs=None):
75  if value is None: value = ''
76  final_attrs = self.build_attrs(attrs, type=self.input_type,
name=name)
77  if value != '': final_attrs['value'] = smart_unicode(value)
# Only add the 'value' attribute if a value is non-empty.
78  return u'' % flatatt(final_attrs)

It should be easy to see that passing final_attrs into Andrew's
template would give the desired result (perhaps with a few
adjustments. It shouldn't be to hard for someone to hack up such a
variation. Then when defining the form, just point to the custom
widgets.

That said, Adrian pointed out elseware that he does not want to tie
the forms to the template system (keeping everything modular) which I
understand. However, if there was a way to pass final_attrs for each
field in a form to the template (perhaps as an optional behavior),
that would give template authors complete control over the layout of
their forms. Perhaps something like:

http://code.djangoproject.com/browser/django/trunk/django/newforms/widgets.py
-- 

Waylan Limberg
[EMAIL PROTECTED]

--~--~-~--~~~---~--~~
 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?hl=en
-~--~~~~--~~--~--~---

Re: Should Django be HTML agnostic?

[Rob Hudson]

Michael Radziej wrote:
> I'm not sure what you mean exactly with "HTML agnostic". Could you
> explain it, please?

Just that Django shouldn't favor XHTML over HTML4.  But I'm actually
not too concerned if it comes with django.forms that default to XHTML,
but they are easily configurable or easy to override via templates.  So
the title is a bit of a misnomer -- the bullet points explain what I'm
after better.

Cheers!


--~--~-~--~~~---~--~~
 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?hl=en
-~--~~~~--~~--~--~---

Re: UNICODE and newforms

[Honza Král]

On 1/11/07, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
>
> On 1/10/07, Honza Král <[EMAIL PROTECTED]> wrote:
> > 1) migrate django to unicode aka big bang approach
> >   + cleanest
> >   - most work
> >   - may break some code
> >
> > 2) migrate newforms to normal byte strings
> >   + doesn't break anything
> >   - waste of good work
> >   - not ellegant (never give in, never surrender ;) )
> >
> > 3) update the rest of django to correctly detect and de/encode the
> > strings using settings.DEFAULT_ENCODING where needed
> >   - lot of work that will be thrown away later
> >   - messy
>
> I'm a huge proponent of moving all of Django to use Unicode strings
> internally. The newforms library is my first experiment in making
> everything Unicode, in (to my knowledge) the cleanest way possible: It
> accepts bytestrings *or* Unicode objects for all input, and it always
> outputs Unicode.
>
> My goal is to see how the everything-is-Unicode approach goes, and it
> has been pretty good so far. As encoding/decoding bugs have been
> detected, we've fixed them pretty promptly.
>
> If the newforms library does not handle "funky character" input
> correctly in *any* case, please report that as a bug immediately, and
> I or one of the many great patch contributors will fix it. We've
> already done this in several cases (tickets #3266, #3153, #3008), and
> the library already is quite resilient when it comes to "funky" input.

yes, but the rest of django is not as resilient to funky input, so you
need an extra layer to put between neforms and the rest, so that you
can deal with the funky yourself - template filters for example don't
handle unicode well...

>
> Regarding moving *all* of Django to use Unicode strings internally,
> that's a separate issue. For now, let's focus on making newforms as
> good as possible, learning from whatever mistakes we make. Once
> newforms is "done," we'll be in good shape to move the rest of Django
> to Unicode.

As I mentioned earlier - newforms are fine, its about the rest of the
system - we have to modify the rest of django to be able to cope with
the unicode outputted by the newforms library, if we do that, the full
unicode support seems only a step away...

>
> Finally, there's one more force at work here, of which people should
> be aware. We should release Django 1.0 sooner rather than later, and
> while making big changes (such as moving the whole framework to
> Unicode) is certainly worthwhile, each big change like this pushes
> back 1.0. Let's balance the perfectionism with the deadlines.

No argument here

>
> Adrian
>
> --
> Adrian Holovaty
> holovaty.com | djangoproject.com
>
> >
>


-- 
Honza Král
E-Mail: [EMAIL PROTECTED]
ICQ#:   107471613
Phone:  +420 606 678585

--~--~-~--~~~---~--~~
 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?hl=en
-~--~~~~--~~--~--~---

Re: Should Django be HTML agnostic?

[Andrew Durdin]

Rob Hudson wrote:
>
> 1. Display code should be separate from logic. Ideally, all HTML would
> be in template files that one could override if need be in their own
> template directory, just like the admin templates. If django.forms did
> this, that would be great.

The forms framework I wrote out of frustration with django.[old]forms
did this.  I ended up with a number of tiny one-line templates. The
template for a TextField, for example, was:



My motivation for this change was less to allow the use of valid HTML
(instead of XHTML), but to allow site-wide customisation of form
elements (i.e. in ways beyond what CSS can do).

> The only consideration I can think of is
> what kind of load would this be to necessitate a file system call to
> pull in the widget template or error template?

I don't think that's generally an issue.  If the Template instance is
cached in the Widget instance, then each widget's template file need
only be loaded and parsed once; and I don't expect the extra rendering
will be a significant issue.

> 4. One of the reasons I've seen touted for the template system not
> having access to Python methods and having it's own language is the
> benefit of separating the programmer from the designer and that
> designers shouldn't need to know Python to create templates in Django.
> But they would if they want to manipulate forms or form error feedback.
> This should be consistent.

This is IMO the best argument for this change.  Being able to have a
custom (but consistent site-wide) display of form labels & errors with
only template overrides would be very nice indeed.

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?hl=en
-~--~~~~--~~--~--~---

intimate dating

[pratik83]

Search Profiles - FREE! Intimate Dating. Start Chatting within seconds
- http://surl.in/HLMAT238206SVRAKSX


--~--~-~--~~~---~--~~
 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?hl=en
-~--~~~~--~~--~--~---

Re: Should Django be HTML agnostic?

[Michael Radziej]

Rob Hudson schrieb:
> I realize some of these aren't directly related to whether Django
> itself prefers XHTML.  Some are more along the lines of how easy it
> should be to work around Django if you prefer HTML4.
> 
> The following are what I think are valid reasons why Django should be
> HTML agnostic.

I'm not sure what you mean exactly with "HTML agnostic". Could you
explain it, please?


So long,

Michael
-- 
noris network AG - Deutschherrnstraße 15-19 - D-90429 Nürnberg -
Tel +49-911-9352-0 - Fax +49-911-9352-100

http://www.noris.de - The IT-Outsourcing Company

--~--~-~--~~~---~--~~
 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?hl=en
-~--~~~~--~~--~--~---

how to specify the location of image in src?

[[EMAIL PROTECTED]]

hi all,

  in the template files (ie. .html files) i am using  tag
for displaying images that is in a directory specified in MEDIA_ROOT.
But the browser can't detect the location properly... I placed the
image in each and every folder exists in the django project. No way
if you have any idea about where to place the images please help me


Thanks in advance..

Regards
Dhanya


--~--~-~--~~~---~--~~
 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?hl=en
-~--~~~~--~~--~--~---

Django Development Team Wanted

[eas]

We are planning to develop a new public facing web application.  This
effort will be a prominent joint venture with a well known media brand.
 We are looking to hire a development team that can help us get up to
speed quickly to develop the application over a 3-6 month time frame,
and then deliver regular updates and feature additions.

We haven't made platform or technology decisions yet, but I think
Django is a swell option, which is why I'm posting here.

If you have a development shop, an existing development team, or feel
confident you can pull a strong team together using people you've
worked with before, I'd like to talk to you further. I can be reached
at especkman [at] gmail [dot] com.


--~--~-~--~~~---~--~~
 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?hl=en
-~--~~~~--~~--~--~---

Oracle - Django (unicode, spanish characters, ..)

[vizcayno]

I made the next testing with last version of Django-Oracle under WinXP
with Oracle 10g2 in a unix Solaris server:
1) I Made a model in Django and created one table (with syncdb). Some
titles in the model.py contains spanish characters (referring in this
case to á, e, Ñ, ñ, etc)
2) I processed many files previously imported (using ftp with bin
option) from unix to Win/XP. The files contain latin-american
characters also (á, é, Ñ, ñ, etc) and can be read using "Word Pad"
without problems.
3) From DOS command window y ran a python program that read the files.
I made the next variants in the attempt to get spanish characters
visible in the Django admin Web page:
v1: dataOracle = dataFile  (DataFile is a string read from the
files generated in point 2)
v2: dataOracle =
dataFile.decode('latin1').encode(sys.stdout.encoding)
v3: dataOracle = dataFile.decode('cp1252').encode('utf-8')
v4: dataOracle = dataFile.decode('cp850').encode('utf-8')
4) Using Oracle tools from Windows I can see the spanish characters
when I ran v2, v3, v4 but when trying to see from Django admin web
page, only v1 and v2 seems to work however, I must previously change
the encoding in the IE7 browser, from unicode (utf-8)  to Western
European (windows) to see the accentuated spanish characters of the
data read from Oracle. Another paradoxical observation is that when the
IE7 browser is in utf-8 I can see the titles of the columns created by
the model.py with the corresponding spanish accents, but when I change
to Western European these accents are replaced by garbage characters.

What do you think is happening? Is my fault or, a unicode work around
is yet necessary for Oracle interface?
If you need some clarification or additional testing, please let me
know.
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?hl=en
-~--~~~~--~~--~--~---

{% url %}

[Ivan Sagalaev]

Hello Django developers!

I'd like to draw some attention to ticket 2606 
(http://code.djangoproject.com/ticket/2606) about exposing URL reversing 
into templates. It's useful, has a patch, docs and tests. Is there 
anything I should do to move it closer to be committed?

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?hl=en
-~--~~~~--~~--~--~---

{% url %}

[Ivan Sagalaev]

Hello Django developers!

I'd like to draw some attention to ticket 2606 
(http://code.djangoproject.com/ticket/2606) about exposing URL reversing 
into templates. It's useful, has a patch, docs and tests. Is there 
anything I should do to move it closer to be committed?

Thanks!


P.S. This might be a dupe since I believe Google has refused to accept 
this message first time but may be it just slowed a bit... Apologies then!

--~--~-~--~~~---~--~~
 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?hl=en
-~--~~~~--~~--~--~---

Should Django be HTML agnostic?

[Rob Hudson]

I posted a bug (http://code.djangoproject.com/ticket/3280) before I
left work which quickly got shot down by Adrian.  :)  He's right in
that it's a pretty general bug so I bring the conversation here.  I'm
curious what the Django devs will make of my reasoning...

I realize some of these aren't directly related to whether Django
itself prefers XHTML.  Some are more along the lines of how easy it
should be to work around Django if you prefer HTML4.

The following are what I think are valid reasons why Django should be
HTML agnostic.

1. Display code should be separate from logic. Ideally, all HTML would
be in template files that one could override if need be in their own
template directory, just like the admin templates. If django.forms did
this, that would be great. The only consideration I can think of is
what kind of load would this be to necessitate a file system call to
pull in the widget template or error template?

2. The argument against #1 that I've seen is usually that you can
subclass Something and write your own output. But in some ways, this
violates the DRY principle. The code to output a form widget, for
example, is already written, and in looking at what it would take, the
only change in the render() method would be the change of the HTML
itself.

3. Better "updatability": If there is a bug in Select(Widget) that was
fixed but I have MySelect(Widget) which is mostly the same except for
the HTML, I wouldn't get the fix unless I noticed and updated my code
as well. Whereas if Select(Widget) pulled in a template and I overrode
that template, the fix would come down just fine across all my
projects.

4. One of the reasons I've seen touted for the template system not
having access to Python methods and having it's own language is the
benefit of separating the programmer from the designer and that
designers shouldn't need to know Python to create templates in Django.
But they would if they want to manipulate forms or form error feedback.
This should be consistent.

If there's agreement, I'd be happy to help in the effort to make this
happen.  Initially I suppose the discussion is whether this is worth it
at all.  I also grepped the code looking for HTML tags and besides a
few places (the Django error page, for example) this is directed at
django.forms (newforms).

Thanks,
Rob


--~--~-~--~~~---~--~~
 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?hl=en
-~--~~~~--~~--~--~---

Re: New newforms code

[Adrian Holovaty]

On 1/10/07, Mikko Ohtamaa <[EMAIL PROTECTED]> wrote:
> I have toyed around with newforms a bit.
>
> We should subclass Widget to TemplateWidget and then rebuild all widget
> class hierarchy usingTemplateWidget based widgets. I'd rather throw
> away the current widgets outputting HTML in Python code once for all.
> Otherwise you'd need to override Field default widgets always.
>
> I don't see any drawback for template based widgets expect that running
> template engine consumes more CPU cycles. But if that's a problem for
> someone, I am willing to buy him/her a new server :)

I see a huge drawback in offloading widget rendering to the template
system -- it couples the forms library to the template system. Ideally
the newforms library, when solidified, would be distributed as a
standalone package that doesn't require the rest of Django.

What if, instead of using the template system, we just provided a
better hook for specifying display? But before you answer that
question, please tell me this: How does the current Widget system
prevent you from doing what you want to do? I'm still having trouble
understanding your problem. The more concrete your example, the
better.

Adrian

-- 
Adrian Holovaty
holovaty.com | djangoproject.com

--~--~-~--~~~---~--~~
 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?hl=en
-~--~~~~--~~--~--~---

Re: select_related() changes

[David Cramer]

It still seems to have a bug when just doing .select_related(depth=1),
sometimes its filling the field w/ the wrong data, looking into it.

On Jan 11, 11:31 am, "David Cramer" <[EMAIL PROTECTED]> wrote:
> I retract my statement, we had some other random server configuration
> error that just happened to appear at the same time as us putting this
> live :)
>
> On Jan 10, 8:34 pm, "David Cramer" <[EMAIL PROTECTED]> wrote:
>
> > It seems there are some issues with the code. Although I'm not sure why
> > it's happening, this was causing servers to get extremely loaded, and
> > the SQL queries werent executing properly. I had no issues when running
> > it on runserver before we pushed it onto a live environment though.
>
> > Going to look into it some more tomorrow, if anyone has any ideas let
> > me know.
>
> > On Jan 10, 5:45 pm, Michael Radziej <[EMAIL PROTECTED]> wrote:
>
> > > David Cramer schrieb:
>
> > > > I can do the docs, but it'd be a great time saver if you could do the
> > > > tests. I'm up to my elbows in work at the moment so :)Fine for me, then 
> > > > I take the tests.
>
> > > Michael
>
> > > --
> > > noris network AG - Deutschherrnstraße 15-19 - D-90429 Nürnberg -
> > > Tel +49-911-9352-0 - Fax +49-911-9352-100
> 
> > >http://www.noris.de-TheIT-Outsourcing Company


--~--~-~--~~~---~--~~
 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?hl=en
-~--~~~~--~~--~--~---

Re: file uploading problem

[[EMAIL PROTECTED]]

hi,
 The problem was solved... by adding a few lines as follows...

--
if request.POST:
new_data = request.POST.copy()
new_data.update(request.FILES)  # This has to be added

errors = manipulator.get_validation_errors(new_data)
if not errors:
new_message = manipulator.save(new_data)
--

Cheers
Dhanya


--~--~-~--~~~---~--~~
 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?hl=en
-~--~~~~--~~--~--~---

Re: UNICODE and newforms

[Arthur]

> +1 for unicode in django

+1

Regards, Arthur.

--~--~-~--~~~---~--~~
 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?hl=en
-~--~~~~--~~--~--~---

Re: New newforms code

[Andrew Durdin]

Mikko Ohtamaa wrote:
>
> I don't see any drawback for template based widgets expect that running
> template engine consumes more CPU cycles. But if that's a problem for
> someone, I am willing to buy him/her a new server :)

Well, that's a handy coincidence, because it's suddenly become a
problem for me :-b

I'm +1 on having widgets template-based also.

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?hl=en
-~--~~~~--~~--~--~---

Re: UNICODE and newforms

[Jannis Leidel]

Am 11.01.2007 um 09:39 schrieb Gábor Farkas:

> but that all happened approx. 5months ago, and the branches are still
> not merged (because they are not finished yet), and it does not seem
> that they will be merged in the near future...

+1 for unicode in django, including http://code.djangoproject.com/ 
ticket/952 (and other?)

Is it just a decision between unicodification and other branches for  
now?
--~--~-~--~~~---~--~~
 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?hl=en
-~--~~~~--~~--~--~---

Re: select_related() changes

[David Cramer]

I retract my statement, we had some other random server configuration
error that just happened to appear at the same time as us putting this
live :)

On Jan 10, 8:34 pm, "David Cramer" <[EMAIL PROTECTED]> wrote:
> It seems there are some issues with the code. Although I'm not sure why
> it's happening, this was causing servers to get extremely loaded, and
> the SQL queries werent executing properly. I had no issues when running
> it on runserver before we pushed it onto a live environment though.
>
> Going to look into it some more tomorrow, if anyone has any ideas let
> me know.
>
> On Jan 10, 5:45 pm, Michael Radziej <[EMAIL PROTECTED]> wrote:
>
> > David Cramer schrieb:
>
> > > I can do the docs, but it'd be a great time saver if you could do the
> > > tests. I'm up to my elbows in work at the moment so :)Fine for me, then I 
> > > take the tests.
>
> > Michael
>
> > --
> > noris network AG - Deutschherrnstraße 15-19 - D-90429 Nürnberg -
> > Tel +49-911-9352-0 - Fax +49-911-9352-100
> 
> >http://www.noris.de-The IT-Outsourcing Company


--~--~-~--~~~---~--~~
 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?hl=en
-~--~~~~--~~--~--~---

Re: UNICODE and newforms

[Gábor Farkas]

Honza Král wrote:
> Hi there,
> 
> I have been playing around with newforms for some time. since I don't
> come from an English speaking country, I did also put the unicode
> stuff to the test.
> 
> It has bitten me on several occasions. I agree that I am not used to
> python unicode strings, but that doesn't make it smaller problem:
> I was bitten by unicode in views, backend, form definitions and even 
> templates.
> for example try:
> 
> {{ form.field.errors|join:"" }}
> 
> when using a non-ascii characters...
> 
> It simply doesn't work well, and I doubt it ever will work 100% -
> mixing unicode and bytestrings.
> 
> Please do not take me wrong - I still love newforms, I think its the
> right way to go.
> 
> I see several ways how to solve this problem:
> 
> 1) migrate django to unicode aka big bang approach
>   + cleanest
>   - most work
>   - may break some code

there was a plan to migrate django to unicode (i once created some 
simple patches...), but then it was decided, that there are too many 
branches currently, so that first some branches should be closed (merged 
back into the trunk), and then a unicode-branch can be created.

but that all happened approx. 5months ago, and the branches are still 
not merged (because they are not finished yet), and it does not seem 
that they will be merged in the near future...


gabor

--~--~-~--~~~---~--~~
 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?hl=en
-~--~~~~--~~--~--~---

Re: UNICODE and newforms

[Philipp Keller]

+1 from me.

I'm german speaking, having ümläüts all over the place.

I stumbled over the following post that refers to a few tickets whose patches 
proved helpful
http://maurus.net/weblog/2006/08/08/utf8-encoded-unicode-support/

greets
Philipp

On Wed, Jan 10, 2007 at 11:56:52PM -0800, Ville Säävuori wrote:
> 
> > I see several ways how to solve this problem:
> >
> > 1) migrate django to unicode aka big bang approach
> 
> +1 from me.
> 
> I'm also working with Django with a language that has many "funky
> characters". I, too, am not very experienced with Python and unicode,
> but it's still a major pain sometimes. It would be _very_ nice to have
> unicode troughout the framework.
> 
> 
> > 
> 

--~--~-~--~~~---~--~~
 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?hl=en
-~--~~~~--~~--~--~---

Re: That would be *cookieless* [was: Stateless sessions almost here]

[Brian Beck]

Nicola Larosa (tekNico) wrote:
> "Stateless session" is an oxymoron, there's no such thing. You're
> talking about *cookieless* sessions.

Of course :) I was using them synonymously, i.e. the *browser* has no
means of storing state.


--~--~-~--~~~---~--~~
 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?hl=en
-~--~~~~--~~--~--~---