Selecthx and Selecthxml - CSS-style selection for Dom and Xml
Simon Krajewski
since the original project got way too little attention in my opinion, I
would like to give an update on selecthx(ml). The author of selecthx
updated his project today:
http://code.google.com/p/selecthx/
Make sure to check out the awesome amount of selector types that is
supported now:
http://code.google.com/p/selecthx/wiki/SelectorSupport
You can do all kinds of crazy stuff like selecting all odd numbered img
elements through "img:nth-of-type(odd)" and whatnot.
And here's my clone that works on haxe Xml:
http://code.google.com/p/selecthxml/
I've successfully ran unit tests of all the basic and some of the fancy
stuff on flash9, js, neko, cpp and php targets. If we fully polish these
libs, it might be our reply to the lack of E4X support in haxe. What do
you think?
Simon
Franco Ponticelli
Simon
--
To post to this group haxe...@googlegroups.com
http://groups.google.com/group/haxelang?hl=en
Stephane Le Dorze
Jason O'Neil
I'm pretty excited about this... Looking forward to getting home and playing with it.
Not on my laptop at the moment, so I can't test but does this use macros at all? Could it be run with selectors given at runtime?
...
Sent from my phone, so apologies for any typos...
Simon Krajewski
>
> I'm pretty excited about this... Looking forward to getting home and
> playing with it.
>
> Not on my laptop at the moment, so I can't test but does this use
> macros at all? Could it be run with selectors given at runtime?
>
The original selecthx uses a macro to generate a typed function which is
executed at runtime. It actually parses the selector string and inspects
which type you are selecting, which will give you fully typed completion
(e.g. if you select "input[type=text]", it will be treated as
js.Dom.Text). The same process is then dynamically repeated at runtime,
where again the selector is parsed and then executed.
It might seem a little odd that the selectors are parsed at both compile
time and runtime, but it provides the most flexibility and passing
values from macro runtime to actual runtime isn't trivial anyway.
For my Xml version, the whole macro pass is currently only used to
determine if you select a concrete element (with #id) or an array of
elements. I plan to allow custom inspectors later, which will then
enable typed working on known Xml formats.
Simon
Juraj Kirchheim
> executed at runtime. It actually parses the selector string and inspects
> which type you are selecting, which will give you fully typed completion
> (e.g. if you select "input[type=text]", it will be treated as js.Dom.Text).
> The same process is then dynamically repeated at runtime, where again the
> selector is parsed and then executed.
>
> It might seem a little odd that the selectors are parsed at both compile
> time and runtime, but it provides the most flexibility and passing values
> from macro runtime to actual runtime isn't trivial anyway.
Actually, it will attempt to use querySelectorAll, which has decent
support: https://developer.mozilla.org/en/DOM/Document.querySelectorAll#Browser_compatibility
I would speculate, that this will perform better than anything you
could spin yourself, even if you were to translate the selector to a
matching function at macro time already.
> For my Xml version, the whole macro pass is currently only used to determine
> if you select a concrete element (with #id) or an array of elements. I plan
> to allow custom inspectors later, which will then enable typed working on
> known Xml formats.
Intriguing idea. Might make Xml parsing a joy ;)
Simon Krajewski
> Actually, it will attempt to use querySelectorAll, which has decent
> support: https://developer.mozilla.org/en/DOM/Document.querySelectorAll#Browser_compatibility
>
> I would speculate, that this will perform better than anything you
> could spin yourself, even if you were to translate the selector to a
> matching function at macro time already.
browser support querySelectorAll has, it probably is the general case.
>> For my Xml version, the whole macro pass is currently only used to determine
>> if you select a concrete element (with #id) or an array of elements. I plan
>> to allow custom inspectors later, which will then enable typed working on
>> known Xml formats.
> Intriguing idea. Might make Xml parsing a joy ;)
I just can't make up my mind how to integrate the inspectors.
Integrating a custom inspector function is easy, but I don't want to
force people to write
xml.select("#menu ul > li a", myInspectorFunc);
There's the option of making it state based, i.e.
SelectDom.inspectorFunc = myInspectorFunc;
but this could be tricky when working with different XML formats.
Ideally, the inspector functions would be directly linked to each Xml
instance (identifier), but I'm not sure if that could be set up reliably
during compile time.
Any thoughts on this?
Simon
Juraj Kirchheim
> I just can't make up my mind how to integrate the inspectors. Integrating a
> custom inspector function is easy, but I don't want to force people to write
> xml.select("#menu ul > li a", myInspectorFunc);
> There's the option of making it state based, i.e.
> SelectDom.inspectorFunc = myInspectorFunc;
> but this could be tricky when working with different XML formats.
>
> Ideally, the inspector functions would be directly linked to each Xml
> instance (identifier), but I'm not sure if that could be set up reliably
> during compile time.
>
> Any thoughts on this?
Sure :)
Well, the type is actually associated with the document, not with the
general API nor with just the call.
Therefore I think this makes sense:
typedef Rules = {
li: ListItem,
a: Anchor,
ul: UnorderedList,
document: Document,
}
typedef TypedXml<T> = Xml;
var xml:TypedXml<Rules> = Xml.parse("<document><el id='test'>Hello</el><ul>
<li><a>1</a></li>
<li><a>2</a></li>
</ul></document>");
The problem here is, that you can lose that type rather quickly, so
this might be a better alternative:
@:native("Xml") extern class TypedXml<T> {
public inline function x():Xml
return untyped this
static public inline function parse<A>(source:String):TypedXml<A>
return untyped Xml.parse(source)
}
Here however the problem is, that the type is not Xml for the
compiler, so the ExprRequire<Xml> will not match. But that's a minor
hurdle ;)
Regards,
Juraj
Simon Krajewski
> Sure :)
>
> Well, the type is actually associated with the document, not with the
> general API nor with just the call.
> Therefore I think this makes sense:
>
> typedef Rules = {
> li: ListItem,
> a: Anchor,
> ul: UnorderedList,
> document: Document,
> }
> typedef TypedXml<T> = Xml;
Thanks, that looks very promising. I was thinking in terms of functions
because I don't think things like the HTML input types where the type
depends on an attribute can be properly handled through typedefs. This
should be fine for all other cases though.
Simon
Juraj Kirchheim
typedef Rules = {
@:pseudo(type) input: {
text:TextInput,
button:Button,
}
a: Anchor,
ul: UnorderedList,
document: Document,
}
Regards,
Juraj
Simon Krajewski
> Well, you *could* do something like this:
>
> typedef Rules = {
> @:pseudo(type) input: {
> text:TextInput,
> button:Button,
> }
> a: Anchor,
> ul: UnorderedList,
> document: Document,
> }
That looks funny, I like it.
I managed to implement the basic version, but I'm unsure as to what
actually return during runtime. The whole thing works so well for the
Dom objects because they all inherit from the MetaDom structure which
has the basic modification operations. The equivalent in regards to Xml
would be something like
typedef Anchor = {
> Xml,
href: String
};
This can be declared, but I couldn't find any obvious way of actually
creating these objects from a given Xml node. I guess this still needs
some thought.
Simon
Juraj Kirchheim
> Am 03.03.2012 15:14, schrieb Juraj Kirchheim:
>
>> Well, you *could* do something like this:
>>
>> typedef Rules = {
>> @:pseudo(type) input: {
>> text:TextInput,
>> button:Button,
>> }
>> a: Anchor,
>> ul: UnorderedList,
>> document: Document,
>> }
>
>
> That looks funny, I like it.
Yes, it does look funny. On second thought this might actually be better:
typedef Rules = {
@:pseudo(input.type) text:TextInput,
@:pseudo(input.type) button:Button,
a: Anchor,
ul: UnorderedList,
document: Document,
}
This has duplication, but it's flat. I guess it's a matter of taste.
Just wanted to add the option :)
> I managed to implement the basic version, but I'm unsure as to what actually
> return during runtime. The whole thing works so well for the Dom objects
> because they all inherit from the MetaDom structure which has the basic
> modification operations. The equivalent in regards to Xml would be something
> like
>
> typedef Anchor = {
>> Xml,
> href: String
> };
>
> This can be declared, but I couldn't find any obvious way of actually
> creating these objects from a given Xml node. I guess this still needs some
> thought.
Just as a thought: Basically, you also don't have to define the types
explicitly but just have one structure and declare the rest through
Context.define to get what you actually need (the return values must
actually be objects created from the result nodes, otherwise field
access won't do what you'd want it to).
class MyRules implements Rules {
@:name(TextInput) @:pseudo(input.type) text:{ text:String },
@:pseudo(input.type) button:{ caption:String },
@:name(Anchor) a: { href: String },
@:name(UnorderedList) ul: {},
document: {},
}
From this you can generate any type you need and the code that will
transform a result node into it.
Regards,
Juraj
Simon Krajewski
> Just as a thought: Basically, you also don't have to define the types
> explicitly but just have one structure and declare the rest through
> Context.define to get what you actually need (the return values must
> actually be objects created from the result nodes, otherwise field
> access won't do what you'd want it to).
>
> class MyRules implements Rules {
> @:name(TextInput) @:pseudo(input.type) text:{ text:String },
> @:pseudo(input.type) button:{ caption:String },
> @:name(Anchor) a: { href: String },
> @:name(UnorderedList) ul: {},
> document: {},
> }
>
> > From this you can generate any type you need and the code that will
> transform a result node into it
I'm not sure if it's even necessary to define the types explicitely. It
should be sufficient to return
Context.parse("function():{href:String} { ... }()", ...);
from the macro. I still need the specific Rules struct, but the
@:name(Anchor) could be omitted, no?
The above is easy to do, but I don't want to lose the real Xml node
because people might want to operate on that on (otherwise typed) Xml
objects as well. I could obviously just return a {href:String, xml:Xml}
object, but that might lead to name collision issues if there's ever an
attribute named xml. I also don't want to end up with a {
attrs:{href:String}, xml:Xml} object as that would partially defeat the
purpose of having easier Xml access. Since I would detect name
collisions in the macro, I think it's okay to go that way and somehow
react to an occuring collision... somehow.
Simon
Juraj Kirchheim
<simon.k...@simn.de> wrote:
> Am 03.03.2012 21:36, schrieb Juraj Kirchheim:
>
>> Just as a thought: Basically, you also don't have to define the types
>> explicitly but just have one structure and declare the rest through
>> Context.define to get what you actually need (the return values must
>> actually be objects created from the result nodes, otherwise field
>> access won't do what you'd want it to).
>>
>> class MyRules implements Rules {
>> @:name(TextInput) @:pseudo(input.type) text:{ text:String
>> },
>> @:pseudo(input.type) button:{ caption:String },
>> @:name(Anchor) a: { href: String },
>> @:name(UnorderedList) ul: {},
>> document: {},
>> }
>>
>> > From this you can generate any type you need and the code that will
>> transform a result node into it
>
>
> I'm not sure if it's even necessary to define the types explicitely. It
> should be sufficient to return
> Context.parse("function():{href:String} { ... }()", ...);
> from the macro. I still need the specific Rules struct, but the
> @:name(Anchor) could be omitted, no?
Technically, it could be, but if you have named types for everything,
they can be explicitly referenced by other code. I find that to be
comforting. I regularly succeed in having type inference give up on me
:D
> The above is easy to do, but I don't want to lose the real Xml node because
> people might want to operate on that on (otherwise typed) Xml objects as
> well. I could obviously just return a {href:String, xml:Xml} object, but
> that might lead to name collision issues if there's ever an attribute named
> xml. I also don't want to end up with a { attrs:{href:String}, xml:Xml}
> object as that would partially defeat the purpose of having easier Xml
> access. Since I would detect name collisions in the macro, I think it's okay
> to go that way and somehow react to an occuring collision... somehow.
Hide it in a "runtime only" field, that's not a valid attribute name
and access it through a helper function. For example, you could add
this to SelectDom:
static public inline function getXML(result:SelectDom):Xml {
return Reflect.field(result, " can't touch this!!! ");
}
And then go:
Context.parse("function():{>SelectDom, href:String} { ... }()", ...);
Where the field is actually created. As a matter of fact, I don't know
how PHP would respond to you using arbitrary field names for anonymous
objects, but I think it works.
This way, you can call SelectDom.getXML to get the xml, even if there
is a getXML attribute on the element. Otherwise you can call it on the
result itself through using. Of course declaring the result to be a
subtype of SelectDom is just an arbitrary choice. Anything
distinguishable will do.
Regards,
Juraj
Simon Krajewski
> Hide it in a "runtime only" field, that's not a valid attribute name
> and access it through a helper function.
I had this idea too, but I thought it would only shift the issue to
another field name (getXml). I'm not sure how that behaves with using,
will have to check that out. The rest seems to be working, I'll clean up
my code and update it tomorrow.
By the way, tink's Printer.hx line 77:
if (a.length > 1)
Shouldn't this be > 0?
Simon
Simon Krajewski
> http://code.google.com/p/selecthxml/
Teaser image for upcoming update:
http://simn.de/haxe/selecthxml_nmml.png
Note how I gracefully removed the if attribute from the window tag to
hide a problem case. On the bright side, note how it auto completes to a
single element of type window. Working with Xml has never been typesafer!
Simon
Juraj Kirchheim
<simon.k...@simn.de> wrote:
> Am 03.03.2012 22:51, schrieb Juraj Kirchheim:
>
>> Hide it in a "runtime only" field, that's not a valid attribute name
>> and access it through a helper function.
>
>
> I had this idea too, but I thought it would only shift the issue to another
> field name (getXml). I'm not sure how that behaves with using, will have to
> check that out. The rest seems to be working, I'll clean up my code and
> update it tomorrow.
No, the getXml is not a member of the result, that's the difference.
The name of the field is something that just can't collide, containing
spaces for example. The getXml through using and *if* there is a
getXml attribute, one can still get to the Xml by an explicit call.
> By the way, tink's Printer.hx line 77:
> if (a.length > 1)
> Shouldn't this be > 0?
That is correct, yes :)
Simon Krajewski
> No, the getXml is not a member of the result, that's the difference.
> The name of the field is something that just can't collide, containing
> spaces for example. The getXml through using and *if* there is a
> getXml attribute, one can still get to the Xml by an explicit call.
That's the convincing argument.
I've integrated a first version which now has tink_macros as a
dependency. Usage can be seen here:
http://code.google.com/p/selecthxml/source/browse/trunk/test/TestTyped.hx
I think this is as typesafe as Xml can get. Comments and suggestions
appreciated!
Simon
Simon Krajewski
There seems to be a small problem with the whole extension approach.
Currently when doing:
var s = xml.select("body#test");
s = xml.select("body#test");
The compiler complains with
selecthxml.+TypedResult should be selecthxml.+TypedResult
I kind of understand this because I was recreating the TExtend for each
macro call, so I added a caching mechanism using Context.signature of
the class field array:
fields = t.getFields().data();
if (fields.length > 0)
{
var signature = Context.signature(fields);
if (!extensionCache.exists(signature))
extensionCache.set(signature, createExtension( { name:
"TypedResult", pack:["selecthxml"], params:[], sub:null }, fields));
ctype = extensionCache.get(signature);
}
ctype is then used as return type for the function. However, the problem
remains. Might be a general limitation of extensions? I will see if I
can find a way to fix it.
Simon
Simon Krajewski
> http://code.google.com/p/selecthxml/
I have fixed all known problems and updated the documentation:
http://code.google.com/p/selecthxml/wiki/TypedXml
You now get proxy objects to the xml attributes when selecting something
in typed mode. For example, given a proper typedef for the nmml format:
typedef Nmml = {
window: { width:Int, height: Int, fps: Int, orientation:String,
resizable:String }
}
The following would completely type-safely update the width and height
attributes of a window element:
var nmml:TypedXml<Nmml> = Xml.parse(...);
var wnd = nmml.select("window")[0];
wnd.width = 400;
wnd.height = 300;
The type for window will be defined as
selecthxml.types.nmml.Window
I wonder if it makes sense to provide a set of definitions for commonly
used Xml formats?
Simon
Juraj Kirchheim
<simon.k...@simn.de> wrote:
> I wonder if it makes sense to provide a set of definitions for commonly used
> Xml formats?
Nah, not really. At least not as a part of the lib. Such definitions
should be bundled with the lib that uses them or simply be provided as
a standalone, with dependency to selecthxml.
Either way, very nice work thus far! :)
Regards,
Juraj
Simon Krajewski
> Nah, not really. At least not as a part of the lib. Such definitions
> should be bundled with the lib that uses them or simply be provided as
> a standalone, with dependency to selecthxml.
>
> Either way, very nice work thus far! :)
Thank you! I think I'm pretty much finished for now and will release it
to haxelib if nobody has any objections or suggestions.
One more thing I'm not sure about: I need a way to define types for
elements whose names that are keywords, such as <class>. I found that
when comparing strings case insensetively, this works:
typedef Rules = {
Class: { someValue: Float }
}
Do you think this is sufficient, or can you think of a scenario where
this fails?
Simon
Simon Krajewski
Never mind, it seems much cleaner to just allow @value on element names too:
typedef Rules = {
@value('class') cl: { someValue: Float }
}
Simon
Simon Krajewski
> http://code.google.com/p/selecthxml/
I added it to haxelib as selecthxml.
Simon
Jason O'Neil
Also great job with the documentation for TypedXml: http://code.google.com/p/selecthxml/wiki/TypedXml
Going to start playing around now...
Simon
Simon Krajewski
> Bravo!
>
> Also great job with the documentation for TypedXml:
> http://code.google.com/p/selecthxml/wiki/TypedXml
>
> Going to start playing around now...
Do you have a particular Xml format you're working with? I want to make
a separate lib with a collection of typedefs for commonly used Xml
formats so this is even easier to use. I just don't know what's commonly
used by haxe devs.
Simon
Jason O'Neil
Though I imagine I'll use straight HTML a fair bit in other projects.
One other one that might be interesting is RSS, though that has a fairly simple structure, no attributes etc.
Simon
Jason O'Neil
> Do you have a particular Xml format you're working with? I want to make a separate lib with a collection of typedefs for commonly used Xml formats so this is even easier to use. I just don't know what's commonly used by haxe devs.
How about two haxe specific formats: the format used for RTTI, and Haxedoc's XML format.
Simon Krajewski
> Haha my project is quite obscure: Kdenlive Video Editing Files (don't
> ask...)
>
> Though I imagine I'll use straight HTML a fair bit in other projects.
>
> One other one that might be interesting is RSS, though that has a
> fairly simple structure, no attributes etc.
Well the TypedXml is all about attributes. I don't plan to implement
anything related to child nodes as that is properly reflected by the
selection engine itself. You can select a certain node such as
var formNode = myXml.select("form#form1");
and then select its children input nodes:
for (inputNode in formNode.getXml().select('input'))
trace(inputNode.value);
You can also obviously select them directly:
var inputNodes = myXml.select("form#form1 input");
> How about two haxe specific formats: the format used for RTTI, and
> Haxedoc's XML format.
Are these actually used in haxe applications?
Simon
JLM
I presume selecthx can do similar to sizzle (think that was the name the thing that jquery uses).
So wanted to ask if selecthx can be added to haxelib?
Also currently in my experimental divtastic ( see the one in haxelib not on googlecode ) when I create a div ( HtmlDom ) I store it and the style on the class. Now James seemed to think this was very heavy, but would it be lighter to name every div ( 'div'+Math.random() ) and then only store it's string name and use Selectorhx to get the div when I need to modify it?
I presume I can create a css3 style object and apply it to the object in a single pass, but details probably elude me.
Just thinking aloud and wondering so any thoughts welcome, but slightly annoying that selecthx is not a haxelib, I have checked it out but prefer to use a haxelib otherwise it would make divtastic too much effort to setup and track compatibility.
Cheers
Justin
On Friday, March 2, 2012 7:44:02 PM UTC, Simon Krajewski wrote:
Hello,since the original project got way too little attention in my opinion, I
would like to give an update on selecthx(ml). The author of selecthx
updated his project toda
y:
http://code.google.com/p/selecthx/Make sure to check out the awesome amount of selector types that is
supported now:
http://code.google.com/p/selecthx/wiki/SelectorSupport
You can do all kinds of crazy stuff like selecting all odd numbered img
elements through "img:nth-of-type(odd)" and whatnot.And here's my clone that works on haxe Xml:
http://code.google.com/p/selecthxml/I've successfully ran unit tests of all the basic and some of the fancy
stuff on flash9, js, neko, cpp and php targets. If we fully polish these
libs, it might be our reply to the lack of E4X support in haxe. What do
you think?Simon
On Friday, March 2, 2012 7:44:02 PM UTC, Simon Krajewski wrote:
Hello,since the original project got way too little attention in my opinion, I
would like to give an update on selecthx(ml). The author of selecthx
updated his project today:
http://code.google.com/p/selecthx/Make sure to check out the awesome amount of selector types that is
supported now:
http://code.google.com/p/selecthx/wiki/SelectorSupport
You can do all kinds of crazy stuff like selecting all odd numbered img
elements through "img:nth-of-type(odd)" and whatnot.And here's my clone that works on haxe Xml:
http://code.google.com/p/selecthxml/I've successfully ran unit tests of all the basic and some of the fancy
stuff on flash9, js, neko, cpp and php targets. If we fully polish these
libs, it might be our reply to the lack of E4X support in haxe. What do
you think?Simon
On Friday, March 2, 2012 7:44:02 PM UTC, Simon Krajewski wrote:
Hello,since the original project got way too little attention in my opinion, I
would like to give an update on selecthx(ml). The author of selecthx
updated his project today:
http://code.google.com/p/selecthx/Make sure to check out the awesome amount of selector types that is
supported now:
http://code.google.com/p/selecthx/wiki/SelectorSupport
You can do all kinds of crazy stuff like selecting all odd numbered img
elements through "img:nth-of-type(odd)" and whatnot.And here's my clone that works on haxe Xml:
http://code.google.com/p/selecthxml/I've successfully ran unit tests of all the basic and some of the fancy
stuff on flash9, js, neko, cpp and php targets. If we fully polish these
libs, it might be our reply to the lack of E4X support in haxe. What do
you think?Simon
Simon Krajewski
> I was talking to James last week and he was explaining some aspects of
> css. Now he was suggesting I use sizzle or something to dynamically
> access div's and apply styles in a single go to reduce redraw and also
> can use css3.
>
> I presume selecthx can do similar to sizzle (think that was the name
> the thing that jquery uses).
>
> So wanted to ask if selecthx can be added to haxelib?
I'm not the author, so I can't add it. Your best chances are probably to
file it as an issue:
http://code.google.com/p/selecthx/issues/list
> Also currently in my experimental divtastic ( see the one in haxelib
> not on googlecode ) when I create a div ( HtmlDom ) I store it and the
> style on the class. Now James seemed to think this was very heavy,
> but would it be lighter to name every div ( 'div'+Math.random() ) and
> then only store it's string name and use Selectorhx to get the div
> when I need to modify it?
I don't really get what you're trying to do. The style is stored in the
Dom anyway, so why would you have a separate class?
Simon
JLM
I don't really get what you're trying to do. The style is stored in the
Dom anyway, so why would you have a separate class?
http://code.google.com/p/divtastic/source/browse/divtastic/js/DisplayDiv.hx
provides a layer of abstraction that allows me to use js more like flash, for instance I found many issues in IE8 were solved by using a double div structure ( ImageDiv inside DisplayDiv ) which was not needed for other browsers, the abstraction of DisplayDiv allows me to reduce special cases limit manipulation to consistant subset, and provide a limited logical interface that reduces time spent and increase overall consistancy. I am not a js developer and have not used the language before ( I should be considered a newbie with js ) so I tend to make sense of js from my perspective of animating. If I store style local to my class then the code in methods is far cleaner but obviously if maybe adding too much memory overhead and a selector is more optimal I need to take this into consideration. Obviously I am using raw div's in some places when experimental drawing but for main structures I am wrapping HtmlDom and Style into a single class that can be treated more like a MovieClip. I understand my approach may not be correct but interested in evolving it to see where it goes, hence the interest in selecthx. So far I have fairly robust structure that works on lots of browsers and even phones but obviously I need to look at the best way to mix in html5 and css3 efficiently without abandoning some of the legacy support my approach provides.
The question was is it better to store a reference to a string and select HtmlDom and style on every access or to store direct references or maybe allow a mixture. And er why is selecthx not in haxelib it looks to be fairly useful. Also I am thinking sizzle or selecthx would allow me to apply a style change to multiple elements in one browser refresh, I guess I need to find a bit more info on how browsers do rendering to improve my understanding.
But I don't want to take the conversation towards my library, but the more general question of the relative merits of storing a reference to a style / htmldom or accessing it via a selector and how selecthx would compare with sizzle typedef s.
Simon does that explain a bit more what I am trying to ask in my round about way, sometimes i ask rather silly questions but I normally find they improve my understanding.
Simon Krajewski
> But I don't want to take the conversation towards my library, but the
> more general question of the relative merits of storing a reference to
> a style / htmldom or accessing it via a selector and how selecthx
Obviously it makes sense to store a reference to objects that you
frequently access, e.g. each frame. Likewise, it makes little sense to
roll out your own accessing structure when the Dom and libs like
selecthx already provide one.
I guess I still don't really get what you're asking.
Simon