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

[Franz Koch]

Hi Elmar,

>> 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.

But the API doesn't have to do anything with the view - does it? The API (controller/model) ensures that all general information is given to render a resultbrowser - this information/data is handled to a view that takes care of the rendering - so the view can be switched without having to care about the API because the view can expect a fixed set of data - right? (Assuming that the resulbrowser is in MVC-style) Maybe the configuration-options have to be named in a general style to not be view specific.


Something else - how about also supporting alphabetic sorting/browsing of records? Could be implemented as second model with it's own views I guess.

>> 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.

Why later? I see no good reason for waiting. If somebody likes to use lib/div than he should follow those additional coding guidelines (enough people won't do anyway) in his own interest. He would also profit from a more flexible extension.


>> 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.

I think that is more a job for a rendering-API (hopefully in v5).

>> 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.

I have tested efaq once and studied the code - but it was on one of the first versions - right when I started my first lib/div project. I'll have a look at the current version. Thanks for the hint.

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

I tried once to code a common rating-extension that can be added to anything with pure TS, based on one of the TER extensions. It's also currently in use, but the code is not the best and should be better done from scratch - best in MVC style with different rating-models (regular rating,multiple ratings like in TER,Polls). Also tried it for comments - but gave it up due to a lag of sparetime.

> 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.

Maybe it doesn't have to be a guideline for queries (some could be to complex to build with regular functions anyway) but for storing the information inside the MVC? Maybe simply suggest the usage of internal supporter functions/methods or setter/getter to store such information for general and own use.

-- 
Kind regards,
Franz Koch