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

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

Thread Previous
From:
Rob Nagler
Date:
December 6, 2004 21:47
Subject:
Re: FW: The P5EE dream is alive, was: ping...
Message ID:
16821.17379.670248.915626@gargle.gargle.HOWL
David Christensen writes:
> Richard Dice wrote:
> > What kind of features are you looking for in such a framework?
> 
> Tough question.  I guess it really depends upon my perspective (coder)
> and what I'm trying to build (ideally, anything that can be seen on the
> web now or in the future).

Nice list.

Since you were kind enough to find two bugs in the bOP petshop
tonight... :-)

> 1.  On-line user/support community.

Bivio-bOP@yahoogroups.com is the nominal place.  We haven't really
announced this before.  We don't "sell" bOP to anybody but our
customers.  It's free if you want to use it, and we'll support you
probably, but we're not in the business of selling frameworks.  We
write applications, and bOP is a side effect.  We license it OSS so we
don't have to discuss licensing with our clients.

> 2.  Separation of function (code), presentation (templates), and content
> (database).

Yes, and you'll also want to separate out facades (skins),
security, and presentation formats (pdf, html, xml, csv, etc.).

> 3.  Genuine Perl; preferably 5.8.

Yes.  Although people have complained that it isn't Perlish.  I always
thought Perlish meant TIMTOWTDI, but there ya go. ;-)

> 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.

Pure Perl.  The template language is Perl, too, unlike other template
systems.  Although, you don't need to use our template language.

> 5.  Perl Artistic License.

LGPL.  Perl Artistic License is badly written.

> 6.  Strong security.

All requests (Tasks, really) are validated by the user's role in the
current realm and what permissions the task requires and what
permissions the role has been granted in the current realm.  Models
have "auth gateways" that force the current realm onto the query.  Can
be easily circumvented, but you have to do so explicitly -- which you
can do anyway with poorly written code, but we make it easy to do with
clearly-identified verbs like unauth_load.

> 7.  Documentation -- architecture, design, implementation, test,
> programmer's guide, designer's guide, author/editor's guide,
> administrator's manual, etc..

Someone wrote a tutorial fairly recently that no one read so we
haven't bothered with docs.  What we rely on is clear, simple code
with an example we keep up to date (most of the time ;-), and run
nightly tests on.

http://paulgraham.com/popular.html sums up the philosophy behind
bOP.  My book http://www.extremeperl.org explains the process by which
bOP evolves.

> 8.  OO design and implementation.

Yes.

> 9.  Ability to sub-class to modify functionality.

Yes.  Moreover, classes can be "delegated".  For example, you might
want to override our default cookie handling, but not change all the
code where the cookies are referenced.  You do this by adding a
line to your configuration file:

    'Bivio::Agent::HTTP::Cookie' => 'MyApp::Delegate::Cookie',

All calls to the Bivio::Agent::HTTP::Cookie class and its instances
get routed to MyApp::Delegate::Cookie, even for methods that have not
been defined in Bivio::Agent::HTTP::Cookie.

> 10. Ability to create and easily add/ remove/ manage/ monitor plug-ins
> to add functionality.

Not sure what you mean by plug-ins.  bOP indirects many entities, such
as, Models, Widgets, and Views, so that you can override or add to
default behavior.

> 11. Built-in functionality:  user accounts, groups, privilege levels,

Yes.  Groups are called clubs (bOP spun out of bivio.com, a site for
investment clubs).

> home pages/ sub-sites,

Yes.

> storage management (quotas),

We currently don't make this available, because it is tied to Oracle
in bivio.com.  We are looking into ways of generalizing our file
storage, but we're swamped with other projects right now.

> search,

Google. ;-)  We relied on Oracle's Intermedia for a long time, but
finally canned it recently.  Now searches are blazing with Google, but
we lose out on non-public searches.

> friendly/short URL's, search engine friendly/compatible.

You can have any URL you like.  You can have multiple URLs for a
single task, which is useful for maintaining backward compatibility
with old URLs.

> 12. Plug-in functionality: threaded forums,

http://www.bivio.com/club_cafe is an example.  This code is fairly
trivial, because it reuses the builtin drilldown table functionality
in bOP.

> issue tracking/ticketing system,

On our wish list, but there are so many free ones.

> CVS client,

Don't understand. Is pserver not good enough?

> photo gallery.

Visit paintedsnapshot.com for an nice example.  This site took about 3
weeks of one programmer's time to launch.  Most of the functionality
is administrative so you can't really appreciate the complexity.

> 13. Version control and content management system capabilities.

No.

> 14. Information architecture hooks.

Don't understand.

> 15. Off-line and on-line development/debugging/test environments for
> coders and designers.

Yes. Our unit test framework allows you to test a task outside of
Apache.  For the most part, though, you need to use apache.  The
acceptance test framework is easy to use.

> 16. On-line WSIWYG development environment and workflow for
> authors/editors.

Nope, but people have used DreamWeaver to do the UI for bOP sites.  We
may generalize this (although the code is trivial) so that you could
define easily define tags for views or view "parts" that DreamWeaver
developers could insert and move around.

> 17. On-line WSIWYG development/debugging environment for novice users to
> create simplified/restricted code, presentation, and/or content.

bOP is not for novice users.  That's what PHP is for.

> 18. Comprehensive regression test suite for framework and anything
> distributed/supported with it.  

Yes, sort of.  We are still adding unit tests for bOP.

> 19. Ability to run on well-featured shared Linux web hosting accounts.

No.  You can rent a standalone server for less than $100/month.  Any
reasonably complex application will cost orders of magnitude more
money to develop, and will require a dedicated server -- if for
nothing else, than for ensuring your app's security isn't in the hands
of someone outside your organization.

> 20. Ability to backup and restore while operational.

bOP is stateless, that is, there is no concept of a session.  The
framework controls the commits, which happen at the end of a task.
This means the database is responsible for state management, and the
state should always be consistent.  All of our systems are live 7x24,
and we run live exports and run remote standby databases.

Some things bOP provides that are not mentioned above: tracing
(selectable at class and statement levels), logging, simple (perl)
configuration, OR mapping, (server-side) stateless form nesting,
sendmail/postfix integration (all email is processed through Apache
via a gateway from sendmail/postfix), and SQL/HTML/XML/etc. type
mapping.

Caveat: I personally don't recommend bOP any more.  I think there are
many useful concepts in bOP, but due to bOP's highly-refactored
nature, it's extremely complicated and difficult to understand at a
practical level.

Rob


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