Pages are 3D container hierarchies

Another fundamental difference between ElePub and conventional DTP and database publishing is in the three-dimensional container hierarchy used to build pages.

In today's DTP and therefore also in conventional database publishing pages are two-dimensional only.

This has substantial disadvantages especially for relatively complex layouts involving tables of database data. In DTP it is impossible to create a layout as a container holding all its elements in several different frames, some of which are perhaps containers themselves such as tables consisting of many table cells. There is no way of logically wrapping all components and thereby creating a logical container entity, whose components adjust themselves inside this "world". The "grouping" function in DTP is only a very primitive surrogate compared to what ElePub offers instead.

ElePub has containers
In ElePub all frames are contained in a three-dimensional container hierarchy. The outermost container is the page frame, which typically holds several logical container frames each of which again holds several other frames or containers. Containers logically and physically group all frames, which logically all refer to one entity such as an article, a group of articles or a specific subject. This hierarchy can be spread theoretically over any number of levels, in praxis it typically consists of 2 to 4 levels only and is therefore very simple to understand and use.

Elepub's fundamental difference is in the fact that to each member of a container frame the known universe consists of the container only, which is its holder. Any frame object calculates its position relative to its container and possibly with respect to a physical predecessor inside this container.

Therefore, moving or copying a container will not affect the members of this container and their positioning inside the container as long as they are not being told to reposition themselves. Further, in most cases containers refer to one single or a clearly defined number of content objects (articles etc.), which are visualized inside this container. Therefore, the container often also is in charge of referencing a series of data objects (articles etc.) as defined in EleStore

In this drawing the (real concrete) page is composed of two containers, each of which is a child inheriting from a mother container in the repository. This mother container itself is build from three frames, each of which is a child of another mother frame in the repository. Like this larger entities are built from very small and modular components.

The mother objects don't have real data but data link objects. Only when placing children on real pages the identifiers are added and the real frames therefore populated with real data.

Typically, the container objects in the repository are used to create children (instances), which are placed on pages. Of course, in praxis there is a great variety of such container objects reflecting the varying content of different content objects (articles etc.) and the differently designed layouts. In extreme cases pages are composed entirely as a sequence of some few container layouts or, on the other extreme, every container on a page is different from the other. But even in the latter case inheriting components and modifying each child is still much more productive and advantageous than creating every new frame or container all over again from scratch. Modifications are anyway mostly limited to size and position and that is done quickly.

In any case, these 3D container hierarchies substantially ease the entire handling of logical entities on pages, i.e. of logically dependent frame objects. It is also is a prerequisite for a simple, quick and automatic make-up and re-pagination and for changing the sequence of content objects in publication. Whenever a page layout has to be (re-) calculated or manually (re-) positioned, the grouping of frames in containers substantially facilitates all tasks involved.

Of course, it is also possible in ElePub to place every container directly on the page frame and thereby to ignore this container feature completely. But this would eliminate the many advantages caused by 3D containers and would be, sorry to be so frank, just as primitive as the usual approach of today's DTP software - with all its disadvantages. We strongly recommend to use and profit from ElePub's 3D containers