Raymond Feng wrote:
- I think we should try to remove all Java code from the demo and try
to implement CustomerAsset (or AccountService) as a BPEL process or
an XQuery function.
Ant was proposing to have a java script component :-). I'm open.
I am proposing BPEL and/or XQuery here was the focus of XML-Bigbank is
XML programming models, but It would be nice to have a variation of that
demo with a Web 2.0 + scripting focus, with Javascript in the browser, a
popular server-side scripting language - note that I didn't say
Javascript again :) - and data/script integration in the various scripts.
and a question:
- What would it take to return Account summary complex documents from
the AccountService instead of just a number? Can we do this without
having to generate any code?
We could try to return the AccountReport (w/ a list account summaries).
+1 this is what the original Bigbank app was doing.
If we don't want to code-gen, then we could use DOM, AXIOM or even
XMLStreamReader. Or we could use XQuery or XSLT to produce HTML.
I'm wondering if code-gen is always a bad thing. On one hand, it
complicates the story a bit,
If it complicates the story it's a bad thing, and why would I need a
Java compiler to compile my XML app?
but on the other hand, it demonstrates that application developers
have the freedom of choices if they prefer strong-typed representation
of XML infoset.
Yes application developers have the freedom to pick their poison :) but
we can use the Java version of Bigbank to show strongly (Java) type
representation of XML. Once we change that demo back to return Account
summary objects we can show SDO, JaxB etc.
(I'd like to do change the Java Bigbank demo to return account
summaries as well, like the original Bigbank scenario described in
the original spec docs)
--
Jean-Sebastien
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
