Yet Another Tridion Blog

In a previous post I was talking about the  URL Syntax for OData Query Extension . In the current installment, I will present an enhancement to the URL  $filter  option parser that will allow us to use custom functions. These functions will give us even more possibilities to specify Criterias in RESTful URLs. The new version is available as JAR distributable ( odata-query-extension-1.2.jar ) and also as source code . One of the limitations in the previous OData Query Extension parser was the inability to specify the CustomMetaValue and CustomMetaKey criteria, as they pretty much need to appear nested in one-another: CustomMetaValue(CustomMetaKey(theKey), theValue[, operator]) Another tricky point are the criterias that accept several parameters, such as TaxonomyKeywordName(publicationId, taxonomyId, keywordName, includeBranches, operator) Therefore, I enhanced the parser logic to allow functions in the following syntax: function(parameter [, field_operator] [, paramete

In my previous article  Extending OData Query Functionality , I explained an extension mechanism for the Content Delivery Web Service with the goal of having more robust capabilities of querying for content than the out-of-the-box OData service offers. Please read that article first, in order to understand the context, goal and approach. This article follows up on the previous concepts and explains the URL syntax, grammar, and URL parameters accepted by the OData Query Extension. Link to source code and distributable JAR available ( odata-query-extension-1.1.jar ). Query Entity Collections QueryComponents Retrieves Component entities. The query API is applied to Components, only (item type = 16). /odata.svc/QueryComponents QueryComponentPresentations Retrieves  ComponentPresenation  entities. The query API is applied to Components, only (item type = 16), yet the results of the query are used to build Dynamic Component Presentations. /odata.svc/QueryComponentPres

Yes, OData is extensible... :) or I should rather call it the Content Delivery Web Service... In its current state, OData WS is pretty limited when it comes to querying for content. I have written the following article about it:  Tridion ODdata -- What's Possible and What Not? . The goal of my exercise is to enhance OData's search capabilities. The Content Delivery API provides the full functionality on querying for content. Hence, my plan is to extend OData with another collection QueryComponents (i.e. in fact with two more collections --  QueryComponentPresentations and QueryPages , but the query handling is identical to just querying for Components), to which I could pass a $filter parameter using the OData syntax, grammar and operators. The web service would parse the  $filter  parameter and construct a com.tridion.broker.querying.criteria.Criteria object from it. It would then execute the query and return Component entries using the OData response and all its for

This walkthrough describes an implementation of an SDL Tridion custom REL tag. The tag has been written in SDLTridion 2013, but it is also applicable to Tridion 2011. Tridion comes with a number of default REL tags, but you can also add your own custom tags. A REL tag can appear inside a Page or Component Presentation content, and it has to be published to the Content Delivery Database. These tags are executed on the Content Delivery side (presentation server) in one of the following situations: using the ComponentPresentationAssembler : when retrieving the content of a DCP; using the PageContentAssembler : when retrieving the content of a Page; using Content Delivery Web Service ( OData ) , when retrieving either a Page or a DCP; Prerequisites In my approach, I chose to use the Content Delivery Web Service (OData) approach. This means I had to install and configure an OData service. You can do so by following the installation guide from  SDL Live Content . I also need