Re: [viewvc-dev] Re: Porting templates to viewvc 1.1

Jens Peters wrote:
> C. Michael Pilato wrote:
>> I don't have a preference for how you initialize the new template set, 
>> but I do think it best that you do your work under 
>> templates-contrib/1.1 instead of just tweaking the 
>> templates-contrib/1.0 bits.
> 
> Ok, I started with making a copy from 1.0 to 1.1. It should be ok.
> 
>> Do you have the "co" view enabled in viewvc.conf (allowed_views)?  If 
>> not, then it may be that what you are seeing isn't that download_href 
>> contains the current URL, but that it is empty and your browser is 
>> treating that as "current URL".
> 
> Men, indeed, sorry for bothering you with such a simple mistake. 
> Wouldn't it be better to throw an exception if a template is asking for 
> a disallowed view? That would make template development a little bit 
> easier too ;)

Templates should ideally work regardless of the ViewVC configuration, don't 
you think?  I mean, I would be rather disappointed in a template set that 
only worked if viewvc.conf was composed a particular way.  So, templates 
need to do things conditionally, and the mechanism for doing so is the likes 
of [if-any download_href].  But [if-any download_href] will raise an 
exception if download_href isn't even defined, and those kinds of annoyances 
were driving me batty as a template author.  This is why ViewVC 1.1 tries to 
keep a more-or-less uniform set of dictionary variables at least defined, 
even if unused.

>  > Do you have 'allow_compress' set in viewvc.conf?  If so, I wonder if
>> there's a misinteraction between the request-level compression and the 
>> tarball compression.
> 
> I tried both settings, the tarball remains corrupted when using apache..
> But I found that not using mod_deflate make a difference (thus not using 
> SetInputFilter DEFLATE and SetOutputFilter DEFLATE). Strange strange..

Ah, okay.  Yes, I've seen certain situations in the past where mod_deflate, 
doin' its thang on a already-gzipped data stream, can go awry. 
Unfortunately, I know neither the cause nor the graceful workaround for such 
situations.

-- 
C. Michael Pilato <[email protected]>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFIhKVOokEGqRcG/W4RApROAJ9rz+mkcLcDsESJfL1AS8nuvwVvFACgiRG0
iDStb49lU9RxkHNXvK2psgo=
=Hxvo
-----END PGP SIGNATURE-----