the ultimate datapicker does not create two-way relations... But, you can use the relation api to create bidirectional relations between articles and products.
If you need to find all articles related to a product, you'll have to iterate your articles to find related products.
Assuming your articles is below a node called Articles, and your Product is below a node called products, that both these nodes are below a root node called Frontpage, and that the propertyname used for the ultimate picker is on the article node is called products you could do it with the following xslt:
I think that the linq2umbraco, enables working in an environment more familiar to asp.net developers, but I actually really like xml/xslt/xpath and the way it works in Umbraco. Using this approach I can handle datastore connection, data querying and output formatting in a single file and to me it doesn't even look like spaghetti code. Add to that blisteringly fast response times thanks to the built in Umbraco response caching, which I typically don't even need to configure myself, and I'm a happy camper :)
I've never been a big fan of asp.net data controls like datagrid, listview and the repeater, to me they often feel clunky and I've had many fights with them to get them output the xhtml I want, and I think that even though linq2umbraco maybe offers a more understandable way of querying the datastore, I'll probably keep using xslt for straightforward listing of things from the datastore like this example.
i guess that is mainly matter of personal preferences. i think that the main advantage of linq2umbraco is the stronglly type and the Object oriented approach: Product.RelatedContent.Articles.GetList() or somthing like that.
i like the xslt way and the performence, but i assume just because in my last job we worked with xslt.. i think maybe there are developers that find the xsl templating system different from other cms's, and maybe they think twice before they choose umbraco. so anyway, the fact that umbraco developer can choose between xsl or .net is just an advantage.
related content - bi-directional
hello,
i read: this post about the ultimate-data-picker and how to use it to relate content. i wonder about bi-directional relation:
for example, i have products and articles. i create new article and relate some products to it. so, in my article i can which products is related.
but - in my product page i want to see all the articles that related to this specific product (without creating new relations).
is it possible? how can i do that?
thanks!
the ultimate datapicker does not create two-way relations... But, you can use the relation api to create bidirectional relations between articles and products.
If you need to find all articles related to a product, you'll have to iterate your articles to find related products.
Hope this helps.
Regards,
/Dirk
Assuming your articles is below a node called Articles, and your Product is below a node called products, that both these nodes are below a root node called Frontpage, and that the propertyname used for the ultimate picker is on the article node is called products you could do it with the following xslt:
<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE xsl:stylesheet [ <!ENTITY nbsp " "> ]> <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:msxml="urn:schemas-microsoft-com:xslt" xmlns:umbraco.library="urn:umbraco.library" xmlns:Exslt.ExsltCommon="urn:Exslt.ExsltCommon" xmlns:Exslt.ExsltDatesAndTimes="urn:Exslt.ExsltDatesAndTimes" xmlns:Exslt.ExsltMath="urn:Exslt.ExsltMath" xmlns:Exslt.ExsltRegularExpressions="urn:Exslt.ExsltRegularExpressions" xmlns:Exslt.ExsltStrings="urn:Exslt.ExsltStrings" xmlns:Exslt.ExsltSets="urn:Exslt.ExsltSets" exclude-result-prefixes="msxml umbraco.library Exslt.ExsltCommon Exslt.ExsltDatesAndTimes Exslt.ExsltMath Exslt.ExsltRegularExpressions Exslt.ExsltStrings Exslt.ExsltSets "> <xsl:output method="xml" omit-xml-declaration="yes"/> <xsl:param name="currentPage"/> <xsl:variable name="articlesNode" select="$currentPage/ancestor::node[@nodeName = 'Frontpage']/node[@nodeName = 'Articles']" /> <xsl:template match="/"> <ul id="productLinks"> <xsl:apply-templates select="$articlesNode/node[contains(concat(',', ./data[@alias='products']), ./@id)]" /> </ul> </xsl:template> <xsl:template match="node"> <li> <a href="{umbraco.library:NiceUrl(./@id)}"> <xsl:value-of select="./@nodeName" /> </a> </li> </xsl:template> </xsl:stylesheet>Regards
Jesper Hauge
by the way, do you think (like i do) that this kind of tasks will be more easy to implement using the new linq to umbraco features?..
Hi Eran
Actually - no.
I think that the linq2umbraco, enables working in an environment more familiar to asp.net developers, but I actually really like xml/xslt/xpath and the way it works in Umbraco. Using this approach I can handle datastore connection, data querying and output formatting in a single file and to me it doesn't even look like spaghetti code. Add to that blisteringly fast response times thanks to the built in Umbraco response caching, which I typically don't even need to configure myself, and I'm a happy camper :)
I've never been a big fan of asp.net data controls like datagrid, listview and the repeater, to me they often feel clunky and I've had many fights with them to get them output the xhtml I want, and I think that even though linq2umbraco maybe offers a more understandable way of querying the datastore, I'll probably keep using xslt for straightforward listing of things from the datastore like this example.
Regards
Jesper Hauge
i guess that is mainly matter of personal preferences. i think that the main advantage of linq2umbraco is the stronglly type and the Object oriented approach: Product.RelatedContent.Articles.GetList() or somthing like that.
i like the xslt way and the performence, but i assume just because in my last job we worked with xslt.. i think maybe there are developers that find the xsl templating system different from other cms's, and maybe they think twice before they choose umbraco. so anyway, the fact that umbraco developer can choose between xsl or .net is just an advantage.
thanks.
Eran.
is working on a reply...