Re: [x3dom-users] Modifying HTML5 and X3DOM attributes. Templating

[Leonard D. <we...@re...>]

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
> X3d...@li...
> https://lists.sourceforge.net/lists/listinfo/x3dom-users



-- 
*Leonard Daly*
X3D Co-Chair
Cloud Consultant
President, Daly Realism - /Creating the Future/