Bruno Dumon <[EMAIL PROTECTED]> > On Tue, 2003-04-01 at 20:39, Hunsberger, Peter wrote: > [...] > > We're currently doing something like this: we've got a > metadata model > > that is mapped using a schema to a XML template that the users can > > modify to create forms and other screens (eg; lists). > We've currently > > got a poorly typed presentation syntax that gets mixed in with the > > object model created from the metadata (it needs to have it's own > > schema but it's not yet a priority). > > > > Basically, in our model there are common presentation types > that any > > object can utilize. Objects are metadata mappings of Java > objects. > > The creation of the metadata object descriptions is driven from a > > database in our system, but could be done with static XML > descriptions > > (and was initially done this way until the EJB's to get the > stuff in > > and out of the database existed). > > Before I reply to the rest of your mail: I don't think I've > understood much of the above. > > What exactly is described in your "metadata model"? Is it a > sort of description of the things that can be put in forms? > > And what exactly is the "object model"? Is it an object model > of the metadata itself? In that case, where is the actual > instance data of the things described in the metadata stored? > Is there also an object structure for that?
This is a generalized data collection system (I've written about it on dev and user in the past). You can look at the metadata as a description of the objects that are available to create a form/screen. The objects themselves are not concrete; we have a generalized O/R mapping from/to the types described by the schema from which the metadata can be created. In other words: the users define metadata (essentially using a schema we provide, though that's invisible to them), for abstract objects that represent the domains they need to deal with. They then map these objects to individual screens/forms (any given set of metadata may be reused multiple times.) The instance data is stored within the generalized O/R database. It does have a corresponding object structure, but that is invisible to the end users with one exception: it is itself represented by metadata and available for use in creating administration screens/forms for the administration of the system itself. (There's an extensive privilege/authorization model on top of the whole thing that controls who can see what when). I should probably note that in many cases we create specialized Java classes to map to external systems and create corresponding metadata for the users. The whole system has the capability for the metadata to be mapped to the generic handling or to specific classes for special purpose interfaces. Various interfaces (think of them similar to Cocoon Generators and Actions) can be implemented in these classes to describe what capabilities can be mapped within the metadata. We're trying to get more and more away from these specialized hacks but that means more generic SOAP or whatever interfaces and descriptions of the external systems and then performance starts to become an issue. > > But it's getting late here, I'll reread it in the morning. > > > > > > (BTW, not using XML, XML validation, and XPath expressions as > > > request parameter names is a conscious choice, so what I'm > > > describing here is quite orthogonal to XMLForm, and leaning > > > more towards FormValidatorAction. XML will of course be used > > > extensively for publishing and configuration.) > > > > By saying orthogonal I assume (hope) you're describing what you > > perceive as a modeling requirement in _addition_ to > XMLForm? I don't > > think you want to abandon XMLForm? It would seem to be good > to have a > > standard way of describing presentation semantics and I want to > > migrate our presentation semantics to XMLForm in future versions of > > what we are doing... > > I meant the XMLForm framework from Cocoon, not so much the > W3C XForms specification. Ok, but even then, having an implementation of the common vocabulary would seem a good starting point not? > [... I'll reply to the rest tomorrow ...] > > -- > Bruno Dumon http://outerthought.org/ > Outerthought - Open Source, Java & XML Competence Support Center > [EMAIL PROTECTED] [EMAIL PROTECTED] >
