-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Folks.
MidCOM is coming together into shape. My first Alpha Implementations work, and we are nearing the point, where I'll release the first, public Alpha, which will be at Stage 1: > Stage 1: Basic implementation > > Implement the basic features of the MidCOM framework. Automatic > Component loading, replication safety. Drive everything directly > from the snippet tree, no automatism for Layouting or so. > Administration will be done solely by hand via your favorite > parameter-capable admin interface. As of now,everything except Component Error Handling (read: displaying the appropriate HTTP Error Pages) works. I think that I'll be able to release MidCOM 0.1 within this week, with a little luck today. Attached is the current version of the MidCOM Architectuer Specification. Live long and prosper! Torben Nehmer - -- Torben Nehmer, Munich, Germany http://www.nathan-syntronics.de, mailto:[EMAIL PROTECTED] PGP Public Key ID on wwwkeys.(de.)pgp.net: 0x7E9DE456 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Weitere Infos: siehe http://www.gnupg.org iD8DBQE8ssc9JPh4Kn6d5FYRAmVqAJwOh0AdKTaqUEamwQx7ktJrsvYN3ACfTFox nG4zgUwhd4etCEGj4P5EXjg= =/p7z -----END PGP SIGNATURE-----
RFC: Midgard Components (MidCOM)
================================
Author: Torben Nehmer, Linksystem Muenchen GmbH <[EMAIL PROTECTED]>
Date : March 4th, 2002
Abstract
--------
This document represents a draft about a component architecture for the Midgard
Content Management System. Its intent is to provide an easily extensible
Application Framework based on Midgard. It should -- in its ultimate
extent -- enable end users to "click their sites together" using common
Components for news tickers, discussion boards or similar things.
This document describes an incremental process. Especially the last parts of
the document are only there because it struck me some time in the night that
"this would be fine". They are not necessary for the system.
Note: Everytime I talk about "Stages" I refer to the Roadmap in Appendix B.
Table of Contents
-----------------
1. Design Goals
2. Application Infrastructure Overview
3. Components
3.1. MidCOM Hooks
3.2. Component-Mode vs. Library-Mode
3.3. Component Code
3.4. Component Style
3.5. Configuration
3.6. Documentation
3.7. Data Storage
4. Namespace Conventions
4.1. SnippetDirs: Component Storage
4.2. Global Variables
4.3. Class and Function identifiers
4.4. Namespace "midcom"
4.5. Parameters in the Topic Tree
4.6. Public and Private MidCOM Elements
5. Interface Definitions
5.1. Component Management
5.2. Component Invocation, URL Parsing and Component Configuration
5.3. User and Administration Interfaces, Layout Management
5.4. Documentation
6. Preparing a Site for Components
7. Using Components
8. Automated Administration Interfaces
9. Advanced Style Engine
10. Navigation Access Points (NAPs)
11. Debugging
12. Security System
13. Versioning
APPENDIX A. References
APPENDIX B. Roadmap
APPENDIX C. Ideas
1. Design Goals
---------------
What Midgard currently lacks most is an easy way of importing applications into
an existing site. Most written applications are site-specific and can hardly be
exported into another site without great customization. This is where Midgard
Components come in:
Every MidCOM application is contained within a Component with an explicitly
defined interface to the world. Controlling infrastructure is the topic tree
not the page tree giving you a far greater flexibility. The code itself is
completely encaspulated in snippets, making replication very easy.
A framework is used to manage the components, both for public and private sites
such as a web site and its administrative site. In theory this could even
automate the building of administration interfaces by "traversing" every active
component.
2. Application Infrastructure Overview
--------------------------------------
The basic idea is that the regular Midgard Program Flow (see midgard-root.php)
is enhanced by the MidCOM Framework. It uses the "code-global", "code-init"
and "content" (magic) page elements to relay execution to the different
components. Basically you can treat a MidCOM as a fully encaspulated package
that provides hooks for the following program flow:
Step 1: <[code-global]>
<? Component Configuration ?>
<[code-global-local]>
Step 2: <[code-init]>
<? URL Parsing ?>
<? Component Initialisation ?>
Step 3: <[content]>
<? Component display ?>
Except from the call to <[code-global-local]>, every call is handled by the
component framework, basically giving you this:
Step 1 loads all necessary functions for the component framework, initializes
the system and loads the component information along with its configuration.
The framework also calls the custom element <[code-global-local]> where you
can place site-specific, not MidCOM-related configuration directives.
After that the real processing starts in Step 2. A URL Parser is used to map
the request URL to the given topic tree. For every topic the Parser activates
the accociated component and runs its URL Parser hook. If the component decides
that it is able to handle the request, parsing stops and execution
continues. If not, the system continues to traverse the topic tree until either
a component can handle the URL or there are no more toics, in which case a 404
Not Found error is triggered.
This means, that every topic must have an accociated component. Either through
direct association using Object Parameters, through Inheritance from another,
higher-level topic, or through the definition of a "default handler" during
system initialization.
If no error occurs during parsing, the component-specific initialization code
is called. It prepares everything for the final display in the "content"
element.
3. Components
-------------
Technically a MidCOM is delivered as a repligarded SnippetDir with a defined
layout. Basically there are five parts of a MidCOM, each contained in its own
SnippetDir below the main one:
1. MidCOM Hooks: Hooks for the MidCOM Framework, required to handle the
Component, including the Admin Site Builder Interface (see
Section 8, "Automated Administration Interfaces")
2. Component Code: The Application itself
3. Layout Hooks: Snippets to control the output of a MidCOM
4. Configuration: Global Configuration of the MidCOM
While the first two parts should never be touched by an end-user, the last
two most certainly will be. This should be kept in mind that those parts of a
MidCOM should _not_ be replicated in updates. (Repligard would overwrite the
customized snippets with the default ones. A good idea(tm) for repligard would
be an option to copy the imported data, especially useful in a situation like
this.)
Remember the replication problem everywhere in the vincinity around
MidCOM. Everything you write should be replication safe. If possible, avoid
using Object-IDs where there is no automatic translation from repligard. Use
Names -- or if you find no alternative, GUIDs -- instead. This has to be
bulletproof, since most more complex sites will use a staging-live setup where
MidCOM has to work its magic too. (And it has to work it as smoothly as it
would do without replication.)
Each Component is housed in its own snippetdir. Five defined subdirs contain
the different Parts of the MidCOM:
3.1. MidCOM Hooks
-----------------
This is the real interface to the outside world. It defines a set of classes
that the Framework uses to access the Component. The classes found here have to
present a defined interface for the different operations. Entry points are
defined for:
- Global Component Initialization
- URL Parsing
- Local Component Initialization
- User Interface Display
- Administration Interface Display
- Navigation Access Points
These Hooks are contained in a snippetdir named "_midcom".
3.2. Component-Mode vs. Library-Mode
------------------------------------
Until now, this text assumed that a component was used in
"component-mode". This means, that the component is directly responsible for a
special object in the content tree. But assume you want to use existing
functionality in a new, enhanced component.
In this case MidCOMs can be used in a "libary-mode". This mechanism allows you
the shared use of classes from other components through loading the code of
another component upon request. Each component can decide for itself whether it
is usable in library-mode, component-mode or both.
Each component should define an external Interface if it is to be used used in
library mode. This set of classes reside within the code subdirectory and are
declared as public by convention (see section 4.6, "Public and Private MidCOM
Elements"). All other classes should be declared as private to show a user,
that thos classes must not be used directly.
Problem 2DO: Configuration management in library mode? Should the local
configuration be added to the current content object? How far will this library
infrastructure really go?
3.3. Component Code
-------------------
This is the place where you write all your component code. Call it Application
Logic, Business Logic or whatever you want, but this is the place where you can
roam around. But keep the Namespace Conventions (see below) in mind!
Elements within this part can be either public or private (see section 4.6,
"Public and Private MidCOM Elements"). This is especially important if the
component is to be used in library-mode.
Idea: You might attach the "version number" to the data objects created with
your MidCOM. This will enable you to do "versioning" within your component,
keeping track of necessary updates.
All component code has to be placed in a snippetdir named "_code".
3.4. Component Style
--------------------
This SnippetDir roughly works like a Midgard Style. It gives you a number of
Snippets, each representing a part of the interface style. Whether you write
the HTML Code directly into those snippets or not is your choice.
Concerning Replication: Since the Layout Hooks SnippetDir is not in the
upgrade-XML file, special care has to be taken here if you introduce new
elements. Preferably you explicitly export those new elements into the
upgrade-XML file to ensure completeness of the Component.
The Style Elements are contained in snippets within the snippetdir "_style".
For further Details about the layouting Process see section 9, "Advanced Layout
Engine".
3.5. Configuration
------------------
The global Snippet Configuration (i.e. for I18N ...) is stored into the _config
SnippetDir. How you organize this snippetdir is entirely up to you,
configuration process is invoked through a class in the MidCOM Hooks section.
The configuration process itself is done in two stages. First any global
configuration which holds true for all snippets is loaded. This is the
information attached to the component itself.
In the second stage the configuration is adapted to the current request
environment using an associative array given by the MidCOM Framework. In
essence, this data is located in parameters attached to the snippet. MidCOM
also provides a mechanism to update the configuration data at runtime.
This holds true for both component- and library-mode. In the latter case, the
adaption Data is delivered by the component that is loading the library. The
Framework should provide a way to manage library-mode configuration data
automatically, perhaps attaching it to the object of the currently active
component.
3.6. Documentation
------------------
All Documentation -- whether it is targeted for other developers or for the end
user -- has to be placed into the snippetdir "_doc". It is accessible through a
common Interface in the MidCOM Administration Site.
3.7. Data Storage
-----------------
The MidCOM Framework uses the topic tree to store the structure of the
site. You have to assign a MidCOM to every topic in the tree. That component is
then responsible for at least the articles in the given topic. Optionally a
component can declare itself responsible for subtopics through the Hooks in the
URL Parser.
4. Namespace Conventions
------------------------
Very important is the Namespace Convention of the whole framework. Current
Midgard Solutions often have no explicit Namespacing (since it isn't supported
by PHP or Midgard anyway), which often results in a certain chaos if you try to
integrate multiple applications into one site.
The basic idea behind MidCOM Namespacing is a system similar to Java's Package
Hierarchy. To achieve globally unique package identifiers it suggests using
Internet Domain Names as a Hierarchy. This leads to package Names like
"de.linkm.newsticker". This path, called the "MidCOM Path", represents the
MidCOM Namespace of Component itself. It is used everywhere to seperate
different Components from each other.
A component's name must match this regular expression:
[a-z][a-z0-9]*
All non-valid characters (i.e. "-" in Domain Names) have to be dropped.
4.1. SnippetDirs: Component Storage
-----------------------------------
Translated into SnippetDirs the path given above results in
"/de/linkm/newsticker/". This path is used to store the Components in an
hierarchical order.
Each component has the five defined snippetdirs from chapter 3, which are the
only reserved names for SnippetDirs. Therefore a MidCOM package is valid if and
only if a SnippetDir contains all five SubSnippetDirs and the defined set of
classes (see below) in the MidCOM Hooks section. This gives us this Basic
Layout:
/------------------------------------------------------------------------------
| Figure: Basic MidCOM Package Structure
|------------------------------------------------------------------------------
|
| de
| \-linkm
| \-newsticker => Base SnippetDir
| |-_midcom
| |-_code
| |-_style
| |-_config
| \-_doc
\------------------------------------------------------------------------------
This structure leads to the conclusion, that every element within this tree can
be both a component and a container for further components. An exception are
the Top-Level Domains (com, net, org, de ...), which must not be used as a
Component.
Although it is possible to put additional Components "into" an existing one,
this is strongly discouraged. It makes the whole tree more difficult to
read. If you require it (i.e. to extend an existing site), the defined
sub-SnippetDir's are all prefixed with an "_" to get them at the right place in
the sorting order.
4.2. Global Variables
---------------------
Each Component will most probably require a number of global variables for
processing. Again we use the MidCOM Path as a prefix for the variables,
replacing the dots with underscores. In our example the newsticker Component
would call its global variables de_linkm_newsticker_...
Any other global variables not starting with one of the domain-prefixes plus an
underscore will be considered local and are therefore _not_ guaranteed to
survive any function call within the MidCOM framework. So either you use real
local variables within your function (which is perfectly fine) or remember the
rule above. Never trust a variable from outside your namespace.
Note: Try to minimize the use of global variables as an interface. They are
good for entry points in a system, but from there use OO-Techniques.
4.3. Class and Function identifiers
-----------------------------------
Basically this works like Global Variable naming above.
4.4. Namespace "midcom"
-----------------------
This is a special Namespace on the same level as the top-level domains. It is
used as the entry point into the MidCOM Framework. Anything below midcom.* is
therefore not allowed for any Components (shouldn't be the case anyway).
Any System Component like the URL Parser, the Automatic Admin Site or the
Enhanced Layouting engine will also fall into the midcom Namespace. For now the
final decision what goes into the midcom namespace and what not is made by the
MidCOM Development team.
4.5. Parameters in the Topic Tree
---------------------------------
MidCOM uses parameters to Content Objects (topics, articles, attachments) to
control the whole web site. Again the Component Path is used to set
configuration parameters. The Domain "midcom" is used to control MidCOM
itself. Important is the Parameter midcom.component, which contains the Path to
the component MidCOM should load at this point. Component-specific parameters
go into a domain named after the MidCOM Path, in our example
"de.linkm.newsticker".
This leads to the conclusion that a single topic or article could hold the
configuration data for more than one component. This behaviour could be useful
for switching to test data during development. Perhaps this could also be used
in a deferral-like mechanism where one component delegates processing to one of
his "children", like in an object inheritance tree.
4.6. Public and Private MidCOM Elements
---------------------------------------
Since PHP does not provide the possibility to distinguish between public and
private variables, it is strongly suggested to use this guidline to get a
similar mechanism: Prefix _all_ private elements with an additional underscore
before the real name. This is used for global functions, global variables,
class identifiers and class member variables.
All classes that start with this prefix must never be used from anywhere
outside the component they define. This is especially improtant if a component
is used in libaray mode.
Note: The underscore goes before the name, not before the fully qualified
MidCOM Path. For Example, if our newsticker requires a private helper class
DateConverter it should be named de_linkm_newsticker__DateConverter. If this
class is to be stored in its own snippet within the _code subdir of the MidCOM,
the snippet should also be prefixed with the "_".
5. Interface Definitions
------------------------
While you could use inheritance to create the MidCOM Hook Classes, this is not
necessary -- PHP doesn't support abstract classes anyway. Due to this an
approach similar to the Standard Template Library's "Concepts" ist taken here.
The class names defined here have to be prefixed with the correct component
path. For example the concept class "config" would be named
"de_linkm_newsticker_config" in our example. This leads to a range of classes
every component must possess in order for the framework to work.
5.1. Component Management
-------------------------
This Hook is used to control the MidCOM itself. For Stage 1 it is there to load
all necessary Snippets for the MidCOM to work. It also defines a central point
which lets you retrieve Meta-Data (Propierties) about a component. Later on
things like pre- and post-installation scripts can also go here.
Concept "Component Management":
class midcom {
function initialize($libmode);
function properties();
}
Concept Description:
- bool midcom::initialize(bool libmode);
Parameter libmode: TRUE if the component is used as a library.
Return Value: TRUE if initialize was successful, FALSE otherwise.
This function prepares everything to incorporate the MidCOM into the
runtime environment. Important: It does not load configuration or anything
else. The sole purpose of this method should be loading and preparing any
external dependencies that are required to "link" the MidCOM into the
existing runtime environment. Most of the time this function will load the
required snippets from the component snippetdir. If this function returns
FALSE, the whole System will ignore the component and won't try to access
it. Any time a component that returned FALSE is required to execute a site,
a HTTP 500 is the result.
- Array[Property-ID => Value] midcom::properties();
Return Value: An acciociative Array of the properties of the component.
This function returns an array with the properties of the component. All
properties are referenced by a Key and return a defined data type. See the
properties reference below.
Properties Reference:
Problem: Are the Default Values a good idea?
- MIDCOM_COMPMODE
Value Type: boolean
Default Value: TRUE
Defines, whether the component can be used in component mode or not.
- MIDCOM_LIBMODE
Value Type: boolean
Default Value: FALSE
Defines, whether the component can be used in library mode or not.
- MIDCOM_VERSION
Value Type: int
Default Value: 0
The Version Number of the MidCOM. For now not really used and here for the
sake of completeness.
5.2. Component Invocation, URL Parsing and Component Configuration
------------------------------------------------------------------
This part gets more interesting. First, MidCOM loads its configuration through
this interface. The snippet will also receive any tree-local configuration data
through this interface. It can be used to prepare everything. Later on in the
MidCOM runtime sequence the real processing invocation ("code-init") will
arrive through this concept class. This Interface has nothing to do with the
production of HTML Output. All Interface Code is accessed through the concept
5.3 "User/Admin Interfaces".
The important difference between the Concepet Classes "midcom" and "component"
is, that "midcom" is used for the management of the component system itself,
while "component" is the access point for actually running a component in the
Runtime System.
In library-mode only the functions configure, errcode and errstr are used.
Concept "Component Invocation":
class component {
function configure($configuration[]);
function can_handle($current_object, $argc, $argv[]);
function handle($current_object, $argc, $argv[]);
function errcode();
function errstr();
}
Concept Description:
- bool component::configure(Array[configkey => configvalue] configuration);
Parameter configuration: Contains an associative array holding all
configuration keys with their values attached to a given Object within the
MidCOM's domain.
Return Value: TRUE if configuration was loaded successfully, FALSE
otherwise
This function does two things: First it loads the global configuration
which is stored within the Component's _config Directory. After that it
will customize the MidCOM to the current situation at hand. It will receive
the local configuration through the configuration array by the MidCOM
Framework. It doesn't need to bother where exactly this data is
stored.
If the function returns FALSE, the error code and error string have to be
set accordingly, and the system will behave like in midcom::initialize().
Note: This function may be called repeadetly, since the same component may
be used in different locations in the content tree. Keep this in mind when
writing this function. Old configuration data may still be present.
- bool component::can_handle(MidgardObject current_object, int argc,
string argv[]);
Parameter current_object: It contains a copy of the object the framework is
currently processing. Currently this could be either a MidgardTopic,
MidgardArticle or MidgardAttachment.
Parameters argc, argv[]: All remaining arguments of the URL in a
Midgard-like form. All already processed items are removed.
Return Value: TRUE if the component can handle this specific request, FALSE
otherwise.
This function tests whether the component can handle the current request in
the given tree. It just has to decide exactly this, not more. The result of
a URL parsing process can be cached for later usage in component::handle(),
the system gurantees that can_handle will be called at least once before
component::handle() is called. If this function returnes TRUE, MidCOM stops
URL processing and initiates the display of the component after
component::handle() has been executed. If this function returnes FALSE,
regular URL evaluation will continue.
- bool component:handle (MidgardObject current_object, int argc, string
argv[]);
Parameter current_object: It contains a copy of the object the framework is
currently processing. Currently this could be either a MidgardTopic,
MidgardArticle or MidgardAttachment.
Parameters argc, argv[]: All remaining arguments of the URL in a
Midgard-like form. All already processed items are removed.
Return Value: TRUE if processing was successful, FALSE otherwise.
This function does the real preparation of the component display. If it
returns false, it has to set its internal state in a way that
component::handle_errcode and component::handle_errstr return the HTTP
Errorcode along with an appropriate message why the handler failed.
- int component::errcode();
Return Value: The HTTP Errorcode of the last component call. For
component::handle calls: 200 if everything was OK; 4xx otherwise. For all
other calls TRUE/FALSE for now.
This function is bound to some (yet to be defined) constants in the
errorcodes it can deliver. It is only queried if component::handle returns
false. Nevertheless it should return 200 while everything is ok, just to
stay consistent.
- string component::errstr();
Return Value: The error message of the last component call. Empty if the
run was successful.
According to component::handle_errcode this function returns an appropriate
error message. It is displayed in the Error Page that is returned to the
client. It should be empty in all non-error cases.
5.3. User and Administration Interfaces, Layout Management
----------------------------------------------------------
This interface class is responsible for the real output of a component. In
Library-Mode these functions are not available.
For Stage 1 only the content output section is filled in here.
Concept "Data Output";
class output {
function show_content();
}
Concept Description:
- void output::show_content();
This method is called to display the output accociated with the processing
done by the last component::handle call of the MidCOM in question.
5.4. Documentation
6. Preparing a Site for Components
----------------------------------
>> Allgemein:
>>
>> Ich w�rde diese default-fallbacks (topic/article-admin, urlparser-defaults)
>> nicht als bestandteil der komponentenarchitektur betrachten, sondern als
>> "mitgelieferte standard-komponenten". Die haben strukturell mit dem modell
>> nichts zu tun, ausser dass sie entweder in der globalen Initialisierung
>> speziell als Defaults registriert werden oder einfach per Namenskonvention
>> definiert sind.
Basically (not including MidCOM Installation...):
- Create the site, with a single, active page
- Write <[code-global]>:
Instantiate MidCOM Main Application Object
- OPTIONAL: Write <[code-global-local]>:
Put your custom Init Code here.
- Write <[code-init]>:
Call MidCOM's code-init-Method
- Write <[content]>:
Call MidCOM's content Method.
- Create Main Site Style, not referencing to any other page-element than
<[content]>
- Use MidCOM Functions to dynamically place Navigation Elements within
the Style tree
- Configure MidCOM Framework (most probable in <[code-global]>:
- Define root Topic
- ...
7. Using Components
-------------------
Basically the only thing you have to do is put a parameter to a Topic
referencing a MidCOM and, if necessary, some more parameters for detail
configuration.
8. Automated Administration Interfaces
--------------------------------------
-> Uses the same infrastructure as the public site to display the admin
interfaces of the different used components.
Using the same infrastructure you could easily create an automated
administration site. By default it gives you a standard interface (which is
defined in the configuration), but as it encounters other components, i.e. a
newsticker, the MidCOM framework loads the MidCOM's own admin interface. Here a
clear abstraction between layout and the application itself is very important
to provide a way to automagically merge the different administration
interfaces into a single admin site.
9. Advanced Style Engine
------------------------
-> Replace the <[...]> Syntax for Style-Elements with custom functions to
enable dynamic style switching.
An enhanced Layout Engine could be created, still using styles and elements,
but not accessing them through midgard but through custom fuctions. The
advantage here is, that you are not bound to use the style associated with the
active page, but any style available. Necessary to do this is a new layer
replacing the <[...]> Syntax with custom function calls that access the Style
Tree directly. Using this Interface, you could do automatic mapping between the
Layout Snippets of the component and an associated Style referenced by path
("/MyRootStyle/MyComponentStyle" and "/MyRootStyle/MyComponentStyle/myelement",
respectively).
10. Navigation Access Points (NAPs)
-----------------------------------
Each component should have a "navigation mode" for display that gives you
enough information to dynamically build navigation trees. It should not be
necessary to know the internals of a component to be able to build a
navigation system. Therefore several functions give you an abstract access to
this information.
11. Debugging
-------------
12. Security System
-------------------
13. Versioning
--------------
APPENDIX A. References
----------------------
From: "Armand A. Verstappen" <[EMAIL PROTECTED]>
To: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
Subject: Re: [midgard-user] RFC: Midgard Components, First Architecture Draft
Date-Sent: Samstag, M�rz 09, 2002 20:05:15 +0100
Just got up to speed with the long thread about Midgard Components,
great stuff!
I think our repligard system is a great concept, but also poses a lot of
problems. It mandates that all content be in the database if you want to
have a one-go replication process set up. As a result we kind of fork
away from the open source community, because the tools produced by the
community don't work for us in a comfortable way. vi, emacs, cvs, rpm,
apt-get, they are all of no use to us. (Well, not easily, that is)
The discussions in this thread made be combine thoughts and come up with
a 'serialize and bootstrap' concept, one that absolutely needs refining,
but potentially could be of great support to the MidCOM initiative.
CONCEPT
namespaces within the snippetdir/snippet hierarchy will be tagged as
filespace snippets. a utility 'bootstrap', can scan the configured
filesystem directories for files, wich will be imported as snippets, a
utility 'serialize' will flatten out existing snippet trees for writing
to the filesystem.
FORMAT
The format of the 'serialized' snippets must be of a workable design, so
that normal tools will work on it. So instead of using XML, we might
turn a snippet into a directory whith files for each of elements:
snippetdir/snippetname/GUID
/SG
/code
/author
/.... (etc)
a snippetdir should also hold files to discribe it properties.
If properly designed, this would allow us to use the timestamps and the
GUID to interface with repligard to do the bootstrapping/serializing.
This would enable us to use existing packaging tools to distribute
aplications, use cvs in shared development, etc, while still having
repligard at the core.
APPENDIX B. Roadmap
-------------------
Stage 1: Basic implementation
Implement the basic features of the MidCOM framework. Automatic Component
loading, replication safety. Drive everything directly from the snippet tree,
no automatism for Layouting or so. Administration will be done solely by hand
via your favorite parameter-capable admin interface.
Stage 2: Enhance Layouting
Prepare the system to relay layouting to a specified style. Route all style
requests to a style specified in the configuration.
Stage 3: Navigation Interface
Provide a way how the style can access MidCOM to dynamically build a
Navigation hierarchy. This has to be independent from the specified
components. Develop an access interface for this.
Stage 4: Automatic Admin site
Build the necessary Infratstructure that administrative sites will be
created automagically -- including a comprehensive way to modify the
look & feel of the generated sites.
Stage 5: Packaging
Build an automatic way of distributing and controlling MidCOM packages.
Preferred is something like apt-get, preferably controlled by the
Automatic Administration Site.
Stage 6: Start playing around
Add the favourite Feature of your choice that is missing. A lot could be
done: A full fledged debugging system, a security interface which builds an
ACL controlled access control system into MidCOM, complete Versioning with
the possibility of automatic upgrades both of MidCOMs and MidCOM Data
Elements and ... and ... and ...
APPENDIX C. Ideas
-----------------
(-> things to incorporate into the rest of the document)
- Inheritance has to be enabled explicitly for each subtree if desired. If no
Component handler is defined either through direct accociation or through
inheritance, a predefined default Component is used.
- Idea: It could be possible to define mulitple component handlers for a single
object, especially if using inheritance. Along with a precedence, MidCOM would
traverse the list of handlers and execute the first one, that actually declares
to be able to handle the request.
===============================================================================
$Id: midgard-components.txt,v 1.15 2002/04/04 16:13:40 torben Exp $
midgard-components.txt.sig
Description: PGP signature
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
