[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Nested tables
From: |
Stephen F. Booth |
Subject: |
RE: Nested tables |
Date: |
Thu, 28 Mar 2002 11:38:59 -0500 |
> >render itself in the destructor. This approach was suggested by
David
> >McCombs, and is good, except that it is
> >almost fully incompatible with the current scheme. The code might
> look
> >like
>
> >/* create a table */
> >{
> > table(cout);
> > {
> > tr(cout);
> > {
> > /* inner table */
> > table(cout);
> > tr(cout).add(td("inner table"));
> > }
> > }
> > {
> > tr(cout);
> > td(cout).add(td("outer table"));
> > }
> >} /* end table */
>
> I personally think this is a little confusing- it took me a while to
> figure out the example above! And I haven't fully thought it through
> yet. But it is an alternative.
>
> Nested elements (not only talbes) are very needed as can be seen from
> many posts. The above solution looks good and it's so "close" to
> writting pure html as it can get in C++, IMHO. I think everybody can
get
> used to it rather easy (after a while) and after that it seems to be
> much more natural. As to compatibility with earlier versions of cgicc
-
> deafult parameter in HTMLElement constructor (..., bool Scope =
> cgicc::options::Scope) will do it just fine. Options could be
namespace
> with global options and the Scope option could be false by default.
This
> way we don't break existing source and introducing new functionality
at
> the same time. What do you think ?
You'll have to help me understand how your proposal would work (in a
backwards-compatible sense). For the scoping method of rendering, an
HTMLElement would have to contain a reference to the ostream it was
destined to write itself to. In the destructor it would write the
closing tag to this ostream. I can't just grab the ostream that was
used in the operator<< call, and store a pointer to it, because code
written exclusively for the new interface (like my sample above)
wouldn't use operator<< at all. The ostream would have to be specified
in the constructor for the HTMLElement. I suppose I could overload the
constructors, but I'm looking for a more elegant solution. A global
function to set the ostream is not an option either, because FastCGI
applications may be using different ostreams for different threads
running concurrently. I need to look at some xml generating libraries
and see how they do it.
> As always, I'm open to suggestions.
>
> I'm glad you are. Are you going to fix source according to Alexander
J.
> Oss's suggestions ?
'fix' implies the source is broken! :) I am going to make it compatible
with BCB, though.