|
List Info
Thread: Forms generation
|
|
| Forms generation |
  Italy |
2007-06-14 04:34:52 |
Hi,
I'd like to ask the list wisdom for a somehow
philosophical problem
connected with this mail subject.
Let us start by considering the CURD example contained in
Catalyst::Manual::Tutorial::AdvancedCRUD. In this example,
the user
enters his or her data using a form generated by the
controller using
HTML::Widget. While this approach presents the non
negligible advantage
to allow easy validation of entered data, and even automatic
population
of a database object, it has IMHO a problem in making the
controller
aware of things that should be known only to the view,
namely how to
actually compose the form in HTML, or even that a HTML form
should be
used at all (what if I want to use something like
Catalyst::View::Wx for
my user interface generation?).
As I see it, the controller should tell the view 'I want
the user
entering the following data, each one with its data-type,
and obeying
the following constraints". But it is not the work of
the controller to
say _how_ the form should be presented to the user. Just as
an example,
if the user is supposed to choose one among several
alternatives, it is
a view decision if present the user with a drop down list,
or a list of
radio buttons. The only thing the controller is interested
in, is that
one, and only one among the proposed alternatives is chosen
by the user.
What I'd like, is to have the controller generate a
"generic user
interface form object" and pass it to the view. The
view would the use
the object to generate the actual form presented to the
user.
On reception of the request, the controller would have to
find the
object filled up with the user entered data (using some
plugin[1]), and
be able to check the constraints (via some
"verify" method), and maybe
use the object for actually filling a database object.
What do the list members thinks about this? How do you
generate your
forms? Is there something like this already out, and I'm to
stupid to
find it?
Note:
[1] Yes,I know that plugins are discouraged, but for
maintaining the
'View and Model agnosticism of Catalyst, filling the object
from the
request data can not be a method of the form object.
--
Leo "TheHobbit" Cacciari
_______________________________________________
List: Catalyst lists.rawmode.org
Listinfo: ht
tp://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-
archive.com/catalyst lists.rawmode.org/
Dev site: http://dev.catalyst.per
l.org/
|
|
| Re: Forms generation |

|
2007-06-14 07:54:05 |
On 6/14/07, Leo Cacciari <leo.cacciari gmail.com> wrote:
> What do the list members thinks about this? How do you
generate your
> forms? Is there something like this already out, and
I'm to stupid to
> find it?
Reaction does exactly what you mentioned:
http://code2.0b
eta.co.uk/reaction/svn
http://code2.0beta.co.uk/reaction/svnweb/index.cgi/re
action
--
Eden Cardim
Instituto Baiano de Biotecnologia
Núcleo de Biologia Computacional e Gestão de Informações
Biotecnológicas
Laboratório de Bioinformática
_______________________________________________
List: Catalyst lists.rawmode.org
Listinfo: ht
tp://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-
archive.com/catalyst lists.rawmode.org/
Dev site: http://dev.catalyst.per
l.org/
|
|
| Re: Forms generation |

