Forums (Obsolete)

Portal Engine Questions on portal engine and web parts.

Version 6.x > Portal Engine > Passing webpart field into repeater transformation

View modes:

Member

Member

ECAbacus - 10/11/2012 12:26:31 PM

Passing webpart field into repeater transformation

The situation is this. I have a webpart that is a clone of the QueryRepeaterWithEffect. The webpart displays a list of urls with varying querystrings which are eventually used to filter a datasource. All of this works fine, with one snag. As the base url can vary based on the webpart's placement, I need to pass in an additional DocumentListUrl field that the repeater transformation can then prepend to the querystring. How would I modify the transformation to include a Field on the webpart?

Member

Member

davids-kentico - 10/12/2012 3:37:29 AM

RE:Passing webpart field into repeater transformation

Accessing a web part's properties within a transformation can be a lot of work. If I understand your problem correctly, I may have a simpler solution.

Basically, you want your transformation to create a link to the document that is currently using the transformation to display some data. So instead of using GetDocumentUrl() which would get the URL of the list item, you want to get the URL of the document where the list is displayed, right?

This should do it:

GetAbsoluteUrl(GetUrl(CMSContext.CurrentDocument.NodeAliasPath, CMSContext.CurrentDocument.DocumentUrlPath), CMSContext.CurrentSite.SiteID)

This returns the URL to the current document and, obviously, the value will be the same for all rendered items. You can append your changing query string to this.

Member

Member

ECAbacus - 10/12/2012 9:41:14 AM

RE:Passing webpart field into repeater transformation

Hmm... that only solves part of the problem. The control in question is a webpart that appears on the same page as a document repeater, which generates a url used to filter the repeater's data source. Your approach would certainly solve the problem on the page where the documents are listed, but once a use clicks through to view a single document the link would then apply the filter to the document url rather than the list url.

Member

Member

davids-kentico - 10/15/2012 4:48:53 AM

RE:Passing webpart field into repeater transformation

Hey,

While we can certainly write some code to access the web part's properties, I still think there may be a more elegant solution to your problem, in terms of both performance and maintainability.

Perhaps if you described the requirements that are behind this so that I could understand the problem better, we may be able to work something out. I still don't quite understand what the goal of your setup is. Could you clarify that? Screeshots could be helpful.

Please let me know what you think of this. Thanks.

Member

Member

ECAbacus - 10/15/2012 7:31:54 AM

RE:Passing webpart field into repeater transformation

Certainly. Let me clarify:

As mentioned, the control is a copy of the QueryRepeaterWithEffect. The control's purpose is to present a list of year/month/total entries for a particular document type based on their publish date, much like the Blog's Archive list. This is performed via a SQL query which runs a join and group by on the items stored in Kentico; pretty standard stuff, and this presents no problem.

The problem is that this list consists of urls which point to a page (i.e. "the newsroom") which contains a Data source tied to a repeater. So the control will generate a list of urls each pointing to "[mypage].aspx?range=06-2012", which then filter the data source based on the querystring. What I'm trying to determine is how to pass in [mypage] as a parameter of the control. This control will be placed in various locations and there are multiple document lists it must filter, so I can't just hard-code [mypage] into the transformation.

Suggestions?

Member

Member

davids-kentico - 10/15/2012 10:30:11 AM

RE:Passing webpart field into repeater transformation

Thanks for clarifying. It seems that adding a new property to the control is the right thing to do. However, I think it would be better to create the URL in the control's code by adding a column to the data set and then evaluating the column in the transformation. This should reduce the number of queries sent to the SQL server compared to retrieving the control's settings when rendering each item of the set.

I'll discuss this with a developer to verify it.

Top