[TYPO3-core] RFC: fix feature request #568
Michael Stucki
michael at typo3.org
Thu Jan 19 11:59:05 CET 2006
Hi Wolfgang,
thanks for taking care of this!
One general notice:
When proposing such big changes, it would be great to send 1 original patch
and 1 which ignores the whitespace-changes. This would be much easier to
review (use "diff -wu").
> 1) $this->browserInfo is never really used (not in other classes too),
> so I dropped it
> 2) changed every ereg* stuff to the preg equivalent
> 3) changed tests like "if ($test)" to "if (strlen($test))"
> 4) inserted an explicit "return false" where it was missing
> 5) moved the hook in 'whichDevice' to the top of the method as the
> result is not used if the hook is called anyway (see below)
All fine.
> 1) the hook in 'whichDevice' is odd:
> - there's a foreach but after the first found object return is
> called
Right, that's a bug. It should return after the first match, but currently
it doesn't check if the function really matched.
BTW, please add a comment that this hook was requested by Michael Perkhofer
(michael at perkhofer.at) for his "wurfl" extension (though it doesn't use it
yet).
> - the hook management is not created for this class but only
> for this single method (compare with e.g. t3lib_tcemain)
>
> so I suggest the following:
>
> rename
> ['SC_OPTIONS']['t3lib/class.t3lib_matchcondition.php'
['devices_class']
> to
> ['SC_OPTIONS']['t3lib/class.t3lib_matchcondition.php'
['matchConditionclass']
ACK. As it seems the hook is not used yet (but who knows if other extensions
are using it?). I think you can change this, that was my fault.
> this allows me to add another hook in 'browserInfo' (I've written
> a wrapper for phpSniff (LGPL) which is more sophisticated... I'll
> release that soon as an extension)
>
> (.. and I don't like the naming of 'whichDevice_ext', why not simply
> whichDevice as it's in its own class anyway, but ok...)
>
> So I would add a member variable "hookObjectsArr" and register the
> hook class(es) there and use method_exists as it's done in e.g.
> tcemain.
> (the patch does not contain that, I've simply copied the other part
> and renamed it to 'browserinfo_class', so this is really temporary)
OK.
> 2) how do I handle a hook, that can only contain a single reference
> (like above) as there's no meaning in calling two methods after each
> other, what's the general practice (besides not using a 'foreach' where
> 'list' is more logical)?
There are no "rules" for this atm. Maybe someone should propose a little
guideline?
> 3) is $this->browserInfo required somewhere else (I found no reference
> to it in any other "core" class)?
Maybe Kasper knows.
> request:
> please test the attached patch (although I will change it in
> response to your answers)
Will do that later. In any case you patch needs Kaspers OK because it
touches the TS parser which is critical...
Regards, michael
--
Use a newsreader! Check out
http://typo3.org/community/mailing-lists/use-a-news-reader/
More information about the TYPO3-team-core
mailing list