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

[Alban Cousinié]

Hi Sebastian,

First let me thank you for having taken the time to answer. I imagine you
have a lot to do and deal with extbase and probably your own work, so it is
really nice of you to take even more time with extbase users.

Second, let me state again I have great respect for the work being done on
extbase / Flow3 and the intelligence put inside it : these are definitely
great pieces of software. I have been programming for 10 years and I know
when I see a clean and smart software implementation.

> 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?

Thanks for that feedback. I have now switched the development of my module
back to piBase because I have realized extbase is not ready yet for module
development, and as the project I am working on is a big development with a
tight deadline, I could not afford to spend too much time finding
workarounds with extbase. While switching back to piBase, I could do the
work of the last 15 days with extbase in 3 days. By saying that I don't mean
extbase is bad : I just found it is not ready for module development.
I had waited for extbase to gain maturity before starting developing with it
and thought version 1.3 could be enough. But as there a lot of essential
missing features regarding what we are used to find and use in Typo3 4.0,
the version numbering 1.3 is misleading and raises unanswered expectations.
On my opinion, extbase version numbering would rather be 0.8 beta regarding
my experience with module development. 


> 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.

I think we raise one big question here : should extbase warranty the easyest
backport of module development to flow3 or should it only target educating
Typo3 users with a new development philosophy ?
Educating Typo3 users to a new development philosophy already is a high
goal. Personally I would be already satisfied if extbase would only fulfill
this one.
Warrantying backport to Flow3 is even an higher one and a complicated
mission. Maybe it could be a second time goal as fulfilling educational goal
one is already a lot of work.

Or maybe the choice can be let to the developer : Extbase could propose some
true Typo3 4.0 functionalities in the form of specific objects (classes) and
viewhelpers while stating they will not be available in Typo3 5.0. So the
developers will be properly informed of what can't be backported. Then when
they will want to backport to Typo3 5.0, they could substitute theses
objects and viewhelpers with Typo3 5.0 compatible implementations. This
should not be extremely complicated since objects and viewhelpers act as
wrappers thanks to the object oriented encapsulation.

We could even imagine in Typo3 5.0 an API which would provide these Typo3
4.0 objects and viewhelpers implementations for Typo3 5.0. This would act
like some kind of emulator for these elements on Typo3 5.0 and this would
make the transition even smoother.

For example to be able to exploit the existing TCA style forms for my
records, I had to create a "new" icon and an "edit" icon viewhelpers which
would call the standard Typo3 functions like editOnClick(). This is not very
clean regarding the pure intended Flow 3.0 way, but this would have brought
a huge development speedup for me. Then for the frontend I would have used
standard flow3 forms anyway since these should be ok.

Regarding my recent experience with module development, here are the main
difficulties I have faced :
- enable fields are non functional with extbase backend implementation
- TCA style autogenerated backend forms for records can't be exploited with
extbase. This has been a major source of disappointment for me because
Typo3, while it is usually quite unproductive because it features the most
complex and unordered API I have ever met, has a big strength : it brings a
huge development speedup with its autogenerated forms. Of course the extbase
kickstarter does generate backend forms, but they are very basic, they don't
yet support every kind of elements (and some are even missing / not being
generated). So if you use complex backend forms today (and I had long and
complex forms in my project), you will have to spend a lot of time creating
the widgets to deal with your form. This is a major disadvantage of extbase
over pibase
- The paginate viewhelper is flawed (allows switching forward, but switching
back doesn't work) so it currently needs correcting or reprogramming when
you want to use it
- The tableList viewhelper is nice, but doesn't allow inserting custom
action icons in line of the records so that makes it pretty useless
- the be.buttons.icon viewhelper currently restricts the list of available
icon by filtering the values of the icon field. It seems some existing Typo3
icons can't be displayed.

> > - 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.

This is definitely needed for records managment.

 
> > 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 :-)

This is the raw extbase kickstarter generated directory structure + about 5
self added files. I can send you the extension if you want.

> 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).

I agree these structure is very clean for ordering stuff. However in
practice, when you work with big extensions with many record objects, the
directory structure tends to become huge and you spend a lot of time
scrolling, folding, unfolding your file tree when working on a single type
of record. I believe it would be much more efficient to have 1 folder per
object type with all the elements (domain class, controller, html
templates....) gathered inside it. This way you wouldn't spend your time
scrolling, folding, unfolding when working on an object type. 
This is my major concern with extbase / flow 3.0 and unfortunately the
development is likely already too advanced to change that. Too bad.
 
> 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...

Don't be sorry, you already do a lot! My purpose is rather to give feedback
in order to help improve things than complain ungratefuly for a software I
didn't have to pay for.
 
> 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.

"an overly complicated Query Object Model in the Persistence framework" is
the feeling I had when browsing the source code ! ;-)
 
> 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?

This could be a solution. Actually I don't understand why overloading
function createQuery() using
$query->getQuerySettings()->setRespectEnableFields(FALSE); has no effect on
hidden records, as it should normally disable enable fields filtering for
all queries. It seems something doesn't connect properly here. Is this a bug
or a missing feature ? ;-)

Thanks for all anyway and keep on the good work. Extbase is not flawed, it
just lacks maturity. Still I have expectations to move back on it when
possible. Just this time I couldn't stand the lack of maturity regarding my
specific project delays.

Regards,

Alban Cousinie.