###RESULTCOUNT### ###ADDSTRING###

###ADDPART### ###PREVIOUS### ###PAGES### ###NEXT###

Search Results

###BROWSE_BOX_TOP### ###RESULTS### ###BROWSE_BOX_BOTTOM###

###NO_RESULT_MESSAGE###

[2] pageBrowser { doNotLinkCurrent = 1 general_stdWrap { wrap =

| } previous_stdWrap { wrap =

} next_stdWrap { wrap =

} pages_stdWrap { wrap =

} current_stdWrap { wrap =

} pageLinks_stdWrap { preCObject = TEXT preCObject.dataWrap = {LLL:EXT:indexed_search/pi/locallang.xml:pi_list_browseresults_page} preCObject.noTrimWrap = | || } } From info at sk-typo3.de Wed Sep 10 16:11:16 2008 From: info at sk-typo3.de (Steffen Kamper) Date: Wed, 10 Sep 2008 16:11:16 +0200 Subject: [TYPO3-project-4-3] indexed_search for 4.3 In-Reply-To: References: Message-ID: Hi, i know Ingo and Stucki did an performance improvement, would like to have this integrated too vg Steffen From masi-no at spam-typo3.org Wed Sep 10 16:19:52 2008 From: masi-no at spam-typo3.org (Martin Kutschker) Date: Wed, 10 Sep 2008 16:19:52 +0200 Subject: [TYPO3-project-4-3] indexed_search for 4.3 In-Reply-To: References:

Message-ID: Steffen Kamper schrieb: > Hi, > > i know Ingo and Stucki did an performance improvement, would like to > have this integrated too Did you test their prerequesit? This would be the page tree / rootline cache. Without that you won't get full speed. Masi From typo3 at t3node.com Wed Sep 10 16:20:54 2008 From: typo3 at t3node.com (=?ISO-8859-15?Q?Steffen_M=FCller?=) Date: Wed, 10 Sep 2008 16:20:54 +0200 Subject: [TYPO3-project-4-3] indexed_search for 4.3 In-Reply-To: References: Message-ID: Hi. Steffen Kamper wrote: > Hi, > > as requested here is the brainstorming thread for indexed_search. > I thought about two new features: * search/find-as-you-type as already realized in mh_ajaxsearch or pmkisac. * soundex comparison and suggestion (like the "Did you mean ..." in google). The quality of soundex heavily depends on the locale, so we would need a bunch of libs to support other languages than EN. Each lib generates the soundex keys for a single language. That would also mean additional table relation between words and soundex keys (1-n). Recently, there has been a french soundex implementation in the EM. -- cheers, Steffen From info at sk-typo3.de Wed Sep 10 16:27:11 2008 From: info at sk-typo3.de (Steffen Kamper) Date: Wed, 10 Sep 2008 16:27:11 +0200 Subject: [TYPO3-project-4-3] indexed_search for 4.3 In-Reply-To: References:

Message-ID: Martin Kutschker schrieb: > Steffen Kamper schrieb: >> Hi, >> >> i know Ingo and Stucki did an performance improvement, would like to >> have this integrated too > > Did you test their prerequesit? This would be the page tree / rootline > cache. Without that you won't get full speed. > > Masi Hi Masi, i didn't as i don't know if it's available anywhere, but i would like to do vg Steffen From info at sk-typo3.de Wed Sep 10 17:24:15 2008 From: info at sk-typo3.de (Steffen Kamper) Date: Wed, 10 Sep 2008 17:24:15 +0200 Subject: [TYPO3-project-4-3] indexed_search for 4.3 In-Reply-To: References: Message-ID: hi, additionally i did this in TS: code = form,rules,results as default. This means that it's possible to render form only by code = form or change the order of the output like code = results,form,rules vg Steffen From gaumondpatrick-s-p-a-m at hotmail-sp-a-m.com Wed Sep 10 17:31:50 2008 From: gaumondpatrick-s-p-a-m at hotmail-sp-a-m.com (Patrick Gaumond) Date: Wed, 10 Sep 2008 11:31:50 -0400 Subject: [TYPO3-project-4-3] indexed_search for 4.3 In-Reply-To: References:

Message-ID: Steffen M?ller wrote: > * soundex comparison and suggestion (like the "Did you mean ..." in > google). The quality of soundex heavily depends on the locale, so we > would need a bunch of libs to support other languages than EN. Each lib > generates the soundex keys for a single language. That would also mean > additional table relation between words and soundex keys (1-n). > Recently, there has been a french soundex implementation in the EM. Yes, soundex is usually a good thing. And while at it, it looks like TYPO3 5.0 CR (Content Repository)will use the Lucene PHP implementation: > I just committed > http://forge.typo3.org/repositories/revision/package-typo3cr/1143 > which introduces Zend_Search_Lucene as indexing/searching engine > in TYPO3CR Source: http://support.typo3.org/projects/typo3-5-0general/m/typo3-50-general-lucene-used-for-search-in-cr-as-of-today-359330/p/9/ And someone also did some more Lucene work in the 4.0 area: http://typo3.org/documentation/document-library/extension-manuals/powersearchindexlucene/1.0.3/view/1/2/ I didn't test any of this. I'm just giving hints and links. Patrick From masi-no at spam-typo3.org Wed Sep 10 19:49:05 2008 From: masi-no at spam-typo3.org (Martin Kutschker) Date: Wed, 10 Sep 2008 19:49:05 +0200 Subject: [TYPO3-project-4-3] indexed_search for 4.3 In-Reply-To: References:

Message-ID: Steffen Kamper schrieb: > Martin Kutschker schrieb: >> Steffen Kamper schrieb: >>> Hi, >>> >>> i know Ingo and Stucki did an performance improvement, would like to >>> have this integrated too >> >> Did you test their prerequesit? This would be the page tree / rootline >> cache. Without that you won't get full speed. >> >> Masi > > Hi Masi, > > i didn't as i don't know if it's available anywhere, but i would like to do Search the Core list. It's pending for at least a month if not two now. Ingo posted it. There was only a discussion if to add this into the Core, as a sysext or on TER. I think noone tested it. Masi From info at sk-typo3.de Thu Sep 11 09:50:59 2008 From: info at sk-typo3.de (Steffen Kamper) Date: Thu, 11 Sep 2008 09:50:59 +0200 Subject: [TYPO3-project-4-3] indexed_search for 4.3 In-Reply-To: References:

Message-ID: Martin Kutschker schrieb: > Steffen Kamper schrieb: >> Martin Kutschker schrieb: >>> Steffen Kamper schrieb: >>>> Hi, >>>> >>>> i know Ingo and Stucki did an performance improvement, would like to >>>> have this integrated too >>> Did you test their prerequesit? This would be the page tree / rootline >>> cache. Without that you won't get full speed. >>> >>> Masi >> Hi Masi, >> >> i didn't as i don't know if it's available anywhere, but i would like to do > > Search the Core list. It's pending for at least a month if not two now. > Ingo posted it. There was only a discussion if to add this into the > Core, as a sysext or on TER. I think noone tested it. > > Masi Hi Masi, i searched the core list and only found the patch from Ingo for the cached rootline, where he said that this is important for the new indexed search. vg Steffen From masi-no at spam-typo3.org Thu Sep 11 10:23:06 2008 From: masi-no at spam-typo3.org (Martin Kutschker) Date: Thu, 11 Sep 2008 10:23:06 +0200 Subject: [TYPO3-project-4-3] indexed_search for 4.3 In-Reply-To: References:

Message-ID: Steffen Kamper schrieb: > Martin Kutschker schrieb: >> Steffen Kamper schrieb: >>> Martin Kutschker schrieb: >>>> Steffen Kamper schrieb: >>>>> Hi, >>>>> >>>>> i know Ingo and Stucki did an performance improvement, would like to >>>>> have this integrated too >>>> Did you test their prerequesit? This would be the page tree / rootline >>>> cache. Without that you won't get full speed. >>>> >>>> Masi >>> Hi Masi, >>> >>> i didn't as i don't know if it's available anywhere, but i would like >>> to do >> >> Search the Core list. It's pending for at least a month if not two now. >> Ingo posted it. There was only a discussion if to add this into the >> Core, as a sysext or on TER. I think noone tested it. >> >> Masi > > Hi Masi, > > i searched the core list and only found the patch from Ingo for the > cached rootline, where he said that this is important for the new > indexed search. This is the one I'm talking about. They will send the rest of the improvement only afrter this one has been added to the COre. Masi From info at sk-typo3.de Thu Sep 11 10:29:01 2008 From: info at sk-typo3.de (Steffen Kamper) Date: Thu, 11 Sep 2008 10:29:01 +0200 Subject: [TYPO3-project-4-3] indexed_search for 4.3 In-Reply-To: References:

Message-ID: Martin Kutschker schrieb: > > This is the one I'm talking about. They will send the rest of the > improvement only afrter this one has been added to the COre. > > Masi interesting. I made a complete review and time measure, and the patch was committed at 7.8. vg Steffen From masi-no at spam-typo3.org Thu Sep 11 11:08:36 2008 From: masi-no at spam-typo3.org (Martin Kutschker) Date: Thu, 11 Sep 2008 11:08:36 +0200 Subject: [TYPO3-project-4-3] indexed_search for 4.3 In-Reply-To: References:

Message-ID: Steffen Kamper schrieb: > Martin Kutschker schrieb: >> >> This is the one I'm talking about. They will send the rest of the >> improvement only afrter this one has been added to the COre. >> >> Masi > > > interesting. I made a complete review and time measure, and the patch > was committed at 7.8. Really? i though it was pending. But hey, they are so many bugs around... Masi From info at sk-typo3.de Fri Sep 12 00:13:56 2008 From: info at sk-typo3.de (Steffen Kamper) Date: Fri, 12 Sep 2008 00:13:56 +0200 Subject: [TYPO3-project-4-3] indexed_search for 4.3 In-Reply-To: References:

