View Full Version : JavaScript Entities
mathsinger
05-20-2003, 11:56 PM
Problem -- to develop a technique whereby novice web page coders can have a page highlight a field in a table based on an argument passed through the URL in the
...?type=1
format. These pages will be called from hotlinks in an ArcView table & so there will not be a browser involved. I cannot see the people who will be using this technique writing entire pages in JS.
Browser(s): IE 5+, recent Navigator versions. I have also been testing in Mozilla
Progress so far -- I have written code to parse the argument out of the URL, and to choose a hilight color for the background of the cell. What I cannot seem to do is to get that color determined at "run-time". At first I thought that JS entities would do it, but understand that they are being deprecated, and may not work on some recent browsers. I have been trying the following sort of thing:
<td bgcolor="&{hilight(1)};">
<td bgcolor="&{type==1?"yellow":"white"};">
Questions:
1. Is this even possible?
2. Is my information on JS entities correct? Is there any alternative?
3. If JS entities are workable here, what is wrong with my syntax?
Thanks,
Susan
cheesebagpipe
05-21-2003, 12:23 AM
Just a quick note: JS entities have always been, afaik, a Netscape/Mozilla implementation. Definately not IE (more's the pity). Not sure if they're deprecated but Micro$oft doesn't seem to be overly interested.
OK, scratch that: a Netscape implementation. Here's an (immodest) opinion (http://www.securityfocus.com/archive/1/272037/2002-05-09/2002-05-15/0).
liorean
05-21-2003, 01:07 AM
They were actually a potential future feature in [HTML4] and are commented on in the DTD. The reason they were dropped in newer versions (XHTML) was mostly because their type of information shouldn't belong to the structure at all. That's what we have CSS for. Too bad the BECSS spec <http://www.w3.org/TR/becss> seems to not have been worked on since 1999. It was a nice suggestion to standardise what Mozilla has in XBL and Internet Explorer has in HTCs. One single spec for that and we would suddenly have a really powerful dynamic behavioral binding feature to play with. XBL and HTC both provide features to CSS that can be compared to those of XSLT. The difference here would be that XSLT is more like document.write in it's abilities and XBL/HTC (unified in BECSS) is more like the DOM. In fact, considering what features they both depend on, that is pretty straight on. XSLT maked changes to what is parsed, and XBL/HTC simply makes dynamic assignment of behavior to that much easier.
cheesebagpipe
05-21-2003, 01:19 AM
Jeez, everybody knows that.
chrismiceli
05-21-2003, 04:27 AM
That made me laugh so hard.
:) :) :) :) :) :) :) :) :)
mathsinger
05-21-2003, 01:35 PM
But seriously now, folks......
I really do need help with this, if nothing more than to give my "user" a definitive answer that it can't be done unless he is willing to write JavaScript. Can I dynamically produce a style sheet? Actually, it is one of the other options I thought to try.
Regards,
Susan
liorean
05-21-2003, 02:13 PM
You can do it through the DOM in a regular JavaScript, but you can't do it through JavaScript entities since there's no support for them. You can also use Microsoft proprietary css expressions, if you wish.
Oh, and sorry for teching out on you...
cheesebagpipe
05-21-2003, 04:31 PM
Susan...
Be interested in hearing more about this. If you could provide a little more detail as to the sequence of events...not entirely grasping what's involved here (my reach generally exceeds my grasp). :(
mathsinger
05-21-2003, 05:56 PM
Let's see..
I work for an outfit which produces GIS (Geographical Information System) products, using ArcView. I don't produce these products myself, but am a technical resource for those who do. Their areas of expertise do not generally lie in producing web pages. However, ArcView has the ability to provide hotlinks associated with various features, e.g., soil types, vegetation types, etc. The goal is to arrange things so that when the ultimate user clicks on a feature, a web page will appear, scrolled via a named anchor to the relevant information in a table. In addition, we would also like to highlight the relavant lines in the table. My goal in this is to develop a technique whereby the producers of the product can make this happen without vast complication. HTML documents are not the major goal of the product; data and information about it is, and most of the producer's time is spent on (and should be spent on) other aspects of the data.
I have retrieved my DHTML & CSS books and am off on a further quest. Would appreciate any pointers in a good direction.
Thanks,
Susan
brothercake
05-21-2003, 07:41 PM
Originally posted by liorean
XBL and HTC both provide features to CSS that can be compared to those of XSLT. The difference here would be that XSLT is more like document.write in it's abilities and XBL/HTC (unified in BECSS) is more like the DOM.
The difference here would be that XSLT is a semantic and interoperable method for transforming data, while XBL and HTC are hacky non-namespaced excuses of methods for transforming data ;)
Susan - any reason why you can't just generate the webpage dynamically - if the hotlink feature in ArcView can be programmed to generate a URI with query-string parameters, then you could write a process to pull information from a single source (a database or maybe XML) and generate a webpage on the fly ..?
mathsinger
05-21-2003, 08:04 PM
Well, I personally would have no problem with creating web pages on the fly, but I think that the people who will be doing this eventually probably would. In addition, this product is to go on a CDROM to be loaded into who-knows-what computer, which has to be loaded with ArcView, but browsers are up for grabs. So are anything like database management systems, etc. I might, however, be able to swing XML, though I am very out-of-date there. I was keeping up with it for awhile at its beginning, but lately.... :o :o :o
Oh, well. One can't do EVERYTHING.
Could someone clue me in, here? Is this really feasible in terms of browser support? I suppose I could write a DTD & and other supporting things and then teach them some simple XML -- They really don't need to do anything fancy, and most of them are going to have to learn HTML anyway. They might as well learn XML.
Best regards,
Susan
brothercake
05-21-2003, 08:35 PM
Oh well I was thinking you create the process that generates the pages - so all your users have to do is learn how to write the query string, and maintain the data source; no?
Theoretically you could run a web server from a CDROM ... never tried it personally, but I can't see why not.
If you wanted to do client-side XML transformation, it will only work in mozilla browsers and IE6. But I think in the business world the fact that x or y feature only works in one browser is not a problem, because you're dealing with a known environment - upgrade all their computers if necessary; no biggy.
For what it's worth - I think XML is probably easier to teach than HTML, because there are no browser/implementation hassles to think about - it's just marked-up data. Here's one example for how you could demonstrate it to non-webby folk:
<person>
<name>Fred</name>
<sex>male</sex>
</person>
Anybody can grok that ... shurely :)
liorean
05-21-2003, 09:15 PM
Originally posted by brothercake
The difference here would be that XSLT is a semantic and interoperable method for transforming data, while XBL and HTC are hacky non-namespaced excuses of methods for transforming data ;)I don't agree here. XSLT first of all has very little to do with semantics. It's destructive, as it transforms the structure itself, and replaces it with another structure. In that transformation, any semantics present in the original document gets lost in favor or the structure and semantics of the representation. Using the bindings technologies, you don't do anything destructive, as the structure of the original isn't at all changed. Instead, you change the representation of a semantic structure into the representation you want. If you for instance want to add something to the document using the DOM; if you have already transformed it using XSTL, you must tailor make the entry not after the original semantic structure, but after the structure of the representation. Using bindings, you can always use the original semantics and rely on the representation to be what the bindings specify. Thus, bindings have more semantical value than transformation, while achieving the same representation.
The paralell I drew between document.write and DOM works rather good for the XSLT versus bindings case. Sure XSLT can do a lot, but it's it's a static technology. Transformantions change the structure and semantics at load, and thus achieve the representation you want. Bindings change the representation of the given structure, and does so dynamically after load. There's things that you can do in one technology that you can't do in the other, but I think the bindings are overall the best technology.
Just my .02 €.
Anybody can grok that ... shurelyWell, they would of course need to know English, but otherwise I think it's pretty straight forward. It's when you start fooling around with more complicated structures and abstractions that you lose the majority of hte people. Like if you use full-fledged XLink to represent links.
brothercake
05-21-2003, 09:36 PM
All fair comment :D I love the idea of behaviors, it's their implementation I don't like; A standard would be very nice.
But hey XML doesn't have to be in english does it:
<personne>
<nom>Pierre</nom>
<sexe>mâle</sexe>
</personne>
or even
<人>
<名前>多く</名前>
<性>男性</性>
</人>
No?
mathsinger,
This may be way off base, I am trying to decifer what you want.
Problem -- to develop a technique whereby novice web page coders can have a page highlight a field in a table based on an argument passed through the URL in the
The goal is to arrange things so that when the ultimate user clicks on a feature, a web page will appear, scrolled via a named anchor to the relevant information in a table. In addition, we would also like to highlight the relavant lines in the table.
HTML documents are not the major goal of the product; data and information about it is
All I could think of is you want to display information in a browser about something when a link is clicked and the producer shoudn't need to know HTML.
Try this, it dynamically creates a page from data, all you have to change is the data. (save it as index.html)
<HTML>
<HEAD>
<TITLE>Test</TITLE>
<!-- *** Start The Data *** -->
<script>
var data = new Object();
data['none'] = {
error : "Item Not Selected"
}
data['nofind'] = {
error : "Item Not Found"
}
data['widget1'] = {
Name : "Widget 1",
Width : "100 Meters",
Weight : "10 Kg"
}
data['widget2'] = {
Title : "Widget 2",
Color : "red",
Length : "25cm",
Density : "25g/m3",
Material : "tungsten"
}
data['widget3'] = {
Product : "Widget #3",
Size : "Medium",
Width : 100,
Height : 200,
Area : 100*200,
Two_Words : "Need the underscore"
}
</script>
<!-- *** End The Data *** -->
<script>
var selected = location.search.substr(1);
if( selected == null || selected == "")
product = data["none"];
else if( data[selected] != null)
product = data[selected];
else
product = data["nofind"];
</script>
</HEAD>
<BODY>
<center>
<h1> Widget Details </h1>
</center>
<table border="2" align="center">
<tr>
<script>
for(var i in product)
document.write("<td>" + i + "</td>");
</script>
</tr>
<tr>
<script>
for(var i in product)
document.write("<td>" + product[i] + "</td>");
</script>
</tr>
</table>
<a href="index.html?widget1">widget 1</a> |
<a href="index.html?widget2">widget 2</a> |
<a href="index.html?widget3">widget 3</a> |
<a href="index.html?widget4">widget 4</a>
</BODY>
</HTML>
mathsinger
05-22-2003, 03:46 PM
Actually, the whole table needs to be displayed, with the relevant data highlighted. The guy who asked me to look at this originally had a page with just the data for one feature type, which then linked to the table with data for all of the features. The hope was to eliminate one click....
Off to XML...
-- Susan
vBulletin® v3.8.2, Copyright ©2000-2012, Jelsoft Enterprises Ltd.