Editable Grid design pattern

Hi,

I am new to Metastorm and have been trying out version 9. My question may sound trivial as I am looking for design patterns that you experts must have been using in your various solutions:

I have recently learnt that editable grids can only be attached to a single table in database. This sounds very limiting to me as i already see requirements where I may have to join multiple tables to display and update data using grid.

What is the suggested design pattern to collect data on a editable grid and then update/insert it in multiple tables ? One option I could think of was using database views but I guess that's not possible as well with editable grids in V9 ?

Any suggestions ?

Thanks in advance.

Find more posts tagged with

BPM

Comments

Carolyn Anderson

The same principle applies to any view, regardless of whether it's in Metastorm or not, so I can understand why you can't do this in Metastorm.

Some people use a non-editable grid, and when a user clicks a row, feed the values into some fields on the form, which are then edited, and when you press save you can save the data where you want (i.e. multiple tables). The advantage of this is that is happens all within the Metastorm environment, and is quite easy for a non-developer to set up. But the disadvantage of this method is that you have a lot of dependencies on your form, and this makes the forms more error-prone in the longer term because you have to manage the order things update, and you need to make sure you don't get circular references. You can also potentially get database deadlocks if the grid is trying to view data and you're trying to update it at the same time.

Personally I try to avoid editing with Metastorm grids if I'm doing anything even remotely complicated. When I need to edit data, I use the grid-row-click to set a field with the key of the row to be edited, then on a 'edit' button I write javascript to open a .Net window with my non-Metastorm edit screen in, where I can write data to where I want. When I'm done i call back into my javascript and click an invisible refresh button to update the form. I know it sounds wierd, but it's the safest and most performance-friendly way I've found to do this. A couple of years ago we had to re-engineer our grid-editing out completely by taking a lot of complex stuff out and placing it in a parallel .Net web application, linking them up with javascript. It worked well. Another advantage to this method is that when you upgrade from one Metastorm version to another, you only have to upgrade one part of the system - the non-Metastorm stuff just gets plugged in and works instantly! And there are a lot fewer functional changes in the .net section than if it had all been in metastorm. I will never regret that decision.

Everybody's going to shout at me now for using non-Metastorm technologies. Go on, use editable grids - just do it carefully:-)

Jerome_Pearce

Editable grids are useful up to a limit, and that limit is not a 'high' one. As you say, single tables are it. In version 6 & 7 you could edit joined tables, but the potential for stuff-ups was so great we did not recommend it. I never did see a proper implementation. Effectively the same restriction applied.

We tend to build all our UI functionality inside Metastorm, so we have come up with a simple approach to editing fields from a read-only grid. Some complex code will fill local variables of the same name as the Business Object column names on a row select, and update/insert/delete these with SQL on pressing a Update/Insert/Delete buttons. Effectively the 'pain' of updating editable grids is vastly reduced to four simple function calls.

This is in our Library here if you are interested. No documentation as yet - that is coming as and when we have time.... ;-)