Dynamically reference custom TeamRaiser pages by name using S-Tags

Mark Kindy

I'm looking for a way to -- if at all possible -- acquire a custom page's SID number using S-Tags and the page's name.



To elaborate:  Let's say I have two pages in two TeamRaisers, both titled "My Test Page", but the "sid" variable in the URL of one is "13000" and the other is "13001".  I feel like it's possible that [[S47]] is designed for this task, but I'm unsure.  It seems like constructing this dynamic URL to point to the given page would go something like:



<a href="TR?fr_id=[[S42:0:fr-id]]&pg=informational&sid=[[S47:0:fr_informational:<?|ID>:My Test Page]]>My Link</a>



Since [[S47]] pulls information from various TeamRaiser custom components (e.g., fr_info is a reference to pg=entry), this seems like the most probable way, but the <?|ID> reflects that I don't know what would go there or after -- since, when referencing a TeamRaiser page like fr_info, that field is a number that references a variable's location in the XML file.  But, in my example, I presuppose that I can tell it to look for a variable such as "ID" to pull it from the reference "My Test Page" associated with the given fr_id.



Anyone have any thoughts?

Jon Reich

Hi Mark, 



I can't speak to S47 in this regard, but what we do (and this only works if you can plan ahead far enough) is create "dummy" custom TR pages in an initial build. That way.. when the TR is copied (or child created if it's a blueprint), those dummy custom pages copy over and they will have the SAME sid number in each TR. This helps things work across a shared wrapper for example. Then all you need to do is call the fr_id number.. since you know the sid number is the same and can be hard-coded into the nav or link. 



I know this doesn't answer your question, but wanted to share in case you weren't aware of it. I'm also interested to hear if anyone else has any thoughts on another solution, especially for TRs that already exist that don't share the sid nubmers.



Thanks, 



- Jon



--

Jon Reich * Partner * Cathexis Partners * jon@cathexispartners.com * p.605.377.8147

Brian Mucha

We use session variables for this.



In the event pagewrapper we set the sid for our key pages like this:



    [[U0:learnId=1005]]

    [[U0:contactId=1003]]



Then in the Teamraiser and the wrapper, we consume them like this:



<a href="TR/Events/TeamRaiser?fr_id=[[S80:frId]]&amp;pg=informational&amp;sid=[[S80:contactId]]">Contact Us</a>



EDIT:



S47 allows you to pull values that are set on TR pages. So you could get the Event Coordinator Name from the field on the Greeting page.

Mark Kindy

Jon Reich:

Hi Mark, 



I can't speak to S47 in this regard...

Thanks, Jon!  This is usually what we do, there just happened to be an erroneous case and I was hoping to find a workaround utilizing the tools at hand.  It's actually not too difficult to create a new TeamRaiser page with a given SID/SOID -- it's just a pain to have to create so many!  I don't think I've seen that mentioned here before though, so I'll post another thread with it as a tip, but when creating a Custom Page in a TeamRaiser, the "soid" URL variable will be set to 0, telling the editor to assign the new page the next available ID number when you click save -- BUT, if you change that "0" in the URL to any other number (except for one corresponding to an existing page on that TeamRaiser), then press Enter to reload the page with the new URL variable, once you save the page, it will use the ID number you assigned to it.

Mark Kindy

Brian Mucha:

We use session variables for this...

That's pretty clever -- I'll have to remember that!

Daniel Hartanto

Hi Mark,



In your specific case where a custom page is added later on post Blueprint initial push, or if someone just didn't start off with a Blueprint to begin with, but wanted to use the same "My Team Page" instance eventhough its off different SIDs.



You can probably tap into Angular JS mechanism -- almost similar but slightly different in purpose to what Brian has stated.



