Front page | perl.p5ee |
Postings from December 2004
Re: The P5EE dream is alive, was: ping...
From: Chris Winters
December 7, 2004 22:42
Re: The P5EE dream is alive, was: ping...
Message ID: 5097A08A-48E4-11D9-AAD2-000A95DBDB3A@cwinters.com
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
> 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.
> 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:
> 8. OO design and implementation.
> 9. Ability to sub-class to modify functionality.
Most pieces of the system can be swapped out at deploy-time and
> 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:
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
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
> 13. Version control and content management system capabilities.
> 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
> 17. On-line WSIWYG development/debugging environment for novice users
> create simplified/restricted code, presentation, and/or content.
> 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
> 20. Ability to backup and restore while operational.
Probably. I haven't tried it, but I guess it depends on your database.
We can store sessions to the filesystem rather than the database and
can do some caching of commonly used objects there (user, groups,
Creating enterprise-capable snack systems since 1988