phphtmllib-devel — phpHtmllib devel mailing list

[Phphtmllib-devel] more changes

[Walter A. B. I. <wb...@qu...>]

Howdy,
  I'm working on adding lots more html_* helper functions with various
"standard" params for each specific tag to be built.  One of the changes
I am making to html_td() is to add specific commonly used params.
Currently html_td() only accepts content.  This kinda sux.
So I have come up with 
html_td($class, $align, $width),
params 4 through n are content.

  I thought about adding colspan as the 4th param, but in my experience,
its not used as often as the other 3.  Also, according to the w3c spec
width is depricated.  You should use a style="width:100px" to set the
width of the td...but, how many ppl know to do that?  My guess is not
many.  So this leads me to a gray area between the w3c, which I would
like to conform to, and normal implementation of html.  Browsers still
to this day are not very compliant in their implementation of the spec,
so its hard to try and enforce an api to the libs that require
conformance.  
So, for the time being I'm trying to take each tag as a case by case
basis for conformance vs. implementation.  Hence my addition of the
width param to html_td().

Also, note, this change to html_td() will break 1.1.x of the libs.
folks will have to change their use of html_td().

Thoughts?
Walt

[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] 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  '  '

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

[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] 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

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

[Phphtmllib-devel] [Fwd: function references]

[Walter A. B. I. <wb...@qu...>]

So I just upgraded my box here at work to php 4.2.1, and I noticed that
the Zend folks are depricating the use of call time pass reference.
This basically depricates

function foo(&$bar) {};

The problem is, push_reference uses that.  So I was wondering if we
should bite the bullet in 2.0.0 and remove the call time pass by
reference in all of the push_reference functions, since at some time in
the future (possible php 5, which isn't that far off), that won't even
work.
  With php 4.2.1, you get php errors( notices ) whenever a function is
called with this.  Does it make sense to change this in 2.0 ?

Walt

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:

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

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] 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:

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

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

[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] 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

[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] multiple select box

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

Howdy,
  I actually found this issue as well, and have it fixed in the 
CVS version (2.0.0) of the libs.  There is a 4th param to the
form_select() function that is a flag to make the select tag
add the multiple attribute.

