On 10 Aug 2007, at 00:33, Martin Flack wrote: > A brief sketch of the current dispatch: > > Bibliotech::Apache runs the dispatch. Bibliotech::Parser > understands the URI passed in, and returns a Bibliotech::Command > object. An appropriate Bibliotech::Page object is created, which > provides a last_updated() method and an html_content() method that > return results (similarly, it is ris_content() or rss_content() > etc. for other formats). The html_content() method generally uses > TT and Bibliotech::Query and various Bibliotech::Component's and > some help from Bibliotech::DBI layer and Bibliotech::Util. > Bibliotech::DBI is the base class for all objects in the database, > and yes they all have an html_content() as well. Actions such as > adding and editing have root functions in Bibliotech.pm since they > coordinate across many modules. >
Riight I think that you could do a fairly straightforward refactor to catalyst by: 1. Getting the database code working independently of the web application and calling it a well separated model. 2. Taking your dispatcher code, getting it working independent of apache (basically factoring out $r into utility functions). Next up, delegating the dispatching logic and content generation logic below and bending it into catalyst logic. I really think this isn't going hard for someone familiar with the codebase, although it would be tricky for me. What this buys you is a clearly understood dispatch process that's very easily understood by a large and active developer community. > I think you'd get your CMV separation as good as any application > can get with these steps: > > - removing the *_content() methods and supporting items and making > them subclasses of the Bibliotech::Page and Bibliotech::Component > objects with a content() method. That just seemed complicated > > - removing the *_content() methods and supporting items from > Bibliotech::DBI objects and putting them into similarly separated > subclasses or have another class that accepts objects and renders > them or something like that. > > It just seemed like that increased syntactical complexity and class > complexity in order to create separation that we didn't think we > needed when the codebase was smaller. > mmm. I really think that's called technical debt > I'm actually interested in seeing a fairly big application written > in Catalyst to see how you guys do it. right. The really big ones tend to be closed source. A prominent one ( Vox from 6apart): http://tokyo2007.yapcasia.org/sessions/ 2007/02/everything_vox.html and a little experiment: /tmp$ du -h -d 1 connotea-code-1.7.1 1.0M connotea-code-1.7.1/bibliotech 1.0M connotea-code-1.7.1 /tmp$ cd ~/Deskop/dev/Catalyst/trunk/examples # (http:// dev.catalyst.perl.org/repos/Catalyst/trunk/examples/) ~/Desktop/dev/Catalyst/trunk/examples$ du -h -d1 # I've edited out the ones I think are of no use to you of I don't know anything about 136K ./AdventREST # example REST app 616K ./CatalystAdvent # lots of example driven documentation 152K ./CatTube # youtube integration 216K ./ChainedEg # innovative dispatch method example - may be relevant to connotea may not 132K ./Cheer # very simple tutorial app 144K ./GeoCat # geotagging 488K ./InstantMessenger # neat IM program - old so contains some deprecated approaches 156K ./JQChat # minimal DBIC/Query chat program 152K ./MiniMojoDBIC # minimal DBIC/Prototype wiki 172K ./OpenID # openID integration 412K ./ServerDB # server management software 3.2M ./SmokeServer # server for testing software? 40K ./Streaming # simple streaming app 352K ./Tutorial # reference implementaiton for the catalyst tutorial in Catalyst::Manual::Tutorial 9.2M . Here's my Website in a Box which I wrote while learning to provide a complete and useful calalyst app with good test coverage and good programmer documentation. The dispatch logic here is very simple. http://code.google.com/p/websiteinabox (codebase = 1.3M). It has some flaws (the controller is too thick in places and the model too thin mainly). Now onto the Model: > Unfortunately we are not even within the bounds of Class::DBI > because Bibliotech::Query does a lot of query building itself, > although I am interested in revamping it because it is the most > difficult part of the codebase. So we'd probably have to do a > general refactoring before we even switched. > Right. DBIC was made because projects outgrew CDBI very quickly in exactly this manner. In this case I'd really recommend doing a concurrent refactor to DBIx::Class to get a model that works independently of the app. Getting a starting schema with good relationships coverage really is as simple as installing DBIx::Class and doing something like: perl -MDBIx::Class::Schema::Loader=make_schema_at,dump_to_dir:/path/ to/lib -e \ 'make_schema_at("MySchemaName", {relationships => 1}, ["dbi:mysql:dbname=db", "user", "pass"])' You've got a lot of sql you can then port back in by using the scalar ref feature in SQL::Abstract, and from there you can wind back to something a bit easier to maintain using core dbic functionality wherever possible. chainable resultsets are a feature everybody finds extremely useful: my $schema = DB->connect(); my $resultset = $schema->resultset('Foo')->search(\% scary_search_condition, \%search_attributes); my $narrowed_resultset = $resultset->search(\%some_more_search_logic); while (my $foo = $narrowed_resultset->next) { # you only hit the database at this point in the chaining of the resultset } things like using a cache engine ie memcached should be transparent and trivial to remove for users who don't need that feature with DBIC (c.f. tight couplling and real maintenance headache for the equivalent CDBI code). DBIx:Class ought to see the following schema from the connotea db by default (ie relationships pre-specified for you in the generated code) - http://www.uow.edu.au/~kdiment/schema.png (generated by sqlfairy which DBIC uses for some purposes). I can't guarantee this, but if not it will be close. As you can see I can continue this conversation for ages :-) Kieren ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Connotea-code-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/connotea-code-devel
