Re: [Connotea-code-devel] feedback

[Martin F. <ma...@ne...>]

Hi Kieren,

A couple quick responses.

Kieren Diment wrote:
> 1.  Controller
> 
>   Porting to Catalyst provides the framework for this, with sane url/ 
> action dispatching (I couldn't work out how this works looking at the  
> connotea code base  with my limited available time.  This is another  
> problem).  Using the catalyst dispatcher makes it very quick for new  
> developers to get their head around the flow of logic within the  
> application (the controller part).  The main task here is refactoring  
> the mod_perl handler dispatching logic into something catalyst  
> compatible.  I've seen people doing this a few times, and it should  
> be pretty quick and straightforward for someone familliar with the  
> existing mod_perl code base.  An experienced mod_perl hacker (which  
> I'm not) from the catalyst project was going to have a look at the  
> connotea code base for me to tell me if my assumptions above are  
> correct, but because there's no code viewable in a web browser, this  
> proved too much friction ... for now.  (Here illustrates a major  
> benifit of open source software communities - a lot of my comments  
> don't come from my expertise, but from knowing how to ask the right  
> questions on the appropriate irc channel).

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.

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.

I'm actually interested in seeing a fairly big application written in 
Catalyst to see how you guys do it.

> 2.  Model
> 
> DBIC is much more flexible and much faster than CDBI.  A port would  
> again reduce technical overhead.  However if you can get the CDBI  
> model working independently of the mod_perl app, it becomes usable  
> within catalyst, and you can defer the decision to port while  
> improving the structure of the codebase.  However, the tight coupling  
> of the cdbi models with memcached is another impediment to casual  
> hacking on connotea.  I suspect that porting to DBIC would make life  
> a lot easier for junior and senior developers alike, and be the  
> easiest way to get a web-app-independent model available as well.   
> Thanks for reminding me about the sql trace stuff you added.  It was  
> a while ago, but not being able to see the do() stuff was  a show  
> stopper for me I'm afraid.

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.

> 3.  View
> 
> Based on your feedback, if using  catalyst, you'd probably want to  
> make a souped up Catalyst::View::ConnoteaTT based on  
> Catalyst::View::TT.  Maybe also  make a  Catalyst::View::RDF as  
> well.  Improving the architecture to something more MVC is going to  
> make all these little components much more modular and easier for new  
> (junior and senior) developers alike to understand.
> 
> A core problem here is that with the current architecture/libraries  
> of connotea you don't have very good ability to leverage the perl  
> community to help with development.  You should also upload the  
> connotea perl api libraries to CPAN so that connotea becomes more  
> visible to the perl community at large, and make a post to  
> use.perl.org once the new version is out with it's vc repository.
> 
> I didn't suggest Rails because Catalyst is far superior both in  
> library support and that it's much less opinionated, and thus has the  
> flexibility that connotea requires. :-D

All noted. Thanks.

Martin