function form_select($name, $options=array(), $selected="", 		    
$multiple_flag=FALSE) {

    $select = new SELECTtag( array("name" => $name) );
    if ($multiple_flag) {
	$select->set_tag_attribute("MULTIPLE");
    }
...


Walt



On Wed, 2002-06-05 at 04:12, winston ralph wrote:
> Hi,
> Must say great class, it's made my job a hell of lot easier.
> Nice standard, clean easy to read HTML. Just a small query.
> I have looked through the classes and couldn't find how you
> would draw a multiple select box.
> eg;
> <select name=test multiple=true>
> <option>1</option>
> <option>2</option>
> </select>
> 
> The following would suffice : ie change the form_select method to
> something like the following
> 
> 
> function form_select($name, $options=array(), $selected="") {
> 
>     $select = new SELECTtag( array("name" => $name) );
> 
>     while( list($label, $value) = each($options) ) {
>         $selected_value = "";
>         if ($label == $selected) {
>             $selected_value = "SELECTED";
>         }
>         $attributes = array( "value" => $value, $selected_value );
>         $option = new OPTIONtag( $attributes );
>         $option->push( $label );
>         $select->push( $option );
>     }
>     return $select;
> }
> 
> Then call the method like so:
> form_select($anonymous_array[],  $options_array, "", "multiple =>
> true");
> 
> But maybe I missed something and it's already there? Keep up the great
> work.
> Must download and try out the new version very soon.
> Regards,
> 
> Winston
> 
> 

[Phphtmllib-devel] multiple select box

[winston r. <win...@al...>]

SGksDQpNdXN0IHNheSBncmVhdCBjbGFzcywgaXQncyBtYWRlIG15IGpvYiBhIGhlbGwgb2Yg
bG90IGVhc2llci4NCk5pY2Ugc3RhbmRhcmQsIGNsZWFuIGVhc3kgdG8gcmVhZCBIVE1MLiBK
dXN0IGEgc21hbGwgcXVlcnkuDQpJIGhhdmUgbG9va2VkIHRocm91Z2ggdGhlIGNsYXNzZXMg
YW5kIGNvdWxkbid0IGZpbmQgaG93IHlvdQ0Kd291bGQgZHJhdyBhIG11bHRpcGxlIHNlbGVj
dCBib3guDQplZzsNCjxzZWxlY3QgbmFtZT10ZXN0IG11bHRpcGxlPXRydWU+DQo8b3B0aW9u
PjE8L29wdGlvbj4NCjxvcHRpb24+Mjwvb3B0aW9uPg0KPC9zZWxlY3Q+DQoNClRoZSBmb2xs
b3dpbmcgd291bGQgc3VmZmljZSA6IGllIGNoYW5nZSB0aGUgZm9ybV9zZWxlY3QgbWV0aG9k
IHRvDQpzb21ldGhpbmcgbGlrZSB0aGUgZm9sbG93aW5nDQoNCg0KZnVuY3Rpb24gZm9ybV9z
ZWxlY3QoJG5hbWUsICRvcHRpb25zPWFycmF5KCksICRzZWxlY3RlZD0iIikgew0KDQogICAg
JHNlbGVjdCA9IG5ldyBTRUxFQ1R0YWcoIGFycmF5KCJuYW1lIiA9PiAkbmFtZSkgKTsNCg0K
ICAgIHdoaWxlKCBsaXN0KCRsYWJlbCwgJHZhbHVlKSA9IGVhY2goJG9wdGlvbnMpICkgew0K
ICAgICAgICAkc2VsZWN0ZWRfdmFsdWUgPSAiIjsNCiAgICAgICAgaWYgKCRsYWJlbCA9PSAk
c2VsZWN0ZWQpIHsNCiAgICAgICAgICAgICRzZWxlY3RlZF92YWx1ZSA9ICJTRUxFQ1RFRCI7
DQogICAgICAgIH0NCiAgICAgICAgJGF0dHJpYnV0ZXMgPSBhcnJheSggInZhbHVlIiA9PiAk
dmFsdWUsICRzZWxlY3RlZF92YWx1ZSApOw0KICAgICAgICAkb3B0aW9uID0gbmV3IE9QVElP
TnRhZyggJGF0dHJpYnV0ZXMgKTsNCiAgICAgICAgJG9wdGlvbi0+cHVzaCggJGxhYmVsICk7
DQogICAgICAgICRzZWxlY3QtPnB1c2goICRvcHRpb24gKTsNCiAgICB9DQogICAgcmV0dXJu
ICRzZWxlY3Q7DQp9DQoNClRoZW4gY2FsbCB0aGUgbWV0aG9kIGxpa2Ugc286DQpmb3JtX3Nl
bGVjdCgkYW5vbnltb3VzX2FycmF5W10sICAkb3B0aW9uc19hcnJheSwgIiIsICJtdWx0aXBs
ZSA9Pg0KdHJ1ZSIpOw0KDQpCdXQgbWF5YmUgSSBtaXNzZWQgc29tZXRoaW5nIGFuZCBpdCdz
IGFscmVhZHkgdGhlcmU/IEtlZXAgdXAgdGhlIGdyZWF0DQp3b3JrLg0KTXVzdCBkb3dubG9h
ZCBhbmQgdHJ5IG91dCB0aGUgbmV3IHZlcnNpb24gdmVyeSBzb29uLg0KUmVnYXJkcywNCg0K
V2luc3Rvbg0KDQoNCg==

Re: [Phphtmllib-devel] howdy

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

> Along the widget lines, I would like to see the idea of themes
> implemented in PhpHtmlLib.  I really like the the idea of themes
> that PHPnuke, PostNuke, et al. offer but I don't want or need their
> idea of users, articles, surveys, ad naseum.  I just want flexible,
> easy to use themes.
---There is some form of widget theming built in to the BaseWidget
class.  I kinda threw it together one night as a hack, so I know its not
perfect, but it works for the most part.
  How it works is this.  Any widget that you want to be "themable", it
has to have a css file, which is a .php file.  The .php file contains 
mostly all css definitions.  Take a look at
phphtmllib/widgets/css/TextNav.php.  It's a simple example.
What you do is to just make the values of the css items you want to be
changeable on the fly into php variables.  So for example, in
widgets/css/TextNav.php, you will see

A.textnavlist:hover {
        color: $fonthover;
}

where the value for the color is a php global var.

In widgets/TextNav.inc you will see a member variable called
$_css_colors, which is an array of name=>value pairs.  The name should
be the name of the var you use in the css php file.
You will also see the $_css_file var which is the name of the css file
that is used for the widget.

What the hell is this crap? :)

Well, there is a method in the BaseWidget class called get_css_file().
This method returns a string which is the path to the css file used by
the widget, along with a query string of the name=value pairs of the
themed items.  So at some point in a script when u create the particular
widget, you add the css link to the page, and it will automatically
create the link to the php css file with the name=value pairs in the
query string, which will set the values of the global variables in the
php css file.  Its a hacked way of dynamic theming.  You can manage the
values of the $_css_colors array with the methods:
set_css_item_color( $name, $value ) and
get_css_item_color( $name )



So if you want to use this, when u create a widget, all you have to do
is build the css file as php, and add the $_css_file member variable, as
well as the $_css_colors array with the names, and default values.

example?

<?php

$page = new HTMLPageClass("some lame name");

$textnav = new TextNav(400);

//you can change the themed values here BEFORE
//you add the css link to the page.
//uncomment these next 3 lines to override
//the default themed colors for the widget.
//$textnav->css_set_item_color("background", "#CC0000");
//$textnav->css_set_item_color("font", "#00FF00");
//$textnav->css_set_item_color("fonthover", "#FFFFFF");

//add the css link to the page w/ the themed values
$page->push_css_link( $textnav->get_css_file() );

$textnav->push("http://www.amazon.com", "Amazon", 200 );
$textnav->push("http://www.ebay.com", "Ebay", 200 );

$page->push( $textnav );
print $page->render();

?>


I hope this made SOME sense at least.  I know its not a perfect
solution, but it worked for me at the time I needed it.  I'd like
a more flexible and elegant solution if possible, but this does work.


Walt

Re: [Phphtmllib-devel] howdy

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

Walter A. Boring IV wrote:

> Hey folks,
>   I just wanted to say hi, and see if this list was working, since some
> folks have signed up.

It appears to be working just fine.  =)

