Re: Why I dislike the MVC implementations in Web

The big difference is that one important responsability is taken from the view and delegated to the controller, which is processing the user input. For instance, in MVC2, if you have a datetime field splitted in two inputs, the View AND the Controller should know about that, because the View will split the datetime into the appropriate fields, and the Controller would put it back before sending to the model.

Not the way I do it, although I'm not sure what I'm doing is any more "pure" MVC. It's just what works for me. Anyway, I modularize my forms and fields so that neither the view or the controller have to worry about stuff like this. The form object simply says "I have a split MDY date field called 'start_date.'"

package MyEditForm;
...
sub build_form
{
  ...
  $self->add_field(start_date => MyDateField::MDY->new(size => ...));
}
[download]

The application associates the form with a page:

package MyWebApp;
...
sub init
{
  ...
  $self->add_forms
  (
    edit_form =>
    {
      class => 'MyEditForm',
      ...
    },
    ...
  )l

  $self->add_pages
  (
    edit_page => 
    {
      form_names => [ qw(edit_form ...) ],
      path       => 'edit.html',
      ...
    },
    ...
  );

  ...
}
[download]

Asking the app to show the page will init the form and pass it to the page.

sub do_whatever
{
  ...
  $app->show_page('edit_page');
}
[download]

From with the page, it's trivial (but templating-language-specific) to print the "start_date" field as XHTML (Mason example):

<!-- file: edit.mc -->
<html>
...

<% $form->start_html %>

<% $form->field('start_date')->html %>
...
<% $form->end_html %>

</html>

<%args>
$form
</%args>
[download]

Nowhere does anyone have to be aware that "start_date" is a split field--not even in the query parameters. These would both work transparently:

/mywebapp/edit?start_date=1/2/2005

/mywebapp/edit?start_date.month=1&start_date.day=2&start_date.year=200
+5
[download]

Ditto for setting fields directly:

$form->field('start_date.day')->input_value(1);
$form->field('start_date')->field('day')->input_value(1);
[download]

$form->field('start_date')->input_value('1/31/1988');
$form->field('start_date')->input_value(DateTime->new(...));
[download]

And so on. My webapp passes query params down to the form object as a hash. No heroics necessary. The form object can init its fields based on that hash, doing any necessary subfield initialization. Form objects can also be initialized with model objects:

$edit_form->init_with_product($product)

Individual fields can be set with objects when appropriate (e.g., DateTime objects) from within the controller (or the view if it's embedded-perl-ish like Mason). Finally, my views just call methods on field objects to produce the appropriate HTML.

Abstracting forms (and by extension, fields) is a big, big win for webapps IME. It lets each piece of "MVC" act as is appropriate to itself without sweating "external" details.

Comment on Re: Why I dislike the MVC implementations in Web Select or Download Code

Replies are listed 'Best First'.
Re^2: Why I dislike the MVC implementations in Web by ruoso (Curate) on Jun 08, 2005 at 11:54 UTC
Well, It seems you're implementing the same component model I am talking about... Could you please point me to the module where you implement that? I'd like to take a look as an inspiration for Oak2.	[reply]
Re^3: Why I dislike the MVC implementations in Web by Anonymous Monk on Jun 08, 2005 at 13:12 UTC
It's actually suite of modules under the name "Rose" The webapp component is not yet on CPAN, but the HTML forms and database objects are up, both of which are useful outside of the rest of the Rose framework. I hoped to have a development version of the webapp module up by now but I've been sidetracked with other work. My new goal is to get it uploaded by the end of the summer...	[reply]


Clear questions and runnable code get the best and fastest answer
	PerlMonks