You can build up the object containing the pool of your FRIDs, and the associated SIDs  -- this is the only time where you have to manually prepopulate the presets (and it's centralized in the term of repository wise for ease of maintenance)



function myFRIDsTeamPgSIDController($scope){

    $scope.myfrids = [    

        {frid:'12345',sid:'13000'},

        {frid:'10840',sid:'13001'},

        {frid:'16590',sid:'13002'}    

    ];        

}



Now on your template, you could do this  -- supposed you want it to dynamically show the relevant link of that "My Team Page", you loop that, use ng-show to compare the value of the frid on that loop instance with the one listed on the URL (S334 is to grab value from URL parameter called "fr_id" or you can use S80:frid that Brian use, but normally if you are using within the Teamraiser pages, the FRID is parsed as URL parameter) 



<ul id="sidenav" ng-controller="myFRIDsTeamPgSIDController">

<li ng-repeat="x in myfrids" ng-show="x.frid == '[[S334:fr_id]]'"><a ng-href="../site/TR?pg=informational&fr_id={{x.frid}}&type=fr_informational&sid={{x.sid}}">My Team Page</a></li>

</ul>



Hope it helps,



p.s. but yup the ideal solution would always be to plan ahead and use Blueprint creating empty placeholder of custom pages even if at moment you might be sure you don't need it -- as Jon has stated, save hassle of having to patch it later on



regards,

Daniel

Brian Mucha

Using javascript would totally work as well. Not sure if one is better than the other.



JS would be client side, S-Tags are server side. So I suppose the JS has a better chance of breaking in an obscure or untested browser. Might be a tad slower too. OTOH, we already rely pretty heavily on JS. And there is a limit to how many S-Tags you can run at once - though we haven't hit it.



In my post I simplified what we actually do, which is something similar to Daniel's approach with a repository.



We put a reusable page in each teamraiser's wrapper. That reusable has a conditional to assign variables that change from instance to instance like this:



[[?[[S80:frId]]::1390::

    [[U0:learnId=2301]]

    [[U0:contactId=3581]]

::[[?[[S80:frId]]::1410::

    [[U0:learnId=3391]]

    [[U0:contactId=4585]]

::

...and so on...

]]]]



Later we found that there are several pages which user's can visit where [[S80:frid]] doesn't work, such as UserLogin or Tell-A-Friend. So we add a single session variable assignment right above the reusable in the pagewrapper and hard code it like this:



[[U0:myId=1410]]  (1410 is the teamraiser ID)

[[S51:reus_teamraiser_config_session_variables]]



And that means our conditional changes to this:



[[?[[S80:myId]]::1390::

    [[U0:learnId=2301]]

    [[U0:contactId=3581]]

::[[?[[S80:myId]]::1410::

    [[U0:learnId=3391]]

    [[U0:contactId=4585]]

::

...and so on...

]]]]

Daniel Hartanto

 

 BUT, if you change that "0" in the URL to any other number (except for one corresponding to an existing page on that TeamRaiser), then press Enter to reload the page with the new URL variable, once you save the page, it will use the ID number you assigned to it.

 

That's a nice finding -- I am learning from it now as well.



And you know (in case needed), you can automate bulk task of creating new custom page likely with this Firefox plugin called iMacros



https://addons.mozilla.org/en-us/firefox/addon/imacros-for-firefox/



Good thing about iMacros, besides its native IIM syntax -- you could create a Javascript based macros (yes, on the free edition plugin) and it could read .CSV and export back a .CSV which is handy.



Have the set of FRIDs that needed the add on custom page in a .csv  (you could probably retrieve it from the query/reporting) - or depending on how you structurally name your Teamraisers (if you create a standard / conventional naming so the names would be like a pattern) -- You could tap into iMacros to search and loop into the list of those teamraisers with that naming standard, extract the IDs that is otherwise listed within those table column into a CSV file; run the IMacros then to do the bulk task of creating the same "My Team" custom page.



Expanding the original idea (potentially crazy idea)

=====================================



You can actually half automate the creation of that JSON object for the Angular JS scope -- it should likely be feasible 



Once those custom pages are created we could probably loop back with iMacros, this time collecting the newly created SIDs, and built a second .CSV file.



When the .CSV is built -- you can use CSV to JSON converter and voila, that portion of the $scope is created.



regards,

Daniel



 

Daniel Hartanto

Brian Mucha:

Using javascript would totally work as well. Not sure if one is better than the other.



JS would be client side, S-Tags are server side. So I suppose the JS has a better chance of breaking in an obscure or untested browser. Might be a tad slower too. OTOH, we already rely pretty heavily on JS. And there is a limit to how many S-Tags you can run at once - though we haven't hit it.

...



In my post I simplified what we actually do, which is something similar to Daniel's approach with a repository.

...



Later we found that there are several pages which user's can visit where [[S80:frid]] doesn't work, such as UserLogin or Tell-A-Friend. So we add a single session variable assignment right above the reusable in the pagewrapper and hard code it like this:



...

 

Ditto on Brian's statement above. Although i am trying to remove the burdens of the server doing everything by passing it to our end client hehehe



And yes, the [[S80:trID]] I believe (of frid, isn't it what we thought Brian about that default S tag to retrieve it?), been experiencing moment of where it's returning "null" value for unknown reason, thus relying more on the S334:fr_id instead



@Brian -- I see now what you mean by the nested S-tag



regards,

Daniel

Mark Kindy

Daniel Hartanto:

And yes, the [[S80:trID]] I believe (of frid, isn't it what we thought Brian about that default S tag to retrieve it?), been experiencing moment of where it's returning "null" value for unknown reason, thus relying more on the S334:fr_id instead

I am loving these responses. Just wanted to point out though -- [[S334:fr_id]] works only if you're sure every URL on all your links on your site are well-formed to include the fr_id. A sure-fire way to always get the fr_id of the page you're currently on is [[S42:0:fr-id]].

Mark Kindy

Daniel Hartanto:

And you know (in case needed), you can automate bulk task of creating new custom page likely with this Firefox plugin called iMacros



https://addons.mozilla.org/en-us/firefox/addon/imacros-for-firefox/

I had heard of this ages ago, but it was a lot less powerful back then. Thanks for re-introducing me to it!