You are viewing a plain text version of this content. The canonical link for it is here.
Posted to xap-dev@incubator.apache.org by Michael Turyn <MT...@nexaweb.com> on 2006/11/07 18:12:29 UTC
A change to MCO declarations
A Xal file's mco declarations now can take a "path" attribute in order
to specify source-code for the constructor indicated in 'src', e.g.:
<mco:mco
xmlns:mco="http://www.openxal.org/mco
<http://www.openxal.org/mco> "
id="attributeSetter"
src="AttributeTesterAlias"
path="../widgets/AttributeTester.js"
/>
Why?: It's better that xal pages and even tags be as self-contained as
possible, and in particular a tag that points to an object should be
able to find its definition. This is good in and of itself (for
example, cutting and pasting from an old file into a new one), and
because eventually I'd like to see a simple servlet page that will take
a xal uri as an argument, and embed the xal in an otherwise blank page:
[...]
out.println("<body onload="Xap.createEmbeddedApplications();">") ;
out.println("<div startPage=\"" + request.getParameter("startPage")
+"\"") ;
if(request.getParameter("applicationName") != null
&& request.getParameter("applicationName").length()>0){
out.println(" applicationName=\"" +
request.getParameter("applicationName") +"\"") ;
}
// Any other Xap parameters?:
[...] ;
out.println(">") ;
[...]
(And, of course, the server could be set to do this embedding
automatically for .xal URIs.)
When?:
If the mco "src" doesn't resolve to a valid constructor, we look for a
"path" attribute for the MCO, and if one's found, load from the URI
indicated there (usual restrictions on XmlHttpRequests in mozilla
apply). (We do this in this order so that we don't make too many
requests---we might want to change that behaviour if we should want the
mco to point to dynamic content from a servlet or server page, perhaps
via an "updatable" attribute.)
How?:
A few more blocks of code in McoNamespaceHandler.
RE: A change to MCO declarations
Posted by Michael Turyn <MT...@nexaweb.com>.
James Margaris writes:
>Sounds good, question:
>
>If I have this:
>
><mco src="com.myCompany.myMco"/>
>
>What happens? We will try to make a new com.myCompany.myMco, that that
doesn't exist will we do a require() on it? To me >that would make the
most sense.
>
>1. IF there is a path, load from that path 2. If there isn't, try a
require on the src
That's the order now. I didn't include a note about the require()
because there seems to be problem with
the paths resolution, or else I put the file in the wrong place. This
wll take future work, but I left
the Xap.require() call is in there as a placeholder.
On paths resolution: I would suggest that the developer be able to alter
and add to the default paths currently set in Xap.js with entries in
XapConfig. Currently, we have
dojo.hostenv.setModulePrefix("dojo", "../dojo/src");
dojo.hostenv.setModulePrefix("xap", "../xap");
dojo.hostenv.setModulePrefix("google", "../google");
...but this ties users to the current directory structure as staged.
A user _could_ alter these or add to them within an html file's
<script/> tag, but that's awkward; I would like to see something like:
<module-maps>
<module-map module-prefix="dojo" module-path="../dojo/src" />
<module-map module-prefix="xap" module-path="../xap" />
<module-map module-prefix="google" module-path="../google" />
<!-- New one -->
<module-map module-prefix="mymcos" module-path="../add_ons/mcos"
/>
</module-maps>
RE: A change to MCO declarations
Posted by James Margaris <jm...@nexaweb.com>.
Sounds good, question:
If I have this:
<mco src="com.myCompany.myMco"/>
What happens? We will try to make a new com.myCompany.myMco, that that
doesn't exist will we do a require() on it? To me that would make the
most sense.
1. IF there is a path, load from that path
2. If there isn't, try a require on the src
James Margaris
-----Original Message-----
From: Michael Turyn [mailto:MTuryn@nexaweb.com]
Sent: Tuesday, November 07, 2006 1:12 PM
To: xap-dev@incubator.apache.org
Subject: A change to MCO declarations
A Xal file's mco declarations now can take a "path" attribute in order
to specify source-code for the constructor indicated in 'src', e.g.:
<mco:mco
xmlns:mco="http://www.openxal.org/mco
<http://www.openxal.org/mco> "
id="attributeSetter"
src="AttributeTesterAlias"
path="../widgets/AttributeTester.js"
/>
Why?: It's better that xal pages and even tags be as self-contained as
possible, and in particular a tag that points to an object should be
able to find its definition. This is good in and of itself (for
example, cutting and pasting from an old file into a new one), and
because eventually I'd like to see a simple servlet page that will take
a xal uri as an argument, and embed the xal in an otherwise blank page:
[...]
out.println("<body onload="Xap.createEmbeddedApplications();">") ;
out.println("<div startPage=\"" + request.getParameter("startPage")
+"\"") ;
if(request.getParameter("applicationName") != null
&& request.getParameter("applicationName").length()>0){
out.println(" applicationName=\"" +
request.getParameter("applicationName") +"\"") ;
}
// Any other Xap parameters?:
[...] ;
out.println(">") ;
[...]
(And, of course, the server could be set to do this embedding
automatically for .xal URIs.)
When?:
If the mco "src" doesn't resolve to a valid constructor, we look for a
"path" attribute for the MCO, and if one's found, load from the URI
indicated there (usual restrictions on XmlHttpRequests in mozilla
apply). (We do this in this order so that we don't make too many
requests---we might want to change that behaviour if we should want the
mco to point to dynamic content from a servlet or server page, perhaps
via an "updatable" attribute.)
How?:
A few more blocks of code in McoNamespaceHandler.