From: Petr Baudis <pasky@suse.cz>
To: Jakub Narebski <jnareb@gmail.com>
Cc: Pavan Kumar Sunkara <pavan.sss1991@gmail.com>,
git@vger.kernel.org, Christian Couder <chriscool@tuxfamily.org>
Subject: Re: [RFC/PATCH 1/4] gitweb: Move subroutines to Gitweb::Config module
Date: Tue, 8 Jun 2010 16:13:21 +0200 [thread overview]
Message-ID: <20100608141321.GP20775@machine.or.cz> (raw)
In-Reply-To: <201006081446.22587.jnareb@gmail.com>
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?
--
Petr "Pasky" Baudis
The true meaning of life is to plant a tree under whose shade
you will never sit.
next prev parent reply other threads:[~2010-06-08 14:13 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-06-07 20:50 [RFC/PATCH 1/4] gitweb: Move subroutines to Gitweb::Config module Pavan Kumar Sunkara
2010-06-07 20:50 ` [RFC/PATCH 2/4] gitweb: Create Gitweb::HTML::Link module Pavan Kumar Sunkara
2010-06-07 20:50 ` [RFC/PATCH 3/4] gitweb: Create Gitweb::HTML module Pavan Kumar Sunkara
2010-06-07 20:50 ` [RFC/PATCH 4/4] gitweb: Create Gitweb::HTML::String module Pavan Kumar Sunkara
2010-06-07 20:58 ` Pavan Kumar Sunkara
2010-06-08 12:46 ` [RFC/PATCH 1/4] gitweb: Move subroutines to Gitweb::Config module Jakub Narebski
2010-06-08 13:50 ` Ævar Arnfjörð Bjarmason
2010-06-12 1:01 ` Jakub Narebski
2010-06-12 1:22 ` Ævar Arnfjörð Bjarmason
2010-06-12 1:41 ` Jakub Narebski
2010-06-08 14:13 ` Petr Baudis [this message]
2010-06-08 19:22 ` Pavan Kumar Sunkara
2010-06-08 19:55 ` Petr Baudis
2010-06-08 20:24 ` Pavan Kumar Sunkara
2010-06-08 20:50 ` Petr Baudis
2010-06-08 23:38 ` Jakub Narebski
2010-06-09 13:13 ` Jakub Narebski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20100608141321.GP20775@machine.or.cz \
--to=pasky@suse.cz \
--cc=chriscool@tuxfamily.org \
--cc=git@vger.kernel.org \
--cc=jnareb@gmail.com \
--cc=pavan.sss1991@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.