RE: Nested tables

"pbc" <[email protected]>
Newsgroups gmane.comp.gcc.cgicc.general
Message-ID <000001c1d752$6ee7a710$52fd4cd5@demon>
|-----Original Message-----
|From: Stephen F. Booth [mailto:[email protected]] 
|Sent: Thursday, March 28, 2002 5:39 PM
|To: 'pbc'; [email protected]
|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
|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.  

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. 

Ok.

|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!
[ http://oferty.onet.pl ]
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.