Skip to main content

MetaData - how mutable need they be?

10 replies [Last post]
kleopatra
Offline
Joined: 2003-06-11

Basically, I'm trying to understand the requirements and collecting use-cases to help :-)

Currently all MetaData properties are mutable and bound. On the other end of the pipe, nearly nobody is listening.

The one exception is TabularDataModel, which listens to "name" and "elementclass" - the two properties I would expect to be immutable in any scenario (once the data has gone "live", that is after reading/loading a model).

Background is, that the mutability poses a heavy burden on the view/binding classes. F.i. changing the elementClass may require to replace a component in a form.

So I would like to get some opinions about reasonable limits for mutability. Starting with my current POV:

MetaData have a live-cycle: there is a "initialization" phase, that's reading/loading/customizing _before_ they are used to drive a view. In this phase every property is mutable (necessary for deserialization anyway). That's okay from the view's prespective, because all relevant properties will be picked-up at creation/binding time anyway. There's a "live" phase - after creation/binding of views. In cthe live phase, only a subset of properties are allowed to change.

Then the next step will be to find the properties should be fixed in "live" phase. Taking Amy's grouping of MetaData from the roadmap:

a) datatype
b) converters
c) view hints
d) edit constraints
e) validators

the obvious mutable group is c). I would regard a), b) plus identifier as essentially immutable. d), e) are related and in the borderline to "data" properties anyway - so could change context-dependent and will need special care.

Comments, please?

Jeanette

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
dhall
Offline
Joined: 2006-02-17

I think you're starting from the right place: I tend to be one who likes to look at the impacts and adjust the starting position as necessary, and it appears at this point that any adjustments are likely to be fairly small.

As you can (or will be able to) tell from the functor filter discussion, though, my concern is more with visibility -- in what contexts do I have access to the underlying metadata.

Dave

rbair
Offline
Joined: 2003-07-08

Hey Jeanette,

I haven't had time to think this all the way out, but I think in discussions Aim and I concluded that a DataModel needs to be able to change what meta-data it contains mid-stream, but that the MetaData themselves are more or less immutable. I can't think of a case where that shouldn't be the case, except perhaps with rendering "hints"

Richard

kleopatra
Offline
Joined: 2003-06-11

Hi Richard,

>
> I haven't had time to think this all the way out, but
> I think in discussions Aim and I concluded that a
> DataModel needs to be able to change what meta-data
> it contains mid-stream,

No nitpicking, just to get our vocabulary up-to-date: all metaData related issues are (will be :-) factored out into the MetaDataProvider. So it's the provider that needs to fire structural changes.

And I agree with your conclusion, but nevertheless my favorite question (learned it from Ramesh :) - use-cases, anybody? Who will be listening to achieve what? Coupled to this: how fine-grained do we need the notification event/listener?

Easiest for the provider would be to go for a coarse-grained structureChanged - that's how TableModel propagates structural changes, which is a nuisance. Fine-grained notification adds complexity, to implement them correctly is quite a task (seeing TableColumnModel as a negative example).

Hmm, I lean to do the latter - will be done once and for all, DataModels can safely delegate to the default implementation, so it might be worth the trouble ...

Any thoughts?

Jeanette

rbair
Offline
Joined: 2003-07-08

Use cases are of the utmost importance!

Here's a couple.

Use case #1, the SQL Editor Application:

This application lets the user type in a query, which it then executes against a database and gets back a response. In the (futuristic and really cool) GUI builder, the developer drops on a JNTable, a DataModel/DataSource combo, and wires them up. The JNTable displays whatever is in the DataModel. He then also puts a JTextArea on the form and a submit button.

