[TYPO3-dev] The extbase dilemma

[Peter Niederlag]

Hello,

Am 19.05.2011 01:09, schrieb Björn Steinbrink:
> On 2011.05.18 14:26:14 +0200, Sebastian Kurfürst wrote:
[...]
> But making the common case expensive to save a bit of work for the
> "rare" case seems just wrong.

This is often a tradeoff, make everything work "out-of-the-box" for the 
DAU which in turn makes it way more complicated for the knowingly people 
to get it done properly. I must admit I have seen this some times in 
TYPO3. For example the good old "static templates" provided a way to 
"instantly kickstart" a website and made it way to much work to really 
adopt it to the way the website should have been looking. Unfortuntaly 
an old and meanwhile obsolete example but i must admit I can't recall 
another one right now... well.. htmlarea configuration probably (bunch 
of people end up in demo mode) .

I am afraid there is not always an easy solution to the problem to 
balance between "make it as easy as possible for the DAU" and "make it 
as nice as possible for the powerful developers".

>>> 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).
>
> IIRC it's not that easy, or at least wasn't in T3 4.4, due to some
> implementation details. I don't have any details at hand right now
> though.  I'll see if I quickly dig in there tomorrow (err, today
> *sigh*).  But what you face irrespective of how things are implemented,
> is that you don't control the object lifetime. If some "smart" developer
> gets the idea of caching the objects on his own to avoid reloading them,
> simply resetting the persistence layer will get you some hard to debug
> problems. Thus, at the very least, you'd then want to detect
> "invalid"/outdated objects in some way, but right now, I have no idea as
> to how you could do that.

It would be really cool if you can provide more details as digging into 
it based on your criticism I can confirm there are some weak spots, 
Especially for the race condition on MM-relations (delete and reinsert). 
This defintily has to be fixed IMO and help probably is very welcome. :->

Lifetime methods would be handy and IMO are part of the concept but just 
missing in the implementation still. I have done that once with an 
initializeWorkaround() in my Domain_Model_Object which I trigger 
manually by iterating over the result in the Repository. Since usually 
you don't use more than a handful of objects as results of a query it 
doesn't have any bad effect on performance. In the code I also tried to 
avoid querying for the same object mutiple times, see [1]. 
worksforme[TM]. ;)

>>> 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.
>
> The problem is that you then give up _everything_. You'll have to handle
> the hidden flag, the deletion flag, pids, versioning, etc. all yourself.
> That's ok if I have to do that anyway, but not if half of the time some
> kind of ORM does it for me, and the other half I have to do it myself,
> always having to be on the lookout to exactly match the behaviour of the
> ORM to get consistent behaviour throughout my code.

well, there's an API for delete/hidden/fe_user/start_time/end_time. pid 
is provided in settings. Versioning is tricky all the way through TYPO3 
but there is an API as well!
I agree having to use SQL might not be the best/most nice solution but 
it is not as bad as you put it, as it is needed only in rare cases. An 
the result can be wrapped into the objects again, also I haven't done 
that yet I must admit.

> Compare that to a system like e.g. Propel, where you can consistenly use
> "building blocks" for all your query building tasks, so you write them
> down once, and then simply re-use them. Sure, that system isn't without
> flaws either but it's far from extbase's all-or-nothing.
>
>>> 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]
>
> Just because it's documented doesn't mean that it's not a PITA to deal
> with it ;-)

Well, it was known from the beginning that API changes might happen! I 
rather like breaking changes and getting that extra work than keeping 
old/stupid behaviour just to stay 100% backwards compatible. Toches 
discussion from above on "Dau" vs. "experienced developer".

[...]
> I don't recall that many details, as we tried to port it around the time
> 4.5 was released, and I simply gave up after like 2-3 hours of not
> getting anywhere at all.

2-3 hours for a port of a huge and complex project witha  lot of 
adaptions doesn't seem like a lot of time to me.

[...]

Greets,
Peter


[1]
if ($this->identityMap->hasIdentifier($uid, $this->objectType)) { 
$object=$this->identityMap->getObjectByIdentifier($uid,$this->objectType);
} else {
   $query = $this->createQuery();
   $query->getQuerySettings()->setRespectSysLanguage(FALSE);
   $query->getQuerySettings()->setRespectStoragePage(FALSE);
   $result = $query->matching($query->equals('uid', $uid))->execute();
   $object = NULL;
   if (count($result) > 0) {
// still puzzled on the ArrayAccess and curent() issue
// it this seems to work here
     $object = current($result);
     $object->initializeWorkaround();
     $this->identityMap->registerObject($object, $uid);
   }
}
return $object;

-- 
Peter Niederlag
http://www.niekom.de * TYPO3 & EDV Dienstleistungen *