Re: SQL for presentation

> > html(docid, title, bodyelementid)
> > element(elementid, seqno, parentid)
> > form(elementid, action)
> > input(elementid, type, name, value)
> > table(elementid, border)
> > tr(elementid, rowno)
> > etc etc
>
> I guess what I meant was a specific example of a body of data, one or more
> rows from one or more tables, converted into a body of HTML. If you gave
> an example of a starting point and an ending point, I might begin to get a
> feel for how you would picture jumping from one to the next. The data
> should be customer data, like orders, not data from a HTML schema like the
> one above.

The starting data could be an employee table. employee(employeeid, firstname, lastname) With the content
employee(1, "Donald", "Duck")
employee(2, "Kit", "Walker")

The end-point might be tuples describing the html page.

html(1, "Employee list", 100)
element(100, 1, null)
element(101, 1, 100)
table(101, 1)
element(102, 1, 101)
tr(102)
element(104, 1, 102)
td(104, "Donald")
element(105, 1, 102)
td(105, "Duck")
element(103, 1, 101)
tr(103)
element(104, 1, 102)
td(104, "Kit")
element(105, 1, 102)
td(105, "Walker")

The result tuples would if possible be obtained by a view (or something similar using any declarative relational language).

> Personally I'm a fanatic for automation, and I automated normal table
> maintenance screens down to zero coding, but custom screens are for me the
> only thing left that is manually coded case-by-case. If you are working
> out a way to hit those cases, I'm all ears.

Automation is not my goal here. I do maintenance screens with zero or minimum coding too. But in this case the goal is to use the relational model instead of a hierachic model to represent a GUI and to use a declarative language to build the GUI. But the views would (partly) be hand-tailored case-by-case.

/Fredrik Received on Thu Jul 06 2006 - 13:29:43 CEST