[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 
http://wiki.typo3.org/TYPO3_Neos-DiscussionMeetings:

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: 
https://review.typo3.org/28502

* 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 
options?

=== CONCLUSIONS ===

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 
blocker
* 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.

=== CONCLUSIONS ===

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

http://lists.typo3.org/pipermail/neos/2014-January/003863.html

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