Field.readonly() returns text rather than read-only input
Nathan Rice
I'm just curious about this behavior. Currently, all major browsers
support read-only input fields, and while I can see the use for
text-ifying fields, it might be better to have a Field.as_text()
method.
A fix for this would be fast patch to throw together, assuming it
doesn't raise backwards compatibility red flags... I'd be happy to do
if needed.
Nathan
Gaël Pasgrimaud
On Mon, Nov 28, 2011 at 7:52 PM, Nathan Rice
<nathan.ale...@gmail.com> wrote:
> Hi,
>
> I'm just curious about this behavior. Currently, all major browsers
> support read-only input fields, and while I can see the use for
> text-ifying fields, it might be better to have a Field.as_text()
> method.
>
What is your need ? You want a real <input readonly /> ?
> A fix for this would be fast patch to throw together, assuming it
> doesn't raise backwards compatibility red flags... I'd be happy to do
> if needed.
>
The problem is that many projects use field.readonly() in custom template.
If this is just a grammar problem you can add an alias
readonly->as_text but I'm afraid that you'll break many projects if
you want to change the behavior
> Nathan
>
> --
> You received this message because you are subscribed to the Google Groups "FormAlchemy" group.
> To post to this group, send email to forma...@googlegroups.com.
> To unsubscribe from this group, send email to formalchemy...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/formalchemy?hl=en.
>
Nathan Rice
with backwards compatibility... perhaps the best course of action
would be to deprecate the Field.readonly() attribute, pointing people
to an as_text for the time being? It wouldn't be a big deal to add an
input_readonly attribute (and while I'm at it, actually implement the
disabled() attribute) at the same time. Then you could just do a
quick switcheroo on input_readonly/readonly when you're breaking the
API elsewhere for a major revision.
Nathan
Gaël Pasgrimaud
<nathan.ale...@gmail.com> wrote:
> Yeah, I was looking for an <input readonly="">. I understand issues
> with backwards compatibility... perhaps the best course of action
> would be to deprecate the Field.readonly() attribute, pointing people
> to an as_text for the time being? It wouldn't be a big deal to add an
> input_readonly attribute (and while I'm at it, actually implement the
> disabled() attribute) at the same time. Then you could just do a
> quick switcheroo on input_readonly/readonly when you're breaking the
> API elsewhere for a major revision.
In fact I was wrong. Has I remember templates are using
.render_readonly() so it's not a real problem
But, why not just use field.attrs(readonly='readonly') ?
http://docs.formalchemy.org/formalchemy/fields.html#formalchemy.fields.AbstractField.attrs
May be .attrs() can be changed to be more pythonic so readonly=True /
disabled=True become readonly="readonly" and disabled="disabled".
This solution is simple and avoid some API changes/deprecation warnings.
Nathan Rice
> .render_readonly() so it's not a real problem
>
> But, why not just use field.attrs(readonly='readonly') ?
> http://docs.formalchemy.org/formalchemy/fields.html#formalchemy.fields.AbstractField.attrs
I did not realize that is what attrs() was for, or even that it was a
method intended for users. I think this stems from the fact that it
is mentioned under the docs for abstractfield but not on
http://docs.formalchemy.org/formalchemy/forms.html which is pretty
much the main go-to page. Putting attrs on the forms page and
updating the docs for it to clarify its purpose slightly would be
enough I think... I will certainly use it now though.
> May be .attrs() can be changed to be more pythonic so readonly=True /
> disabled=True become readonly="readonly" and disabled="disabled".
>
> This solution is simple and avoid some API changes/deprecation warnings.
I agree, this solution is simple. My confusion came from the fact
that readonly() and disabled() closely correspond to input attributes.
Because I was testing with empty forms, I thought readonly()'s output
was a bug at first. I think that a name change might clarify the
situation a bit for people first approaching the library. Updates to
the docs to clarify these methods would probably be a workable simple
solution. Should I assume given attrs() that the disabled() method is
DOA and should be removed from the docs?
Nathan
Gaël Pasgrimaud
I dont know. For me you can do everything you want with field.set()
and field.attrs(). Everything else is useless. Except maybe some
widget stuff like .textarea() but maybe people like this useless
stuff...
The main point is that the doc is missing some real use cases. Like for .attrs()