smd_calendar: complete schedule / event / calendar / diary

merz1 · 2009-02-24 10:32:52

Well it would make merz1 happy for sure :-p

Please take my excuses for rethinking your elegant concept in a more down to earth way :-)
(And you know that I always enjoy your specific solutions, comments and documentations with that certain twist of British extravaganza)

Simple question: What is the difference between the publishing date field and the use of a custom field or two to define start and end dates?

Btw (Don’t hit me! It’s called real life example.): An editorial TV-guide and all its possible functions, whistles and bells are the perfect ‘down to earth’ checklist items for such a nice flexible calendar plug-in. (Did I mention RSS-Feeds? Yes I did, I know… ;) Let’s call the plug-in ‘TV-Pattern’ :-)

Bloke · 2009-02-24 10:43:58

merz1 wrote:

What is the difference between the publishing date field and the use of a custom field or two to define start and end dates?

Only one difference as far as I can tell: the article publishing date and expiry are validated by TXP and are thus guaranteed to be error free. A custom field contents is freeform text and can therefore contain invalid dates.

What if you told the calendar plugin that custom3 contained the publishing date and in one article (event), someone wrote one of these in custom3:

nothing at all
36 Feb 2009
26 Feb 2009 41:00:00
gandalf

What should the plugin do with the event upon encountering such nonsense?

merz1 · 2009-02-24 11:50:00

Only one difference as far as I can tell: the article publishing date and expiry are validated by TXP and are thus guaranteed to be error free. A custom field contents is freeform text and can therefore contain invalid dates.

What if … What should the plugin do with the event upon encountering such nonsense?

Simple answer: Validation

There is no hook in TXP to validate a given date with the TXP core code against a set/overridden custom field type?
Doesn’t PHP offer a date validation?

Validation while entering event date: Well, a hook for validation through a plug-in is needed, isn’t it?
- Don’t trust the user if you expect correct date data in a text field.
When rendering event with wrong data: If error during validation don’t show event.
- Don’t trust the database if you expect correct date data in a text field.

Bloke · 2009-02-24 12:58:34

merz1 wrote:

There is no hook in TXP to validate a given date with the TXP core code against a set/overridden custom field type?

Nope. At least, not that I’m aware of. glz_custom_fields might do it, but we can’t rely on the plugin being present.

Doesn’t PHP offer a date validation?

Kind of, but it can’t correct bad dates.

This plugin is not ‘around’ on the admin side during article saving and — even if it was — how would I target the exact custom field used later by a client-side plugin? Using a date-picker (which is where progre55 is heading I think) is fine, but the user can still mangle the date before save if they wish.

Also note that by “mangle” I could mean a valid date that is actually ‘incorrect’ in terms of what the user intended. I’ve used a date picker before (say, in December), selected ‘January’ but it didn’t advance the year automatically so I chose the wrong year by mistake and never noticed.

Thus, we cannot trust user input; that’s totally cool and is standard programming practice. So we are only left with your 2nd item: Don’t trust the database. That’s easy too, but my question is: how should it do it? i.e. what action should be taken? What level of trust is acceptable? I can think of a few options:

ignore the event completely if the start/end date is empty OR mangled in any way OR the end date is after the start date
drop back to trying the ‘Posted’ or ‘Expires’ dates if one of the custom dates is empty or mangled, and then do a further test to make sure the end date is not after the start date (if it is, perhaps ignore the event?)
if the start date is after the end date, switch them over and try again
show an error/warning in the calendar so the event can be corrected
don’t bother validating anything in the plugin, and try to render the event as best as possible and whatever is shown on the screen is your fault if it’s wrong!

There are probably others. But which should I choose? How can I please as many people as possible? Can I offer a plugin option for the above methods, or are some of them not worth bothering with?

You and progre55 and all other potential users of the plugin are my ‘customers’ so please throw your input into this. Give some example uses where each (or any) of the above scenarios would make sense, or potential avenues for other methods of handling erroneous input, or which ones are worth considering.

Bear in mind that whatever action is taken must also be duplicated in smd_article_event because it must read the custom dates too and perform the same routine so it can render upcoming information correctly. Thus, what makes sense for the calendar must also make sense for smd_article_event.

Last edited by Bloke (2009-02-24 12:58:57)

progre55 · 2009-02-24 13:45:47

Gentlemen:

I did not realize that my question and request would spark such friendly banter and discussion. Bloke, you are absolutely correct regarding my direction and the date picker. I am actually testing a variety of things out, but this from an end user stand point is the way to go when inputting data. Another reason for the request regarding custom fields is the additional flexability that the custom fields provide that the posted /expirey date fields don’t and finally the dreaded time stamp which ideally would be optional when using the plug in :)

