Documentation of gwt.js et al. changes in 1.4?
Rob Jellinghaus
// This startup script is for legacy support and is now deprecated.
Instead of
// using this script, just include the selection script directly.
Is there any better documentation of the infrastructural changes in
1.4? I'm 90% sure that it's yet to be written given that things are
still in flux (multiple modules, etc.), but if there's *anything*
written up yet, it'd help me. I'm working on getting the Ajax4JSF
project's JSF/GWT integration working with r771 of the trunk, and
things have moved around enough in gwt.js and module-loading land that
any documentation whatsoever would greatly expedite my life.
And if there isn't any yet, consider this a plea to include some with
the first preview build, as otherwise -- based on my experience now --
I can guarantee a deluge of redundant questions in the user forum :-)
Thanks very much!
Cheers,
Rob
Rob Jellinghaus
use of the __gwt_getMetaProperty function that used to be globally
defined in gwt.js. In 1.4 it's been moved into
SelectionScriptTemplate.js, so now it's essentially private in the
module setup function. This breaks code that used to expect it to be
defined globally.
One workaround would be to make it a publicly visible property of the
module setup function, though that wouldn't help in this particular
case. It would arguably be better for the legacy gwt.js to still
support the previously visible global functions (or at least that
one!) for backwards compatibility. Maybe they could be modularized a
bit better so as to not pollute the global namespace, but in any case,
this particular function *is* conceptually global (it's working off
the <head> meta elements, which aren't module-specific), and
privatizing it seems slightly wrong.
I don't know if anyone else in the world besides the GWTJSF project
made use of this hook, but if they did, they'll get caught short like
I am. And if this is technically an implementation detail, not to be
relied on in user code, then I think I need to do a good detailed
writeup of how GWTJSF works! UI component integration is definitely
an interesting use case for GWT modules in general, and it almost
inevitably pushes the "implementation detail" boundaries.
Definitely more fodder for the "GWT 1.4 Migration Guide", in any
case....
Cheers!
Rob
Scott Blum
Hey Rob,
Nope, the user doc hasn't been written for this yet. The short answer is, don't bother including gwt.js; just include the selection script directly. You also don't need to use the gwt:module meta tag anymore.
The other major change is that in your module.gwt.xml, the CDATA section of a <script> node is now ignored, because we can guarantee that a dependent script will load before your onModuleLoad is called.
In fact, let me be more specific. The g4jsf integration also makes
use of the __gwt_getMetaProperty function that used to be globally
defined in gwt.js. In 1.4 it's been moved into
SelectionScriptTemplate.js , so now it's essentially private in the
module setup function. This breaks code that used to expect it to be
defined globally.
There was a very conscious decision to take *everything* out of the global namespace we possibly could. There are really a couple of reasons for this:
1) Less risk of harmful interaction with other JavaScript, other GWT apps, and other GWT apps compiled with different (and future) versions of GWT.
2) Hiding the implementation details so people don't write code that depends on them. ;)
As you've guessed, relying on getMetaProperty (at least, outside of a property provider's js code) was somewhat of an implementation detail. However, we did realize that we'd probably run afoul of someone's already using one of the implementation details. My thought was to go ahead and break them (in the feature preview/RC), and then figure out whether some kind of first-class mechanism was appropriate to do what they needed. In your case, it sounds like accessing the meta properties is something you really need (which is cool), but it's probably something that should be a Java API whose implementation details you shouldn't care about. For example, maybe a GWT.getMetaPropertyMap() that returns a Map<String, String>.
What do you think?
Scott
Rob Jellinghaus
> The short answer is,
> don't bother including gwt.js; just include the selection script directly.
> You also don't need to use the gwt:module meta tag anymore.
Roger that. I'll probably clean it up after I get the current
structure working (this is a bunch of code I didn't write, so I'm
taking it step by step).
> There was a very conscious decision to take *everything* out of the global
> namespace we possibly could.
Fair enough.
> For example, maybe a GWT.getMetaPropertyMap() that returns a
> Map<String, String>. What do you think?
I think you shouldn't tease me with Java 5 syntax in a GWT API, that's
what I think ;-) Especially when the last thread about it ended so
(apparently) inconclusively! Oh well, first things first (e.g. 1.4!).
Seriously, that seems fine. I was actually going to write such a
method in the G4JSF integration library, but I didn't know exactly how
to get at the <head> document element via RootPanel.get(). I didn't
spend much time experimenting, because it was quicker for me to just
snarf the pre-existing gwt.js code (hacking on my own time means every
minute counts).
Meanwhile, I now find that GWT trunk r771 refuses to run nicely in
noserver hosted mode under IDEA's debugger :-( Or at least, it is DOG
slow -- easily ten times slower than the previous version. No idea
what's going on here, but it's definitely annoying. Sigh! Onwards!
Thanks as always for the timely response.
Cheers,
Rob
Fred Sauer
Seriously, that seems fine. I was actually going to write such a
method in the G4JSF integration library, but I didn't know exactly how
to get at the <head> document element via RootPanel.get().
RootPanel.get() gives you the BODY, so DOM.getParent(RootPanel.get().getElement()) should give you the HTML element from which one of the children ought to be HEAD.
To get to the HTML element faster, use $doc.documentElement, which I'm pretty sure works both in quirks and standard mode to return the HTML element.
(Disclaimer, while I've fiddled with BODY and HTML, I've never actually manipulated or inspected HEAD this way.)
Just thought of two more ways: use <HEAD id="MYHEAD"> and then get it by id, or JavaScript getElementByNodeName, then grab the first element of the returned array.
--
Fred Sauer
fr...@allen-sauer.com
Rob Jellinghaus
/**
* Private cached static map of meta gwt:property values, defined as
* (meta name="gwt:property" content="propName=value").
*/
private static Map gwtMetaProperties = null;
/**
* Get a named meta property. Cache in static map. Uses logic from
* SelectionScriptTemplate.js implementation.
*/
public static String getMetaProperty(String propName) {
if (gwtMetaProperties == null) {
gwtMetaProperties = new HashMap();
Element bodyElement = RootPanel.getBodyElement();
// go up to the parent
Element htmlElement = DOM.getParent(bodyElement);
// iterate over meta children
Element headElement = DOM.getFirstChild(htmlElement);
int count = DOM.getChildCount(headElement);
for (int i = 0; i < count; i++) {
Element nextChild = DOM.getChild(headElement, i);
if ("meta".equalsIgnoreCase(getElementTagName(nextChild))) {
String nameAttribute = DOM.getAttribute(nextChild, "name");
if ("gwt:property".equals(nameAttribute)) {
String contentAttribute = DOM.getAttribute(nextChild,
"content");
if (contentAttribute != null) {
int eqPos = contentAttribute.indexOf("=");
if (eqPos != -1) {
String name = contentAttribute.substring(0, eqPos);
gwtMetaProperties.put(name,
contentAttribute.substring(eqPos + 1));
}
}
}
}
}
}
return (String)gwtMetaProperties.get(propName);
}
/**
* Get the tag name of an element. I can't believe this isn't in the
DOM class.
*/
public static native String getElementTagName (Element element) /*-{
return element.tagName;
}-*/;
Speaking of that, why *isn't* there a DOM.getTagName(Element) method?
In any case, this works great :-) I can't even believe how fantastic
it is to see the serialized text of an Element in the Java debugger.
Feel free to drop this into the code if anyone has a spare moment.
Also, I was somewhat wrong about IDEA and current trunk. It's not
*always* slow. Sometimes it's quite fast. But other times it fails
to hit my very first entry point breakpoint at all, even if I wait for
over a minute. If I stop (not terminate, but stop) the hosted mode
browser, and then rerun it, it often (not always) works right away.
Seems like the connection to the native browser is somewhat flakier
under the IDEA debugger in r771 of the trunk.
I'll try to move future threads like this over to the users forum, so
as not to abuse the developer-ness here. In fact, when I post my
upcoming tour of the guts of this GWT-JSF integration, should it go on
the developers forum or the users forum? An argument could be made
for both... thoughts?
Cheers,
Rob
Rob Jellinghaus
> OK, how about this?
>
> /**
> * Private cached static map of meta gwt:property values, defined as
> * (meta name="gwt:property" content="propName=value").
> */
> private static Map gwtMetaProperties = null;
Oops, duh, there are going to be different properties on each page and
I'm not sure of the scope of a static map (is it guaranteed to be per-
module, in which case this is OK, or will it be across the whole
browser, in which case this is horribly, horribly wrong?). Will keep
an eye on that.
Cheers
Rob
Scott Blum
Rob Jellinghaus
> It should do what you want it to do. The static Map should remain valid
> exactly as long as the outer page remains the same.
Lovely!
Now how about that DOM.getTagName(Element) method? Isn't that a
glaring omission?
Cheers!
Rob
Rob Jellinghaus
I have got two examples: a simple example and a complex example. The
simple example is working great; I have gotten rid of gwt.js as you
suggested, loading the selection script directly, and it's all good.
One question about it, though: the selection script has this code:
doc.write('<iframe id="demo.gwt.HelloWidget" style="width:0;height:
0;border:0" src="' + base + strongName + '"></iframe>');
doc.write("<script>demo_gwt_HelloWidget.onInjectionDone('demo.gwt.HelloWidget')</
script>");
When I look at the DOM after this gets executed, I see, basically,
this:
<head>
...
<script src="/a4j-gwtKickStart/faces/gwt/demo.gwt.HelloWidget/
demo.gwt.HelloWidget.nocache.js" language="javascript"></script>
<script>
demo_gwt_HelloWidget.onInjectionDone('demo.gwt.HelloWidget')
</script>
</head>
<body>
<iframe id="demo.gwt.HelloWidget" src="http://localhost:8080/a4j-
gwtKickStart/faces/gwt/demo.gwt.HelloWidget/
62900469BADB886FB3448EDF317EA615.cache.html" style="border: 0pt none ;
width: 0pt; height: 0pt;">
...
</body>
The weird part of this is, of course, that the
doc.write('<iframe...>'); line actually seems to emit its <iframe> tag
into the body. Which is obviously where it should go, but I don't see
how doc.write magically gets it to be there. From the looks of the
code, the <iframe> should come BEFORE the onInjectionDone <script>.
But in the DOM, the onInjectionDone script is in the <head> (after the
selection script, as expected), but the <iframe> is in the <body>,
another element altogether.
This matters, because in my complex example, things are broken.
They're actually multiply broken. My first stab at it was with the
default selection script, as above. That hit this error in Firefox
web mode:
Object cannot be created in this context" code: "9
That error was caused by this line in computeScriptBase:
doc.write('<script id="__gwt_marker_demo.gwt.HelloWidget"></
script>');
Well, fine, I thought. I'll just make the G4JSF code emit a <script
id="__gwt_marker_js_demo.gwt.HelloWidget"/> tag, so computeScriptBase
doesn't have to generate its own marker. This actually worked, or at
least it made computeScriptBase work.
But now the doc.write('<iframe...>') line blows up, with that same
"Object cannot be created in this context" error.
I'm pretty sure it is because the GWT code is not the only Javascript
on the page. In fact, there is a bunch of Ajax4JSF code, which runs
first. And that code emits its own <script> tag, which happens to go
BETWEEN the <head> and the <body>:
<head>
<script type="text/javascript" src="/jboss-seam-booking/a4j.res/
org.ajax4jsf.framework.ajax.AjaxScript.seam">
..... BIG long script .....
</script>
...
<script type="text/javascript" language="javascript" src="/jboss-seam-
booking/faces/gwt/demo.gwt.HelloWidget/
demo.gwt.HelloWidget.nocache.js">
</script>
</head>
<script>
A4J.AJAX._scriptEvaluated=true;
</script>
<body>
...
</body>
So my questions are:
- Can you elucidate how the iframe doc.write lands in the body?
- Can you opine about whether this interposing <script> tag might be a
problem?
- What are the general causes of this "Object cannot be created in
this context" error in Firefox, and what are some of the general
workarounds? Any debugging tips?
If I don't hear from you, I will proceed (tomorrow, it's after 2 am
now):
- first trying to disable the Ajax4JSF in the page, so as to confirm
whether that's the trouble;
- second, mucking with SelectionScriptTemplate.js to see if I can
alter the doc.write behavior.
But I suspect this second path is mucking with fairly deep magic that
you worked on for quite a while (and that is probably fragile on
different browsers), so I'm nervous about doing it.
In general I would like these two frameworks (Ajax4JSF and GWT) to be
able to coexist on the same page, since it is definitely possible
(it's already working in IE with the code I've got!). I'm just hoping
that the necessary Firefox (et al.?!) tweaking isn't a back-breaking
straw for the SelectionScriptTemplate camel.
Thanks.
Cheers,
Rob
Scott Blum
This matters, because in my complex example, things are broken.
They're actually multiply broken. My first stab at it was with the
default selection script, as above. That hit this error in Firefox
web mode:
Object cannot be created in this context" code: "9
Got an example you can post?
I'm pretty sure it is because the GWT code is not the only Javascript
on the page. In fact, there is a bunch of Ajax4JSF code, which runs
first. And that code emits its own <script> tag, which happens to go
BETWEEN the <head> and the <body>:
That strikes me as pretty darn weird. Why is it doing that?
- Can you elucidate how the iframe doc.write lands in the body?
I think what's happening here is, it's illegal for an iframe to be in the head, so the browser is just putting down in the body where it belongs.
- Can you opine about whether this interposing <script> tag might be a
problem?
No clue, sorry. But it seems awfully squirrely.
- What are the general causes of this "Object cannot be created in
this context" error in Firefox, and what are some of the general
workarounds? Any debugging tips?
Unfortunately, no.. never run up against this one. Maybe Joel can shed more light.
If I don't hear from you, I will proceed (tomorrow, it's after 2 am
now):
- first trying to disable the Ajax4JSF in the page, so as to confirm
whether that's the trouble;
- second, mucking with SelectionScriptTemplate.js to see if I can
alter the doc.write behavior.
Before any of that, can you try moving the GWT script tag down into the body?
Hopefully Joel will know more...
Scott
Rob Jellinghaus
> Wow, Rob.. you've certainly run up against some weird cases we haven't seen
> yet.
Both you and the Ajax4JSF guys say that :-) That's the trouble with
new integration projects, weirdness always reveals itself....
> > Object cannot be created in this context" code: "9
>
> Got an example you can post?
http://unrealities.com/gwtjsf/20070406 has examples a-plenty,
including two war files (one which totally works, one which
demonstrates this bug), full source, and instructions. If you or Joel
have a couple of minutes to try 'em out, it would be transcendentally
fantastic.
> > In fact, there is a bunch of Ajax4JSF code, which runs
> > first. And that code emits its own <script> tag, which happens to go
> > BETWEEN the <head> and the <body>:
>
> That strikes me as pretty darn weird. Why is it doing that?
Well, the basic purpose seems clear. It's emitting the following
script:
<script>
A4J.AJAX._scriptEvaluated=true;
</script>
Which serves an analogous purpose to your onInjectionDone script in
GWT, I would imagine. As to why the script tag ends up where it does,
I don't yet know, but I will dig through the Ajax4JSF script to see
exactly how it's injecting it.
> > What are the general causes of this "Object cannot be created in
> > this context" error in Firefox, and what are some of the general
> > workarounds? Any debugging tips?
>
> Unfortunately, no.. never run up against this one. Maybe Joel can shed more
> light.
Help me, Obi-Joel, you're my only hope! :-) (Though it looks like
Joel has a bunch of reviews stacked up, which are higher priority than
this....) I will also Google the hell out of this error momentarily.
> Before any of that, can you try moving the GWT script tag down into the
> body?
That's just the kind of great idea that you can never think of at 2
am. Unfortunately, I did so, and it didn't help; still getting that
error on the doc.write('<iframe...>'), which is very surprising. The
example apps above have this version of the code in them.
Thanks very much anyone who can help,
Cheers!
Rob
Rob Jellinghaus
> > > In fact, there is a bunch of Ajax4JSF code, which runs
> > > first. And that code emits its own <script> tag, which happens to go
> > > BETWEEN the <head> and the <body>:
>
> > That strikes me as pretty darn weird. Why is it doing that?
>
OK, so now I'm REALLY puzzled. I chopped out all the Ajax4JSF stuff
from the page. The Ajax4JSF script now isn't loaded or run at all.
BUT I'M STILL GETTING THIS CODE 9 ERROR FROM FIREFOX.
I've updated my page with the version of the app that has no Ajax4JSF
stuff in it:
http://unrealities.com/gwtjsf/20070406
Now it's pretty clear that this really is a GWT-specific problem. I
have no idea why I'm encountering it on this page -- at this point the
two demo applications seem to be pretty much equivalent (they load the
same module code, in the same way, with the same HTML structure).
This Firefox error is an utter puzzle as of now.
Joel? Any connections on the Firefox team who might know what this
error is about?
Thanks VERY much,
Rob
Rob Jellinghaus
> OK, so now I'm REALLY puzzled. I chopped out all the Ajax4JSF stuff
> from the page. The Ajax4JSF script now isn't loaded or run at all.
>
> BUT I'M STILL GETTING THIS CODE 9 ERROR FROM FIREFOX.
>
> I've updated my page with the version of the app that has no Ajax4JSF
> stuff in it:
>
> http://unrealities.com/gwtjsf/20070406
Google (surprise!) is helping a bit.
Evidently it may be related to .xhtml extensions on the page being
rendered?!? :-P Seems ridiculous, but since I'm using Facelets as my
server-side view layer, it's going to be a bit tricky to muck around
with the page extensions to see if that helps.
This is a report of a very similar bug with <script> tag injection, in
a Ruby on Rails context, from Nov 2005:
http://wrath.rubyonrails.org/pipermail/rails-spinoffs/2005-November/001293.html
This reports the full exception code as: [Exception... "Object cannot
be created in this context" code: "9" nsresult: "0x80530009
(NS_ERROR_DOM_NOT_SUPPORTED_ERR)"]
Here's someone reporting the bug in a similar context with a stat
counter:
http://forum.statcounter.com/vb/archive/index.php/t-17068.html
That person points to an old-school Mark Pilgrim article (he's a
Googler now, I believe, isn't he?) which claims that document.write is
not supported at all for XHTML content!
http://www.xml.com/pub/a/2003/03/19/dive-into-xml.html
I have a hard time believing this, but if it's true, aren't the
implications for GWT profound? Or should the recommendation just be,
don't serve your pages as XHTML with GWT? That will pretty much
torpedo my integration endeavor....
I'm actually starting to believe that this is the root problem,
because it turns out that Ajax4JSF -- which clearly has no problems
inserting its <script> tags into an XHTML page in Firefox -- uses
Sarissa (http://sarissa.sourceforge.net) to do pretty much exactly
what Pilgrim says you have to do when inserting elements into an XHTML
document. Here's how Ajax4JSF inserts its
<script>A4J.AJAX._scriptEvaluated=true;</script> element (taken from
AJAX.js inside ajax4jsf.jar from Seam 1.2.0):
// AJAX-JSF AJAX-like library, for communicate with view Tree on
server side.
// Modified by Alexander J. Smirnov to use as JSF AJAX-like
components.
if (!window.A4J) { window.A4J= {};}
A4J.AJAX = {};
// Test for re-evaluate Scripts in updated part. Opera do it.
A4J.AJAX._scriptEvaluated=false;
try{
// Simulate same calls as on XmlHttp
var oDomDoc = Sarissa.getDomDocument();
var xmlString = "<html xmlns='http://www.w3.org/1999/
xhtml'><sc"+"ript>A4J.AJAX._scriptEvaluated=true;</scr"+"ipt></html>";
oDomDoc = (new DOMParser()).parseFromString(xmlString, "text/xml");
var _script=document.importNode(oDomDoc.getElementsByTagName("script")
[0],true);
document.documentElement.appendChild(_script);
} catch(e){ /* Mozilla in XHTML mode not have innerHTML */ };
So, it looks like Ajax4JSF -- which is coded specifically to work with
Facelets and JSF, both of which render everything as XHTML -- *does
not use document.write at all*.
Yikes!
Thoughts?
Cheers,
Rob
Rob Jellinghaus
http://www.w3.org/MarkUp/2004/xhtml-faq#docwrite
"Does document.write work in XHTML?
No. Because of the way XML is defined, it is not possible to do tricks
like this, where markup is generated by scripting while the parser is
still parsing the markup.
You can still achieve the same effects, but you have to do it by using
the DOM to add and delete elements."
It looks like there's even a JIRA issue already:
http://code.google.com/p/google-web-toolkit/issues/detail?id=710&can=2&q=XHTML
-- I will add a link to this thread for more details.
Based on current evidence, this issue will become much more severe
with GWT 1.4; if you don't serve as text/html, your GWT app won't work
*at all*.
So. Is GWT intended to be XHTML compliant? It looks like only
Firefox actually accepts application:xhtml+xml and hence only Firefox
users will get xhtml+xml delivered to them. But it's a moderately
important question standards-wise as to whether GWT is intended to be
XHTML compliant.
This is indeed fairly critical for my use case of integrating GWT with
JSF + Facelets, which is an XHTML-based server-side view system.
Cheers!
Rob
Kelly Norton
As I understand things, document.write should work just fine in documents that declare themselves XHTML via doctype, but the problem comes in when you try to enable page parsing with the xml parser (you send content-type: application/xhtml+xml). So really the issue is about being able to send your content with application/xhtml+xml. Is that correct?
Let me also play devil's advocate for a minute and say, I personally don't consider GWT support for application/xhtml+xml to be critical for a couple of reasons:
1) It increases the divide between the browsers with pretty much no benefit. What does the fact that mozilla is parsing the document as xml do for users?
2) Mozilla even recommends not sending application/xhml+xml unless you are using MathML in your document (that was the reason that mozilla reports it in the accept header). The reason they don't recommend it is that incremental rendering of content parsed with the XML parser will not be available until FF3. So sending xhtml+xml content actually decreases user experience. (and that's even if you don't accidentally send malformed content and show the user an XML error).
http://www.mozilla.org/docs/web-developer/faq.html#accept
Anyway, I wanted to throw out a counter opinion. I'm actually all for web standards but not if it negatively impacts users. Eventually all the wrinkles for sending application/xhtml+xml will be ironed out, but personally, I don't think we're there yet.
/kel
Rob Jellinghaus
> As I understand things, document.write should work just fine in documents
> that declare themselves XHTML via doctype, but the problem comes in when you
> try to enable page parsing with the xml parser (you send content-type:
> application/xhtml+xml). So really the issue is about being able to send your
> content with application/xhtml+xml. Is that correct?
Yes, although it turns out that in my particular case, declaring the
document as XHTML via doctype seems to force JSF / Facelets to send
the document with content-type application/xhtml+xml. There is a
Facelets override for content-type, but if I have an XHTML DOCTYPE, it
ignores the override. Thankfully, removing the DOCTYPE lets the
Facelets override work, so now I'm all good.
> Let me also play devil's advocate for a minute and say, I personally don't
> consider GWT support for application/xhtml+xml to be critical for a couple
> of reasons...
Your reasons are fine with me (especially now that I have a
workaround ;-). My only comment in issue 710 was that this should be
better documented. The fact that Scott was totally unaware of this
issue (Scott!) indicates that there is potential for people to be
seriously tripped up by it. It's not hard to figure out if you Google
for the error (obviously, since I figured it out and I'm a relative
newbie), but since it's so serious and so relatively easy to inflict
on yourself, it should be included in the 1.4 release notes.
Cheers!
Rob
Rob Jellinghaus
and XHTML compliance becomes reasonably compelling), is that Sarissa /
Ajax4JSF provide solid precedent that just about everything GWT does
can also be done in an XHTML-compliant way. So if and when there is
perceived user benefit (or developer benefit), it looks like it is at
least *possible* for GWT to be compliant.
Cheers!
Rob
Scott Blum
Your reasons are fine with me (especially now that I have a
workaround ;-). My only comment in issue 710 was that this should be
better documented. The fact that Scott was totally unaware of this
issue (Scott!) indicates that there is potential for people to be
seriously tripped up by it.
Hah hah, I'm just the compiler dude and hardly know HTML from a hole in the ground. Joel and Kelly are the guys with PhDs in Browser Quirks. :)
Scott
Joel Webber
More seriously, I am most definitely the 'chose to use document.write() to implement the bootstrap sequence' guy, and I definitely didn't realize that this wouldn't work in Mozilla's XHTML+XML context. However, the code above leads me to believe that XHTML mode won't even support element.innerHTML! If that's true, it would be exceedingly awkward to get anything useful done.
joel.
joel.
Rob Jellinghaus
> Actually, I've put my browser quirks dissertation on hold indefinitely, and
> have very little probability of ever getting my degree...
Shyeah right! You're working on GWT. That counts as SERIOUS browser
quirks research.
> More seriously, I am most definitely the 'chose to use document.write() to
> implement the bootstrap sequence' guy, and I definitely didn't realize that
> this wouldn't work in Mozilla's XHTML+XML context. However, the code above
> leads me to believe that XHTML mode won't even support element.innerHTML! If
> that's true, it would be exceedingly awkward to get anything useful done.
I don't know the details on element.innerHTML, but I do know that
Ajax4JSF seems to be able to do essentially everything it wants to do
(which is quite a lot; they've got a big widget set) in Moz/XHTML
+XML. I think the innerHTML comment is really a "catch and ignore the
irrelevant exception" kind of thing, not a total deal-breaker. (I
reserve the right to be utterly wrong.)
The Ajax4JSF project is open source at http://labs.jboss.com/portal/jbossajax4jsf/?prjlist=false
if you want to check their source out, at such time as XHTML
compliance becomes a GWT goal.
Cheers!
Rob
Joel Webber
I do want to say one thing about XHTML support. It seems to me that there are really two levels at which we can support XHTML:
1. Supporting XHTML strict doctypes, and the various (un?)quirks this brings up.
2. Supporting XHTML+XML.
The former of these is definitely a near-term goal, and very achievable. We have a few bugs in 'standards' rendering mode that we plan to fix 'real soon'.
The latter is a bit more ambitious, and I'd prefer to wait a bit and see where this goes ( i.e. any other browsers adopting it, better performance, etc) before explicitly working to support it. If it does turn out to be widely needed, I'm certain we (along with all the other Ajax frameworks) will do what it takes to support it.
joel.
Rob Jellinghaus
> Thanks for the pointers, Rob. I'll definitely look into this.
Glad it's helpful.
> I do want to say one thing about XHTML support. It seems to me that there
> are really two levels at which we can support XHTML:
> 1. Supporting XHTML strict doctypes, and the various (un?)quirks this brings
> up.
> 2. Supporting XHTML+XML.
>
> The former of these is definitely a near-term goal, and very achievable. We
> have a few bugs in 'standards' rendering mode that we plan to fix 'real
> soon'.
>
> The latter is a bit more ambitious, and I'd prefer to wait a bit and see
> where this goes (i.e. any other browsers adopting it, better performance,
> etc) before explicitly working to support it.
That's all fine with me. I'll just reiterate that in my experience,
with the Seam / JSF / Facelets stack I'm using, putting an XHTML
strict doctype in my page *forces* the server stack to use the
application/xhtml+xml content-type, even if I try to override it.
So you may find that supporting the strict XHTML doctype inadvertently
increases the frequency with which various server stacks will emit
application/xhtml+xml content-type to Firefox and other browsers that
accept it. This will break GWT. In other words, better support for
#1 may cause greater exposure to (postponed) #2. Documentation will
be your friend!
Cheers,
Rob
Kelly Norton
/kel
Joel Webber
That's all fine with me. I'll just reiterate that in my experience,
with the Seam / JSF / Facelets stack I'm using, putting an XHTML
strict doctype in my page *forces* the server stack to use the
application/xhtml+xml content-type, even if I try to override it.
So you may find that supporting the strict XHTML doctype inadvertently
increases the frequency with which various server stacks will emit
application/xhtml+xml content-type to Firefox and other browsers that
accept it. This will break GWT. In other words, better support for
#1 may cause greater exposure to (postponed) #2. Documentation will
be your friend!
Rob Jellinghaus
> Very good point. Is there already an issue for this? If not, I'd really
> appreciate it if you could create one. Maybe we could even do something more
> helpful than just doc, by putting a try/catch in the startup script and
> warning the user of what the likely problem is. That way you'll hopefully be
> one of the last people to have to debug this mess :)
Sounds good :-) There is already an issue, linked about halfway back
up the thread -- issue #710. That issue is really about GWT not being
fully XHTML-compliant.
I added a comment to #710 with your "helpful exception message"
suggestion; if you want that to be a separate issue (leaving #710 to
represent "full compliance"), I'll leave it to you.
Cheers!
Rob