[x3d-public] [x3dom-users] Modifying HTML5 and X3DOM attributes. Templating
Leonard Daly
web3d at realism.com
Fri Feb 5 16:37:45 PST 2016
John,
> So there’s a current going on where we are trying to modify HTML5 and X3DOM attributes, either with straight JavaScript or Templating (via AngularJS). While the X3D JSON loader does not support modifying attributes that I know of after the fact (well, it *may*), it dos support specifying @class and @id attribute names for later modification with your favorite JavaScript framework. Templating is likely another issue we need to face. Who has used templating with X3DOM and what success have they had? Should X3DOM support templating as part of its core, or should it be done with web components or a framework like Meteor, Angular.js, handlebars, mustache, etc.?
I am not sure I understand exactly what you mean by templating. I don't
want to make any assumptions and start going down a completely wrong
path. Can you provide a foundation for the discussion?
> We need to decide pretty quick whether Protos will be supported in X3DOM (perhaps through a prototype expander on the client and/or server side), otherwise, there will be a massive bifurcation of technology (which may be good) and struggle possibly as people attempt to merge various templating frameworks with X3DOM.
In my experience, all of the interesting X3D PROTOs contain a Script
node. Without a Script node, I have not seen or been able to construct
something that is any different than an Inline. If one exists, I would
like to know about it.
I do not see why there should be a Script node in an html-type profile
for X3D. Having JavaScript (meaning code to manipulate the DOM) and
ECMAScript (meaning code to manipulate X3D's SAI) is dangerous as people
will quickly be confused. The SAI api cannot replace the DOM api as
there are things that can to be done to the DOM that do not make sense
to handle with the SAI. There are also a lot (meaning >>1,000x) more DOM
programmers than SAI programmers.
So without Script node, I do not see the need for PROTO. I am willing to
reconsider if you can provide me useful examples that are doable in
PROTO and not Inline or some other means.
Perhaps a better concept might be a MACRO where the contained
(declarative) code is expanded and parameter values from the parent are
substituted to equivalent parameters in the expanded code. That probably
has lots of applications and would be straight-forward to code. It would
be sort-of like an Inline with pre-defined parameters. If that is the
case. it would be necessary to define any name-scoping limitations and
parameter updates. Perhaps an extended Inline definition would be
sufficient.
Leonard Daly
> I think we need to provide an answer which *isn’t* straight JavaScript, and that can be declarative.
>
> John
> ------------------------------------------------------------------------------
> Site24x7 APM Insight: Get Deep Visibility into Application Performance
> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> Monitor end-to-end web transactions and take corrective actions now
> Troubleshoot faster and improve end-user experience. Signup Now!
> http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
> _______________________________________________
> X3dom-users mailing list
> X3dom-users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/x3dom-users
--
*Leonard Daly*
X3D Co-Chair
Cloud Consultant
President, Daly Realism - /Creating the Future/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20160205/b633b787/attachment.html>
More information about the x3d-public
mailing list