[TYPO3-ect] Draft: Proposal of a resultbrowser pipe

[Elmar Hinz]

Hello,

what do you think about this draft:

Introduction
============

this is a proposal of a resultbrowser system, to make it easy to plugin
and exchange resultbrowsers of different types. The basic idea is, that
resultbrowsers are not build into the extensions any more. Instead they
come as independent plugins that the adminitrotor can plugin directly
below the listing plugin. He has the opportunity to finetune the
resultbrowser directly by a flexform and exchange them as he likes.

Obviously there must be some exchange of data between the resultbrowser
and the listing plugin of the controller key ($prefixId), the views
offset, the total result count and the result count. This proposal
specifies an interface that is able to exchange this informations. I
call it a pipeline.

Technical details
=================

The resultbrowser pipline is implemented as an extension that is
targeted to become part of the core. Let's take the name
"tx_resultbrowser_pipe". We need to pipe at least 3 informations between
listing plugin and the resultbrowser plugin:

a) controller key (for the parameter array)
b) number of results per view to show
c) the total results count

Further informations can be usefull for more inhanced resultbrowsers.
For now we define:

d) actual result count (it differs from resultsPerView in the last view)

The information channels are called "pipes" and work as setters and
getters. Simplyfied example for "resultsPerView":

function pipeResultsPerView($number = ''){
  if($number){
    $GLOBALS['TYPO3_LOADED_EXT']['resultbrowser_pipe']['resultsPerView']
=  $number;
  }
  return
$GLOBALS['TYPO3_LOADED_EXT']['resultbrowser_pipe']['resultsPerView'];
}

So the resulting class looks like this:

class tx_resultbrowser_pipe{
	function pipeControllerKey($string = ''){...}
	function pipeTotalResults($integer = ''){...}
	function pipeResultsPerView($integer = ''){...}
	function pipeResultsCount($integer = ''){...}
}

It is called in the static way.

By the listing extension:

tx_resultbrowser_pipe::pipeControllerKey($this->prefixId);
tx_resultbrowser_pipe::pipeResultsPerView($resultsPerView);
...

By the resultbrowser plugin:

$conrollerKey = tx_resultbrowser_pipe::pipeControllerKey();
$resultsPerView = tx_resultbrowser_pipe::pipeResultsPerView();

The resultbrowsers need to create links with the typolink function that
contain:

a) all incomming Parameters for the controller key
     &my_extension['searchword']=example
b) the view offset also stored within the array of the controller key:
     &my_extension['viewOffset']=8


Motivation
==========

a) The resultbrowser within pi_base doesn't work for the page visitor in
   a way he used it from typical internet pages.
b) It isn't accessible.
c) The configuration is difficult.
d) The extension coordination team want's to make pi_base obsolete.

All in all we need a more flexible system that makes it possible to
provide different types of resultbrowsers as extensions and to combine
them with freely with any plugin. This is only possible by a standard
interface between listing plugins and resultbrowsers.


Discussion
==========

This draft specifies a way, to place resultbrowsers as plugins below
listing plugins. I propose to define a second interface of the service
type, that makes it possible to access resultbrowsers as objects and to
bind them into the listing extension directly. Any resultbrowser can
implement both interfaces, but it must not.