On Fri, Apr 13, Wolfram Kriesing wrote:
> Since I have tried creating forms from models, fields and all the
> magic I finally ended up creating my forms by hand and also connecting
> the data to it by hand, that is not DRY but it allows for most
> flexibility, which I found to need most of the ti
This is great stuff. Is there some place where one can see the
proposed dates when such branches would be merged to the trunk? I will
definately stop working on my project due to this, I would not want to
rewrite all my code to use newforms-admin.
Thanks
--~--~-~--~~~--
On 4/12/07, jp <[EMAIL PROTECTED]> wrote:
>
> Oh, in addition I was wondering what the 'right' way to do this would
> be at the current time?
very nice that you are bringing this up. I am also just waiting for
the wholy grale on this one.
Since I have tried creating forms from models, fields and
Jeremy Dunck wrote:
> While I agree that choices is model-y,
+1. I actually thought that this (displaying CharField with choices as a
type="text") was an obvious bug :-).
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Gro
On 4/12/07, jp <[EMAIL PROTECTED]> wrote:
> Adrian, correct me if I'm wrong, but the newforms-admin branch
> currently doesn't have arguments such as choices, editable, and other
> admin-related arguments removed from model fields, correct?
>
> Are they going to be removed? That's what I'm concern
Adrian, correct me if I'm wrong, but the newforms-admin branch
currently doesn't have arguments such as choices, editable, and other
admin-related arguments removed from model fields, correct?
Are they going to be removed? That's what I'm concerned about, not the
Admin class itself. I'm concerned
On 4/12/07, James Bennett <[EMAIL PROTECTED]> wrote:
> Since it doesn't seem to have come under the axe yet, I'd like to go
> ahead and suggest that 'choices' stay in the model -- we really ought
> to be turning that into a database-level constraint.
While I agree that choices is model-y, I don't
On 4/12/07, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
> The options that apply to the admin interface have been factored out
> as options to the admin class. Here's more information:
Since it doesn't seem to have come under the axe yet, I'd like to go
ahead and suggest that 'choices' stay in the
On 4/12/07, jp <[EMAIL PROTECTED]> wrote:
> Numerous arguments applicable to different fields.
>
> choices, radio_admin, editable, blank and several others.
>
> Some of them have absolutely nothing to do with the model/database
> itself, they exist purely for form/display-related purposes.
Hi jp,
Numerous arguments applicable to different fields.
choices, radio_admin, editable, blank and several others.
Some of them have absolutely nothing to do with the model/database
itself, they exist purely for form/display-related purposes.
On Apr 12, 1:34 pm, "James Bennett" <[EMAIL PROTECTED]> wr
On 4/12/07, jp <[EMAIL PROTECTED]> wrote:
> That doesn't make a whole lot of sense to me. I would think that with
> the newforms admin stuff it would be an ideal time to completely
> remove all display-related information from the models. It really just
> doesn't belong there.
What "display-relat
Alright, well now I'm even more confused.
The Admin class is being moved out of the model, but the display
information will remain on individual fields so that newforms can use
it via form_for_model() and form_for_fields()?
That doesn't make a whole lot of sense to me. I would think that with
th
I feel a bit ashamed. I came across a post about the newforms-admin
stuff and one of the prime goals is to move the admin information out
of the model.
Yay! I guess I will be writing my code with that in mind from here on
out.
On Apr 12, 12:50 pm, "jp" <[EMAIL PROTECTED]> wrote:
> Oh, in additio
Oh, in addition I was wondering what the 'right' way to do this would
be at the current time?
On Apr 12, 12:48 pm, "jp" <[EMAIL PROTECTED]> wrote:
> Today I needed to do something perhaps not entirely uncommon. I wanted
> to create a form that contained elements from both the User model as
> well
Today I needed to do something perhaps not entirely uncommon. I wanted
to create a form that contained elements from both the User model as
well as the UserProfile object I had attached to it.
At this point, I had an option. I could either define a completely
separate new form that had fields rel
15 matches
Mail list logo