|
2007-06-14 11:20:41 |
On Thu, Jun 14, 2007 at 11:34:52AM +0200, Leo Cacciari
wrote:
> Let us start by considering the CURD example
contained in
> Catalyst::Manual::Tutorial::AdvancedCRUD. In this
example, the user
> enters his or her data using a form generated by the
controller using
> HTML::Widget. While this approach presents the non
negligible advantage
> to allow easy validation of entered data, and even
automatic population
> of a database object, it has IMHO a problem in making
the controller
> aware of things that should be known only to the view,
namely how to
> actually compose the form in HTML, or even that a HTML
form should be
> used at all (what if I want to use something like
Catalyst::View::Wx for
> my user interface generation?).
That was my thinking.
htt
p://search.cpan.org/~hank/Form-Processor-0.10/
still needs a few tweaks as needs arise.
There's a simple demo Catalyst application in the t/example
directory of:
http://search.cpan.org/~hank/Catalyst-Plugin-Fo
rm-Processor-0.01/
Also look at:
http://search.cpan.org/~jsiracusa/Rose-HTML-Objects-0.
548/
which is more about widget generation (which is very nice)
but less
about interfacing with the database automatically, IIRC.
Not that it
wouldn't be easy to add on (which I did once).
> As I see it, the controller should tell the view 'I
want the user
> entering the following data, each one with its
data-type, and obeying
> the following constraints".
I take that a step further, and say that the controller
should say
only "I want the user to update their profile"
and the controller
shouldn't have to worry what fields and field types the
"profile" is
made up of.
> But it is not the work of the controller to
> say _how_ the form should be presented to the user.
Just as an example,
> if the user is supposed to choose one among several
alternatives, it is
> a view decision if present the user with a drop down
list, or a list of
> radio buttons. The only thing the controller is
interested in, is that
> one, and only one among the proposed alternatives is
chosen by the user.
And along those lines, I use a template to generate the HTML
and for
basic crud forms the template decides if to show a drop down
list or a
list of checkboxes (multiple select) or radio buttons based
on how
many options there are.
> What I'd like, is to have the controller generate a
"generic user
> interface form object" and pass it to the view.
The view would the use
> the object to generate the actual form presented to the
user.
>
> On reception of the request, the controller would
have to find the
> object filled up with the user entered data (using some
plugin[1]), and
> be able to check the constraints (via some
"verify" method), and maybe
> use the object for actually filling a database object.
Again, you have a form object, so the controller only needs
to know if
the entire form is valid or not -- the controller decides
what page to
show, so it only needs to either show the form page or the
"Profile
Updated!" page. It's up to the form to know if the
input data is
valid or not. The form is an object, so it can have its own
behavior.
So my controllers to update/create look like:
sub profile : Local {
my ( $self, $c, $user_id ) = _;
$c->post_redirect( 'list', 'Profile Updated!')
if $c->update_from_form( $user_id );
}
--
Bill Moseley
moseley hank.org
_______________________________________________
List: Catalyst lists.rawmode.org
Listinfo: ht
tp://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-
archive.com/catalyst lists.rawmode.org/
Dev site: http://dev.catalyst.per
l.org/
|
|
| Re: Forms generation |
  United States |
2007-06-14 13:33:17 |
On Jun 14, 2007, at 9:20 AM, Bill Moseley wrote:
> On Thu, Jun 14, 2007 at 11:34:52AM +0200, Leo Cacciari
wrote:
>> As I see it, the controller should tell the view
'I want the user
>> entering the following data, each one with its
data-type, and obeying
>> the following constraints".
>
> I take that a step further, and say that the controller
should say
> only "I want the user to update their
profile" and the controller
> shouldn't have to worry what fields and field types the
"profile" is
> made up of.
i've implemented something similar to RoR-style form
helpers, where
the controller stashes the $user, and the view (mason here)
does:
<&| /form, for => $user, action =>
$c->uri_to('update_profile',
$user->id) &>
<& /text, name => 'username', label =>
'Email address' &>
<& /text, name => 'full_name' &>
<& /checkbox_group, name => 'opt_in', choices
=> [ [ 0 =>
'No'] , [ 1 => 'Yes' ] ] &>
<&| /form:buttons &>
<& /submit &>
<& /cancel &>
</&>
</&>
and the mason components take care of populating input
values (from
object or previous request params), displaying inline errors
(generated from Date::FV) on failed submission, all layout
and field
labeling requirements.
the end result is something like
my $results = $self->check_form(
Model::User->dfv_args_for_form
('update_profile') );
if ($results->has_missing || $results->has_invalid)
{
return $self->form_error( $results->msgs );
} else {
$user->update_from_hash($results->valid);
}
i've been looking at Form::Processor and similar, but the
tricky bit
for me is that i want the view to be both responsible for
generating
the HTML and deciding which fields belong on which form,
without an
intermediate form object that has to inform both the view
and
controller.
the problem becomes giving the view a way to communicate the
allowed
fields back to the controller without trusting the client.
i've been experimenting with having my form component store
the
details in the session as its being rendered.
<&| /form, for => $user, form_id =>
'update_profile', ... &>
<& /text, name => 'username', ... &>
<!-- pushes to { $c-
>session->-> }
-->
...
my $fields = delete
$c->session->->;
my $results = $self->check_form(
Model::User->dfv_args_for_fields(
$fields) );
i'm still teasing out the right API for this, but i do like
how it
gives authority to the view without also giving it to the
client.
_______________________________________________
List: Catalyst lists.rawmode.org
Listinfo: ht
tp://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-
archive.com/catalyst lists.rawmode.org/
Dev site: http://dev.catalyst.per
l.org/
|
|
| Re: Forms generation |

