some questions about bxcms architecture

Hi.

There're some points in bxcms design that confuse me a little.
I'd be happy if someone can find a pair of minutes and explain these
moments for me.

1. plugins/resources
The role of (non-admin) plugins is mainly to generate content, adding
resources (in id-space), and sometimes provide links to editors of this content.
They map request into plugin-specific content id and responcible to
retrieve it by id.
For static content, it is stored in resources, as files in filesystem,
plugins delegate getContentById to bx_resource classes.
For dynamic content, it seems that it's intended to be retrieved through
php-streams, plugins delegate getContentById to bx_stream classes.

Now if i want to store (the same images or xhtml pages) resources in database,
I can write bx_resource that retrieve content from database.
Or, they just provide contentURI referring to some database-related
stream.
But anyway i have to hack all plugins to make them use such resources,
since classes are hardcoded in plugins code.
I cannot just configure plugins to use another (re)source.

Should i implement another stream+resource+plugin for this situation ?

Reallife possible example: retrieving info about people from ldap.

2. output-mimetype property
Some resources has this property, but it is not clean what does it indicate.

When having some resource, a user might want to request it in various
formats: txt, png, pdf, rtf...
So mimetype of resulting output differs for the same resource.

In code it is mainly used just to tell httpd/unix-directory and
text/html from other types.
(in bx_plugins_tree, bx_plugins_sitemap, bx_plugins_fulltree,
popoon_components_generators_admintree, )
and to match if plugin handle this type (bx_plugins_subcontent,bx_tree).

Does it have some other use ?

3. sitemap vs configxml.
If i figured out right, the purpose of collection .configxml file is:
- matchi request and select a plugin that provide content
- provide parameters for plugin
- selecting xslt theme stylesheet
- setting pipeline parameters (used only for xslt transform)
- selecting filters

These points are exactly what cocoon/popoon pipelines are designed for:
- map:match used to select pipeline based on request (or some other criteria)
- map:generators used to generate content
- map:transformers used to xslt transform and filtering
- map:paramater used to provide parameters to generators or transformers.

So, theoretically, a random configxml may look like:
<sitemap>
 <match type="uri" pattern="*/**">
   <!-- stuff for children collections -->
 </match>
 <match type="uri" pattern="$filename.$ext">
   <aggregate element="bx">
     <generate type="plugin" name="navtree"/>
     <generate type="plugin" name="$somepluginname"/>
   </aggregate>
   <call-resource name="theme-transform">
     <param name="xslt" value="$stylesheetname"/>
   </call-resource>
   <transform type="$filtertype" name="$filtername"/>
 </match>
</sitemap>

The configxml however, can be inherited and overloaded in child
collections, which is somewhat tricky for sitemaps.
Beside this and some trick about adminplugin
? what are advantages of using configxml-style instead of more clean sitemap-style ?

Thanks in advance :)

-- 
 qMax

-- 
bitflux-cms mailing list
[email protected]
http://lists.bitflux.ch/cgi-bin/listinfo/bitflux-cms