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

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

On 1 Dec 2005, at 01:31, Steffen Pingel wrote:

> Hi,
>
>>> 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?
>
> Why would we want to? Creating these objects is a one time task,  
> just as
> parsing the cvs log file, and should be done on start up. IMHO a  
> simple
> Profile class with a couple of getters and setters will do the job.

OK, you win. Let's have an AuthorProfile type.

> But while
> we are at it, we may want to go with an interface that specifies  
> the get
> methods and provide a default implementation that has the setters  
> as well.

Nah. I don't see why an interface should be necessary at the current  
state. I don't want to generalize prematurely.

Would that cover your needs?

interface AuthorProfileFactory
    Profile getProfile(String loginName);

class AuthorProfile
    String getFullName();
    String getImageURL();
    String getWebPageURL();
    + setters

Richard



>>> 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.
>
> Yes, I certainly agree. The profile stuff should be kept separate  
> from the
> model code as there is no apparent connection to the cvs log.
>
>> 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.
>
> Exactly. StatCvs-XML which shares the model code has a very  
> different approach
> to the profile . For maven we have a straight forward dom parser  
> that stores
> results in a map of maps.
>
>  SAXBuilder builder = new SAXBuilder();
>  Document suite = builder.build(file);
>  Element element = suite.getRootElement().getChild("developers");
>  if (element != null) {
>      for (Iterator it = element.getChildren().iterator(); it.hasNext 
> ();) {
>          Element developer = (Element)it.next();
>          String id = developer.getChildText("id");
>          if (id == null) {
>              continue;
>          }
>          if (developer.getChildText("name") != null) {
>              settings.setFullname(id, developer.getChildText("name"));
>          }
>          if (developer.getChildText("image") != null) {
>              settings.setAuthorPic(id, developer.getChildText 
> ("image"));
>          }
>          else if (developer.getChildText("url") != null) {
>              settings.setAuthorPic(id, developer.getChildText 
> ("url") + "/" +
> id + ".png");
>          }
>      }
>  }
>
> If anyone were to define a profile class I would probably go ahead and
> refactor the code though :).
>
> Steffen
>
>
> -------------------------------------------------------
> 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
>