zeroCode,
addresses the development of web-based
business applications from a
designer’s perspective. This makes
zeroCode the ideal platform to put
together forward-thinking, extensible
and scalable applications for Internet
and Intranet users in an enterprise
setting. The zeroCode platform supports
the development of just about every kind
of business application, with special
abilities to deal with data from
different types of sources across the
web.
The Need
for Server Side Logic
One
important requirement that zeroCode
users have identified is the ability to
build complex server-side logic that
encapsulates business rules and
execution sequences. Normally, such
business logic is encapsulated in
server-side objects written in Java or
C++. In some cases, such objects are
deployed as “beans” managed by an
application server. These objects are
accessed from a zeroCode-built
application, just like from any other
application, and their capabilities
exploited in the application context.
While this
approach of hand-coding business logic
is an infinitely-extensible and
therefore well-accepted mechanism, it
has the limitation that it needs
programmer skills to put together.
Instead, a good solution in the zeroCode
context would be an engine that accepts
business logic in a non-programmatic
language and executes it in the context
of a zeroCode-built application. A major
step forward from there would be the
ability to execute such business logic
from outside a zeroCode-built
application, therefore making it a
repository of business logic that is
available enterprise-wide.
Operational
Background
Notice that,
like in any web-based application, a
zeroCode-built application is driven by a
cycle of requests and their responses. In
the
simplest
case, the user requests a particular
URL, and the application determines the
corresponding UDM. The application then
retrieves the data specified by the UDM
and returns it to the user after merging
it into a rendition template (usually an
HTML template), as shown in the diagram
above.
In the
more complex case where the user submits
a form associated with a UDM A, the
application first executes the UDM’s
submission operation (edit or delete),
and then determines the response UDM B
that should be produced. It retrieves
the data for UDM B and returns it to the
user after merging it into a rendition
template, as illustrated in the flow
diagram shown below.
In either
case, the zeroCode environment must support
the introduction of server-side logic at
various points in the sequence.
