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

[JoH]

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

Where 's the problem with that? As I already told in my other post: Smarty
doesn't separate logic an presentation it combines them completely.
And I really don't see the problem you've got with looping and different
subparts, since this can already be done with current TypoScript.

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

Fine for me. If you integrate something new, that will work together with
TypoScript - even better.
I just wanted to make clear, that a rewrite doesn't have to mean replacing
things, but improving them.

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

You got me completely wrong here. It's not about me, it's about the clients.
How should I explain them, that they will have to pay another few thousand
bucks for coaching just because some of the developers thought that
TypoScript sucks and kicked it completely?

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

Doesn't sound like that at the moment. And this is why I stepped in.

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

Of course - but these changes should be improvements and not replacements.
You could make your bicycle run faster by using the "standard technique" of
a combustion engine.
But this would not make you more successful in selling bicycles, since you
would be selling motorbikes to a completely different target group.
I think the success of TYPO3 is mainly based on the fact that it is a unique
product offering the TYPO3 way of doing things.
We should keep that spirit instead of trying to be the master of all
standards.

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

But TypoScript is not behind the scenes, it's in the frontline.
What I expected from a rewrite or overhaul or whatever you may call it is,
that most of the principles are kept as is, but the way things are coded to
do exactly the same they did before is changed.
A good example is stdWrap that could be improved in many ways. But you
should keep the principle so that something like stdWrap.dataWrap will
produce exactly the same output in 4.x and 5.x by executing the improved
code in 5.x.

IMHO TYPO3 should stick to it's current internal standards and principles,
while the code should be improved regarding consistency and performance. If
there's a need to implement additional stuff, no problem with that.

Joey

-- 
Wenn man keine Ahnung hat: Einfach mal Fresse halten!
(If you have no clues: simply shut your knob sometimes!)
Dieter Nuhr, German comedian
openBC: http://www.cybercraft.de