Importantly, the critical thing done with an Element, rendering markup to a
character stream, walks the list and doesn't use this method.
Earlier versions of Tapestry uses an internal ArrayList for storing the
children; this was changed in 5.1 or 5.2 to help reduce the memory
footprint of pages.
On Fri, 15 Jun 2012 12:35:07 -0300, Lance Java
wrote:
Have you checked http://tapestryxpath.sourceforge.net
I'm aware of the library but I haven't used it. I can only assume that it
makes use of Element.getChildren() too (unless it accesses the private
"firstChild" and "nextSibling" fields w
> Have you checked http://tapestryxpath.sourceforge.net
I'm aware of the library but I haven't used it. I can only assume that it
makes use of Element.getChildren() too (unless it accesses the private
"firstChild" and "nextSibling" fields which I highly doubt).
> Have you done any benchmarks to kn
On Fri, 15 Jun 2012 04:57:57 -0300, Lance Java
wrote:
When manipulating the serverside DOM in a mixin etc, the only public API
for accessing a node's children is via Element.getChildren().
Have you checked http://tapestryxpath.sourceforge.net/? I haven't yet, but
I should. :)
The getCh
When manipulating the serverside DOM in a mixin etc, the only public API for
accessing a node's children is via Element.getChildren().
The getChildren() method creates a new ArrayList, adds all the children and
returns it which I think is inneficcient. I would have expected
getChildren() to retur
