XMLBeans Practice--Automate Exchanging data between XML's & Java (1)

Installation of XMLBEANS
I hope this section can help solve your problems, if not all, encountered when installing XMLBEANS. XMLBEANS installation is hard to deal with and I think most of people will encounter problems when installing it and I'm not an exception.
The XMLBEANS(here it's 2.0.0-beta1) binary archive package, by convention, contains directories, bin, docs, lib, etc. And you'll have to set your path and classpath just like installing other java tools. But after that I think 90% people can't run XMLBEANS correctly. There're some points to notice and I hope your encountering problems are listed below (OS:WIN XP SP2) :

• About your jdk directory. My jdk directory is under the "Program Files" directory. And when I run XMLBEANS with "scomp...." in the command line prompt, errors saying roughly like this(on my PC erro message is in Chinese): "'E:\program' is not a internal or external command, neither is it a executable or a batch file." This error message reminded me of the caution information I read when I was installing Weblogic 8.1. The information said "Don't leave a white space in your weblogic path, for it may cause severe problems". Since both of XMLBEANS and Weblogic are produced by BEA. So I move my "JAVA_HOME" to the root directory of one of my partition.
• About your "PATH". When I thought I would make it. The fact again let me down. When I run "scomp...", XMLBEANS threw IOException saying "'javac' is required on the path.java.io.IOException : CreateProcess: c:\xmlbeans-1.0.2\schemas\javac @c:\DOCUME~1\alex\LOCALS~1\Temp\javac20992 error=2nulljava.io.IOException: CreateProcess: c:\xmlbeans-1.0.2\schemas\javac @c:\DOCUME~1\alex\LOCALS~1\Temp\javac20992 error=2 ", something like this. And this time I checked FAQ at here .I followed its advice but I couldn't find JAVA_HOME in my scomp script(in the bin folder). I think it's for old version of XMLBEANS and the information was not timely refreshed. And another piece of information solved my problem. There is a precedence among your JRE and JDK when java program finds java path. The former would be first located by default. So I put my JDK directory at the left most of my PATH variable.
• About your "XMLBEANS_LIB". The official installation guide doesn't mention this. I found it in the scomp script. So I add a new environment variable called XMLBEANS_LIB pointing to my lib folder.

After the three steps I'm processing my XML Schema files with XMLBEANS. In addition, I wonder why BEA don't make it easier to install it just as install other java tools. Do they want to test our patience of using their tools?

Coming soon: XMLBeans Practice--Automate Exchanging data between XML's & Java (2): Working With XMLBeans

The origin of foo & bar which almost everywhere in the demonstrating codes

The etymology of hackish `foo' is obscure. When used in connection with `bar' it is generally traced to the WWII-era Army slang acronym FUBAR (`Fucked Up Beyond All Repair'), later bowdlerized to foobar. (See also FUBAR.)
...It has been suggested that this might be related to the Chinese word `fu' (sometimes transliterated `foo'), which can mean "happiness" when spoken with the proper tone (the lion-dog guardians flanking the steps of many Chinese restaurants are properly called "fu dogs").
...
Other sources confirm that `FOO' was a semi-legendary subject of WWII British-army graffiti more-or-less equivalent to the American Kilroy. ...
Earlier versions of this entry suggested the possibility that hacker usage actually sprang from "FOO, Lampoons and Parody", the title of a comic book first issued in September 1958, a joint project of Charles and Robert Crumb.
...
An old-time member reports that in the 1959 "Dictionary of the TMRC Language", compiled at TMRC, there was an entry that went something like this:
FOO: The first syllable of the sacred chant phrase "FOO MANE PADME HUM." Our first obligation is to keep the foo counters turning.
For more about the legendary foo counters, see TMRC. Almost the entire staff of what later became the MIT AI Lab was involved with TMRC, and probably picked the word up there.
Very probably, hackish `foo' had no single origin and derives through all these channels from Yiddish `feh' and/or English `fooey'.
Complete explanation can be found here.

How about writing your GUI as XML files?

I've got an idea from the previous project our lab is involved in. We can store all the information of a GUI, including both its layout appearance and logics behind it, in a bunch of XML files, from which then we can restore the GUI with both the same behavior and the same appearance.
As I said in my previous article, in VC++ environment we can't make it because of widely used user customed Controls in addition to lack of implementation of meta data protocol (in Java it's the reflection mechanism). But on JVM we can get every control's properties, if not all, through Java's reflection mechanism. So it is likely that we can replicate, of course not through copying binary files, a given control written in java.
However, technology is just technology and is useless if it is not practical. Now I just don't know where it can come into play. I know in MS's next generation OS Longhorn there will be a new graphical architecture, Avalon, which allows writing GUIs just like writing HTML files , and which, I wanna mention, uses XML files as the intermediate representation of GUI. That's very similar to my idea. But MS sets up an environment, a some kind of parser or engine, for use of these XML files. But in a common system not as large as a OS, I can't figure out what this technology can be used for, although I think it's not a bad idea and I subconsciously feel that it will be useful.
So I have to further think about it. And if anyone got idea on how to use this technology, please leave a comment. You'll be very appreciated.

Spending Hours Writing a Testing GUI.

It's a part of our lab's arrangements. It's supposed to be finished this morning. But as I said in the last post I put off it till now.
Wirting here, I wanna talk about the project our lab recently involved in, which now proved to be infeasible. The project is to provide a very vivid environment for the user to practise or test their mastering of operating large scale Windows based ERP software. Simply speaking, what we supposed to do is to emulate the targeted ERP software, not only the user interfaces, but also some logic, which the users are interested in, behinde them.
It is not easy to write a software like that. We do a lot of experiments in which we capture as much information of kinds of control as we can from a third party software which will be finally targeted on SAP's ERP. We identify the type of a control according to its internal class name which, if not by default, arbitrary. Obviously, It's a mission impossible. Because user customed controls are everywhere, even in MS's software. So considering this, the type of a control can't be automatically identified.
My advisor has decided to turn down the project. To clarify that we really made a lot efforts and to tell our customer that this project is not feasible we have to integrate what we've done into one prototype to demonstrate our judgement.
And that's why I write the GUI. It's sort of WIN32 programming. I don't use MFC.
ps: If someone know how to work out problems I mentioned above please contact me. Thanks for any reply in advance.