Symphony.

For a current project I want to list all the events (for example concerts) that happen in a certain place.

The most simple way to display those events would be to order them chronologically, but I want to go a step further and “rank” the events following certain criteria, for example:

• How “new” is the event: events posted recently rank higher than those who are older.
• Where the event is held: some venues would give more points than others.
• How well the event is rated by the admins.
• etc.

I don’t really know how I could implement something like this, maybe some xslt wizardry that assigns a number to every entry or would a custom datasource be better? Could it even be the idea for an extension?

I hope the question is not to vague, if needed I can elaborate :-)

Thanks for the advice

This is where multiple sort fields might be appropriate.

I think this depends on the quantity of events. Will it be one single page, less than, say, a few hundred? If so, then getting all of them and filtering in XSLT would be fine. If it's more, and you need pagination, then you'll want to achieve this at the DS level (perhaps a custom data source).

If you do this with XSLT it would be relatively straight forward. You can copy your DS XML (a list of entries) into a variable, loop over them, and add an attribute or node to each one as a popularity score that you can later sort on. This score could be a simple index, say:

• award 10 - (days_ago), so posted today gets 10, posted yesterday gets 8, posted three days ago gets 6 and so on
• award venues a popularity score in Symphony (perhaps a select box, "Low", "Medium", "High") which adds, say, 1, 5 and 10 respectively
• admin rating work in the same way

If you want to do this natively in Symphony you could potentially do this using the reflection field — when an entry is saved, use its values to calculate a popularity score and then sort by this value in a data source. However because this value only gets updated when an entry is saved, you can't factor in date/time.

One option we went with a few years ago was to have a Number field (named "Popularity") in the entry and a cron job that ran overnight with a load of custom code that:

• selected one entry at a time
• worked out the popularity based on a whole load of factors
• resaved the entry with the new score

It was quite painful...

Nick gave me the same advice for a complicated 'similarities' datasource I did for someone recently. It worked on basically the same principals that you're looking at.

If it gets to the stage where you think you may need a custom datasource, give me a shout.

You could also use the reflection field for this, in combination with the resave entries extension.

The reflection field will update every time the entry is saved, so you will only have to resave them once.

edit: shit. Nick beat me to it with a better answer.

Thank you Nick, John and Huib for your thorough replies.

At the moment (and my skill level) I think that I will follow the XSLT approach, 100-150 entires should be sufficient for a “smart” homepage after which I could resolve with a traditional calendar.

I still have to figure out how to do the ordering at runtime but Nick’s concept is fairly clear: now I just need to do my homework.

Digging deeper, it would also be nice, also via XSLT, to shuffle the first, say, 5 events. This way I could promote different events. I could do this by adding a random number to the first five entries I think. Is it something crazy?

I’ll let you know as soon as I’ll figure everything out.

Thank you!

After some serious thinking and testing I think I will follow an hybrid approach:

• all the “static” ranking will be handled by a reflection field, this way I can still give some hierarchy in the calendar view;
• the “smart” ranking (which is static + date based) will be only available in the homepage and will be handled via XSLT.

As a technical note, I’m using EXSLT to retrieve the modified XML from the variable (via the node-set function as seen here) and for the date calculation. Is it the right approach?

Now, if only the reflection field would be available in symphony 2.3

If you log an issue with it, then it will act as a reminder to update it.

The unstable branch is compatible with Symphony 2.3.