[TYPO3-dev] typolink - link to records 2

[Daniel Pötzinger]

Ernesto Baschny [cron IT] schrieb:
> Jeff Segars wrote: on 04.10.2007 16:02:
> 
>>>  So I would propose to have a hook where each extension can "generate
>>> the link" it finds appropriate for a given record-uid. This could
>>> depend on the storage-pid, on the current rootline, maybe even on
>>> other bizarrefactors we don't know (and don't care) about.
>> Daniel can correct me if I'm wrong here, but I believe thats exactly
>> the way the underlying hook for the core is set up.  You register a
>> keyword inside your extension (usually a table name but in the case of
>> Daniel's extension, linkhandler) and your extension gets the ability
>> to run any code it wants when its keyword is found in a typolink.
>>
>> The challenge with the original implementation of this hook is there
>> wasn't a user interface tied to it at all.  Keywords were not
>> necessarily table names and there wasn't a clear place that a keyword
>> could define what it allowed you to select (ie. tt_news articles).
>> This is where Daniel's linkhandler keyword came in, adding the
>> structure of TSConfig and Typoscript.
>>
>> The original core hook should still work just fine for those cases
>> when more complex processing is needed, but it seems like there may be
>> a little disconnect between the hook method and the linkhandler
>> method.  Is there anything we can do to make those more similar? Just
>> my two cents :)
> 
> True, I wasn't thinking of that. Daniel's method is very useful to any
> kind of "record linking" where the extension author even didn't thought
> about it. Very useful indeed!
> 
> In case of extensions that already register a "typolinkLinkHandler"
> those can already generate more complex linkings.
> 
> The question about making them "more similar" you mean some standard way
> to link to single records where either linkhandler OR the extension
> itself can generate the link when requested? It would be wise to use the
> tx_linkhandler additions (e.g. to browse_links) also for fancy linkings
> which tt_news might provide one day, but having a fallback to
> "configurable" for those records that don't have a extension that
> provides the handler.
> 
> And those "fancy additions" should of course be part of core, and the
> API could be a hook with "fallback" possibility:
> 
> 	record:<table>:<uid>
> 
> first calls "record:<table>" handler, and if that doesn't exists, calls
> "record" handler (e.g. tx_linkhandler). And if this doesn't exist
> either, just return an empty link (or an error or whatever). This way
> tt_news could provider a "record:tt_news" handler which would overwrite
> the tx_linkhandler way of linking to tt_news records.
> 
> What do you think?
Cool idea.

Here are some others:

1) Another will be to configure the tabs in the browse_links to use 
another  linkHandler. E.g. tt_news can come up with some TSConfig like:
(BE)

mod.tx_linkhandler {
     tt_news {
         label=News
         listTables=tt_news
         onlyPids=5
	overrideLinkHandler=tt_news_handler
     }
}

2) keep the existing stuff and call a userfunc in the frontend. E.g. 
tt_news can come up with something like:


plugin.tx_linkhandler {
     tt_news {
              userFunc=tt_news->generateLink
     }
}

A userFunc in tt_news is called to generate the typolink (typolink has 
that feature.) But I am not sure if the userFunc recieves the loaded 
record array.
But one can also use the userFunc on the parameter and additionalParams 
property.

3) Add the possibility to translate linkHandlers in the extension 
linkHandler. (FE)

plugin.tx_linkhandler {
	_handlerTransformations {
		source=record:tt_news:
		target=tt_news_handler
	}
}




1 and 3 are nearly the same: You can still use the browse_links feature 
offered by the linkhandler, but you are able to handle the links by your 
own linkhandler.

Greetings

Daniel