[TYPO3-ect] tcaObjects WAS: MVC Project

[Michael Scharkow]

Elmar Hinz wrote:

> Is it the right way to subclass tcaObj if it is specially connected with one
> table? Inheritance isn't allways the most flexible solution. There is the
> alternative pattern of components, typically used to compose the view. I wounder
> if this pattern wouldn't match also for tcaObj-components to "compose" the full
> model.

I'm not a software engineering wizard, but typically subclassing will 
suffice for most jobs. Components are really well suited if you expect 
heavy reuse of them in multiple contexts (which I don't really). If we 
implement TCA completely there won't be the need for extra components 
for around 90% of all cases. Plus, we can still implement generic hooks 
for special 'column' types (I guess this what you have in mind), as well 
as a factory pattern for instanciation of a tcaobj or a subclass like 
pageobj which certainly needs some special treatment.

> I partly understand you here. tcaObj query the DB!? Which interface should they
> query? DB-Layer? What is "you special join"?

Didn't *you* talk about special joins? TCAobj is nothing but an 
object-relational mapper that works on top of DBAL. Like in 
ActiveRecord, you have several find() convenience methods as well as the 
possibility to find_by_sql(), and the results are stored in an object 
instead of a simple array.

> You seldom need complex joins in edit forms, because the task of an edit form
> is, to fill the tables, usually one by one. Complex joins are regularly needed
> in search forms.

I guess you mean search engines, as the form itself is pretty empty in 
google ;)

> O.K. Then I need to alter my comprehension of their task. Palette definitions,
> etc. were misleading me here.

Current TCA is more than a model definition, and I'm not sure if we 
should change that or live with it and deviate a little from the pure 
MVC. I haven't had a look into palettes and stuff for some time, but it 
is definitely a neat way to further customize the views for forms, kind 
of configurable scaffolding that is...

> So we postulate two different things. tcaObj as model and tcaForms as view?
> Both usable in FE and BE on the long run?

That is my opinion, yes. Plus a lot of other fancy stuff, like a generic 
controller for use in BE and FE (in FE as a successor to pi_base) 
because I am *so* tired of writing excessive switch statements for 
controllers.

> Let me drop in a question in this context. Assume the data wouldn't come from
> the DB but from another source like an RSS feed. Could and should it be handeld
> by tcaObj?

Not out of the box, but if the differences aren't too big, you could 
possibly subclass tcaobj and override the load() and save() functions, 
etc. Since any object is basically only configured with TCA and then 
filled with *some* data array (coming from the DB, or user input, or 
...), this should not be too hard.

> Here I hint to the discssion of Ernesto, Kaspar and me "Improvement of the
> template engine" upon new standards in plugin development.
> 
> Proposal Ernesto: model => cObj => TS ( => Smarty)
> 
> Proposal Kasper/Elmar: model => (a standard format: i.e.
> tcaObj/microformats/Arrays) => pluggable FE Services

I would consider your and Kasper's way as more flexible, but of course, 
you could still us cObj as *one* rendering method, if you like, with 
automatic inclusion of appropriate TS configuration.

Cheers,
Michael