Regarding your above list:

ignore the event completely if the start/end date is empty OR mangled in any way OR the end date is after the start date I do not like this one because from my point of view the huge plus for this plug in is creating TXP applications that your end user can manage and if you do this one you will have questions from your end users of why is my event not showing up
drop back to trying the ‘Posted’ or ‘Expires’ dates if one of the custom dates is empty or mangled, and then do a further test to make sure the end date is not after the start date (if it is, perhaps ignore the event?) seems a little complicated and unnecessary
if the start date is after the end date, switch them over and try again would prefer the plug in not “guess”
show an error/warning in the calendar so the event can be corrected THIS WOULD BE MY VOTE – clean; simple; easy to understand for the end users who do some mangling :)
don’t bother validating anything in the plugin, and try to render the event as best as possible and whatever is shown on the screen is your fault if it’s wrong! now I know you just threw this one in to make five :)

progre55

Last edited by progre55 (2009-02-24 13:57:04)

Bloke · 2009-02-24 14:33:49

Right, so the votes are in from progre55 (thanks man). Who’s next?

For the record, I agree that option (1) might cause some confusion with things not appearing, and (3) is annoying so I’m glad it’s been rejected! I was only half serious about option (5). I could just do nothing and let it fall over like a giraffe with 3 legs. It’s certainly the easiest option from a coding perspective!

Options (2) and (4) are kind of mutually exclusive. I agree that (4) is probably the safest bet. I’ve had more time to think about it now and I’d like to be able to render the event with an “error” flag (and/or message) in the calendar itself but sadly I won’t know which cell it belongs in if the start date is mangled, so that’s not an option. So a horrible TXP-style error is the only reliable way to go. Does that change your opinion of this method?

My motivation for option (2) was out of convenience. If you had a load of events already set up and you got annoyed with the dates shifting every time DST changed, you might decide to bite the bagel and switch them over to use a custom field for start/end. Fine. You would have to first copy all the dates to the custom fields, then add the datefield to the smd_calendar and smd_article_event tags. If you missed a few or — during the time it took you to do the conversion — a new article was generated, or your users used the “old” method, you’d get errors showing up on the client side. And errors are ugly.

Also remember that when writing an article you may not bother to look at it rendered on the calendar because that would mean moving to the correct month first and checking it. If you trust the calendar plugin to do its job you might not bother looking at the event you just created (e.g. I don’t bother checking the plugins I export from ied_plugin_composer any more because I trust the plugin to do its job and render them correctly). Also, you may have decided to only render that type of event to the calendar under particular circumstances so you would never spot the error unless you filtered by a particular item, or a certain date arrived.

Anyway, having the “fallback” would mean you could add the datefield to your tags at any point, and everything would continue to work even if there were empty (or bogus) dates in your custom fields. Sure, it might cause confusion if you added 36-Feb-2009 (meaning 26-Feb-2009) and your event showed up in today’s cell (the Posted date of the 24th) instead of Thursday’s cell, but at least you wouldn’t show the world a TXP error.

So I don’t know. Maybe there should be an option to show errors or not so you can at least choose how to handle duff info. Still pondering on this one.

rsilletti · 2009-02-24 14:51:59

On the point of datefields in custom fields, I used such in a delete expired plugin I wrote before the expire mod was implemented, and the biggest complaint was the formatting of the date input to the custom field.
Granted my skills with php date handling was limited and still is, but there will always be a difference for users, date formats being the quagmire they often are, between entering numbers in a custom field, and times and dates in the article posting time boxes; the later has always shown more consistent results especially from the user that is inexperienced with date formats.
Restructuring two custom fields from text inputs to something less error prone might help that tendency, perhaps a JS date-picker – it worked well in zem_event.

Last edited by rsilletti (2009-02-24 14:56:35)

progre55 · 2009-02-24 15:09:03

Bloke:

With the updated information, I change my vote. :) I was actually fine with option 2 … but thought it would be less convenient for you ….

Regarding Rick’s comment and based on your comment, I implemented the date picker from here and it works like a charm. My next crack will be applying it to the publish/expire date fields ….

progre55

Bloke · 2009-02-24 15:48:19

rsilletti wrote:

the biggest complaint was the formatting of the date input to the custom field.

Yes, and you’re right that a date picker is a better way to go. I’ve not built one into the plugin because there are so many out there and jm’s plugin is very good at that kind of thing. It’ll be interesting to see how much progre55 can be made on this front ;-)

