Re: [PEPr] Comment on HTML::HTML_FormPersister

Dmitry Koterov wrote:

Dmitry Koterov (http://pear.php.net/user/koteroff) has commented on the proposal for HTML::HTML_FormPersister. Comment: a) As I googled, flexyparser is written in C - http://devel.akbkhome.com/svn/index.php/akpear/flexyparser/ - and it needs dl() to load - it is not supported on most virtual hostings. HTML_Template_Flexy is complete templating system, it uses its own ideology to work with. Tidy does not support callbañks (as I know) and loaded by default only in PHP5 (not in PHP4) - same troubles with hostings (not everybody could allow himself to use own machine fully dedicated to his site :-). The other one was HTML_Sax - this should do what you are looking for.

b) About performance. Caching is not needed - ideologically. Class works with ANY HTML generated by ANY type of code (manual-written or generated by template system- no matter). This method - outputbuffering, then parsing the buffered data, then outputting it again, scares the hell out of me for performance reasons. Flexy which does full HTML parsing, can take >5 seconds on a really complex HTML page, (although this only happens once per file change). When you factor this into a busy site, and this peice of code would be a critical component, it would be negligant to suggest that it is suitable for a site that's traffic may grow.

But you shouldn't take care about performance, because HTML_SemiParsed DOES NOT parse input HTML completely. It searches for few tags and parses them only. For example, it searches for "<INPUT", "<SELECT" etc. sequences in HTML and then, if found, performs callbacks. PCRE regular expressions are extremely fast in these cases and gives us no overheat if page contains no form elements (for example). you cant believe how difficult it is to parse HTML in reality.. - things like this are only the tip of the iceburg...

<input type="button" value="Add Row" onclick="javascript: doc.getElementById('xxxx').innerHTML =+ '<input name=\'some item\'>'"> imagine someone putting javascript in the page: input = doc.getElementById('someelement').value if (12 <input ) { ...... } if (input > 12 ) { .....

So, if you have not so many form elements in your page (<20), performance is not a problem at all. c) About "seperation of input and rendering". If user have entered some text in the form, afrer submission he expects that these texts will stay uncganged (if this form is shown again, as it performed in most cases). Getting and user-defined input processing is the task of controller, and it could still be performed as usual. No changes. You need to read the basics of Model/View/Controller to understand that comment (while not absolutely perfect for web, it's not a bad guide), a library (which is what pear is generally), should be very carefull about how much it reads from request variables or even outputs, doing both starts to destroy alot of the flexibility in the class..

d) About "difficult to register callbacks" - I do not understand, please work out in detail. $parser = HTML_Parser::construct(array(

                  'tag' => '..callback..',
                  'cdata' => '....callback...',
         .....

)); This makes it alot clearer how one class is interacting with another, without depending on the reader to examine the base class..

e) Words about "code from include" is not understood too - please itemize. Maybe you said about flip-fields? They are not so necessary and could be excluded from the package, because they only simplify working with <select multiple> elements, no more. A library should be called from the incuding code, it should generally not do _Anything_ unless you tell it to, your library goes off and turns inputbuffering on, reads input and outputs stuff, just based on including it, this is not the behaviour you would expect of a library.

you should do something like include 'HTML/.....php'; HTML_FormPersister::run(); or similar REgards alan

Proposal information: http://pear.php.net/pepr/pepr-proposal-show.php?id=193