AltME groups: search

In the ancient (!!) rebol.org snapshot I have locally, I counted 
11 occurrences in 8 files (blog, new-blog, make-doc, make-doc-pro, 
makedoc2, json, translate, xml-dom) in a total of ~1000 files and 
255k lines of code.

My daughter married John Resig's brother.  Long conversations.  John 
is a good guy, a human-centered technology sort of guy.  Saw the 
DOM and went yuk.  I've got to do something about this.

Sunanda, absolutely. I went way too fast on this. 

Unfortunately there is no way to refill the form fields from the 
cgi data. Now I say so the DOM and a Javascript maybe able to. I 
tried some little things but it seems to mess things up more than 
doing good.

Andreas:  Sorry. I wasn't really commenting as much on Make-Doc-Pro 
as the impending realization that we are going to see a ton of forks 
branching off.  Make-Doc and Make-Doc-Pro have been associated in 
my mind with the "official" RT over the years. 


Hopefully the R3 team will be able to keep this thing focused.  Still 
not sure who those people are.  As long as Mark Down is pure Rebol, 
I suppose I don't have much preference.  Rebol has always taken the 
high road, so if MDP is better, I think we should stick with it. 
 Widespread adoption has never been as important as top quality better 
design.


If we continue to adopt whatever is widespread we'll end up losing 
everything that is better.  Amiga OS, Be OS, QNX Nutrino, etc.  All 
far better OS designs than Unix and Windows NT.  What do we end up 
with?  Unix and NT and of course the dreaded DOM (don't try to convince 
me that a flavor of Linux is anything more than a Unix OS).


So better is better.  If MDP is better, then we should adopt it, 
not because it is widespread, but because it is better.

AdrianS:  Not mixing at all.  I am done with taking something like 
MarkDown which is limited in syntax and "adding features" to make 
it do more things.  That's how the beast we call the DOM came to 
be.  An awful thing.  You can't talk about the syntax without talking 
about the design of the parser.  They can't be separated.

Whew!  Not being clear.  The DOM is the result of taking a simple 
Hypertext engine and trying to turn it into a application architecture. 
 Everyone adopted it because it was widespread, not because it was 
good at appications.

Graham depends on the tool. With dig. You do
dig MX domain.dom

I know about evaluate for doing DOM stuff from the .r script, but 
what about the other way around?

It works like a DOM. It decomposes (parses) html page (disadvantage 
is it requires tags to be properly ended, but that is maybe question 
of robustness of parsing mechanism, which just could be made better) 
into rebol block ....

the thing I really don't like is - original html code structure (pretty 
formatting is lost), as html code is generated back from "DOM" (rebol 
blocks of blocks) ... I don't like it, but well, otherwise you would 
have to remember original position in original html template and 
things could become tricky ...

Any DOM experts here ?

I have a frameset with two frames, and in the first frame there is 
a menu implemented with <ul>.

I am wondering if I can move the <ul> menu out of the frame into 
the top level document. (The frame exists only for the menu, so I 
should be able to size it to zero so that it does not obscure the 
top-level doc.)

This would mean I could keep the website frameset-oriented without 
doing the work of converting it to single pages. And frames allow 
pure HTML to include code efficiently.

I found document.body.removeChild(elem), but I get lost when I try 
to identify the new location and createElement.
Can anybody help with that ?

By the way, I didn't play much with the DOM until recently.

I found that appendChild(elem) should do the move.

But still difficulty navigating the DOM tree to get to the right 
place where it can be inserted.
eg.  top.frame2.appendChild(elem)  is not working.

Frustration: The DOM inspector says the frame has a property "contentDocument" 
but I can't seem to get at it.

ah, so the main problem here is imo still the same - XML parser. 
Building kind of "DOM". Rebol's XML parser is rather simplified after 
all. I do remember using Gavain Mckenzie's xml parser, which was 
much more usefull - it allowed for hooks during parsing and created 
rebol object too ...

As text? Is the XML a DOM tree, parse-xml generated blocks, what?

as a dom tree but it may be generated blocks as well

How is your DOM tree implemented? REBOL doesn't currently have very 
good XML support by default as such. People tend to use text, blocks, 
objects or a combination of them.

From 'Tech News' -- Discussion on implementing the DOM (or something 
similar)...

