[Neos] FYI: Summary of todays "Technical Meeting"
Dominique Feyer
dfeyer at ttree.ch
Tue Mar 18 22:13:21 CET 2014
Thanks for tacking care of the minutes of the meeting.
--
Dominique Feyer
Sent with Airmail
Le 18 mars 2014 à 16:35:10, Bastian Waidelich (bastian at typo3.org) a écrit:
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
_______________________________________________
Neos mailing list
Neos at lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/neos
More information about the Neos
mailing list