[TYPO3-core] RFC: #11487: Feature: Open InlineHelp in Ext Js non-modal windows

[Martin Kutschker]

Steffen Kamper schrieb:
> Hi,
> 
> this is a SVN patch request.
> 
> Type: Feature
> 
> Bugtracker references:
> http://bugs.typo3.org/view.php?id=11487
> 
> Branches: trunk
> 
> central point for inlineHelp link rendering is
> t3lib_beFunc::helpTextIcon where the handler is installed.
> There is a preconfigured dimension in
> $GLOBALS['TYPO3_CONF_VARS']['BE']['PopupSizes']['inlineHelp'] =
> array(400, 300)
> which can be overridden in localconf.php.

Do we have CGL for JS? I'd have formatted the JS code a bit differently.

I admit I haven't read the new CGL, but wasn't there a rule to avoid
global and use $GLOBALS instead?

And Steffen I wondered when you showed the code to me why the window
opening is done via via DOM manipulating instead by generating a
different window-open function. As you had to change the code that
generates the links you could have done it easily in this way. This has
the advantage that you can pass JS-window-open parameters for the
open-in-new-window feature.

Something else I would like to change see is the open method of the
IframeWindow class - BTW, how do we protected our ux classes from the
ones in the wild? * - it resembles neither the JS window function nor
the standard ExtJS signature of "option" parameters. How about open(url,
target, options) where "options" is an array. Options takes all options
from Ext.window and JS window open (perhaps with a "javascript"
sub-array to pass stuff that might be different for the JS-window from
the Ext.window (like height and width).

And added benefit would be the possibility for a TYPO3.open function
where target could be '_iframe'. Instead of a JS-window open it would
use the iframe class to open the url.

Masi

* IMHO we shouldn' use ux at all. If it's working outside of TYPO3,
fine. The user shall be grateful that it works and not mind if it's
Ext.ux or Ext.TYPO3.