[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