[Typo3-dev] Event System in the core / Ease the integration of3rd party apps

[Andy Staudacher]

Hi Again,

I'll try to summarize a reply to all your ideas:

The goal is a loose integration. Mostly, both, the CMS and the 3rd party
application, have their own API resulting in a lot of redundant
functionality. Both have their user / session management, templating
engine, caching, database abstraction layer, etc.
What implies a real integration? Choose a "master" API, i.e. the one of
the CMS, and change the 3rd party application to make it use the API of
the CMS for all functionality that is also present in the CMS or at
least for user/session mangement, templating, caching, db.
The result is a fork of the 3rd party application. You'll introduce your
own bugs, etc.
All people running your "fork" depend on your support, the original devs
of the application can't help them. Chances are good that it are only 1
or 2 people who have ported the application to the CMS and that they
won't support it as long/good as the original developers could/would.

What I'm saying is that you need a loose integration because only a
loose integration is maintainable. You can patch/port new versions of
the 3rd party application within minutes and the documentation would be
quite short.

My orignal mail was about an event system or another functionality that
allows calling user defined code in the core (when a user updates his
account) without changing core files.
It was not about all other problems that arise when integrating a 3rd
party application because most of them are not that difficult to solve.

@Templating, Caching:
Don't integrate this part. The 3rd party app may or may not have it's
own templating engine and caching system. G2 saves it's output in
variables. Other applications print everything, easy solved with output
buffering.

@Links in the 3rd party application:
Easy solved in G2, all links are generated by a single class. Other 3rd
party application do it similar I guess.

@Disable user subscription etc.:
Some applications allow this by configuration, some need a 1-line change
in their files.

@LDAP:
How many webhosting offers do you know that offer LDAP? LDAP is for all
those who can afford dedicated hosting / serverhousing etc. So it's too
expensive for the most people and not all 3rd party applications support
LDAP.

@Webdav, xml-rpc soap, Java 170:
Sure, some of these technologies can be used to let 2 applications talk
to each other but that's not the point of my mail. i.e. xml-rpc is about
how to exchange data and accesss an application from another
application. That's an interesting topic and each CMS should support it,
but the event system is about how to hook your functionality right into
the core (or another extension) without changing the core itself.
Your event listener could then use xml-rpc to talk to another
application or it might just use the API of the other application
because the other application is already in a booted state (as it is
when you embed an application in a CMS).
Bottom line: This discussion is not about these technologies, it's a
broad topic.

@Overloading core functions, i.e. add_user(), edit_user():
Yes, overload these functions or enable something like events for these
functions. i.e.
function add_user($bla)
{   /* new */
    call_registered_functions_for_event('eventAddUser', &$bla);
    /* end of new code */
    /* code of add_user function */
    ...
}

@API-only projects:
Keep it real ;)


@Write a paper:
Perhaps I'll do that, but I guess it wouldn't be about "event systems"
in general, but about integration of 3rd party application in CMS. It
would describe what the CMS and what the 3rd party application can do to
ease the integration, what functionality they need to offer etc.
An event system is a good solution for both, the CMS and the
application, that's why I'm talking about it.

Thanks again and sorry for the lengthy emails - Andy