Help with date picker - Velo

Hi, I have a start date and an end date for a caravan rental & need the selected dates to be disabled once the user has confirmed the booking by clicking ‘submit’.


John Doe accesses the website & chooses 1st Jan 2022 as his rental start date on ‘datePicker1’. He then chooses 7th Jan 2022 as his rental end date on ‘datePicker2’. He fills the rest of the form including his personal details then clicks ‘submit’.

This then populates ‘dataset1’ with the details that were inputted.


The issue I have is that when John Doe clicks ‘submit’, I need that information to be pulled back through so that the next user, (in this case, Jane Doe) accesses the website & is not able to select 1st Jan 2022 on ‘datePicker1’ or 7th Jan 2022 on ‘datePicker2’ but can select the next available date and so on.

Is there a code out there that will allow for this?

I have looked at the disable dates resource but not sure this will work.

Any help would be greatly appreciated.

Yes, disabling dates will work, but only so far: if John and Jane both look at the site AT THE SAME TIME, they will both see their dates available. When John submits, Jane’s calendar will NOT refresh. So she will be able to book too.
That is why frontend checking only goes so far: you also have to check at the backend just before making the reservation, to exclude the above problem.
And you are going to have other problems too: do users come in from different time zones? Is the renting company located outside those time zones?
Really, I developed a (hotel) reservation system using Wix, but it is a tad more complicated than you might suspect.

Thanks Giri, timezones wouldn’t be a factor as all bookings would be based in the UK. I don’t suppose you have a code to allow this to work by any chance do you?

@info89408 I fear you have no idea what you are getting yourself into. E.g. in the above example, where you have to do a backend check to avoid concurrency, do you realize you have to do 4 combined OR-queries to determine if the from-to dates are available: in-out, out-in, out-out and in-in. That is, if you have chosen a reservation based system, not its complement, an availability based system.
And what about security: you cannot wix-dataset your way out of this, it’s too vulnerable. So you have to move everything to the backend, unless you want to risk people making reservations for nothing.
Really, I beg you, if you have no compelling reason to write your own reservation system, do not do it. (A compelling reason might be: “I have researched all available apps on the market, none of them do what I want, I cannot adjust my wishes because that’s my competitive advantage.”. A non-compelling reason might be: “apps on the market cost me 400 x a year, and this wix-thing is for free”.
If the latter, DO NOT DO IT, you will regret it for the rest of your life.