phphtmllib-devel

[Phphtmllib-devel] Usability issues

[David M. <da...@re...>]

Hi,

I've just tried out phpHtmlLib on a part of a web app I've written.

As much as I hate to say this, after all the work you guys have put into
it, I've found that the phpHtmlLib-ised code is twice as long and half
as readable, compared to plain echo statements.

Code snippets follow.

Before phpHtmlLib:

  $ff = "<td><font size=1 face='arial,helvetica,sans-serif'>";
  $ffr = "<td align=right>"
	. <font size=1 face='arial,helvetica,sans-serif'>";
  $ffend = "</font></td>";

  echo "<tr>";
  echo "$ffr" . "Commands:</td>$ff";
  writeLink("$urlPrefix&dbCommand=newTask", "Create New Task",
		"Create New", "", "");
  echo "$ffend";
  echo "</tr>";

phpHtmlLib-ised version which does exactly the same:

  $row1 = new TRtag();
  $fflabel = new FONTtag(array('size'=>'1',
				'face'=>'arial,helvetica,sans-serif'));
  $col1 = new TDtag(array('align'=>'right'));
  $fff = $fflabel;
  $fff->push("Commands:");
  $col1->push($fff);
  $row1->push($col1);
  $col1 = new TDtag(array('align'=>'left'));
  $fff = $fflabel;
  $link1 = new Atag(array("href"=>"$urlPrefix&dbCommand=newTask",
			  "title"=>"Create New Task"));
  $link1->push("Create New");
  $fff->push($link1);
  $col1->push($fff);
  $row1->push($col1);
  print $row1->render();

To me, it's about as clear as mud compared to the raw version.

I tried to make it more readable by creating tags on the fly, within
constructors for enclosing tags. Thus the previous code looks more like:

  $row1 = new TRtag(
	    "",
	    new TDtag(array('align'=>'right'),
	      new FONTtag(array('size'=>'1',
				'face'=>'arial,helvetica,sans-serif'),
			  "Commands:")));
  $row1->push(new TDtag("",
	new FONTtag(array('size'=>'1',
				'face'=>'arial,helvetica,sans-serif'),
		new Atag(array("href"=>"$urlPrefix&dbCommand=newTask",
			"title"=>"Create New Task"),
		   	"Create New"))));
  print $row1->render();

Pardon the shitty formatting - blame my email client.

But alas, the readability has not improved.

I might humbly suggest that phpHtmlLib would allow for more readable
code if the constructors could take an arbitrary number of content
arguments.

Or, better, if there were global functions with the same name as the
phpHtmlLib classes, which take an arbitrary number of arguments and
return a new instance of a tag object.

