[FLOW3-general] Best Practice for a plugin-based app in flow3

[Robert Lemke]

Hi Christian,

On 29.03.2012, at 09:30, Christian Peters wrote:

> *How to write a plugin based system in flow3?*
> 
> Inutitively I would think of every plugin as a package, but I'm not really
> sure how to manage e.g. the view, for plugin based templates? Is there a
> three-level inheritance like in symphony's view?
> 
> In general, is there a recommended way of doing this or are there any
> already existing examples of an application that has plugins, that are
> designed for this application (and not just shareable packages)?

I think that Fluid and FLOW3 are very well prepared for plugin scenarios –
especially because we need that functionality a lot in the CMS part.

What I did in a project recently is this:

- one package provides the master functionality other packages can plug into
- coupling is loose: neither package refers to the other directly but instead uses
the reflection service (getAllImplementationClassNamesForInterface()) for registering
suitable plugin controllers (which are just ActionControllers)
- the master package can provide a base action controller for sharing functionality

A single page is rendered by the plugin controller which has its own template.
That template is based on a layout provided by the master package. That way the
plugin renders only the area it is responsible for and the surrounding content is
rendered by the master package. 

This is a very simple scenario and we can easily imagine more complex ones.
In Phoenix we're approaching this a bit differently (more flexible).

But in general, FLOW3 itself does not provide some plugin management (yet).
After we collected enough good practices, we can consider providing such
support, but personally I think that its too early for that yet.

> *
> *
> *Are there any plans to update the documentation?*
> *
> *
> I've asked this question a lot and got answers like "it's an ongoing
> process" and "yes, documentation will be finalised". I really like your
> efforts and work and I know you may have pressure to proceed with other
> important stuff, but: Are there plans in terms of "There is a task in
> sprint y that will take place at xx-xx-xx" for some key documents (session
> handling, deployment, errors and exceptions, testing framework,
> architectual overview …)?


yes, yes, yes.

There were three big issues which potentially kept people from using FLOW3:

 1) production speed (rendering time)
 2) development speed (compiling time)
 3) documentation

we have pretty much solved 1) and 2) in FLOW3 1.1 and I'm pretty much aware
of that we need to tackle 3) as soon as possible.

Personally I feel a lot under pressure as we also need to work on Phoenix and
a lot of other side aspects. So, I appreciate any help for solving this.

What would be especially helpful at this point:

 - someone who takes care of the FLOW3 website and produces (or lets produce) a lot
   more information about the core features, where to find help, how to contribute etc.
 - we also need a good tutorial / screen cast section which allows the community to easily
   contribute tutorials and screen casts
 - someone who looks at the documentation as a whole with a skilled eye and coordinates
   further steps

Anyway, documentation is the next top feature on our todo list.

Cheers,
Robert

-- 
Robert Lemke
Lead Developer TYPO3 Phoenix and FLOW3
Co-Founder TYPO3 Association

Blog: robertlemke.de/blog
Get involved: typo3.org – flow3.org