Properly type-casting multiple items in request handler

Folks,

I ran into something I could have sworn I saw work before (and maybe the difference is that it works in request handlers but not webnode actions). This is for the case of your form having multiple items with the same name (i.e. objID) and retrieving them in your request as request.objID_list.

In my prototype I have

{'objID', IntegerType, "Object ID", FALSE, Undefined, TRUE} - the last param to force the creation of objID_list in my request. If I had three object ID fields, say, 2000, 10101, and 10102, I would expect that request.objID = {2000} and request.objID_list = {2000, 10101, 10102}. Instead, I'm getting the list as strings, i.e. {'2000', '10101', '10102'}.

Is this a documented bug or is there a way of getting all my elements properly cast to integer?

-Hugh Ferguson

Find more posts tagged with

Comments

Christopher_Meyer

Hi Hugh, I don't believe the prototype creates the objID_list in the request; I believe it's done by the CGI when multiple form items have the same name. Nonetheless, for this use case I created my own function:

function List GetListFromRequest( Record request, String paramName, Integer dataType=StringType )    String listParam = Str.Format( "%1_list", paramName )    List items = {}    if RecArray.IsColumn( request, listParam )        items = request.(listParam)    elseif RecArray.IsColumn( request, paramName )        items = {request.(paramName)}    end    Dynamic item    List l    for item in items        l = {@l, $RHCore.DataUtils.toNativeValue(dataType, item)}    end    return lend

The function handles the case when the form field isn't repeated in the form (e.g., when using checkboxes). After the values are collected I run the values through a function to convert each value to an integer.

Hope this helps. Chris

HFCDev

Hi Chris,

I ended up doing something like that function. I wonder then why they have that last param in the prototype, when set to TRUE, means that you expect to have a <param>_list, or otherwise set FALSE. I'm starting to wonder if that param does anything now.

-Hugh

Christopher_Meyer

Hi Hugh: I've never seen or took notice to this parameter before. In what type of request is this parameter valid? Either way, you probably need to use your own function to properly cast the values in the list. I regularly use this function (and others) and rarely depend on prototypes anymore. Good luck!

Carsten_Kulms

I don't know neither with which version you made your oberservation nor at which place in the code, however, (afaik) this should work for NodeAction the same as for RequestHandler.

It is right that the values in the list come in as strings. The conversion happens when WebNodeAction.Execute calls _ValidateRequest with the action's prototype what in turn calls $WebDSP.PrototypePkg.CheckArgs what does the all checking and conversions specified by the prototype. (As I see this was unified in 2010 in the sense that both NodeAction and RequestHandler use the same implementation but basically the processing of the parameters have been the same before.)

Did you overwrite the WebNodeAction's Execute function (instead of _SubclassExecute)?

Carsten_Kulms

I would recommend to leverage the prototype functionality. It provides several useful checks (cf. description in WEBDSP::WebDspRoot.PrototypePkg) - you do not need to re-invent the wheel, imho.

Christopher_Meyer

Hi Carsten,

I would recommend to leverage the prototype functionality. It provides several useful checks (cf. description in WEBDSP::WebDspRoot.PrototypePkg) - you do not need to re-invent the wheel, imho.

I use the prototype functionality when a value must be valid for the request to continue. However, it's not very friendly when used to validate the input of a form. That is, an invalid value will display an error page and require use of the browser back button to recover. It's for these values that I do the validation outside of the prototype to prevent the error page and to allow the user to correct their invalid input. I've blogged about this topic if you're interested: Content Server Forms

HFCDev

If I'm not mistaken, I think I've seen two approaches in your code - Javascript validation on the page, and actually using the request handler, processing the request, then regenerating the page with the error message and an indication of what went wrong. The latter kind of mimics what you would do in Javascript generally for client side validation.

-Hugh

HFCDev

I was developing on CS 10.0 U 201503. I've since ported to CS 10.0 U201506, and I'm upgrading my code to 10.5 with each finalized version.

And no, I didn't override Execute, only _SubclassExecute(). I will dive into the WebDSP function when I get a chance.

-Hugh

Christopher_Meyer

Hi Hugh,

If I'm not mistaken, I think I've seen two approaches in your code - Javascript validation on the page, and actually using the request handler, processing the request, then regenerating the page with the error message and an indication of what went wrong. The latter kind of mimics what you would do in Javascript generally for client side validation.

Correct. But any client side validation only complements server side validation (and not the other way around). Server validation is crucial since unexpected or disastrous results can occur (e.g., SQL injection, stack traces, etc.) if the Javascript validations fails or the user gets around it by manipulating the URL directly.