Opened 12 years ago

Closed 8 years ago

#4925 closed defect (fixed)

Dojo and XML-XSL-Transformation problems with FF

Reported by: guest Owned by: anonymous
Priority: high Milestone: 1.7
Component: Core Version: 0.9
Keywords: Cc:
Blocked By: Blocking:

Description (last modified by bill)

As per z320's initial post:

I've tried to use the dojo components with XML-XSL-Transformation. With IE 6 and 7 it runs but with the Firefox 2 (Version 2.0.0.6) and 3 (Gran Paradiso) the dojo-parser ignores all the 'dojoType="..."'-elements. It seems to be the problem that the Firefox browser converts all tags into LOWERCASE because of XHTML compatibility. The dojo-parser searches for the attribute named 'dojoType' but will never find it because it's new name is 'dojotype' after FF finished it's work (the transformation). IE ignores this aspect of XHTML standard and that's why it runs without problems. I stumbled over the following two messages when I searched for a solutions.

Mozilla: Firefox:3.0 DOM Case Sensitivity Firefox:3.0 DOM Case Sensitivity

W3C - XHTML 1.0 The Extensible HyperText? Markup Language (Second Edition) Element and attribute names must be in lower case

best regards from germany

Attachments (1)

editor-fontName.png (12.9 KB) - added by Inarus 8 years ago.
fontName plugin open in xhtml mode, displays fine (except for that already noted in bug #13730)

Download all attachments as: .zip

Change History (14)

comment:1 Changed 12 years ago by dylan

Milestone: 1.3

comment:2 Changed 11 years ago by bill

Component: GeneralCore
Description: modified (diff)
Milestone: 1.31.5

I think this is really a ticket about dojo.query() not working in XHTML mode.

comment:3 Changed 9 years ago by Adam Peller

Milestone: 1.5tbd

comment:4 Changed 9 years ago by James Burke

Resolution: invalid
Status: newclosed

This ticket is 3 years old, not sure if it is still valid -- feel free to reopen with a test case.

comment:5 Changed 8 years ago by Inarus

Resolution: invalid
Status: closedreopened

This bug still applies, I hope this is the right place to post this.

The fix for this is relatively straight forward now we have data-dojo, simply migrate all internal javascript widgets to use the data-dojo- format, that is to say, change all dojoType, dojoAttachPoint and dojoAttachEvent (case insensitive as I have found both dojoAttachPoint and dojoattachpoint for example in dijit.layout.ScrollingTabController?) to data-dojo-type, data-dojo-attach-point and data-dojo-attach-event respectively (case sensitive).

Example test case:

<div data-dojo-type="dijit.layout.TabContainer" style="width: 100%; height: 500px;" data-dojo-props='doLayout: false'>
   <div data-dojo-type="dijit.layout.ContentPane" data-dojo-props='title:"My First Tab", selected:true'>
   </div>
   <div data-dojo-type="dijit.layout.ContentPane" data-dojo-props='title:"My Second Tab"'>
   </div>
</div>

Running in full xhtml mode (mime type set correctly). Without migrating the internals I get javascript errors about a null node and so the widgets are never made.

comment:6 Changed 8 years ago by bill

I could change this, although there are >8000 "dojoType" references in the current code base (probably most in test files). About 800 dojoAttachPoint and 200 dojoAttachEvent's...

comment:7 Changed 8 years ago by Inarus

Ahh, I didn't realise there were so many. Though I am assuming the test files don't need to be changed. As the test files should be testing both the legacy and the new syntax.

Just to be clear, the changes that I refer to, reside purely in the template files. I believe a bash script could perform this task relatively quickly.

I would happily write one, though I am not set up yet for contributing code, I should really do that. If you would like me to write the script then let me know.

comment:8 Changed 8 years ago by bill

Thanks, no need write a script, I can do it, or more easily just do a global search/replace from my IDE. You are right that the test files don't need to be changed currently, although they need to be updated for the 2.0 release so might as well do it now.

As for legacy testing, that should be part of the parser and _TemplatedMixin test files.

comment:9 Changed 8 years ago by bill

Seems like this also involves converting parameters to data-dojo-props format, for example in the FontChoice plugin:

templateString:
	"<span style='white-space: nowrap' class='dijit dijitReset dijitInline'>" +
		"<label class='dijitLeft dijitInline' for='${selectId}'>${label}</label>" +
		"<input dojoType='dijit.form.FilteringSelect' required='false' 
labelType='html' labelAttr='label' searchAttr='name' " +
				"tabIndex='-1' id='${selectId}'
dojoAttachPoint='select' value=''/>" +
	"</span>",

It seems likely that if you are having problems with dojoType you'd also have problems with labelType, labelAttr, searchAttr, etc. Do you? (I haven't tried it.)

comment:10 Changed 8 years ago by bill

In [26324]:

Use data-dojo-type / data-dojo-props in dijit templates (with widgets in the templates), refs #11490, #4925 !strict.

comment:11 Changed 8 years ago by Inarus

With myself, I have not experienced a problem with dojoType per se. For me, where I suspected the javascript error (and thus seeing no dojo widgets) arose from was dojoAttachPoint.

The way I saw it, giving my example testcase above, was that in specifying a TabContainer?, dojo's internals then generates lots of other dojo widgets like tabs right click menus (to close a tab) etc. This generated content will be using dojoAttachPoint so when the javascript tries to access it, it will get a null domNode. Obviously dojoType also needed to be changed to push the widgit into html5 mode to use the extra options.

I don't see anything wrong with the fontName plugin (I will post a screenshot). Though personally I say update everything to valid (x)html5 syntax i.e. lowercase tag and element names using data- for extra attributes, then nothing can go wrong; we get the added bonus of browser speed of their dom parsers; and can rule this out as a cause for future bugs.

Coincidently I am seeing that filtering selects are initialising to empty, though I am hoping that these changes might fix it. Let me know when all the changes are committed and I will retest!

Changed 8 years ago by Inarus

Attachment: editor-fontName.png added

fontName plugin open in xhtml mode, displays fine (except for that already noted in bug #13730)

comment:12 Changed 8 years ago by bill

In [26331]:

Use data-dojo-attach-point / data-dojo-attach-event in dijit templates, refs #11490, #4925 !strict.

comment:13 Changed 8 years ago by bill

Milestone: tbd1.7
Resolution: fixed
Status: reopenedclosed

OK, so sounds like it's a problem with widgets in templates. I think this problem could be fixed by modifying the code in _WidgetsInTemplateMixin from:

this._attachTemplateNodes(cw, function(n,p){
	return n[p];
});

to

this._attachTemplateNodes(cw, function(n,p){
	return n[p] || n[p.toLowerCase()];
});

but I didn't change it since I didn't test it.

Anyway, I've updated the templates in dijit to 2.0 syntax. I'm not going to do the templates in dojox since there are too many of them, and too hard to test, but they will get updated on/before the 2.0 release since 2.0 won't support the old dojoAttachPoint syntax.

So I'm going to mark this as "fixed" although if you are having problems with dojox widgets then test my change above and if that fixes it, I'll add that too.

Note: See TracTickets for help on using tickets.