[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
> >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
> 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
> with global options and the Scope option could be false by default.
> way we don't break existing source and introducing new functionality
> 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
> Oss's suggestions ?

'fix' implies the source is broken! :)  I am going to make it compatible
with BCB, though.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]