[TYPO3-v4] The future of ExtJS 4 in TYPO3 4.7

[Oliver Hader]

Hey Kay,

Am 11.01.12 19:18, schrieb Kay Strobach:
> There some reasons for dropping ExtJS Support (long term):
>  - Making smooth transition to Phoenix possible
>  - Breaking Changes with every release
>  - Time

It's not about totally dropping ExtJS in TYPO3 v4. It's about carefully
thinking if ExtJS is the best framework to solve a particular problem or
project. So, if it's basically about plain DOM handling, events, effects
etc. a slim framework would be suitable best. If it's about working with
widgets like a grid-view or a configuration wizard (like the Form Wizard
that has been introduced with TYPO3 4.6), then ExtJS already meets these
criteria and is quite good.

> Otherwise there are other reasons for taking advantage of ExtJS (3 or 4)
>  - Governmental Projects like BLE, rely on Extjs (3 or 4)
>  - Many Extensions rely on ExtJS (mostly 3)
>  - As far as i understand Vidi it can be a rock solid basement for many
>    modules:
>      - everything what is list based
>      - scheduler task management
>      - listmodule
>      - files / media
>      - trash

Yeah, Vidi "can" be and of course that's the plan. But Vidi should not
be the only reason to replace ExtJS 3 with ExtJS 4 in the TYPO3 v4 Core.
The compatibility to old modules is missing and it does not sound fair
to force everything else to be compatible to ExtJS 4 suddenly since
there might be something like "Vidi".

So with this paragraph and the one above, I agree that there are good
reasons to have ExtJS - which we currently have already with ExtJS 3 and
we wanna keep. But there's no reason to go the next step to ExtJS 4. Do
you agree?

>  - projects like the dashboard rely on extjs 4

Uhm, seems like this project is still hidden on forge.typo3.org?! But
anyway, of course it's possible that a particular module uses ExtJS 4
that is shipped with the extension then (or EXT:extjs4 from TER e.g.).

> For the iframes i can think of a solution like this:
> 
>  - Change API of pagerenderer and add a hook which works as following:
> 
>   t3lib_pagerender::loadJSlib($libKey)
> 
>   then the function just checks if there is a registered object for
>   that library and execute it to add the appropriate libs, this way we
>   could use extjs 3 in frames and 4 in the top frame!
>   (no words about speed ;)

We already have something similar like this in the current master
branch. ExtJS 4 and a compatibility mode rendering "old" modules in
IFRAMEs - however this does not really work out and has side-effects.
And exactly the "does not really work out" and those "side-effects" are
the origin of this very thread...

I played around with the sandboxed mode, to have ExtJS 3 and ExtJS 4
side-by-side in the same document, e.g.

"Ext.whatever" is ExtJS 3
"Ext4.whatever" is then ExtJS 4

But, also this did not really work out and is kind of hacky. It's fine
to add exactly one single ExtJS 4 component/application to an existing
ExtJS 3 infrastructure. But it's not good for mixing ExtJS 3 and ExtJS 4
infrastructures...

> Anyway we should take advantage of the mentioned Sencha support and tell
> them where the Problems are!
> I doubt the would notice if there would be a press notice like:
> 
>  - TYPO3 is dropping ExtJS Support, because of unstable API's

Oh wait. The statement is not about ExtJS being unstable. ExtJS for each
version seems to be stable. But the API has changed a lot from 3.x to
4.0 (sure), and again from 4.0 to 4.1. So for us it's just not possible
to upgrade everything to the most recent ExtJS version and there is no
good way to have both libraries side-by-side.
Latter is of course based on the fact, that we as TYPO3 developers did
not think about the changing API back at the time we introduced the
first ExtJS application to TYPO3.