[TYPO3-dev] The extbase dilemma

[Sebastian Kurfürst]

Hey Daniel,

first off, thank you very much for your detailed posting; I think that
this can really start a fruitful discussion. First off, I'm gonna
comment some concrete points in your email, and then I try to get to
more general things at the end of the email.

> The first thing we noticed: extbase does not scale. At all. And no, it's not
> our coding style, it's just a framework that burns CPU, and Fluid puts oil
> onto the fire.
I'd be curious to see concrete use cases on where Fluid is slow. Best
would be a simple controller which contains demo data; and then all
required templates/layout/partials for the rendering.
We have some ideas how Fluid can be compiled to native PHP code, and
such real-world tests would be very helpful for us to benchmark Fluid.

One more question with regards to Performance: Do you use the TYPO3
caching mechanisms, or is this not possible in your application domain?

> [Persistence]
You're right that we built our own persistence layer, but the most
prominent reason is that we wanted integration into TYPO3 practices;
meaning we needed support for stuff like comma-separated lists in
relations, and other weird things.
Today, I am not able to say if a pre-made persistence layer would have
bought us less problems -- but it could certainly be. I am with you that
the Persistence Layer is maybe the most complex part of Extbase; and
because of that, nobody dares to touch it (including me, I have to say)...

> What does this mean for extbase? First of all: no transactions, no locks,
> and therefore - race conditions everywhere.
You're right; and that's the same for TYPO3 v4 -- no use of transactions
there as well (correct me if I'm wrong); so while I agree that
transactions would be nice, we have lived in TYPO3 v4 for ages without them.

> In order to find out which data has to be persisted, extbase goes through
> _all_ objects used in the current request, even if they were just used for
> reading. It does so, because there is no dirty-flag.
How does a dirty-flag help? IMHO it is not possible to get notified when
a property of an object changes (in PHP); so one does not know if an
object has changed. As soon as any method on an object has been called,
we cannot know anymore if the internal state has changed.
It'd be cool to get some notifications as soon as object properties
changed, but apart from a custom PHP extension[1] I once wrote I think
it is not possible with plain PHP -- although I'd love to be proven wrong ;)

> This check is extremely
> expensive and gets even more expensive if there are many extbase-plugins on
> a page, because then _all_ objects are checked again for _every_ plugin!
Good point, that's a bug which needs to be fixed. The Persistence Layer
needs to be reset after each plugin run, or alternatively detect if it
is run on the last plugin on the page. Could you open a bug report for
this, or even provide a patch? I think that's pretty easy to solve (at
least the first solution).

> access whatever database you want in any way you like. extbase isolates you
> from the underlying database, which is ok for a full-blown ORM that allows
> for almost any operation that you could think of in SQL.
You can always directly write SQL inside Repositories if Extbase is slow
or does not support a particular use-case. Extbase does not force you to
use the persistence layer, and in some cases (like building a tag
cloud), a handmade SQL statement will be the better choice I think.

> TYPO3 4.5.2, is so incompatible to last years release that it requires a
> major rewrite of our codebase! Hooray.
I'd be curious on what changes are there; as we tried to document all
breaking changes on [2]
What other difficulties did you experience when using the publicly
exposed API?

Further, some general remarks about extbase:

The Purpose of Extbase
===============
For me, the most prominent purpose of Extbase is to let people learn
Domain-Driven Design and the associated FLOW3 paradigms in a known
environment, and to gain real-world experiences with these techniques. I
agree with you that it depends very much on your project if it makes
sense to upgrade it to FLOW3 or not; or if a rewrite makes more sense.

Furthermore, I'd like to give some proposals on how we could improve,
such that issues like the above will be less likely.

First off, I think it makes sense to create a dedicated page (in the
wiki for example), stating which parts of Extbase are Stable, which are
Beta, and which are Alpha Quality; so it could be easier for users to
decide when to use Extbase and when not.
Second, we should formulate the *goals of extbase* explicitely. For my,
I'd say the goal is: *to enable the mental transition to concepts of
FLOW3*, but that should be discussed.

The Future of Extbase
==============
We're currently in the progress of moving to a community-oriented
development style, and we'd like everybody interested in Extbase to join
development. Today it became clear to me that we need to make our
decisions (especially Bastian's and mine) more transparent (thanks Felix
for this nice discussion!); so I'd suggest that we start a regular
meeting every one or two weeks; discussing the current status, how to
proceed etc. This meeting will be open for everybody, and we'll set up a
date in the next weeks (follow the typo3v4mvc mailing list for further
details on that).
I think it is a great challenge to involve more people in the
development of Extbase, and I really hope we are successful on this.
Btw: We have made a longer posting on the future on Extbase recently,
see [3]. This one might be interesting as well.

So, as said, together with all of you who are interested we'd like to
work on the issues of Extbase and coordinate working together, and it'd
be awesome if you could be at the first public team meeting if you want
to contribute.


Greets,
Sebastian
--
Extbase co-leader

[1] https://github.com/skurfuerst/objectmonitor
[2] http://forge.typo3.org/projects/typo3v4-mvc/wiki/Breaking_Changes
[3]
http://lists.typo3.org/pipermail/typo3-project-typo3v4mvc/2011-May/009394.html