Message-ID: Steffen M?ller schrieb: > Hi. > > Steffen Kamper wrote: >> Hi, >> >> as requested here is the brainstorming thread for indexed_search. >> > > I thought about two new features: > > * search/find-as-you-type as already realized in mh_ajaxsearch or pmkisac. > * soundex comparison and suggestion (like the "Did you mean ..." in > google). The quality of soundex heavily depends on the locale, so we > would need a bunch of libs to support other languages than EN. Each lib > generates the soundex keys for a single language. That would also mean > additional table relation between words and soundex keys (1-n). > Recently, there has been a french soundex implementation in the EM. > Hi Steffen, as i like such features i think it's a bit overhead for IS. Soundex only works with english, there is no "easy" integration of such feature for all languages (i didn't looked at the french one) Also the ajax completition sounds great, but as complex the search algorythm is, i fear that it's not done with good performance. Remember that normal IS is a performance killer for many sites with vig big result tables, don't speaking about external file search. vg Steffen From masi-no at spam-typo3.org Fri Sep 12 11:20:46 2008 From: masi-no at spam-typo3.org (Martin Kutschker) Date: Fri, 12 Sep 2008 11:20:46 +0200 Subject: [TYPO3-project-4-3] indexed_search for 4.3 In-Reply-To: References:

Message-ID: Steffen Kamper schrieb: > > Also the ajax completition sounds great, but as complex the search > algorythm is, i fear that it's not done with good performance. You're right. Auto completition is not an option. What could be done though is to have an auto complettiiton based on terms the users searched for. Masi From info at sk-typo3.de Fri Sep 12 12:33:28 2008 From: info at sk-typo3.de (Steffen Kamper) Date: Fri, 12 Sep 2008 12:33:28 +0200 Subject: [TYPO3-project-4-3] indexed_search for 4.3 In-Reply-To: References:

Message-ID: Martin Kutschker schrieb: > Steffen Kamper schrieb: >> Also the ajax completition sounds great, but as complex the search >> algorythm is, i fear that it's not done with good performance. > > You're right. Auto completition is not an option. What could be done > though is to have an auto complettiiton based on terms the users > searched for. > > Masi good idea. That would mean that every search saves the search word user types. It has to be deleted after search if result is 0. Good that it's not for single user as these saved search expressions are saved for all users. vg Steffen From typo3 at t3node.com Fri Sep 12 13:55:31 2008 From: typo3 at t3node.com (=?ISO-8859-15?Q?Steffen_M=FCller?=) Date: Fri, 12 Sep 2008 13:55:31 +0200 Subject: [TYPO3-project-4-3] indexed_search for 4.3 In-Reply-To: References:

Message-ID: Hi. On 12.09.2008 00:13 Steffen Kamper wrote: > > Soundex only works with english, there is no "easy" integration of such > feature for all languages (i didn't looked at the french one) > My idea was to have some kind of service API for language specific soundex algorithms. The lexer could check if the actual language is supported, then call a wrapper function and calculate the according soundex keys. However this is solved technically, the algorithms can be natively shipped by IS or by 3rd party extensions. This would make it possible to support multiple languages concurrently and even to choose alternative algorithms for one language (e.g. soundex or metaphone). For english, there's two native php functions: http://us2.php.net/soundex http://us2.php.net/manual/de/function.metaphone.php For german, there's the "Cologne Phonetic". You can find the code in the comments of the above soundex function. The mentioned french extension bases on the phonex algorithm: http://typo3.org/extensions/repository/view/search_suggestions/1.0.0/info/phonex.class.php/ The implementation bases on some code by Fr?d?ric Brouard: http://sqlpro.developpez.com/cours/soundex/ I found a double_metaphone algorithm for spanish: http://www.geocities.com/isloera/spanish_methaphone.txt That's at least four implementations though I did not test them. I bet there are some more around. The index_words table already has a metaphone column. But I have no clue if it is used at all. Also performance is an issue here. -- cheers, Steffen http://www.t3node.com/ From typo3 at t3node.com Fri Sep 12 14:19:45 2008 From: typo3 at t3node.com (=?ISO-8859-15?Q?Steffen_M=FCller?=) Date: Fri, 12 Sep 2008 14:19:45 +0200 Subject: [TYPO3-project-4-3] indexed_search for 4.3 In-Reply-To: References:

Message-ID: Hi. On 12.09.2008 00:13 Steffen Kamper wrote: > > Also the ajax completition sounds great, but as complex the search > algorythm is, i fear that it's not done with good performance. > > Remember that normal IS is a performance killer for many sites with vig > big result tables, don't speaking about external file search. > The autocompleter queries can be separated from any complex search query itself. No impact on the performance of the result query, no searchword<->resultpage query needed. (like it is handled in the firefox search box: show suggestions as user types, but query results are gathered in a second step) IMHO a DB key for basewords in index_words and queries limited to LIKE $searchCharacter% should work to fetch all possible search words. But I admit, I didn't test the performance of this query with huge tables. These are just brainstorming ideas. Keep in mind that even some retarded autocomplete suggestions can have a positive impact on the effectivity of users research. From a users point of view, this can mean a performance gain in spite of little autocomplete delays. -- cheers, Steffen http://www.t3node.com/ From masi-no at spam-typo3.org Fri Sep 12 14:22:27 2008 From: masi-no at spam-typo3.org (Martin Kutschker) Date: Fri, 12 Sep 2008 14:22:27 +0200 Subject: [TYPO3-project-4-3] indexed_search for 4.3 In-Reply-To: References:

Message-ID: Steffen Kamper schrieb: > Martin Kutschker schrieb: >> Steffen Kamper schrieb: >>> Also the ajax completition sounds great, but as complex the search >>> algorythm is, i fear that it's not done with good performance. >> >> You're right. Auto completition is not an option. What could be done >> though is to have an auto complettiiton based on terms the users >> searched for. >> >> Masi > > good idea. That would mean that every search saves the search word user > types. Already there. Have a look at Web>Info Indexed Search Statistics (something like that). > It has to be deleted after search if result is 0. No, this helps the admin to see what the users are looking for. But words with 0 results shouldn't be suggested in the AJAX search box. But as you could type in more than one word this needs to be properly thought of. Masi From ingo at typo3.org Fri Sep 12 19:01:08 2008 From: ingo at typo3.org (Ingo Renner) Date: Fri, 12 Sep 2008 12:01:08 -0500 Subject: [TYPO3-project-4-3] indexed_search for 4.3 In-Reply-To: References:

Message-ID: Hi Masi, hi Steffen, >> Did you test their prerequesit? This would be the page tree / rootline >> cache. Without that you won't get full speed. > i didn't as i don't know if it's available anywhere, but i would like to do it's in trunk already =) Now the only thing missing is Stucki's MySQL Fulltext Index stuff Ingo -- Ingo Renner TYPO3 Core Developer, Release Manager TYPO3 4.2 From typo3 at t3node.com Sat Sep 13 15:11:32 2008 From: typo3 at t3node.com (=?ISO-8859-15?Q?Steffen_M=FCller?=) Date: Sat, 13 Sep 2008 15:11:32 +0200 Subject: [TYPO3-project-4-3] indexed_search for 4.3 In-Reply-To: References:

Message-ID: Hi. On 12.09.2008 19:01 Ingo Renner wrote: > >>> Did you test their prerequesit? This would be the page tree / rootline >>> cache. Without that you won't get full speed. > > > it's in trunk already =) > Couldn't find it. which revision? Thanks! -- cheers, Steffen http://www.t3node.com/ From info at sk-typo3.de Sat Sep 13 17:04:58 2008 From: info at sk-typo3.de (Steffen Kamper) Date: Sat, 13 Sep 2008 17:04:58 +0200 Subject: [TYPO3-project-4-3] indexed_search for 4.3 In-Reply-To: References:

Message-ID: Steffen M?ller schrieb: > Hi. > > On 12.09.2008 19:01 Ingo Renner wrote: >>>> Did you test their prerequesit? This would be the page tree / rootline >>>> cache. Without that you won't get full speed. >> >> it's in trunk already =) >> > > Couldn't find it. which revision? > Thanks! > Hi Steffen, here it is: http://forge.typo3.org/repositories/revision/typo3v4-core/3947 vg Steffen From typo3 at t3node.com Sat Sep 13 20:21:11 2008 From: typo3 at t3node.com (=?ISO-8859-15?Q?Steffen_M=FCller?=) Date: Sat, 13 Sep 2008 20:21:11 +0200 Subject: [TYPO3-project-4-3] indexed_search for 4.3 In-Reply-To: References:

Message-ID: On 13.09.2008 17:04 Steffen Kamper wrote: >> >> Couldn't find it. which revision? > > here it is: > http://forge.typo3.org/repositories/revision/typo3v4-core/3947 > thanks! -- cheers, Steffen http://www.t3node.com/ From ng at ralfhettinger.de Sun Sep 14 16:27:27 2008 From: ng at ralfhettinger.de (Ralf Hettinger) Date: Sun, 14 Sep 2008 16:27:27 +0200 Subject: [TYPO3-project-4-3] indexed_search for 4.3 In-Reply-To: References: Message-ID: Hi, Steffen Kamper schrieb: > Hi, > > as requested here is the brainstorming thread for indexed_search. > > I started modification with > > * remove hardcoded html for compiled result and use subpart in template [1] > * build pagebrowser with stdWraps from TS [2] > > as requested from Patrick: > > * render searchBox only usind resultPid from TS (like macina searchbox > does) > > * use typolinks for using linkVars or addQueryString > > > any additional ideas are welcome :-) > * enable result navigation (pagebrowser) that doesn't rely on JavaScript only (e.g. by using [3]) Cheers Ralf [3] http://bugs.typo3.org/view.php?id=1347 From info at sk-typo3.de Sun Sep 14 17:11:51 2008 From: info at sk-typo3.de (Steffen Kamper) Date: Sun, 14 Sep 2008 17:11:51 +0200 Subject: [TYPO3-project-4-3] indexed_search for 4.3 In-Reply-To: References:

