[TYPO3-core] [TYPO3-mvc] Call for help: Migrate core extensions to extbase

[François Suter]

Hi all,

>> Do we want extension to behave more ajax like? - If so, why don't we use
>> the cardlayout and extdirect for common modules to reduce the data,
>> which is transfered?
>
> Yes, I'm open for good changes in this area, but I'd prefer to do the
> extbase code migration first.

I made a lot of effort recently to try and migrate the BE module of one 
of my extensions (external_import) to Extbase/ExtJS to try and make "by 
the book" according to current TYPO3 best practices. This thread seems a 
very appropriate place to share my experience.

First of all I have to say that it was difficult, because the ExtJS 
documentation is not very helpful and the code found in TYPO3 is nearly 
not documented at all. Nevertheless I decided to keep trying and I was 
quite satisfied to find solutions to all my problems eventually 
(although I'm not finished yet and there are certainly more challenges 
on the horizon). No matter if we're moving towards jQuery in the future, 
I still feel that it was worth collecting that experience.

The nice thing with ExtJS is that - once your familiar with it - you 
have tons of widgets at your disposal and it's really more a matter of 
configuration than programming. Indeed you build up most of your 
interface by defining object and their properties and not really coding 
any JS.

The drawback of this is that you have nearly no control over the 
generated HTML: all the output is produced by ExtJS, except for the 
couple of classes you may have defined or some special elements made 
with XTemplates. This is rather a pain IMO, especially since ExtJS 
generates a lot of markup, making it often hard to style it. It also 
makes the use of Extbase/Fluid pretty pointless. The controller of my 
extension has just 2 actions and the Fluid templates boil down to almost 
nothing but a <div> tag into which ExtJS renders all the stuff. For me, 
that's a shame. I would rather generate a clean markup and augment it 
with JS, than having it generated by some mostly uncontrollable framework.

ExtDirect is pretty nice too, but unfortunately it's implemented rather 
sporadically throughout ExtJS (at least, that was my impression). It's 
also even less documented than the rest of the framework, making it 
pretty hard to use, although very convenient once you get it working: 
it's very pleasant to be able to map JS functions to PHP functions.

I'm glad I made the experience to explore ExtJS for my extension and I'm 
pleased of my results as a personal challenge. However I wouldn't use 
ExtJS if I had to start designing some interface from scratch. There's 
also the worry of upgrading (as we saw during 4.7 development, upgrading 
to ExtJS 4 was far from trivial), and ExtJS is only mildly open source 
in their philosophy. I think we made a good choice when going for ExtJS 
back when we made it. There were far less alternatives back then. And we 
could still manage, especially if we stick to the 3.x branch.

I understand the desire to migrate away from ExtJS and - in part - I 
support it, but we need to be careful about this too. I would say that 
the first aim of this project should be to get rid of Prototype. I would 
not want to see all three JS frameworks loaded side by side (I'm not 
sure that even works at all). Replacing ExtJS stuff with jQuery should 
come only after that. I'm also not sure how much we can really achieve, 
as some ExtJS parts are now quite deeply-ingrained into the Core (I'm 
thinking of the RTE and the page tree, for example).

Cheers

-- 

Francois Suter
Cobweb Development Sarl - http://www.cobweb.ch