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. [EMAIL PROTECTED] 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
