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

[Christian Kuhn]

Hey devs,

thanks for positive feedback and lots of happy discussions during events.

A first summary on what is happening.

I was added to the extbase team to fill a communication gap between core 
and extbase. We already have some issues on our radar and would love to 
see more people working on that. See below for more information.


On 04/04/2012 09:40 PM, Christian Kuhn wrote:
> - Extract core models from specific extensions and stuff them to extbase
> (like fe_users) to be available for everyone. belog already creates some
> models, sys_log for example.
 >
> - With the three extensions a bunch of BE view helpers was created. They
> should be reviewed if they are generally useful, unit tests should be
> added and then tests and view helpers merged to fluid. Further general
> BE view helpers will be needed, too.

Oliver Hader wants to pick up some widget tasks and uploader handling. 
Next to other things, I'll try to spend some time on generic models in 
extbase and some viewhelpers for BE in fluid.


> - We need a quicker process to raise git submodule pointers if we tie
> extbase / fluid with core.

This is solved, we can raise pointers on demand.


> - Make extbase + fluid required extensions and take care that dummy and
> other packages still run without problems.

Done in master (6.0).


> - Actually migrate more extensions (we should create a list which
> extensions are feasible and who takes care of it)

There was some great feedback, status:
- ext:belog is merged now
- ext:viewpage is pending and might be merged soon
- ext:beuser: Felix Kopp and Patrick Broens committed to a new User 
Admin tool based on extbase
- Georg Ringer wants to work on a ext:scheduler migration
- Tobias Liebig gave a generic 'count me in' answer, we'll see if we can 
inspire him for one or the other task :)
- Alexander Schnitzler started working on a ext:fe_login port.
- YOU doing ext:xy ??


> - With belog I created a pretty ugly hack to bootstrap extbase as a
> module-function-ext plugin (the log view below web->info). It would be
> great if extbase could handle this alone, at best by migrating 'info'
> (same for other modules) itself to extbase, while still maintaining a
> compatible path for 'old' modules.

This is currently more a sub-task, we'll see if we can handle it. There 
are more of them, for example using extbase as click-menu.


> - We already stumbled upon some issues that should be changed / fixed /
> finished in extbase and more will evolve. Some of them must and some
> should be solved.

It seems we have at least two bigger issues here:
- extbase needs TS, especially for settings like persistence mappings. 
So, for example with ext:belog, you must have a FE page and a TS Root 
template to run the BE module. This is ugly for various reasons. With 
Felix Oertel we are currently thinking of a new layer. It is still open 
if we take the FLOW3 yaml parser for that and if and when we find time 
to implement something. Help welcome, contact us :)
- It was decided that the core can use extbase things internally, now 
that it is required extension. We have some cases where this is already 
in use. For example FAL used to have an own signal-slot dispatcher, 
while extbase also had one. We decided to use the extbase signal-slot 
handling in FAL, and not to extract things like that from extbase and 
merge it at a different location in the core again (for example in 
t3lib/). This is good since it eases the backport path between extbase 
components and FLOW3, but it also gives us headaches (beside performance 
issues) in the TYPO3 bootstrap regarding early instantiating of the 
ObjectManager. We did not find the perfect solution yet, but it seems 
that we will work on the TYPO3 bootstrap anyway to disentangle some 
things. I'll spend some of my time on this within the next weeks, maybe 
we will even have a sprint on the bootstrap topic, after that we will 
see how we can handle the ObjectManager issue. Help welcome again.


So long
Christian