[TYPO3-ect] Draft: Proposal of a resultbrowser pipe
Elmar Hinz
elmar.DOT.hinz at team.MINUS.red.DOT.net
Sat Sep 2 12:22:20 CEST 2006
> What i forgot to mention: the actual output of the browser
> could get configured by TS (COA) or a callback-function
> into the calling object.
>
> function main() {
> data = db->getSelect('*', 'foo', where);
> b = getInstanceofService("resultbrowser");
> b->setData(data);
> b->setRenderObj(TS[foo][renderObj.];
> // or b->setRenderFunc(this->renderfunc);
> if(!b->showResults()) {
> // no page browsing mode
> // perhaps single view or armageddon.
> }
> }
>
Yes. That would come close to the usual object way I mentioned in the
discussion of the draft. b->setRenderObj($TS) is fine and we are used to
it. b->setData(data) looks a little unspecific to me, because it gives no
assitance how the data should look like. I would prefer some more specific
setters like:
b->resultsPerView($integer);
b->resultsCount($integer);
b->totalResultsCount($integer);
b->resultLabels($array);
Ther labels are only needed for resultbrowsers, that display labels like
dropdown selects:
Alpha ... Gamma
.......
.......
Sigma .... Omega
But you should set them allways to make the browsers completly exchangabel.
> Another cool thingy would be a new TS-object RESULTBROWSER which acts
> like CONTENT but also does the resultbrowser rendering.
Definitly. So you could configure complete result lists in TS and than
drop in lib.resultbrowser. Wich is a choice in some cases.
Not to mention, that you also can write the complete result browser
functionality in TS. But that blows up the TS tree and isn't easy to
handle and configure.
Regards
Elmar
More information about the TYPO3-team-extension-coordination
mailing list