The upside to date formatting — and the secret weapon in all of this — is that PHP’s strtotime() function is wonderfully good at working out what you mean from a random series of characters that kind of look like a date/time (I bet it’s not efficient, but that’s another thing entirely). It figures out all manner of stuff and is the driving force behind the plugin; most importantly the stepfield. If it can’t figure something out it just goes “huh?” and I can detect its moment of confusion and take action; probably dropping back to the Posted date as a fallback and hoping it doesn’t completely bamboozle people who thought they were getting an event on a day other than the one actually rendered.

It’s going to be interesting. I’m sure some people will complain that the plugin should just balk (or be quiet) when things go wrong and others will put up with the oddness. Assuming it can be pulled off at all, that is.

Slightly OT: I’m never quite sure how much “help” to give in plugins. A classic example is in attributes: if you have a choice of section or category as options (with a default of ‘category’) and you mistype sectoin, most of my plugins will go “ermm, well that isn’t a valid choice so I’ll go back to the default and use the category”. Depending on your stance this could be good or bad; good in the sense the plugin will actually render something and not error out, but bad in that it doesn’t do what you expect until you notice your mistake.

From a usability perspective, classic thinking from minds immeasurably superior to mine state that code (and interfaces) should always do what you expect, thus my plugins are all “wrong” in this regard. But I’ve kind of dug a hole for myself in code terms so I’ll probably have to continue along this path for a while yet and ignore the jeering from the proper programmers out there :-)

merz1 · 2009-02-24 16:02:19

and #4 would be my choices., where #4 show an error/warning in the calendar so the event can be corrected is good for everybody and #1 could only be a safety fallback providing a ‘don’t break the rest’ feature.

Regarding ‘how to show an error’ in #4, nicely & long explained here by Stef, really leaves the option for #2.

I’m confused by #2 but that is better than showing a bad error page in a productive environment :)

Bloke · 2009-02-24 16:13:09

merz1 wrote:

could only be a safety fallback providing a ‘don’t break the rest’ feature.

Thinking aloud here, how about I just render an error anyway and it’s down to the Production Status whether it shows up or not? I think (will have to confirm) that even if I trigger_error() due to some mangled date that it will be silently swallowed when the site is Live. Thus it’s down to you if you fix them or not when developing.

That then just leaves the question of whether to fallback on the posted date or render nothing.

progre55 & Bloke say #2, merz1 prefers #1. I can see another attribute coming on…!

els · 2009-02-24 22:34:03

I am trying to have two calendars on one page, each one shows ‘events’ from a different category. I used the remap attribute for the second calendar, but it doesn’t want to use it… I can change the ‘m’ and ‘y’ to ‘mm’ and ‘yy’ manually in the URL, and then it works. But as soon as I use the calender navigation it goes back to ‘m’ and ‘y’.
Quite probably I am just misinterpreting the workings of the attributes (I’m also not sure about how to use maintain). These are my tags:

<txp:smd_calendar id="cozinha" maintain="calid,section" section="calendar" category="cozinha" expired="1" firstday="1" classlevels="cellplus" classprefixes="" eventwraptag="" form="calform" cellform="cellform" select="month" />

<txp:smd_calendar id="loja" maintain="calid,section" section="calendar" category="loja" remap="m:mm, y:yy" expired="1" firstday="1" classlevels="cellplus" classprefixes="" eventwraptag="" form="calform" cellform="cellform" select="month" />

Page is ~~here~~ (edit: removed link), any help is much appreciated, but there is no hurry at all (just testing) ;)

Last edited by els (2011-04-09 22:31:01)

Textpattern CMS

Textpattern CMS support forum

#169 2009-02-24 10:32:52

Re: smd_calendar: complete schedule / event / calendar / diary

#170 2009-02-24 10:43:58

Re: smd_calendar: complete schedule / event / calendar / diary

#171 2009-02-24 11:50:00

Re: smd_calendar: complete schedule / event / calendar / diary

#172 2009-02-24 12:58:34

Re: smd_calendar: complete schedule / event / calendar / diary

#173 2009-02-24 13:45:47

Re: smd_calendar: complete schedule / event / calendar / diary

#174 2009-02-24 14:33:49

Re: smd_calendar: complete schedule / event / calendar / diary

#175 2009-02-24 14:51:59

Re: smd_calendar: complete schedule / event / calendar / diary

#176 2009-02-24 15:09:03

Re: smd_calendar: complete schedule / event / calendar / diary

#177 2009-02-24 15:48:19

Re: smd_calendar: complete schedule / event / calendar / diary

#178 2009-02-24 16:02:19

Re: smd_calendar: complete schedule / event / calendar / diary

#179 2009-02-24 16:13:09

Re: smd_calendar: complete schedule / event / calendar / diary

#180 2009-02-24 22:34:03

Re: smd_calendar: complete schedule / event / calendar / diary

Board footer