|
2007-06-14 18:16:25 |
On Thu, Jun 14, 2007 at 11:33:17AM -0700, Michael Reece
wrote:
> i've been looking at Form::Processor and similar, but
the tricky bit
> for me is that i want the view to be both responsible
for generating
> the HTML and deciding which fields belong on which
form, without an
> intermediate form object that has to inform both the
view and
> controller.
You can't let the View decide because the client can post
whatever
they feel. And I the Controller shouldn't have to bother
with
individual fields, but just if the entire post is valid or
not (as the
controller needs to know what page to return).
> the problem becomes giving the view a way to
communicate the allowed
> fields back to the controller without trusting the
client.
And, of course, the view isn't involved until displaying the
form and
that's too late in the request cycle.
> i've been experimenting with having my form component
store the
> details in the session as its being rendered.
But say someone wants to change their password -- you have
to validate
that the old password is correct, the new password matches
the
"Enter password again:" field, and that they are
different from the old
password. How do you communicate that logic back to the
controller or
whatever in the session?
It makes sense to have a separate form object to handle that
work.
--
Bill Moseley
moseley hank.org
_______________________________________________
List: Catalyst lists.rawmode.org
Listinfo: ht
tp://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-
archive.com/catalyst lists.rawmode.org/
Dev site: http://dev.catalyst.per
l.org/
|
|
| Re: Forms generation |
  United States |
2007-06-14 22:03:53 |
> On Thu, Jun 14, 2007 at 11:33:17AM -0700, Michael Reece
wrote:
>> i've been looking at Form::Processor and similar,
but the tricky bit
>> for me is that i want the view to be both
responsible for generating
>> the HTML and deciding which fields belong on which
form, without an
>> intermediate form object that has to inform both
the view and
>> controller.
>
> You can't let the View decide because the client can
post whatever
> they feel.
right, this my attempts to let the view still decide,
without trusting the
client post, by letting the view register (in the session)
exactly which
fields were provided, and then have the controller look at
only those
fields.
> And I the Controller shouldn't have to bother with
> individual fields, but just if the entire post is valid
or not (as the
> controller needs to know what page to return).
i've been leaning towards the models providing the
validation profiles for
whatever subset of fields the view was allowed to render.
> But say someone wants to change their password -- you
have to validate
> that the old password is correct, the new password
matches the
> "Enter password again:" field, and that they
are different from the old
> password. How do you communicate that logic back to
the controller or
> whatever in the session?
the answer is by allowing the model to provide the
validation coderef for
the password field, which notes it has a dependency on the
old_password
and password_confirm fields, makes the appropriate
comparisons, et al.
> It makes sense to have a separate form object to handle
that work.
i'll probably realize that as soon as i try to swap DFV for
RHTMF or
other, and wish i had abstracted or adopted a general API,
but until then
i'm happy enough with models returning DFV validation
closures, et al..
but only if that also supports my goal of not having the
authoritative
list of fields to be rendered defined in a .pm or .yml file,
but in the
.html template where it belongs imho.
_______________________________________________
List: Catalyst lists.rawmode.org
Listinfo: ht
tp://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-
archive.com/catalyst lists.rawmode.org/
Dev site: http://dev.catalyst.per
l.org/
|
|
| Re: Forms generation |
  United Kingdom |
2007-06-15 06:35:56 |
On Thu, Jun 14, 2007 at 08:03:53PM -0700, mreece vinq.com
wrote:
> i'll probably realize that as soon as i try to swap DFV
for RHTMF or
> other, and wish i had abstracted or adopted a general
API, but until then
> i'm happy enough with models returning DFV validation
closures, et al..
>
> but only if that also supports my goal of not having
the authoritative
> list of fields to be rendered defined in a .pm or .yml
file, but in the
> .html template where it belongs imho.
I'm not sure it always does.
In fact, I don't think it always belongs anywhere
Sometimes you'll want to select the fields in the view (not
necessarily the
template itself, but at least in something that belongs to
the view, not
anything else).
But equally, sometimes you'll want to be able to say
"just render all
applicable fields" - for e.g. for uniform CRUD type
stuff, so when the model
changes you don't have to run round updating all the
templates.
Getting DRY and clean factoring for this stuff can be ...
interesting.
I think the Reaction model is a damn good stab at this with
the new
widget-oriented view layer I've checked in recently; I'll
try and post some
examples to the list soon so people can see what I'm
gibbering about.
--
Matt S Trout Need help with your Catalyst or
DBIx::Class project?
Technical Director Want a managed development or
deployment platform?
Shadowcat Systems Ltd. Contact mst (at)
shadowcatsystems.co.uk for a quote
http://chainsawblues.vo
x.com/ http://www.shadowc
atsystems.co.uk/
_______________________________________________
List: Catalyst lists.rawmode.org
Listinfo: ht
tp://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-
archive.com/catalyst lists.rawmode.org/
Dev site: http://dev.catalyst.per
l.org/
|
|
| Re: Forms generation |

