2007.04.25 (though in-progress in my brain for many years)

This is a brain dump.

The ultimate goal is to minimize and centralize code, writing it the same way you would explain it to another human. You talk about the high level flow, and then the details. You talk about control flow on the one hand, and data structure and business logic on the other. Sometimes they overlap.

So I have ODB -- Object DataBase. It is like Class::DBI or similar. It is the model.

I have Continuity. It is the base for the controller, but isn't a controller directly.

I have DOM Templates -- these parse HTML into a DOM and then you are expected to manipulate that. You use CSS or other things to easily interlace your stuff.

The controller does the user's POV flow in the application.

The Templates and CSS control the look.

The ODB control the data and business logic.

The trick is that some business logic is reflected or implemented in the flow. Some look is dependent upon the data in the model, of course.

So one idea I have is to actually have the ODB code render itself into the DOM. So I'm imagining that you can do it two ways. One way would be ODB->render return a DOM snippet. Another is to point the ODB object at a DOM tree or snippet. So you might do

  $snippet = $person->render

or you might do

  $person->render_on($node);

I think I like the second one better.

OK -- so here is where the context-sensitive part comes in. I want to be able to do the render_on as a generic method call, but sometimes it would be an editable form that is being rendered, and sometimes a static one. The static information might be different depending on the surrounding context.

The analogy I draw on here is that of rendering HTML. In an HTML doc an individual node has various attributes which determine how it is rendered. Some of theses attributes are inherited from their parent nodes. Others are determined based on their context (parent/siblings) and any CSS rules that apply.

When a browser renders a tree, it starts at the top and does a depth-first traversal. But before that it goes through its list of CSS selectors, finds all matching elements, and overrides or defines the relevant attributes.

It then does a depth-first traversal, Drawing the nodes and calculating their various sizes. Often the size of a rendered node will affect later rendered nodes, and every now and then the renderer will be forced to back-track to re-adjust some already drawn pieces -- forcing them to be re-drawn.

The same thing could be done with components of a DOM Template. There could be a component CSS, code selectors that is, which would select and set some parameters based on context. Something like:

.edit-form $code {
  mode: edit;
}


and then something like

  sub render {
    my ($self) = @_;
    foreach my $child ($self->children) {
      $child->render;
    }
  }

  # ...
  
  # An individual field
  sub render {
    my ($self) = @_;
    if($self->{mode} eq 'input') {
      my $name = $self->html_name;
      if($self->{input_type} eq 'text') {
        print "<input type='text' name='$name'>