<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>The main idea is to write X3DLoaderJava, X3DLoaderJSON,
X3DLoaderVRML, X3DLoaderJavaScript, X3DLoaderPython, ... ,
toFileJava, toFileJSON, ... etc. for APIs, API examples, Schemas,
Encoded Documents, Object Models, etc. etc. In a very
object-oriented fashion. If we ultimately do this with XSLT or
Java, I don't care, but we should define good interfaces to
support immutability and encapsulation.<br>
</p>
<p>Suggestion: Revisit Cameron Browne's "class grammar" for
maintaining and enhancing code. I think we should consider
maintaining source code in revision control, or maintaining
versions of jars which contain source code.</p>
<p>I have not heard of a Java Code Builder like there is a Dart
code builder.<br>
</p>
<p>John<br>
</p>
<div class="moz-cite-prefix">On 8/1/21 12:26 AM, John Carlson wrote:<br>
</div>
<blockquote type="cite"
cite="mid:9f0683c3-34cb-e5c2-0abd-d7696c828576@gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<p><a class="moz-txt-link-freetext"
href="https://howtodoinjava.com/design-patterns/creational/builder-pattern-in-java/"
moz-do-not-send="true">https://howtodoinjava.com/design-patterns/creational/builder-pattern-in-java/</a></p>
<p>Builder in Dart:<br>
</p>
<p><a class="moz-txt-link-freetext"
href="https://github.com/dart-lang/code_builder"
moz-do-not-send="true">https://github.com/dart-lang/code_builder</a></p>
<p><br>
</p>
<p>I call the Builder pattern the Importer/Exporter pattern. One
passes the Importer or subclass to the node or statement
constructor, and the Exporter, Formatter or subclass is passed
to the node or statement outputter. I think it would be a good
plan to pass a Builder or Importer to a constructor in Java.<br>
</p>
<p>Main advantages: 1) Immutability 2) Encapsulation<br>
</p>
<p>Main disadvantages: 1) code bloat.</p>
<p>According to the first link, you create a Builder as an
enclosed class of the class you want to build. You can have a
class hierarchy of Importer/Exporters you want for different
encodings, etc.</p>
<p>Obviously, I offer this as an alternative to XSLT hell.
However, we may need to bootstrap with XSLT, I think, and it
would be good to have roundtrip with the XSLT. My preference is
to bootstrap into Java. Then add different Exporters as
alternatives to the XSLT Exporter. For exporting, you pass the
exporter to the outputter method, and then extract any data
values using getters on the exporter.<br>
</p>
<p>Obviously this is a step away from the "Java Beans,"
"Enterprise Java Beans," "Plain Old Java Object" and "Data
Transfer Object" patterns of Java. The important thing is
immutability and encapsulation for proper object-oriented
design.</p>
<p>I think this would be a good pattern for Blender I/O plugins to
follow. Would it be possible to generate the Blender X3D plugins
from X3DJSAIL?<br>
</p>
<p>What I will attempt to do is create a new Serializer in
JavaScript to produce Java "Importer/Exporter" examples, but I
may need to dig into X3DJSAIL. Perhaps I can treat current
X3DJSAIL classes as importer/exporters. I think this way, we can
advance step-by-step to the next generation of X3DJSAIL.</p>
<p>Question: Does C/C++/C# SAI or other SAI already follow this?
Is this "CreateX3dFromString()"?<br>
</p>
<p>John<br>
</p>
<p>Additionally, I will work with es6x3d and x3d.dart to adopt
importer/exporter patterns.</p>
<p>I do not see this as a problem per se for Python or Dart. But
it would be good to have exporters for Python and Dart in
X3DJSAIL. It may help with the pyjnius X3DJSAIL-Python SAI.</p>
<p>I am thinking of leaving the org.x3d.web3d.jsail as
Importers/Exporters and starting a new package next to sai and
jsail in X3DJSAIL. Perhaps there would be some organization of
Importers/Exporters by input/output language under jsail.<br>
</p>
<p>John<img src="cid:part3.BD86498E.23F3D720@gmail.com" alt=""
class=""></p>
</blockquote>
</body>
</html>