UI generator library?

Mark Wells mark at pc-intouch.com
Mon Jul 7 16:14:46 PDT 2003


Ivan--

We've added virtual field support to the view/edit UI for several tables
(router and most of the svc_*s).  To reduce redundancy, we created a
method (FS::part_virtual_field::widget) which takes a few options and
returns a chunk of HTML code for either viewing or editing the associated
virtual field value.  (See today's commit for examples.)

However, we're thinking about ways we can generalize this further.  There
are two driving forces here:

1.  We don't like hardcoding visual style into the core libraries.  (Of
course, it's not much worse than what we have now, where visual style is
scattered across more than a hundred CGI scripts, but still...)

2.  There's still a lot of redundancy.  For example, all of the edit forms
contain something along the lines of

<TABLE><%
foreach (sort { $a cmp $b } $whatever->virtual_fields) {
  print $whatever->pvf($_)->widget('HTML', 'edit', $_->getfield($_));
}
%></TABLE>

(Except that for edit/svc_*, there's a check on part_svc_column to make
sure the field doesn't have a fixed value.)

What we'd like to do is say something like

print virtual_field_widget('HTML', 'edit', $whatever);

and create the whole virtual-field-editing section of the form.  However,
we're not sure about how to organize this part of the code.  We could do
something like

print $whatever->virtual_field_widget('HTML', 'edit');
(which allows interface code to follow the existing inheritance
hierarchy, for nice handling of things like the svc_* loophole)

or even

print $ui->virtual_field_widget('edit', $whatever);
(which puts all the formatting-related stuff in one place).

Do you have any thoughts on this?




More information about the freeside-devel mailing list