Fog Creek Software
Discussion Board




Metadata Driven Interfaces

Does anyone have any experience with metadata driven interfaces for rich client applications.  I was thinking of implementing one for a new application that I'm writing.  I'm not quite sure on how to go about it but I think it would provide the benefit of being able to easily change the interface by simply editing a field in the relational database.

Anyone have any experience on this sort of thing?  Good, Bad, Ugly?  Any advice is appreciated.

Ned Yost
Wednesday, July 07, 2004

Sounds like JavaBeans, which allows a Java application (via a BeanInfo object) to determine what properties and events an object has at runtime, as well as components needed to modify those properties.  There have been various levels of success at implementing bean-oriented UIs.

http://java.sun.com/products/javabeans/

joev
Wednesday, July 07, 2004

I've done it a bunch of times with web apps:

- runtime reflection from a class
- runtime reflection from a class derived from an ORM
- runtime UI gen from database metadata
- code generation from database metadata

I still think it's a great idea, but the potential time savings are somewhat diminished when you factor in the latent issues you will face with this type of setup. Issues you may face:

- show hide UI elements (not all DB fields need to be exposed)
- type conversion from DB types to class types to UI types

The biggest issue I have found is that UI's change constantly, and as a rule, people REALLY want them to look and act a certain way.  The problems I've  faced is that when the thing is all done, you have sacrificed that granular flexibility for something that really only serves to save developer time.

Sassy
Wednesday, July 07, 2004

I'll be using VB and SQL Server for this project.  Good point about flexibility, Sassy.

Ned Yost
Wednesday, July 07, 2004

I'm actually faced with this issue right now.  I have a situation similar to this:  I have a table of Widget Types, a table of Customers, and a table of Orders.  When a customer requests a Widget, additional information needs to be collected, depending on what the Widget Type is.

It's easy enough to represent in the DB (each row in the Widget Types table has a text column holding the XML Schema for the additional details belonging to that type, and each row in the Orders table has a text column holding the details in XML).  However from a rich-client UI point of view, it's a pain in the arse.

Basically, I've identified two options:

1) Build a rendering engine that can take an XSD and create a reasonable UI.

2) Hand-code plug-ins for each Widget Type that would implement a common interface and fit into the workflow generically.

Right now, I'm leaning towards #2, but I really haven't figured this one out yet.

Joe
Wednesday, July 07, 2004

option 2 is very boring when someone wants to add a new column, you have to change the code rather than the meta-data.
Also, non-programmers can probably learn to change meta-data but they wouldn't want to learn to change code.

gwyn
Wednesday, July 07, 2004

Option 2 is much more boring.  But I also think the cut-off point of productivity is pretty high.  I could probably write 50+ plugins in the same amount of time it would take me to write the rendering engine, and the engine still wouldn't be as complete or flexible as I'd like.

Also, it's not a requirement for my particular project that users be able to modify the metadata.  Indeed, I'd rather they didn't, as they wouldn't be considering all the ramifications of schema changes to existing data.

Joe
Wednesday, July 07, 2004

I've written something similar I reckon. I've got users who can do X to Y and the sets of data will depend on X and/or Y. Were this to be written long-hand it could get real long and put fear in all hearts, which is what another section of our site does. Yet, even what I've done I reckon would throw most for a loop. I've got an engine which renders forms based on X and their roles, Y who they are editing, D, the data sets are modified based on both X and Y. I haven't put anything in a database. All metadata is stored in configs in classes since they are called by user X modifying user Y so what they return will depend on current business rules stored in the function they call. So I build up a data model which is passed to the rendering engine which will return a form with data to edit. But the engine can pass the *building* of a  widget to another function if the particular widget has been marked as extraordinary.  Personally I've found this ever so much easier to evolve than what was done in another part of our site where the whole thing is a collection of many, many files with hundreds of lines of html and code and you've never seen so many if statements. I can take what I've put in the class files as arrays and store them in a database if anyone ever wanted this but no one does.

me
Wednesday, July 07, 2004

This topic rears its head on this board every so often. Google for more, but here are two

Don't define the UI in the database
http://discuss.fogcreek.com/joelonsoftware/default.asp?cmd=show&ixPost=27467

A simple programmers joy
http://discuss.fogcreek.com/joelonsoftware/default.asp?cmd=show&ixPost=47739

there's a few more buried in the archives.

Tapiwa
Thursday, July 08, 2004

link to google search

http://www.google.com/search?hl=en&lr=&ie=UTF-8&q=metadata+driven+interface+site%3Adiscuss.fogcreek.com&btnG=Search

Tapiwa
Thursday, July 08, 2004

You might like to take a look at Naked Objects:

http://www.nakedobjects.org

Ged Byrne
Thursday, July 08, 2004

yeah, second Naked Objects.

Have not looked at it in a while though. Read somewhere that they now had a .Net version, so might be worth another look.

Tapiwa
Thursday, July 08, 2004

I have been there for Browser/Server apps.
I went there because of the usual "flexibility" etc. arguments. After the experience, I have to say, I am not too keen to repeat the excersize.
Yes, you get the "flexibility", but most often it is not really used to its full potential.
What you do get is more complexity, less transparancy. You are in serious danger of leaving an alien artefact on the table for the future developers of the app. This can lead to an ultimately less flexible solution (don't touch that app. there's monsters in there!). Most changes an app needs over time is not changing a listbox to checkboxes.

Just me (Sir to you)
Thursday, July 08, 2004

Programmers love to design their own special languages and write little interpreters to go along with them; what the OP proposes is a good example of this. It's more interesting than just coding a few dozen widgets by hand.

But as Just Me points out, you rarely get a payback that justifies the effort, and you usually end up with something only the original author can maintain.

Tom H
Thursday, July 08, 2004

Well, given what I've seen on this thread, and the two similar threads posted above, I guess I'm leaning more heavily now towards the compiled plugin-style way of doing it. 

I originally thought metadata would be the solution, since this particular app really does have a business requirement for some amount of flexibility in the UI, but it seems like writing the generation framework would take more time than I've got right now.

But doesn't anyone else feel like they are constantly doing the same thing over and over again when they write business data collection UI's?  Isn't there *some* way to reduce the amount of tediousness involved?

Joe
Thursday, July 08, 2004

*  Recent Topics

*  Fog Creek Home