I'll pipe in with some answers for OpenInteract2 (the latest beta of
which was just released to CPAN, FWIW). You might have seen
OpenInteract 1.x in your survey but this version has some dramatic
differences in architecture and documentation. (It's pretty much a
rewrite, although a number of core concepts remain.)
On Dec 6, 2004, at 11:05 PM, David Christensen wrote:
I'll start by throwing out a rough wish-list that we can all critique
and modify:
1. On-line user/support community.
Sourceforge, JIRA issue tracking, mailing lists, usual.
2. Separation of function (code), presentation (templates), and
content
(database).
You bet.
3. Genuine Perl; preferably 5.8.
It's pure-perl. I dunno what 5.8-isms are useful.
4. Open-source de-facto standard language(s) and tools for the
framework itself and all associated infrastructure used to work on it
and the products built with it.
It's all Perl, although the templating engine is Template Toolkit (by
default) and configuration is mostly modified-INI files.
5. Perl Artistic License.
Yes.
6. Strong security.
Do you mean the code itself is secure? As far as I know. I think
there's only one place where we shell out to do something and that will
be gone soon.
7. Documentation -- architecture, design, implementation, test,
programmer's guide, designer's guide, author/editor's guide,
administrator's manual, etc..
Architecture, design and programmer's guides are pretty solid. Nothing
on testing. Not terribly much on gui-type authoring (since we rely on
other templating engines for us).
You can see the html-ified docs for the latest release online:
http://www.openinteract.org/docs/oi2/
8. OO design and implementation.
Yes.
9. Ability to sub-class to modify functionality.
Most pieces of the system can be swapped out at deploy-time and
run-time.
10. Ability to create and easily add/ remove/ manage/ monitor plug-ins
to add functionality.
OI (1.x and 2.x) has distributable application packages. Each package
has its own database structures and initial data (and initial security
settings) plus code, configuration files and localization messages. And
each one is installable/upgradeable/removably by itself.
11. Built-in functionality: user accounts, groups, privilege levels,
home pages/ sub-sites, storage management (quotas), search,
friendly/short URL's, search engine friendly/compatible.
Users, groups, privileges, search: yes.
Friendly/short URLs: sorta -- most use query strings to indicate
parameters, but I think the next beta will have support for:
/MyApp/action/display/1586
instead of:
/MyApp/action/display?object_id=1586
Home pages, quotas: no.
Subsites: no ( I think).
12. Plug-in functionality: threaded forums, issue tracking/ticketing
system, CVS client, photo gallery.
Forums: Comes with a basic commenting system (attach comments to any
object).
Everything else: it's not PHP Nuke. There's not much of a community to
share these because OI tends to be used for internal applications. I
know the Dicole folks (http://www.dicole.com/) use OpenInteract2 as a
core part of their main product and have a number of community-type
features available.
13. Version control and content management system capabilities.
Not built-in.
14. Information architecture hooks.
Not exactly sure what this means. Many interesting parts of the system
can throw events and objects can register to listen for those events
and react accordingly.
15. Off-line and on-line development/debugging/test environments for
coders and designers.
Not yet. You can run OI2 in a 'standalone' environment -- not using a
web server at all, submitting requests programmatically -- but it's not
used very often yet.
You can use the same application packages and configuration from
different environments. So running a standalone LWP server and under
mod_perl only requires changes to their respective configuration files
(e.g., apache.conf), nothing else.
Debugging support is pretty good because we're using the log4perl
package. So it's simple to modify system-wide logging or to confine
debugging levels for individual areas.
16. On-line WSIWYG development environment and workflow for
authors/editors.
Not built-in.
17. On-line WSIWYG development/debugging environment for novice users
to
create simplified/restricted code, presentation, and/or content.
Not built-in.
18. Comprehensive regression test suite for framework and anything
distributed/supported with it.
Test suite: yes; comprehensive: not yet. In particular, application
packages don't have testing support yet.
19. Ability to run on well-featured shared Linux web hosting accounts.
It does work with a plain CGI interface, but I wouldn't recommend it.
Anything with all these features takes some horsepower, otherwise
you're building up and tearing down a lot of information with every
request.
20. Ability to backup and restore while operational.
Probably. I haven't tried it, but I guess it depends on your database.
We
