[TYPO3-mvc] hidden records seem to be unworkable with extbase + is extbase bloated ?

[Sebastian Kurfürst]

Hey Alban,

you are right, Extbase definitely lacks in handling hidden records
correctly. The reason for this is, that we originally started Extbase
for Frontend usage; and in this context it (IMHO) makes perfect sense to
have all access restrictions transparently in place.
You are of course right that for the backend, things are a lot
different. Somewhen in the next time we need to backport the MVC changes
done to FLOW3, and then we have a flexible property mapper in place
which we can configure nicely -- and also configure if hidden records
should be fetched or not. I can imagine this does not sound too nice for
you now, so I guess you need some "hacky" solution right now. Anybody
who has an idea?

> - First I don't understand why the enable fields are not basically handled
> in base Domains classes since they are the earth of Typo3 database records
> mecanism. But I can hear there can be types of records no stored in the
> database which do not require any enable fields. So why not, but also why
> not have them inherited by default (this would add a lot of productivity)
> and not use them if you don't need them ...
Well, in the context of FLOW3 there is no such notion of "EnableFields".
That's why we did not implement them in the domain models in the first
place, but rather handle them "on top".

Still, it could make sense to add them, because it is pragmatic. However
people need to know that if they use them, their stuff will not be
easily portable to FLOW3.

> - Second I beleive Extbase / Flow3 should return any records found and let
> the programmer filter them according to his needs.
FLOW3 does that, but see above for the reasons why extbase does not do
it (yet). But I agree with you, that should be changeable.

> But extbase, while it allows to create simple Object classes requires in the
> same time so many classes and directories where the code is split that it
> becomes very complex to deal with all those files and inheritance. In my
> extension I have 6 Domains, 3 Modules, 1 plugin. And I have 194 files to
> deal with that : 194 FILES !!!
I'd be curious about the directory structure :-)

But generally you are right: the trend is to have *more files* which are
*much smaller*, so the structure is much more "spread out", but also
better understandable (hopefully). I think in some areas we are doing a
pretty good job in this regard, f.e. in the MVC component, but in
others, we do not (Persistence).

Generally our goal was to have a "strict" structure, so everything will
be neatly organized and it's clear where to look when having a
particular problem.

>  And extbase itself is made of 362 files while
> not being able to generate a TCA style backend form and only providing a
> fe_user, fe_group and configurationManager objects to deal with Typo3 !
That'd be definitely a nice feature; though right now this is done
automatically for you by the extension_builder.

I'm sorry for your negative feelings about Extbase, we know that there
is still a lot to improve; and we welcome every contribution we can get.
Still, the "main task" of Bastian and myself is currently working on
TYPO3 Phoenix, that's why Extbase development is currently pretty slow...

Our focus right now is on getting a first beta version of FLOW3 out; and
there we tried to learn from some errors we made, and unfortunately some
of these mistakes (such as an overly complicated Query Object Model in
the Persistence framework) are part of Extbase.

So much for the status quo, I hope we stay in touch, and maybe somebody
else has some neat ideas how to solve this particular problem :-) Maybe
a TypoScript setting to globally change whether an extension will
transparently handle enableFields or not?

Greets,
Sebastian