[suspicious - maybe spam] [PEPr] Comment on HTML::HTML_FormPersister

Dmitry Koterov (http://pear.php.net/user/koteroff) has commented on the proposal for HTML::HTML_FormPersister. Comment: Few questions & answers from email - for avoiding answer the same questions twise. Sorry if this text become broken - there is no "preview" button here. >>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. I am not looking for anything, I propose the solution, which is used in about 10 production sites. ;-) HTML_Sax is too large, too slow, and too excessive. I do not need to parse ALL html, just only small piece of it - form elements. >>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. 100000 hits per day - not a problem. And no overheat at all for pages fith no forms. You wanna create yet another Google? :-) >>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.. I can, believe me. ;-) > - 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\'>'"> Suppose, this example works correctly: <input type="text" name="a" default="Add Row" onclick="doc.getElementById('xxxx').innerHTML =+ '<input name= \'some item\'>'"> Try it. ;-) It is replaced into: <input type="text" name="a" onclick="doc.getElementById('xxxx').innerHTML =+ '&lt;input name=\'some item\'&gt;'" value="222" /> And, in general, your example is not a correct XHTML - no '<' characters are allowed in attributes, you must use &lt; for it. > imagine someone putting javascript in the page: > input = doc.getElementById('someelement').value > if (12 <input ) { > ...... > } > if (input > 12 ) { ..... And THIS is a real problem, you're right. Frankly, code must ignore <script>...</script> containers. But this case is plenty occasional. >>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.. You do not understand purpose of HTML_FormPersister, I suppose. ;-) MVC is another layer, library is used ONLY to save user input between submissions of certain form. >>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.. $parser = new HTML_SemiParser(); $parser->addTag("a", "callbackName"); $parser->addContainer("pre", "callbackName"); Difficult? :-) >>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, Wrong! Have you seen a code at all? :-) Do it now: http://pear.dklab.ru/lib/HTML/FormPersister.php > 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 See the code. :-) processFlip(), as I said before, is not obligatory. It may be excluded from the library, because it only extends PHP form input engine adding support for "key-based" fields: * <select multiple name="@sel"> * <option value="first" selected>First</option> * <option value="second">Second</option> * <option value="third" selected>Third</option> * </select> * * (watch "@" prefix!) gives the result: * $_REQUEST['sel'] === array('first'=>'first', 'third'=>'third') * * It is much more logical to work with associative array instead * of lists for multiple selects. It is used very rarely and could be excluded. Proposal information: http://pear.php.net/pepr/pepr-proposal-show.php?id=193 -- Sent by PEPr, the automatic proposal system at http://pear.php.net