[TYPO3-ect] Struts of a Roadmap

Jan-Hendrik Heuing [DD] jh at digitaldistrict.de
Mon Mar 20 22:05:11 CET 2006


> 1.) Leaving pi_base:
>
> I think our primary milestone should be to give up the dependancy of
> extensions from pi_base and show a working example of an alternative
> solution.

... which is no real Problem I guess.
In my case, the only  thing I am using from pibase are those link-functions, 
but that can easily be changed to some new solution like you proposed.

> To make this step easier we need to provide the services of pi_base in
> a better, easier, more flexible way. With lib_link I did an important
> first step on this way and hope that you follow me and design objects
> replacing other parts of pi_base.

True, looks ok so far. It might be interesting to be able to register some 
common functions in extensions. Like you ask for a link to some specifc view 
of a page, and it takes all needed parameters etc. automaticly. I am just 
heaving the case here, of course that could be done with some extension, but 
having a central way of doing those things cross extensions seems to be a 
good idea.

> 2.) Learning MVC (or OOP in general):
>
> We gain a lot of flexibility and freedom of implementation now. We
> will discover typical patterns how extensions can be organized more
> flexible. But in the end we will find a MVC structure in every
> solution, because every FE plugin has a view by nature.

I guess so. And for the BE Plugins you just stick to MC ;)

> 3.) Implementing the kickstarter to generate MVC:
>
> We should be able to automatically generate an application that does
> the typical insert, select, update, delete stuff for one table.

This has low priority in my case. If the framework is working, first steps 
should be to build some real-live applications with it, to see if it's 
comfortable to use.

> 4.) Scaffolding extends kickstarter:
>
> We should be able to generate skeleton applications classes by
> scaffolding whithin a given extension. That includes to produce a
> skeleton of $TCA settings.
>
> 5.) Definition of PHP5 Interfaces, Abstracts and TYPO3 Services:
>
> Meanwhile we will have found a bunch of usefull patterns. To make the
> interactions and communications of our extensions easy and flexible we
> will need standard interfaces and services. This will come with PHP5
> within TYPO3 5.0.

Maybe we could just stick to PHP5 straight away? If people are using PHP4, 
they can just stick to the old pibase. Those people using the new framework 
are mostly capable of somehow getting PHP5 done.

> This was my proposal for a plan.
>
> It doesn't speak a lot of libraries we need, but we should have the
> necessary libraries done or selected from the existing ones in the end.
>
> It doesn't speak of BE plugins, but the overall plan would go in
> parallel. We should be able to use our libraries in both places.
>
> It doesn't speak of the organization of ECT, but we need to set up
> some structures and need to settle who is responsible for what.
>
>
> With this proposal I give the moderation back to Jan-Hendrick.

HAHA ;)

You are doing a great job, just get on..

JH 





More information about the TYPO3-team-extension-coordination mailing list