Drag & Drop

[achartier]

Drag and Drop is relatively easy, however, to implement it we must give up the current behavior of opening the view with a single click. I can change the existing behavior to always open on a double click, or only open on a double click when drag & drop is enabled.

Any thoughts?

 

[achartier]

There also needs to be some place to validate whether the drag & drop is valid. There is an eventDrop callback that is called when the drop occurs. This callback has all the information about the move so it would be possible to have a JS function that validated the move.

Is it enough to provide a filelist type of a field that can select a specific JS file (provided by the admin) to handle this? Return true if all is OK or false if not. If false the move is reverted.

This seems the easiest to me.

There is also an eventResize event if events can be resized either forward or backward. Again, this would allow the callback to allow or disallow the resize.

Again, a filelist to choose a JS file?

Any thoughts?

 

[troester]

Some thoughts/questions:

There are a lot of changes (options, behaviour) so I would prefer to have it as a new plugin (not replacing the old one), especially with regard to docu (WIKI, tooltips) and support.

I don't understand the JS selection. Selecting some script which the admin has to provide?
Drag/resize triggers the change of start/end date in the DB?
So it has to take care of validations on element and form level (or mustn't be enabled if there are complex ones)?

 

[achartier]

We can rename the various wiki entries to legacy fullcalendar and create new ones for the new plugin. It is unlikely anyone is going to try and run both versions at the same time.

My point about the validation is that FC does not itself do any validation on the change, it simply moves the in memory copy of the event. It is up to our plugin to handle recording the change in the database. That part is not difficult.

The more difficult part is doing the validations. We can leave these up to the user (i.e. the Fabrik admin responsible for the FC setup) by providing a means to add a JS file that runs on the drop. Or, we can force a form submit action on the record which would run through all of the various form/element validations. This one is far more complex.

 

[troester]

It is unlikely anyone is going to try and run both versions at the same time.

Only if you have the possibility to exclude drag/resize per visualization.

Drag/resize is great on simple lists/forms but may become horrible if you have to replicate complex validation (which are very likely in case of booking stuff like checking for overlays, blocking times, available resources etc).
And you have to run the server site validations anyway, pure JS is never a security means.

 

[achartier]

D&D is configurable per visualization table. So a FC Viz instance may have multiple tables associated with it that get displayed on the Calendar. Each table can have its own set of D&D settings.

Yes, some D&D validations may become extremely complex. This is why I think we leave it to the developer to implement the validation code. It could also be a PHP file that gets called via Ajax to do the validations. This would be more secure than doing it in JS. I can also implement both options, JS only, PHP only, or both with an indication of which should run first. In fact, thinking about ti now, perhaps the PHP option is best. In that way the developer can implement their own logic for validation as well as updating the database.

I could create a sample PHP script that the developer could then modify, much like the user_ajax.php script.

 

[achartier]

With drag & drop there are only 2 things that can possibly change; the Start & End dates.

I think it may be possible, in the PHP script, to load the full event row, adjust the dates, and then push it through the form for validation.

Also, if the date elements have javascript validations, or call any allow-date JS or PHP code, this can be done immediately on drop and an alert can happen immediately.

DnD may not be for everyone if they indeed have very complex validations and such, but ti may be useful to many as well in its limited form.

 

[troester]

DnD may not be for everyone if they indeed have very complex validations

Yup. That why I said it needs a per visualization option. You may want to use both with multiple visualizations.

BTW:
Any chance to get "allow-date JS or PHP code" into jdate? I have sites sticking with old date because of this feature (resp. I had sites... I'm going to retier definitively, it's no longer my sites...)

 

[achartier]

Will have a look.

 

[achartier]

The native J! datepicker does not provide an option to set allowed/disallowed dates. However, we can always create a new datepicker using a much newer library. Most of the infrastructure already exists so implementing another should be relatively easy (I say that now...). If we do this then the restriction of different date plugins on the same page will mostly go away.

 

[achartier]

OK, so my current thinking is this: I will add a DnD option for validation of the event. The only real validation that can happen is on the start and end dates, so for each, there will be 4 options, [Do Nothing, JS Validation, PHP Validation, Both]. The "Do Nothing" option is to allow validation on only one of the date elements. NOTE: This will only work for the older Date element, JDate (native J! datepicker) does not support allowed/disallowed as mentioned above.

The JS Validation would run the Date element's Allow Date Function. The PHP Validation would run the element's PHP Allow Date Function. If either of those returns "not allowed" then the move would be declined.

In addition, I would add a file selection option for a specific JS and/or PHP file that can be run. This would allow someone to create much more complex validations should the above not be sufficient.