14:25:05 <danilobuerger> subject should be registered with FALSE, NULL as well since its optional if we want to render the children
14:30:35 <neufeind> "Argument "subject" has already been defined, thus it should not be defined again." - AbstractViewHelper
14:30:41 <dasFelix> Hi folks... Can I do the "Clean Cache" in the install tool also on bash shell? It seems to do more than just clean up typo3temp/* -R, right?
14:31:19 <danilobuerger> neufeind yeah, in render just do it like the IntersetViewHelper does
14:32:03 <danilobuerger> dasFelix the clear cache in install tool does db cleans
14:33:21 <neufeind> but with $subject? fetching it from $this->arguments you mean, and not specifying it as NULL in the render()-parameters?
14:33:51 <dasFelix> danilobuerger - Oh that's what I thought. I just ran into problems while installing/using "fluidcontent_bootstrap". Even *with* uncache AND manually deleted /typo3temp/* -R. I wonder what else should be cleaned
14:33:59 <danilobuerger> leave subject in initialize and remove it as renders argument
14:36:40 <neufeind> new version :-) now with a basic test. runs fine here (well, doesn't do much actually - but anyway)
14:37:09 <danilobuerger> dasFelix take a look at ClearCacheService it shows what the install tool does.. then you could build your own bash for that
14:37:35 <dasFelix> #1203698223: A cache with identifier "cache_hash" has already been registered. was the error during installation in EM - but after it WAS installed. No content elements showed up tough. Everything worked finde _after_ install-tool->cleanup cache
14:38:01 <danilobuerger> yeah 90 % of all problems can be solved that way ;-)
14:38:43 <dasFelix> okay... thx danilobuerger - will do :) and yes, my most used file these days is ENABLE_INSTALL_TOOL :) ^^ *cheerio* :D
14:42:25 <danilobuerger> neufeind looking very good, i will comment in there.. i just noticed we have a utlity for the traversable stuff
14:53:32 <neufeind> in for example IntersectViewHelper we don't have a "name" and there is no "throws exception", just a @return. How do we want it? :-)
14:55:59 <danilobuerger> well i guess since the utility promises to always return an array its fine to do it as the intersectviewhelper does
14:56:42 <neufeind> and no title "Render method" at all?
14:56:55 <neufeind> same would imho go for "Initialize arguments" etc.
14:57:22 <danilobuerger> you can but you dont have to ;-)
14:57:32 <danilobuerger> render and initialize are always the same so ..
15:08:01 <danilobuerger> yeah you still need to squash those commits :-)
15:10:00 <neufeind> How can I squash them and push again or so?
15:14:43 <xaver> git reset --soft HEAD~4 #Number you want to go back
15:16:12 <xaver> git commit --amend -a #if you have other changes you don't want amend -> remove -a and use git add before Last step git push yourremote yourbranch -f
15:43:25 <neufeind> okay, it's down to one commit now
15:50:20 <danilobuerger> neufeind this is looking very good!
15:52:17 <danilobuerger> one more thing about the test: the result should be hard coded and not rely on the function we use ourself in the view helper..
16:28:24 <neufeind> but it's a "core function" imho. Don't you think that is "safe"?
16:29:07 <neufeind> I thought I want to test if the VH works fine - not if array_keys works :-)
16:31:43 <xaver> neufeind: you test it with your viewhelper against a static result. Functions can change, have a bug or something else. Your viewhelper uses already array_keys and it would allow to change the behavior.