Often when I need a list I tend to create 2 document types, a container (the page) and a data item, which can be added to the container in the content tree.
The container has a template with a macro containing the XSLT which generates the list and the item does not need an associated template as it will only be visible in the list. I noticed that in some cases I do need a reference to an item in the list, for example if there's a sitemap and the items need to be listed there as well.
To solve this issue I have created a quite generic template, which can be associated to the item and will redirect (javascript) the user to the item's parent (the list) providing the ID of the item node in the query string. That way I can handle selection of the item in the list's XSLT.
I was wondering if this is a good practice though, and if you know of a more solid/robust way of handling this, I would really like to hear so :-) I will also add some example code in case I was not clear, thanks!
Example: a simple FAQ. The page has a macro that generates a jquery driven accordion with questions/answers. The list item "Question" is a document type that can be added as a child of the FAQ page in the content tree.
I would use custom URL rewrite rules for the redirection to to the parent pages instead of a custom javascript. E.g. if your FAQ sits under /about/faq you can redirect everything that comes after /about/faq/* to /about/faq. You would have to add a rule for every such instance though.
With regards to the other point: I always find it quite natural in Umbraco to create a list based on a list of child nodes. However it might get a bit crowded in the sub trees, e.g. if you have a page that displays ten different lists with child nodes underneath. That's why I have created a while back a custom data type which is basically a grid and saves the data as Xml inside of the node, so e.g.
<list1> <item1> <text>some text some text</text> <link>http://somelink</link>; </item1> <item2> ... </list1>
In the custom control I can then add/delete/modify the items and also order them around (pretty much like the related links datatype). Have a look at this datatype by Marko: http://our.umbraco.org/projects/backoffice-extensions/dynamic-grid-data-type, I haven't used it yet myself but it should do pretty much of what I have described above.
I like the idea of using URL rewriting to handle the redirection. I can still pass the node name or relative path to the parent page, which kinda resembles the way return url's are often handled when a user is prompted to login (login.aspx?returnUrl=/secure/users).
Handling the selection in the list's XSLT will be a bit more difficult though, as I will need to find a child node given its URL name or alias while taking into account the URL encoding and other transformations (e.g. spaces that were replaced with underscores).
I am not yet familiar with the related links datatype, but I will surely have a closer look at the ones you mentioned. It definately sounds like a good way of handling items when the content tree gets crowded. I haven't really created any custom data types before, but I have customized the ultimate picker a few times to make it easier setting up 1-to-many relations in the content tree, and that worked out nicely, so I do see some possiblities there.
Parent redirect for items in a list
Hi guys,
Often when I need a list I tend to create 2 document types, a container (the page) and a data item, which can be added to the container in the content tree.
The container has a template with a macro containing the XSLT which generates the list and the item does not need an associated template as it will only be visible in the list. I noticed that in some cases I do need a reference to an item in the list, for example if there's a sitemap and the items need to be listed there as well.
To solve this issue I have created a quite generic template, which can be associated to the item and will redirect (javascript) the user to the item's parent (the list) providing the ID of the item node in the query string. That way I can handle selection of the item in the list's XSLT.
I was wondering if this is a good practice though, and if you know of a more solid/robust way of handling this, I would really like to hear so :-) I will also add some example code in case I was not clear, thanks!
Example: a simple FAQ. The page has a macro that generates a jquery driven accordion with questions/answers. The list item "Question" is a document type that can be added as a child of the FAQ page in the content tree.
QuestionAccordion.xslt:
Question template:
ParentRedirect.xslt:
If I now go to the URL of a question, I am redirected to the FAQ with the correct question expanded.
Hi Lennart,
I would use custom URL rewrite rules for the redirection to to the parent pages instead of a custom javascript. E.g. if your FAQ sits under /about/faq you can redirect everything that comes after /about/faq/* to /about/faq. You would have to add a rule for every such instance though.
With regards to the other point: I always find it quite natural in Umbraco to create a list based on a list of child nodes. However it might get a bit crowded in the sub trees, e.g. if you have a page that displays ten different lists with child nodes underneath. That's why I have created a while back a custom data type which is basically a grid and saves the data as Xml inside of the node, so e.g.
In the custom control I can then add/delete/modify the items and also order them around (pretty much like the related links datatype). Have a look at this datatype by Marko: http://our.umbraco.org/projects/backoffice-extensions/dynamic-grid-data-type, I haven't used it yet myself but it should do pretty much of what I have described above.
Sascha
Hi Sascha, thanks for your reply.
I like the idea of using URL rewriting to handle the redirection. I can still pass the node name or relative path to the parent page, which kinda resembles the way return url's are often handled when a user is prompted to login (login.aspx?returnUrl=/secure/users).
Handling the selection in the list's XSLT will be a bit more difficult though, as I will need to find a child node given its URL name or alias while taking into account the URL encoding and other transformations (e.g. spaces that were replaced with underscores).
I am not yet familiar with the related links datatype, but I will surely have a closer look at the ones you mentioned. It definately sounds like a good way of handling items when the content tree gets crowded. I haven't really created any custom data types before, but I have customized the ultimate picker a few times to make it easier setting up 1-to-many relations in the content tree, and that worked out nicely, so I do see some possiblities there.
Thanks!
Lennart
is working on a reply...