Re: some questions about bxcms architecture

Sorry for not anwering. We're really busy right now. I'll try to find 
some time. But you're questions are not answered in 5 minutes or so :)

chregu

On 20.3.2006 11:00 Uhr, qMax wrote:
> 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 :)
> 

-- 
christian stocker | Bitflux GmbH | schoeneggstrasse 5 | ch-8004 zurich
phone +41 44 240 56 70 | mobile +41 76 561 88 60 | fax +41 1 240 56 71
http://www.bitflux.ch | [email protected] |  GPG 0x5CE1DECB
-- 
bitflux-cms mailing list
[email protected]
http://lists.bitflux.ch/cgi-bin/listinfo/bitflux-cms