Why is that unfortunate?
It's just that Django is compatible with Python versions 2.3, 2.4 and
2.5. I would have thought that was a good thing. It just means that you
can install any of the above versions of Python with the latest version
of Django and it will all work.
You would need to look
In creating a fairly complex form I realise that I would like to
create several "separate" Radio Input controls. I need to do this in
order to be able to lay them out more flexibly alongside other
controls.
I can't use the RadioInput widget directly as it seems to be only for
use by the RadioSele
I've just got to write my first form.clean method. I need to to do some
complex validation of different combinations of fields depending on the
setting of one other field.
This works great until one or more of the individual field validations
fail.
In my form.clean method I'm using the self.clea
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
> stan
Adrian Holovaty wrote:
>> but you *can* do that now, the only difference between what is now and
>> what you are proposing is that you call validators, what are now
>> Fields and you would call it
>> CharField( validators=[USState, IsAllUpperCase] )
>> where you can now write
>> ComboField( CharFi
Adrian Holovaty wrote:
> Ah, but we *will* have USStateField and USStateField field -- I just
> haven't written those Field classes yet. :)
>
Why not just have a CharField and a USState validator and an IPaddress4
validator. That way you have a USState validator to apply to other
fields as wel
Adrian Holovaty wrote:
> If the argument is "It violates DRY to have to create a Field subclass
> just to handle an existing validator," I'm not sure that argument
> flies, because we will eventually have a Field for every validator.
> Ideally, validators wouldn't even *exist* anymore, as Fields c
Adrian Holovaty wrote:
> Hey Gary,
>
> Great suggestion! Based on your idea, I've just checked in an extra
> hook, Field.widget_attrs(), which lets a Field specify any HTML
> attributes to add to its Widget. I've implemented the maxlength
> attribute for CharField, so your example can be rewritt
Honza Král wrote:
>> Also, how can I pass a validator_list to get similar functionality to
>> manipulators? Having the ability to supply a validator_list containing
>> a list of small single purpose validators is quite nice. Have I missed
>> something?
>
> you can subclass the Field class and add
I'm just starting to contsruct a form or two with the newforms package.
It works very nicely. However I have a couple of points so far:
It would be nice for the CharField field to output a "maxlength"
attribute if the max_length parameter is set. Otherwise we have to do
this:
name =
CharField(ma
Yeah, I've been using it for a couple of months now with no problems. I
also use it on another project via SQLAlchemy.
I only really pointed it out when I saw the beta chapters (chapter 2)
for the book. If it still recommends psycopg1 when it comes out it may
look out of date.
Jacob Kaplan-Mo
I notice that the documentation is still recommending psycopg1 and not
psycopg2 for PostgreSQL. Psycopg2 has been in release status for quite
a while now. The psycopg site is now firmly recommending psycopg2 and
noting that psycopg1 is effectively obsolete.
It may be better for the documentation,
12 matches
Mail list logo
