Re: Permission module and documentation

Hi

Simon brought up some interesting topics regarding Flux CMS. I will now
answer them here on this mailinglist (he's ok with it :) )


> Well about convincing myself and them of Flux CMS beging the right choise...
> A few requirements and wishes are to be met:
> - a possibility of LDAP autenthication should be possible

We use PEAR::Auth as authentication container, so LDAP shouldn't be a
problem. Furthermore the whole auth/perm part is completely replaceable,
meaning you can implement your own Auth/Perm container without having to
use PEAR::Auth. But just for LDAP, PEAR::Auth should be enough.

> - MySQL 5 support (MySQL 5 isn't nessecarily always backwards compatible)

Our SQL Queries are pretty "simple" and not necessarily written only for
MySQL. You may find a "REPLACE INTO" somewhere and we use the FULLTEXT
index for the livesearch, but in general it's pretty standard SQL.
Having said that, we are only testing the CMS on MySQL 4.x currently, so
any other RDBMS won't almost certainly not work out of the box, but the
necessary adjustements should be minimal. About MySQL 5, Silvan tested
it shortly on his laptop and it seemed to work. We will certainly also
switch to MySQL 5, when we need some of its features.

By the way, we use now ext/mysqli instead of ext/mysql, if the installer
finds the extension (but you can easily switch later via config.xml) and
finally improved the UTF-8 support, when using MySQL 4.1 (both features
are in trunk, but not 1.3)

> - XML output/input for integration between other existing PHP-scripts that the 
> school is already using (ie. room booking, schedules, courses and what not).

There are about a dozen different ways to integrate such externals
scripts :) On the lowlevel via popoon, on an upper level as CMS plugin
or even just including them in the XSLT. It depends a little bit, what
you exactly need, but Flux CMS is quite flexible with that.

> - scalability (we'd need to easly be able to add functionality whenever 
> needed)

"Functionality" is a broad term. Adding new plugins and new features on
that is certainly possible, once you know how it works.

"Scalability" is also a broad term :) In terms of performance, flux cms
is quite scalable thanks to the mysql replication support and built in
caching (although the caching part could be made more intelligent than
it is now)

> In addition to this I (and any upcoming webmaster) should be able to feel like 
> I've (he/she's) got a somewhat overall understandning of the CMS/framework... 
> which I can't say that I have a the present moment. Simplicity and standards 
> are keywords here, at least when it comes to standards Popoon/Flux CMS does a 
> great job. Feeling comfortable with making plug-ins is a must.

Making new plugins has gotten much easier with the new plugin generator:

http://devblog.flux-cms.org/archive/2006/01/07/build-your-own-flux-cms-plugin-in-an-instant.html

It's really not that hard making new plugins, but once again, if you
know how to do it :)

> The biggest problem is the lack of documentation, but a good thing is that 
> you're giving very helpful support through the mailinglist. The downside is 
> just that one is dependent on your continued helpfulness and time for it.

Yes, we know. Documentation is a problem on that project. We currently
just don't have the resources (neither financally nor time-wise) to do
proper and easy-to-read documentation. We have basically to decide, if
we just don't care about it (meaning, you always can ask, if something's
not clear) or if we want to try to build a bigger community. The latter
would maybe some day pay off for us, as others may contribute faster and
easier to the project than it is now. But there's no guarantee for that
for us and it would be a long term investement.

Currently, the documentation is a mess, we have this mailinglist, we
have the forum (basically for freeflux users), the blog,
docs.bitflux.org and the wiki. All have its pros and cons and I don't
want giving up any of them, but if we want to go serious about the
docoumentation part, we have to put that on a central place and collect
together the different sources. docs.bitflux.org would certainly be a
good place for that, in general. At the end, the docu should be
book-like (IMHO), with links to the other sources, where it makes sense
and it's more detailed. For example for work in progress, the wiki is
certainly a good place, for news the blog, etc...

But as I said, we don't have the resources currently to write a
book-like documentation. OTOH I count a little bit on the community
here. So, if a few people of the community are ready to maintain the
documentation, we would certainly help out. Set up something useful,
contribute and proof read the stuff and where it really needs some in
depth knowledge of course also contribute to it.

Alain is currently writing a plugin for his semester thesis at his
university and as far as i remember, he plans to write some
documentation as well. That could be a good start.

When I talk here about documentation, I mean developer or administrator
documentation, not end-user documentation. That part is not that
difficult (and we already have some stuff) and Flux CMS isn't very
difficult to use for end-users (meaning people who edit content).

