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

[Steffen Kamper]

Hi Masi,

Martin Kutschker schrieb:
> 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?
>

i didn't made cleanup. The global $BACK_PATH simply was forgotten as it 
was used before - wonder why it worked. So cleanup here (GLOBALS instead 
of global) will follow after it.


> 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.
>

it's the source i showed to you ;) Here it is a register process, where 
popup types are passed with their dimensions. There is no DOM 
manipulation, only event catching, there a new window is created.
Only new is the button to open it in new window, and sure, the dimension 
can be used as well.

> 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).
> 

the class is different to an object which is used in a context. So the 
few params are passed in the register method. If you have a better idea, 
try it. As this is the "first" ux for core we may find common solutions 
later anyway.

> 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.
>

you can register any link with this class. Here selector is class, but 
you can choose any available selector like target, rel etc.

> 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.

We didn't defined that yet. We can create an own namespace, like t3ux or 
something simular.

vg Steffen