Thursday, March 27, 2003
fyi - new info on data binding
Brett McLaughlin 3 (out of 4) articles on Data Binding:

The goal of this series is to show you how to convert XML elements to Java
objects so you can directly manipulate XML data with Java language accessor
and mutator methods. Part one compares data binding to other methods of
handling XML data within Java applications, analyzes the design decisions,
and defines the XML schema for the example Web service configuration
document. Part two explains how to generate interfaces and implementations
from the XML schema so that XML documents that conform to the XML schema
can then be converted into instances of these generated classes. Part
three covers unmarshalling the nested elements in the XML documents into
Java objects, testing, and putting the new tools into action with some

XML in Java: Data Binding with Castor
XML data binding for Java is a powerful alternative to XML document models for applications concerned mainly with the data content of documents. In this article, enterprise Java expert Dennis Sosnoski introduces data binding and discusses what makes it so appealing. He then shows readers how to handle increasingly complex documents using the open source Castor framework for Java data binding. If your application cares more about XML as data than as documents, you'll want to find out about this easy and efficient way of handling XML in Java.

S karinga is a framework for Java and XML language binding. Its core component is an Object Transformer, which is able to transform Java objects into XML documents and vice versa.
It consists of the parts:

* Serializer: Marshalls Java objects into XML documents.
* Deserializer: Creates Java objects from XML documents.
* XML schema generator: Generates XML schema definitions (XSD) from Java classes. The XML documents created by the serializer can be validated against those schemas.
* Transformer: Transforms Java objects of different types into each other by using XSLT instructions.

JiBX: Binding XML to Java Code
JiBX is a framework for binding XML data to Java objects. It lets you work with data from XML documents using your own class structures. The JiBX framework handles all the details of converting your data to and from XML based on your instructions. JiBX is designed to perform the translation between internal data structures and XML with very high efficiency, but still allows you a high degree of control over the translation process...
This approach gives several important benefits:

1. Flexibility - Use any class structure you want, so long as you can tell JiBX how to translate it to and from XML.
2. Performance - Pull parsing and class file enhancement techniques let JiBX build high-performance marshalling and unmarshalling code directly into your classes.
3. Clean code - You write the code and JiBX works with it, not the other way around!

Wednesday, March 26, 2003
2001-06-07 The Java Specialists' Newsletter [Issue 022] - Classloaders Revisited: "Hotdeploy"
Perhaps you found that having several classes called "A" in your java.exe was not very useful. On the contrary, it probably required quite an effort to keep the various sources and class files of that newsletter in separate directories. However, I would like to demonstrate how this rather theoretical possibility has significant practical value when it comes to building real programs that are able to simultaneously host multiple Java applications. The most well known examples of such programs are found in the J2EE(tm) application servers.

For this purpose, let us briefly revisit what the head of Maximum Solutions Ltd., by the way, one of the best Java consultancies I know of ;-) [hk: hihi], has demonstrated to our surprised eyes and what may be already apparent from the terminology: A java.lang.ClassLoader is an object that is used to locate external resources (such as *.class file placed in a directory or zipped into a jar-file) and to import the contained byte code for constructing java.lang.Class instances at runtime.

XML and JavaScript in the Browser
A couple of considerations make this not such a silly question after all. First, the questioner specified client-side processing. This eliminates back-end programming languages such as Perl, ASP, and Python. Second, JavaScript has a two-pronged advantage over the languages remaining: it's a simple, cross-platform solution. If you could actually get it working, any browser capable of running JavaScript (and, of course, displaying XML in the first place) could be made to handle the XML exactly the same way. You could restructure the document tree on-the-fly, for example, or add completely new elements, attributes, and other nodes to it -- all without requiring any proprietary languages, and all without having to know any language more complex than, well, JavaScript.

In researching this question, I found numerous possible solutions to the problem. Two of them might interest you: the Sourceforge XML for [SCRIPT] project and Cyril Jandia's ESPX/TinyXSL.

Design Markers: Explicit Programming for the Rest of Us
Many choices made at software design time cannot be directly expressed in today's implementation languages like C# and Java. These design choices (known by names like Design Patterns, Design Contracts, Refactorings, Effective Programming Idioms, Blueprints, etc.) must be implemented via programming and naming conventions, because they go beyond the built-in functionality of production programming languages. The consequences of this limitation conspire over time to erode design investments as well as to promote a false segregation between the designer and implementer mindsets.

Monday, March 24, 2003
YAXOL (Yet Another XML Output Library)

is part of the general MXP1 Parser. #


the server side
dotnet junkies
sam gentile
sam ruby
paul prescod
.net guy
jon udell
john robb
blogging roller
desktop fishbowl
cafe au lait
be blogging
kevin burton
james strachan
the truth is out there
brett morgan
blogging roller #2
joe's jelly
psquad's corner
rickard oberg
the saturn times
russel beattie
gerhard froelich
pete drayton
clemens vaster
ingo rammer
ken rawlings
simon fell
bit working
justin rudd
chris sells
john lam
jim murphy
brian jepson
john burkhardt
matt pope
better living through software
loosely coupled
understanding software engineering
rest lst,rdf-interest lst,tag lst ucapi lst

A man, his puppy, and a double barreled shotgun.

Powered by Blogger