There are a few concepts used by Meta Facility, those carry some special meanings and concerns.
Let's clarify them before going in deeper.

Referenced Concepts

XPath

XPath is a W3C standard published at: http://www.w3.org/TR/xpath .

All metadata lookups in Meta Facility are based on XPath expressions. If you havn't got familar with XPath, it's better to first go over the official XPath tutorial at http://www.w3schools.com/xpath/ . However, this is not absolute necessary, since XPath is fairly easy and intuitive in common cases, and its most usages within Meta Facility are no more complex than file path names as in a filesystem (but the path separator is / instead of \ , so more like a UNIX filesystem than a MS-DOS™/MS-Windows™ filesystem).

Meta Facility Specific Concepts

MetaBundle

You can consider a MetaBundle as a named infinite set of XML files sharing a common major name and residing in a same access path (like the resource path on top of java class path ). The set is infinite because there are infinite number of Locale s, and these XML files each corresponds to a distinct Locale, by having the Locale 's Meta ID inserted between its major name and its file extention .

For example, the following files ( only the first 2 actually exist in the Demo App's source, others can be created for their locales respectively ) are in a MetaBundle named tutor.meta.Brief

tutor/meta/Brief.meta
tutor/meta/Brief_zh.meta
tutor/meta/Brief_de.meta
tutor/meta/Brief_fr_FR.meta

that loaded from the Default MetaRepository , or other MetaRepositories admitting XML resources with .meta extention .

You may have noticed that, although these files are genuine, Well-Formed XML Documents, their names do not necessarily end in .xml extention . As the above example, the MetaBundles from the Default MetaRepository consist of XML files whose names end in .meta extention .

MetaRepository

Every MetaBundle is associated and loaded from an instanceof MetaRepository. Each MetaRepository is given a file extention as well as a MetaLoader at construction.

The MetaBundle class has a static Default MetaRepository so that you don't have to define your own MetaRepository to fetch MetaBundles.

However the door of MetaRepository is open as its constructor is public such that you're always free to construct MetaRepository instances and get MetaBundles from it.

MetaLoader

MetaLoaders serve as adapters between Meta Facility and various XML storages. Meta Facility is shipped with a few default MetaLoader implenmentations:

MetaLoader Implementation	Loads Resource From
ClassPathLoader	The java class path.
FileSystemLoader	The file system.
WebAppLoader	The J2EE web application /WEB-INF/meta/ position.
CompositeLoader	Other MetaLoaders.

You can implement your own MetaLoaders by implementing its java.io.InputStream getMetaResourceAsStream(String id) method. Then use them to construct MetaRepository instances.

Meta

A Meta is a runtime object that represents a single data node loaded from a MetaBundle by parsing an XML file chosen among that MetaBundle's XML file set, with respects to the specified Locale by the calling code.

Normally you retrieve Meta objects from a MetaBundle instead of data values for further manipulations of structured metadata under them.

RootMeta

If a Meta represents the root node of the XML file, then it is a Root Meta.

Normally RootMeta objects are obtained through MetaBundle.getRootMeta() or MetaBundle.getRootMeta(Locale l)

Only RootMeta objects have parent Meta, which goes a step further in the direction that be more generic to its Locale.

For RootMetas of MetaBundle tutor.meta.Brief, RootMeta tutor.meta.Brief_zh_CN's parent Meta is RootMeta tutor.meta.Brief_zh, whose parent Meta is RootMeta tutor.meta.Brief.

A RootMeta will delegate a metadata inquiry that itself doesn't have answer to its parent Meta while other Meta objects will throw a MetaNotFoundException immediately for such an inquiry.

‹ Previous • TOC • Next ›