4 Replies Latest reply: Dec 22, 2012 4:39 PM by 617057 RSS

    Automatic Encoding of Application Items

    617057
      I just upgraded from 4.0 to 4.2 and I've noticed there is an encoding in place that wasn't there before. For instance if I got to a URL like this (this URL will not work for you, no need clicking on it, just look at the application item getting set):
      https://dev.surveyorhealth.com/meds/f?p=500:4002:0::::AI_PATIENT_BIRTH_DATE:03%2F07%2F2001

      Now when I look at the value in the session it reports this: 08/01/2012

      What is this format? And how to I "decode" it? I need to do something like this with the value:
      SELECT to_date(:AI_PATIENT_BIRTH_DATE,'MM/DD/YYYY') INTO l_birth_date from dual;
      But this fails with the following error:
      ORA-01858: a non-numeric character was found where a numeric was expected

      I've tried a variety of conversion procedures that apex offers but I can't find one that will get the string back into a useful format.
      In the meantime I'm doing this (I know it's a terrible idea)
      SELECT to_date(replace(:AI_PATIENT_BIRTH_DATE,'/','/'),'MM/DD/YYYY') INTO l_birth_date from dual;
      This works but I'm sure there must be a proper conversion function around that I could use.

      Thanks
        • 1. Re: Automatic Encoding of Application Items
          Matthew Morris
          Something is getting lost in translation here. I don't know what you mean by encoding:

          "AI_PATIENT_BIRTH_DATE:03%2F07%2F2001"

          This simply translates to setting page item AI_PATIENT_BIRTH_DATE to *03/07/2001*. The page value can't be passed in the URL as '/' because the slash is a special character in a URL. '%2F' represents '/'.
          Now when I look at the value in the session it reports this: 08/01/2012
          I don't understand this because the value of AI_PATIENT_BIRTH_DATE according to the URL you supplied should have been *03/07/2001*.
          What is this format?
          It appears to be MM/DD/YYYY. Fairly standard -- so I'm missing something.
          SELECT to_date(:AI_PATIENT_BIRTH_DATE,'MM/DD/YYYY') INTO l_birth_date from dual;
          But this fails with the following error:
          That is bizarre. If what you have showed is correct, then I'd suspect a non-printing character. I don't really know, though.

          SELECT to_date(replace(:AI_PATIENT_BIRTH_DATE,'/','/'),'MM/DD/YYYY') INTO l_birth_date from dual;
          It makes no sense that this works and the previous one did not. The only difference is the REPLACE which is replacing a character with itself... so far as I can tell. The other possibility, I suppose, is that there are characters which are not showing up due to the nature of the forum posting. If there are HTML tags, they'll get filtered out of your post.
          • 2. Re: Automatic Encoding of Application Items
            617057
            Thanks for the response. Indeed the post made no sense because the forum has altered the appearance of my text.

            The value seen in the application item is 08/01/2012

            Which means the select that works actually looks like this:
            SELECT to_date(replace(:AI_PATIENT_BIRTH_DATE,'/','/'),'MM/DD/YYYY') INTO l_birth_date from dual;
            • 3. Re: Automatic Encoding of Application Items
              fac586
              Shawn Kessler wrote:
              Thanks for the response. Indeed the post made no sense because the forum has altered the appearance of my text.

              The value seen in the application item is 08/01/2012

              Which means the select that works actually looks like this:
              SELECT to_date(replace(:AI_PATIENT_BIRTH_DATE,'/','/'),'MM/DD/YYYY') INTO l_birth_date from dual;
              In 4.2 there is a new HTML Escaping Mode security attribute, which is set to "Extended" by default. You can find it under Edit Application Properties > Security > Browser Security. Setting it to "Basic" may restore the previous behaviour. (This setting might not be visible if Edit Application Properties > Properties > Compatibility Mode isn't set to *4.2*.)

              However, the best practice is simply to avoid data representations that use URL reserved characters in links (e.g. for dates use YYYYMMDD or ISO 8601 YYYY-MM-DD formats). I'm standardising on using ISO 8601 representations for non-displayed date values. These are unambiguous, sort properly using character semantics, and are compatible with other systems and technologies.
              • 4. Re: Automatic Encoding of Application Items
                617057
                I've seen the HTML Escaping Mode talked about in other threads. I don't mind using the extended setting if there is a straightforward way to un-escape the characters when you needed them in their original format.

                But if that's not possible, I'll likely take your suggestion and change the format, so thanks for that.