Writing s_src url parameter to different custom data elements depending on if value is a number. HELP!

Tanna Lewis

Question for the javascript/js-savvy users. 


Right now, we have a custom solution built into our BBCRM integration with LO which is grabbing data from custom data element fields on the donation forms and mapping them to various things in BBCRM, including appeal or mailing.  We're popping data into the appeal/mailing custom data element fields from the s_src url parameter.  We want to continue to use s_src for both appeals and specific mailings if possible to keep things simple for the staff creating the urls.  Mailings are identified by a 3-digit number, while appeals are longer strings combining numbers and text. Appeals are only used when there is no mailing, so the two would never need to be captured in tandem.


So my question is this:

Would there be some fairly simple js/jquery we could use to identify whether the s_src value in the url is a number, and then if so, have it write to a particular custom data element field, and if else, write to a different custom data field? 


So basically:

if [[S334:s_src]] = number, then ('crm_appeal_mailing_effort_id_input').value = '[[S334:s_src]]'

else ('crm_appeal_input').value = '[[S334:s_src]]' 


Any advice hugely appreciated!!!

Brian Mucha

Something like...

 

<script type="text/javascript">

var src  = "[[S334:s_src]]";

if(isNaN(src)){

    document.getElementById('crm_appeal_mailing_effort_id_input').value = src;

}else{

    document.getElementById('crm_appeal_input').value = src;

}

</script>

Mark Kindy

Tanna Lewis:


Would there be some fairly simple js/jquery we could use to identify whether the s_src value in the url is a number, and then if so, have it write to a particular custom data element field, and if else, write to a different custom data field?

I know you asked for JavaScript solutions, but if you can use and want a completely Luminate-driven solution, you can use the [[S130]] tag:

    <!-- If s_src contains non-numerical data, using it in a <, >,

         or == comparison will treat the parameter like a "0" -->

    [[?x1x::x[[E130:[[S334:s_src]] 0 >]]x::

        <!-- s_src is entirely numerical (s_src > 0) -->

        [MAILING CONTENT HERE]

    ::

        <!-- s_src contains non-numerical data (s_src == 0) -->

        [APPEALS CONTENT HERE]

    ]]

Also, as a possibly irrelevant aside, a URL parameter starting with "s_" gets set as a session variable and is accessible using [[S80]], e.g. [[S80:src]] for s_src. This also means that this value remains a part of the user's session until they log off -- so, if s_src at a later point is expected to be a different value but is not explicitly reset, it will still be whatever value it was when it was initially set. If the URL parameter does not start with "s_", this is not a problem. This may not be a problem anyway, since I'm unfamiliar with how you have your site/service set up.

Tanna Lewis

As always, THANK YOU Brian, works like a charm.

Tanna Lewis

Mark Kindy:

Tanna Lewis:


Would there be some fairly simple js/jquery we could use to identify whether the s_src value in the url is a number, and then if so, have it write to a particular custom data element field, and if else, write to a different custom data field?

I know you asked for JavaScript solutions, but if you can use and want a completely Luminate-driven solution, you can use the [[S130]] tag:

    <!-- If s_src contains non-numerical data, using it in a <, >,

         or == comparison will treat the parameter like a "0" -->

    [[?x1x::x[[E130:[[S334:s_src]] 0 >]]x::

        <!-- s_src is entirely numerical (s_src > 0) -->

        [MAILING CONTENT HERE]

    ::

        <!-- s_src contains non-numerical data (s_src == 0) -->

        [APPEALS CONTENT HERE]

    ]]

Also, as a possibly irrelevant aside, a URL parameter starting with "s_" gets set as a session variable and is accessible using [[S80]], e.g. [[S80:src]] for s_src. This also means that this value remains a part of the user's session until they log off -- so, if s_src at a later point is expected to be a different value but is not explicitly reset, it will still be whatever value it was when it was initially set. If the URL parameter does not start with "s_", this is not a problem. This may not be a problem anyway, since I'm unfamiliar with how you have your site/service set up.

 

Oh, sweet, thanks so much for the alternative!  And, yes, that is another reason we wanted to keep using s_src, so that we have the opportunity to tap into it as they move around the site - and thanks for the reminder on S80!