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

[Michael Scharkow]

Hi Sven,

you didn't expect me *not* to put my 2c here. Since you asked for knives 
out, I hereby delightfully disagree with you on many points ;)

In short, the more XML, JAVA and Design-by-committee your proposals are 
the more I'll shout "This is soooo 90s! It's too ambitious, convoluted, 
non-agile! The whole goddam web app industry is just moving in the 
opposite direction! TYPO3 *is* a kitchen-sink already.". Be warned...


Sven Wilhelm wrote:

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

>                            UNIFIED STORAGE LAYER
>                                     |
>               -----------------------------------------
>               |         |                |            |
>            RDMBS      XML Files    XML Databases      Webdav

If you mean ORM with the main target being RDMBS I fully agree that we 
need it.

As for XML, I'd be more than happy with a working import/export for 
that. Rails 1.1 has a very nice toXML method which just serializes an 
object into XML. You can image the other way around...

I'm not sure about the rest though: There's a good reason for keeping 
files organised in the filesystem, and I smell a lot of overhead if you 
try to stick all that into a *unified* data model. Maybe two separate 
class families with similar methods for DBlike and file-like stuff is 
enough.

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

> Thinks about the idea when objects are able to store themself to the
> right datasource, maybe all you need is a news container (old style
> called sysfolder) that knows the datasource to use :)
> 
> Example (an object news):
> $news = new News();
> $news->setTitle('Hello World, TYPO3 5.0 will rule');
> $success = $news->save();

We've come to theconclusion already that page->save() *is* the way to 
go, we being Kasper, Elmar and fespecially Jeff Segars who actually 
implemented parts of that already as TCAobject (see ECT group).


> 3. Cleanup or complete redesign of database model
> --------------------------------------------------
> If you have played around with the previous two sections you may have
> changed your view/mind how and what data should be stored in the
> database and which way. Having a unified storage layer, it should be
> quite unimportant in which datasource which object is stored! You can
> store a news item on RDBMS mysql or in XML file news.xml. To be able to
> do that the complete object must have a strict model (not changing every
> minute because another extension wants to add a column).
> As some guys have asked for a normalization of the database schema in
> the past, it is really 
> necessary.

I agree that TCA should be the one and only source for any model 
definitions (whatever format TCA itself is is, please not XML!), we 
should never ever bother with SQL or anything like this again.

As for other data-sources: I think we should concentrate mainly on our 
own necessary stuff in core, and leave the import/export to extensions. 
If we implemented horror like JSR170(?) in the core, we'd not release 
until 2010. Let's just see how the demand for import/export will be and 
not start with this now because most probably "You ain't gonna need it" :)

> 4. Getting a real Metadata System!!!
>  An also required
> key feature for really large content bases is a central categorisation
> of data. It's part of a good metadata system. If you think in objects
> (see section 2) you will see that you have a metadata element to each
> object in each revision (and under normalization an n-m mapping)

As long as the metadata is kept out of the regular models (as you 
propose), I'm fine with that.

> 5. Developing style - The Eclipse Way
> 5.b Splitting the project into manageable parts
> ----------------------------------------------
> Big projects like the Linux Kernel are only manageable because they
> split the whole system into manageable parts, the so called subsystems
> (eg. network, scsi, ide, protocols,...).
> 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.

We have that already. TYPO3 is mainly a smaller core and lots of sysext 
which can be perfectly developed separately. And the core itself is also 
quite modular. So I see no real problems there.

> 6. Having regular code sprints

Hm, I admit that I completely agree with you :(

> 7. Dropping the frontend/backend behavior
> -----------------------------------------
> Having worked with TYPO3 for some years now, it gets a bit difficult to
> break through the barriers of habit and find a solution for those
> editors that complain about the unnecessary abstraction layer they are
> forced to deal with when using the backend to edit their front-end page.

No fucking way! I love the BE/FE separation, and I think it's a very 
good thing to have. I have worked exclusively in the BE for years and it 
works very well, although there are rough edges. The BE/FE user 
separation makes much sense in a lot of situations.

Rather, I agree a) that FE editing should be made much more usable 
(Tapio is AFAIK very well working on that), b) content editing for fe 
users (like submitting news, etc.) should be made much easier. However, 
once we get TCAobjects working, it's a no-brainer to make records 
editable from the BE, FE, or via web services...

> At least imagine that at the moment you see usability from a developers
> point of view. But an editor has another view, he looks task oriented on
> the system!!!

That's a whole different point. You can very well work task-oriented in 
the BE. I agree that we need to revamp the whole content creation 
process to be more userfriendly. BTW, I recommend reading
http://www.veen.com/jeff/archives/000622.html for a very insightful 
summary of what sucks about CMS usability.

> -> 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 :)
>    Starting on such a base should boost developing a new base like a
>    rocket

I have had a look at propel (and the whole symfony project) and found 
that it sucks. Quoting myself from the ECT thread:
"Okay, the ORM they use (propel) is completely unsuited for us because 
we need runtime accessors and not generated code from some XML 
definition. "
I still think we can use our own ORM and Jeff has proven how well this 
looks. We have TCA which defines our models (and contrary to propel it 
does this dynamically) and we can very well use that.

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

(Am I repeating myself?) I don't like TAL because a) it is XML, b) it is 
excessively verbose, c) it's only suited for X(HT)ML output, d) did I 
mention it's XML?

I'd really enjoy templating only if it does not get into my way as I 
write prepared output. Basically, I want only a little logic 
(conditions, loops, etc.) and simple access to my objects and variables. 
And tiny convenience functions for localisation, like LL:add_page 
instead of $this->pi_getLL('add_page',1,0,1)

Huh, that's all already. Sven, I really enjoy debating with you ;)

Cheers,
Michael