[TYPO3-ect] tcaObjects WAS: MVC Project

[Elmar Hinz]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Michael Scharkow schrieb:
> As Jeff wrote, you can and should always subclass from tcaboj if you
> need additional functionality. Complex queries always need to be added
> manually, so this is not specific to tcaobject.

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.

> The goal is to use them always 100% for querying the *interface* to
> build forms from. As I see it, tcaforms are the instances of TCA-defined
> arrays. If you add you special join to it, chances are you must also
> define a special form input.

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

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.

> No, they are not. You really should look into ActiveRecord. TCAobjects
> are just models: They have a defined structure and some attributes that
> they themselves validate. They are only exposing that data for use in
> the view.
> 

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

> See above. No view attached to an object (although TCA is violating this
> principle by palette definitions, etc.), but you can attach an object to
> a view. If you have a public interface, another class like TCAforms can
> render a form according to the TCAobj definition.
> 
> $user = new TCAobj('fe_users',3);
> $form = new TCAform(&$user);
> $form->render();
> 

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

> 
> TCAobject is *not* relying on anything but TCA, but could of course,
> once it has a stable API, be used to do a lot of fancy stuff.
> 

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?

> Concerning the view: I'm looking forward to a pluggable template API,
> but since TCAobject only exposes data arrays, we're pretty flexible with
> rendering.
> 

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 also hint to the concept of http://www.microformats.org/

model => XML-microformats (i.e. RSS feeds)
      => CSS
      or XSLT: pdf, etc.
      or other programms (server or clients)

Well. All this discribes a flow of transformations in the view rather than the
interfaces to model and controller.


Regards

Elmar









-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFD6GQzO976RNoy/18RAn5aAJ9mqrdzTl8tqdKoRSn606r5RRaugQCfZQgu
4mGJ+kHgJM4iMwMByhpx6sI=
=Cx70
-----END PGP SIGNATURE-----