sitecore8 - Master/Detail Dilema: Wildcard items vs Sitecore Pipeline for Virtual Items or any better idea? -

i used implement listing/detail scenarios using wildcard items, meaning that, sake of url, create regular item display list , under node, create wildcard item represent possible detail pages, like:

/news/*   

(i generate friendly name code replace wildcard , produce full url such as: mywebsite.com/news/the-meeting-press-release)

then create folder or bucket of content items somewhere else repository. assign same datasource listing node , wildcard node give them same repository of content items.

main reason want use datasources , make navigational nodes (which generate actual pages , urls) separate content folder structure. in other words, separation of concerns: navigational items presentation nodes , content items data repository.

this easy way work around master/detail requirements feel guilty this, feels technique breaks integrity (sitecore links table on database) , design pattern in sitecore back-end.

for example when @ analytics, * name of items, feels aliens back-end system.

i know not new topic. have seen threads this or ideas sitecore pipeline processor virtual items implement such requirements.

is there best practice this? have example of sitecore-friendly way implement such pipeline processor? how address issue wildcards on analytics?

i'm going go different way martin here. have used wildcards many times exact purpose suggesting (for example have @ http://www.atpworldtour.com/news - news articles items in bucket wildcard resolve url).

there 2 options enabling page editor.

1. the news article item becomes page. in way, need new processor in httprequestbegin pipeline resolves url item , sets sitecore.context.item current item. iirc setting 1 of pipeline argument properties. work fine in page editor context item - 1 being edited - news article. , other renderings on page can use data sources needed.

2. the news article resolves datasource. have tried method. this, need custom datasource resolver. sill used processor in httprequestbegin pipeline didn't have resolve url multiple times each rendering needed datasource. in renderrendering pipeline had processor detected if wanted wildcard datasource , used item had been resolved in httprequestbegin processor.

there pros & cons each method.

option 1 nice , simple. means could use single wildcard resolve different "types" of page item presentation on page item , not wildcard item, each item can have own custom presentation, datasources set in page editor unique article. disadvantage in someways. a/b testing becomes more difficult main article text etc... limited testing article versions.

option 2 more flexible in testing area - can test/personalize parts of article changing datasource. more limited presentation must set on wildcard. renderings not part of main article have same content/settings across all news articles.