Re: [Statcvs-users] [PATCH] Make the author page display real names (if available)

[Richard C. <ri...@cy...>]

Hi James,

On 30 Nov 2005, at 23:43, James Ring wrote:

> Hi Richard,
>
>>
>> Yeah, the name sucks. I think the class should not represent a single
>> profile, but a method of getting author profiles. It's clear what the
>> implementation classes would be, things like PasswdFile,
>> MavenProjectFile, SourceforgeWebsiteScraper. Now find a good common
>> name for these.
>>
>> AuthorProfileSource?
>>
>
> AuthorProfileFactory? This sounds like the classic situation for a  
> factory
> pattern.

This implies that you have an AuthorProfile class with many  
instances. Can we do without?

> You could have the Factory as an abstract class with pretty much  
> the single
> method
>
> public abstract AuthorProfile getProfile( Author a );
>
> and then just subclass it and provide the correct concrete  
> implementation
> depending on the command line options.
>
> Alternatively, you could it as a Factory which calls other factories.
> For example, AuthorProfileFactory may call all its "sub-factories"
> (PasswdAuthorProfileFactory) until it finds a factory which can  
> give back
> a profile for the given author. This would allow StatCVS to source its
> author profiles from many different sources at the same time...  
> Whether
> that's useful or not is another question... :)

Take it easy here ... ;-)

>> Also, I see no need why the Author class should know about the
>> existence of the profiles. I want the Author class to remain as close
>> as possible to the concept of a CVS login. We're discussing a
>> presentation issue, and changing stuff on the presentation layer
>> shouldn't affect the core CVS classes.
>
> Actually, the AuthorProfile shouldn't have anything to do with the
> presentation.

You're right. Presentation was the wrong term.

> How you choose to represent the author's profile is totally
> up to the presentation layer. AuthorProfiles should be concerned  
> only with
> those things which make up an author's profile (like you said, an e- 
> mail
> address, URL, etc).
>
> Presentation layer classes would merely need to call  
> Author.getProfile()
> and then render that profile any way they like.

That's where I disagree. I'd prefer the log parsing and  
representation to make no assumptions about the application that uses  
the data. Having Author.getProfile() would add such an assumption to  
the log representation. I want to be able to re-use the low-level  
classes (like Author) without having a dependency that forces me to  
drag higher-level classes (like the Profile stuff) into my new project.

Hope that makes sense.

Richard



>
>> (Actually, the Author class should probably be called CVSLogin. My
>> suggestions may make more sense if seen from that point of view.)
>
> Ok, maybe I am thinking differently about the role of the Author  
> class.
>
>> Richard
>>
>
> Regards,
> James
>
> PS. I'm now using StatCVS at my work, and the bossman likes it a  
> lot ;)
> -- 
> James Ring
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through  
> log files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD  
> SPLUNK!
> http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
> _______________________________________________
> Statcvs-users mailing list
> Sta...@li...
> https://lists.sourceforge.net/lists/listinfo/statcvs-users
>