Phoenix Devs,
This morning I adapted ProjectInfoList to use the ProjectInfoData class that
Bjorn provided last night. I find this to be a much more elegant solution
and it relieves some of the questions / difficulties that I had when
implementing the original ProjectInfo class for my category pages.
I did however encounter a bug when trying to retrieve data from Multi Record
data such as "mailinglist", "newsgroup", and I would imagine "release" would
be the same.
$projectInfoData->newsgroup[0]->name;
$projectInfoData->newsgroup[1]->name;
Would both return the same values. The newsgroup[] array had the right
number of records but all records were identical. I dove into the class and
found the culprit in the __get() function.
Original
foreach( $this->rows as $rr ) {
if( $rr['MainKey'] == $mainkey) {
$subrows = array();
foreach( $this->rows as $rr ) {
if( $row['ProjectInfoID'] ==
$rr['ProjectInfoID']) {
$subrows[] = $rr;
}
}
$result[] = new ProjectInfoValues( $this, $subrows
);
}
}
Fixed
foreach( $this->rows as $rr ) {
if( $rr['MainKey'] == $mainkey) {
$subrows = array();
foreach( $this->rows as $rrr ) {
if( $rr['ProjectInfoID'] ==
$rrr['ProjectInfoID']) {
$subrows[] = $rrr;
}
}
$result[] = new ProjectInfoValues( $this, $subrows
);
}
}
$rr was being overwritten and then checked against the wrong value.
I've tested this new code and it returns the correct records as expected.
Thanks for the new class Bjorn!
/eclipse.org-common/classes/projects/projectInfoData.class
/eclipse.org-common/classes/projects/projectInfoList.class
The new class files above have been committed to CVS on Phoenix.eclipse.org.
Can we get some more +1's to move this forward?
Web Developer
The Eclipse Foundation
-----Original Message-----
Sent: Wednesday, September 12, 2007 10:53 PM
To: For developers on the new Eclipse.org website project.
Subject: Re: [phoenix-dev] ProjectInfoAPI Documenation
You guys are brilliant.
+1 for Bjorn's code and Nathan's adaptation.
Nathan Gervais wrote:
I'm not suggesting we rewrite any of the code that Denis, Karl, Matt,
and Nathan have already written with the other class, but I think we
should
hide that other class and only expose this one to our user population
(the
committers).
I don't see the point in creating two different API's for accessing this
data.
I would suggest replacing the class ProjectInfo with this new
ProjectInfoData class, and then adapting ProjectInfoList to use this new
class. This will provide the flexibility of the SimpleXML style, while
still allowing filtered lists of ProjectInfoData that are required to
produce pages such as the categories, mailinglist / newsgroups (by topic),
project page etc.
Web Developer
The Eclipse Foundation
-----Original Message-----
Sent: Wednesday, September 12, 2007 9:16 PM
website
project.
Subject: Re: [phoenix-dev] ProjectInfoAPI Documenation
Karl, Nathan, Denis, Matt,
I didn't think you could do this in a dynamic way (meaning you don't
have to track the DB schema by hand in the class' member variables)
without manipulating the PHP language structs like SimpleXML does.
I took up the challenge and wrote the two classes necessary. Here's the
file and a demo. In the end you just write code like this:
$info = new ProjectInfoData( 'technology.dash');
$a = $info->pargraphurl ;
$b = $info->descriptionurl ;
$c = $info->bugzilla->productname ;
$d = $info->mailinglist[0]->name ;
$e = $info->mailinglist[0]->description ;
I'll let Denis or Karl code review my work and then check it in the
appropriate place (where ever that is) and then update that wiki page.
Or I can update the wiki page once you tell me where the file is going
to reside.
I suggest that we implement the classes as they are now--and as Nathan
has done a nice job of documenting--because we are running out of time
to complete the page conversion before the end of the quarter. But I
think we could make a significant improvement to usability if we built a
dynamic ProjectInfo class next quarter.
It's a significantly better user experience for our committers, so I
suggest we roll this code out this quarter. I'm not suggesting we
rewrite any of the code that Denis, Karl, Matt, and Nathan have already
written with the other class, but I think we should hide that other
class and only expose this one to our user population (the committers).
- Bjorn
_______________________________________________
phoenix-dev mailing list
_______________________________________________
phoenix-dev mailing list
_______________________________________________
phoenix-dev mailing list
