[Neos] FYI: Summary of todays "technical meeting"Participants: Aske, Julle (readonly), Karsten, Mar

[Markus Goldbeck]

Participants: Aske, Julle (readonly), Karsten, Marc, Markus, Rens, Robert, Bastian, Christopher (partly), Søren (partly)

Persisting chosen workspace and create links to different edit modes
Initiator(s): Søren, Aske, Bastian

Background:
* Discussed in the IRC channel 15th january, having the workspace name in the url was "not handy" in terms of keeping the url clean and easy to share.
* It was discussed, how to save the current workspace, and create a link to share with a editor (imagine a workspace with more editors, and I will share a link to a specific page. Either for review etc.)
* At the same time, the topic of parsing around edit mode (raw, in-content) and locale was brought up.

Possible discussions:
* How do we persist what workspace the current user is working in (user preferences?)
* How do we pass different edit related arguments around? (locale, editMode etc.)
* Will a hashed url be the answer or should the url consist of meta information?

node/path at some-workspace;locale=foo;mode=print
Use query path for context "overrides" and edit modes:
node/path?context[workspace]=some-workspace&context[dimensions][locales]=de_DE,de_ZZ&context[editMode]=print
locale/url/path?__neos=some-workspace;editMode=print


Conclusion:
* In general everyone agreed to have meta data encoded in the *backend* URLs
* Follow "HTTP" - regular URL encoding for query parameters
* Specify from case to case whether it is a *user preference*, a *context* or *configuration*
* If a parameter is not specified in the URI the default can be loaded from User Settings

Neos node constraints
Initiator(s): Bastian
Background:
An often requested feature of Neos is the possibility to restrict allowed child node types for certain nodes/node types.
Possible discussions:
Is it sufficient to have those constraints in the NodeTypes.yaml - or do we need it for certain node paths?
Do we need to be able to specify the *number* of certain child node types (e.g. 1 Text, 1-5 Images)
What about inheritance? (Is "SpecialText" allowed, if "Text" is in the constraint whitelist?)
Does it make sense to combine this feature with "ACL"?
Notes about this subject with suggested structure in Scrum notes: https://docs.google.com/document/d/1AcKVToYzQMe2QuV5IyiAo5dfyF7CWgfrmm_IeVxDSmo/edit#heading=h.igtd07j1zmh8

Conclusion:
* Having constraints based on the node path would be very hard to achieve (and possibly slow)
* We'll start with global constraints only
* The configuration format should be simple to start with but open for change

Dynamic configuration of selector elements
Initiator(s): Soren 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
  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'


"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

Should we use @include in the ClassLoader?
Initiator(s): Marc Neuhaus

Background:
The Recent commit for the ClassLoader reintroduced several "@include" statements which make it impossible to debug flow sometimes because the compile runtime throws **no** useful information. We had this same issue already last time after trying to speed up the ClassLoader which introduced the exact same issue :(

https://review.typo3.org/#/c/27384/

Conclusion:
The change improves performance & composer compatibility, but it swallows all errors that might occur during a subrequest
-> get rid of the @ and measure performance
-> Marc pushes a fix by the end of this week



Redirects for moved or deleted Pages
Initiator: Markus Goldbeck
Background:
Moved pages which are tried to be visited with an old url should be deliver 301 and redirected to the new url.
Pages especially for temporary promotions are deleted so it would be helpful if a valid status code for google could be delivered.

Possible discussions:
part of this functionality already in master?? (Bastian)
solution for wanted redirects when a page is moved

Conclusion:
https://review.typo3.org/24873

-> Wait for HTTP components to be merged and implement the Flow redirect handling as (configurable) HTTP component

FYI: http://getluky.net/2010/12/14/301-redirects-cannot-be-undon/



1.0 branch backporting

Initiator: Aske

Background

Currently some changes are backported into 1.0 but there aren't any clear guidelines on when this should be done or not.

Possible discussions

Backporting of performance improvements
General guidelines

Conclusion

In general only bugfixes should be backported
Performance improvements will be a feature of the 1.1 release
If in doubt, changes should not be backported
More releases to prevent people from using master


WIP Changes
Initiator: Rens
Background:
We've some open changes like Resource Management & NodeType switching. What's the status.
Also a number of changes for branches like Flow 2.0 are waiting for reviews.
Conclusion:
Resource management: in progress, on the agenda if time
Node Type Switching: would be nice if someone could rebase & fix functional tests
Ext.Direct replacement: planned to process comments within about a week (Rens)


Jira
Initiator: Robert
Conclusion:

Robert is in contact with the server team and we're about to be able to use jira on TYPO3 server infrastructure!
Hopefully we can start using adding issues by friday.

-- 

Markus Goldbeck
TYPO3 Core Developer, Neos Team

TYPO3 .... inspiring people to share!
Get involved: typo3.org