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

[Dimitri Tarassenko]

Joey,

On 4/12/06, JoH <info at cybercraft.de> wrote:

> > Just because it CAN be done (which I am not yet convinced in, I'll
> > wait for your examples;) it does not necessarily mean it's the most
> > efficient way. TYPO3 COULD in theory have been written in Visual
> > Basic.
>
> Agreed - but the conclusion should be:
> If it's not the most efficient way yet how can we improve it to be the most
> efficient way?

That's where the problem lies - to improve the situation is to change
TS in a way that would allow "control structures" and "presentation
logic" to be easily implemented in the templates. Unfortunately, this
seems to be quite a stretch for TS that was initially created just to
STORE information and not process it. Citing Kasper, "TypoScript
itself does not "do" anything - it just contains information."
(doc_core_ts).

While TS maybe is acceptable for organizing and structuring
information, whenever you try to actually add some _instructions_ and
_rules_ as to how the information should be processed you are stuck
with what Martin just called "TS woodoo" - creating a whole new
LOAD_REGISTER object just to find the number of elements in a set and
insert it someplace else, all those ".if" s and optionSplits, etc. All
in all, this makes TS fundamentally inefficient as a language to
implement what has been called "presentation logic".

> But your conclusion is:
> If it's not the most efficient way we should replace it with something that
> can be under some circumstances more efficient.

And this actually makes sense, doesn't it? ;))

> You still won't have the most efficient way _and_ you would buy the
> advantages by accepting the drawbacks too, since smarty is something new and
> for templating only while TypoScript can be much more and it is the tool
> TYPO3 users are used to.

There is no "most efficient way". Efficiency, as you properly noted
factors in how well the developers can use the tools. I would argue
that Smarty is a tool that's a lot more widespread and a lot easier to
learn than TS.

> BTW: The calendar view you described could be done with CONTENT, CASE, split
> and a condition for switching the starting day based on the L parameter.

I won't torture you with requests to produce the TS that would do it.
I am quite convinced it would look impressively complex and utterly
incomprehensible by anyone with less than 2 years' experience in
TS-templating ;))

> Rotating the view by 90 degrees has nothing to do with TypoScript but with
> properly formatted HTML and CSS.
> If you use floated div containers for each week and the days as well you can
> "rotate" the view just by reducing the width of the week containers.
> A surrounding div container with a class "normal" or "rotated" based on a
> layout field set by the editors would be the trigger.

This is an interesting idea but it won't work. Days have to be cells
in a table because if one Monday has 5 events in it and is stretched
vertically, you need other Mondays to match the height of that quite
eventful one. Now of course you can put a layer of JavaScript that
would correct the problem by evaluating and adjusting heights of the
<div>s, or make all cells the same size and hope the content fits, but
this would just underline how much of a "workaround" and a "tweak"
this solution is.

> But since you seem to be good in finding things that seem(!) to be
> impossible or not very efficient while using TypoScript, why not make a list
> out of it, so that we know what should be improved?

I think this would make any more sense than a list of even numbers.
Instead of building that list I can just say "whatever divides by 2
without fractions". Instead of building a list of things where TS is
inefficient, I can just say "anything that requires more or less
complex data _processing_ in the presentation layer or deals with
iterating over an array of values".

--
Dimitri Tarassenko