cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hunsberger, Peter" <>
Subject RE: [RT] Towards a new/another Forms Framework
Date Tue, 01 Apr 2003 21:59:31 GMT
Bruno Dumon <>

> 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                   
> Outerthought - Open Source, Java & XML Competence Support Center

View raw message