You can build a working movie-ticket reservation prototype in MDriven Designer and MDriven Turnkey by modelling theatres, shows, show-specific seats, and a server-processed seat request; this walkthrough is for developers who want to validate the data and reservation workflow before replacing the generated UI.

What you build

This part of the Movie Theatre example creates the data model and the initial generated ViewModel UI for a ticket-purchase flow.

A customer can:

• Browse shows.
• Open a buy-tickets view for a selected show.
• Select show seats and submit a reservation request.
• Receive a granted or declined result after the request is processed on the server.

The generated UI is intentional at this stage. Use it to verify that the model exposes the data and actions that the final screen needs. Part 2 replaces this initial ticket-selection view with a custom seat-map presentation.

Model the theatre and reservation domain

Create diagrams that separate the long-lived theatre layout from the data that changes for each show and reservation.

Concept	Purpose	Example
Theatre	Holds the physical seating layout.	Rigoletto and Sergel are theatres.
Seat	Represents one physical seat in a theatre.	A theatre has two rows with four seats in each row.
Movie	Represents a film that can be scheduled.	Die Hard or The Martian.
Show	Represents one screening of one movie at one theatre and time.	The Martian at Rigoletto today.
ShowSeat	The link object between a show and a physical seat. It is the seat availability for one particular show; it can also be regarded as a ticket.	Seat A1 can be available for one show and sold for another.
SeatRequest	Represents a user's request to reserve one or more ShowSeat objects.	A signed-in user requests two seats for a selected show.

A physical Seat belongs to a theatre and can occur in many shows. A Show has many seats. Model the Show–Seat relationship as the ShowSeat link object so that each show has its own state for each physical seat.

Add states for availability and requests

Add a state machine to ShowSeat (or the ticket represented by ShowSeat) to record whether the seat is free or sold for that show.

Add a state machine to SeatRequest for the reservation process. The workflow shown in this example uses a request-processing state and ends in either a granted or declined result.

The request-processing transition must execute on the server. This is the concurrency boundary: the server checks the requested seats and updates their state, rather than trusting a browser-side check. Two users can therefore submit competing requests, but the request processor determines whether the seats can be granted.

Use diagram colors consistently

Use diagram colors as a visual grouping aid. In this example:

• Theatres and physical seats belong together because they are relatively stationary.
• Shows and ShowSeat objects belong together because they vary by screening.
• Movies form a separate concern.
• Seat requests form a separate concern.
• Mark the server-executed request-processing transition in red so it is immediately recognizable in the diagram.

Colors do not replace associations or state definitions. They help you review lifecycle boundaries and identify related model elements quickly.

Create the management ViewModels

Before building the customer-facing ticket page, create the straightforward ViewModels needed to maintain the basic data and actions that open those views.

Create ViewModels that let you manage:

• Theatres, including their names.
• Seats for each theatre, including row and seat position information.
• Movies, including the movie image used by the ticket view.
• Shows, including the selected theatre, movie, and show time.

Use the generated ViewModel UI to enter and verify this data. This is also a way to discover missing attributes and associations before custom browser code depends on them.

Example setup data

Run the application, register a user, and enter sample data such as:

1. Create theatres named Rigoletto and Sergel.
2. Create movies named Die Hard and The Martian.
3. Add show records for the movies at Rigoletto today.
4. Set an image for each movie so the ticket view can identify the selected film visually.
5. Create the physical seats for a theatre, for example two rows with four seats in each row.

Development proceeds in a loop: run the application, inspect the generated result, adjust the model, upload the model, and test again. For example, if the show-management view does not show the movie image, expose the image as read-only and rerun the application.

Create ShowSeat objects for every show

Each new show needs ShowSeat objects for the physical seats in its theatre. Add a method to Show that creates these show-specific seat records.

In the Action Editor body, the example uses:

self.Theatre.Seat ->collect(s|self.Seat.Add(s))

This expression iterates over the theatre's seats and adds them to the show seat collection, creating the show-specific seat/ticket records needed for that show.

After creating a show, run the action to create its ShowSeat records. The buy-tickets ViewModel can then show each seat's row and its current availability state.

Build the initial Buy Tickets ViewModel

Create an initial Buy Tickets ViewModel for a selected show. Do not start by writing custom JavaScript. First expose the information and actions declaratively, then use the generated UI to test the model.

The view should show the buyer:

• The show time.
• The theatre.
• The movie.
• The movie image.
• The show seats, including row information and state.

For example, a buyer selecting The Martian at Rigoletto needs to see what film to watch, where to go, when to arrive, and which show seats are available.

At this stage, listing all ShowSeat objects is useful even before the final seat-map layout exists. It lets you verify that you can select seats, clear the selection, and submit a request. Finding gaps here is preferable to discovering them later in browser-side runtime checks.

Add a show browser

Create another ViewModel that browses shows and provides an action that opens the Buy Tickets ViewModel for the selected show.

Build and verify it in this order:

1. Add expressions that display the show information you need.
2. Add the action that opens the ticket-purchase view.
3. Run the application and verify that you can open a show, select seats, and submit the request.

This browse-to-buy flow gives users an entry point to the reservation process while keeping the selected show as the context for the ticket view.

Process seat requests on the server

Create a separate diagram and a ViewModel named Server Side Check Requests. Make it available for server-side execution.

Use an expression that finds SeatRequest objects waiting to be processed:

SeatRequest.Allinstances ->select(sr|sr.State="RequestProcess")

Configure the server-side execution to run every five seconds. On each run, the ViewModel actions process the requests in the RequestProcess state.

The processing action must:

1. Take the seats included in the request.
2. Check whether all requested ShowSeat objects are free.
3. If they are free, set the seats to sold and grant the request.
4. Otherwise, decline the request.

This server-side check is required to avoid overbooking. The browser can display a seat as available when a user selects it, but another user may submit a request for that same seat before the first request is processed. The server makes the final decision and updates the ticket states.

Verify the complete flow

Test the prototype from a buyer's perspective:

1. Browse to a show.
2. Open the Buy Tickets ViewModel.
3. Select one or more ShowSeat records.
4. Submit the SeatRequest.
5. Wait for the server-side request processor to run.
6. Confirm that the request is granted and the selected tickets change to sold with the buyer's name, or confirm that the request is declined when the seats are no longer free.

The generated view is now a validated contract for the final ticket screen: it has the show context, the seat data, selection behavior, request submission, and server-authoritative result.

Next step: replace the generated ticket view

Continue with Movie Theatre Part 2 to replace the generated Buy Tickets layout with a ViewModel override and a seat-map UI. Part 2 keeps the model and server-side reservation workflow from this page while changing how the seat data is rendered and clicked.

See also

• Documentation:MDriven Movie Theatre Part 2
• Documentation:MDriven Turnkey Series
• Documentation:MDriven designer overview Part 4
• HowTos:MDriven Designer Overview Series