As noted above, there are no application frameworks presently available for Linux that combine being:
There are many free components available, including databases, web servers, scripting languages, but these must always be assembled in ad-hoc ways, which discourages reuse.
There are many components available; most will require substantial systems integration efforts that require substantial background.
This is not dissimilar to the previous point; you in effect need to be capable of architect the system in order to modify it.
It is arguable that there is no such framework anywhere; this does not dictate against trying to improve what is available.
Use CORBA as a technology to enable the separation of functionality into components.
This enables splitting applications into modular components as this makes the components easier to understand, manage, and debug.
Furthermore, as workload grows, it might be expected to split processing onto multiple physical systems, and the use of an ORB makes it much easier to move "virtual servers" onto separate physical hardware.
A third advantage is that the use of CORBA permits extensive use of both component and interface standards, thus leveraging other peoples' designs.
Since CORBA is interoperable with a wide variety of languages and platforms, this provides a goodly level of portability as well as a standard interface scheme.
Use Application Servers to perform "application logic" to separate application logic from user interface.
This has three benefits:
Application logic can be managed explicitly as such; it is not encoded in the user interface, which makes it much more difficult to analyze and manage;
Application logic can run in the more robust environment of a server rather than (as is unfortunately all too common) within the GUI;
Application logic can run on a remote server, thus reducing the load on the desktop machine.
Use abstractions to describe screens, rather than requiring programmers to code screens.
This means that it becomes at least plausible to deploy applications atop multiple graphical systems.
(define (demo) (let* ((conn (pg:connect "template1" "postgres" "postgres")) (res (pg:exec conn "SELECT * from scshdemo WHERE a = 42"))) (format #t "status is ~s~%" (pg:result res 'status)) (format #t "metadata is ~s~%" (pg:result res 'attributes)) (format #t "data is ~s~%" (pg:result res 'tuples)) (pg:disconnect conn)))
Use XML to build data interchange infrastructure.
This allows much of the data validation to be automated, which should reduce the likelihood of being affected by data corruption.
Furthermore, adding in an XML infrastructure means that XML datasets may be analyzed by common XML reporting tools even if those tools are not completely cognizant of the content.
An interesting idea would be to use XML as report data interchange format; reports would be generated as XML data by an application server, and then passed on to the presentation server (e.g. the program with which the user interacts) which would then render the XML data for viewing. A sufficiently "intelligent" presentation server might be able to do further manipulations such as summarization and "drill-down."
The Glade User Interface Builder takes an approach where user interface code is represented using XML as its "native format."
The XML is then transformed into C source code, which may then be combined with other code in order to build an application.
libGlade takes this a step further, providing a way for the GUI description (in XML form) to be read and parsed at runtime.
This reputedly parallels the GNUstep notion of MIBs, where the GUI elements involve separate "resource" files that may be modified separate from the application, thus allowing the behaviour and appearance to be modified at runtime.
Design database updates based on transactions, so that all updates may be grouped together into an atomic transaction grouping, and updates managed by a single robust transaction monitor process.
There does not exist at present a free TP (Transaction Processing) Monitor similar to BEA Tuxedo or Transarc Encina. A November 1998 Slashdot discussion indicated there was a population with interest in such an effort.
The CORBA Transaction Service might prove suitable as a design to use.
While there may not be a free TP monitor, there are a number of libraries available to help do processing based on the related notion of asynchronous message queueing.
Link in a "report writer" to generate reports.
This could be based on:
Data "exports" could be generated in XML form; this could be browsed on-screen in considerable detail, or transformed (using XSL?) into printable form.
Display Postscript is a printing framework that offers both onscreen and on paper rendering; this represents the "WYSIWYG" approach.
TeX may not be highly suitable for screen display, but it could be used as the "rendering system" to provide printed output of extremely high quality.
PDF may be unattractive for archival purposes, but, like DPS (DISPLAY POSTSCRIPT) , represents a WYSIWYG framework that be readily displayed and printed.