Re: fixed the problem about simplejson in utf-8 when use chinese

2006-12-07 Thread limodou
> > No, I just say you may got a unicode string, but not say you *must* > > got a unicode string. > > sorry, you lost me there. assuming you're still using Python to run > your Django program, surely u"" gives you a unicode string ? and surely > that string will be properly encoded and decoded b

Re: fixed the problem about simplejson in utf-8 when use chinese

2006-12-07 Thread Fredrik Lundh
limodou wrote: > On 12/8/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote: >> limodou wrote: >> Why not use unicode object directly ? dict={"adviser":u"n.顾问, <美> (学生的)指导老师","od":"dd"} >>> because django will auto convert unicode to DEFAULT_CHARSET encoding, >>> so you got may be no

Re: fixed the problem about simplejson in utf-8 when use chinese

2006-12-07 Thread limodou
On 12/8/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote: > > limodou wrote: > > >> Why not use unicode object directly ? > >> > >> dict={"adviser":u"n.顾问, <美> (学生的)指导老师","od":"dd"} > >> > > because django will auto convert unicode to DEFAULT_CHARSET encoding, > > so you got may be not a unicode string

Re: fixed the problem about simplejson in utf-8 when use chinese

2006-12-07 Thread Fredrik Lundh
limodou wrote: >> Why not use unicode object directly ? >> >> dict={"adviser":u"n.顾问, <美> (学生的)指导老师","od":"dd"} >> > because django will auto convert unicode to DEFAULT_CHARSET encoding, > so you got may be not a unicode string even if you pass the unicode object to simplejson? sound weird. us

Re: fixed the problem about simplejson in utf-8 when use chinese

