Components of vishia-Java

From Java4c

Revision as of 07:06, 27 February 2011 by Admin (Talk | contribs)
(diff) ← Older revision | Current revision (diff) | Newer revision → (diff)

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

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

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.

Personal tools