Question

Calendar widget on change behavior

0

Hello Mendix community: I am a new Mendix user but have been able to do quite a bit thus far that likely confirms the power of these tools. I am using the calendar widget (v1.12) and version 5.6 of the Modeler to show reservations on a number of pieces of equipment. Say a machine shop with a drill press, a hole punch, a band saw, a lathe and a milling machine. When a new reservation is created, I call a microflow to make sure that the the new reservation will not overlap any existing reservations on that same tool. If things are non-overlapping, the reservation is made. If there is an overlap, however the new reservation page stays open with the error message which allows the user to adjust the day or time to avoid overlap. This all works great and was quick and easy to do ... even for a neophyte. However, if I change either the starting time or the ending time of a reservation using drag and drop, the reservation entity that is sent to the on-change microflow is the entity that has already been changed (I think). If my microflow finds an overlap error, it reports it, but because the entity has already been changed it appears as if there is no way to roll back to the original, unchanged reservation. Am I missing something? Is there a way to save the state of the reservation before it was changed so that I can rollback to it in case the new reservation was found to be illegal for some reason? Thanks for your consideration, John p.s. It would also be a nice feature if the minimum reservation slot in the calendar widget was adjustable with a configuration parameter that could come from an Xpath property. In my above machine shop example, reservations of a drill press could be as short as 5 or 10 minutes, whereas for most people, a minimum useable time slot on a more complex machine such as a lathe or milling machine might be 30 or even 60 minutes.

asked 2014-07-27

John Shott

5 answers

Stephan Numan · Answer 1 · 2014-07-28

Hi John,

You could check by doing a database retrieve of the reservation entity with xpath constraint like [id = $Reservation/id]. before doing the commit. If both objects are the same the object was already changed in the database. (use the debugger to check all variables)

My guess is the object that the onChange microflow receives is the object which is changed but not yet committed. If there is a overlap you could try to call a rollback action for the reservation object.

The only way to do a manual "rollback" is to have some kind of audit trail on the reservation object.

John Shott · Answer 2 · 2014-07-28

Stephan:

Thanks for your input. Based on your suggestion, I'm trying to see if I can use the Community Commons menberHasChanged() or getOriginalValueAsString() Java methods as the first calls to my Calendar OnChange Microflow in hopes of being able to grab the origianl Start or End dates of a Calendar Event that is changing. However, I seem to be struggling with this because the member that I'm looking at is a DateTime rather than a string. Trying to use the toString to convert the member property using something like toString($Reservation/Start) doesn't seem to work. It almost seems as I need a getOriginalValueAsDateTime() method ... that doesn't exist.

But, I hope that this may be an approach to recover the original Start or End DateTime in the Calendar OnChange Microflow as a means of allowing me to recover after an "illegal" drag and drop of a Calendar event.

Thanks again,

John

John Shott · Answer 3 · 2014-07-30

Follow Up Note:

Use of the Community Commons getOriginalValueAsString() does indeed allow me to capture the original Start and End of a Calendar Event and can be effectively used in the "On Change" calendar microflow. If the newly changed time slot fails tests for suitability (for example, overlaps an existing calendar event if we don't allow overlaps) the original Start and End can be replaced to restore the original event prior to the change.

The original problems that I encountered earlier when trying to use the getOriginalValueAsString() method were due to my misunderstanding of what the member field was expecting: It is expecting the string representing the column name: e.g. 'End' rather than a string of the value of that column name such as toString($Event/End) which was what I originally attempted.

It is possible that use of the AuditTrail module may also be useful, but I have not yet explored that.

Thanks,

John

Mike Kumpf · Answer 4 · 2014-07-30

John

Maybe I am missing something, but it seems to me that in your microflow, you could use a Rollback action to rollback the calendar appointment in case there is a conflict. This is one of the out of the box actions, so you shouldn't need to use Community Commons. Also, I can confirm what Stephan said - when calendar events are changed via drag and drop, the object that is passed to the onChange microflow has not been committed - so doing a Rollback on that object will reset the values to what they originally were.

Hope that helps,

Mike

John Shott · Answer 5 · 2014-07-30

Mike:

Thanks for taking the time to make that confirmation. I had originally tried to use the built-in Rollback and have now gone back to look at my original attempts once again. I now believe, however, that the problem that I thought I had when I tried to use the rollback was actually a flaw in my own thinking that resulted in microflow logic that never actually got me to the Rollback activity.

Thanks for encouraging me to look at the more straightforward approach again,

John