Message-ID: Hi Ralf, Ralf Hettinger schrieb: > > * enable result navigation (pagebrowser) that doesn't rely on JavaScript > only (e.g. by using [3]) > > Cheers > Ralf > > > [3] http://bugs.typo3.org/view.php?id=1347 good one! I will take it into account. vg Steffen From info at sk-typo3.de Sun Sep 14 19:21:22 2008 From: info at sk-typo3.de (Steffen Kamper) Date: Sun, 14 Sep 2008 19:21:22 +0200 Subject: [TYPO3-project-4-3] Splitting t3lib_div and having autoloader instead of inclusions Message-ID: Hi, i try to sum up the discussion started in core list inside RFC for HTTP_STATUS-constants. As the discussion is misplaced in corelist, Francois asked for moving this. IDEA Ingo came up with the idea to split t3lib_div into single classes. To be compatible the idea was to use t3lib_div as a container having the functions inside but calling the new classes. For using these classes an autoloader should be used as PHP5 comes along with such possibility. Main point of the discussion was the naming issue. * How should the new classes be named? Many proposals used underscores, Dmitry veto'd because of naming convention. * where should the classes be located, in t3lib-folder or in subfolders? AUTOLOAD For use an autoload the naming issue should be solved first. Ingo and Masi started with an SPL-idea http://bugs.typo3.org/view.php?id=9116 I tried with such a funtion: http://pastebin.com/m1c6ebeb2 I hope i didn't forgot an important thing, if so please add it. vg Steffen From dmitry at typo3.org Sun Sep 14 21:26:17 2008 From: dmitry at typo3.org (Dmitry Dulepov [typo3]) Date: Sun, 14 Sep 2008 22:26:17 +0300 Subject: [TYPO3-project-4-3] indexed_search for 4.3 In-Reply-To: References:

Message-ID: Hi! Ralf Hettinger wrote: > * enable result navigation (pagebrowser) that doesn't rely on JavaScript > only (e.g. by using [3]) I made a dedicated page browser extension as a part of my work in Netcreators. It is specially developed for use from other extensions. Comments extension will soon migrate to use this new page browser. The extension is not public yet. You can see something close in functionality here: http://scan.vara.nl/pg.9-8.archief.htm It is *not* my extension there but I got inspiration from this web site. There are first [on/off], previous [on/off], dots-previous [on/off], page list [configurable number of before/after], dots-next [on/off], next [on/off], last links [on/off]. I think more and more to propose the page browser as a new sysext when the extension becomes public. This way we will have common feature reach pagebrowser that can be used by the indexed search too. Here is a code from one real extension that creates the page browser: protected function getListGetPageBrowser($numOfPages) { // Get default configuration $conf = $GLOBALS['TSFE']->tmpl->setup['plugin.']['tx_pagebrowse_pi1.']; // Modify this configuration $conf += array( 'pageParamName' => $this->prefixId . '|page', 'numPages' => intval($numOfPages/$this->conf['pageSize']) + (($numOfPages % $this->conf['pageSize']) == 0 ? 0 : 1), ); // Get page browser $cObj = t3lib_div::makeInstance('tslib_cObj'); /* @var $cObj tslib_cObj */ $cObj->start(array(), ''); return $cObj->cObjGetSingle('USER', $conf); } As you see from the example, it is really simple. The page browser even uses $this->extPrefix to create a configurable piVar for the current extension. Seven lines of code (without comments) and you have s fully styleable and templateable page browser! The page browser is also clever enough to make cHashes. It will skip page parameter for the first page and avoid extra page cache entry, which is extra optimization. The only missing thing to the moment is the manual and public status of the extension. -- Dmitry Dulepov TYPO3 Core team My TYPO3 book: http://www.packtpub.com/typo3-extension-development/book In the blog: http://typo3bloke.net/pages/book-reviews/presentation-zen-by-garr-reynolds/ From dmitry at typo3.org Sun Sep 14 21:29:58 2008 From: dmitry at typo3.org (Dmitry Dulepov [typo3]) Date: Sun, 14 Sep 2008 22:29:58 +0300 Subject: [TYPO3-project-4-3] Splitting t3lib_div and having autoloader instead of inclusions In-Reply-To: References: Message-ID: Hi! Steffen Kamper wrote: > Main point of the discussion was the naming issue. > * How should the new classes be named? Many proposals used underscores, > Dmitry veto'd because of naming convention. It is not veto. It is a note that we decided not to use underscores in class or function names. If we say we allow this, it means we change CGL. We just need to make a decision and vote about it. > * where should the classes be located, in t3lib-folder or in subfolders? I like structure. I prefer subfolders. But do not want 100 subfolders with 1-2 files in each :( > AUTOLOAD > > For use an autoload the naming issue should be solved first. Not necessarily. A registry could do. -- Dmitry Dulepov TYPO3 Core team My TYPO3 book: http://www.packtpub.com/typo3-extension-development/book In the blog: http://typo3bloke.net/pages/book-reviews/presentation-zen-by-garr-reynolds/ From fsuter at cobweb.ch Sun Sep 14 21:48:25 2008 From: fsuter at cobweb.ch (Francois Suter) Date: Sun, 14 Sep 2008 21:48:25 +0200 Subject: [TYPO3-project-4-3] indexed_search for 4.3 In-Reply-To: References:

Message-ID: Hi, > I made a dedicated page browser extension as a part of my work in > Netcreators. It is specially developed for use from other extensions. > Comments extension will soon migrate to use this new page browser. The > extension is not public yet. When can we expect it to be public? I'm looking at the development of such a page browser now and I would gladly not reinvent the wheel. Cheers -- Francois Suter Cobweb Development Sarl - http://www.cobweb.ch From dmitry at typo3.org Sun Sep 14 21:57:13 2008 From: dmitry at typo3.org (Dmitry Dulepov [typo3]) Date: Sun, 14 Sep 2008 22:57:13 +0300 Subject: [TYPO3-project-4-3] indexed_search for 4.3 In-Reply-To: References:

Message-ID: Hi! Francois Suter wrote: > When can we expect it to be public? I'm looking at the development of > such a page browser now and I would gladly not reinvent the wheel. I hope it will be very soon. I'll ask internally. If I can write the manual quickly, it should be a matter of days. -- Dmitry Dulepov TYPO3 Core team My TYPO3 book: http://www.packtpub.com/typo3-extension-development/book In the blog: http://typo3bloke.net/post-details/debugging_symlinked_typo3_files_with_komodo_ide_on_mac/ From info at sk-typo3.de Sun Sep 14 22:42:30 2008 From: info at sk-typo3.de (Steffen Kamper) Date: Sun, 14 Sep 2008 22:42:30 +0200 Subject: [TYPO3-project-4-3] Splitting t3lib_div and having autoloader instead of inclusions In-Reply-To: References:

Message-ID: Hi Dmitry, Dmitry Dulepov [typo3] schrieb: > Hi! > > Steffen Kamper wrote: >> Main point of the discussion was the naming issue. >> * How should the new classes be named? Many proposals used >> underscores, Dmitry veto'd because of naming convention. > > It is not veto. It is a note that we decided not to use underscores in > class or function names. If we say we allow this, it means we change > CGL. We just need to make a decision and vote about it. > >> * where should the classes be located, in t3lib-folder or in subfolders? > > I like structure. I prefer subfolders. But do not want 100 subfolders > with 1-2 files in each :( > i understand this. Do you have a proposal which subfolder/grouping would make sense in your eyes? >> AUTOLOAD >> >> For use an autoload the naming issue should be solved first. > > Not necessarily. A registry could do. > Indeed a good idea. Do you have any idea or do you know such registry from other projects? vg Steffen From info at sk-typo3.de Sun Sep 14 22:52:26 2008 From: info at sk-typo3.de (Steffen Kamper) Date: Sun, 14 Sep 2008 22:52:26 +0200 Subject: [TYPO3-project-4-3] Splitting t3lib_div and having autoloader instead of inclusions In-Reply-To: References:

Message-ID: Dmitry Dulepov [typo3] schrieb: >> AUTOLOAD >> >> For use an autoload the naming issue should be solved first. > > Not necessarily. A registry could do. > may be we can learn something from Drupal http://api.drupal.org/api/group/registry/7 vg Steffen From ingo at typo3.org Sun Sep 14 22:55:14 2008 From: ingo at typo3.org (Ingo Renner) Date: Sun, 14 Sep 2008 15:55:14 -0500 Subject: [TYPO3-project-4-3] Splitting t3lib_div and having autoloader instead of inclusions In-Reply-To: References:

Message-ID: Dmitry Dulepov [typo3] wrote: >> AUTOLOAD >> >> For use an autoload the naming issue should be solved first. > > Not necessarily. A registry could do. With our current structure and their exceptions we'll need a mix of a an autoloader and a registry anyways ;) Ingo -- Ingo Renner TYPO3 Core Developer, Release Manager TYPO3 4.2 From benni at typo3.org Sun Sep 14 23:09:30 2008 From: benni at typo3.org (Benjamin Mack) Date: Sun, 14 Sep 2008 16:09:30 -0500 Subject: [TYPO3-project-4-3] Splitting t3lib_div and having autoloader instead of inclusions In-Reply-To: References:

Message-ID: Hey Steffen, Steffen Kamper wrote: > i understand this. Do you have a proposal which subfolder/grouping would > make sense in your eyes? I like the Zend Framework structure, unfortunately not as easy for existing projects as ours. -- All the best, benni. -SDG- From ingo at typo3.org Sun Sep 14 23:15:20 2008 From: ingo at typo3.org (Ingo Renner) Date: Sun, 14 Sep 2008 16:15:20 -0500 Subject: [TYPO3-project-4-3] Splitting t3lib_div and having autoloader instead of inclusions In-Reply-To: References:

Message-ID: Steffen Kamper wrote: > may be we can learn something from Drupal > > http://api.drupal.org/api/group/registry/7 the description definitly sounds interesting and goes even further than what we thought about yet... thanks for digging this up! Ingo -- Ingo Renner TYPO3 Core Developer, Release Manager TYPO3 4.2 From info at sk-typo3.de Mon Sep 15 10:12:31 2008 From: info at sk-typo3.de (Steffen Kamper) Date: Mon, 15 Sep 2008 10:12:31 +0200 Subject: [TYPO3-project-4-3] indexed_search for 4.3 In-Reply-To: References: Message-ID: Hi, if someone is interested, here is the work i did with IS so far vg Steffen -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: is_work.diff Url: http://lists.netfielders.de/pipermail/typo3-project-4-3/attachments/20080915/92c16944/attachment.txt From news at ringerge.org Mon Sep 15 11:22:49 2008 From: news at ringerge.org (Georg Ringer) Date: Mon, 15 Sep 2008 11:22:49 +0200 Subject: [TYPO3-project-4-3] indexed_search for 4.3 In-Reply-To: References:

Message-ID: Dmitry Dulepov [typo3] wrote: > As you see from the example, it is really simple. The page browser even > uses $this->extPrefix to create a configurable piVar for the current > extension. Seven lines of code (without comments) and you have s fully > styleable and templateable page browser! great! I would use it immediatly in my extensions ;) Georg From info at sk-typo3.de Mon Sep 15 11:27:18 2008 From: info at sk-typo3.de (Steffen Kamper) Date: Mon, 15 Sep 2008 11:27:18 +0200 Subject: [TYPO3-project-4-3] indexed_search for 4.3 In-Reply-To: References:

