[Webkit-unassigned] [Bug 30520] Enable creation of custom SidebarTreeElements for different ProfileTypes

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=30520





--- Comment #9 from Alexander Pavlov (apavlov) <apavlov at chromium.org>  2009-10-21 03:25:59 PDT ---
(In reply to comment #7)
> (From update of attachment 41493 [details])
> > +    // Must be implemented by subclasses.
> > +    createView: function(profile)
> 
> Nit, can be done in subsequent patch: usually abstract methods that are
> implemented in concrete classes are named as doCreateSomething*.
> Otherwise it is easy to get confused on what should be overriden and what not.

Timothy has commented on this one.

> > +    {
> > +        throw new Error("Needs implemented.");
> > +    },
> 
> "Not implemented" ?

This is fine, as in "Has a comment that points out this needs implemented when
network headers are added" (WebCore/ChangeLog, 2008-05-13) or at the bottom of
Comment #2. And, it was suggested by Timothy.

> >  
> > +        profile._type = profileType;
> 
> This looks like a hack: what if concrete profile object already has this
> property?
> Either declare it a hack and name it "__profilesPanelProfileType" or make
> profile define "type" getter and put it into docs.

Profiles should be definitely ProfileType-agnostic since ProfileTypes deal with
visual representation of profiles, and they are bound only at the point of the
addProfileHeader() invocation. That's why I was parsing the keys (which was
cleaner than "caching" ProfileTypes inside profiles) rather than using an
explicit association. I will stick to "__profilesPanelProfileType".

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.