[TYPO3-dev] Moving the topic of the discussion a little bit -- Based of thread "Change roadmap..."

[Ernesto Baschny [cron IT]]

Hi,

JoH schrieb am 12.04.2006 17:56:

> Very easy: Because 10thousands of people in the world are doing it this way.
> What really annoys me ist the way how some of the developers are going to
> replace things with so called "standards" instead of improving the existing
> things to become "standards" as well.
>
> "TypoScript sucks - it has to be replaced with XML"
> "Hooks are crap - we need a registry"
> "Marker based templating is uncool - we need smarty"
> "Look, Mom, Puma shoes are ugly - all the other kids have got Nikes"

JoH, its not about sucking or not. Besides the 10thousands of TYPO3nic
people, there are also MILLIONS that might be potential new users. Thos
don't know anything about TypoScript, Hooks, Markers, etc.

If someone knows IT, he'll know XML, but not TypoScript.
If someone knows PHP, he will surely know Smarty, but not Subparts+Markers.
If someone knows design patterns, he will probably know what we are
talking about if we say registry and factory, but "hooks" are very TYPO3
specific and need more explanation.

My opinions: TypoScript should stay, it's the thing that makes TYPO3 so
cool and flexible, its the "glue" between all components. We should
surely enhance this (see my proposition on cObjects in ECT) to make it
more robust, more easy to locate errors, etc.

I cannot believe you are really satisfied with all those html-templates
that ship with every extension, are you. Be it tt_news, tt_products,
those templates suck!! The lack of separation of the business logic from
the templating (i.e. loops in PHP and different subparts in the
template) makes this impossible to maintain in a organized way.

So if we adopt Smarty as a templating engine that extensions *can* use,
I would use it right away! Finding a way to integrate Smarty into
TypoScript is still a bit misterious, because cObjects processes one
record at the time, while Smarty could be able to process the whole
"rowset" with one template call. Combining Smarty with stdWrap and other
TS-possibilities seems to me the most perfect combination. You would use
TS for what its best at (stdWrap functions to "process" your data,
existing cObjects to render common output, etc) and Smarty for what its
best at (offer a template to render information).

> Another one is: I learned the TYPO3 way of doing things and invested a lot
> of time and money in it. So I would like to keep as much of it as possible.

That's a bit egoistic to say: "I've spend so much time learning this, so
others should go through that too.." :) If we can make life easier for
new users and developers, why not? This doesn't mean disregard current
users/developers. Besides the "captionSplit.cObject-problem", which we
all agree that was wrong, are there any other things that went wrong in
your upgrade from 3 to the 4 serie?

> And then there is: The current way of doing things with TYPO3 is working
> fine but could be improved in different ways.

I agree, and I think most people agrees on that.

> If you kick the "inflexible marker stuff" and replace it with smarty you
> will lose more than you win, since many people won't be willing to upgrade
> to a version that is ignoring all the stuff they have been learning over the
> years.

I don't think that rendering through TypoScript, which includes the
marker-based approach ("TEMPLATE" cObject) will ever cease to exist.
Nobody is talking about kicking it. The Smarty-way, once someone finds a
way to integrate it, would be the "recommended" way for new extensions.
I think besides cObject output, there is no system extension in 4.0 that
is a FE-plugin.

> The major problem is that most developers seem to forget the people that
> made TYPO3 such a big success.

You seem to forget that the most if not all developers that are working
on TYPO3 are also "power users" and are not just implementing stuff or
thinking about the architecture because they like it this or that way,
but they want to move the project further and make things easier for
developers, users and admins. This sometimes includes changes.

> These people are called "users" and most of them really don't care, if the
> technique behind the scenes is a "standard" or not.

So there shouldn't be a problem if the techniques behind the scenes are
changed?


Cheers,
Ernesto