So, in other words all options are optional, but the second level locations or sub categories are only allowed if their parent is also there, so the following would never be valid:
/jobs/kent/vb
What I am trying to do now is to find the nodes using XSLT, but of course the node names are not the same as above, as they have been URL encoded.
E.g.
URL = south-east
nodeName = South East
So what is the most efficient XSLT way of searching for the south-east nodeID?
As promised in case someone else wants to do something similar, here is the XSLT code I used to find the area and counties.
To re-cap, I am using URL redirect to allow up to 4 parameters to be passed in a URL.
First pull the possible 4 variables from the query string:
[code]
[/code]
Now search for the Area, which could be in the 1st,2nd or 3rd position:
[code][/code]
And now a search for the Counties, which could be in the 2nd,3rd or 4th position:
[code]
[/code]
If anyone has a better solution / shorter solution feel free to chip in your suggestions, but for now, it's working :) The site re-design has to be finished and going live on Monday, so the heat is on to get the rest finished :)
The setSource wrote out the correct nodeId, but it wouldn't pass into the macro - this isn't quite as complex as your querystring but the principle is similar - if I could just wourk out how to get that *!@%! setSource to pass into the macro then there wouldn't actually need to be a querystring at all ( in my case)
Maybe somebody clever can tell me where I went wrong :)
How to find a node ID from a URL Encoded parameter?
Hi All,
I thought I would ask in the forum incase I am trying to re-invent the XSLT wheel and someone out there already knows the answer.
What I am trying to do is the following:
I have a page called: JOBS
And I am using URL Redirect which allows up to 4 parameters to be passed in the URL.
e.g. all the following should be valid URL's.
/jobs/
/jobs/south-east
/jobs/south-east/kent
/jobs/programming
/jobs/programming/vb
/jobs/south-east/programming
/jobs/south-east/programming/vb
/jobs/south-east/kent/programming
/jobs/south-east/kent/programming/vb
So, in other words all options are optional, but the second level locations or sub categories are only allowed if their parent is also there, so the following would never be valid:
/jobs/kent/vb
What I am trying to do now is to find the nodes using XSLT, but of course the node names are not the same as above, as they have been URL encoded.
E.g.
URL = south-east
nodeName = South East
So what is the most efficient XSLT way of searching for the south-east nodeID?
Thanks in advance for your help,
Chris
You could do a match on @urlName as opposed to @nodeName ?
Does that help you out Chris?
Warren :)
Hi Warren,
Your a life saver, I knew all I'd need was a gentle nudge :)
I'll post my final solution later :)
Thanks again,
Chris
Yeh be interesting to see how you solved this problem with your final XSLT.
Warren :)
As promised in case someone else wants to do something similar, here is the XSLT code I used to find the area and counties.
To re-cap, I am using URL redirect to allow up to 4 parameters to be passed in a URL.
First pull the possible 4 variables from the query string:
[code]
[/code]
Now search for the Area, which could be in the 1st,2nd or 3rd position:
[code][/code]
And now a search for the Counties, which could be in the 2nd,3rd or 4th position:
[code]
[/code]
If anyone has a better solution / shorter solution feel free to chip in your suggestions, but for now, it's working :) The site re-design has to be finished and going live on Monday, so the heat is on to get the rest finished :)
Thanks again Warren,
Chris
Hi Chris this was very helpful as I'm currently making a jobboard for surgical assistants in Australia (filter by state)
I originally tried doing it the other way, but got stuck trying to pass the nodeid into the macro - I put this directly in the template:
[code]
[/code]
And then tried to get:
[code]
<%=setSource%>
[/code]
The setSource wrote out the correct nodeId, but it wouldn't pass into the macro - this isn't quite as complex as your querystring but the principle is similar - if I could just wourk out how to get that *!@%! setSource to pass into the macro then there wouldn't actually need to be a querystring at all ( in my case)
Maybe somebody clever can tell me where I went wrong :)
is working on a reply...