 |
 |
 |
 |
|
 |
 |
Gravitybox Schedule.NET
1998-2005 Gravitybox Software LLC
Page 69 of 90
Controllers
If you are data binding to a local database, you can bind simply by selecting the
appointment table, with the proper fields. This is quick and will work, but you will most
likely want more robust functionality. The schedule can natively process a dataset with
the tables: Appointment, Provider, Room, Category, Resource, Appointment_Provider,
Appointment_Category, and Appointment_Resource. If you use the database scripts
provided with the install, you can create all of these tables with the proper format. They
are related as described in Figure 8.1 above.
ScheduleController
Gravitybox provides a companion component named ScheduleController that is
included in with the install and allows you to connect to a database with no code. The
controller, given a connection string, connects to the specified database and queries for
providers, rooms, categories, and appointments. You need only one line of code to load
and one line of code to save. The code below demonstrates.
'Get all appointments
ScheduleDomainController1.GetScheduleDataSet("")
'Get appointments from a date range
Schedule1.DataSource = ScheduleDomainController1.GetScheduleDataSet( _
"", #1/1/2005#, #1/31/2005#)
Schedule1.Bind()
'Get a specific appointment by IDSchedule1.DataSource =
Schedule1.DataSource = ScheduleDomainController1.GetScheduleDataSet( _
"", "163c61b3-504e-4e45-b1af-ebfe205fa141")
Schedule1.Bind()
There are currently three different ways to query the database based on different
criteria. They are shown above. You only need to call one of them to load the schedule.
There is however only one way to update the database as follows.
ScheduleDomainController1.UpdateData("", Schedule1.DataSource)
When the dataset is updated, you need to immediately re-query the database to avoid
getting an error.
You will also notice that the first parameter is set to empty string. In the database
schema defined there is an “account_guid” that parses all objects into account buckets.
This allows you to build applications that load only data specific to one account. This is
quite useful if you are building an application that you wish to use to host different,
distinct users. For example, you may want to build an application for dentists and also
you want to host the dentist’s data. If you sell your application to multiple dentists then
you need some way to separate each dentist data. None of the doctor practices need
(nor do you want them) to know about each other. You could host all of the offices’ data
in the same database and no office would be aware of any other office, since each
 |