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