Forum Stats

  • 3,781,536 Users
  • 2,254,528 Discussions
  • 7,879,748 Comments

Discussions

Textarea with newlines

partlycloudy
partlycloudy Member Posts: 8,095 Silver Trophy
edited Nov 24, 2021 2:03PM in APEX Discussions

https://apex.oracle.com/pls/apex/f?p=134181:79

When the text area item contains a string with newlines (e.g. 1234\n5678) the behavior is a little strange

  1. The character counter shows 10
  2. The server side DA (length(:item)) shows 10
  3. The server side DUMP shows 10 with CHR(13) and CHR(10)
  4. Client side script apex.item(:item).getValue().length shows 9

Intuitively, #4 makes sense to me and I would expect #1 and #4 to match since they are client side values.

Questions

  1. What is going on here?
  2. How can I add a server side validation to restrict the length to X characters using client side semantics i.e. using CR for newline instead of CR+LF
  3. Setting up a simple example in sqlplus also shows the newline represented by CHR(10). So where exactly does APEX ACCEPT processing introduce the CHR(13)?!!
create table foo(s varchar2(10));
insert into foo(s) values ('1234
5678');
select s,length(s) l,dump(s) d from foo


@Patrick Wolf-Oracle

Thanks

Edit: Inspecting the XHR requests shows that itemsToSubmit sends a newline as \r\n instead of simply \n. Is this a bug? Can this behavior be changed?

{
   "p_flow_id": "134181",
   "p_flow_step_id": "79",
   "p_instance": "9562125705508",
   "p_debug": "",
   "p_request": "PLUGIN=REEgVFlQRX5-MjQwMzg3MjQwNzg4OTYzNzQy/b9WwH-mRaJRMDBBMmMUJB6siUMNKIFftJz7Lb8rqPlrrKjsXFrpS7qKbw0-3ieuptnP1CAg0EC3FXja625bkaA",
   "p_json": "{\"pageItems\":{\"itemsToSubmit\":[{\"n\":\"P79_TEXT\",\"v\":\"1234\\r\\n5678\"}],\"protected\":\"UDc5X0xFTkdUSDpQNzlfRFVNUDpQNzlfTEVOR1RIXzE6UDc5X0RVTVBfMQ/FHenCYgvpHMBQJhe2v-STPOXhhka5HeGR0QwdTEJa0ddtAr34d8WO_K_3dylZkAzhlXPmxAG9GLHup6qeeab0A\",\"rowVersion\":\"\",\"formRegionChecksums\":[]},\"salt\":\"238399275411624567538150413637297130171\"}"
}

Best Answer

  • partlycloudy
    partlycloudy Member Posts: 8,095 Silver Trophy
    Accepted Answer

    Thanks so much to Marc and @Stefan Dobre for helping resolve this over a APEXD2D session yesterday. Just updating this thread for everyone's benefit by paraphrasing Stefan's comments

    https://www.w3.org/TR/html401/interact/forms.html#h-17.13.4.1

    Turns out that a newline is always sent over the wire as a CRLF (2 characters) but in Javascript it is 1 character so that explains the off-by-one issue 

    The character counter on the text box however, has a little bit of logic in it to mimic the “final” length of the value. So that if it says even if the real length is 98 with 2 line breaks, it will say 100/100, you’re sure the value will get through. Otherwise the user might get a validation error despite the counter seeming alright.

    Solution: Create a after-submit computation (before validations and processes) that replaces chr(13)||chr(10) with chr(10) for the textarea item. This way the item will have the expected value in subsequent page processing

Answers

  • partlycloudy
    partlycloudy Member Posts: 8,095 Silver Trophy
    Accepted Answer

    Thanks so much to Marc and @Stefan Dobre for helping resolve this over a APEXD2D session yesterday. Just updating this thread for everyone's benefit by paraphrasing Stefan's comments

    https://www.w3.org/TR/html401/interact/forms.html#h-17.13.4.1

    Turns out that a newline is always sent over the wire as a CRLF (2 characters) but in Javascript it is 1 character so that explains the off-by-one issue 

    The character counter on the text box however, has a little bit of logic in it to mimic the “final” length of the value. So that if it says even if the real length is 98 with 2 line breaks, it will say 100/100, you’re sure the value will get through. Otherwise the user might get a validation error despite the counter seeming alright.

    Solution: Create a after-submit computation (before validations and processes) that replaces chr(13)||chr(10) with chr(10) for the textarea item. This way the item will have the expected value in subsequent page processing