2006-12-07 Thread Favo
Same effect json_data = simplejson.dumps((json_data), ensure_ascii=False) return HttpResponse(json_data, mimetype=text-x-json; charset=utf-8') """ If ``ensure_ascii`` is ``False``, then the some chunks written to ``fp`` may be ``unicode`` instances, subject to normal Python ``str`` to ``

Output utf-8 in templates?

2006-12-07 Thread Favo
My website is based on utf-8. all data in database is in utf-8. but django didn't auto encode string to unicode for model field. So I have to encode them manually for template render. In fact I need use slice filter. otherwise it will break the utf-8 bits. could django assume all data in database

Re: fixed the problem about simplejson in utf-8 when use chinese

2006-12-07 Thread limodou
On 12/8/06, yi huang <[EMAIL PROTECTED]> wrote: > Why not use unicode object directly ? > > dict={"adviser":u"n.顾问, <美> (学生的)指导老师","od":"dd"} > because django will auto convert unicode to DEFAULT_CHARSET encoding, so you got may be not a unicode string, and just like I descibed that there are some

Re: Django t-shirts?

2006-12-07 Thread Don Spaulding
It seems like you would need to have a good grasp on what all of the expenses were before you could decide how to meet them. LJ sponsors the project site right? What other development expenses are there? A few possibilities I thought of: - Core devs' travel expense? - Conference materials (do yo

Re: fixed the problem about simplejson in utf-8 when use chinese

2006-12-07 Thread yi huang
Why not use unicode object directly ? dict={"adviser":u"n.顾问, <美> (学生的)指导老师","od":"dd"} -- http://codeplayer.blogspot.com/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this

newforms: MultipleChoiceField broken ??

2006-12-07 Thread Honza Král
Hi, is anybody using MultipleChoiceField with any success? It didn't work for me, so I produced a patch (ticket 3114) to correct the behaviour. The ticket also includes some tests that fail when run against the current SVN version. Could someone please check the patch? comments welcome Thanks PS

Re: fixed the problem about simplejson in utf-8 when use chinese

2006-12-07 Thread limodou
On 12/8/06, SP Z <[EMAIL PROTECTED]> wrote: > The simplejson has some problem when you use chinese character in utf-8 > > for example ,below chinese dictionary > > dict={"adviser":"n.顾问, <美> (学生的)指导老师","od":"dd"} > > show be encoded as , > > {"adviser": "n.\u987e\u95ee, <\u7f8e> > (\u5b66\u751f\u76

fixed the problem about simplejson in utf-8 when use chinese

2006-12-07 Thread SP Z
The simplejson has some problem when you use chinese character in utf-8 for example ,below chinese dictionary dict={"adviser":"n.顾问, <美> (学生的)指导老师","od":"dd"} show be encoded as , {"adviser": "n.\u987e\u95ee, <\u7f8e> (\u5b66\u751f\u7684)\u6307\u5bfc\u8001\u5e08", "od": "dd"} but the simplejs

Re: django.contrib.formtools: High-level abstractions of common form tasks

2006-12-07 Thread Ian Maurer
On 12/5/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote: > It's an abstraction of the workflow "Display an HTML form, force a > preview, then do something with the submission." Very slick. > What other sorts of things can we make abstractions for, > given a Form? I wanted to come up with a standa

Re: django.contrib.formtools: High-level abstractions of common form tasks

2006-12-07 Thread koenb
Isn't it useful to allow two-step validation in general: one by the form and one by the model when saving (both optional of course). This would allow to add constraints to a form that are not needed by the model in general (interesting when using different forms on the same model eg for different

Re: django.contrib.formtools: High-level abstractions of common form tasks

2006-12-07 Thread [EMAIL PROTECTED]
Adrian Holovaty wrote: > On 12/7/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > Yes, something along the lines of the wizard control in ASP.NET. > > Ideally, nothing is committed to the db unless all the pages in the > > wizard are validated. Whether this is done by capturing the > > inter

Re: django.contrib.formtools: High-level abstractions of common form tasks

2006-12-07 Thread Ivan Sagalaev
Waylan Limberg wrote: > Presumably each page would do validation on submit (we don't want to > send the user back to page one after completing 10 pages). If the > validated data is now in hidden fields, couldn't someone alter that > data (with evil intent) requiring re-validation? Why would it be

Re: django.contrib.formtools: High-level abstractions of common form tasks

2006-12-07 Thread [EMAIL PROTECTED]
I'm interested. --~--~-~--~~~---~--~~ 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 [EMAI

Re: Django t-shirts?

2006-12-07 Thread Adrian Holovaty
On 12/7/06, Rob Hudson <[EMAIL PROTECTED]> wrote: > There was a discussion a long time ago about Django t-shirts (at > OSCON?). My question for the core devs is: Why not set up a quick Cafe > Press site for a couple simple t-shirts and use the money to help fund > development? Maybe put up boun

Django t-shirts?

2006-12-07 Thread Rob Hudson
There was a discussion a long time ago about Django t-shirts (at OSCON?). My question for the core devs is: Why not set up a quick Cafe Press site for a couple simple t-shirts and use the money to help fund development? Maybe put up bounties for some bugs or features? Or simply split the proce

Re: django.contrib.formtools: High-level abstractions of common form tasks

2006-12-07 Thread sandro.dentella
Adrian Holovaty wrote: > Also, this is only the beginning of django.contrib.formtools, which I > intend to be a collection of common high-level form operations such as > this one. What other sorts of things can we make abstractions for, > given a Form? I do have an idea, almost an obsession: I

Re: Re: django.contrib.formtools: High-level abstractions of common form tasks

2006-12-07 Thread Adrian Holovaty
On 12/7/06, Antonio Cavedoni <[EMAIL PROTECTED]> wrote: > On 12/7/06, Waylan Limberg <[EMAIL PROTECTED]> wrote: > > Presumably each page would do validation on submit (we don't want to > > send the user back to page one after completing 10 pages). If the > > validated data is now in hidden fields,

Re: Re: django.contrib.formtools: High-level abstractions of common form tasks

2006-12-07 Thread Antonio Cavedoni
On 12/7/06, Waylan Limberg <[EMAIL PROTECTED]> wrote: > Presumably each page would do validation on submit (we don't want to > send the user back to page one after completing 10 pages). If the > validated data is now in hidden fields, couldn't someone alter that > data (with evil intent) requiring

Re: django.contrib.formtools: High-level abstractions of common form tasks

2006-12-07 Thread Waylan Limberg
On 12/7/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote: > This would be a great addition. Rather than requiring sessions, what > do you think of passing intermediate form data in hidden fields? It's > simpler, it wouldn't require cookies and I can't immediately think of > any downsides to the appro

Re: django.contrib.formtools: High-level abstractions of common form tasks

2006-12-07 Thread Rob Hudson
On 20061207.0851, Adrian Holovaty said ... > This would be a great addition. Rather than requiring sessions, what > do you think of passing intermediate form data in hidden fields? It's > simpler, it wouldn't require cookies and I can't immediately think of > any downsides to the approach. One do

Re: Re: django.contrib.formtools: High-level abstractions of common form tasks

2006-12-07 Thread Adrian Holovaty
On 12/7/06, Antonio Cavedoni <[EMAIL PROTECTED]> wrote: > > This would be a great addition. Rather than requiring sessions, what > > do you think of passing intermediate form data in hidden fields? > > Isn't that the way the dreaded ASP.NET "view state" works? Saving > marshaled temporary data in

Re: Re: django.contrib.formtools: High-level abstractions of common form tasks

2006-12-07 Thread Antonio Cavedoni
On 12/7/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote: > This would be a great addition. Rather than requiring sessions, what > do you think of passing intermediate form data in hidden fields? Isn't that the way the dreaded ASP.NET "view state" works? Saving marshaled temporary data in a hidden f

Re: Re: Default representation of a Form

2006-12-07 Thread Adrian Holovaty
On 12/7/06, Waylan Limberg <[EMAIL PROTECTED]> wrote: > But looking at the code, the error string is passed in first > regardless of whether `errors_on_separate_row` or not. Perhaps > `_html_output()` should use the optional mapping key for string > substitution [1]. Hey, that's a really good sug

Re: django.contrib.formtools: High-level abstractions of common form tasks

2006-12-07 Thread Honza Král
On 12/7/06, Ivan Sagalaev <[EMAIL PROTECTED]> wrote: > > Adrian Holovaty wrote: > > This would be a great addition. Rather than requiring sessions, what > > do you think of passing intermediate form data in hidden fields? > > +1 > > It's cleaner anyway since all data accumulated in one place. > +1

Re: django.contrib.formtools: High-level abstractions of common form tasks

2006-12-07 Thread Ivan Sagalaev
Adrian Holovaty wrote: > This would be a great addition. Rather than requiring sessions, what > do you think of passing intermediate form data in hidden fields? +1 It's cleaner anyway since all data accumulated in one place. --~--~-~--~~~---~--~~ You received th

Re: django.contrib.formtools: High-level abstractions of common form tasks

2006-12-07 Thread Graham King
Adrian Holovaty wrote: > On 12/7/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: >> Yes, something along the lines of the wizard control in ASP.NET. >> Ideally, nothing is committed to the db unless all the pages in the >> wizard are validated. Whether this is done by capturing the >> intermedi

Re: Re: Default representation of a Form

2006-12-07 Thread Waylan Limberg
Adrian, excellent job abstracting the common code into `Form._html_output()`. Now, anyone can write there own `as_method()` as a one-liner - with one minor problem... On 12/7/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote: > > On 12/1/06, James Bennett <[EMAIL PROTECTED]> wrote: > > So maybe an as

Re: django.contrib.formtools: High-level abstractions of common form tasks

2006-12-07 Thread Adrian Holovaty
On 12/7/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > Yes, something along the lines of the wizard control in ASP.NET. > Ideally, nothing is committed to the db unless all the pages in the > wizard are validated. Whether this is done by capturing the > intermediate form data in the session o

Re: django.contrib.formtools: High-level abstractions of common form tasks

2006-12-07 Thread [EMAIL PROTECTED]
Yes, something along the lines of the wizard control in ASP.NET. Ideally, nothing is committed to the db unless all the pages in the wizard are validated. Whether this is done by capturing the intermediate form data in the session or by rolling back a db transaction, I'm not sure. DB transaction

Re: Re: "getattr(): attribute name must be string"

2006-12-07 Thread Phil Powell
I'm just wondering if anyone is following up on this issue, as I've just been bitten by it? Or I'd happy to pull together some diff's and have a shot at some regression tests - but don't want to tread on anyone's toes? -Phil On 01/12/06, Russell Keith-Magee <[EMAIL PROTECTED]> wrote: > > > On 1

Re: django.contrib.formtools: High-level abstractions of common form tasks

2006-12-07 Thread Lachlan Cannon
Adrian Holovaty wrote: > What other sorts of things can we make abstractions for, > given a Form? Wizards, maybe? Given a series of forms, run through them all appending data from previous forms to next ones, or processing each in turn. Maybe an option to have it do either, so you can process