Date/JDate

[achartier]

In Fabrik5 we are eliminating the jDate element in favor of a new Date element. We will update your element definitions when you install F5.

The old Date element was custom built and was showing its age. It relied heavily on Mootools and jQuery which we have removed from F5. Using an existing calendar widget significantly reduces the code requirements both at the server side as well as in the browser.

Our new Date element has considerable more configuration options. If you are interested in seeing how the new Date element will work head on over to the TerminusDominus site and check out the examples.

Note: We are not at this time looking at implementing any sort of date range options. If this is of interest to many we may consider it.

What this thread for more details.

 

[wezetel]

Will this new date element replace Jdate AND date elements?

Note: We are not at this time looking at implementing any sort of date range options.

Does this mean, there is no 'Allow Date Function' available (which I need)?

 

[achartier]

It will replace both, and yes, your allow date php and javascript functions will work as before.

 

[wezetel]

Great!

 

[achartier]

Question for you, do you use both PHP and JS allowed dates? I am trying to determine which should take preference? Should both functions (if configured) allow a date in order for it to show as selectable? Or is it enough that one of them allows the date?

 

[wezetel]

I'm just using the PHP version (just because I have a little better knowledge of PHP and included db queries for calculating allowed dates).

 

[achartier]

@wezetel As I am working through the logic of allowed dates a question comes up. If this is a new date and the default is set to today, what if today is not an allowed date? I wonder if we need an option in this case that forces us to choose the next earliest allowed date as the default. As an option the application builder can choose either.

Also, if this is an existing record, then I think I need to add the existing date to the allowed dates list, so that navigation will allow it to be re-selected should they select another date but then decide to go back to the original one.

 

[troester]

As it is now:
JS is only affecting the calendar widget selects, it's not "validation".
If it's defaulting to current, current is inserted (and stored), if type in field is enabled any other date can be typed and is stored.

 

[achartier]

Fair enough, but is that the way we want it? What is the point of having allowed dates if the user can simply ignore them and type in whatever they want. What if they type in gibberish, like xyz, what do we do with that?

 

[troester]

It's up to the admin to disable typing.
Having it enabled with "Allow dates" doesn't make sense (and typing gibberish is possible always if typing is enabled).
But it should be able to have a date which is not in "Allowed dates" (a default, something set by admins or php plugin, or via an other form with other access settings).
If the user changes it (if he is allowed to do so) and saves he can't go back to the "unallowed" date.

 

[wezetel]

It's up to the admin to disable typing.

This is key for allow date function. Probably worth to mention in the tooltip (and Wiki).

In regards of existing records: this always depends on the use case. Either the user is allowed (access level) to change the date and then needs to take one of the available dates, if he changes the value. Or he needs to make a new record.

Sometimes we need to trust in the admins, that they know what they are doing. Fabrik has a wide area of users (from beginners to experts) and using enhanced features needs some kind of deeper knowledge and understanding of their application logic. And not every use case can be forseen by the developers. And in those rare cases they can always ask in the forum