Click
  1. Click
  2. CLK-3

Controls generate incompatable XHTML

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None

      Description

      This issue was raised by Andrus Adamchik:

      "I used Click AJAX features and discovered that most standard
      controls are not XHTML compatible. So I had to create my own ugly
      formatter method to filter Field output:

      public String xml(Field field) {
      // fixing click bug - fields rendering is not XHTML compatible

      if (field == null)

      { return ""; }

      String string = field.toString();
      if (string.startsWith("<input"))

      { string = string.replace("checked", "checked='checked'"); string = string.replaceAll("([\\w])''", "\\1'"); string = string.substring(0, string.length() - 1) + "/>"; }

      else if (string.startsWith("<select"))

      { string = string.replace("selected", "selected='selected'"); }

      return string;
      }

      It would be nice if the framework could generate XHTML by default or
      have a flag somewhere to control it."

        Activity

        Hide
        Malcolm Edgar added a comment -

        Click initially generated controls which were valid XML, but I changed this to make it compliant with HTML 4.01.

        However HTML 4.01 is not necessarily valid XML, for example:

        <input> rather than <input/>

        I dont think it is a major issue changing it back to valid XML, but people will have to accept that its not strictly conformant HTML.

        I dont really want to make HTML vs XHTML configurable, as its more stuff to document and explain. I want to keep the learning curve simple, introducing unneccesary details like this doesn't help.

        regards Malcolm Edgar

        Show
        Malcolm Edgar added a comment - Click initially generated controls which were valid XML, but I changed this to make it compliant with HTML 4.01. However HTML 4.01 is not necessarily valid XML, for example: <input> rather than <input/> I dont think it is a major issue changing it back to valid XML, but people will have to accept that its not strictly conformant HTML. I dont really want to make HTML vs XHTML configurable, as its more stuff to document and explain. I want to keep the learning curve simple, introducing unneccesary details like this doesn't help. regards Malcolm Edgar
        Hide
        Malcolm Edgar added a comment -

        Unless there are not comments against this Click controls will be modified in the next release to generate valid XHTML.

        regards Malcolm Edgar

        Show
        Malcolm Edgar added a comment - Unless there are not comments against this Click controls will be modified in the next release to generate valid XHTML. regards Malcolm Edgar
        Hide
        Ahmed Mohombe added a comment -

        Please don't do it !. (I mentioned this on the newsgroup too).
        If I could vote against it, than I would (but JIRA doesn't allow it).

        XHTML breakes and restritcts Javascript functionality allot.
        There are many good javascript libraries that use innerHTML, and it would be said not to be able to use them
        just because of 'standard fanatism'.
        Most libraries that do a little more 'rich' functions, and many AJAX effect libs too are based on this innnerHTML: it's simple, very fast and it just works.
        I see no real reason why we should use XHTML since HTML offers all that and more. Why should we complicate things?

        Maybe I'm wrong here and I didn't understood XHTML well, but from my tests, many cool javascript libraries just don't work in XHTML mode.

        Thanks in advance,

        Ahmed.

        Show
        Ahmed Mohombe added a comment - Please don't do it !. (I mentioned this on the newsgroup too). If I could vote against it, than I would (but JIRA doesn't allow it). XHTML breakes and restritcts Javascript functionality allot. There are many good javascript libraries that use innerHTML, and it would be said not to be able to use them just because of 'standard fanatism'. Most libraries that do a little more 'rich' functions, and many AJAX effect libs too are based on this innnerHTML: it's simple, very fast and it just works. I see no real reason why we should use XHTML since HTML offers all that and more. Why should we complicate things? Maybe I'm wrong here and I didn't understood XHTML well, but from my tests, many cool javascript libraries just don't work in XHTML mode. Thanks in advance, Ahmed.
        Hide
        Malcolm Edgar added a comment -

        The reported issue from Andrus Adamchik is:

        "An AJAX response that is not valid XML would refuse to render (Firefox, Mac OS X). So the area that would otherwise display content obtained via AJAX would stay blank.

        The changes I am proposing it to have Control attributes rendered as:

        <input type='text' disabled='disabled'/>

        Instead of:

        <input type='text' disabled>

        Does this affect JavaScript?

        regards Malcolm Edgar

        Show
        Malcolm Edgar added a comment - The reported issue from Andrus Adamchik is: "An AJAX response that is not valid XML would refuse to render (Firefox, Mac OS X). So the area that would otherwise display content obtained via AJAX would stay blank. The changes I am proposing it to have Control attributes rendered as: <input type='text' disabled='disabled'/> Instead of: <input type='text' disabled> Does this affect JavaScript? regards Malcolm Edgar
        Hide
        Malcolm Edgar added a comment -

        Committed to CVS will be available in release 0.12

        Show
        Malcolm Edgar added a comment - Committed to CVS will be available in release 0.12
        Hide
        Malcolm Edgar added a comment -

        Fixed in release 0.12

        Show
        Malcolm Edgar added a comment - Fixed in release 0.12

          People

          • Assignee:
            Malcolm Edgar
            Reporter:
            Andrus Adamchik
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development