RE: Nested tables

[Stephen F. Booth]

> >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.