Components of vishia-Java
From Java4c
(first) |
(Navigation) |
||
(4 intermediate revisions not shown) | |||
Line 1: | Line 1: | ||
+ | ==Navigation== | ||
+ | * up: [[Main_Page]] / [[Component]] | ||
+ | * down: see chapters | ||
+ | |||
==Overview== | ==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. | 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. | ||
Line 15: | Line 19: | ||
* bazaar-archive on [[https://launchpad.net/zbnf/srcjava.zbnf launchpad.net/zbnf/srcjava.zbnf]] | * bazaar-archive on [[https://launchpad.net/zbnf/srcjava.zbnf launchpad.net/zbnf/srcjava.zbnf]] | ||
* description, home-site on [[http://www.vishia.org/ZBNF www.vishia.org/ZBNF]] | * description, home-site on [[http://www.vishia.org/ZBNF www.vishia.org/ZBNF]] | ||
+ | |||
Content of the distribution: | 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 ZBNF-Parser with this Java-soruce is able to use discrete to convert plain-text but well-syntactical files into XML. | ||
Line 23: | Line 28: | ||
* 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. | * 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 | + | * 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. | * Some util-components are included. | ||
- | * A MessageDispatcher which separates output messages (logs, able to use for embedded applications too) | + | 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 <tt>Class.forName("nameOfClass")</tt>. | ||
+ | |||
+ | 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 [[http://sf.net/projects/zbnf sf.net/projects/java2c]] | ||
+ | * bazaar-archive on [[https://launchpad.net/java2c launchpad.net/java2c]] | ||
+ | * description, home-site on [[http://www.vishia.org/Java2C 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. | |
- | + |
Current revision as of 07:06, 27 February 2011
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.