Re: SQL for presentation
From: Bob Badour <bbadour_at_pei.sympatico.ca>
Date: Thu, 06 Jul 2006 13:09:13 GMT
Message-ID: <ZX7rg.6998$pu3.156447_at_ursa-nb00s0.nbnet.nb.ca>
>
>
> 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).
Date: Thu, 06 Jul 2006 13:09:13 GMT
Message-ID: <ZX7rg.6998$pu3.156447_at_ursa-nb00s0.nbnet.nb.ca>
frebe73_at_gmail.com wrote:
>>>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).
If you are creating a relational design to describe a document or user interface, why would you choose to re-invent all of the problems of html? Received on Thu Jul 06 2006 - 15:09:13 CEST