HTML Controls

Hi, I've just started writing a package to scratch a certain itch. That is, I wanted to be able to create HTML controls in a more abstract way so that programming against them because easy, ..almost 'VB' or 'Delphi' like. I've looked at HTML_QuickForm, but it doesn't really meet my requirements. I'll explain why later. The api itself is loosely based on that of MS's .NET WebControls, which inspired me in the first place. It is their clean api which made it very attractive. The ultimate goal is to be able to create HTML controls, that: 1) Are easy to create. 2) Maintain their own state. 3) In the case of list controls, can be data-bound. 4) Do not make 'designing' forms more difficult. 5) Can optionally retain values over a session (for 'wizard' interfaces) Number 4 is of particular importance. I don't want the logic required by the programmer's script to interfere with the page design, ..making reusability and the inevitable (page redesign) more straight forward. A typical example of usage would be as follows: //*********************************************** <?php require_once "HTML_Controls/TextBox.php"; require_once "HTML_Controls/Button.php"; // Setup the controls with their default properties. // This should generally happen near the top of the script. $txtName = new TextBox("txtName"); $txtName->cssClass = "mytextclass"; $txtName->maxLength = "20"; $btnSubmit = new Button("btnSubmit"); ?> // Do your standard HTML stuff, then render the controls at the desired point. <form name="blah" method="post"> <p><b>Name:</b><br> <?php $txtName->render(); ?> </p> <?php $btnSubmit->render(); ?> ***********************************************// The really cool thing is having the controls maintain their state. Thus, after you have created the controls at the top of the script, you can interrogate them as part of your logic. If you want to use the value from the textbox in a sql statement, you would use $txtName->text. Whilst I'm sure that many people find HTML_QuickForm very useful, you can see how my goals might conflict. I'm focussing on absolute ease of use. Built in state maintenance (even though it wouldn't suit _everyone_) is incredibly important to me. I guess what I'm asking is, should I code this to PEAR conventions and submit it? If people are generally happy with the HTML_QuickForm method, or think that my package might be too similar then I'll keep it separate. I don't wish to tread on the toes of the HTML_QuickForm developers, but feel that my code might offer a different perspective on the OO forms idea. Any thoughts? Cheers. James Hurst. mailto:james@projects.new-media.co.uk // "Better lives have been lived in the margins, // locked in the prisons and lost on the gallows than // have ever been enshrined in palaces." - Propagandhi 2001