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 probably >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 >application. > 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="http://www.w3.org/1999/xhtml";> <head> <script language="JavaScript" type="text/JavaScript" src="../../src/xap/Xap.js"></script> <script language="JavaScript" type="text/JavaScript"> Xap.bootstrap( "../../" ); function launch() { Xap.createSession( "xap-container" ); } </script> </head> <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> </body> </html> >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 one >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 file >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. >
