[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Nested tables

From: pbc
Subject: RE: Nested tables
Date: Fri, 29 Mar 2002 19:49:18 +0100

|-----Original Message-----
|From: Stephen F. Booth [mailto:address@hidden 
|Sent: Thursday, March 28, 2002 5:39 PM
|To: 'pbc'; address@hidden
|Subject: RE: Nested tables

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

You are absolutly right. I forgot abou this detail :) So adding two
additonal parameters with default values should be enough.
HTMLElement::HTMLElement(<old parameter list>, bool IsScoped =
cgicc::options::IsScoped, ostream& out = cgicc::options::OutStream)

I suppose I 
|could overload the constructors, but I'm looking for a more 
|elegant solution.  

May I ask why overloaded constructors or additional parameters added to
original are not elegant ? One thing I can think of is that behaviour of
objects of new version of the class is very different depending on used
constructor what is not normal. Strong influance on behaviour suggests
using templates with policy parameter.

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

Good idea. I was thinking about this, too.

Piotr Dobrogost


Okresl Swoje potrzeby - my znajdziemy oferte za Ciebie!
[ ]

reply via email to

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