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

[Martin Seebach]

  Hi Andy,

Andy Staudacher wrote:

>As I wrote at the end of my mail, the tikipro dev managed to integrate
>phpbb with very few changes. It's possible, given the right tools from
>the CMS.
>  
>
I looked into the way phpBB integrates in tikipro - it simply imports 
the 'frame' of the page (menus, layout etc), and lets the phpBB template 
engine handle that as the page header and footer. Functional, 
definately, yes, but from a technicians point of view, not very pretty.
There are serveral ways to handle these things, spanning from titkipros 
very simple "i'll draw a menu for you" to Typo3s all-embracing 
philosophy. The first is probably well fit for a large number of 
purposes, but when you want to do caching, indexed search etc, it's just 
not a good idea.

>As a sidenote: phpbb easymod automates modifications in phpbb.
>  
>
I'd rather not edit third party sourcecode. It's just a nasty 
workaround, even it it is done automatically.

>I'm asking to keep the tables in sync by calling events whenever they
>get out of sync, exactly in the moment when it happens. So, the moment
>they are out of sync is extremely short. As we talk of data as "language
>choice, address, real name, ...", I can't imagine a scenario this
>instant of loss of data integrity would do much harm. 
>
Just because it can work doesn't make it a good idea. ;) I made phpBB 
run, and quite well, too. I just fear the day something stops working. 
If you try to keep heavily updated tables in sync, maybe even across 
serveral mirroring database servers, something is bound to go wrong. A 
users default language set wrong today, a credit card transaction run 
twice tomorrow ..

>>The 'rewriting' could be very 
>>simple, if the third party application was weel designed. 
>>    
>>
>How simple was it for phpbb? 
>
Non-trivial at best. And there is considerable work put into lz_phpbb.

>And you'll have to do that for every 3rd
>party app and by far not all are well designed. Either you have to
>translate all queries that contain the user/group/map table or you
>translate the queries centralized in the database abstraction layer.
>Some 3rd party apps have modules themself (G2), or modifications (phpbb)
>and if you change the queries manually, you'll break all these
>modules/modifications. There are other problems, it's not as simple as
>you think.
>  
>
I don't think it is simple at all. But I maintain my position that it is 
the best (from a software-design POV) way.
If phpBB had a function hasAccess($user_id, $forum_id, $operation) , I 
could implement my changes in a simple way, and be fairly sure that it'd 
work right. Instead, I browsed through a 1000 lines long file with very 
few comments and figure out what to change.

>But what you surely agree on is that method "B" needs a lot more changes
>to the 3rd party application and my goal is minimal changes, to profit
>from the ongoing support of the 3rd party developers (bugfixes, new
>versions).
>  
>
If the thirdparty application is designed to be used as a module, then 
no, it would need minimal changes. But obviously, yes, if there is a bug 
in ie. the user authentication method, and I have overridden that to use 
Typo3 authentication, then that is a, to me, irrelevant bugfix, as well 
as any plugins regarding to that applcations authentication mechanism 
will be useless. You give some and you take some.. ;)

>Do these features allow the events I was describing? Or can I register a
>function that is called whenever a user updates his account?
>  
>
To get back to your original concern, yes, I am fairly sure that is 
possible. However someone else will have to tell you how.

I better revise my previous statement that phpBB is bad design.. That is 
not true. Given the design-decisions made, with which I disagree, phpBB 
is properly designed - and phpBB is a great board..

Best regards,
Martin Seebach
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.typo3.org/pipermail/typo3-dev/attachments/20040902/45a465e6/attachment.htm>