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
>