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

On Tue, Jun 8, 2010 at 7:43 PM, Petr Baudis [off-list ref] wrote:

 Hi!

On Tue, Jun 08, 2010 at 02:46:20PM +0200, Jakub Narebski wrote:

quoted

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!

quoted

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

quoted

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.

quoted

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.