develooper Front page | perl.p5ee | Postings from December 2004

Re: The P5EE dream is alive, was: ping...

Thread Previous
From:
Chris Winters
Date:
December 7, 2004 22:42
Subject:
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 
> 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 can store sessions to the filesystem rather than the database and 
can do some caching of commonly used objects there (user, groups, 
etc.).

Good luck!

Chris

--
Chris Winters
Creating enterprise-capable snack systems since 1988


Thread Previous


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About