On Tue, Jun 8, 2010 at 7:43 PM, Petr Baudis <pasky@xxxxxxx> 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html