[Top]
This page gives a short overview of the planned features of PFC 2.0. As mentioned in the
feature plan, this list is subject to change.
[Top]
[Top]
This API and container support will offer the application callbacks on the session life cycle. I have been playing
with the idea of disconnected (suspended) sessions that can be reattached on a later time. This might also enable
session take-over by an administrator, other user or the support desk.
[Top]
There is not much support for themes and styles in the current PFC version. Most components use cascading style
sheets that can be changed to alter the look of the application. Making themes in this way can be a time
consuming and complicated task, it also does not guarantee a consistent look and it does not easily support
third-party or new components. A theme and style API should fix most of these current issues while at the
same time keep the rendering phase as efficient as possible.
[Top]
Google uses the XMLHTTPRequest object to update the web page without doing a
full re-rendering of the page. PFC has an architecture that can easily support this web development concept.
[Top]
Recently some articles appeared showing the ease with which web applications can be built given the right set of tools
and libraries. They show you how, with just the definition of a domain object or database table, user interfaces for
CRUD (create, retrieve, update and delete) operations are automatically created together with any required logic.
Although most of these examples are somehow naieve and will surely not hold in a professional and complex
environment I am convinced that a huge portion of the required effort in this area (CRUD operations) can be handed
over to a framework.
The binding framework of PFC will be responsible of exposing a variety of data sources and providers through a generic
but uniform API. On top of that API, binding models will be provided that can bind the models of common user interface
components (TextInput ...) to these data sources. The binding module must supply enough defaults so that simple
cases can be handled with little or no customization but must be customizable enough to accomodate more
complex cases of binding.
[Top]
One part of the binding module will create a relational oriented API on top of data sources and providers.
Since this API will always be used in a web application, special measures should be taken to support
the asynchronous nature of this environment. One example is that in a stand-alone application, enough
hooks are provided to guarantee freeing of resources in a timely fashion, in a web environment
however, not all of these hooks are present or can be made present. The binding module will inherently
support the intrinsics of web applications.
[Top]
To augment the support for rapid application development set forward in the pfc-binding module, a module
must be developed to create and manage user interfaces based on descriptors. Instead of writing several classes
in which components are constructed, connected and placed on panels, the developer should limit his tasks
to describing what the user interface must contain. Using that description the module will then take
responsability.
A powerful combination can be created if this module can be made to talk with the binding module. That will truely
bring us a step closer to RAD development with PFC.
|