Message-ID: Hi, Dmitry Dulepov [typo3] schrieb: > Hi! > > Ralf Hettinger wrote: >> * enable result navigation (pagebrowser) that doesn't rely on >> JavaScript only (e.g. by using [3]) > this is independent from used pagebrowser as these links are compiled in an extra function of IS, the pagebrowser used is the one from pibase. > I made a dedicated page browser extension as a part of my work in > Netcreators. It is specially developed for use from other extensions. > Comments extension will soon migrate to use this new page browser. The > extension is not public yet. > > You can see something close in functionality here: > http://scan.vara.nl/pg.9-8.archief.htm It is *not* my extension there > but I got inspiration from this web site. There are first [on/off], > previous [on/off], dots-previous [on/off], page list [configurable > number of before/after], dots-next [on/off], next [on/off], last links > [on/off]. > > I think more and more to propose the page browser as a new sysext when > the extension becomes public. This way we will have common feature reach > pagebrowser that can be used by the indexed search too. > > Here is a code from one real extension that creates the page browser: > > protected function getListGetPageBrowser($numOfPages) { > // Get default configuration > $conf = $GLOBALS['TSFE']->tmpl->setup['plugin.']['tx_pagebrowse_pi1.']; > // Modify this configuration > $conf += array( > 'pageParamName' => $this->prefixId . '|page', > 'numPages' => intval($numOfPages/$this->conf['pageSize']) + > (($numOfPages % $this->conf['pageSize']) == 0 ? 0 : 1), > ); > // Get page browser > $cObj = t3lib_div::makeInstance('tslib_cObj'); > /* @var $cObj tslib_cObj */ > $cObj->start(array(), ''); > return $cObj->cObjGetSingle('USER', $conf); > } > > As you see from the example, it is really simple. The page browser even > uses $this->extPrefix to create a configurable piVar for the current > extension. Seven lines of code (without comments) and you have s fully > styleable and templateable page browser! > > The page browser is also clever enough to make cHashes. It will skip > page parameter for the first page and avoid extra page cache entry, > which is extra optimization. The only missing thing to the moment is the > manual and public status of the extension. > great! As the pibase pagebrowser is conceptional for usage from extensions, is there a possibility to enhance that one or exchange with yours? vg Steffen From dmitry at typo3.org Mon Sep 15 12:25:23 2008 From: dmitry at typo3.org (Dmitry Dulepov [typo3]) Date: Mon, 15 Sep 2008 13:25:23 +0300 Subject: [TYPO3-project-4-3] Splitting t3lib_div and having autoloader instead of inclusions In-Reply-To: References:

Message-ID: Hi! Steffen Kamper wrote: > i understand this. Do you have a proposal which subfolder/grouping would > make sense in your eyes? I think we should have function groups first. > Indeed a good idea. Do you have any idea or do you know such registry > from other projects? Not for PHP. Again, we can make requirements for such registry after we have function/class groups. We need a live use examples to see how better organize such registry. Basically it is a map of class<=>filename relations. Pure PHP, no database involved. -- Dmitry Dulepov TYPO3 Core team My TYPO3 book: http://www.packtpub.com/typo3-extension-development/book In the blog: http://typo3bloke.net/post-details/debugging_symlinked_typo3_files_with_komodo_ide_on_mac/ From dmitry at typo3.org Mon Sep 15 12:31:43 2008 From: dmitry at typo3.org (Dmitry Dulepov [typo3]) Date: Mon, 15 Sep 2008 13:31:43 +0300 Subject: [TYPO3-project-4-3] indexed_search for 4.3 In-Reply-To: References:

Message-ID: Hi! Steffen Kamper wrote: > this is independent from used pagebrowser as these links are compiled in > an extra function of IS, the pagebrowser used is the one from pibase. Yes. Table-based and not really customizable. > As the pibase pagebrowser is conceptional for usage from extensions, is > there a possibility to enhance that one or exchange with yours? I do not think so. tslib_pibase cannot have templates, etc. It even cannot have localized strings unless we include them to cms ext. Having a standalone extension is better. It can be sent to TER with TYPO3 version requirement < 4.3 and people can start using it right now. If it comes as sysext, people do not have to do anything when system is upgraded. Admin sismply uses sysext instead of the same ext from TER. tslib_pibase code can be changed to check if page browser is installed and use it. If not installed, skip to old method. -- Dmitry Dulepov TYPO3 Core team My TYPO3 book: http://www.packtpub.com/typo3-extension-development/book In the blog: http://typo3bloke.net/post-details/debugging_symlinked_typo3_files_with_komodo_ide_on_mac/ From info at sk-typo3.de Mon Sep 15 12:56:15 2008 From: info at sk-typo3.de (Steffen Kamper) Date: Mon, 15 Sep 2008 12:56:15 +0200 Subject: [TYPO3-project-4-3] indexed_search for 4.3 In-Reply-To: References:

Message-ID: hi Dmitry, Dmitry Dulepov [typo3] schrieb: > I do not think so. tslib_pibase cannot have templates, etc. It even > cannot have localized strings unless we include them to cms ext. > > Having a standalone extension is better. It can be sent to TER with > TYPO3 version requirement < 4.3 and people can start using it right now. > If it comes as sysext, people do not have to do anything when system is > upgraded. Admin sismply uses sysext instead of the same ext from TER. > > tslib_pibase code can be changed to check if page browser is installed > and use it. If not installed, skip to old method. > please do so! This would be a great benefit to have a "real" pagebrowser configurable, devs will be happy if there is a built-in-solution. Also i recognized that many devs don't use the pibase one because they don't know how to configure and work with it. vg Steffen From ng at ralfhettinger.de Mon Sep 15 15:02:38 2008 From: ng at ralfhettinger.de (Ralf Hettinger) Date: Mon, 15 Sep 2008 15:02:38 +0200 Subject: [TYPO3-project-4-3] indexed_search for 4.3 In-Reply-To: References:

Message-ID: Hi. Dmitry Dulepov [typo3] schrieb: > You can see something close in functionality here: > http://scan.vara.nl/pg.9-8.archief.htm It is *not* my extension there > but I got inspiration from this web site. There are first [on/off], > previous [on/off], dots-previous [on/off], page list [configurable > number of before/after], dots-next [on/off], next [on/off], last links > [on/off]. This indeed sounds very very neat and it would be great to have it available. But I think we have some special situation for indexed_search, which has been discussed a bit in BT [1]: indexed_search can have many parameters, which would have probably to be transfered as GET-params using a generalized pagebrowser or tx_pagebrowse_pi1. The patch in [1] therefore suggests the possibility to create a pagebrowser with submit buttons and hidden input fields to submit those parameters by POST. Could tx_pagebrowse_pi1 be used to do that (render pagebrowser "links" as submit buttons and putting in hidden input fields)? If not, I would be happy to have at least an optional (meaning: configurable to use) solution _within_ indexed_search that uses submit buttons as pagebrowser. Cheers Ralf [1] http://bugs.typo3.org/view.php?id=1347 From ng at ralfhettinger.de Mon Sep 15 15:21:13 2008 From: ng at ralfhettinger.de (Ralf Hettinger) Date: Mon, 15 Sep 2008 15:21:13 +0200 Subject: [TYPO3-project-4-3] indexed_search for 4.3 In-Reply-To: References:

