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

[Dimitri Tarassenko]

Sven,

On 4/10/06, Sven Wilhelm <wilhelm at modulebox.com> wrote:

> 1. Storage Layer (which is not really existing)

Like the idea, however it should be approached very carefully - we
need to reevaluate what types of data should be stored in what form
(at least BY DEFAULT). And sometimes the most efficient way is not the
obvious one - I always thought that having cache as files in the
filesystem would have been faster, until recent real-life tests with
4.0 shown otherwise.

> 2. Changing the view on data (Strict usage of objects)
> -------------------------------------------------------

Absolutely. I feel strong Java influence in what you are proposing,
but it's way better than the current data layer.

> 3. Cleanup or complete redesign of database model

+1.

> 4. Getting a real Metadata System!!!

If I understand you correctly this is about replacing the $TCA monster
with something a bit more standard. I'm with you on that ;).

> 5. Developing style - The Eclipse Way
> --------------------------------------
> In several postings we could read that it's necessary to release to not
> unsettle the users/companies earning money with typo3 projects. Other
> guys answered that the philosophy of "it's ready when it's ready" it a
> more safer and better way. At least everybody agrees to like the middle
> way, secure release on a regular base.
>
> To solve the problems that are standing in the way of making this happen
> some say we need more developers, others say don't burn out the existing
> developers or throw down the barrier for new developers. And both
> parties are right :)

The key to solving this conflict is _predictability_. For example,
most people know that kernels with odd numbers are for risk-takers and
evens are for production. As long as you provide clear distinction in
which releases are developer and which ones are production, you can
keep the fish and eat it at the same time ;))

> 5.b Splitting the project into manageable parts
[...]
> For each subsystem there are maintainers that are specialized. They
> concentrate on one part of the Kernel. With enough developers, this
> could also be a way for TYPO3? See also next section.

I think this process has started already, maybe it needs to be more
formalised though.

> 7. Dropping the frontend/backend behavior

Well, I happen to think BE actually is pretty good because it gives
them the capability to think of their website structure in a more
abstract way. I've noticed that a lot of users are editing their
website in Web/View mode - i.e. they are navigating using the page
tree and then click on the pencil icons to edit content.

Having a backend where you have complete control over styles
(independent from FE) also lets you do more in terms of AJAX, etc. As
a matter of fact, I think one of the worst things about *Nukes was
that they had no BE and content management interfaces are implemented
within the FE template.

> --------------------------------------------------------------------
> -> A good base for a more advanced database abstraction layer could be
>    Propel. This project builds a Object Relation Mapper (reminding parts
>    of section 2 :)

If you had any experience with it, how is it in terms of overhead when
working with DB? Compared to ADOdb?

> -> There are several good template systems out there. Using one of this
>    existing projects will save a lot of development time. One of these
>    really perfect systems is ZOPE TAL (Template Attribute Language) that
>    is also implemented in a PHP Version.

I think we should _seriously_ consider Smarty for templating. It seems
that Smarty becomes more and more mainstream templating solution for
PHP. Right now I am doing most of extension templating in Smarty,
after I wrote a couple of Smarty functions that provide access to
GIFBUILDER and other T3 Core goodies. It really works a lot better
than TS (better process/presentation layer separation) and it's
faster, too.

> A last word to the current hype of TYPO3!
> ------------------------------------------
> very, very DANGEROUS how TYPO3 hypes at the moment, as a system itself
> and the personality cult you hear very often in TYPO3 UGs!!! In such a
[...]

<Dimitri's babbling> ;))

You know, after being around here for a couple of years, I think that
the whole "marketing" concept that TYPO3 follows right now is
misguided at best. They take a very complex product (remember the
all-time favorite metaphor of TYPO3 being a Boeing 747?) and try to
market it to the end-customers, spending bunch of time on some
"branding" and "re-branding" efforts where there is NO brand and
shouldn't be. If TYPO3 is a Boeing, sell it to AIRLINES, goddam it,
not the passengers! ;)))

TYPO3's real customer is a _developer_. And as a developer (at least
in the past) I can tell you that stuff like
http://typo3.org/news-single-view/?tx_newsimporter_pi1%5BshowItem%5D=0&cHash=e4a40a11a9#csingle
is absolutely meaningless to the process of making a decision whether
to use TYPO3 or something else. Although I have to admit, copywriting
and style is on par with Microsoft's (you can read this as a comliment
or vice versa, as you like;). I don't know. Maybe in Europe people who
need a website come to developers and ask for their websites to be
done in TYPO3.

And right now, TYPO3 happens to be one of the hardest frameworks to
learn for a developer that I know of. I can tell it both from my own
experience and from the process I am going through right now when I
help 2 other developers to get up to speed on how TYPO3 works.

So, you may have greatest press releases and CI packages ever, but if
the developer documentation sucks and there IS a "hype" going on, you
WILL get the cases when people choose TYPO3 for wrong reasons (hype)
and statistically, wrong tools is the one BIGGEST reason why IT
projects fail. "OOPS! And you guys told me TYPO3 could do this and
that and draw a kitchen sink on my PDP-11!"

</babbling>

Enough said, way to go Sven. I'm going to join that new newsgroup and
see what happens there, I'm interested.

--
Dimitri Tarassenko