I thought it'd make a nice learning project (as it'd be learning to
think of the go-way for problems that have already had a lot of
thought in other languages) and will probably start, but would prefer
to contribute to something that's already started if it exists.
Thanks!
[1] http://docs.djangoproject.com/en/1.3/topics/forms/
--
-
Michael Nelson
http://liveandletlearn.net
http://micknelson.wordpress.com
Yes, I wasn't planning on tackling model-form type functionality
(auto-generation of forms based on data definitions). I'm just
starting by putting together a small library of fields (CharField,
RegexField) etc., that support cleaning and errors etc., and was
planning on a BaseForm that can be composed together with the relevant
fields to provide a form.Clean() (which may require a little
reflection), IsValid and CleanedData.
> I've idly
> thought about how I would do this (I also have not seen anything so far),
> and my idea basically comes down to:
> 1. Use reflection and struct tags to convert a structure into a web form and
> process the results back into the structure
> 2. Integrate with the template library to insert the form into a webpage
> nicely, possibly customize it, etc
Great, but I'm hoping both those points will be orthogonal to form
field cleaning and error collection... what do you think? I'm keen to
work on the basics first :)
Thanks!
> This is not to say that there aren't other, perfectly legitimate ways to
> handle this in Go, this is just one potentially Go-like idea that I've come
> up with.
> Since a package that handles forms would tend to be very high level, it may
> or may not be a candidate for inclusion into the standard library, but if it
> made it very easy to do web forms and was sufficiently hardened against
> injection attacks, it might be a good candidate for going into the standard
> appengine libraries. If you built accessibility into it (using labels,
> tabindex, titles, etc), it could also increase the quality of go webapps in
> general.
> --
> ~Kyle
> "Everyone knows that debugging is twice as hard as writing a program in the
> first place. So if you're as clever as you can be when you write it, how
> will you ever debug it?"
> — Brian Kernighan
>
--
-
Michael Nelson
http://liveandletlearn.net
Something like that will be very handy.
--
André Moraes
http://andredevchannel.blogspot.com/
I've done an initial trial supporting forms with CharField,
IntegerField and RegexField, to do things like:
{{{
egForm := forms.NewForm(
forms.NewCharField("description"),
forms.NewIntegerField("purchase_count"))
}}}
You can then set the form input data (from http.Request.Form), call
egForm.IsValid(), and access either the egForm.CleanedData() or
egForm.Errors depending on the result.
If anyone has time to try it out and give some feedback on the
direction, you can install GoForms with `goinstall
launchpad.net/goforms` or browse the source at:
http://bazaar.launchpad.net/~michael.nelson/goforms/trunk/files
(fields_test.go and forms_test.go have examples - thanks Gustavo for
gocheck :) ).
It's been a great little learning project for me so far.
Cheers,
Michael
>
> Thanks!
>
> [1] http://docs.djangoproject.com/en/1.3/topics/forms/
>
> --
> -
> Michael Nelson
> http://liveandletlearn.net
> http://micknelson.wordpress.com
>
--
-
Michael Nelson
http://liveandletlearn.net
My brain has been thinking about this quite a bit, and I may take a
stab at it too at some point. One interesting, possibly useful, thing
to do would be to use reflection in the formatter of a template
argument to automatically create form elements. For example:
<form ...>
{Name|formString}
{University|formSelect}
{Password|formPassword}
</form>
It looks pretty ugly; better names could probably be chosen. These
can (would? should?) complement a mechanism for reading form data from
the request into the structure. This sort of mechanism could help
close the gap between writing forms and writing the code that
processes them; it would make it trivial to validate form data on the
Go side and just redisplay the form if it's wrong, because the data
and its representation are coupled.
Just some musings. I don't know if I have yet stumbled on the "right"
way to do this, but I think it is a worthwhile conversation to have,
so that maybe a "canonical" way, or a "go-like" way of doing it can
emerge and maybe be integrated into GAE.
This looks really nice from the template perspective. It's very clean.
Brian
Yes, form generation would be a huge job (something similar to
Django's modelforms + widget library etc.). I am interested to see the
approach you took for the validation/error display though, if you get
a chance to put it up somewhere?
Personally, I think it makes sense to keep the form API (definition,
validation and cleaning of data) separate from helpers for generating
forms automatically (similar to Django's model forms, and the link
provided earlier by Islan has a nice example of an approach for
parsing results from an interface).
Similarly for the default rendering of html widgets for each form
field - integration with a (separate) widget library that handles that
would be nice... from what you've said, it sounds like your code
handles this aspect? Let me know if you do make it available
somewhere, as I'd be keen to see the approach you took. I might try
adding a small widget library to the goforms above to try out a few
approaches.
Thanks!