incubator-xap-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Coach Wei" <>
Subject RE: Next steps
Date Tue, 27 Jun 2006 15:55:42 GMT
All the six items identified make sense.
Some more specific thoughts below:

---Coach Wei

James Margaris wrote on Monday, June 26, 2006 2:08 PM:
>1. Identify UI framework we are going to be using.
>	We can mix and match but we will most likely end with one as our
>default. Now that Kabuki is no longer an Apache project Dojo is
>the way to go. (?)

[Coach Wei:] I definitely think Dojo is the toolkit to use, in
particular for the followings:
1. Dojo packaging and loading (for XAP bootstrap);
2. Dojo internationalization (contributed by IBM. Adam Peller showed me
a demo and it looked very nice);
3. Dojo UI components 

The additional components from Dojo that I think fairly highly of and
can be very valuable to XAP in the future are:
1. Dojo storage
2. Dojo charting/graphing (still in early development, Dylan Schiemann
made some fairly good decisions in terms of how to approach it);

>2: Identify the minimal things you need to do to create a XAP
>	The way our application is launched is a bit of a mess right
>now, really just placeholder functionality.

[Coach Wei:] About XAP application launching:
1. Right now XAP assumes its XML code resides in separate files, which
is definitely one use case. There is another scenario that needs to be
taken into consideration of: embeddening XML code inside HTML page. 

The following is an example hypothetically:

<html xmlns="">  
<script language="JavaScript" type="text/JavaScript"
 <script language="JavaScript" type="text/JavaScript">
        Xap.bootstrap( "../../" );
       function launch() {  Xap.createSession( "xap-container" ); }
<body onload="launch();"> 
<p>A simple tree using XAP in XHTML.</p>
    <div id="xap-container">
    <some XAP XML CODE HERE>
   </div><p>Another Paragraph.</p> 

>3: Code size/loading issues.
>	We've already been discussing this to some degree, I think the
>general approach we agree on is to compress files and glom them into
>large JS file using the Dojo mechanism or equivalent.

[Coach Wei:] Enabling a minimum bootstrap profile would be great. For
example, the minimum amount of code needed for bootstrapping Dojo is
15KB, requiring combining only 4 files into dojo.js(bootstrap1.js,
bootstrap2.js, hostenv_browser.js, and loader.js). Based on this minimum
profile, people can optionally add additional files for additional
functionality that they want to load at bootstrap time. Such a modular
design would make XAP very pluggable in different situations. 

>4: Specifying i18n (internationalization) information.
>	Dojo has a way to do this essentially based on Java resource
>bundle loading.
>5: Specifying configuration information, properties files, etc.
>	One question here is that for configuration information that is
>needed for a XAP app should that config info be XML, a text format,
>javascript, etc. Running javascript would have the advantage this it
>would be fastest (most likely) and could be glommed into the big JS
>as part of the build process. However that does not lend itself well to
>editing by end-users or to tools support. xap.taghandlers contains a
>plugin.xml file that defines a mapping of tags/namespaces to bridge
>classes if people want to look at that.

[Coach Wei:] I'd suggest the configuration file to be XML based for easy
editing and tool integration; Further, this XML file should be loaded by
XAP engine when the application bootstraps. In the future, I can see
this XML file being translated into a JSON file that would enable easier
processing, but starting from XML is a good option. 
>6: Figure out naming scheme for classes/files.
>	The agreement here seems to be a package naming system with
>"xap" as the root.

View raw message