Mozilla reference -- http://www.mozilla.org/docs/dom/

So it tries to conform to SAX (Simple API to XML) instead of the 
DOM...

Yes the DOM is the standard.

So if we implement this api in rebol, we could use standard documentation? 
And browsers are based on DOM, we could map that to rebol-plugin 
and control browser?

So the DOM would be more usefull than having SAX? (if that is correctly 
laid question)

AFAIK yes. SAX is efficient, dom simple to use.

Well, perhaps DOM will be efficient in its Rebol incarnation :o)

SAX is like parse. [a-tag another-tag (do-something) /a-tag]. DOM 
works like load does. AFAIK.

So with DOM you need all in memory, with SAX you can stream.

As programmer not AFAIK. with a dom you can use path-notation. with 
SAX you build that tree yourself. I guess SAX makes sense when you 
convert data, like xml-make-doc. one tag, output something, another 
tag, output something other.

If its more like a block of records, it would be DOM. parse<->sax, 
load <-> DOM.

There are two major types of XML (or SGML) APIs:

Tree-based APIs

    These map an XML document into an internal tree structure, then allow 
    an application to navigate that tree. The Document Object Model (DOM) 
    working group at the World-Wide Web Consortium (W3C) maintains a 
    recommended tree-based API for XML and HTML documents, and there 
    are many such APIs from other sources. 
Event-based APIs

    An event-based API, on the other hand, reports parsing events (such 
    as the start and end of elements) directly to the application through 
    callbacks, and does not usually build an internal tree. The application 
    implements handlers to deal with the different events, much like 
    handling events in a graphical user interface. SAX is the best known 
    example of such an API.

It should work -- XML -> DOM -> XML -- with the DOM being a document 
structure and a collection of methods for manipulating itself.

what would you find more usefull when working with XML? DOM sounds 
good when working with loaded document, all those find-element-by-name 
etc funcs sound usefull. For streaming kind of purposes (protocols), 
SAX sounds being a better option ...

The thing is - result of DOM parsing is tree representation of document 
- in Rebol .... the question is, what if you need data organised 
otherwise? You will have to search that tree and build such structure 
which fits you anyway ....

Which is the point in my suggesting the DOM :o)

I don't think the DOM should be as complex as you suggest.

actually that description favors DOM. First, we dont want to save 
memory, we are scripters. We use load too.. Second, we are not strongly 
typed (they mean static typed). SO we can happily be generic.

ok, is anywhere complete and nice DOM specs? W3C org?

But we should not think that having DOM will allow us to manipulate 
website elements, as having document loaded into rebol DOM will not 
allow us to manipulate DOM tree loaded into browser :-)

Petr, that is exactly what the DOM does -- and web site elements 
*are* xml.

Petr, I don't anticipate being able to manipulate a browser's DOM.

i im using the scripts made by Gavin the code is great, but libs 
for dom implementation are out there and are free i dont know why 
not to use this natively  in rebol i feel like the stone age here, 
tell me if im wrong but i feel like a cave man doing my parsing like 
this. if the code is free and the implementation is easy why not 
to have this in rebol ? just because we can exeed 650k ?

I still believe it can the DOM be implemented succinctly in Rebol, 
in a way that not only makes it easy for Rebollers to manipulate 
XML content, but makes Rebol a desireable tool to work with XML, 
period.

XML as an interchange format is common, as Pekr says.....It many 
ways it is better than CVS files that we used to use.

But XML as a sort of toy in-memory database that can be updated with 
APIs like DOM -- well that is a lurch into a strange direction, and 
not one I'd he happy to take.

the thing is simple - you are ither able to read, change, store XML 
files, or not, simple as that .... so what Chris means is - being 
able to read XML into DOM like structure, then do something with 
particular fields, store it back into XML ...

Don't forget in your structure that attributes can have name spaces 
as well.  In the DOM, attributes are made with the same node prototype.

I understand the need for efficiency, I am also mindful of completeness. 
 The DOM is a complete standard for accessing XML (and I appreciate 
that the 'O' in DOM does not necessarily mean Rebol object! :o)

Especially since REBOL objects have a different semantic model than 
the objects that class-based object-oriented languages use to implement 
the DOM.

