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

[Bastian Waidelich]

Hi list,

another technical meeting took place today (see 
http://wiki.typo3.org/TYPO3_Neos-DiscussionMeetings):

Participants: Rens Admiraal, Aske Ertmann, Christopher Hlubek, , 
Sebastian Kurfürst, 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/203261/

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

* How to make editing more configurable:
     -> We had a dedicated meeting, see 
http://forum.typo3.org/index.php/t/203662/ & 
http://forum.typo3.org/index.php/t/203504/

* "Party decoupling" task:
     -> No updates, see 
https://review.typo3.org/#/q/status:open+topic:PartyDecoupling,n,z & 
http://forum.typo3.org/index.php/t/203504/

= Summary of the last meeting (13th May 2014) =

== "Rules" workflow concept ==

* Initiator(s): Søren 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

=== CONCLUSIONS ===

We didn't really discuss that topic, but Rens has already experimented 
with a similar approach and suggested to discuss this in a dedicated 
hangout.
It would be good if Søren could join as well as he brought up the issue 
and probably has some valuable experience with the concept.

== Collation issue in migrations ==

* Initiator(s): Christian Müller

=== Background: ===

Migrations can easily fail without any useful error message if the 
collation of relation columns is wrong.

=== Possible discussions: ===

Should we define a default collation for identifier and relation columns 
in migrations.

=== CONCLUSIONS ===

We came up with 3 possible approaches to improve the situation:

* add Collation statement to all “CREATE TABLE” migrations
** But this would mean that we change existing migrations, which is not 
feasible
* Only set a collation explicitly for primary columns
** Are there drawbacks to having different collations in one table?
* Make default collation configurable somehow

Christopher suggests to remove the collation statement because we should 
not change existing migrations (until we have a feature of “Zero” 
migrations to have something like a migration snapshot).
If we follow that approach, we should tweak the migration generation to 
not create the COLLATION statements for new migrations (of 3rd party 
packages)

== Rest/Http/Exception Handling Concepts ==

* Initiator(s): Carsten Bleicker

=== Possible discussions: ===

* Rest Support / HTTP Request Building
* Exception Handling Concept

=== Background: ===
Rest Support / HTTP Request Building:
HTTP Requests currently using phps GET/POST variables to build up the 
request.
Also Get and Post are mixed. But get represents more arguments 
identifies the "resource" i am asking for.
Post, what is its content. Currently f.e. the get [__identity] is mixed 
into the body. but the resource is already identified,
and this mix up is not needed. its more then not needed, its bad concept 
i think :(
Also we should find some solution to handle the body without using phps 
POST and FILES stuff.
its currently not possible to handle multipart bodies having parts with 
json, xml, and image f.e.
request building should be done only by parsing the body and the headers 
and never touch POST, FILES, GET of php.

Exception Handling Concept:
Simply showing Exceptions in Neos isn't enough for a good user 
experience. User is not interested in Errors,
he is interested in Solutions. Currently Exceptions in most case just 
using http status code 500.
But there are many many more could used to introduce some improved 
exception handling.
Lets say f.e. we have some validation errors happened. This 
ValidationException could have status 4xx including its id (timestamp).
This exception bubbles up to the exception handler wich looks for a 
possible "SolutionController" and calls its index action.
In this case the index will simply redirect to the parent action (whats 
done in the errorAction now).
The resolving of the "SolutionController" could be done in a way like 
the converter resolving is done (canHandle).

=== CONCLUSIONS ===

The first issue (improved request building) should be resolved with the 
"HTTP components" feature 
(https://review.typo3.org/#/q/status:open+topic:http-components,n,z)
Bastian will look into this one again in order to rebase/finetune it and 
get it merged asap

Regarding the error handling we are aware of the fact that a lot of the 
common exception messages should be greatly improved. Besides some of 
the usual error could be prevented or caught much earlier by checking 
for failures earlier.
There are already some attempts to improve the situation:

* Make exception handler respect the requested format 
(http://forge.typo3.org/issues/43569)
* Improve NoMatchingRouteException (http://forge.typo3.org/issues/58773)
* For Neos the situation will be better once we have a stable TYPO3CR 
that encapsulates common node actions (like move, copy, ...) so that the 
failure handling can be done in a central location (The Neos REST API 
should return proper HTTP headers/-status codes for the client code to 
provide more usable error messages/dialogs)

== Introduce configurable namespace aliases to Fluid? ==

* Initiator(s): Bastian Waidelich

=== Background: ===

Once again the feature of globally configurable Fluid namespace prefixes 
came up (http://forge.typo3.org/issues/58557)

=== Possible discussions: ===

* Feasible feature?
* Possible in a 100% B/C way? (Maybe in conjunction with 
http://forge.typo3.org/issues/53059 for greater stability)

=== CONCLUSIONS ===

We are still skeptical of introducing a global configuration option for 
following reasons:

* It's very handy that Fluid files are "self-contained", so that it is 
comprehensible even if no other configuration is known (even thought the 
*f*-prefix is predefined, that's no contradiction in our opinion, just 
another convention)
* If every package can register global namespace mappings, conflicts 
would be very likely - using Views.yaml for that would not solve this
* It defeats the "convention > configuration" approach

Instead of a new configuration option, we suggest to introduce a new 
convention:
The package keys of all packages that contain ViewHelpers are 
pre-registered (lower-cased).

With this you could directly use 3rd party ViewHelpers without having to 
register the namespace:
<pre>
<typo3.neos:helper foo="bar" />
{typo3.neos:helper(foo: 'bar')}
</pre>

Apart from that we should get http://forge.typo3.org/issues/53059 in 
asap independently of the result of the above discussion.

-- 
Bastian Waidelich