> The reason I was thinking that a separate class might be cleaner is > the integration_get_product_name method - using the code attached to > the bug this doesn't require database access, so that method would > become something like (from memory):
I bet some "magic" that connects to the database happens when a new
Bugzilla::Bug is initialized in the following. And
integration_connect_database/integration_disconnect_database could
remain unimplemented for 3.0 if they need to. But they are implemented
for other bugtrackers (Mantis, etc.)
> sub integration_get_product_name {
> my $self = shift;
> my $bugid = shift;
> my $bug_product_name;
>
> if ($self->isBugzilla3()) {
> my $bug = new Bugzilla::Bug($bugid));
> $bug_product_name = $bug->product->id;
> } else {
> .... existing code
> }
> return $bug_product_name;
> }
>
> Two things about the above:
> 1. Should we rename is_version_latest latest to is_version_2_22 and
> add a is_version_3_0?
I began doing this the first time (from Oliver I think) a patch was sent
for this:
http://bugzilla.mkgnu.net/attachment.cgi?id=227
Yes, change is_version_latest to is_version_2_22 and essentially have
is_version_latest mean 3.0.
> 2. The above is going to get more and more complicated as more of
> these variations are added. As a java developer, I'd have something
> like:
What you propose is certainly cleaner, yes. If we were to do this
consistently, meaning build classes for <= 2_14, 2_16, 2_18, 2_20, 2_22,
2_24, 3_0 to make this consistent Iwould not be opposed to it. This has
to be done, and I certanly postponed it indefinitely.
> and then have the appropriate instance chosen. Unfortunately my perl
> is not strong enough to know how to model the above in perl but the
> point I'm trying to get across is having a separate implementation for
> each version (with re-use where appropriate).
Look at the relationship between Bugzilla.pm and Bugtracker.pm. Bugzilla
is a Bugtracker (look at @ISA).
signature.asc
Description: This is a digitally signed message part
_______________________________________________ scmbug-users mailing list [email protected] http://lists.mkgnu.net/cgi-bin/mailman/listinfo/scmbug-users