If you use a linear structure it would probably be best to use a 
list instead of a block to better facilitate insertions and deletions. 
This would be OK because you would have to access it in a linear 
way anyways. But if you are doing that, you might as well be using 
an event-based parser instead of a DOM.

We should choose the way of how we integrate it into rebol - SAX, 
DOM, other ...

http://www.artima.com/intv/dom.html- The Good, the bad and the DOM 
- "a camel is a horse designed by committee" :-)

As Christophe told on the mailinglist - we actually need both SAX 
and DOM, because if you have a large document and are only interested 
in a sequence of appearings of elements one at a time, you don't 
need DOM, but if you need information about the overall structure 
of a document you have to read in the whole document and that's DOM. 
But if Christophe is doing DOM already - don't know to what extend 
- this would be very nice and might be ok for now.

Would it make sense to have XML files be represented as a port like 
xml:// . This could make sense for DOM and for SAX. But please correct 
me if that's stupid. For SAX this would enable one to copy from the 
port and get events by copying, for some one could navigate with 
some dialect and position the cursor in the document. A copy would 
read the data at the current positon - but then a block or something 
which represents an element could be returned. But I guess that's 
not well thought out. :-)

To Michael:

I'm not sure if need DOM and SAX, there problem is, that the commitee 
tried to develop language independant interfaces - so both APIs have 
problems in the targeted programming language. DOM is inefficient, 
and you should avoid it. The best way seems to be:
1. have a parser like SAX with events
2. build the model in the best way for your language
3. provide a API for your language

Basically XOM does it for JAVA very well, E.R.H. uses a SAX parser 
and converts to its own object model that is optimized for java. 
For REBOL this should be something like a block, I think. (Blocks 
are best way to store things in REBOL ?). But thats internal side 
of the the tool and could be the rebxml block structure. As api there 
should be a dialect, maybe one that uses a port (there I have less 
knowledge - have to learn about this).

Pekr: I do not know XOM, i will study it. Maybe it fits beter than 
our idea of DOM.

I thought SAx was about finding the most suitable data structure 
- not a tree representation, which is DOM.

I don't know if the event handling part is mandatory (BTW, to whom 
?).
isn't all about accessing XML data the best way a PL can ?

No, parse-xml generates a (broken, incomplete) DOM tree. Gavin McKenzie's 
xml-parse is more like a SAX parser.

I've also noticed a tendency to kick the DOM (no doubt for good reason) 
-- though worth noting that it is a complete api to xml and it is 
a standard api, I wouldn't underestimate the value of the latter, 
particularly when it comes to Rebol advocacy...

But this is the issue here with Rebol and XML, there are solutions 
that suit one XML operation or another.  Aiming for loosely implementing 
DOM gives us loading, extraction, modification, and saving without 
affecting the integrity of the data structure.  Examples: changing 
the title of an HTML page, adding an entry to an RSS file, etc.

Using DOM methods, you can do this albeit clumsily, but completely. 
 All through a set of standard functions, with no need to manipulate 
the structure directly.

DOM: in java APIs there were allways problems with dom - big amount 
of memory, not optimized for a language, so there was a need for 
optimized tools like JDOM, XOM or DOM4J, they all prefer SAX for 
parsing and have their own internal model - of course the API is 
special for all these tools and no standard like DOM

does it work SAX way or DOM way? I mean - load first, then parse, 
or parse while reading way?

maybe, but maybe not. We need to be able to interface XML (DOM) anyway 
.... (e.g. for plug-in )

this group exists for a long time, and IIRC initially we were more 
or less discussing rebol - XML interoperability - SAX or DOM parser 
in rebol .... while from what is being discussed now, sounds like 
slightly bit different topic?

; Next, Quick DOM:

do http://www.ross-gill.com/r/qdom.r

Only one method at the moment - get-by-tagname


Note, this is not an attempt to implement W3 DOM.  Just a quick approximation 
for fast manipulation (hence the name).  It's object happy, not sure 
of the weight considerations as such.

do http://www.ross-gill.com/r/qdom.r

doc: load-dom {<some><xml>to try</xml></some>}
values: doc/get-by-tagname <xml>
values/1/value = "to try"

Ok, another revision.  This has a few more methods, I may strip them 
down to read-only, as I don't need to manipulate the object though 
I left them in for completeness.

