Description:
Daisy is a content management development framework that ships with a sophisticated in-browser editing application, a scalable repository back-end, which is accessible through open standards, and a flexible, role-based authorization control system. It features robust and flexible XHTML and media asset management, full-text indexing and searching, document versioning and differencing, user-defined metadata management and integration of external systems through event queuing (JMS). Its SQL-like query language offers in-page embeddable queries and can be used to define virtual views on the document repository. Daisy has no outside dependencies except for a relational database and access to a filesystem, making it an affordable, yet surprisingly powerful content management system. Daisy consists of a standalone repository service, integrated with an Apache Cocoon-based Wiki-on-steroids CMS front-end application.

Author: Outerthought
Homepage: http://outerthought.org/

App rating details:
Total votes: 3
Overall rating: 9.00

How'd this get started?: Steven Noels: "A customer, who we did xReporter already with - a web-based database reporting engine - wanted to work with us on the core foundation of his future CMS products, and at the same time tackle the information overload most IT shops with many customers and projects deal with. From our experience hosting the Apache Cocoon Wiki for two years, he first started using a simple Wiki engine, but after deciding on a unified approach for both project, we ventured into looking what was out there. Cocoon was more or less a given since we had been consulting with him on the use of that webapp framework. For the repository, we spent some time evaluating a number of solutions out there, but in the end we decided to do our own thing. We wanted to follow the same architecture pattern we used in xReporter, with a standalone, ReST-accessible repository service, and a separate user application (the Daisy Wiki) connecting to the repository server through HTTP and XML.

The reason we jointly open sourced it was mostly to try and attract other parties interested in a similar project model, with paid development being feed back into an open source project. We already did that with xReporter, where subsequent releases of xReporter contained new features, some of them funded and some of them based on voluntary contributions by other developers, for which the original funding customer didn't have to pay for - he could simply install the new release and enjoy the new stuff.

We envisioned a different repository model than what was usual little less than a year ago: namely a hierarchy-free model with lots of metadata which could be used for searching and classifying repository content. We felt the Wiki idea was well suited for that, but added access control and rich text support on top of that."

Daisy's Most Impressive Features:

"First of all, there's the rich text editing available through the Daisy Wiki application. We use HTMLArea, a number of our own plugins and some sophisticated cleanup machinery to make sure people can edit documents in an inline WYSIWYG editor, across the two major browsers (Mozilla & IE), generating clean XHTML stored in the repository - which can be used for PDF generation through FOP. We also provide nice content diffs between versions.

Next is the Daisy Query language, which is very similar to SQL, and which provides simultaneous access to all metadata and document content (through Lucene fulltext indexing). People can embed searches inside documents, and even include search results as documents (not lists) inside other documents. Searches can also be used inside navigation trees for dynamically-created views on sections of the repository content. Daisy runs on top of MySQL and a Lucene fulltext index, with work under way to make it run on PostgreSQL as well. We're pretty close to that ATM actually, but that will ship in a next release.

For access control, we have the usual users and roles. The ACL is centrally defined however, and we make use there of the the Query language as well. That way, people are free to set up any ACL model they want. An ACL rule consists of three components: who is allowed or denied something (using the users/roles), what they are allowed (read/write/change status), and what documents are governed by a given rule. This last part is defined using the Query language, and can be any sensible query, like "documents for which this metadata field has that value", "documents in a certain collection", or anything else. The fact that all ACL rules are centralized makes it much easier to find out what rules are in effect, and makes complex ACL rulesets more manageable.

We also have a notification service running in the repository, accessible across JMS. Daisy ships with an email notification service making it easy to subscribe to repository change events, such as documents being added or edited, user management changes, etc. The notification services could be used for other applications as well, such as a full-blown workflow system.

On the publishing side, people can include documents into other documents (with recursion detection), embed searches and search results into documents as well, and we use all the nice Cocoon machinery for PDF generation, i18n, and have some nice image/attachment upload stuff as well. The hierarchy of a Daisy site is kept in separate XML navigation trees, so that people can publish different websites (or views) out of a single repository.

The entire repository functionality is available across HTTP/XML, but we also have a high-level Java API (independent from Cocoon) which hides the HTTP stuff from a CMS developer.

...the automatic customization of the document editor, depending on user-definable documenttypes. What we have seen with other systems is that quite often, if one wants to change the structure of a "document" (which in Daisy's case means what Parts and what Fields are required for a certain class of document, all strongly typed) one needs to change UI code as well. In Daisy, the editor adapts itself automatically to the document type schema, with field or part entry tabs being added to the editor. This comes from our CForms heritage and knowledge. While a Part contains free-formed HTML rich text, the overall document that contains such a Part is a validatable object. So in a sense, this model can be used to manage any kind of information - though one shouldn't replace all archetypical CRUD RDBMS application with it of course."


[ Download Daisy now! | Get Support for Daisy at LinuxQuestions.org ]