Comments for "HTML_FormPersister"

» Submit Your Comment
Comments are only accepted during the "Proposal" phase. This proposal is currently in the "Finished" phase.
» Comments
  • Justin Patrin  [2005-01-17 22:22 UTC]

    First of all <% and %> are ASP tags. Please use <?php and ?>. Second, the HTML_QuickForm package already does the same kind of thing, albeit via creating an object for your form and elements.

    I can see this being possibly useful, but only for quick and dirty scripts. I honestly wouldn't trust a simple HTML parser and and rewriter to get everything right. I'd much rather HTML_QuickForm with the additional functionality it gives and the more correct way of handling this. i.e. before the HTML is created.
  • Dmitry Koterov  [2005-01-17 23:21 UTC]

    You are so meticulous about ASP tags, I have used it only because my text editor messes up syntax highlighting if I write <?...?> in COMMENTS (COMMENTS!!! Not code!). :-)

    Don't you think templates with embedded forms are written not only by programmers, but by HTML-makeup men too? And we shouldn't mix up presentation logic and business-logic? HTML_FormPersister, of course, may be used as a fast way to improve "traditional" scripts with no need of their modifications at all.

    Apropos, used HTML-parser is not so "dirty" as it could be thought. With correct HTML on input - it works very fine. But - let's talk about that in HTML_SemiParser proposal: http://pear.php.net/pepr/pepr-proposal-show.php?id=194
  • Lukas Smith  [2005-01-17 23:42 UTC]

    Well the approach taken is novel enough in my book. I havent looked at the implementation nor really pondered the feasability, but it certainly takes a new spin at things compared to existing form handling solutions in PEAR that it should certainly not be seen as a redundant package.
  • Alan Knowles  [2005-01-18 01:50 UTC]

    The concept is quite interesting (it's basically how flexy's element stuff works in principle)
    however the implenentation has some serious questionable issues:
    a) parsing HTML with regex seems like a recipe for disaster... (the parser package)
    - HTML Tidy?, google flexyparser / look at Flexys HTML parser.
    b) performance of a non-cache based solution would be very questionable.
    (consider some kind of compiled solution?)
    c) this totally breaks the seperation of input and rendering.. (think of the end user manually giving the package the input data, rather than it reading it directly.)
    d) the extending parser design makes the code very difficult to follow, registing callbacks may be clearer

    e) actually running the code from the include is very naughty - it stops the code be used as a library.
  • Dmitry Koterov  [2005-01-18 16:57 UTC]

    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 :-).

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

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

    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.

    d) About "difficult to register callbacks" - I do not understand, please work out in detail.

    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.
  • Dmitry Koterov  [2005-01-19 11:05 UTC]

    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.
  • Dmitry Koterov  [2005-01-24 17:25 UTC]

    And - on more thought about lightweight HTML parser. Look to PHP's standard session engine - I mean use_trans_sid. It ALSO uses incomplete HTML parser to insert SID's into <a> and rather <form>, but - there no complaints (at least, I have not heard). And it works enough fast for "production sites". :-)