Rebuilding InputfieldRecurringDates

[elabx]

Hi! 

I am trying to build a new version (open source) of the recurring dates module released a few years ago. And I've found myself with a couple doubts.

I am building it as a single value Fieldtype module where I want to save the rrule string (to render the UI) but I want to save the actual occurrences of the rule in a second table, so I can use mysql to query the actual dates.  Does this make sense? Is there another field around that uses a secondary table to save data? If this is sensible, where should I do it?? sleepValue()? savePageField()?

@adrian I think I saw you suffering with the bugs a lot around the support thread haha, so any input on how you would approach the development/refactors of this would be appreciated.

Right now on the "big picture" I want to use Alpine.js to redo de Inputfield and looking for advice here on how to do the actual Fieldtype. Also it's the plan to completely rely on rlavin/php-rrule .

And this module will only involve the fieldtype/inputfield not the whole rendering modules that came along the original one. 

[Robin S]

Thanks for tackling this project!

If the rrule for an event doesn't need to be searchable via $pages->find() then you could store it in $page->meta() and use the standard field table for the event occurrences.

And if there really was a strong need to find event pages by rrule then you could add a custom search method that queries the pages_meta table.

[elabx]

5 hours ago, Robin S said:

If the rrule for an event doesn't need to be searchable via $pages->find() then you could store it in $page->meta() and use the standard field table for the event occurrences.

Great idea! I always wondered how the meta() feature could useful haha. 

[adrian]

I think I am scarred for life from my time battling that module.

Thank you for taking this on - it will be a very welcome addition. 

A few initial thoughts:

1. rlavin/php-rrule is very useful - I ended up using it to parse some info from the output of that module
2. If you make use of momentjs, please ensure you use the version with timezone support - the lack of this was a huge part of the issues I was having and the module relied on an old version which made upgrading and switching to the timezone version quite difficult
3. Please follow the rrule spec properly - the way it was implement did not follow the standard (I don't recall the exact problem, but a read through my comments should help you find it) so it resulted in errors when using php-rrule and other means of parsing it.
4. Really focus on getting the API methods for querying events by date working properly and performantly - it was a nightmare in the other module.

PS - I know I am coming across harshly regarding the old module. I don't want to sound unappreciative of the work that was put into it because recurring dates really are a difficult thing to do well and I have produced my own fair share of poor stuff and I am not saying I could have done any better.

Best of luck with it and let me know if you have any other questions. 

[elabx]

3 hours ago, adrian said:

I think I am scarred for life from my time battling that module.

Mine's still open and bleed once in a while with support emails lol  so that's why I've decided to tackle this once and for all. 

3 hours ago, adrian said:

If you make use of momentjs, please ensure you use the version with timezone support - the lack of this was a huge part of the issues I was having and the module relied on an old version which made upgrading and switching to the timezone version quite difficult

I have a vague memory of this but don't clearly remember why momentjs was introduced. I'll just start without it?

3 hours ago, adrian said:

Really focus on getting the API methods for querying events by date working properly and performantly - it was a nightmare in the other module.

x10000000 I understand the issue well here. My guess if that it should work just as a FieldtypeMulti? 

3 hours ago, adrian said:

PS - I know I am coming across harshly regarding the old module. I don't want to sound unappreciative of the work that was put into it because recurring dates really are a difficult thing to do well and I have produced my own fair share of poor stuff and I am not saying I could have done any better.

If anything I appreciate your time to answer my questions! I am a bit nervous cause I know it's no easy feat, but excited to try to bring this to a more stable status. 

I will try to reuse most of the UI design wise at least to start with something, I think that part could be salvaged and is already a great deal of work? I'm sure it might have some areas improvement but I have used it successfully with a lot of people (when it works :D) that's why I feel it's really worth saving.

[adrian]

8 hours ago, elabx said:

I will try to reuse most of the UI design wise at least to start with something, I think that part could be salvaged and is already a great deal of work? I'm sure it might have some areas improvement but I have used it successfully with a lot of people (when it works :D) that's why I feel it's really worth saving.

Agreed - I found that interface quite effective as well.

[bernhard]

On 11/8/2021 at 4:04 AM, adrian said:

If you make use of momentjs, please ensure you use the version with timezone support - the lack of this was a huge part of the issues I was having and the module relied on an old version which made upgrading and switching to the timezone version quite difficult

I don't know much about datetime libraries, just know that tabulator.info recently replaced momentjs by luxon.

http://tabulator.info/docs/5.0/release#dependencies
https://github.com/you-dont-need/You-Dont-Need-Momentjs
https://www.htmlgoodies.com/javascript/luxon-vs-moment-javascript/

Good luck with your new challenge ??

[kongondo]

I like date-fns.

[benbyf]

Hows this going? Not sure I need it 100% but i'm making a booking system and I mostly need a front week view for the data, its a pain, and I'm not sure whether php or js or a bit of both is the right way forward really.

[elabx]

@benbyf still in very early progress and I don't see how it would help with the front week view. The original module did have some rendering modules attached but those are the last priority in this refactor. 

[benbyf]

1 hour ago, elabx said:

@benbyf still in very early progress and I don't see how it would help with the front week view. The original module did have some rendering modules attached but those are the last priority in this refactor. 

Fair, will feedback with anything useful–will probably end up being some php and vanilla js to support booking on the front end... but still.

[Pixrael]

https://ui.toast.com/tui-calendar

[elabx]

Hey crew, this is in pre-elease by the way: