[Typo3-dev] feature-patch for pi_list_browseresults

[Michael H.E. Roth]

Christopher wrote:

> <snip>
> 
>> Now, if there are 2 different html-template markers or 2 different
>> ts-elements you want to assign the page browser and the result count
>> to, I
>> don't see no way but to call the function twice (at least not without
>> breaking the traditional behaviour). But if you can position the two
>> parts
>> merely by css, it should be possible to do it with just one call.
>> 
>> what do you think?
>> 
> 
> I think this is a poor option. It's just another way of forcing people
> to use a particular sort of markup that might not be appropriate to the
> purpose. I don't really see what would be gained over the current table
> method. 
sorry? I think you didn't read the whole thread! 
quote of my post on 29-10 13:22 :
<quote>
added a third parameter ($wrapArr) which can contain the following elements:
['disabledLinkWrap']
['inactiveLinkWrap']
['activeLinkWrap']
['LinksWrap']
['showResultsWrap']
['browseBoxWrap']
['showResultsNumbersWrap']
</quote>
there's absolutely no force to use any kind of markup at all. OK, maybe
some nesting for conveniance... but that can be overcome by reorganizing
your "wrappers"

> IMO, it would be better to just call the function once and populate a
> couple of typoscript objects with the results; this way, a developer can
> wrap and output one and unset the other one etc...
> 
without breaking the current behaviour? Remember lots of extensions base
on the current behaviour!
I am not talking about a total rewrite of the search and
browse methods of class.tslib_pibase.php... Thats another topic... There
are a lot of inconsistencies already in how the behaviour of this one
original method is controlled:
- parameters
- one plugin-variable ($this->piVars['pointer'])
- one object-variable ($this->pi_alwaysPrev)
- some more via an object-array ($this->internal[])
which also should be cleared out when rewriting

But I think your suggestion sounds like a good idea for an
alternative method, even though I'm not quite sure I understood you right:

You mean to introduce a new TS-Object-Type similar to HMENU or the like?
Again sounds tempting good, but how? I have to admit I don't know, this
goes beyond of what I digged into the core sources yet... (if you can
point out a good example how this has to be done, I might give it a try...)

If I misunderstood you, please clarify

Michael
-- 
Michael H.E. Roth