Components of vishia-Java
From Java4c
Contents |
Navigation
Overview
vishia-Java is a tree of Java-files in the package-structure org/vishia/stuff. All files are written by Hartmut Schorrig, www.vishia.org. They are used in some applications in profession too (with second license model). It is a conglomeration of different things, of course.
The usage of all files as jar-library if only a few files are needed - it isn't optimal:
- The usage as library will be proper, if an extrinsic application will use them as it is.
- If one of developers uses a component in another self-programmed application, it is self-evident to improve the used component with the challenges of the application. In that case the source should be present to check, change and improve.
- But on the other hand, if an extrinsic application should use that components proper, it should be well tested in a defined environment. A conglomeration can't be tested well enough.
Therefore that Java-sources are separated in some components. Any of the named component is available as a bazaar archive to work with sources. Any of this components are available as a download-file with some test environments as a application - or some test-Java-files exist.
This components are presented in the next chapters:
srcJava_ZBNF
- distribution on [sf.net/projects/zbnf]
- bazaar-archive on [launchpad.net/zbnf/srcjava.zbnf]
- description, home-site on [www.vishia.org/ZBNF]
Content of the distribution:
- The ZBNF-Parser with this Java-soruce is able to use discrete to convert plain-text but well-syntactical files into XML.
- The Java-sources includes a tool Header2Reflection which translates C/C++-headerfiles to C-files, which represents reflection-information about the data structures. It is used in a ReflectPro-suite.
- A Zmake-Tool is assiciated there. It converts simple make-prescripts to [ANT]-make-files.
Further usage:
- The ZBNF is used in almost all applications of the author. It is because the applications translates some texts (for example Java2C), it needs config-files (GUI) etc.
Contains:
- A commandline calling argument preparer is included in the srcJava_ZBNF-package because it is the core-package of all applications.
- Some util-components are included.
there.
- Some XML-functionalities are included. Because the ZBNF-Parser outputs XML, a simple XML-Outputter is a core-part. A calling environment for XSLT, which can work with more as one input-XML-file, is contained there. But the XSLT-translator itself should be supplied by. SAXON is recommended. For the input preparing JDOM is used. Supplied-by-packages are not need while compiling, because there are symbolic-dynamic-linked using Class.forName("nameOfClass").
Dependencies:
- This component has not any dependencies to any foreign component. Only standard-Java-classes are used.
srcJava_vishiaXML
links: TODO
Contains:
- Some functionality for documentation generation via XML.
Dependencies:
- This component needs SAXON and JDOM.
srcJava_vishiaRun
links: TODO
This component offers routines, which are nice to have in a longtime-running system. In opposite, some applications runs as task to translate something etc. If there are finished, the application is closed.
Contains:
- An interface to socket usage: This interface has the same concept as in C-language in the CRuntimeJavalike: InterProcessComm.
- A reflect-target-engine. It allows to access to all data while running via the Java-Reflections. All data can visited, presented as time-track and changed (with policy).
- A MessageDispatcher which separates output messages (logs, able to use for embedded applications too).
- Access to binary data, which are described symbolic. It includes translation from C-language headerfiles for its structure.
- Some additional parts which are used especially if the Java-sources should be translated to C with Java2C.
srcJava_Java2C
- distribution on [sf.net/projects/java2c]
- bazaar-archive on [launchpad.net/java2c]
- description, home-site on [www.vishia.org/Java2C]
Contains: Sources of the translator
srcJava_vishiaGUI
links TODO
The appearance of a GUI is able to control with scripts.
Another aspect is: All widgets are placed on a fix position, but not organized in pixel, rather than in grid-units. The size of the grid can be changed in runtime for lesser or greater display (zoom).
The basic functionalities and a configurable executable are provided. A complex application with additional source of data to show and edit can be programmed in Java using this component as base. That user-program should not know details about graphic-programming systems. A widget is a widget, not a complex of GUI-calls of the basic graphic system.
The basic graphic system used is: SWT. Swing was used in the past, but should be established again. The goal is: Both systems can be used in several applications, without change of the users application. it is a adaption layer to the basic graphic system.