|
|
|
|
L3 – Changing elements and relationships in
the database |
|
| In
traditional programming environments, this
is one of the most complicated tasks to perform.
The programmer needs to be aware of all the
dependencies that his/her code has on the
various data elements in the database and
the different validations that need to be
done for each such element. With zeroCode,
though, this is as simple as a few clicks.
You make changes to the database, transfer
those changes into your SQL model and regenerate
objects. Once that is done, you can redo any
of your UDMs as needed. Not changing a UDM
for an entity that has a new element will
not adversely impact its use, so you can modify
UDMs on an as-needed basis (as in L2 above). |
|
| Consider
this example: when you first built a salesperson
management application, let’s say you assumed
that more than two salespeople will not split
commissions for a given sale. Come December
and you find that you need to support upto
four salespeople on some complex sales transactions.
Here’s what you do, typically: |
|
 |
Make
the appropriate database changes. In this
example, add two more optional (nullable)
references to the Salesperson table from the
Order_Header. You would typically do this
using SQL ALTER statements, via whatever database
management utility you (or your DBA) use. |
|
|
|
Change your model.sql to reflect these changes.
The safest mechanism is to download the model.sql
from your site and add the two new columns
and their foreign-key references to the model.sql,
as changes to the CREATE statement for the
Order_Header. Do not add ALTER statements.
If you choose to make changes to a save version
of your site’s model.sql, ensure that you
verify the schema in the zDE, using that option
on the left panel. |
|
|
| |
Regenerate
the Java data-access objects in your site
using the option in the zDE. Note that this
option takes in the new model.sql and will
overwrite existing objects by recreating all
of them. If you have changed the data access
objects in any manner after your previous
run of site-generation, those changes may
be destroyed and you may need to reintroduce
them subsequently, in the newly-generated
objects. |
|
|
|
Now you can open up the UDMs that you need
to include the new elements in, delete the
nodes that represent the tables that you changed
and reintroduce them. This will automatically
bring in the new data elements you added.
You can now choose to regenerate the HTML
to use auto-generated HTML or hand-code the
changes to the page, to add these data elements
appropriately. |
|
|
| If
you added non-nullable data items to the database,
you will obviously need to ensure that the
new elements are reflected on all the pages
that access the relevant tables and that the
data in the database is accurately initialized
in these new columns. |
|
| Deleting
or changing columns and relationships in the
database is a much trickier operation, although
only in the database context. The zDE supports
changes in the same manner as additions (as
described above), but special care needs to
be taken in the database to ensure data integrity
is maintained when such changes are made. |
|
|
| L4
– New data sources need to be added |
|
|
In a number of multi-platform situations,
you will need to access data from sources
other than a database or from an external
database using non-JDBC connections. For example,
you may want to display the NASDAQ closing
index every day in a month, along with the
temperature in New York on the same day and
the number of shares your company traded on
those days. In this case, you would retrieve
the stock information from your own database,
but the NASDAQ index and the temperature would
come from external sources like a web-page
or a special Web API that the information
provider may give you. |
|
| While
bringing in new data from a web-page is simple
and straightforward, using a pre-specified
API would need Java development. In order
to do this, you will need to use a zeroCode-specified
API to build a new “data port”. This needs
Java skills, to establish connections to the
new data sources using new Java objects. Click
here for more information on building a new
data port. |
|
| Once
the data ports have been built, you can use
them in your UDM in the same manner as you
use the data access objects that zeroCode
generates. These data ports become available
in the UDM construction process and can be
used directly. Changes can be made as in L3
above, in the appropriate UDMs and the HTMLs. |
|
| The
zeroCode servlet is available to be called
from any other application, using standard
server-side Java constructs. |
|
| All
in all, changing a zeroCode-built site for
pretty much any kind of extension is a whole
lot easier than in traditional programming
environments, so much so that the zeroCode
development process completely upends some
of the earlier tenets of programming, like
“Thou shalt not make database changes after
development”. With zeroCode, such changes
can be dealt with in the same manner as any
other lesser changes – with a few clicks. |
|
|
|