>> do http://www.ross-gill.com/r/qdom.r
connecting to: www.ross-gill.com
Script: "QuickDOM" (none)
>> doc: load-dom {<some><xml id="foo">to try</xml></some>}
>> foo: doc/get-by-id "foo"
>> foo/name
== <xml>
>> foo/value
== [
    /id "foo" 
    # "to try"
]
>> kids: foo/children
== [make object! [
        name: #
        value: "to try"
        tree: [
            # "to try"
        ]
        position: [
   ...
>> kids/1/value
== "to try"
>> doc/tree/<some>/<xml>/(#)           
== "to try"

>> do http://www.ross-gill.com/r/altxml.r
connecting to: www.ross-gill.com
Script: "AltXML" (7-Jun-2009)
>> all-stats: load-xml/dom your-xml-data 
>> player: stats/get-by-id "b.11965"                        
>> his-stats: first player/get-by-tag <stats-baseball-offensive>
>> his-stats/get #hits                                          
== "1"


>> remove-each code codes: all-stats/get-by-tag <sports-content-code> 
["league" <> code/get #code-type]
== [make object! [
        name: <sports-content-code>
        space: none
        value: [
            #code-type "league" 
      ...
>> foreach code codes [probe code/get #code-name]
Major ^/      League Baseball
== "Major ^/      League Baseball"

>> google-xml: load-xml/dom clipboard:// ; copied from page
>> entries: google-xml/get-by-tag <entry>
== [make object! [
        name: <entry>
        space: none
        value: [
            #etag {"BxAUSh5RAyp7ImBq"} 
            <...
>> foreach entry entries [probe entry/get <resourceId>]
spreadsheet:key
== "spreadsheet:key"

I like SAX model, because IIRC it allows to work on things in a "streamed" 
way, whereas DOM requires you load everything in memory? Sorry if 
I oversimpilifed it :-) IIRC Doc used such aproach in his Postgress 
SQL driver, in opposite to his mySQL one ...

It's a matter of tradeoff, if you only need fast XML document reading, 
SAX is the winner. If you need to modify the document, you need DOM 
(with or without SAX).

I just created this function to convert the data tree returned from 
REBOL's default parse-xml function back to the same string:
context [
	out: copy ""
	emitxml: func[dom][
		foreach node dom [
			either string? node [
				out: insert out node
			][
				foreach [ name atts content ] node [
					out: insert out join {<} [name #" "]
					if atts [
						foreach [att val] atts [ 
							out: insert out ajoin [att {="} any [val ""] {" }]
						]
					]
					out: remove back out
					
					either all [content not empty? content] [
						out: insert out #">"
						emitxml content
						out: insert out ajoin ["</" name #">"]
					][
						out: insert out "/>"
					]
				]
			]
		]
	]
	set 'xmltree-to-str func[dom][
		clear head out
		emitxml dom
		head out
	]
]

Graham, AltXML dom objects have a 'flatten function that renders 
xml.  It preserves namespaces but not whitespace or cdata as cdata 
(though I may do a strict version that does both).

Reichart - have you ever looked into stuff like transformations? 
If XML was all that easy as you suggest, how is that we don't have 
proper SAX or DOM parser in rebol - those supporting libs are sometimes 
larger than Core itself - I wonder, if it was intention of its creators 
......

Volker, I know, but some time ago I though that e.g. you have rebol 
block for e.g. and I thought that there might be some api, kind of 
DOM, so that from C library, you would access it via such structure 
and you would manipulate rebol datatype value directly

Interesting, bever thought about that. Seems Google has thought about 
that too. Because with firefox they can build spiders which press 
buttons, read the results from the dom etc. Means you may get some 
robot-users which try mad input..

And they have this new traffic-tools for webmasters, where you can 
see what is searched, how yoursite is ranked etc. So everyone can 
tune his ajax enough to be googable too.

but still, dom interface is weak, no? otoh we don't need full rebol 
version of dom, js has one, so via do-browser we can call even dom, 
right? :-)

server-in-a-browser would be a piece of cake with rebol. just consider 
that you can output HTML code to the browser via DOM as well as View 
graphics

I really don't understand all the buzz about Ajax. About 1998/1999 
a friend of mine and I made a remote Javascript debugger that used 
IFrames to update the client page without reloading. And we were 
able to remote debug the client side. The problem was, that we really 
drove the Javascript and DOM engines to the limit...

and it's only advatntage is access to the DOM.

I did before when trying stuff

index|dom_user|domains|11|CREATE INDEX dom_user on domains ( domain, 
user )
index|dom1|domains|16|CREATE INDEX dom1 on domains ( domain )
index|user1|domains|21|CREATE INDEX user1 on domains ( user )

something else entirely: should there be a more REBOLish way to access 
the browser DOM tree?

(I think it would be very cool to have a DOM tree browser written 
in REBOL)

Yes, a DOM tree browser would be very cool.

1) is likely a pipe dream without ubiquity.  As messy as JS/DOM is, 
it is a standardised language that most if not all modern browsers 
adhere to.  That it is standardised allows Ajax developers to depend 
on it (which was not the case when pre-standardised implementations 
ruled).

well, you can minimize the use of JS, but not entirely get rid of 
it. I'd imagine that someone could conjure up a library that translates 
common DOM access through JS to rebol code

do-browser goes out? that means no DOM access in the mozilla version?

Running a REBOL/Services client in a webbug and having it control 
the browser through the DOM could be useful though.

I'm not sure that such information is possible through the DOM (which 
is where it would come from). wouldn't that be a security hole?

I think it would be. DOM only allows access to page related data, 
not anything beyond that. you can, I believe, tell which browser 
you are running through the DOM

Mozilla: I think the problem with hosting the Mozilla control in 
IE with a wrapper is two-fold:

 (1) one more wrapper layer slows things down (a problem for high-performance 
 apps, e.g. graphics-intensive)

 (2) according to that page, there's no scripting support. that's 
 a major bummer because we need at least do-browser, not to mention 
 the possibility of DOM access.

Mozilla: This opens up a good discussion. What I really like about 
npruntime is the native access to the DOM. On IE, COM gives us that 
too. The problem/question is -- maybe you guys have ideas -- how 
to expose those C++ reference counted objects to REBOL clients?

wrt own window on top to do the window messages, etc -- I'm all for 
slamming itself on top of the browser, and not going through it to 
embed view.   or make it a "windowed" control, which is how IE does 
SELECT elements.  The complexity there is having it crop to be part 
of the page.  I think wndows media control is like that, where you 
can pick a windowed version, which performs better (probably from 
similar things that you are running into.  MSAgent runs in the browser, 
and is allowed ro roam anywhere on the screen in an irregularly shaped 
winoow.  It also starts a server process which handles all calls 
to the interactions with applications like IE and Office that take 
advantage of that aspect.  It's all asynchronous/multithreaded, and 
shuts down automatically when there are no more client controls to 
serve.


The DOM provides screen position information, but the downside is 
that with embedded controls like Adobe SVG viewer and Flash is that 
they will respond correctly to transparency (showing html page background 
through transparent parts of control  -- never got REBOL plugin to 
do that, which has something to do with wmode="transparent"  or something 
similar

Use Firebug to inspect which DOM properties give you the correct 
height...

I thought by setting the object's size properties through the DOM... 
I haven't tried.

hi guys, I can't find ANY example of calling javascript within the 
plugin !    can any one just give an example where I get some values 
from the DOM (I'd like to retrive the current URL from which the 
plugin was called, so I can talk to the server... a tool I built 
needs to be setup for each site... (without changing the code... 
its compressed.)

maxim, I made this a long time ago, shortly after the first plugin 
came out:

http://hmkdesign.dk/dom/curvyclean.html

http://hmkdesign.dk/dom/<-- all files can be seen here

nothing is finished, but you can at least see some DOM calls somewhere 
in there :-)

Hey Doc, thanks..
One thing I was trying with Uniserve years ago went like this.. 
1) A http request is received as usual. (port 80)

2) Depending on the request, Uniserve would launch a process that 
may run for hours (ie: reading a website looking for changes), and 
would occasionally send a message back to the ip address, but on 
a different port (communicates to a flash script on the original 
response page, that in turns manipulates the DOM.)


So, what's the best method to run these small scripts as to not block, 
and close without closing the server. 

I still want to serve up an HTML response, so it's a hybrid of sorts.. 
sends back a page AND runs it as a handler too?