CMS and database publishing in one homogenous system

In database publishing brochures or websites words like "import, exchange, interface" etc. are frequently used. It is undisputed that it is vital to communicate with other systems, but we know from experience that such interfaces are quite clumsy and really are welded joints.

By nature, any database publishing system must have the closest and most frequent communication with the database, for all the content that needs to be published is stored only there. Frequently this content is even spread over several different database systems from multiple vendors, requiring multiple connections for acting in concert. We found this way of working difficult and cumbersome and looked for ways of improving this process.

This is why we unified the Elestore CMS and Elepub to one homogenous application, where the content management and the object publishing system seamlessly unite - without any need for interfaces! No import, export or exchange between them! No welded joints at all!

As explained earlier both Elestore and Elepub have the same origin, they come from the same "mould" so to speak.

Virtual objects in Elestore and Elepub

Elepub and Elestore are practically one system consisting of two parts! Siamese twins - but capable of living separately, when needed!

Continue to use what you have

Still, you are not forced to store your content in Elestore if you wish to work with your existing CMS (Content Management System) and/or with your ERP or other databases. Elestore can act either as a permanent or intermediate storage and fully supports permanent and/or sporadic connection to external databases using "data link objects". This way Elepub becomes fully independent of the physical storage location of Elestore's data. As explained, this is by design.

This enables you to very easily switch between Elestore and your existing database when necessary. We feel this "off-line" process to be a much smoother solution than the sometimes massive overhead of a permanent access to your databases (which should in fact be only rarely needed).