Opened 14 years ago
Closed 14 years ago
#5686 closed enhancement (fixed)
support ioArgs argument to ContentPane
Reported by: | ptwobrussell | Owned by: | bill |
---|---|---|---|
Priority: | low | Milestone: | 1.3 |
Component: | Dijit | Version: | 1.0 |
Keywords: | Cc: | Adam Peller, bill | |
Blocked By: | Blocking: |
Description (last modified by )
While digging into ContentPane? (as of r12172), I noticed the following lines in _downloadExternalContent:
if(dojo.isObject(this.ioArgs)){ dojo.mixin(getArgs, this.ioArgs); }
Well, as it turns out, ioArgs
is not defined in this widget, or any that it inherits from. So, if you try to include ioArgs
when creating it, it has no effect. For example:
div preload="true" ioArgs="{handleAs:'javascript'}" dojoType="dijit.layout.ContentPane" href="./bar">
does not treat the returned content from href
as javascript. Instead it treats it as text
, the default for handleAs
via ioArgs
.
Seems to me that the fix is trivial: define ioArgs as a member and then in constructor
actually create it, (because defining it inline since it would be treated as a static since ioArgs
is an object).
I marked this as high priority for 1.1, because it seems very important and the fix is trivial. (I checked the logs and this "problem" has existed forever it seems--making me wonder if I'm missing something here since this hasn't been reported yet.)
In case you're wondering, my working assumption for the use case is that it would be really nice to use a ContentPane? to have the server return back an arbitrary dijit that was not originally dojo.required into the parent document. e.g. getting JavaScript? back from the ContentPane? that would dojo.require in the dijit, construct it, and append it to somewhere in the page at will (preferably the ContentPane? itself, I guess).
Change History (9)
comment:1 Changed 14 years ago by
Milestone: | 1.0.3 → 1.1 |
---|
comment:2 Changed 14 years ago by
Description: | modified (diff) |
---|
comment:3 Changed 14 years ago by
Milestone: | 1.1 → 2.0 |
---|---|
Priority: | high → low |
Summary: | Cannot pass ioArgs into ContentPane → support ioArgs argument to ContentPane |
Type: | defect → enhancement |
Hmm, ContentPane is only meant to support text in a href so this isn't a bug but rather an enhancement request, and I'm not sure how important it is given that in theory you could just wrap your text from the server in a <script> tag, and use dojox.layout.ContentPane? with evalScripts=true option.
Basically, this is beyond what I intend dijit.layout.ContentPane? to support, but will consider for 2.0.
comment:4 Changed 14 years ago by
Owner: | set to mumme |
---|
comment:6 Changed 14 years ago by
Owner: | changed from mumme to Sam Foster |
---|
Sam can you take a look at these? Hopefully these are fixed by your refactor or you can fix them
comment:7 Changed 14 years ago by
Description: | modified (diff) |
---|---|
Owner: | changed from Sam Foster to bill |
comment:8 Changed 14 years ago by
Status: | new → assigned |
---|
OK, I guess this ticket has nothing in particular to do with handleAs... could be setting timeout etc.
I'll fix as you suggested... note though that this.ioArgs={};
in the constructor is not necessary, since when the parser sets ioArgs it will do this.ioArgs = { ... };
, defining a new Object private to the instance, rather than mucking w/the existing shared object.
comment:9 Changed 14 years ago by
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
(In [15958]) Fixes #5686: support ioArgs argument to ContentPane? declared via markup. ioArgs argument to ContentPane? was already supported for programatic creation. !strict
I just noticed a weird-ism when experimenting with JavaScript? that is returned from the server: It appears that document.body refers to the ContentPane? versus the entire document's body. For example, if the script returned from the server via
bar
(see example above) isthen the
<div>foobar</div>
gets appended *into* the ContentPane? instead of after it. I can't see how that would be expected, but wanted to follow up and note it so someone could confirm/deny/explain.