Skip to main content

Grid best approach

Author: roger.wallin@abilita.fi (rogerw)

Hi,

Generally spoken, whats the best way to populate a grid by two or several related tables, ie. you don't want to use a view and you can only use one entity in the grid. Think of it as 1:1 and you know which entity to be outermost (searchable). The grid should be refreshable but not storeable, ie. a data-menu.

1. Use a dummy entity for the grid and populate it from some "hidden" entities using fex. creocc "dummy" in the read-trigger....
2. Use a real entity as the grid and use fex. clear and retrieve in the read-trigger to populate some dummy-fields containing the data of the other entity..
3. Get the grid data from a service as xml......
4.........
5. You can't tell a pattern for this complicated situation....

Does anyone have a good pattern?

Regards RogerW.

 

Grid best approach

Author: roger.wallin@abilita.fi (rogerw)

Hi,

Generally spoken, whats the best way to populate a grid by two or several related tables, ie. you don't want to use a view and you can only use one entity in the grid. Think of it as 1:1 and you know which entity to be outermost (searchable). The grid should be refreshable but not storeable, ie. a data-menu.

1. Use a dummy entity for the grid and populate it from some "hidden" entities using fex. creocc "dummy" in the read-trigger....
2. Use a real entity as the grid and use fex. clear and retrieve in the read-trigger to populate some dummy-fields containing the data of the other entity..
3. Get the grid data from a service as xml......
4.........
5. You can't tell a pattern for this complicated situation....

Does anyone have a good pattern?

Regards RogerW.

 

Hi RogerW,

if you have entities with a relationship (UP entitiy),

just use the frame-in-frame to let uniface do all the retrieves
and populate dummy fields of the outermost entity in the READ trigger of the UP entities.

For dynamic or 1:many situations (DOWN entities).

I recommend the same frame-in-frame concept to collect the data,
but use a complete new dummy-entity as a base for the grid
the READ trigger of the lowest DOWN entity will create the occurences.

If you have a standard set of data, but different components to select different fields in the grid
you can use a "product line" approach:

Use the DOWN entity solution as a general data provider
where the DUMMY entity presents "all" data needed in all your different grids.

As a base for the different grids,  COPY the data provider component and purge anything but the DUMMY entity (right now this is a 1:1).
Create a DTD (with the name of the component) from this presentation component and implement the following:
- Send the presentation DTD using $componentname or the precompiler constant as a data-request to the data-provider
- build your DUMMY entity with your data .

If you need variations of the presentation with less fields:
- take the base presentation,
- delete the fields you do not want
- create a new DTD
and here we go.

Success, Uli


Author: ulrich-merkel (ulrichmerkel@web.de)

Grid best approach

Author: roger.wallin@abilita.fi (rogerw)

Hi,

Generally spoken, whats the best way to populate a grid by two or several related tables, ie. you don't want to use a view and you can only use one entity in the grid. Think of it as 1:1 and you know which entity to be outermost (searchable). The grid should be refreshable but not storeable, ie. a data-menu.

1. Use a dummy entity for the grid and populate it from some "hidden" entities using fex. creocc "dummy" in the read-trigger....
2. Use a real entity as the grid and use fex. clear and retrieve in the read-trigger to populate some dummy-fields containing the data of the other entity..
3. Get the grid data from a service as xml......
4.........
5. You can't tell a pattern for this complicated situation....

Does anyone have a good pattern?

Regards RogerW.

 

Hi Uli,

Thanks for a good answer, although the question unfortunately was sent without too much testing from me (friday! :)  ).

I think the main concern was that you can't use more than one entity in the grid. There has obviously been a misunderstanding here that you can't paint an up-entity in the grid-entity, which you apparently can, but you can't directly show the field of the up-entity (inner-entity)?!  But I understand the misunderstanding, what's the technical reason not being able to show fields of up-entities directly in the grid? Perhaps that's just a way to avoid the following problem with down-entities.

I suppose that with the down-entity you mean that the whole frame-in-frame, to collect data, is completely outside the grid? 

   Regards RogerW.

 


Author: rogerw (roger.wallin@abilita.fi)

Grid best approach

Author: roger.wallin@abilita.fi (rogerw)

Hi,

Generally spoken, whats the best way to populate a grid by two or several related tables, ie. you don't want to use a view and you can only use one entity in the grid. Think of it as 1:1 and you know which entity to be outermost (searchable). The grid should be refreshable but not storeable, ie. a data-menu.

1. Use a dummy entity for the grid and populate it from some "hidden" entities using fex. creocc "dummy" in the read-trigger....
2. Use a real entity as the grid and use fex. clear and retrieve in the read-trigger to populate some dummy-fields containing the data of the other entity..
3. Get the grid data from a service as xml......
4.........
5. You can't tell a pattern for this complicated situation....

Does anyone have a good pattern?

Regards RogerW.

 

Hi RogerW,

the "down"-entity is a many-entity (as seen from the current entity)
the "up" is the ONE or reference entity (denoted by foreign-key fields in your entity.

While there is always maximal one UP-occurence you can transfer teh values to the current occurence.
A down entity implicits multiple occurences for each occurence of your current entity.

In the latter case, a dummy entity as the base for the GRID is recommended
where you can paint all these extra occurences you got from the many entities.

SUccess, Uli


Author: ulrich-merkel (ulrichmerkel@web.de)

Grid best approach

Author: roger.wallin@abilita.fi (rogerw)

Hi,

Generally spoken, whats the best way to populate a grid by two or several related tables, ie. you don't want to use a view and you can only use one entity in the grid. Think of it as 1:1 and you know which entity to be outermost (searchable). The grid should be refreshable but not storeable, ie. a data-menu.

1. Use a dummy entity for the grid and populate it from some "hidden" entities using fex. creocc "dummy" in the read-trigger....
2. Use a real entity as the grid and use fex. clear and retrieve in the read-trigger to populate some dummy-fields containing the data of the other entity..
3. Get the grid data from a service as xml......
4.........
5. You can't tell a pattern for this complicated situation....

Does anyone have a good pattern?

Regards RogerW.

 

Hi Uli,

yes I know what you mean by Down- and Up-entity. Sometimes having the Down-entity situation you still can go for the Up-entity solution as the logic (fex. in read-trigger) will reduce the Down-entity to one record, ie. you get a 1:1 situation.

However it would be interesting to know why it isn't possible to show a field of an up-entity in the grid, but you have to copy to a dummy-field of the outermost entity?

 Regards RogerW.


Author: rogerw (roger.wallin@abilita.fi)

Grid best approach

Author: roger.wallin@abilita.fi (rogerw)

Hi,

Generally spoken, whats the best way to populate a grid by two or several related tables, ie. you don't want to use a view and you can only use one entity in the grid. Think of it as 1:1 and you know which entity to be outermost (searchable). The grid should be refreshable but not storeable, ie. a data-menu.

1. Use a dummy entity for the grid and populate it from some "hidden" entities using fex. creocc "dummy" in the read-trigger....
2. Use a real entity as the grid and use fex. clear and retrieve in the read-trigger to populate some dummy-fields containing the data of the other entity..
3. Get the grid data from a service as xml......
4.........
5. You can't tell a pattern for this complicated situation....

Does anyone have a good pattern?

Regards RogerW.

 

Hi,

I think someone from "the Lab" can explain it better,
but AFAIK the implementation of the GRID is based on a single entity and the fields defined there.

So all data to be displayed have to be defined as fields within this entity.

Success, Uli


Author: ulrich-merkel (ulrichmerkel@web.de)