Re: Modifying DOM before netWindows tree widget created.

Alex Russell <[email protected]> Wed, 21 Apr 2004 23:05:24 -0700
Newsgroups gmane.comp.windows.devel.netwindows
Organization netWindows.org
Message-ID <[email protected]>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hey Bernard,

First, thanks for the complete outline of what you're trying to 
accomplish. That helps me a lot more in formulating a complete answer 
for you = )

I'll answer the rest inline:

On Wednesday 21 April 2004 7:21 pm, [email protected] 
wrote:
> Hi folks,
>
> I think I do need some help with this.
>
> Let me explain what I am doing.  I have a discussion hierarchy that
> Domino cannot return in the structured manner required by
> netWindows (ie the nested div elements representing the hierarchy).
>  But Domino will return an identifier for each entry, and the
> structure of this identifier corresponds to the depth and location
> of the entry in the hierarchy.
>
> I am manipulating the DOM in Javascript using this identifier
> before I want to pass it on to netWindows tree widget to process. 
> The manipulated DOM structure is fine if I save it to a file with
> the relevant netWindows code in the html head - when I load the
> file, it is processed appropriately by the tree widget (and very
> cool it is too...)

This sounds kind of expensive. Is there no other server-side language 
available to do the munging here?

> However, I am at a loss as to the best way to coordinate this
> processing.  Alex (briefly) suggested that __data__.getData() would
> be the way to do it.  But looking through The Manual, it looks  a)
> like this is for asynchronous data retrieval to update the page
> already displayed b) even if it would be appropriate for the
> initial loading of my data prior to manipulation, I don't really
> understand how the data structure part of the the call would work. 
> [It did strike me when I read how __data__.getData() works, that
> maybe that is where I should be manipulating the structure of my
> document - but as I spent so long getting it to work my way, I'm
> reluctant to change it ;-) ]

Well, I think I was suggesting __data__.getData() because I wasn't 
aware that you were trying to load into a tree. In the newly 
re-written tree widget (are you using it, btw?), you can actually 
request a URL to load tree nodes from directly. Given that you're 
doing your manipulation on the client side already, this might be 
moot, but it's there for future reference.

> I also noticed that there are the __sig__.connectByName calls, and
> wondered if they might not be more appropriate.

__sig__.connect and __sig__.connectByName are the ways that methods 
are "attached" or "connected" via signals-and-slots in the toolkit. 
Essentially, when you connect two functions or methods togeather, the 
second will be notified when the first is called without the need for 
a seperate calllback mechanism. While cool, I don't know that it's 
going to solve this problem.

> All I really want to do is
> - load my page
> - manipulate div structuring in the DOM
> - have netWindows tree widget then process this altered page

This is actually a lot easier that we're making it out to be here. If 
you've had a chance to look at any of the netwindows example pages, 
you'll note that nothing happens with inline constructors until after 
onLoad() fires. This means that processing of DOM nodes to look for 
inline constructors is entirely dynamic and could happen at any time 
after onload, not just right after the document finishes loading.

Sooo, with that in mind, here's the plan:

1.) your page will load
2.) you'll manipulate your DOM structure
3.) then call NW_checkNodeIsConstructor() on the resulting node or one 
of it's parents.

NW_checkNodeIsConstructor is one of the few top-level functions that 
the toolkit defines, and it takes two arguments: the source node (as 
a reference) and the target node (as a reference). In the case of 
in-place replacement, these are the same node reference. 
NW_checkNodeIsConstructor does a recursive descent parsing of the 
passed in node and if there's an inline constructor in the subtree 
being parsed and there's a registered widget for the type declared on 
the constructor, it will be replaced with the constructed widget.

If the following is your DOM structure (regardless of when it's 
constructed or how):

<div id="widgetContainer">
	<div nwType="tree">
		...
	</div>
</div>

You might then do this:

var nodeRef = document.getElementById("widgetContainer");
NW_checkNodeIsConstructor(nodeRef, nodeRef);

I hope this helps. Let me know if you need something else or a better 
approach. The new tree widget (as well as test pages for it) are 
included in this tarball, however icons for it aren't (you'll need to 
supply your own item icons):

http://netwindows.org/releases/netWindows_0.4.0pre6.tar.gz

Regards.

- -- 
Alex Russell
[email protected]   BD10 7AFC 87F6 63F9 1691 83FA 9884 3A15 AFC9 61B7
[email protected] F687 1964 1EF6 453E 9BD0 5148 A15D 1D43 AB92 9A46
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)

iD8DBQFAh2CloV0dQ6uSmkYRAitoAKCwkS0Dm7ki8VfzHlkLiTozXpHkmwCdHFaU
s23a8Wc0M/XkTNQEgTTlXQI=
=LpV7
-----END PGP SIGNATURE-----


_______________________________________________
The netWindows developers list: [email protected]
http://netwindows.org/mailman/listinfo/devel_netwindows.org