At runtime, the user types a query into the JTextArea, and hits submit. This query is placed into the RowSetDataModel, and the DataModel is refreshed (the logic that does this is in the 'submit' button's event handler). The results are some time later loaded from the database. Since the results are most likely entirely different than those that the DataModel had previously loaded, it must reload all of its MetaData based on the RowSetMetaData contained in the RowSet. The table is then notified that it needs to refresh itself via a data model changed event.

Ok, use case #2, a static form:

The developer constructs a bunch of DataModels and sets up the MetaData by hand. The DataModels are passed to a JNForm for auto-assembly. Use proceeds as one would expect (nothing fancy here).

In use case #1, the important thing is that the same DataModel can be reused with totally different MetaData. In use case #2 the important thing is that the JNForm can count on the MetaData being constant. In fact, unless dynamic runtime changes to the JNForm are desired, it would be best if the DataModel did NOT allow swapping out of MetaData.

Hmmmm....

Richard

wsnyder6
Offline
Joined: 2004-04-20

Jeanette,

Nobody has answered, so here is my .02...

This sounds very reasonable to me. We have been actively developing with the JDNC binding framework for a little while; I have personally not come across a case where I need to dynamically change the datatype/converter. Once I add MetaData to a model, I always intend for it to be the same type.

The only thing that might change in context would be the validation/constraints.

--Bill

kleopatra
Offline
Joined: 2003-06-11

Bill,

>
> Nobody has answered, so here is my .02...

thanks for starting to break the deafening silence

>
> This sounds very reasonable to me. We have been
> actively developing with the JDNC binding framework
> for a little while; I have personally not come across
> a case where I need to dynamically change the
> datatype/converter. Once I add MetaData to a model, I
> always intend for it to be the same type.
>
> The only thing that might change in context would be
> the validation/constraints.

that's (and the others' answers as well) reassuring, so I'm not too far off-track.

Interesting that you work/experiment with context dependent validation/constraint - there was a question about it last week - can you elaborate a bit on how you do it? And/or what you would need to make life easier?

Jeanette

wsnyder6
Offline
Joined: 2004-04-20

Sorry for the delay Jeanette,

I don't have any hard use cases for it now (our app is still quite basic). But from a business workflow standpoint, I thinks its fair to expect constraints/validators to change as the app modifies the datamodels. As we come across this scenario, I'll let you know how well the JDNC API handles this type of change.

--Bill

Anonymous

Just mine 2 cents.

I would say that how mutable MetaData should be is depend on your business rules. So if you are using one table to display different results, yes it should be mutable.
But if you have a table that display a data that doesn't change it's format during lifecycle, your MetaData could be even static (theoretically).
But on the other hand, sometimes, MetaData should be tight to the DataModel so you can use a single class for both models. So you can mutate your MetaData based on the data in data model.
As an example DataBeans DataModel, when MetaData is driven by DataModel.

kleopatra
Offline
Joined: 2003-06-11

Thanks to all for your input! Feels good to get it :-)

To sum up to an intermediate result

a) as structural changes we expect an all-or-nothing change - replace all metaData or none.

b) as property changes we expect them in the visual clues and the realm constraints/validators which are coupled to the business rules.

Sounds all very reasonble to me.

Jeanette

mikeazzi
Offline
Joined: 2003-08-11

Hi Jeanette,

I would like to add my own 2 cents, if I may, to this ongoing discussion. The product that I'm working on at my current employer is a fairly large Web based business application suite for the Enterprise/IT Asset Management sector, so I may be able to provide a use case scenario that's relevant to this topic.
First let me start by saying that all meta data in our application is stored in the data base alongside the app data, and are both accessed in a unified fashion through an Object/Relational persistence API. So our binding framework at runtime uses this API to get the meta data info of a given DB field, which in turn is used by the rendering layer.
The two meta data groups that we are mostly interested in as far as mutability is concerned is a) datatypes, and
d) edit constraints. As for group a) they are like you said, essentially static except for the case when that data field is a value list (or pick list) where the values in the list change when another field on the form changes from one value to another. For example a status field value list changing from Active/Inactive, to Open/Close/Pending etc.
With regard to group d), it's the same situation where the edit constraints (ReadOnly v/s ReadWrite or Required v/s Optional) of a field change with the changing of a value in another field on the form. Add to that the ability to further restrict the edit constraints of a field by specifying the corresponding attribute in the XML file.

As far as the remaining meta data groups are concerned I think what you have so far pretty much covers most of our requirements.

That's all I have to say for now, I hope I have been able to contribute positively to this discussion, and to the gathering of requirements.

Thanks,
Mike