[PATCH 2 of 3] hgweb: move entry-preparing code from webcommands to webutils.makeentry()

[Yuya Nishihara]

On Fri, 20 Nov 2015 23:11:20 +0800, Anton Shestakov wrote:
> On Fri, 20 Nov 2015 22:40:15 +0900
> Yuya Nishihara <yuya at tcha.org> wrote:
> 
> > On Wed, 18 Nov 2015 23:19:26 +0800, Anton Shestakov wrote:
> > > On Wed, 18 Nov 2015 23:27:18 +0900
> > > Yuya Nishihara <yuya at tcha.org> wrote:  
> > > > On Tue, 17 Nov 2015 21:33:57 +0800, Anton Shestakov wrote:  
> > > > > +    return tmpl("filerevision", **webutil.makeentry(web.repo,
> > > > > fctx, {
> > > > > +        'file': f,
> > > > > +        'path': webutil.up(f),
> > > > > +        'text': lines(),
> > > > > +        'symrev': webutil.symrevorshortnode(req, fctx),
> > > > > +        'rename': webutil.renamelink(fctx),
> > > > > +        'permissions': fctx.manifest().flags(f),
> > > > > +    }))    
> > > > 
> > > > This is minor thing, but I prefer
> > > > 
> > > >     return tmpl("filerevision",
> > > >                 file=f,
> > > >                 ...
> > > >                 **webutil.commonentry(web.repo, fctx))
> > > > 
> > > > because webutil has similar functions named xxxentry(). A good
> > > > thing of this style is that you can get TypeError if
> > > > rev=ctx.rev() is specified twice, for example.  
> > > 
> > > It might be a nice bonus, but makeentry() is supposed to first fill
> > > some defaults and then allow to override them (that happens in
> > > webutil.changelist() entry with "parent" and "child"). So sometimes
> > > you're supposed to have a duplicate key.  
> > 
> > Is it common to override the defaults? If not, we can do it explicitly
> > to show that it does change the behavior of common keywords.
> > 
> >   entry = commonentry(web.repo, ctx)
> >   entry['parent'] = ...
> >   return entry
> 
> Overriding defaults is not common, but happens in about 3 places.

Perhaps some of them can be avoided by passing fctx instead of ctx?
I didn't try it yet. If it's possible, it should be done by a separate patch.

> But
> all of the users of this function add at least one (and up to 10) more
> item to the entry, so I decided to have entry.update() in makeentry()
> as a shortcut.
> 
> OK, seeing how it's not very obvious what happens to the dict passed to
> makeentry(), let me do this your way and see if commonentry() looks
> better.

Thanks, and sorry for late reply. I found the previous email in my gmail's
spam folder.