Users might want to see the same document in many different ways:

• changing the order of the nodes,
• changing how nodes look,
• collecting information about several related nodes,
• and so on.

As XMLEye allows us to browse both the whole document tree and view the current node in detail, we might want to customize any of them. We would like to do so independently, being able to switch how the whole tree or each node are processed at any time. However, this should require as little work as possible: it doesn't make sense to hardwire every possible tree/node view combination, even within a specific input format.

The way XMLEye solves this problem is through the tried-and-true Pipes and Filters architectural pattern. In this pattern, we have several filters whose inputs and outputs are connected by virtual “pipes”: that is, the output of a filter is the input of the next filter. The trick here is that some of those filters can be optional, and that any filter can be switched with another that complies with the same input and output format.

In particular, as can be seen in the figure to the right, XMLEye uses up to three filters:

1. An optional converter filter which takes the non-XML input document and turns it into XML. If the input is already well-formed XML, it doesn't need to be used.
2. A preprocessing stylesheet (see this page for details) which produces from the XML obtained before the representation of the document tree, which will be displayed in the left pane in the tab. This transformation only needs to be done once per document.
3. Every time the user selects a node, a view stylesheet (again, refer to the page above) will generate the detailed node view that will be presented to the user in the right pane. Currently XMLEye is limited to XHTML views, but in the future more formats might be added, such as JavaFX, for instance.

The preprocessing and view stylesheets can be switched freely by the user. No restrictions are imposed on possible combinations by XMLEye. Of course, those stylesheets might be format-specific and thus produce unexpected results for other formats. Stylesheets are lazily compiled into Java bytecode the first time they're used since XMLEye was started. It might take a second or two, but it's rather fast after that.