[x3d-public] 4 things before pursuing further development
John Carlson
yottzumm at gmail.com
Thu Dec 30 10:22:28 PST 2021
I do apologize in advance, but I will not search the mail archives
next. I'm guessing I saw an Exception being thrown, but did not
document it properly. I'm going to cave in on this. I do not have any
evidence of an containerField="metadata" errors being thrown at this
time. I may have the energy as some point, but it doesn't seem to be a
pressing issue.
I think that "code too large" is a better thing to work on now, if it's
possible to do class splitting in XSLT (creating inner classes should be
okay, I think). I don't know how you name classes in Java, and that may
be a long term issue with supporting more .class files than .x3d files.
Wisdom from Java would be appreciated now, and wondering if I should
change my java to a single .class, and let Java programmers do their own
splitting instead of me trying to automate it.
Here is some example files, which could probably be increased in size by
30x or so. I'm not quite sure why there are different dates. I don't
really have a clean up mechanism, I guess. Java leaves a bunch of
source code turds around based on my code.
-rw-rw-r-- 1 coderextreme coderextreme 1852 Dec 24 01:35
JinLOA4$MFVec3f656.class
-rw-rw-r-- 1 coderextreme coderextreme 1138 Dec 30 12:11
JinLOA4$MFVec3f65.class
-rw-rw-r-- 1 coderextreme coderextreme 1730 Dec 24 01:35
JinLOA4$MFVec3f661.class
-rw-rw-r-- 1 coderextreme coderextreme 1338 Dec 24 01:35
JinLOA4$MFVec3f666.class
-rw-rw-r-- 1 coderextreme coderextreme 1655 Dec 24 01:35
JinLOA4$MFVec3f671.class
-rw-rw-r-- 1 coderextreme coderextreme 1338 Dec 24 01:35
JinLOA4$MFVec3f676.class
-rw-rw-r-- 1 coderextreme coderextreme 1654 Dec 24 01:35
JinLOA4$MFVec3f681.class
-rw-rw-r-- 1 coderextreme coderextreme 1910 Dec 24 01:35
JinLOA4$MFVec3f686.class
-rw-rw-r-- 1 coderextreme coderextreme 1338 Dec 24 01:35
JinLOA4$MFVec3f691.class
-rw-rw-r-- 1 coderextreme coderextreme 1665 Dec 24 01:35
JinLOA4$MFVec3f696.class
-rw-rw-r-- 1 coderextreme coderextreme 1488 Dec 30 12:11
JinLOA4$MFVec3f69.class
-rw-rw-r-- 1 coderextreme coderextreme 1495 Dec 24 01:35
JinLOA4$MFVec3f701.class
-rw-rw-r-- 1 coderextreme coderextreme 1694 Dec 24 01:35
JinLOA4$MFVec3f706.class
-rw-rw-r-- 1 coderextreme coderextreme 2026 Dec 24 01:35
JinLOA4$MFVec3f70.class
-rw-rw-r-- 1 coderextreme coderextreme 1950 Dec 24 01:35
JinLOA4$MFVec3f711.class
-rw-rw-r-- 1 coderextreme coderextreme 1333 Dec 24 01:35
JinLOA4$MFVec3f716.class
-rw-rw-r-- 1 coderextreme coderextreme 1655 Dec 24 01:35
JinLOA4$MFVec3f721.class
-rw-rw-r-- 1 coderextreme coderextreme 1635 Dec 24 01:35
JinLOA4$MFVec3f726.class
-rw-rw-r-- 1 coderextreme coderextreme 1780 Dec 24 01:35
JinLOA4$MFVec3f731.class
-rw-rw-r-- 1 coderextreme coderextreme 1358 Dec 24 01:35
JinLOA4$MFVec3f736.class
-rw-rw-r-- 1 coderextreme coderextreme 2314 Dec 30 12:11
JinLOA4$MFVec3f73.class
-rw-rw-r-- 1 coderextreme coderextreme 1645 Dec 24 01:35
JinLOA4$MFVec3f741.class
-rw-rw-r-- 1 coderextreme coderextreme 1346 Dec 24 01:35
JinLOA4$MFVec3f75.class
-rw-rw-r-- 1 coderextreme coderextreme 2021 Dec 30 12:11
JinLOA4$MFVec3f77.class
-rw-rw-r-- 1 coderextreme coderextreme 1138 Dec 24 01:35
JinLOA4$MFVec3f80.class
-rw-rw-r-- 1 coderextreme coderextreme 1346 Dec 30 12:11
JinLOA4$MFVec3f81.class
-rw-rw-r-- 1 coderextreme coderextreme 1143 Dec 30 12:11
JinLOA4$MFVec3f85.class
-rw-rw-r-- 1 coderextreme coderextreme 2512 Dec 30 12:11
JinLOA4$MFVec3f89.class
-rw-rw-r-- 1 coderextreme coderextreme 2314 Dec 24 01:35
JinLOA4$MFVec3f90.class
-rw-rw-r-- 1 coderextreme coderextreme 1985 Dec 30 12:11
JinLOA4$MFVec3f93.class
-rw-rw-r-- 1 coderextreme coderextreme 2021 Dec 24 01:35
JinLOA4$MFVec3f95.class
-rw-rw-r-- 1 coderextreme coderextreme 2304 Dec 30 12:11
JinLOA4$MFVec3f97.class
-rw-rw-r-- 1 coderextreme coderextreme 1953 Dec 30 12:11
JinLOA4$MFVec3f9.class
-rw-rw-r-- 1 coderextreme coderextreme 129996 Dec 30 12:11 JinLOA4.class
What I'd like to do is change the Skeleton with Java, instead of
modifying XML.
John
On 12/30/21 11:41, John Carlson wrote:
> John posted:
> 3. Fix or remove alternate containerFields in X3DJSAIL. /metadata/ alternate in MetadataSet.java. Discussion of alternate containerField enumerations in X3DUOM.
>
> Don replied:
>
> Also reported on mailing list last week. X3D3 and X3D4 containerField corrections relevant HAnimHumanoid/Metadata have been applied and deployed to the models in X3D Examples Humanoid Animation archives,*with most subsequent changes now deployed. *
> Authors modify the name of a containerField to correctly show the field relationship to the parent. You should never (i repeat Never Never Never) need to touch alternative containerField sources in underlying X3DJSAIL code.
>
> I reply:
>
> I was not trying to modify the alternative containerField sources. I was responding to an exception thrown. But I still need to search for the email in the mailing list. In lieu of that, a more definitive exposition on how SimpleType has not been incorporated from X3DUOM with an subversion (SVN) commit will follow:
>
> Here is relevant code about containerField_ALTERNATE_VALUES. Previous emails discussed how the metadata containerField was included in X3DUOM for MetadataSet.java. Here is relevant code from CreateX3dSceneAccessInterfaceJava.xslt. The first two sections of bolded, italicized, underlined text is where the two "value" container come in the containerField_ALTERNATE_VALUES String array. What is missing from the array is what was intended to be done in the 3rd section of highlighted code. That is, traverse into the <xsl:value-of select="InterfaceDefinition/containerField/@type"/> and pull out the SimpleType enumeration found in the @type value, instead a comment is provided (for later work?). There's no xpath to skip to the enumeration yet. I realize the code has not been released yet, and there is still existing code that provides a strawman way of doing it. I was merely asking you to provide an <xsl:when> for MetadataSet which includes "metadata" as a workaround for not expanding the SimpleType (and maybe add "value" as well, but it will appear twice if you do that). Imagine, perhaps, even replacing "value" with MetadataSet, since "value" appears in all cases with the default containerField, AFAIK. I do not know if this is still a WIP, but not checked in state or not, since you hold stuff close to your chest. If you say that this will be in the next release (which I think you have stated), I will be satisfied. But don't say it's fixed. It's not fixed until I can see the code working somewhere. You need something better than that. There's an old story about devs that say they release right after a compile.
>
> Now I will go look for the test case where having a metadata caused X3DJSAIL to throw an exception and I will retest.
> _/**/_
> <xsl:if test="not($isX3dStatement = 'true')">
> <!-- as needed, containerField updates by checking parent node and
> SFNode field -->
> <!-- Reference list found at X3D Scene Authoring Hints: containerField -->
> <!--
> https://www.web3d.org/x3d/content/examples/X3dSceneAuthoringHints.html#containerField
> -->
> <xsl:text>
> setContainerFieldOverride(""); // ensuring default value used
> containerField_ALTERNATE_VALUES = new String[] {
> "</xsl:text>
> _/*<xsl:value-of select="InterfaceDefinition/containerField/@default"/>*/_
> <xsl:text>"</xsl:text>
> <!-- TODO once recorded in X3D XML Schema and X3D Object Model,
> iterate over values and add to array -->
> <xsl:choose>
> <xsl:when test="($name = 'Shape') or ($name = 'LOD') or ($name =
> 'Transform')">
> <xsl:text>, "proxy", "shape"</xsl:text>
> </xsl:when>
> <xsl:when test="($name = 'Group') or ($name = 'StaticGroup') or
> ($name = 'Collision') or
> ($name = 'Anchor') or ($name = 'Billboard') or ($name =
> 'CADAssembly') or ($name = 'Anchor') or ($name = 'Billboard') or
> ($name = 'CADAssembly') or
> ($name = 'CADLayer') or ($name = 'CADPart') or ($name = 'Switch')">
> <!-- debatable whether support is appropriate for a few other
> X3DGroupingNode nodes -->
> <xsl:text>, "proxy"</xsl:text>
> </xsl:when>
> <xsl:when test="($name = 'ImageTexture') or ($name = 'PixelTexture')">
> <xsl:text>, "back", "bottom", "front", "left",
> "right", "top"</xsl:text>
> <xsl:text>, "backTexture", "bottomTexture", "frontTexture",
> "leftTexture", "rightTexture", "topTexture"</xsl:text>
> </xsl:when>
> /*_<xsl:when test="starts-with($name,'Metadata')">_*//*_
> _*//*_<xsl:text>, "value"</xsl:text>_*//*_
> _*//*_</xsl:when>_*/
> <!-- X3D3 synonyms for X3D4 field regularization -->
> <xsl:when test="($name = 'MovieTexture')">
> <xsl:text>, "source"</xsl:text>
> <xsl:text>, "back", "bottom", "front", "left",
> "right", "top"</xsl:text>
> <xsl:text>, "backTexture", "bottomTexture", "frontTexture",
> "leftTexture", "rightTexture", "topTexture"</xsl:text>
> </xsl:when>
> <xsl:when test="starts-with($name,'DISEntityTypeMapping')">
> <xsl:text>, "mapping"</xsl:text>
> </xsl:when>
> </xsl:choose>
> <!-- X3DUrlObject nodes can also be a child of LoadSensor -->
> <xsl:if test="($name = 'Anchor') or ($name =
> 'AudioClip') or ($name = 'DISEntityTypeMapping') or ($name =
> 'GeoMetadata') or
> ($name = 'ImageCubeMapTexture') or ($name = 'ImageTexture3D') or
> ($name = 'ImageTexture') or ($name = 'Inline') or
> ($name = 'MovieTexture') or ($name = 'PackagedShader') or
> ($name = 'Script') or ($name = 'ShaderPart') or
> ($name = 'ShaderProgram')">
> <xsl:text>, "children"</xsl:text><!-- formerly watchList in X3D3 -->
> </xsl:if>
> <xsl:text> };</xsl:text>
> _/*<xsl:if
> test="(string-length(InterfaceDefinition/containerField/@type) >
> 0)">*/__/*
> */__/*<xsl:text> // type </xsl:text>*/__/*
> */__/*<xsl:value-of
> select="InterfaceDefinition/containerField/@type"/>*/__/*
> */__/*</xsl:if>*/_
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20211230/d2dc39ef/attachment-0001.html>
More information about the x3d-public
mailing list