[TYPO3-ect] tx_base - tslib_pibase modernized

[Ernesto Baschny [cron IT]]

Elmar HInz wrote: on 02.04.2007 10:28:

>> cool idea. The initial proposal also looks straight and good.
>>
>> But I am not sure if this is a good idea, since this would inspire the
>> continuation of plugins based on "old school" one class does it all. Do
>> we want that? You state it is "for beginners", but couldn't we have some
>> way that even beginners do it "right" from start (using lib/div)?

> I can't give an ultimative answer. 
> 
> Original Nuke and TYPO3 did quickly build up a large community of
> developers of simple but usefull extensions. In both cases extension
> development was not object orientated and the codebase itself was
> spaghetti-code in the eys of professionals. Xoops, the first object
> orientated nuke successor, didn't have the steep startup in this field.

That is exactly what I also thought and was not daring to say.. TYPO3
extreme huge extension repository, even if most of them are "bad" in our
eyes, is one of the main reasons why this is so successful. And I agree
with you that we should keep that "ease" of extending TYPO3 for
beginners, and maybe "base" is really the right way to do that. We then
have to give proper help on "upgrading" to div/lib step by step, so that
our community gets more

> So I believe that an all-in-one class for beginners does make sense, but
> specially caching should be optimized.
> 
>> If we think it is needed to have this "simple" method for plugin
>> development, we still have the issue of caching. Having a parameter
>> "$noHash = FALSE" in the link generation method is not really of much
>> help. I cannot think of any way yet, but there must be something that
>> enforces better usage of USER of USER_INT even for "beginners". So I
> 
> My philosophy is that the complexity of caching with tslib_pibase is the
> main cause of the beginners problems with caching. tx_base provides at
> least 4 simplifications in this field:
> 
> 1.) pi_USER_INT_obj setting becomes obsolete. The most confusing setting. 

We need at least an internal replacement that can be generated by the
kickstarter (with a better name of course). See below...

> 2.) $pi_checkCHash should be set to TRUE by default (I see it's not
> implemented yet.) So in doubt caching works simply by selecting USER.

But won't this break a plugin specifically set to "USER_INT"? I think
having caching on by default will frustrate a beginner who will "ask
google" and find the solution of "set_no_cache()", where auto-magically
everything "works", which is then kept in his extension.

My idea would be to have as little caching as possible (USER_INT by
default) so that the beginner will see results without having to
set_no_cache(). But then provide some "easy" ways to turn the script to
a USER script. Or maybe have more information in the kickstarter near to
 checkbox where the user chooses "USER" or "USER_INT"?

> 3.) The many link functions are replaced with by unly 2: makeLink and
> makeUrl. Both have the same parameter order.

That is cool, true!

> 4.) The names are less cryptic.

I wouldn't use negated boolean named flags like "noHash = FALSE", which
is pretty cryptic. Maybe something more "speaking" as
"isDestinationCached = TRUE".

But this is also where the old "pi_USER_INT_obj" comes into play. The
default for "isDestinationCached" should be FALSE if the user chose to
build an USER_INT plugin in kickstarter and TRUE if he choses an USER
plugin. So I see no way of getting "rid" of that setting, and maybe we
could skip that parameter in the link generating functions, and use the
default depending on the cObj type.

Cheers,
Ernesto