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 James Margaris <jm...@nexaweb.com> on 2006/06/26 18:08:08 UTC

Next steps

I had some ideas for the order we should approach things in. Mostly
these are organizational issues, getting the proper foundation in place.

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. (?)

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. 

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.

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.

6: Figure out naming scheme for classes/files.
	The agreement here seems to be a package naming system with
"xap" as the root.

Of course this is all my opinion only. Thoughts?

James Margaris