Multiple urls for a single page in cms / IContentFinder question
Hi,
Just wondering if the following scenario is possible:
Old legacy cms system:
/language/jobs/job-category.html /language/jobs/job-category/province.html (9x, one landing page for each of the 9 BE provinces)
Both are landing pages which use parameters (set in cms) to fetch data from database
And what I want in new system: (Pages will get a 301 from old to new url)
/language/jobs/job-category/ and /language/jobs/job-category/province/
But, as there always 9 provinces, I really don't want to create 9 additional cms pages for each new job category (I could, but it's not desirable as data originally comes from yet another system and gets sync'ed multiple times per day and doesn't have a 1-1 mapping)
And additionally, each of these landing pages will need to be available in 3 sites (always same content), so there's a need to have
with essentially the same data and layout (Apart from some logo's and other images and maybe some text)
Really nightmare-ish...
which makes me think I will need to keep job-category pages in a "Data" node so it will become available in all 3 sites and don't need those pages per site. But then I'd still need a url for each of these pages in each site!
Same goes for provinces.
So, my question is, in case I put all job categories and provinces in a Data node, create a single page in each of the site (/language/jobs), can I use the new IContentFinder in v6 so I can perform a lookup on category and province in case someone requests
/nl/language/jobs/category-1/province-1 or /nl/language/jobs/category-1/province-2 or /nl/language/jobs/category-2/province-1
Won't url rewriting and a macro on the /language/jobs/job-category page be your friendly solution? Data stored and sync'd in "data" nodes with appropriate properties set. Rewriting to change from querystring params (for the macro to fetch the correct info) and convert that into pretty urls on the websites of each domain? No extra content nodes to worry about in the content tree either.
Don't exactly understand... "and convert that into pretty urls on the websites of each domain? No extra content nodes to worry about in the content tree either."
Can you give an example? (Must be my weekend mood already kicking in...) And what data do you keep then in your content structure?
Maybe I haven't fully understood what you're trying to do but I might try something like this:
CONTENT
- domain1
- - language
- - - jobs (macro on this page)
- - other pages
- domain2
- - language
- - - jobs (macro on this page)
- - other pages
- domain3
- - language
- - - jobs (macro on this page)
- - other pages
- Common Data
- - jobs
- - - job1 (job title, details, langs, categories, etc)
- - - job1 (job title, details, langs, catetories, etc)
- - - jobN
That keeps your common data (the jobs that are synced with your other system) in one place. On the doctype for the jobs data you'd include which domains/languages/categories/etc are appropriate to each job. That way you only list each once in the data section but your macro can make the appropriate ones display wherever you want them in the site.
If you have a request to domain1/language/jobs/categoryA you would use URL rewriting to actually request domain1/language/jobs?category=A. Urlrewriting hides the real request, which is always to the appropriate site's jobs page. The macro on that page takes query string params for any fields to filter on and then selects and displays the appropriate items from the Common Data/jobs section of the content tree.
You could handle this in many other ways but I've found this to be quite clear for users and doesn't clutter the content tree.
Ok, we're on the same level now. You got it right (Altho there's some minor differences in how we need to handle the jobs in common data, but that's not the point here). I guess it's just a trade off now of whether to use url rewriting or IContentFinder, and I'm not sure/don't know what's best (So, have no list of (des)advantages of using IContentFinder in comparison with url rewriting). I sure don't want to be the hipster and use IContentFinder just because it was introduced in v6, but would love to see if and why I would use it in favor of url rewriting)
And yes, url rewriting IS an option here, I just didn't think of it (My original quest was a bit more complex, and have changed my mind multiple times, even when posting my own question)
Anyway, thanks for taking the time to provide feedback and answers!
No problem, Dirk. Also looking forward to Stephan's comments!
My approach is one I've used since v3 so it has the advantage of not being version-specific, which is a bonus. On the negative side, I hate urlrewriting and always forget it's there and wonder why my site behaves as it does. Doing it all in code in the site would be preferred. FWIW, if you do urlrewriting, use the one in IIS 7+ and not the one in umbraco, which is slow slow slow.
Sorry, bit late to comment... in your case I guess it's a one-liner rewriting rules to change jobs/category/province into jobs?x=category/province and then the jobs page can run any type of macro, parse x=category/province, and display what's required.
It can be done with IContentFinder... you have to check that the request begins with ".../jobs" then take the rest of it, create a route with it eg "/data/category/province" and lookup that route... but... looks more complicated to me than the simple rewriting rule.
This is a while down the line now, but I have a very similar situation with having common node that should have multiple URLs.
I'm just intrigued as to which route you went down in then end, and if there were any issues with either way it was done? I'm starting work on a fairly heavy use site so want to make sure I am retrieving content in the quickest way possible with as few db hits as possible.
I think I'd prefer the IContentFinder route, but as pointed out, it is more involved to set it up, and I wonder what the benefits are above URL Rewriting?
I view into your findings would be much appreciated.
Multiple urls for a single page in cms / IContentFinder question
Hi,
Just wondering if the following scenario is possible:
Old legacy cms system:
/language/jobs/job-category.html
/language/jobs/job-category/province.html (9x, one landing page for each of the 9 BE provinces)
Both are landing pages which use parameters (set in cms) to fetch data from database
And what I want in new system: (Pages will get a 301 from old to new url)
/language/jobs/job-category/ and
/language/jobs/job-category/province/
But, as there always 9 provinces, I really don't want to create 9 additional cms pages for each new job category (I could, but it's not desirable as data originally comes from yet another system and gets sync'ed multiple times per day and doesn't have a 1-1 mapping)
And additionally, each of these landing pages will need to be available in 3 sites (always same content), so there's a need to have
http://domain1.local/language/jobs/job-category/ and
http://domain2.local/language/jobs/job-category/
with essentially the same data and layout (Apart from some logo's and other images and maybe some text)
Really nightmare-ish...
which makes me think I will need to keep job-category pages in a "Data" node so it will become available in all 3 sites and don't need those pages per site. But then I'd still need a url for each of these pages in each site!
Same goes for provinces.
So, my question is, in case I put all job categories and provinces in a Data node, create a single page in each of the site (/language/jobs), can I use the new IContentFinder in v6 so I can perform a lookup on category and province in case someone requests
/nl/language/jobs/category-1/province-1 or
/nl/language/jobs/category-1/province-2 or
/nl/language/jobs/category-2/province-1
Does that make sense?
Cheers,
/Dirk
Won't url rewriting and a macro on the /language/jobs/job-category page be your friendly solution? Data stored and sync'd in "data" nodes with appropriate properties set. Rewriting to change from querystring params (for the macro to fetch the correct info) and convert that into pretty urls on the websites of each domain? No extra content nodes to worry about in the content tree either.
Or am I missing something?
cheers,
doug.
Doug,
Don't exactly understand... "and convert that into pretty urls on the websites of each domain? No extra content nodes to worry about in the content tree either."
Can you give an example? (Must be my weekend mood already kicking in...) And what data do you keep then in your content structure?
/Dirk
Maybe I haven't fully understood what you're trying to do but I might try something like this:
That keeps your common data (the jobs that are synced with your other system) in one place. On the doctype for the jobs data you'd include which domains/languages/categories/etc are appropriate to each job. That way you only list each once in the data section but your macro can make the appropriate ones display wherever you want them in the site.
If you have a request to domain1/language/jobs/categoryA you would use URL rewriting to actually request domain1/language/jobs?category=A. Urlrewriting hides the real request, which is always to the appropriate site's jobs page. The macro on that page takes query string params for any fields to filter on and then selects and displays the appropriate items from the Common Data/jobs section of the content tree.
You could handle this in many other ways but I've found this to be quite clear for users and doesn't clutter the content tree.
cheers,
doug.
Doug,
Ok, we're on the same level now. You got it right (Altho there's some minor differences in how we need to handle the jobs in common data, but that's not the point here). I guess it's just a trade off now of whether to use url rewriting or IContentFinder, and I'm not sure/don't know what's best (So, have no list of (des)advantages of using IContentFinder in comparison with url rewriting). I sure don't want to be the hipster and use IContentFinder just because it was introduced in v6, but would love to see if and why I would use it in favor of url rewriting)
And yes, url rewriting IS an option here, I just didn't think of it (My original quest was a bit more complex, and have changed my mind multiple times, even when posting my own question)
Anyway, thanks for taking the time to provide feedback and answers!
Really hope Stephan can shed some light on it
/Dirk
No problem, Dirk. Also looking forward to Stephan's comments!
My approach is one I've used since v3 so it has the advantage of not being version-specific, which is a bonus. On the negative side, I hate urlrewriting and always forget it's there and wonder why my site behaves as it does. Doing it all in code in the site would be preferred. FWIW, if you do urlrewriting, use the one in IIS 7+ and not the one in umbraco, which is slow slow slow.
cheers,
doug.
Sorry, bit late to comment... in your case I guess it's a one-liner rewriting rules to change jobs/category/province into jobs?x=category/province and then the jobs page can run any type of macro, parse x=category/province, and display what's required.
It can be done with IContentFinder... you have to check that the request begins with ".../jobs" then take the rest of it, create a route with it eg "/data/category/province" and lookup that route... but... looks more complicated to me than the simple rewriting rule.
Stephan
This is a while down the line now, but I have a very similar situation with having common node that should have multiple URLs.
I'm just intrigued as to which route you went down in then end, and if there were any issues with either way it was done? I'm starting work on a fairly heavy use site so want to make sure I am retrieving content in the quickest way possible with as few db hits as possible.
I think I'd prefer the IContentFinder route, but as pointed out, it is more involved to set it up, and I wonder what the benefits are above URL Rewriting?
I view into your findings would be much appreciated.
Mark
is working on a reply...