Re: [RFC/PATCH 1/4] gitweb: Move subroutines to Gitweb::Config module

[Pavan Kumar Sunkara <pavan.sss1991@gmail.com>]

On Tue, Jun 8, 2010 at 7:43 PM, Petr Baudis <pasky@suse.cz> wrote:
>  Hi!
>
> On Tue, Jun 08, 2010 at 02:46:20PM +0200, Jakub Narebski wrote:
>> Third, and I think most important, is that the whole splitting gitweb into
>> modules series seems to alck direction, some underlying architecture
>> design.  For example Gitweb::HTML, Gitweb::HTML::Link, Gitweb::HTML::String
>> seems to me too detailed, too fine-grained modules.
>
>  I agree!
>
>> It was not visible at first, because Gitweb::Config, Gitweb::Request and to
>> a bit lesser extent Gitweb::Git fell out naturally.  But should there be
>> for example Gitweb::Escape module, or should its functionality be a part of
>> Gitweb::Util?  Those issues needs to be addressed.  Perhaps they were
>> discussed with this GSoC project mentors (via IRC, private email, IM), but
>> we don't know what is the intended architecture design of gitweb.
>
>  I would expect Gitweb::Escape functionality to live in Gitweb::HTML
> (HTML escaping) and/or Gitweb::Request (URL escaping).
>
>> Should we try for Model-Viewer-Controller pattern without backing MVC
>> (micro)framework?  (One of design decisions for gitweb was have it working
>> out of the box if Perl and git are installed, without requiring to install
>> extra modules; but now we can install extra Perl modules e.g. from CPAN
>> under lib/...).  How should we organize gitweb code into packages
>> (modules)?
>
>  I thought we already discussed MVC and sort of agreed that it's an
> overkill at this point. At least that is still my opinion on it; I'm not
> opposed to MVC per se, but to me, this modularization is a good
> intermediate step even if we go the MVC way later, and doing MVC properly
> would mean much huger large-scale refactoring than just naming a module
> Gitweb::View instead of Gitweb::HTML. Let's do it not at all, or
> properly sometime later. I think it's well out-of-scope for GSoC.
>
>> Perhaps having gitweb.perl, Gitweb::Git, Gitweb::Config, Gitweb::Request,
>> Gitweb::Util and Gitweb would be enough?
>
>  I'm not sure what would fall into Gitweb::Util. I think Gitweb::HTML
> makes a lot of sense to have, but I don't see the advantage of finer
> graining than that - I dislike the Gitweb::HTML::* submodules as well.
>
>  Pavan, can you outline your next plan on the other modules you aim to
> create, plus possibly a bit of rationale?

I am graining Gitweb::HTML into Gitweb::HTML::* to reduce circular
dependancies of the modules.

In the following days, I will be creating more modules
  Gitweb::HTML::Navigation
  Gitweb::HTML::Error
  Gitweb::HTML::Page (Containing header and footer subs)
  Gitweb::HTML::Format (format_* subs)
  Gitweb::Parse
  Gitweb::RepoConfig
  Gitweb::Util
  Gitweb::Action::* (All action subs like git_blame, git_log)

This is my architectural design for now. But It may change due to
later circular dependancies.

I will be rebasing the whole series, edit them and send them once
every module has undergone as RFC in the mailing list.

I have been stuck many times trying to workaround the circular module
dependancies and believe me, the patches I am sending and the modules
I am creating involves a lot of effort from my side and as long as you
think there's nothing wrong with the grouping of subroutines in my
modules and their names, you need not worry about the module
structure.

Thanks,
Pavan.