[freeside-devel] UI generator library?

[ivan at 420.am]

I agree we need to do something to modularize duplicate code on the
HTML side of things.

Rather than code HTML elements as perl modules, we should take advantage
of the fact that we're now using templating systems (Apache::ASP or
HTML::Mason), and componentize this way, putting pieces into components
in their own files under httemplate/ - i.e.
httemplate/components/header, and so on.

The kind of include we're looking for is done like this in Apache::ASP:

  $Response->Include('filename', args...)

and like this in HTML::Mason:

  $m->scomp('filename', args...)

So we should be able to define a "sub include" in global.asa and
handler.pl, and then call components under httemplate/ with syntax like:

  <%= include('component/header') %>

or

  <%= include('cust_main/small_custview', $arg1, $arg2 ) %>

or

  <%= include('black/cat', key=>'value' ) %>

In the components, we can access the arguments with @_, like in a
subroutine.

Does this make sense?

If the Apache::ASP / HTML::Mason compatibility bits cause us to take any
significant time dealing with them, I wouldn't be averse to moving to
just HTML::Mason.

As you did, sticking stuff in the FS::tablename classes is an acceptable
workaround for now as we can easily move the code into components.

-- 
_ivan


On Mon, Jul 07, 2003 at 04:14:45PM -0700, Mark Wells wrote:
> 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?
> 

-- 
_ivan