Last post Jun 25, 2006 05:59 AM by donker
Jun 25, 2006 05:59 AM|donker|LINK
I have the following issue I’d like to bring up for discussion: currently DNN is designed to handle modules that have a ‘module-wide’ scope of operation which is too limited for more complex applications. Let
A module stores its data typically with a
ModuleID in the column of the principal table.
You can verify this in most core modules, but let’s take Announcements as an example. So every announcement stored is tied to the instance of the announcement module in which it was created and, conversely, the modules shows only the announcements that were
made in its own instance. So far so good. This design prevents data from being accessed by other announcement modules or, more importantly, from being accessed from another portal. In this example I refer to the scope of the data as being ‘module-wide’.
It does not traverse the boundaries of the module on some DNN page.
Although this is all very well for the announcements module and most other core modules, it is somewhat limiting in other cases. Let’s take the example of a store module (not necessarily the core version, but
any). Typically one displays items in a module pane, allowing users to select them. Then they are aggregated on a separate pane as a feedback to the user (the ‘cart’ pane). Furthermore there are at least checkout and management panes. Although this could all
be implemented as a module with a single pane showing, in practice this would be too limiting. We may want to have multiple catalog panes across the site and a cart showing on every page, for instance. Nor can it be done with a multi-pane module solution,
for you cannot freely add, remove, and displace the panes. The only solution is to work with multiple module instances around the site (the core version uses this approach).
Invariably this means that data has to cross the module boundary. Your user cart data is the same regardless of which page you’re on, but fixed for a portal. This means that this data has a scope that is ‘portal-wide’.
Finally there is data that has ‘installation-scope’. You can think of licensing data or information about the machine where the DNN installation is running.
As mentioned above: the proverbial store module. But next to this also solutions like my document management solution (and all the custom solutions that are based on this), file management solutions, and many
more data sharing solutions where multiple groups of people maintain a single set of data throughout a DNN installation.
I hope that the core architects will debate this. I know people like Shaun, Joe, etc have a keen eye and are skilled designers.
Have a great Sunday ...