datetime
datetime copied to clipboard
DeuxHuitHuit
Sorting is incorrect with multiple dates
I have 2 use cases:
The first one is where I want to sort the next-occuring event on my website. Let's say today is 02-09-2011. I have 2 re-occuring events with the following dates: A: 01-09-2011, 08-09-2011 and B: 05-09-2011, 12-09-2011.
I filter on later than {$today}, {$today}, so both events show up in my datasource. I order them on the date field. Now the expected result would be: B (05-09-2011) and then A (08-09-2011), since B would occur earlier than A, because 01-09-2011 has already passed.
instead the following happens: event A gets shown before event B, because it get's ordered on the first date (which has already passed and should no longer be accounted for in the equation).
The second use case is coherent on the first one: I want to show a single event which is the next occuring event. Expected would be that I can create a datasource with a limit of 1, and use the same filter and sorting as described above. But then event A would be shown, instead of event B.
I tried working around all this by using XSLT functions with sorting and translating, but this is a) getting quite complex b) still a bit flaky at it's best. And still I would have to create datasources that load more events than I want to use (use case 2).
Working on this at the minute for a client, should have a fix within the next hour or so hopefully.
edit, er, well the Issue as the title says, my use case is slightly different to the two provided above (but I think related). I have a datasource that basically shows the next 4 events (so filter on later than now and sorting ascending order). I have an entry that has 4 dates on it (one field, 4 dates). At the moment, only one Entry ID is returned, yet the SQL returns 4 rows.
I also have a similar problem where if Date A has passed, and the entry is being returned because Date B passed the filter, that there is no way in the XSLT to know to show Date B and not Date A
So that commit is Part One. The SQL now correctly returns one entry for the datasource.
The second part is pretty tricky as the appendFormattedElement function has no idea what context it's being used. Currently looking into ways where the $data passed to appendFormattedElement will only contain dates that match the filter.
I wasn't able to solve this with the extension and had to resort to XSLT. Interesting situation.
@brendo: What's the status of this issue? Did you find a working solution? Sorting of (multiple) date ranges is quite tricky …
I was able to fix the REGEX that caused the wrong entries (or rather, one entry being considered as 'x' entries), but I wasn't able to do anymore than that.
The problem is that the appendFormattedElement function has no idea why it has the data is has, it's just been told to output it. This caused an issue on a site I was working on where there was pagination involved. While the entry was selected correctly with pagination, the appendFormattedElement function returns all the attached dates.
What I had to do was use XSLT to work using the previous entry's date (or the next entry's date) to figure out what one of the 'dates' was the correct one in this context. It's a difficult one to solve and I'm not sure how we would to be honest.
There are situations where it would be desirable to return all the dates.
Is there a way to pass appendFormattedElement more information so it would be possible to add a special attribute to the matched dates? Like filter="matched".
Not currently.
It would be possible to add another (!) parameter to the function however that could hold $this->dsParamFILTERS[$field_id]. This would give later than today etc.
I don't think anything should be assumed from this though, a user should probably select a particular $mode before the extension just 'assumes' to only show related dates based from the filter.
I don't think anything should be assumed from this though, a user should probably selected a particular
$modebefore the extension just 'assumes' to only show related dates based from the filter.
My idea was not to hide any date but to add filter="matched" to those that match the given filter. This could be used in the XSL template without the need of any fancy comparisons.
The most interesting question though: are we able to find a working solution for this problem or should it be closed for now?
Right, sorry.
Not sure, you could definitely test if passing the filter makes this possible. My concern is the cost to performance, but that would depend on the implementation.
There's two ways it could be done:
- If we use the database and generate the filter again to get the exact date (most costly - perhaps? - but easiest)
- Do the filtering ourselves using PHP and for loops (no database queries, could be costly, more difficult)
I think this is perhaps one situation where it's worth a performance hit to be honest, the XSLT logic wasn't much fun.
@vlad-ghita Can you share how you worked around this by using custom filtering in the datasource?
@chadspencer Sorry mate. It's long back now. I'm not working Symphony anymore.
@chadspencer can you elaborate more on what you are trying to do ? Can you post the data source code and xml result please ?
A section’s entries with a date field that has multiple dates are not sorted properly in a data-source when output is sorted by this date field. I worked around this with an interim filtered node-set and xslt sorting.
a date field that has multiple dates are not sorted properly
Can you provide the example data-source output please ? I am curious to see what you are getting.
I just rechecked the gitter.im timeline and it looks like this ended in a d’oh-moment, meaning it was totally my fault … so I guess I cannot add something useful here. Not sure what the status of the original problem is, sorry.
@animaux LOL. But the thing I have been asking myself is this: how do you order entries that have multiple dates ? You need to choose a value to make it! I do not see how this can be done...
The thing I would do would be to add a dedicated date field, that contains only one date, and do the ordering on that one.
Normal sorting is a problem, yes. Might not be useful in any way.
However when grouping by this date field the current output is quite sensible: for each of the multiple dates there is a copy of the entry with it’s full content. The problem is inside this entry node there are ALL of the multiple dates. And there is no way of knowing which of the date is responsible for the current repetition.