Hi!
We have an asset listing that provides 'news-feed' type functionality to a site. There are two sources for the news. One is a folder of standard pages. There is a metadata schema applied to these pages that includes a field called date. Sa far so good, we can sort these results by the metadata field, date.
However the feed is also reading from a DB Data Source, which is ok too, because the asset listing seems to automatically sort them how I expect 
The problem is that this is a single news feed, so I need to sort the results from both sources at once to show just the [n] most recent items from Matrix and from the external source. If it comes to it, then we may have to split the [n] feed into an [n], [m] feed so the two sources are listed seperately, but idealy this wont be necessary.
I gather record sets can't have metadata applied (I read this on the forums but decided to tinker anyway - I was rewarded for my efforts by a raw PHP parse error appearing in the backend!!!), otheriwse it would easy (obviously).
Any thoughts?
I'm not sure you can sort both sources at the same time, because the Data Source Record Set doesn't actually have any real attributes and you can't apply metadata to individual records. I'm not sure if anyone else have any other ideas.
Thanks for the quick reply, as ever Avi!
Occurs to me I didn't mention above that we do have %data_record_set_date% available, but it doesn't seem like the asset listing will recognise this as a 'useful' property.
Thanks.
Well, you would do your sorting within the DB Data Source's query anyway, so the asset listing wouldn't have to sort again. Its just trying to merge the results from the DB Data Source and the real assets where the sorting conundrum lies.
I don't think you can sort both at the same time. We'd need to extend sorting to allow it to use keywords, and then to merge two sort options together into one field.
[quote]I don't think you can sort both at the same time.[/quote]
OK no worries - we'll split the news feed up then. Thanks for your help, everyone.
[quote]We'd need to extend sorting to allow it to use keywords, and then to merge two sort options together into one field.[/quote]
Wouldn't it be easier to add metadata capabilities to data source record sets?
Data Source Record Sets represent temporary assets, so metadata cannot be stored against them. The attributes are already dynamic because of this, but metadata cannot work in the same way.
The use of keywords is a solution we use in a couple of places (dynamic root node in asset listing comes to mind) so it fits nicely with existing functionality.
Ah yes, of course.
[quote]Data Source Record Sets represent temporary assets, so metadata cannot be stored against them. The attributes are already dynamic because of this, but metadata cannot work in the same way.[/quote]
I was thinking though, that the only kind of metadata that would make sense on a dynamic asset like a record set would be something that is available as a keyword from the query. Presumably, you would set up the metadata values on the DB Data Source asset using the available keywords and these would magically appear on the shadow assets.
How about overiding the getMetadataFieldFunction for record sets with a function that performs a keyword replacement as defined on the data source? Then, instead of needing database records for dynamic assets (which obviously makes no sense) we in effect create 'pseudo metadata' from the query keywords. The advantage of this is that it enables the information returned from the query to be used for any of the metadata behaviours 'natively' as it were - things like sort positions in asset listings.
I'm not sure how this would integrate into the schema concept though. It would also probably trip up if there is a default value set via keyword (presumably shadow assets don't have properties like 'date created' available (although further thought suggests any values unavailable to the shadow asset would be inherited from the data source asset)). On reflection, unless the schema issue can be resolved (thereby solving the merging problem as well) enabling keywords is a much better solution - I see now.
I'm interested in your thoughts,
Thanks!
ps. We're going to split our news feed up into two parts now, so this is just an exercise in thinking rather than a help question. Maybe this should go to the developer's forum?
That is what the attributes do now. Having them as attributes instead of metadata forces us to load the asset and ask it for info. Metadata is often sourced from the system directly.
[quote]How about overiding the getMetadataFieldFunction for record sets with a function that performs a keyword replacement as defined on the data source? Then, instead of needing database records for dynamic assets (which obviously makes no sense) we in effect create 'pseudo metadata' from the query keywords. The advantage of this is that it enables the information returned from the query to be used for any of the metadata behaviours 'natively' as it were - things like sort positions in asset listings.[/quote]
My comment above is probably valid here as well. That method is not often used to source metadata. More commonly, values are grabbed from the metadata.php file on the file system as it has cached PHP code and values that allow for all sorts of complex keyword replacements. Without this file, metadata would not work for these shadow assets.
This is why attributes are used currently. The problem with attributes is that you cannot enter a free-text value for the attribute. Matrix tries to present you with an interface for selecting static attributes, not taking dynamic attributes into account. Keywords solve this problem because they are always dynamic and free-text.
[quote]That is what the attributes do now. Having them as attributes instead of metadata forces us to load the asset and ask it for info. Metadata is often sourced from the system directly.
My comment above is probably valid here as well. That method is not often used to source metadata. More commonly, values are grabbed from the metadata.php file on the file system as it has cached PHP code and values that allow for all sorts of complex keyword replacements. Without this file, metadata would not work for these shadow assets.
This is why attributes are used currently. The problem with attributes is that you cannot enter a free-text value for the attribute. Matrix tries to present you with an interface for selecting static attributes, not taking dynamic attributes into account. Keywords solve this problem because they are always dynamic and free-text.[/quote]
Yeah, I see what you mean.
Cheers for your time, Greg!
Not a problem. Thanks for taking the time to talk it through with me.