[Neos] FYI: Summary of todays "Technical Meeting"
Bastian Waidelich
bastian at typo3.org
Tue May 13 16:19:41 CEST 2014
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
More information about the Neos
mailing list