Flux.net
From Wikipedia, the free encyclopedia
| Flux.NET | |
 |
|
| Developer: | HG Interactive [1] |
|---|---|
| Latest release: | 2.0.0 / 20-02-2007 |
| OS: | ASP.NET / Microsoft Windows |
| Use: | web application framework |
| License: | GPL Open Source |
| Website: | http://www.hginteractive.co.uk/ |
Flux.NET ECMS (Enterprise Content Management System) is an open source content management solution and web application framework created in C# for the ASP.NET 2.0 framework using Microsoft SQL Server 2005 (including express editions). The system is extremely extensible and customizable through its advanced plug-in architecture and its exposed developer APIs. Developed in the UK by architect and developer Tony Johnson, the system was originally planned as a commercial release through the company HG Interactive, but instead in 2007 the first major release of Flux was launched as an open source platform.
Contents |
[edit] Features
The application is an enterprise class content management and application framework. Broadly it offers the following features;
- Browser based management of your website, intranet and/or extranet
- Granular, roles based security
- Intuitive and familiar user interface
- In-built auditing, accountability and tracing
- Workflow and business process engine
- Customisable content approval processes
- Asset and file management tools
- Unlimited types of content
- Template based content management
- WYSIWYG editing of HTML and X-HTML content
- Taxonomic tagging of content
- Manage websites that are accessible
- Intelligent and search engine friendly URL's
- Inbuilt portal engine
- Highly extensible and customisable application
- Modular based system
- Multi-language websites
- Powerful API and application framework
[edit] Extensibility
The application can be extended in a number of different ways. As you would expect the system is designed to allow a developer to create relational content types and to write templates for the rendering of these on a site via whatever means necessary. In addition to this usual CMS extensibility the framework and application itself can be manipulated, changed and extended without making custom builds of the core application.
The entire core FLUX application utilises an add-in infrastructure that allows developers to override current and normal behaviour. If the current menu structure isn't how you would like it or if you want to remove options without the need to configure roles based security you can override menu behaviour by creating an addin definition file in your web application. Addin definition files are loaded in a particular sequence, allowing you to override whatever behaviour the core system prescribes with your own behaviour. This allows existing elements of the application to be tweaked as necessary.
Moving on from here FLUX provides a comprehensive API for writing administrative extensions that plug in to the main UI. Developers can extend the core functionality using the API and the add-in infrastructure. By creating directories and populating them with structured XML, developers can modify and extend most things on the system and integrate their own applications with the solution very easily. These applications can make use of the installation API's to allow their addins to be installed side-by-side with other third party extensions, components and applications.
Finally, by writing your application to make use of the add-in infrastructure and API, your custom applications also benefit from the add-in architecture's ability to inherently be extended. Because of this, when you create your own custom application using the add-in infrastructure your application becomes extensible also.
[edit] Roadmap to v3
The first public release of FLUX is stage one in the roadmap for the project. In the V3 release, the project team intends to add the following facilities;
- Portal / Webpart engine
The portal engine will allow templates to specify zones where portlets/webparts can be scheduled to appear. These portlets would be discreet pieces of functionality that display information onto the page in context. V3 will ship with a number of standard portlets including HTML Area, Image etc. Most interestingly will be the aggregator. This portlet can be placed in a portlet zone on your page and told to query the content repository in almost any way imaginable. This will then integrate with the new render methods exposed against content types to allow the found content to be rendered accordingly. For example, an aggregator may be scheduled onto a page and instructed to find the latest 5 news articles with given taxonomy categorisations. The render method called against the items could be summary, which would be coded to show only the title of the item, the first 255 characters of the summary meta data and a link to the item itself.
- Render methods
Conventionally the system works with content objects using a single template as it's primary display mechanism. Render methods allow content items to be re-used in various other ways. A render method is simply an ASCX definition that takes a content object of the appropriate type and knows how to render it differently. This allows content to be re-purposed and re-used in different scenarios.
- Browse edit mode
The browse edit mode will be a feature introduced to work alongside the portal/webpart engine. By logging into the site, the content administrator will be able to navigate as a normal user would, but will have the ability to check-out and edit the current page, add an item to the current page being looked at. In addition, to support the portal engine a drag and drop interface will be available to allow the content editor to add portlet information onto the page quickly and easily.
- Template gallery
Presently the templates on the system are all contained in a single level. In V3 these can be categorised by taxonomy allowing for more efficient grouping of content type templates on larger systems.
- Content Tree administrator security
Presently roles based security grants users the ability to access the content tree or not. In V3 this will be extended to allow nodes in the content tree to have deny/read/write levels for administrators and groups. By doing this certain users or groups can be configured to grant or deny access to different areas of the content tree.
- Content Tree workflow configuration
Presently the content management application allows selection of any content workflow when submitting for approval. V3 will offer the ability to configure what workflows are available to who for different areas in the site. Eg: High level administrators may be able to instantly publish their content, whereas lower level users might have to select one of the approval processes when editing content in important areas of the sites.
- Side by Side preview for history and workflow (for sites using internal URL Re-writing)
The preview functionality of version history and workflow will be extended for V3 to show old versus new side by side. This will be a great help when deciding which version to rollback to or whether to approve some content changes or not.
- Cancel check-out
In V2, when you check-out content, you have to ultimately check it back in. Sometimes you might decide to abandon the work you've done on a version and in V2 you would be forced to use the rollback facility to go back to the last version. In V3 you will be able to simply cancel a check-out to return to the previous published state.
- Atomic check-ins
In V2, when you check-in several changes to your content repository, each item is treated in isolation as a separate check-in. In V3, the version control system will support atomic check-ins and changesets. This will still allow individual items to be checked in separately and exclusively, but where multiple items are being checked in together this will allow that group of check-ins to be marked as one whole changeset. As such, whole changesets can be committed together and maintain their atomic relationship and whole changesets can be rolledback as necessary.
- Open to view
The open to view facility will allow the form for a content item to be opened in a read only state when the item is checked in to version control. For instances were you need to just quickly check the data on an item or such like this tool will be very useful, negating the need to check the item out just to view it.
[edit] Critisisms
Presently the application, whilst browser based, requires clients to use a Microsoft Windows based PC with either Internet Explorer or Firefox. These limitations mean that unix, linux and mac users are presently not catered for in the administration of Flux.NET websites. In addition the browser based administration interface is only available in English. The team at HGi are working on making their administration tool more available cross platform and in additional languages.
