[TYPO3-ect] RFC: Result Browser Service for lib/div - part 1 + 2

[Elmar Hinz]

Hi Franz,

Franz Koch wrote:

> 
> I think the possible types should not be limited. I'd suggest a view
> service or something like that which can be easily extended with new
> view-types. If the views are limited there will soon be the same problem
> with pagebrowsers in TER than with gallerys, calendars etc.
> 
> I could also think of such a view:
> 
> < next        pages 1 ... 5 6 7 8 ... 43        previous >
> 
> 
> or any other variation maybe with ajax, XML (for flash?) or whatever.

Exactly. That's the bottomline of point 4. The API should always be the same
independent of the implementation.

> In addition a guideline/rule should be set, that in extensions the
> view-type is NEVER hardcoded and must be configurable with TS or be

Yeah. We should design those guidelines in the moment lib/div becomes
widespread enough, so that it has some normative strength.

> overriden by a global preset for view-types in the service itself (or
> whatever). It'll also be nice if the configuration of the pagebrowser
> could be the same in every extensions flexform - but TYPO3 lacks for such
> intelligent features (hope that's better in v5).

Modular, extendable flexforms are still an open field. We will need
solutions for this, if we want to extend extensions with add-ons. That
would be a special job for Thomas Hempel.

> 
> Even better would be that no extension would have to be aware of the
> existence of the pagebrowser as long as it uses special coding guidelines
> (or maybe lib/div queries) for the result-handling. Wouldn't it be nice if
> extensions of general interest (pagebrowser, rating, commenting) could be
> attached to any other extension just by activating a checkbox that is
> instantly provided everywhere as soon as the extension (e.g.
> pagebrowser-MVC) is installed? Sorry - I'm dreaming.
> 

I share this vision. The search form of efaq is already a big step into this
direction. Did you test it. You can combine it with any of the views.

Rating and commenting. Maybe there are solutions in TER? Anybody?

For the pagebrowser this "special coding guidelines" is not that simple,
because 2 SQL queries are required, one to find the total result count and
one for the current results. However, I would say that this API we
currently discuss not far from this "special coding guideline". If you
implement it, resultbrowsers can plugged in as a service.

Regards

Elmar