> [...]
> 
>  I would eventually like to see more widget classes built that add more
> value to the libs other then just building xml/html/xhtml tags.  I have
> a bunch of widgets that I have built over time for various web
> applications.  I personally feel the long term value of the libs is in
> the widgets.  
>   Widgets are nothing more then classes that help build some html
> "widget", such as a table with a border, title, and rows of data.
> The purpose of these widgets is to make it much easier to build complex
> html structures.  So all the php programmer has to do is worry about 
> getting the data, and stuffing that data into the object.
> HTMLPageClass is a widget that helps the programmer build a fully
> qualified html page.  

This may be an ambitious desire...

Along the widget lines, I would like to see the idea of themes
implemented in PhpHtmlLib.  I really like the the idea of themes
that PHPnuke, PostNuke, et al. offer but I don't want or need their
idea of users, articles, surveys, ad naseum.  I just want flexible,
easy to use themes.

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

[Phphtmllib-devel] howdy

[Walter A. B. I. <wb...@qu...>]

Hey folks,
  I just wanted to say hi, and see if this list was working, since some
folks have signed up.

I am currently working on version 2.0.0 of the libs, which is a small
rewrite of the base class HTMLTagClass to be based off of 
XMLTagclass, which in turn is a child of Container.

This will let everyone build xml/html/xhtml with the same exact api.
It is 100% compatible w/ the 1.x series of the libs, and should have a
few more bells n whistles.  

I will probably be putting the CVS repository for phphtmllib up on
sourceforge in the next week or so, so folks can check out the latest
and greatest at any time.  Also, if you would like to contribute to the
libs, you can feel free to send me patches for review, and eventually I
will give some folks write access to the cvs repository.  

 I would eventually like to see more widget classes built that add more
value to the libs other then just building xml/html/xhtml tags.  I have
a bunch of widgets that I have built over time for various web
applications.  I personally feel the long term value of the libs is in
the widgets.  
  Widgets are nothing more then classes that help build some html
"widget", such as a table with a border, title, and rows of data.
The purpose of these widgets is to make it much easier to build complex
html structures.  So all the php programmer has to do is worry about 
getting the data, and stuffing that data into the object.
HTMLPageClass is a widget that helps the programmer build a fully
qualified html page.  

Anyways, I'm rambling, so I'll shut the f up :)

Walt

[Phphtmllib-devel] testing

[Walter A. B. I. <wb...@qu...>]

This is a test.

Walt