|
2007-06-15 06:54:42 |
i took a look at the Reaction repo yesterday. I see the docs
and
examples have come a long way. When you first showed me I
was quite
new to cat and it was young, so I was just baffled. I'm
looking
forward to having time to play with it again.
On 6/15/07, Matt S Trout <dbix-class trout.me.uk> wrote:
> On Thu, Jun 14, 2007 at 08:03:53PM -0700, mreece vinq.com
wrote:
> > i'll probably realize that as soon as i try to
swap DFV for RHTMF or
> > other, and wish i had abstracted or adopted a
general API, but until then
> > i'm happy enough with models returning DFV
validation closures, et al..
> >
> > but only if that also supports my goal of not
having the authoritative
> > list of fields to be rendered defined in a .pm or
.yml file, but in the
> > .html template where it belongs imho.
>
> I'm not sure it always does.
>
> In fact, I don't think it always belongs anywhere
>
> Sometimes you'll want to select the fields in the view
(not necessarily the
> template itself, but at least in something that belongs
to the view, not
> anything else).
>
> But equally, sometimes you'll want to be able to say
"just render all
> applicable fields" - for e.g. for uniform CRUD
type stuff, so when the model
> changes you don't have to run round updating all the
templates.
>
> Getting DRY and clean factoring for this stuff can be
... interesting.
>
> I think the Reaction model is a damn good stab at this
with the new
> widget-oriented view layer I've checked in recently;
I'll try and post some
> examples to the list soon so people can see what I'm
gibbering about.
>
> --
> Matt S Trout Need help with your Catalyst
or DBIx::Class project?
> Technical Director Want a managed development or
deployment platform?
> Shadowcat Systems Ltd. Contact mst (at)
shadowcatsystems.co.uk for a quote
> http://chainsawblues.vo
x.com/ http://www.shadowc
atsystems.co.uk/
>
> _______________________________________________
> List: Catalyst lists.rawmode.org
> Listinfo: ht
tp://lists.rawmode.org/mailman/listinfo/catalyst
> Searchable archive: http://www.mail-
archive.com/catalyst lists.rawmode.org/
> Dev site: http://dev.catalyst.per
l.org/
>
--
Daniel McBrearty
email : danielmcbrearty at gmail.com
www.engoi.com
danmcb.vox.com
danmcb.blogger.com
BTW : 0873928131
_______________________________________________
List: Catalyst lists.rawmode.org
Listinfo: ht
tp://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-
archive.com/catalyst lists.rawmode.org/
Dev site: http://dev.catalyst.per
l.org/
|
|
| Re: Forms generation |

|
2007-06-15 09:22:47 |
On Fri, Jun 15, 2007 at 10:35:48AM +0200, Leo Cacciari
wrote:
> yes, someone suggested it yesterday and I downloaded
and installed it,
> I'll try it asap By the
way, there is an error in the 10password.t
> test: Since the form field in weakened, you can not
create the object to
> be stored there at the same time you define the Field
(so,
you see I
> read the code;)) I'll let you (and the list) know how
it's going..
Maybe your CPAN mirror is out of date or you have bad timing
-- IIRC
that was only in .09 which was only on CPAN for half a day a
few days
ago. It's not the first time adding a weakened attribute
has caught
me. ;)
Thanks,
--
Bill Moseley
moseley hank.org
_______________________________________________
List: Catalyst lists.rawmode.org
Listinfo: ht
tp://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-
archive.com/catalyst lists.rawmode.org/
Dev site: http://dev.catalyst.per
l.org/
|
|
[1-9]
|
|