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

[Bastian Waidelich]

Hi all,

we just had a nice little technical meeting. Here a brief summary of 
what has been discussed. You can also see (a better readable) version on 
http://wiki.typo3.org/TYPO3_Neos-DiscussionMeetings:

= Todos/Updates from the previous meetings =

* Jira:
     -> Robert is in contact with the server team and we’re about to be 
able to use jira on TYPO3 server infrastructure!

* ExtDirect replacement:
     -> New patch-set, almost ready to be merged: 
https://review.typo3.org/25204

* Fix support for relative/aliased namespaces in Flow
     -> https://review.typo3.org/28490

* Throw exception for unpersisted changes in Safe Request:
     -> Merged! (https://review.typo3.org/23484)

= Summary of the last meeting (18th March 2014) =

== Dynamic configuration of selector elements ==

* Initiator(s): Søren Malling

=== Background: ===

copy'n'paste from this forge ticket: http://forge.typo3.org/issues/55438

Many selectors can consist of dynamic content: * Specific nodetypes * 
tags * objects/models from your own package/backend module * and many more..

Somehow, this could be dynamicly possible within configuration. This is 
an example, and hopefully be usable for discussion

<code>
     properties:
         selectorElementInTheInspector:
             type: [IM IN DOUBT HERE, AS IT CAN BE ANYTHING. MAYBE A PROXY?]
             ui:
                 label: 'Tags'
                 reloadIfChanged: true
                 inspector:
                     editor: TYPO3.Neos/Inspector/Editors/SelectBoxEditor
                     editorOptions:
                         placeholder: 'Select the tags identifier'
                         multipleItems: TRUE // IF ITS POSSIBLE TO 
CHOOSE MULTIPLE ITEMS
                         displaySelectedItems: TRUE // IF DISPLAYED 
ITEMS SHOULD BE DISPLAYED (EX. tags)
                         [SOMEHOW CONFIGURATE THE DYNAMIC PARTS 
(nodeTypes, domain object etc.)
                         values:
                             '': null
                             contact-form:
                                 label: 'Contact form'

</code>

=== CONCLUSIONS ===

We should extend the SelectBoxEditor so that it can be re-used for 
arbitrary property types.
Following features would be nice:

* General "dataSource"-option (similar 
"[http://docs.typo3.org/typo3cms/TCAReference/Reference/Columns/Select/Index.html 
itemsProcFunc]" in CMS
** A generic DataSourceInterface that returns key/values and can be 
implemented for nodes, nodeTypes etc.
** A way to poll that data source via AJAX (e.g. for the Node editor, 
with an optional filter)
* Grouping (move to Select2?)
* Dependant properties (possibilty to pass property x to dataSource 
option of property y, e.g. for PluginViews editor)
* MultiValue: TRUE/FALSE (or/and maxItems option)

Søren also raised the question whether it makes sense to store those 
properties and relations in a serialized array (because it makes 
crawling of nodes based on properties very hard)

We agreed that this is the only viable way currently and that we should 
create an *index* on top of the node properties for search-ability in 
the long term.

BTW: There already exists a 
[https://github.com/Flowpack/Flowpack.ElasticSearch.ContentRepositoryAdaptor 
CR adapter for elasticsearch] and Christian is currently working on a 
[https://github.com/kitsunet/Flowpack.ZendLucene.ContentRepositoryAdaptor "raw 
PHP adapter"]

== Improved handling for TargetNotFound exceptions ==

* Initiator(s): Georg Ringer, Bastian, Sebastian

=== Background: ===

 From the IRC: "hey guys. can you take a look at 
http://forge.typo3.org/issues/55869 again how that would be solved in flow?"

=== Possible discussions: ===

* Map errors to default values of the action parameter?
* Extend the errorAction() to handle the "not found" case?
* There's a difference between
** Exception while property mapping for target type 
"Some\Package\Domain\Model\News", at property path "": Object with 
identity "non-existing-uuid" not found. (1297759968)
** Exception while property mapping for target type 
"Some\Package\Domain\Model\News", at property path "categories.0": 
Object with identity "non-existing-uuid" not found (1297759968)

Related changes/issues:

* https://review.typo3.org/26570
* https://review.typo3.org/27535/

=== CONCLUSIONS ===

We agreed that falling back to the default argument value on error is 
*not* the way to go, because:

* It is a breaking change that is hard to detect
* It's not very explicit/transparent and it creates wrong HTTP status 
codes by default (200 instead of 404 for example)

Instead we suggest to handle it via the *errorAction*:

* Collect errors in the Controller\Argument (like we do with 
ValidationResults currently)
* If an error occurs, invoke the errorAction. The default implementation 
will detect the error and throw the matching exception (404 or 500, 
depending on the error) as before
* Developers can override the errorAction (or a protected method that is 
called from the error action) in order to handle the error in a custom way

To make this more usable we should check the existence of a custom 
errorAction for the current action (like we do with the 
initialize*Action() methods).

This change would be backwards-compatible in theory, but there are 
naming clashes if two actions "showAction()" and "showErrorAction()" 
already exist..

A solution for that would be the usage of annotations instead of "magic 
method names". But if we go that way we should do it for actions and 
initialize*actions as well:
<php>
class SomeController {

	/**
	 * @Flow\BeforeAction(actions = {"show", "delete"})
	 */
	protected function myInitialization() {
		// some initialization
	}

	/**
	 * @Flow\Action
	 */
	public function show(News $news) {
	}

	/**
	 * @Flow\OnError(actions = {"show"})
	 */
	protected function myErrorHandler() {
		foreach ($this->arguments->getArgument('news')->getErrors()) {
			// some custom error handling
		}
	}
}
</php>

We decided to go for the non-invasive approach for now.


-- 
Bastian Waidelich