For example:

 $row1 = TRtag("",
           TDtag(array('align'=>'right'),
             FONTtag(array('size'=>'1','face'=>'arial etc'),
               "Commands:")),
           TDtag(array("",
             FONTtag(array('size'=>'1','face'=>'arial etc'),
               Atag(array('href'=>'somegoddamurl', 'title'=>'myshit'),
                 "Create New"))));

With code like *that*, I could scan over it with even the most tired
eyes and still see clearly what's going on, without having to follow
gazillions of different variables.

Thoughts anyone?

Cheers
David

Re: [Phphtmllib-devel] Usability issues

[David M. <da...@re...>]

Hi,

Following up from previous email, I've come up with a solution - a set
of function wrappers that constructs tag objects and populates them on
the fly with an arbitrary number of elements.

For example:

  function TRtag($attribs)
  {
    $tag = new TRtag($attribs);
    $n = func_num_args();
    for ($i = 1; $i < $n; $i++)
      $tag->push(func_get_arg($i));
    return $tag;
  }

That way, I'm able to take advantages of the strengths of phpHtmlLib and
generate some quite readable code.

Example from previous messages then converts to:

  $cmdstyle = array('size'=>'1',
                    'face'=>'arial,helvetica,sans-serif');
  $row1 = TRtag("",
            TDtag(array('align'=>'right'),
              FONTtag($cmdstyle,
                "Commands:")),
            TDtag("",
              FONTtag($cmdstyle,
                Atag(array("href"=>"$urlPrefix&dbCommand=newTask",
			   "title"=>"Create New Task"),
                  "Create New"))));
  print $row1->render();

That's a whole lot more readable (well, to me anyway).

I forgot to say - thanks guys for developing phpHtmlLib - it really is
an excellent tool. Great building-block towards HTML abstraction in PHP.

Cheers
David


On Thu, 2002-06-06 at 22:17, David McNab wrote:
> Hi,
> 
> I've just tried out phpHtmlLib on a part of a web app I've written.
> 
> As much as I hate to say this, after all the work you guys have put into
> it, I've found that the phpHtmlLib-ised code is twice as long and half
> as readable, compared to plain echo statements.
> 
> Code snippets follow.
> 
> Before phpHtmlLib:
> 
>   $ff = "<td><font size=1 face='arial,helvetica,sans-serif'>";
>   $ffr = "<td align=right>"
> 	. <font size=1 face='arial,helvetica,sans-serif'>";
>   $ffend = "</font></td>";
> 
>   echo "<tr>";
>   echo "$ffr" . "Commands:</td>$ff";
>   writeLink("$urlPrefix&dbCommand=newTask", "Create New Task",
> 		"Create New", "", "");
>   echo "$ffend";
>   echo "</tr>";
> 
> phpHtmlLib-ised version which does exactly the same:
> 
>   $row1 = new TRtag();
>   $fflabel = new FONTtag(array('size'=>'1',
> 				'face'=>'arial,helvetica,sans-serif'));
>   $col1 = new TDtag(array('align'=>'right'));
>   $fff = $fflabel;
>   $fff->push("Commands:");
>   $col1->push($fff);
>   $row1->push($col1);
>   $col1 = new TDtag(array('align'=>'left'));
>   $fff = $fflabel;
>   $link1 = new Atag(array("href"=>"$urlPrefix&dbCommand=newTask",
> 			  "title"=>"Create New Task"));
>   $link1->push("Create New");
>   $fff->push($link1);
>   $col1->push($fff);
>   $row1->push($col1);
>   print $row1->render();
> 
> To me, it's about as clear as mud compared to the raw version.
> 
> I tried to make it more readable by creating tags on the fly, within
> constructors for enclosing tags. Thus the previous code looks more like:
> 
>   $row1 = new TRtag(
> 	    "",
> 	    new TDtag(array('align'=>'right'),
> 	      new FONTtag(array('size'=>'1',
> 				'face'=>'arial,helvetica,sans-serif'),
> 			  "Commands:")));
>   $row1->push(new TDtag("",
> 	new FONTtag(array('size'=>'1',
> 				'face'=>'arial,helvetica,sans-serif'),
> 		new Atag(array("href"=>"$urlPrefix&dbCommand=newTask",
> 			"title"=>"Create New Task"),
> 		   	"Create New"))));
>   print $row1->render();
> 
> Pardon the shitty formatting - blame my email client.
> 
> But alas, the readability has not improved.
> 
> I might humbly suggest that phpHtmlLib would allow for more readable
> code if the constructors could take an arbitrary number of content
> arguments.
> 
> Or, better, if there were global functions with the same name as the
> phpHtmlLib classes, which take an arbitrary number of arguments and
> return a new instance of a tag object.
> 
> For example:
> 
>  $row1 = TRtag("",
>            TDtag(array('align'=>'right'),
>              FONTtag(array('size'=>'1','face'=>'arial etc'),
>                "Commands:")),
>            TDtag(array("",
>              FONTtag(array('size'=>'1','face'=>'arial etc'),
>                Atag(array('href'=>'somegoddamurl', 'title'=>'myshit'),
>                  "Create New"))));
> 
> With code like *that*, I could scan over it with even the most tired
> eyes and still see clearly what's going on, without having to follow
> gazillions of different variables.
> 
> Thoughts anyone?
> 
> Cheers
> David
> 
> 
> 
> _______________________________________________________________
> 
> Don't miss the 2002 Sprint PCS Application Developer's Conference
> August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
> 
> _______________________________________________
> Phphtmllib-devel mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phphtmllib-devel

Re: [Phphtmllib-devel] Usability issues

[Walter A. B. I. <wab...@bu...>]

On Thu, 2002-06-06 at 04:09, David McNab wrote:
> Hi,
> 
> Following up from previous email, I've come up with a solution - a set
> of function wrappers that constructs tag objects and populates them on
> the fly with an arbitrary number of elements.
---This is a really good suggestion.  I kinda have something like this
already, but not exactly.  There are a bunch of wrapper functions under
phphtmllib/tag_utils that I use more often then creating the object w/
the constructor itself.  I named all of the functions as html_*

The one thing they don't have is the ability to set the attributes AND
push n #'s of content items.  But one of the nice things about some of
the html_* functions is the api of params for most common things.
Such as the html_a() function which has the params of

function html_a($url, $content, $class=NULL, $target=NULL);

This by no means covers ALL the possible attributes of the
a tag, but it covers most of em.  I pretty much use that call
exclusively when constructing an A tag.  There is also the
other wrapper function for a common thing of wrapping an IMG tag
inside an A tag.  this is done with the
function html_img_href( $url, $image, $width='', $height='', $border=0,
$alt="", $usemap=NULL, $target=NULL);

But I guess there isn't a reason why we could have the 
TRtag() function along w/ the other helpers.  Most of the html_*()
functions only accept content items, so creating the new style
wrapper would be a benefit.  
  So the only issue is, what to do w/ the existing html_* functions?
If we create the new wrappers, I want to maintain compatibilty with the
old html_* functions so ppl that are using the libs don't have issues
upgrading to 2.0.0.

This is really a great request tho David.  Thanks!
I'll get right on it.

Walt


> 
> For example:
> 
>   function TRtag($attribs)
>   {
>     $tag = new TRtag($attribs);
>     $n = func_num_args();
>     for ($i = 1; $i < $n; $i++)
>       $tag->push(func_get_arg($i));
>     return $tag;
>   }
> 
> That way, I'm able to take advantages of the strengths of phpHtmlLib and
> generate some quite readable code.
> 
> Example from previous messages then converts to:
> 
>   $cmdstyle = array('size'=>'1',
>                     'face'=>'arial,helvetica,sans-serif');
>   $row1 = TRtag("",
>             TDtag(array('align'=>'right'),
>               FONTtag($cmdstyle,
>                 "Commands:")),
>             TDtag("",
>               FONTtag($cmdstyle,
>                 Atag(array("href"=>"$urlPrefix&dbCommand=newTask",
> 			   "title"=>"Create New Task"),
>                   "Create New"))));
>   print $row1->render();
> 
> That's a whole lot more readable (well, to me anyway).
> 
> I forgot to say - thanks guys for developing phpHtmlLib - it really is
> an excellent tool. Great building-block towards HTML abstraction in PHP.
> 
> Cheers
> David
> 
> 
> On Thu, 2002-06-06 at 22:17, David McNab wrote:
> > Hi,
> > 
> > I've just tried out phpHtmlLib on a part of a web app I've written.
> > 
> > As much as I hate to say this, after all the work you guys have put into
> > it, I've found that the phpHtmlLib-ised code is twice as long and half
> > as readable, compared to plain echo statements.
> > 
> > Code snippets follow.
> > 
> > Before phpHtmlLib:
> > 
> >   $ff = "<td><font size=1 face='arial,helvetica,sans-serif'>";
> >   $ffr = "<td align=right>"
> > 	. <font size=1 face='arial,helvetica,sans-serif'>";
> >   $ffend = "</font></td>";
> > 
> >   echo "<tr>";
> >   echo "$ffr" . "Commands:</td>$ff";
> >   writeLink("$urlPrefix&dbCommand=newTask", "Create New Task",
> > 		"Create New", "", "");
> >   echo "$ffend";
> >   echo "</tr>";
> > 
> > phpHtmlLib-ised version which does exactly the same:
> > 
> >   $row1 = new TRtag();
> >   $fflabel = new FONTtag(array('size'=>'1',
> > 				'face'=>'arial,helvetica,sans-serif'));
> >   $col1 = new TDtag(array('align'=>'right'));
> >   $fff = $fflabel;
> >   $fff->push("Commands:");
> >   $col1->push($fff);
> >   $row1->push($col1);
> >   $col1 = new TDtag(array('align'=>'left'));
> >   $fff = $fflabel;
> >   $link1 = new Atag(array("href"=>"$urlPrefix&dbCommand=newTask",
> > 			  "title"=>"Create New Task"));
> >   $link1->push("Create New");
> >   $fff->push($link1);
> >   $col1->push($fff);
> >   $row1->push($col1);
> >   print $row1->render();
> > 
> > To me, it's about as clear as mud compared to the raw version.
> > 
> > I tried to make it more readable by creating tags on the fly, within
> > constructors for enclosing tags. Thus the previous code looks more like:
> > 
> >   $row1 = new TRtag(
> > 	    "",
> > 	    new TDtag(array('align'=>'right'),
> > 	      new FONTtag(array('size'=>'1',
> > 				'face'=>'arial,helvetica,sans-serif'),
> > 			  "Commands:")));
> >   $row1->push(new TDtag("",
> > 	new FONTtag(array('size'=>'1',
> > 				'face'=>'arial,helvetica,sans-serif'),
> > 		new Atag(array("href"=>"$urlPrefix&dbCommand=newTask",
> > 			"title"=>"Create New Task"),
> > 		   	"Create New"))));
> >   print $row1->render();
> > 
> > Pardon the shitty formatting - blame my email client.
> > 
> > But alas, the readability has not improved.
> > 
> > I might humbly suggest that phpHtmlLib would allow for more readable
> > code if the constructors could take an arbitrary number of content
> > arguments.
> > 
> > Or, better, if there were global functions with the same name as the
> > phpHtmlLib classes, which take an arbitrary number of arguments and
> > return a new instance of a tag object.
> > 
> > For example:
> > 
> >  $row1 = TRtag("",
> >            TDtag(array('align'=>'right'),
> >              FONTtag(array('size'=>'1','face'=>'arial etc'),
> >                "Commands:")),
> >            TDtag(array("",
> >              FONTtag(array('size'=>'1','face'=>'arial etc'),
> >                Atag(array('href'=>'somegoddamurl', 'title'=>'myshit'),
> >                  "Create New"))));
> > 
> > With code like *that*, I could scan over it with even the most tired
> > eyes and still see clearly what's going on, without having to follow
> > gazillions of different variables.
> > 
> > Thoughts anyone?
> > 
> > Cheers
> > David
> > 
> > 
> > 
> > _______________________________________________________________
> > 
> > Don't miss the 2002 Sprint PCS Application Developer's Conference
> > August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
> > 
> > _______________________________________________
> > Phphtmllib-devel mailing list
> > Php...@li...
> > https://lists.sourceforge.net/lists/listinfo/phphtmllib-devel
> 
> 
> 
> _______________________________________________________________
> 
> Don't miss the 2002 Sprint PCS Application Developer's Conference
> August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
> 
> _______________________________________________
> Phphtmllib-devel mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phphtmllib-devel

Re: [Phphtmllib-devel] Usability issues

[David M. <da...@re...>]

On Fri, 2002-06-07 at 05:34, Walter A. Boring IV wrote:
> But one of the nice things about some of
> the html_* functions is the api of params for most common things.
> Such as the html_a() function which has the params of
> 
> function html_a($url, $content, $class=NULL, $target=NULL);

I didn't see any mention of the html_* functions in the doco.

RTFS time I guess :)

One of the best things about phpHtmlLib in general is that it eliminates
that annoying issue of having to 'close' tags. It's amazing how much
debugging time I've wasted looking at statements like
"echo '</table\n'" and asking 'which bloody nested table have I closed
here?!?'.

Anyway, I'll put my API design skills to the test and see if I can cook
up a wrapper that makes for ergonomic programming.

For example, if one wants TD cells to have a given font size, one has to
embed a FONT tag in each cell, which tends to mess up the code. (I
commented out the 'FONT is deprecated' warning in the lib, and I haven't
found anything in phpHtmlLib for CSS). I'll have a go at addressing
this.

Cheers
David

Re: [Phphtmllib-devel] Usability issues

[Walter A. B. I. <wab...@bu...>]

 
> I didn't see any mention of the html_* functions in the doco.
---yah I need better docs
The docs that I have are auto generated w/ phpdoc.  Otherwise docs
wouldn't really exist :)

> RTFS time I guess :)
> 
> One of the best things about phpHtmlLib in general is that it eliminates
> that annoying issue of having to 'close' tags. It's amazing how much
> debugging time I've wasted looking at statements like
> "echo '</table\n'" and asking 'which bloody nested table have I closed
> here?!?'.
---Amen. After you get over the learning curve of using the libs, 
it really can speed up the development of sites using it, especially
applications where you can create widget classes that can be reused.

> For example, if one wants TD cells to have a given font size, one has to
> embed a FONT tag in each cell, which tends to mess up the code. (I
> commented out the 'FONT is deprecated' warning in the lib, and I haven't
> found anything in phpHtmlLib for CSS). I'll have a go at addressing
> this.
---the font tag actually is a depricated tag in the W3C spec.
You should use a <span> or <div> to add styles to text.
In your case all u need to do is specify a style on the TD tag.

<td style="font-family:arial;font-weight:bold;font-size:10pt;">
foo bar</td>

or 
<td>
 <span style="font-family:arial;font-weight:bold;font-size:10pt;>
   foo
 </span>
</td>

In most cases I use a css class.
<td class="myfont">
 foo
</td>

or
<td>
 <span class="myfont">
  foo
 </span>
</td>

the great thing about <span> is that its harmless as far as layout goes
the browsers don't put auto padding on it, and it doesn't break layouts.
It was meant as a replacement for <font>
  

CSS is definetly the next project to tackle, but I haven't come
up with anything yet for it.
> 
> Cheers
> David
> 
> 
> 
> _______________________________________________________________
> 
> Don't miss the 2002 Sprint PCS Application Developer's Conference
> August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
> 
> _______________________________________________
> Phphtmllib-devel mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phphtmllib-devel

[Phphtmllib-devel] Getting picky on push()

[David M. <da...@re...>]

At the risk of sounding pedantic, I feel the need to question the
rightness of the name 'push' as a tag's append method.

Even though the doco explains that tags work as FIFOs, the word 'push'
still has a stack and LIFO connotation.

How about calling it 'add' instead? Perhaps supporting 'add' and 'push'
as synonyms, then deprecating 'push' at some stage?

Also, 'add' is one character shorter, and to some may be more
self-explanatory than 'push'.

Cheers
David

Re: [Phphtmllib-devel] Getting picky on push()

[Walter A. B. I. <wab...@bu...>]

> At the risk of sounding pedantic, I feel the need to question the
> rightness of the name 'push' as a tag's append method.
> 
> Even though the doco explains that tags work as FIFOs, the word 'push'
> still has a stack and LIFO connotation.
> 
> How about calling it 'add' instead? Perhaps supporting 'add' and 'push'
> as synonyms, then deprecating 'push' at some stage?
> 
> Also, 'add' is one character shorter, and to some may be more
> self-explanatory than 'push'.
---you just want to make more work for me don't ya? :)

What do other folks think about this?  It would require a bit of
work to add add(), since some classes have specialized push() 
implementations (TABLEtag, TRtag, etc.)


Walt

Re: [Phphtmllib-devel] Usability issues

[Walter A. B. I. <wab...@bu...>]

Howdy again,
  So I didn't think about this when I sent my previous email, but you
can't have a function that is named the same as a class.  So the
functions as you listed them as wrappers won't really work.  I think we
could possibly just build more of the html_* functions ?

Walt


On Thu, 2002-06-06 at 04:09, David McNab wrote:
> Hi,
> 
> Following up from previous email, I've come up with a solution - a set
> of function wrappers that constructs tag objects and populates them on
> the fly with an arbitrary number of elements.
> 
> For example:
> 
>   function TRtag($attribs)
>   {
>     $tag = new TRtag($attribs);
>     $n = func_num_args();
>     for ($i = 1; $i < $n; $i++)
>       $tag->push(func_get_arg($i));
>     return $tag;
>   }
> 
> That way, I'm able to take advantages of the strengths of phpHtmlLib and
> generate some quite readable code.
> 
> Example from previous messages then converts to:
> 
>   $cmdstyle = array('size'=>'1',
>                     'face'=>'arial,helvetica,sans-serif');
>   $row1 = TRtag("",
>             TDtag(array('align'=>'right'),
>               FONTtag($cmdstyle,
>                 "Commands:")),
>             TDtag("",
>               FONTtag($cmdstyle,
>                 Atag(array("href"=>"$urlPrefix&dbCommand=newTask",
> 			   "title"=>"Create New Task"),
>                   "Create New"))));
>   print $row1->render();
> 
> That's a whole lot more readable (well, to me anyway).
> 
> I forgot to say - thanks guys for developing phpHtmlLib - it really is
> an excellent tool. Great building-block towards HTML abstraction in PHP.
> 
> Cheers
> David
> 
> 
> On Thu, 2002-06-06 at 22:17, David McNab wrote:
> > Hi,
> > 
> > I've just tried out phpHtmlLib on a part of a web app I've written.
> > 
> > As much as I hate to say this, after all the work you guys have put into
> > it, I've found that the phpHtmlLib-ised code is twice as long and half
> > as readable, compared to plain echo statements.
> > 
> > Code snippets follow.
> > 
> > Before phpHtmlLib:
> > 
> >   $ff = "<td><font size=1 face='arial,helvetica,sans-serif'>";
> >   $ffr = "<td align=right>"
> > 	. <font size=1 face='arial,helvetica,sans-serif'>";
> >   $ffend = "</font></td>";
> > 
> >   echo "<tr>";
> >   echo "$ffr" . "Commands:</td>$ff";
> >   writeLink("$urlPrefix&dbCommand=newTask", "Create New Task",
> > 		"Create New", "", "");
> >   echo "$ffend";
> >   echo "</tr>";
> > 
> > phpHtmlLib-ised version which does exactly the same:
> > 
> >   $row1 = new TRtag();
> >   $fflabel = new FONTtag(array('size'=>'1',
> > 				'face'=>'arial,helvetica,sans-serif'));
> >   $col1 = new TDtag(array('align'=>'right'));
> >   $fff = $fflabel;
> >   $fff->push("Commands:");
> >   $col1->push($fff);
> >   $row1->push($col1);
> >   $col1 = new TDtag(array('align'=>'left'));
> >   $fff = $fflabel;
> >   $link1 = new Atag(array("href"=>"$urlPrefix&dbCommand=newTask",
> > 			  "title"=>"Create New Task"));
> >   $link1->push("Create New");
> >   $fff->push($link1);
> >   $col1->push($fff);
> >   $row1->push($col1);
> >   print $row1->render();
> > 
> > To me, it's about as clear as mud compared to the raw version.
> > 
> > I tried to make it more readable by creating tags on the fly, within
> > constructors for enclosing tags. Thus the previous code looks more like:
> > 
> >   $row1 = new TRtag(
> > 	    "",
> > 	    new TDtag(array('align'=>'right'),
> > 	      new FONTtag(array('size'=>'1',
> > 				'face'=>'arial,helvetica,sans-serif'),
> > 			  "Commands:")));
> >   $row1->push(new TDtag("",
> > 	new FONTtag(array('size'=>'1',
> > 				'face'=>'arial,helvetica,sans-serif'),
> > 		new Atag(array("href"=>"$urlPrefix&dbCommand=newTask",
> > 			"title"=>"Create New Task"),
> > 		   	"Create New"))));
> >   print $row1->render();
> > 
> > Pardon the shitty formatting - blame my email client.
> > 
> > But alas, the readability has not improved.
> > 
> > I might humbly suggest that phpHtmlLib would allow for more readable
> > code if the constructors could take an arbitrary number of content
> > arguments.
> > 
> > Or, better, if there were global functions with the same name as the
> > phpHtmlLib classes, which take an arbitrary number of arguments and
> > return a new instance of a tag object.
> > 
> > For example:
> > 
> >  $row1 = TRtag("",
> >            TDtag(array('align'=>'right'),
> >              FONTtag(array('size'=>'1','face'=>'arial etc'),
> >                "Commands:")),
> >            TDtag(array("",
> >              FONTtag(array('size'=>'1','face'=>'arial etc'),
> >                Atag(array('href'=>'somegoddamurl', 'title'=>'myshit'),
> >                  "Create New"))));
> > 
> > With code like *that*, I could scan over it with even the most tired
> > eyes and still see clearly what's going on, without having to follow
> > gazillions of different variables.
> > 
> > Thoughts anyone?
> > 
> > Cheers
> > David
> > 
> > 
> > 
> > _______________________________________________________________
> > 
> > Don't miss the 2002 Sprint PCS Application Developer's Conference
> > August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
> > 
> > _______________________________________________
> > Phphtmllib-devel mailing list
> > Php...@li...
> > https://lists.sourceforge.net/lists/listinfo/phphtmllib-devel
> 
> 
> 
> _______________________________________________________________
> 
> Don't miss the 2002 Sprint PCS Application Developer's Conference
> August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
> 
> _______________________________________________
> Phphtmllib-devel mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phphtmllib-devel

Re: [Phphtmllib-devel] Usability issues

[Walter A. B. I. <wab...@bu...>]

On Thu, 2002-06-06 at 10:43, Walter A. Boring IV wrote:
> Howdy again,
>   So I didn't think about this when I sent my previous email, but you
> can't have a function that is named the same as a class.  So the
> functions as you listed them as wrappers won't really work.  I think we
> could possibly just build more of the html_* functions ?
> 
> Walt
---So I just tried to do this and php doesn't complain about having
a function named the same as a class.  In fact it works fine.  But I'm
not sure its something we should do.  First of all it kinda blurs the
line between functions and classes.  How would you debug a problem with
an accidental missing "new" in front of the tag, when you meant to use
it?  That would be hard to find.  It does make for more readable code,
but all it really does is enable you not to use "new" in front of the
name.  One way to solve this is to enable the constructor of the 
objects handle n number of content items.  The drawback is that you
would still have to do "new"

new SPANtag(array(), "foo", "bar", "blah blah");

This also has an issue.  The current API of the libs is that the 
constructor of the html tag's 3rd param is a flag to set the
newline after opentag flag.  This was done to help collapse the 
content of a tag on the same line as the tag.  But with 2.0.0 there
is a new method called set_collapse() which will collapse the tag's
content onto the same line (even nested objects as content).

So do we break the API for 2.0 ?  How many folks are actually using the
3rd param to the constructor?

The other option is to modify the html_* functions.  But that would also
break folks that are using them now.  I use them heavily.  

Any thoughts?
Walt

Re: [Phphtmllib-devel] Usability issues

[Walter A. B. I. <wab...@bu...>]

> I'm for improving the API and usability.  If you are going to change
> the API, the best time is at a major version (1.0.3 -> 2.0).
--agreed.  As long as its not too much of a break. :)  So I went
ahead and changed the constructor to accept n number of content items,
and I have checked my apps I have built here at work, and it seems to
not have broken anything.  

> Another API change that I suggested before is switching the label and
> value in the form_select() convenience function.  It would allow calls
> like this:
> 
>    $form = form_select('example', ('zero', 'one', 'two'));
> 
> rather than this:
> 
>    $form = form_select('example', (0=>'zero', 1=>'one', 2=>'two'));
> 
> The patch for this is simply:
> 
> --- phphtmllib.orig/tag_utils/form_utils.php    Fri Apr  5 14:29:45 2002
> +++ phphtmllib/tag_utils/form_utils.php Tue Apr 23 21:02:01 2002
> @@ -294,7 +294,7 @@
> 
>       $select = new SELECTtag( array("name" => $name) );
> 
> -    while( list($label, $value) = each($options) ) {
> +    while( list($value, $label) = each($options) ) {
>           $selected_value = "";
>           if ($value == $selected) {
>               $selected_value = "SELECTED";

---ah yes.  I think you have wanted this one for a while no?
I know this will break a lot of pages I have that use select tags.
I guess when I built this function it seemed to make sense to me
to have the array be label=>value, as in tag attributes, instead of 
value=>label.  
  Switching the array to be value=>label would make it easier to read in
the cases where the value is an int 0,1,2,3.  But in the cases where
its some string it seems to make more sense to have it label=>value

so you would do 
array("California" => "CA", "Texas" => "TX");
instead of 
array("CA" => "California", "TX" => "Texas");

to give u

<select ...>
 <option value="CA">California</option>
 <option value="TX">Texas</option>
</select>

thoughts?

Re: [Phphtmllib-devel] Usability issues

[Tim M. <mo...@mr...>]

Walter A. Boring IV wrote:

>>Another API change that I suggested before is switching the label and
>>value in the form_select() convenience function.  It would allow calls
>>like this:
>>
>>   $form = form_select('example', ('zero', 'one', 'two'));
>>
>>rather than this:
>>
>>   $form = form_select('example', (0=>'zero', 1=>'one', 2=>'two'));
>>
>>The patch for this is simply:
>>
>>--- phphtmllib.orig/tag_utils/form_utils.php    Fri Apr  5 14:29:45 2002
>>+++ phphtmllib/tag_utils/form_utils.php Tue Apr 23 21:02:01 2002
>>@@ -294,7 +294,7 @@
>>
>>      $select = new SELECTtag( array("name" => $name) );
>>
>>-    while( list($label, $value) = each($options) ) {
>>+    while( list($value, $label) = each($options) ) {
>>          $selected_value = "";
>>          if ($value == $selected) {
>>              $selected_value = "SELECTED";
> 
> 
> ---ah yes.  I think you have wanted this one for a while no?

Since 1.0.2 but it's easy enough to change as each new version is
released.  =)

>   Switching the array to be value=>label would make it easier to read in
> the cases where the value is an int 0,1,2,3.  But in the cases where
> its some string it seems to make more sense to have it label=>value
> 
> so you would do 
> array("California" => "CA", "Texas" => "TX");
> instead of 
> array("CA" => "California", "TX" => "Texas");
 >> to give u
> 
> <select ...>
>  <option value="CA">California</option>
>  <option value="TX">Texas</option>
> </select>
> 
> thoughts?
I think you have this reversed.  The change I suggested would accept
array("CA" => "California", "TX" => "Texas") to provide the HTML output
you gave.

To be explicit, this

   $select = form_select('test', array('CA' => 'California',
                                       'TX' => 'Texas'));
   echo $select->render();

gives you this

   <SELECT name="test"><OPTION value="CA" >California</OPTION>
   <OPTION value="TX" >Texas</OPTION></SELECT>

To answer your question...
If you are using strings, you have to enter both strings anyway and the
order doesn't matter (at least no to me).  If you are using integers, it
makes sense to use the array index as the value so you only have to
enter the string.  This just makes the job a little easier where it can
and adds no extra work where it can't.

-- 
Tim Moloney
ManTech Real-time Systems Laboratory
2015 Cattlemen Road                             \     /
Sarasota, FL  34232                     .________\(O)/________.
(941) 377-6775 x208                        '  '  O(.)O  '  '

[Phphtmllib-devel] TRtag::push_reference() bug

[David M. <da...@re...>]

Hi again,

When using the push_reference() method in TRtag, it sometimes wraps the
inserted thing even when it's actually a TDtag.

Example:

    $page = new HTMLPageClass("This page");
    $page->push_reference($font);
    $font = new
    FONTtag(array('size'=>'4','face'=>'arial,helvetica,sans-serif'));
    $font->push_reference($table1);
    $table1 = new TABLEtag(array('border'=>1));
    $table1->push_reference($row[0]);
    $table1->push_reference($row[1]);
    
    $row[0] = new TRtag(0);
    $row[0]->push_reference($col[0][0]); // forward reference
    $row[0]->push_reference($col[0][1]); // ditto
    $col[0][0] = new TDtag(0, "Cell A");
    $col[0][1] = new TDtag(0, "Cell B");
    
    $row[1] = new TRtag(0);
    $col[1][0] = new TDtag(0, "Cell C"); // backward reference
    $col[1][1] = new TDtag(0, "Cell D"); // ditto
    $row[1]->push_reference($col[1][0]);
    $row[1]->push_reference($col[1][1]);
    
    print $page->render();

Produces:

    <FONT size="4" face="arial,helvetica,sans-serif">
      <TABLE border="1">
        <TR>
          <TD>
            <TD>Cell A</TD>
          </TD>
          <TD>
            <TD>Cell B</TD>
          </TD>
        </TR>
        <TR>
          <TD>Cell C</TD>
          <TD>Cell D</TD>
        </TR>
      </TABLE>
    </FONT>
 
Note that the data cells in the first row are being incorrectly wrapped
in an extra 'td' tag. This seems to be happening when I push_reference()
on something I haven't defined yet - TRtag is assuming that it won't be
a column object.

Cheers
David

Re: [Phphtmllib-devel] TRtag::push_reference() bug

[Walter A. B. I. <wab...@bu...>]

On Thu, 2002-06-06 at 07:16, David McNab wrote:
> Hi again,
> 
> When using the push_reference() method in TRtag, it sometimes wraps the
> inserted thing even when it's actually a TDtag.

---push_reference() was meant to take a tag object as the reference.

> 
> Example:
> 
>     $page = new HTMLPageClass("This page");
>     $page->push_reference($font);
>     $font = new
>     FONTtag(array('size'=>'4','face'=>'arial,helvetica,sans-serif'));
>     $font->push_reference($table1);
>     $table1 = new TABLEtag(array('border'=>1));
>     $table1->push_reference($row[0]);
>     $table1->push_reference($row[1]);
>     
>     $row[0] = new TRtag(0);
>     $row[0]->push_reference($col[0][0]); // forward reference
>     $row[0]->push_reference($col[0][1]); // ditto

$col[0][0] doesn't really exist at this point, so push_reference() 
doesn't know what type of tag its pushing.  It can't know what type of
tag you might push in the future :)  If you look at the push_reference()
code for the TRtag, it tries to detect if the item being pushed is a 
TD or TH.  If it is, it doesn't wrap it.  If its not, it wraps it. 
Since what you are pushing isn't an object, it wraps it.

>     $col[0][0] = new TDtag(0, "Cell A");
>     $col[0][1] = new TDtag(0, "Cell B");
>     
>     $row[1] = new TRtag(0);
>     $col[1][0] = new TDtag(0, "Cell C"); // backward reference
>     $col[1][1] = new TDtag(0, "Cell D"); // ditto
>     $row[1]->push_reference($col[1][0]);
>     $row[1]->push_reference($col[1][1]);
>     
>     print $page->render();

push_reference was meant to allow you to push an object, and
at some later time manipulate that object.  
So you could do something like

...
...
$span = new SPANtag;
$td->push_reference( $span );
...
...
...
$span->push("foo");
$span->set_tag_attribute("class", "green");


Walt

Re: [Phphtmllib-devel] Usability issues

[Tim M. <mo...@mr...>]

Walter A. Boring IV wrote:

 > [...]
 >
 > new SPANtag(array(), "foo", "bar", "blah blah");
 >
 > This also has an issue.  The current API of the libs is that the
 > constructor of the html tag's 3rd param is a flag to set the
 > newline after opentag flag.  This was done to help collapse the
 > content of a tag on the same line as the tag.  But with 2.0.0 there
 > is a new method called set_collapse() which will collapse the tag's
 > content onto the same line (even nested objects as content).
 >
 > So do we break the API for 2.0 ?  How many folks are actually using
 > the 3rd param to the constructor?

I know that I don't use the third parameter.

I'm for improving the API and usability.  If you are going to change
the API, the best time is at a major version (1.0.3 -> 2.0).

Another API change that I suggested before is switching the label and
value in the form_select() convenience function.  It would allow calls
like this:

   $form = form_select('example', ('zero', 'one', 'two'));

rather than this:

   $form = form_select('example', (0=>'zero', 1=>'one', 2=>'two'));

The patch for this is simply:

--- phphtmllib.orig/tag_utils/form_utils.php    Fri Apr  5 14:29:45 2002
+++ phphtmllib/tag_utils/form_utils.php Tue Apr 23 21:02:01 2002
@@ -294,7 +294,7 @@

      $select = new SELECTtag( array("name" => $name) );

-    while( list($label, $value) = each($options) ) {
+    while( list($value, $label) = each($options) ) {
          $selected_value = "";
          if ($value == $selected) {
              $selected_value = "SELECTED";


On an unrelated note, can the mailing list be set up to have a
Reply-To header back to the list?

-- 
Tim Moloney
ManTech Real-time Systems Laboratory
2015 Cattlemen Road                             \     /
Sarasota, FL  34232                     .________\(O)/________.
(941) 377-6775 x208                        '  '  O(.)O  '  '

Re: [Phphtmllib-devel] Usability issues

[Walter A. B. I. <wab...@bu...>]

> 
> On an unrelated note, can the mailing list be set up to have a
> Reply-To header back to the list?
---I think I updated the list s/w to do this.  We'll see


Walt

Re: [Phphtmllib-devel] Getting picky on push()

[Tim M. <mo...@mr...>]

David McNab wrote:

> At the risk of sounding pedantic, I feel the need to question the
> rightness of the name 'push' as a tag's append method.
> 
> Even though the doco explains that tags work as FIFOs, the word 'push'
> still has a stack and LIFO connotation.
> 
> How about calling it 'add' instead? Perhaps supporting 'add' and 'push'
> as synonyms, then deprecating 'push' at some stage?
> 
> Also, 'add' is one character shorter, and to some may be more
> self-explanatory than 'push'.

+1

BTW, a simple "Reply" still doesn't work.  Looking at the headers,
I see a "Return-Path" header (which I don't know what it does) but
no "Reply-To" headers.

-- 
Tim Moloney
ManTech Real-time Systems Laboratory
2015 Cattlemen Road                             \     /
Sarasota, FL  34232                     .________\(O)/________.
(941) 377-6775 x208                        '  '  O(.)O  '  '

[Phphtmllib-devel] A Critique

[David M. <da...@re...>]

Hi all,

I fear that I might come across as putting down phpHtmlLib, so please
try and trust that that is not my intention.

I love the concept of phpHtmlLib, that of abstracting the generation of
HTML code.

But after working with it for 2 days, I've gone back to printing out raw
html for now.

In using phpHtmlLib, I've found that the abstractions can be more fiddly
to drive than raw html generation itself.

At first, I felt really enthusiastic, and started converting a web-based
project management application over to phpHtmlLib.

My app generates some intricate HTML - tables nested 3 deep, rows and
columns full of links which vary according to php script invocation
flags and database content. More, link and non-link column styles -
colours, italics, bold etc - also vary according to script arguments and
database content.

I gave up trying to convert the app. Instead, I started writing a
completely new script, borrowing slightly from the logic of the raw one.

But on writing the phpHtmlLib code, I found myself having to create tons
of temporary variables to keep track of things.

It all started to feel like programming in assembler. The abstraction
mechanisms of phpHtmlLib came at a price - a whole lot of concrete
tracking of details, and a whole lot of 'noise' in the script, which
completely destroyed its readibility. The code ended up far more
concrete than before.

[It's a shame we don't have 3D displays. Then, logic indenting could go
left-right, and tag indenting could go front-back. Or perhaps someone
with too much time on their hands could write a LISP major mode script
for phpHtmlLib to represent different levels of tags as different
colours']

But seriously, it would be unfair for me to just rant on without
offering some kind of ideas for how this could be fixed. Well, here
goes...

1) Create a 'cursor' object, so that every time a tag object gets
created, the cursor gets set to that object. Then, one could do
something like 'add("A line of text")', and know the text will be
written to the right place, without having to keep track of what the
current tag is.
2) Complementary to (1) - a function allowing an arbitrary 'pop' back to
any level of the stack. For example, if one is currently writing an <a>
within a <div> within a <td> within a <tr> within a <table> within a
<td> within a <tr>, one could pop the 'cursor' back to the outer level
'<tr>' tag.
3) Make reference the standard default type of 'push'. For situations
where someone really wants to do the 'copying'-style push, provide a tag
object copying function (or method) which completely copies a tag object
and all its children. With methods such as 'push_row()', the lack of a
reference push is a big drawback.
4) Allow for easy creation of template classes.
For example, it would be lovely to have a class which writes 10-point
bold green centred links within a table column, without having to create
n levels of tags each time.

I'll sleep on it tonight. I feel very tempted to have a go at creating
things like this myself, but I don't want to jump in without thinking at
depth how it could be done well.

Your thoughts?
Cheers
David

Re: [Phphtmllib-devel] A Critique

[Walter A. B. I. <wab...@bu...>]

First things first,
  Thanks for the Critique.  It's always healthy for any project to get
some devil's advocate/crituquing, and I appriciate it.  Thanks.  no
really. :)  
  That being said and out of the way, when I wrote the libs, I was doing
just for a fun project to do and with no real "lets convert the entire
php engineering population to the libs" kind of thought process.  I
personally find the libs very usefull for many reasons, so I choose to
use em.  If they aren't for you, then thats kewl to.  

> Hi all,
> 
> I fear that I might come across as putting down phpHtmlLib, so please
> try and trust that that is not my intention.
> 
> I love the concept of phpHtmlLib, that of abstracting the generation of
> HTML code.
> 
> But after working with it for 2 days, I've gone back to printing out raw
> html for now.
> 
> In using phpHtmlLib, I've found that the abstractions can be more fiddly
> to drive than raw html generation itself.
> 
> At first, I felt really enthusiastic, and started converting a web-based
> project management application over to phpHtmlLib.
> 
> My app generates some intricate HTML - tables nested 3 deep, rows and
> columns full of links which vary according to php script invocation
> flags and database content. More, link and non-link column styles -
> colours, italics, bold etc - also vary according to script arguments and
> database content.
> 
> I gave up trying to convert the app. Instead, I started writing a
> completely new script, borrowing slightly from the logic of the raw one.
> 
> But on writing the phpHtmlLib code, I found myself having to create tons
> of temporary variables to keep track of things.
---with 2.0.0 and the html_* wrappers, this should help some, as well as
the new constructor args.

 
> It all started to feel like programming in assembler. The abstraction
> mechanisms of phpHtmlLib came at a price - a whole lot of concrete
> tracking of details, and a whole lot of 'noise' in the script, which
> completely destroyed its readibility. The code ended up far more
> concrete than before.
> 
> [It's a shame we don't have 3D displays. Then, logic indenting could go
> left-right, and tag indenting could go front-back. Or perhaps someone
> with too much time on their hands could write a LISP major mode script
> for phpHtmlLib to represent different levels of tags as different
> colours']
> 
> But seriously, it would be unfair for me to just rant on without
> offering some kind of ideas for how this could be fixed. Well, here
> goes...
> 
> 1) Create a 'cursor' object, so that every time a tag object gets
> created, the cursor gets set to that object. Then, one could do
> something like 'add("A line of text")', and know the text will be
> written to the right place, without having to keep track of what the
> current tag is.
---you can do this with references, but it creates very difficult to
read/manage code.  The nice thing about the libs is that its just an 
object tree.  So anyone that knows OOP can use them out of the box, with
a little learning curve.

> 2) Complementary to (1) - a function allowing an arbitrary 'pop' back to
> any level of the stack. For example, if one is currently writing an <a>
> within a <div> within a <td> within a <tr> within a <table> within a
> <td> within a <tr>, one could pop the 'cursor' back to the outer level
> '<tr>' tag.
---use references if you have to do this.  Most of the time I don't have
to worry about "popping" back out to an outer level.  If you organize
code with lots of functions/objects then this really doesn't happen that
often.  In my case, I usually write a widgets which are logical html
"objects" and I just stuff data into them.  I don't care how they are
structured.  its just data.

> 3) Make reference the standard default type of 'push'. For situations
> where someone really wants to do the 'copying'-style push, provide a tag
> object copying function (or method) which completely copies a tag object
> and all its children. With methods such as 'push_row()', the lack of a
> reference push is a big drawback.
---I am playing with making push handle references.  The problem with it
is, that since push can accept n # of arguments, I have to use the
func_* functions, which do not do references.  Hence the push_reference
(and now add_reference replacement of push_reference), that only takes 1
parameter.  This is just a limitation in the php language that I can't
get around for the moment.

> 4) Allow for easy creation of template classes.
> For example, it would be lovely to have a class which writes 10-point
> bold green centred links within a table column, without having to create
> n levels of tags each time.
---anyone can do this.  They are called functions, or objects :)  The
libs are not intended to cover every web engineer's style of output
html, but to provide a standard Object API for building/rendering html
as close as the w3c spec as possible.  
  If you want specific styled/colored objects, tags, you should write
your own wrapper functions/objects.  I do this on many of my
applications I used the libs with.  Take for example, I have a span with
a specific css class that I use everywhere.  So I just create a specific
local (to the app) library wrapper.  Something like,

 function span_font10(  ) {
    $args = func_get_args();
    $span = new SPANtag( array("class" => "font10") );
    push_args( $span, $args );
    return $span;
 }

Does this mean that the phphtmllibs should include this?  I don't think
so. 

 
My $0.02
Walt

Re: [Phphtmllib-devel] A Critique

[David M. <da...@re...>]

Hi Walt,

Thanks for not taking my critique harshly.

As it happens, I've taken some of the concept of phpHtmlLib and written
my own thingy, which I've called 'tagwriter'.

Basically, what I've done is to create a single main class called
'tagwriter', and a bunch of global functions for each of the tag types.

In order to gain some power of abstraction, I've created a mechanism of
'parametric substitution', whereby I can insert, at any point in the
HTML tree, a named parameter. This parameter gets filled with another
HTML tree upon invocation of a method called 'insert'.

Example code:

<?php

include_once("tagwriter.inc");

// instandiate a tagwriter object
$page = new tagwriter;

// write some stuff to it, including a 'tagmarker' called 'redtext'
// that we'll fill in later. Tag markers here are a bit like arguments
// in C #define macros

$page->put
(HTML(HEAD(TITLE("This Page")),
      BODY(P(targs("align", "center", "style","font-size:24pt"),
	     "Body Text"),
	   P(targs("style", "color:red"),
	     tagmarker("redtext")))));

// now insert a value into the 'redtext' marker
// note - the inserted value can be large, even an html tree
// with megabytes of tags
$page->insert("redtext", "This line should appear as red text");

// Now render and display the page
echo $page->raw();

?>

end example.

The basic trip is, that all of the global tag generation functions
accept any number of arguments, and render the HTML on the fly.
Indenting is disabled by default, since the simplistic indenting code
I'm using has a tendency to stuff up <TEXTAREA> tags.

I've attached the 'tagwriter.inc' file, plus:

test3.php - demonstrates stylesheet generation
test4.php - demonstrates a mindlessly easy use of frames, allowing
            a single PHP file to generate all the frames for a
            single page.

(hopefully your mailing list server permits attachments).

For me, this scheme is proving far easier to write with.
By keeping the global functions' names as short as possible, and not
prefixing them with 'html_', I avoid ending up with code that indents
right off the edge of the screen.

With this 'tagwriter' scheme, I was able to re-write my php/postgres web
application into something that for me is very readable.

Note - the 'tagwriter.inc' is not exactly complete - very lacking in
comments, argument validation etc, but it's working sufficiently well to
demonstrate the concepts.

The one feature I got excited about was the 'parametric substitution'
thing. This provides the ability to accumulate a library of HTML code
tree fragments, boilerplates, and to 'include_once()' them as desired.

I'm in no way interested in any kind of 'php html library war' - just in
personally having an easy time with php programming, and perhaps
supporting others to have the same.
So please feel welcome to rip off anything in tagwriter that you may
like. I'll only say that I've issued tagwriter here under GPL. I don't
even know if I'll end up publishing it.

Cheers
David


On Sat, 2002-06-15 at 05:36, Walter A. Boring IV wrote:
> First things first,
>   Thanks for the Critique.  It's always healthy for any project to get
> some devil's advocate/crituquing, and I appriciate it.  Thanks.  no
> really. :)  
>   That being said and out of the way, when I wrote the libs, I was doing
> just for a fun project to do and with no real "lets convert the entire
> php engineering population to the libs" kind of thought process.  I
> personally find the libs very usefull for many reasons, so I choose to
> use em.  If they aren't for you, then thats kewl to.  
> 
> > Hi all,
> > 
> > I fear that I might come across as putting down phpHtmlLib, so please
> > try and trust that that is not my intention.
> > 
> > I love the concept of phpHtmlLib, that of abstracting the generation of
> > HTML code.
> > 
> > But after working with it for 2 days, I've gone back to printing out raw
> > html for now.
> > 
> > In using phpHtmlLib, I've found that the abstractions can be more fiddly
> > to drive than raw html generation itself.
> > 
> > At first, I felt really enthusiastic, and started converting a web-based
> > project management application over to phpHtmlLib.
> > 
> > My app generates some intricate HTML - tables nested 3 deep, rows and
> > columns full of links which vary according to php script invocation
> > flags and database content. More, link and non-link column styles -
> > colours, italics, bold etc - also vary according to script arguments and
> > database content.
> > 
> > I gave up trying to convert the app. Instead, I started writing a
> > completely new script, borrowing slightly from the logic of the raw one.
> > 
> > But on writing the phpHtmlLib code, I found myself having to create tons
> > of temporary variables to keep track of things.
> ---with 2.0.0 and the html_* wrappers, this should help some, as well as
> the new constructor args.
> 
>  
> > It all started to feel like programming in assembler. The abstraction
> > mechanisms of phpHtmlLib came at a price - a whole lot of concrete
> > tracking of details, and a whole lot of 'noise' in the script, which
> > completely destroyed its readibility. The code ended up far more
> > concrete than before.
> > 
> > [It's a shame we don't have 3D displays. Then, logic indenting could go
> > left-right, and tag indenting could go front-back. Or perhaps someone
> > with too much time on their hands could write a LISP major mode script
> > for phpHtmlLib to represent different levels of tags as different
> > colours']
> > 
> > But seriously, it would be unfair for me to just rant on without
> > offering some kind of ideas for how this could be fixed. Well, here
> > goes...
> > 
> > 1) Create a 'cursor' object, so that every time a tag object gets
> > created, the cursor gets set to that object. Then, one could do
> > something like 'add("A line of text")', and know the text will be
> > written to the right place, without having to keep track of what the
> > current tag is.
> ---you can do this with references, but it creates very difficult to
> read/manage code.  The nice thing about the libs is that its just an 
> object tree.  So anyone that knows OOP can use them out of the box, with
> a little learning curve.
> 
> > 2) Complementary to (1) - a function allowing an arbitrary 'pop' back to
> > any level of the stack. For example, if one is currently writing an <a>
> > within a <div> within a <td> within a <tr> within a <table> within a
> > <td> within a <tr>, one could pop the 'cursor' back to the outer level
> > '<tr>' tag.
> ---use references if you have to do this.  Most of the time I don't have
> to worry about "popping" back out to an outer level.  If you organize
> code with lots of functions/objects then this really doesn't happen that
> often.  In my case, I usually write a widgets which are logical html
> "objects" and I just stuff data into them.  I don't care how they are
> structured.  its just data.
> 
> > 3) Make reference the standard default type of 'push'. For situations
> > where someone really wants to do the 'copying'-style push, provide a tag
> > object copying function (or method) which completely copies a tag object
> > and all its children. With methods such as 'push_row()', the lack of a
> > reference push is a big drawback.
> ---I am playing with making push handle references.  The problem with it
> is, that since push can accept n # of arguments, I have to use the
> func_* functions, which do not do references.  Hence the push_reference
> (and now add_reference replacement of push_reference), that only takes 1
> parameter.  This is just a limitation in the php language that I can't
> get around for the moment.
> 
> > 4) Allow for easy creation of template classes.
> > For example, it would be lovely to have a class which writes 10-point
> > bold green centred links within a table column, without having to create
> > n levels of tags each time.
> ---anyone can do this.  They are called functions, or objects :)  The
> libs are not intended to cover every web engineer's style of output
> html, but to provide a standard Object API for building/rendering html
> as close as the w3c spec as possible.  
>   If you want specific styled/colored objects, tags, you should write
> your own wrapper functions/objects.  I do this on many of my
> applications I used the libs with.  Take for example, I have a span with
> a specific css class that I use everywhere.  So I just create a specific
> local (to the app) library wrapper.  Something like,
> 
>  function span_font10(  ) {
>     $args = func_get_args();
>     $span = new SPANtag( array("class" => "font10") );
>     push_args( $span, $args );
>     return $span;
>  }
> 
> Does this mean that the phphtmllibs should include this?  I don't think
> so. 
> 
>  
> My $0.02
> Walt
>