Message-ID: Adding an examplary reference that uses submit buttons for page browsing indexed_search results - which might be of help to see how it's meant by looking at the HTML source (unfortunately, it's in german only currently): http://www.ea-aw.de/de/website/website-durchsuchen.html (you may want to search for "akademie"). Cheers Ralf Ralf Hettinger schrieb: > Hi. > > Dmitry Dulepov [typo3] schrieb: >> You can see something close in functionality here: >> http://scan.vara.nl/pg.9-8.archief.htm It is *not* my extension there >> but I got inspiration from this web site. There are first [on/off], >> previous [on/off], dots-previous [on/off], page list [configurable >> number of before/after], dots-next [on/off], next [on/off], last links >> [on/off]. > > This indeed sounds very very neat and it would be great to have it > available. > > > But I think we have some special situation for indexed_search, which has > been discussed a bit in BT [1]: > > indexed_search can have many parameters, which would have probably to be > transfered as GET-params using a generalized pagebrowser or > tx_pagebrowse_pi1. The patch in [1] therefore suggests the possibility > to create a pagebrowser with submit buttons and hidden input fields to > submit those parameters by POST. > > Could tx_pagebrowse_pi1 be used to do that (render pagebrowser "links" > as submit buttons and putting in hidden input fields)? > > If not, I would be happy to have at least an optional (meaning: > configurable to use) solution _within_ indexed_search that uses submit > buttons as pagebrowser. > > > Cheers > Ralf > > > [1] http://bugs.typo3.org/view.php?id=1347 From info at sk-typo3.de Mon Sep 15 15:41:53 2008 From: info at sk-typo3.de (Steffen Kamper) Date: Mon, 15 Sep 2008 15:41:53 +0200 Subject: [TYPO3-project-4-3] indexed_search for 4.3 In-Reply-To: References:

Message-ID: Ralf Hettinger schrieb: > Adding an examplary reference that uses submit buttons for page browsing > indexed_search results - which might be of help to see how it's meant by > looking at the HTML source (unfortunately, it's in german only currently): > > http://www.ea-aw.de/de/website/website-durchsuchen.html (you may want to > search for "akademie"). > > Cheers > Ralf > > Hi ralf, i read the bt entry and the reason was too long urls? I'm a bit confused as the JS-links use same url in onclick="..." Looking to your example i don't see a reason for a long url, so can you enlighten me why this is needed? thx in advance, vg Steffen From ingo at typo3.org Mon Sep 15 16:29:06 2008 From: ingo at typo3.org (Ingo Renner) Date: Mon, 15 Sep 2008 09:29:06 -0500 Subject: [TYPO3-project-4-3] Splitting t3lib_div and having autoloader instead of inclusions In-Reply-To: References:

Message-ID: Dmitry Dulepov [typo3] wrote: > Basically it is a map of class<=>filename relations. Pure PHP, no > database involved. let's check Drupal's implementation Steffen dug up. Ingo -- Ingo Renner TYPO3 Core Developer, Release Manager TYPO3 4.2 From ingo at typo3.org Mon Sep 15 16:32:04 2008 From: ingo at typo3.org (Ingo Renner) Date: Mon, 15 Sep 2008 09:32:04 -0500 Subject: [TYPO3-project-4-3] indexed_search for 4.3 In-Reply-To: References:

Message-ID: Dmitry Dulepov [typo3] wrote: Hey Dmitry, > Having a standalone extension is better. It can be sent to TER with > TYPO3 version requirement < 4.3 and people can start using it right now. > If it comes as sysext, people do not have to do anything when system is > upgraded. Admin sismply uses sysext instead of the same ext from TER. > > tslib_pibase code can be changed to check if page browser is installed > and use it. If not installed, skip to old method. wouldn't that be a perfect fit for extbase then?! Ingo -- Ingo Renner TYPO3 Core Developer, Release Manager TYPO3 4.2 From ng at ralfhettinger.de Mon Sep 15 16:37:43 2008 From: ng at ralfhettinger.de (Ralf Hettinger) Date: Mon, 15 Sep 2008 16:37:43 +0200 Subject: [TYPO3-project-4-3] indexed_search for 4.3 In-Reply-To: References:

Message-ID: Hi Steffen, Steffen Kamper schrieb: > i read the bt entry and the reason was too long urls? I'm a bit confused > as the JS-links use same url in onclick="..." I would think, that it should be no problem to have very long URLs and many GET params. _should_ Formally, there exists a W3C recommendation suggesting a maximum length of 255 bytes for an URL [1]. This length is not unlikely to be exceeded, if using indexed_search and pagebrowsing with GET, since all indexed_search params would have to be transmitted as GET vars. Furthermore, I remember that older IEs may have problems when using a back button to a very long URL. I could imagine further problems like content inspections in firewalls blocking pages or indeed 414 server errors (though that admittedly sounds not very likely). Finally, it might be a cosmetic question of having URLs that fit into a browser's address line. > Looking to your example i don't see a reason for a long url, so can you > enlighten me why this is needed? The URLs in pagebrowser (if not submitted by POST, as they are in [2]) would be easily at around 350 chars (without tricky realurl configuration - yes, I think you could tune that, but why having the need to tune if some other solution exists?). Which I personally think is a long URL. Cheers Ralf [1] http://www.ietf.org/rfc/rfc2616.txt => section 3.2.1 General Syntax [2] http://www.ea-aw.de/de/website/website-durchsuchen.html From ingo at typo3.org Mon Sep 15 16:36:29 2008 From: ingo at typo3.org (Ingo Renner) Date: Mon, 15 Sep 2008 09:36:29 -0500 Subject: [TYPO3-project-4-3] Splitting t3lib_div and having autoloader instead of inclusions In-Reply-To: References:

Message-ID: Dmitry Dulepov [typo3] wrote: > Basically it is a map of class<=>filename relations. Pure PHP, no > database involved. BTW: could you please add your ideas how this thing should work to http://bugs.typo3.org/view.php?id=9116 Ingo -- Ingo Renner TYPO3 Core Developer, Release Manager TYPO3 4.2 From info at sk-typo3.de Mon Sep 15 17:11:13 2008 From: info at sk-typo3.de (Steffen Kamper) Date: Mon, 15 Sep 2008 17:11:13 +0200 Subject: [TYPO3-project-4-3] indexed_search for 4.3 In-Reply-To: References:

Message-ID: Hi Ralf, thx for the explanation, i got it now. btw - do you know the problem with different result counts? I have here an example 1st page: results: 60 2nd page: results: 42 3rd page: results: 30 I don't see anything that could cause this error, but it looks very strange to me (and the users) vg Steffen From ng at ralfhettinger.de Mon Sep 15 17:26:42 2008 From: ng at ralfhettinger.de (Ralf Hettinger) Date: Mon, 15 Sep 2008 17:26:42 +0200 Subject: [TYPO3-project-4-3] indexed_search for 4.3 In-Reply-To: References:

Message-ID: Hi Steffen Steffen Kamper schrieb: > btw - do you know the problem with different result counts? > I have here an example > > 1st page: results: 60 > 2nd page: results: 42 > 3rd page: results: 30 > > I don't see anything that could cause this error, but it looks very > strange to me (and the users) This is addressed in [1]. And is all that I really know about - astonishingly, in the installations I have insight to or set up, I did not encounter the problem. As a wild guess, I could imagine that there exist problems with kind of "garbage" (meaning double entries for the same page in IS tables). I normally set up kind of a garbage collection (truncating indexed_search tables and refilling them regularly)... which is far from being elegant, but seemed to be necessary. Shame on me, don't let anybody know... whoops ;) Maybe this idea helps, maybe it's completely misleading. Haven't dig into that. Cheers Ralf [1] http://bugs.typo3.org/view.php?id=5714 From ingo at typo3.org Mon Sep 15 18:48:11 2008 From: ingo at typo3.org (Ingo Renner) Date: Mon, 15 Sep 2008 11:48:11 -0500 Subject: [TYPO3-project-4-3] Splitting t3lib_div and having autoloader instead of inclusions In-Reply-To: References:

Message-ID: Steffen Kamper wrote: > may be we can learn something from Drupal > > http://api.drupal.org/api/group/registry/7 I just had a look at it, and hey, this is cool stuff and provides quite a few new ideas for our autoloader! Ingo -- Ingo Renner TYPO3 Core Developer, Release Manager TYPO3 4.2 From info at sk-typo3.de Mon Sep 15 19:13:53 2008 From: info at sk-typo3.de (Steffen Kamper) Date: Mon, 15 Sep 2008 19:13:53 +0200 Subject: [TYPO3-project-4-3] Splitting t3lib_div and having autoloader instead of inclusions In-Reply-To: References:

Message-ID: Ingo Renner schrieb: > Steffen Kamper wrote: > >> may be we can learn something from Drupal >> >> http://api.drupal.org/api/group/registry/7 > > I just had a look at it, and hey, this is cool stuff and provides quite > a few new ideas for our autoloader! > > Ingo > Hi Ingo, that was my impression too while reading that code ;-) vg Steffen From dmitry at typo3.org Mon Sep 15 21:30:35 2008 From: dmitry at typo3.org (Dmitry Dulepov [typo3]) Date: Mon, 15 Sep 2008 22:30:35 +0300 Subject: [TYPO3-project-4-3] indexed_search for 4.3 In-Reply-To: References:

Message-ID: Hi! Ralf Hettinger wrote: > Could tx_pagebrowse_pi1 be used to do that (render pagebrowser "links" > as submit buttons and putting in hidden input fields)? Absolutely. Page browser uses HTML template. We could simply have its markers in indexed search template file and pass path to this file to the page browser. This also means one single template for indexed search if it uses page browser. All integrated but still separate enough to divide them again if necessary. -- Dmitry Dulepov TYPO3 Core team My TYPO3 book: http://www.packtpub.com/typo3-extension-development/book In the blog: http://typo3bloke.net/post-details/debugging_symlinked_typo3_files_with_komodo_ide_on_mac/ From dmitry at typo3.org Mon Sep 15 21:32:47 2008 From: dmitry at typo3.org (Dmitry Dulepov [typo3]) Date: Mon, 15 Sep 2008 22:32:47 +0300 Subject: [TYPO3-project-4-3] indexed_search for 4.3 In-Reply-To: References:

Message-ID: Hi! Ingo Renner wrote: >> tslib_pibase code can be changed to check if page browser is installed >> and use it. If not installed, skip to old method. > > wouldn't that be a perfect fit for extbase then?! Yes, why not? :) One of my goals is to provide solution for both older versions of TYPO3 (through extension in TER) and newer version (as sysext). I see the advantage of the page browser is that it can be executed as USER or USER_INT (as necessary) and configured very flexibly using TS setup. This is unusual approach but I think it has future. -- Dmitry Dulepov TYPO3 Core team My TYPO3 book: http://www.packtpub.com/typo3-extension-development/book In the blog: http://typo3bloke.net/post-details/debugging_symlinked_typo3_files_with_komodo_ide_on_mac/ From ingo at typo3.org Mon Sep 15 21:42:58 2008 From: ingo at typo3.org (Ingo Renner) Date: Mon, 15 Sep 2008 14:42:58 -0500 Subject: [TYPO3-project-4-3] changing the page cache to use the new caching framework Message-ID: Hi all, now that t3lib_cache is in trunk I had the idea to change the existing page cache to use the new framework. biggest con though: * it would break backwards compatibility pros: * way more flexible * easier to use * (maybe / depending on the chosen cache backend) faster * we would have tags on the cache entries especially the thing with the tags got me some nice ideas: After moving to the new system it would dramatically easier for people to "tag" pages in their extensions. with whatever tags they want and clear those cache entries whenever their extension needs to. This would make the system way more flexible and more dynamic Example: a page showing a list of tt_news records in a list view. tt_news could go and add tags in a way like this: // tt_news_X are the records shown on that page $TSFE->page->addTags('tt_news_list, tt_news_1, tt_news_2, tt_news_3'); Then there could be another plugin X on the same page that also tags the page: $TSFE->page->addTags('tx_X_someTag, tx_X_someOtherTag'); And of course the core would tag the page with stuff we already have like the cHash: $TSFE->page->addTags('core_cHash_######'); Looking up and clearing pages by tag is then quite easy using t3lib_cache... Any comments? Ingo -- Ingo Renner TYPO3 Core Developer, Release Manager TYPO3 4.2 From info at sk-typo3.de Mon Sep 15 22:08:01 2008 From: info at sk-typo3.de (Steffen Kamper) Date: Mon, 15 Sep 2008 22:08:01 +0200 Subject: [TYPO3-project-4-3] indexed_search for 4.3 In-Reply-To: References:

Message-ID: Dmitry Dulepov [typo3] schrieb: > Hi! > > Ralf Hettinger wrote: >> Could tx_pagebrowse_pi1 be used to do that (render pagebrowser "links" >> as submit buttons and putting in hidden input fields)? > > Absolutely. Page browser uses HTML template. We could simply have its > markers in indexed search template file and pass path to this file to > the page browser. This also means one single template for indexed search > if it uses page browser. All integrated but still separate enough to > divide them again if necessary. > Hi Dmitry, i would like to preview your pagebrowser as i work on IS, so i can try to integrate it, is that possible? vg Steffen From ng at ralfhettinger.de Mon Sep 15 22:26:25 2008 From: ng at ralfhettinger.de (Ralf Hettinger) Date: Mon, 15 Sep 2008 22:26:25 +0200 Subject: [TYPO3-project-4-3] indexed_search for 4.3 In-Reply-To: References:

Message-ID: Hi Dmitry. Dmitry Dulepov [typo3] schrieb: >> Could tx_pagebrowse_pi1 be used to do that (render pagebrowser "links" >> as submit buttons and putting in hidden input fields)? > > Absolutely. Perfect! > Page browser uses HTML template. We could simply have its > markers in indexed search template file and pass path to this file to > the page browser. This also means one single template for indexed search > if it uses page browser. All integrated but still separate enough to > divide them again if necessary. Really looking forward to that piece of pagebrowser :) Cheers Ralf From dmitry at typo3.org Tue Sep 16 05:47:19 2008 From: dmitry at typo3.org (Dmitry Dulepov [typo3]) Date: Tue, 16 Sep 2008 06:47:19 +0300 Subject: [TYPO3-project-4-3] changing the page cache to use the new caching framework In-Reply-To: References: Message-ID: Hi! Ingo Renner wrote: > now that t3lib_cache is in trunk I had the idea to change the existing > page cache to use the new framework. > > biggest con though: > * it would break backwards compatibility If you mean it will break extensions that clear cache_* tables, I say "Do it!" :) TCEmain should still clear cache properly after this change. > especially the thing with the tags got me some nice ideas: > > After moving to the new system it would dramatically easier for people > to "tag" pages in their extensions. with whatever tags they want and > clear those cache entries whenever their extension needs to. This would > make the system way more flexible and more dynamic I think we should do it before the next week. Preferably before Thursday as we may need it next week @ Hackontest. Do you have time to do it quick? > Example: > a page showing a list of tt_news records in a list view. tt_news could > go and add tags in a way like this: > > // tt_news_X are the records shown on that page > $TSFE->page->addTags('tt_news_list, tt_news_1, tt_news_2, tt_news_3'); addTags or addCacheTags? > And of course the core would tag the page with stuff we already have > like the cHash: > > $TSFE->page->addTags('core_cHash_######'); Looks like we will need certain rules for tag names. > Looking up and clearing pages by tag is then quite easy using > t3lib_cache... > > Any comments? Sounds wonderful! :) I am very enthusiastic and willing to test it when patch is ready :) -- Dmitry Dulepov TYPO3 Core team My TYPO3 book: http://www.packtpub.com/typo3-extension-development/book In the blog: http://typo3bloke.net/post-details/debugging_symlinked_typo3_files_with_komodo_ide_on_mac/ From franz at fholzinger.com Tue Sep 16 07:52:01 2008 From: franz at fholzinger.com (Franz Holzinger) Date: Tue, 16 Sep 2008 07:52:01 +0200 Subject: [TYPO3-project-4-3] changing the page cache to use the new caching framework In-Reply-To: References: Message-ID: Hello Ingo Renner a ?crit : > > Example: > a page showing a list of tt_news records in a list view. tt_news could > go and add tags in a way like this: > > // tt_news_X are the records shown on that page > $TSFE->page->addTags('tt_news_list, tt_news_1, tt_news_2, tt_news_3'); > > Then there could be another plugin X on the same page that also tags the > page: > > $TSFE->page->addTags('tx_X_someTag, tx_X_someOtherTag'); > page in tslib_fe is an array. IMHO you cannot add a method to an array. var $page=''; // The pagerecord (array) What does this mean to add tags of an extension to a list view? - Franz From oliver at typo3.org Tue Sep 16 12:50:20 2008 From: oliver at typo3.org (Oliver Hader) Date: Tue, 16 Sep 2008 12:50:20 +0200 Subject: [TYPO3-project-4-3] changing the page cache to use the new caching framework In-Reply-To: References: Message-ID: Hi Ingo, Ingo Renner schrieb: > biggest con though: > * it would break backwards compatibility What does that mean exactly? What won't work anymore? Maybe we could have a best-practise suggestion for extension developers to keep the behaviour in their extensions still working... > pros: > * way more flexible > * easier to use > * (maybe / depending on the chosen cache backend) faster > * we would have tags on the cache entries I'd like to see the more general and extensible approach you suggested. olly -- Oliver Hader TYPO3 4.3 Release Manager From fsuter at cobweb.ch Tue Sep 16 13:00:13 2008 From: fsuter at cobweb.ch (Francois Suter) Date: Tue, 16 Sep 2008 13:00:13 +0200 Subject: [TYPO3-project-4-3] Improving the language overlay performance Message-ID: Hi all, I have been working recently on extensions that can display any record from the TYPO3 database. As such I have had a lot to do with the overlay process with 2 main worries: performance and a useful API. The performance is the most important topic. Right now the typical way to get a list of records is to use t3lib_db::exec_SELECTquery() and then call t3lib_page::getRecordOverlay() for each record. The latter queries the database each time, to retrieve the correct overlay. This would seem to be a performance killer on a high-traffic site, especially with USER_INT plug-ins (think search engines, for example). I tried to develop an alternate process, by querying all the relevant overlays in one go, and matching them on the PHP-side (precise matching is necessary because of versioning), thereby reducing the number of calls to the database. I have bundled the code in an extension called "overlays" which I will attach to this mail (if allowed by the list server) or that can be gotten from forge [1]. I made some performance test on a page containing a USER_INT plugin which calls 4 different tables, with a varying number of records each (actually 1, 1, 6 and 25, respectively). I'm not a specialist of benchmarking and I just used Apache bench with the following parameters: ab -n 250 -c 50 [URL of test page] and this clearly hasn't pushed the limits of my local server very far. On several runs I see nearly no performance difference, but maybe I should be pushing my server further and making more runs and averaging the figures. I still wanted to describe all of this to you before going much further, as a kind of sanity check. Do you think that what I'm doing makes sense or am I barking up the wrong tree? I know that I have added some refinements to the whole overlay process (for example, by making sure that the query contains all the necessary fields for performing the overlay), so it may be that this additional processing offsets part of the reduced database calls gains. Basically the "overlays" extension contains a class called tx_overlays which contains methods to be called statically. In terms of API, there's a method called tx_overlay::getAllRecordsForTable() which takes the same arguments as t3lib_db::exec_SELECTquery() and takes care of returning properly overlaid records. It calls on methods like tx_overlays::getLanguageCondition() and tx_overlays::getEnableFieldsCondition() that take care of setting the right SQL clauses for the developer. So it's quite easy to test, because all you have to is include the class.tx_overlays.php class file and call tx_overlay::getAllRecordsForTable() with the same arguments as t3lib_db::exec_SELECTquery() and you will get your fully overlaid recordset. I would be very glad to have your feedback about this. Cheers -- Francois Suter Cobweb Development Sarl - http://www.cobweb.ch [1] https://svn.typo3.org/TYPO3v4/Extensions/overlays/trunk -------------- next part -------------- A non-text attachment was scrubbed... Name: T3X_overlays-0_0_0-z-200809161259.t3x Type: application/octet-stream Size: 6492 bytes Desc: not available Url : http://lists.netfielders.de/pipermail/typo3-project-4-3/attachments/20080916/6fd0eb50/attachment.obj From ingo at typo3.org Tue Sep 16 16:41:50 2008 From: ingo at typo3.org (Ingo Renner) Date: Tue, 16 Sep 2008 09:41:50 -0500 Subject: [TYPO3-project-4-3] changing the page cache to use the new caching framework In-Reply-To: References:

Message-ID: Dmitry Dulepov [typo3] wrote: > Hi! > > Ingo Renner wrote: >> now that t3lib_cache is in trunk I had the idea to change the existing >> page cache to use the new framework. >> >> biggest con though: >> * it would break backwards compatibility > > If you mean it will break extensions that clear cache_* tables, I say > "Do it!" :) TCEmain should still clear cache properly after this change. Well, actually that came to my mind, too. The caching system doesn't have a real API and is not used very often anyways, and direct operations on the cache tables are bad, too. So it's not that a big issue as I first thought... > I think we should do it before the next week. Preferably before Thursday > as we may need it next week @ Hackontest. Do you have time to do it quick? will try =) >> // tt_news_X are the records shown on that page >> $TSFE->page->addTags('tt_news_list, tt_news_1, tt_news_2, tt_news_3'); > > addTags or addCacheTags? whatever, this was just a quick brain dump > >> And of course the core would tag the page with stuff we already have >> like the cHash: >> >> $TSFE->page->addTags('core_cHash_######'); > > Looks like we will need certain rules for tag names. I'd say that extensions should just prepand their tags with tx_EXTKEY_ Ingo -- Ingo Renner TYPO3 Core Developer, Release Manager TYPO3 4.2 From ingo at typo3.org Tue Sep 16 16:43:01 2008 From: ingo at typo3.org (Ingo Renner) Date: Tue, 16 Sep 2008 09:43:01 -0500 Subject: [TYPO3-project-4-3] changing the page cache to use the new caching framework In-Reply-To: References:

Message-ID: Franz Holzinger wrote: >> $TSFE->page->addTags('tx_X_someTag, tx_X_someOtherTag'); >> > page in tslib_fe is an array. IMHO you cannot add a method to an array. it was just a quick brain dump with some pseudo code Ingo -- Ingo Renner TYPO3 Core Developer, Release Manager TYPO3 4.2 From ingo at typo3.org Tue Sep 16 16:44:23 2008 From: ingo at typo3.org (Ingo Renner) Date: Tue, 16 Sep 2008 09:44:23 -0500 Subject: [TYPO3-project-4-3] changing the page cache to use the new caching framework In-Reply-To: References:

Message-ID: Oliver Hader wrote: Hey Olly > Ingo Renner schrieb: >> biggest con though: >> * it would break backwards compatibility > > What does that mean exactly? What won't work anymore? > Maybe we could have a best-practise suggestion for extension developers > to keep the behaviour in their extensions still working... see my response to Dmitry, it's actually not as bad as I first thought. >> pros: >> * way more flexible >> * easier to use >> * (maybe / depending on the chosen cache backend) faster >> * we would have tags on the cache entries > > I'd like to see the more general and extensible approach you suggested. what, where? Ingo -- Ingo Renner TYPO3 Core Developer, Release Manager TYPO3 4.2 From oliver at typo3.org Tue Sep 16 18:22:45 2008 From: oliver at typo3.org (Oliver Hader) Date: Tue, 16 Sep 2008 18:22:45 +0200 Subject: [TYPO3-project-4-3] changing the page cache to use the new caching framework In-Reply-To: References:

Message-ID: Ingo Renner schrieb: > Oliver Hader wrote: >>> pros: >>> * way more flexible >>> * easier to use >>> * (maybe / depending on the chosen cache backend) faster >>> * we would have tags on the cache entries >> >> I'd like to see the more general and extensible approach you suggested. > > what, where? Theeeere! :) My last comment was like a "+1 go ahead, Ingo!" olly -- Oliver Hader TYPO3 4.3 Release Manager From ingo at typo3.org Wed Sep 17 00:26:09 2008 From: ingo at typo3.org (Ingo Renner) Date: Tue, 16 Sep 2008 17:26:09 -0500 Subject: [TYPO3-project-4-3] changing the page cache to use the new caching framework In-Reply-To: References:

Message-ID: Oliver Hader wrote: >> what, where? > > Theeeere! :) > My last comment was like a "+1 go ahead, Ingo!" ahaa ;) -- Ingo Renner TYPO3 Core Developer, Release Manager TYPO3 4.2 From masi-no at spam-typo3.org Wed Sep 17 10:10:20 2008 From: masi-no at spam-typo3.org (Martin Kutschker) Date: Wed, 17 Sep 2008 10:10:20 +0200 Subject: [TYPO3-project-4-3] Improving the language overlay performance In-Reply-To: References: Message-ID: Francois Suter schrieb: > Hi all, > > I have been working recently on extensions that can display any record > from the TYPO3 database. As such I have had a lot to do with the overlay > process with 2 main worries: performance and a useful API. > > The performance is the most important topic. Right now the typical way > to get a list of records is to use t3lib_db::exec_SELECTquery() and then > call t3lib_page::getRecordOverlay() for each record. The latter queries > the database each time, to retrieve the correct overlay. This would seem > to be a performance killer on a high-traffic site, especially with > USER_INT plug-ins (think search engines, for example). > > I tried to develop an alternate process, by querying all the relevant > overlays in one go, and matching them on the PHP-side (precise matching > is necessary because of versioning), thereby reducing the number of > calls to the database. For the live version I think you can do the overlays in go on the DB side with SQL functions. All merge rules can IMHO opinion be expressed as IF (Mysq specific) or CASE (ANSI SQL) expression.s Performance for previews doesn't matter so much, I think that it's more important to have a switch that distincs between live and other WS to make the best performance posssible for the former. If you can improve the latter, fine. Masi From fsuter at cobweb.ch Wed Sep 17 11:03:37 2008 From: fsuter at cobweb.ch (Francois Suter) Date: Wed, 17 Sep 2008 11:03:37 +0200 Subject: [TYPO3-project-4-3] Improving the language overlay performance In-Reply-To: References:

Message-ID: Hi, > For the live version I think you can do the overlays in go on the DB > side with SQL functions. All merge rules can IMHO opinion be expressed > as IF (Mysq specific) or CASE (ANSI SQL) expression.s > > Performance for previews doesn't matter so much, I think that it's more > important to have a switch that distincs between live and other WS to > make the best performance posssible for the former. If you can improve > the latter, fine. I'll keep that in mind when handling workspaces. Currently I'm just trying to improve on language overlay. In this case I'm not sure IF and CASE statements can be enough, since there are quite some TCA parameters than enter the picture when handling translations. Cheers -- Francois Suter Cobweb Development Sarl - http://www.cobweb.ch From masi-no at spam-typo3.org Wed Sep 17 11:51:12 2008 From: masi-no at spam-typo3.org (Martin Kutschker) Date: Wed, 17 Sep 2008 11:51:12 +0200 Subject: [TYPO3-project-4-3] Improving the language overlay performance In-Reply-To: References:

Message-ID: Francois Suter schrieb: > Hi, > >> For the live version I think you can do the overlays in go on the DB >> side with SQL functions. All merge rules can IMHO opinion be expressed >> as IF (Mysq specific) or CASE (ANSI SQL) expression.s >> >> Performance for previews doesn't matter so much, I think that it's more >> important to have a switch that distincs between live and other WS to >> make the best performance posssible for the former. If you can improve >> the latter, fine. > > I'll keep that in mind when handling workspaces. Currently I'm just > trying to improve on language overlay. But this is exactly about language overlay. My point was that you're fussing with overlays on workspaces where performance is not an issue. The only optimizing in my opinion should be done for the live WS. And there you can (my thesis) fetch all records in one go. In this case I'm not sure IF and > CASE statements can be enough, since there are quite some TCA parameters > than enter the picture when handling translations. I thougt about that quite some time ago. I didn't really do it, but AFAIR I didn't find an obstacle at first glance. Masi From masi-no at spam-typo3.org Wed Sep 17 11:52:46 2008 From: masi-no at spam-typo3.org (Martin Kutschker) Date: Wed, 17 Sep 2008 11:52:46 +0200 Subject: [TYPO3-project-4-3] Splitting t3lib_div and having autoloader instead of inclusions In-Reply-To: References:

Message-ID: Benjamin Mack schrieb: > Hey Steffen, > > Steffen Kamper wrote: >> i understand this. Do you have a proposal which subfolder/grouping >> would make sense in your eyes? > I like the Zend Framework structure, unfortunately not as easy for > existing projects as ours. Heretic! Our only guidance in respect to software engineering should be now TYPO3 5.0 ;-) Masi From fsuter at cobweb.ch Wed Sep 17 12:06:32 2008 From: fsuter at cobweb.ch (Francois Suter) Date: Wed, 17 Sep 2008 12:06:32 +0200 Subject: [TYPO3-project-4-3] Improving the language overlay performance In-Reply-To: References:

Message-ID: Hi, > But this is exactly about language overlay. My point was that you're > fussing with overlays on workspaces where performance is not an issue. > The only optimizing in my opinion should be done for the live WS. And > there you can (my thesis) fetch all records in one go. Huh? I'm not handling workspaces... Actually I copied the original code from t3lib_page::getRecordOverlay(), but I didn't keep the part where it does version overlay: $this->versionOL($table,$olrow); > In this case I'm not sure IF and >> CASE statements can be enough, since there are quite some TCA parameters >> than enter the picture when handling translations. I'm not really familiar with these constructs, but I'll take a look. It may be interesting to see which is best performance-wise (doing things MySQL-side or PHP-side). > I thougt about that quite some time ago. I didn't really do it, but > AFAIR I didn't find an obstacle at first glance. Even with parameters such as mergeIfNotBlank? Cheers -- Francois Suter Cobweb Development Sarl - http://www.cobweb.ch From masi-no at spam-typo3.org Wed Sep 17 12:34:14 2008 From: masi-no at spam-typo3.org (Martin Kutschker) Date: Wed, 17 Sep 2008 12:34:14 +0200 Subject: [TYPO3-project-4-3] Improving the language overlay performance In-Reply-To: References:

Message-ID: Francois Suter schrieb: > Hi, > >> But this is exactly about language overlay. My point was that you're >> fussing with overlays on workspaces where performance is not an issue. >> The only optimizing in my opinion should be done for the live WS. And >> there you can (my thesis) fetch all records in one go. > > Huh? I'm not handling workspaces... Actually I copied the original code > from t3lib_page::getRecordOverlay(), but I didn't keep the part where it > does version overlay: I didn't look at your code, but you said something about "exact matches because of version" so I thought you did some extra processing for WS. >> I thougt about that quite some time ago. I didn't really do it, but >> AFAIR I didn't find an obstacle at first glance. > > Even with parameters such as mergeIfNotBlank? Something like that: to = origibal language tt = translation IF(to.col='',tt.col,to.col) AS col But that is Mysql specific. Should be done with CASE in real life for DBAL compliancy. Masi From fsuter at cobweb.ch Wed Sep 17 13:51:38 2008 From: fsuter at cobweb.ch (Francois Suter) Date: Wed, 17 Sep 2008 13:51:38 +0200 Subject: [TYPO3-project-4-3] Improving the language overlay performance In-Reply-To: References:

Message-ID: Hi, > I didn't look at your code, but you said something about "exact matches > because of version" so I thought you did some extra processing for WS. Ah true, yes, forgot about that. It's just a pid check on the language overlay record to make sure that it's gotten from the right page. In t3lib_page::getRecordOverlay, the overlay is gotten with the following query: $res = $GLOBALS['TYPO3_DB']->exec_SELECTquery( '*', $table, 'pid='.intval($row['pid']). ' AND '.$TCA[$table]['ctrl']['languageField'].'='.intval($sys_language_content). ' AND '.$TCA[$table]['ctrl']['transOrigPointerField'].'='.intval($row['uid']). $this->enableFields($table), '', '', '1' ); Notice the condition on the pid, where the pid of the overlay must match the pid of the original. I asked about that in the dev-list and Dmitry answered that this check was necessary because of workspaces. I worked on from that. Thinking back on it, I'm not sure I understand 100% why this is necessary, because it seems to me that checking the transOrigPointerField should be enough... Maybe this test could be dropped and simply replaced by a check on the workspace (overlay should be in workspace 0 as long as we don't care about preview (support for which could be added later and as you said needs not be optimised as much)). Cheers -- Francois Suter Cobweb Development Sarl - http://www.cobweb.ch From masi-no at spam-typo3.org Wed Sep 17 14:07:51 2008 From: masi-no at spam-typo3.org (Martin Kutschker) Date: Wed, 17 Sep 2008 14:07:51 +0200 Subject: [TYPO3-project-4-3] Improving the language overlay performance In-Reply-To: References:

Message-ID: Francois Suter schrieb: > Hi, > >> I didn't look at your code, but you said something about "exact matches >> because of version" so I thought you did some extra processing for WS. > > Ah true, yes, forgot about that. > > It's just a pid check on the language overlay record to make sure that > it's gotten from the right page. In t3lib_page::getRecordOverlay, the > overlay is gotten with the following query: > > $res = $GLOBALS['TYPO3_DB']->exec_SELECTquery( > '*', > $table, > 'pid='.intval($row['pid']). > ' AND > '.$TCA[$table]['ctrl']['languageField'].'='.intval($sys_language_content). > ' AND > '.$TCA[$table]['ctrl']['transOrigPointerField'].'='.intval($row['uid']). > $this->enableFields($table), > '', > '', > '1' > ); > > Notice the condition on the pid, where the pid of the overlay must match > the pid of the original. I asked about that in the dev-list and Dmitry > answered that this check was necessary because of workspaces. I worked > on from that. Thinking back on it, I'm not sure I understand 100% why > this is necessary, because it seems to me that checking the > transOrigPointerField should be enough... Records on WS have always a pid set to -1. > Maybe this test could be > dropped and simply replaced by a check on the workspace (overlay should > be in workspace 0 as long as we don't care about preview (support for > which could be added later and as you said needs not be optimised as > much)) I don't think that the query would be any faster as you must check the pid anyway. Masi From benni at typo3.org Wed Sep 17 16:12:50 2008 From: benni at typo3.org (Benjamin Mack) Date: Wed, 17 Sep 2008 09:12:50 -0500 Subject: [TYPO3-project-4-3] Splitting t3lib_div and having autoloader instead of inclusions In-Reply-To: References:

Message-ID: :-D Martin Kutschker wrote: > Benjamin Mack schrieb: >> Hey Steffen, >> >> Steffen Kamper wrote: >>> i understand this. Do you have a proposal which subfolder/grouping >>> would make sense in your eyes? >> I like the Zend Framework structure, unfortunately not as easy for >> existing projects as ours. > > Heretic! > > Our only guidance in respect to software engineering should be now TYPO3 > 5.0 ;-) > > Masi -- All the best, benni. -SDG- From info at sk-typo3.de Wed Sep 17 21:15:34 2008 From: info at sk-typo3.de (Steffen Kamper) Date: Wed, 17 Sep 2008 21:15:34 +0200 Subject: [TYPO3-project-4-3] Extended Problem Report Message-ID: Hi, may be you read discussion in dev list. What i try to do: Extended Problem Report on user level. What is needed? * http://bugs.typo3.org/view.php?id=9368 (apply this patch) * enter this in userTS: setup.xReporting.enable = 1 * install attached extension * (deinstall cc_dubug if installed) Now go to user settings and enable debug, you will see debug()-output in new window like cc_debug. If you uncheck, you don't see any debug-output :-) Remark: this is a pre-pre-pre-version which works with debug and shall show you the idea behind vg Steffen -------------- next part -------------- A non-text attachment was scrubbed... Name: T3X_extended_problem_reporting.t3x Type: application/octet-stream Size: 13560 bytes Desc: not available Url : http://lists.netfielders.de/pipermail/typo3-project-4-3/attachments/20080917/438ffa03/attachment-0001.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: xReporting.png Type: image/png Size: 8263 bytes Desc: not available Url : http://lists.netfielders.de/pipermail/typo3-project-4-3/attachments/20080917/438ffa03/attachment-0001.png From masi-no at spam-typo3.org Wed Sep 17 22:57:38 2008 From: masi-no at spam-typo3.org (Martin Kutschker) Date: Wed, 17 Sep 2008 22:57:38 +0200 Subject: [TYPO3-project-4-3] changing the page cache to use the new caching framework In-Reply-To: References: Message-ID: Ingo Renner schrieb: > Hi all, > > now that t3lib_cache is in trunk I had the idea to change the existing > page cache to use the new framework. > > biggest con though: > * it would break backwards compatibility > > pros: > * way more flexible > * easier to use > * (maybe / depending on the chosen cache backend) faster > * we would have tags on the cache entries > > especially the thing with the tags got me some nice ideas: > > After moving to the new system it would dramatically easier for people > to "tag" pages in their extensions. with whatever tags they want and > clear those cache entries whenever their extension needs to. This would > make the system way more flexible and more dynamic > > Example: > a page showing a list of tt_news records in a list view. tt_news could > go and add tags in a way like this: > > // tt_news_X are the records shown on that page > $TSFE->page->addTags('tt_news_list, tt_news_1, tt_news_2, tt_news_3'); > > Then there could be another plugin X on the same page that also tags the > page: > > $TSFE->page->addTags('tx_X_someTag, tx_X_someOtherTag'); > > And of course the core would tag the page with stuff we already have > like the cHash: > > $TSFE->page->addTags('core_cHash_######'); > > Looking up and clearing pages by tag is then quite easy using > t3lib_cache... > > > Any comments? Interesting. May an extension/plugin also modify the cache expiry time? Let's say the page starts with the default of 24 but the news plugin for a some site thinks 2 hours is enough then it could change the value on-the-fly (only reduce, never extend). Masi From masi-no at spam-typo3.org Wed Sep 17 23:08:57 2008 From: masi-no at spam-typo3.org (Martin Kutschker) Date: Wed, 17 Sep 2008 23:08:57 +0200 Subject: [TYPO3-project-4-3] Splitting t3lib_div and having autoloader instead of inclusions In-Reply-To: