04:30:38 <denisdroid> Xatenev: Thank you. Do you know an wiki page or something like that with an overview of the default 6.2 tables and the purpose of each table
04:31:16 <denisdroid> I'm just thinking about which tables can be truncated when starting a new instance from an old one.
05:47:08 <fger> hi guys, is there no way to detect mobile devices using vhs viewhelpers anymore ?
05:47:16 <fger> i remember having a if.client.isMobile etc.
05:47:36 <fger> or can it now be solved with another "construct" ?
06:42:16 <fger> and 2nd question: I need to switch on a property of a content element in a v:content.render viewhelper
06:42:46 <fger> afaik i can only set render=0 or render=1 to get the record itself or the rendered content ... thus i have to call the v:content.render twice
06:43:41 <fger> is there a possibility, where i can iterate over elements inside the viewhelper, which contain the rendered html AND record-properties ?
06:49:48 <NamelessCoder> fger the client/browser conditions were removed because they can only ever work in an uncached context which makes their usefulness very limited. It's better to just do such conditions in the controller or as TS conditions (which makes the page cache contain another cached version per condition).
06:50:20 <NamelessCoder> and regarding the other one, if "condition" won't solve your use case then v:content.get + v:content.render
06:51:15 <NamelessCoder> strike that: v:content.get + v:content.render is the only way. No conditions for v:content.*
07:07:55 <NamelessCoder> it would only make sense if you disable caching for that page or redefine the top level PAGE object's configuration as USER_INT
07:08:28 <NamelessCoder> if you don't, the code only executes until page is cached. That's why TS conditions create a second cached version for each (combination of) condition
07:08:53 <fger> ok, but how could we "deliver" content-objects per column different for desktop/mobile (we use flags in content-elements) then ?
07:09:09 <fger> not use the v:content.render viewhelper at all ?
07:09:17 <fger> and do it with typoscript-objects ?
07:09:57 <fger> I mean, doesnt fluid(pages) create a different cache-version for i.e. various conditions ?
07:11:22 <NamelessCoder> first: you may be designing an approach that is not ideal. It might make more sense to replace the template paths via a condition than to modify each and every content element being rendered.
07:12:13 <NamelessCoder> second: no, we do not create a different cached version for each condition. Doing so would require us to render the template in order to determine which conditions apply - which completely defeats the purpose and is equal to fully uncached rendering of every request
07:13:15 <fger> ok, get that. to your first statement: We have to decide, WHICH contentelements are rendered on the page desktop/mobile
07:13:42 <fger> so if that cannot be decided inside the fluid-template, we have to go with typoscript-objects then
07:14:07 <fger> because we need to process the properties showMobile=yes/no etc.
07:14:17 <NamelessCoder> unless the elements are huge HTML outputs I suggest doing so with a CSS class on the container (possible in CSC as well as FCC) and eliminating that from display on mobile using your preferred CSS selector.
07:18:42 <NamelessCoder> if you use CSC: add an "if" sub-structure that evaluates the record's field, inside the general element rendering instruction inside a TS condition that applies only on mobile.
07:19:31 <NamelessCoder> if you use FCC: override or overlay the Layout used by content elements inside a TS condition, then make the overridden Layout file contain a condition that only renders anything if your record's field is disabled.
07:31:17 <fger> hmm... we use csc, so fluidpages still uses the content.20 etc. objects to fetch the contentelements ?
07:32:03 <NamelessCoder> yes, v:content.render will render the TS object associated with the CType/list_type of the record (that's all internal in the core)
07:32:19 <fger> ah fine, then we are done quickly i think :)
07:43:06 <fger> seems to work - maybe i should post a snippet to fluidtypo3.org ;)