> Another thing is that there should be a reason why to use Popoon/Flux CMS, I 
> like it for being built on standards, but I'm not sure about what sense the 
> Cocoon-like architecture makes for us.

First, Popoon is not really A-whole-Cocoon-in-PHP :) We basically just
took the pipeline idea and most of their syntax and used that for
Popoon. Cocoon has many many more features than popoon ever will have
(popoon is basically quite feature complete for our purposes), therefore
you shouldn't be scared by the "big architecture behind" topic. Popoon
is more or less just the pipeline/generator/transformer/serializer idea
of Cocoon and not that heavy in requirements. We use Popoon just as
underlying framework, 'cause it makes some stuff much easier. The heavy
part happens on the Flux CMS level, which is on top of Popoon. We have
to change the sitemap or add new features to Popoon very seldom and if
we have to, the framework makes it pretty easy. See for example qMax's
addition of last week, all it needed on the Popoon level was an
additional transformer.

We could ditch Popoon today and write our own, more Flux CMS specific
output framework, but i don't think we would gain much, as we would end
up in something quite similar and as I said, the whole overhead of
popoon is quite negligable.

If your just developing for Flux CMS, you don't need to touch Popoon,
maybe just adding some new pipelines, if you do a new editor or new a
new output type.

> I once grabbed a book about Cocoon, but as most available books it's very 
> outdated. In the book the main motivation for using Cocoon is multiple 
> outputs, different HTML for different browsers as well as WML and maybe PDF. 
> This is not really so useful anymore when using standards compliant XHTML & 
> CSS design, so I was left wondering what the benefit of Cocoon/Popoon could 
> be today.

It's still useful and some people still want PDF. And even with CSS and
XHTML, you don't want to deliver the same content to mobile devices for
example (due to bandwidth restrictions). I think, you still need the
cross-media support in such a framework, you can't deliver everything in
XML/XHTML and CSS.

> I also found that there are many other CMS:es using XSLT for templating, but 
> not Cocoon pipelining. (There is ie. a quite new Finnish project is using a 
> kind of MVC-structure using XSLT. http://angelinecms.info/ ) This seems like 
> a wise idea, especially since we've got existing PHP-based scripts which 
> could be modified to output XML to be formatted and integrated in the CMS 
> using XSLT. (Using a binary XSLT engine also gives much better performance 
> than a template system built in PHP, of course.)

As said, ditching Popoon for something different wouldn't gain us much.
We would end up in something similar, just different syntax maybe. Or
where exactly do you see an advantage in that? Integration of other PHP
scripts is IMHO the same problem with Popoon as with something not
Cocoon-like.

> Another thing I'm wondering is, if I'd study litterature on Cocoon more 
> deeply... would this mean that I'd very easily get an understandning for 
> Popoon/Flux CMS... or is it too different?

The Pipelining/generator/transform/serializer/matcher concept is the
same, the syntax of the sitemap.xml very similar. But looking closer
into the components of Cocoon doesn't make much sense, IMHO.


>>>What I need is a plain, simple, scalable and preferably standardsbased
>>>framework (ie. XSLT=good, uncommon proprietary things=bad :-), so that
>>>it'd be easy to extend it according to future needs, as well as maybe
>>>letting somebody else do it (proprietary=bad ;-). FluxCMS/Popoon looks
>>>promising, but the documentation is too incomplete. Please write a book
>>>(in Enlish) soon... ;-)
>>
>>Yeah, the same as before. Documentation doesn't bring us actually money,
>>so it has a very low priority .) And noone here in the office really
>>likes writing it, obviously :)
> 
> 
>   Well, I guess this is a common problem with opensource things...
> Of course writing books could bring money, but then the subject needs to be 
> famous enough.

Writing books doesn't bring very much money, I can tell you :) and I
don't think a Flux CMS book would be a big bestseller. If we're going to
write a book-like documentation, it would be open, IMHO. We can only
gain momentum this way, writing a hardcopy book and try to selling that
wouldn't help much at this stage of the project.


> (If I'd be better in German I would have bought your book. ;-) 
> I think the smartest thing you could do when it comes to documentation would 
> be to suggest what books/other documentation (ie. about Cocoon, XSLT, PHP5 
> and so on) people could read, and then write documentation only for the 
> Popoon/Flux CMS specific stuff.

Sure :)

> Do you have any ideas of other CMS:es/frameworks that could be of interest, in 
> case Popoon/Flux CMS wouldn't be the best choise?

Honestly? No :) Apache Lenya maybe, but that's also cocoon based.. Other
people are better to judge that and maybe have some feedback on that.

Hope that clearifies some things, if you have more questions, just ask.

chregu
-- 
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