[Neos] FYI: Summary of todays "Technical Meeting"

Bastian Waidelich bastian at typo3.org
Tue Apr 29 16:02:21 CEST 2014

Hi all,

as usual, a short summary of our bi-weekly discussion on technical 
issues related to Neos. You can also see (a better readable) version on 

Participants: Adrian Föder, Markus Goldbeck, Christian Müller, Marc 
Neuhaus, Bastian Waidelich

= Todos/Updates from the previous meetings =

* Dynamic configuration of selector elements (dropdowns in Neos inspector):
     -> No updates, see http://forum.typo3.org/index.php/t/203184/

* Improved handling for TargetNotFound exceptions:
     -> Bastian pushed a basic implementation, reviews wanted: 

* Optimize database step in setup:
     -> No updates, see http://forum.typo3.org/index.php/t/203184/

* Case insensitive search in TYPO3CR:
     -> No updates, see http://forum.typo3.org/index.php/t/203184/

= Summary of the last meeting (29th April 2014) =

* "Rules" workflow concept: We skipped that one because Søren wasn't there

==  How to make editing more configurable ==

* Initiator(s): Christian Müller

=== Background: ===

Currently it’s not possible to extend (aloha) editing options as 
flexible as it should be.

=== Possible discussions: ===

* Does it make sense to evaluate/use another RTE editor?
* Can we extend aloha/its integration so that it has more configurable 


None of our "Javascript gurus" where present, but the general feeling was:

* The architecture of Aloha could be better, but it's currently not the 
* We should be able to improve the integration of Aloha so that more 
configuration options are exposed
* At some point an abstraction layer for the RTE would be nice, but for 
the moment this would probably be counter-productive (e.g. Rens is 
currently working on a way to display Aloha sidebar options in the Neos 
inspector, solving this in an abstract manner would make it more complex)

== "Party decoupling" task ==

* Initiator(s): Adrian Föder

=== Background: ===

The TYPO3.Party package should not longer be a requirement for Flow, but 
an optional package.

=== Possible discussions: ===

As far as the initiator of this topic (I, Adrian) is aware, there is no 
doubt in necessity of that task at all; however, I wanted to discuss 
whether there should be *no* "Party" at all in Flow, i.e. also no 
PartyInterface or something.
"Akii" from the IRC channel and I conclued on this: an Account is an 
Account and here the story ends. If an Account should be (able to be) 
wired with a Party, the Party package should bring everything with it.
I already started a draft on 
https://review.typo3.org/#/q/topic:PartyDecoupling,n,z where all changes 
to the Flow package are considered "deprecated-per-design" changes to 
maintain backward compatibility.
''Addendum:'' I'd even like or at least strive to have that Package then 
as a state-of-the-art DDD package where "Party functionality" represents 
a BC, having all that stuff like Application Services etc.


The attendees agreed on the idea and upon the general approach of 
Adrians patch.
It was suggested though to tweak the change so that a very basic 
implementation is possible without having to install the party package 
or having to implement everything manually.

This means:
* A PartyInterface (and possibly an (empty) implementation) should 
reside in the Flow package
* The return type annotation of Account::getParty() should be changed to 
that interface
* AbstractParty implements the interface and - if the party package is 
installed - makes sure that its implementations are used

= Suggested Topics for the upcoming meeting =

== "Rules" workflow concept ==

* Initiator(s): Soren Malling

=== Background: ===

Based on the discussion on


Implementation can be discussed further. Christopher talked about makes 
rules with TypoScript and Eel.

=== Possible discussions: ===

* How should rules be persisted, if created by the editor

Bastian Waidelich

More information about the Neos mailing list