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

[Bastian Waidelich]

Hello friends,

here's the summary of todays long technical meeting (see 
http://wiki.typo3.org/TYPO3_Neos-DiscussionMeetings):

Participants: Karsten Dambekalns, Aske Ertmann, Dominique Feyer, Jacob 
Floyd, Sebastian Kurfürst, Bastian Waidelich

== Recursive Node Constraints ==

* Initiator(s): Aske Ertmann, Bastian Waidelich, Christian Müller

=== Background: ===

In the current WIP 
(https://review.typo3.org/#/q/topic:nodetype-constraints,n,z) Node 
Constraints are not applied recursively

=== Possible discussions: ===

* What's the current status of the NC?
* Does it make sense to have recursive constraints or is it to hard to 
grasp/implement?
* What about contradicting constraints (due to multi-inheritance)
* What is expected from the integrator? That extending node types should 
automatically be constrained if the super type is constrained?
* Possible solutions
** Use inheritance sorting
** Use "isDescendantOf" (evaluated first)
** Use mixins instead of extending node types (e.g. text with image 
extending text and image)

=== CONCLUSIONS ===

The reason why recursive constraints are an issue is the 
multi-inheritance of node types that makes it impossible to calculate a 
deterministic inheritance order. However, that is only for “ill-defined” 
inheritance chains.

→ generally, taking inheritance into account makes sense.
→ “Normally”, topological graph sort solves this problem, we just need 
to make it deterministic (NEOS-239).
→ revise inheritance of provided node types (in TYPO3.Neos, 
TYPO3.Neos.NodeTypes, TYPO3.NeosDemoTypo3Org) - especially TextWithImage 
needs to be adjusted
→ Question: should we throw an exception if a parent type is defined 
twice in the inheritance chain (and does that work with “mixins”)?


== Cropping of images ==

* Initiator(s): Aske Ertmann

=== Background: ===

Neos doesn't support cropping of images in specific aspect ratio, a 
feature very commonly
used when creating websites. In CMS there's lots of very flexible 
configuration options to achieve
it, e.g. 600c. A proposed solution is to allow setting specific aspect 
ratios for the image editor in
the inspector, which would always apply that aspect ratio. The cropping 
in the secondary inspector
would also apply the aspect ratio. Additionally a optional aspect ratio 
for when cropping could be
made available allowing easier cropping of portrait, landscape and 
square formats.

=== CONCLUSIONS ===

* Do we agree on the proposed approach? → YES.
* What about images not inserted manually? → currently not a problem. 
Long-term we could implement more “magic” cropping or the like on the 
server side.
* Optionally: Completely disable “image cropper” & size fields in UI as 
option.

== Created/modified dates for nodes ==

* Initiator(s): Aske Ertmann

=== Background: ===

Currently there's no timestamps on nodes making it difficult to see when 
something was created
or last modified. As a simple solution introducing fields for the two 
dates that are set automatically would suffice. However there are some 
challenges when using dates set automatically.

=== CONCLUSIONS ===

* Fields:
** Modified Date
** Creation Date
** Published Date *NEW*

* Modification == Creation on node creation
* Published Date == NULL on node creation

* Should a modified date be updated when publishing a proxy node to 
live? → NO. but we should introduce an additional TimeStamp field for 
the publish date. Note: That means that a node can get an older modified 
TS when being published!
* Should creation date be transferred between workspaces? → YES. should 
be always transferred.
* Should existing nodes have default dates set to when applying the 
migration or set to NULL? → NULL values not allowed for creation & 
modification dates. → set to DEFAULT DATE.
* Should copied nodes get a new creation/modification date? → Yes.
* Field names? e.g. '''creationDate''', created, createdAt, modifiedAt, 
modificationDate, '''lastModificationDate''', lastModifiedDate, updatedAt
** Asset has "lastModified", Account has "creationDate"
→ creationDate
→ lastModificationDate
→ lastPublicationDate
→ additionally (optional): rename “Asset::lastModified”

== Soft deletion ==

* Initiator(s): Aske Ertmann

=== Background: ===

To avoid loss of content there should be soft deletion of node data. 
However the desired behavior
needs to be decided:

=== CONCLUSIONS ===

* Should deleting a node in non-live workspace be soft deleted or only 
live nodes? Keep everything for the first iteration.
* Should there any automatic clean up deleted non-live nodes to avoid 
very large tables? Not in the first iteration.
* Would the constraint "pathhash", "workspace", "dimensionshash", 
"deletionDate" suffice? If using behaviors the “deletionDate” should be 
handled low-level, the unique index probably needs to be extended though
* Field name? e.g. '''deletionDate''', deletedAt, removedAt, removalDate 
→ “deletionDate”
→ Extra: Hide behind a feature flag for the first iteration.


== Possible Fluid security improvements ==

* Initiator(s): Helmut Hummel

We skipped this topic because Helmut wasn't present. It is added as 
suggested topic for the upcoming meeting (see 
http://wiki.typo3.org/TYPO3_Neos-DiscussionMeetings#Possible_Fluid_security_improvements)

== Eliminate package keys in favor of composer names ==

* Initiator(s): Karsten Dambekalns, Thomas Maroschik

=== Background: ===

Within the TYPO3 universe there are three identifiers around: extension 
key, package key and composer name. With composer as a base for 
dependency management the idea came up to unify that into just one: the 
composer name.

For Flow this is not really a problem, since the package key and 
composer name can be converted bi-directionally but might lessen 
confusion and clean up the code.

=== CONCLUSIONS ===

Extension key: “typo3flow”
Package key: “TYPO3.Flow”
Composer name: “typo3/flow”

One reason to unify this is the backported package management

* It is NOT possible to convert forth and back without data loss :) 
Example: TYPO3\Flow → typo3/flow -- why not TyPo3\FlOw ? -- 
SandstormMedia\Foo → sandstormmedia/foo → to circumvent that, we look at 
the namespace mapping.

* directory naming
* upgrade path
* deprecation policy

→ we’ll all sleep over it, and then bring it up next time. We’re neither 
against or in favor of that currently, but it needs to be investigated 
further.

== Enable split source support for Settings.yaml ==

* Initiator(s): Aske Ertmann

=== Background: ===

The settings configuration can grow quite big and the split source is 
not supported for this configuration type.
Allowing split source would make settings for packages like Flow and 
Neos a lot more structured and same
would be possible for large application packages.

=== CONCLUSIONS ===

* Are there any downsides? *Slight* performance loss in Dev context, 
possible long list of files (but that’s a matter of best practice)
* Should it be configurable instead? → NO. Rather, *ALWAYS* enable this 
mode. !!! potential pitfall for the people, so mark it as !!!.
* Is there a general consensus of doing it? → yes for all types where it 
makes sense (except Routing).
→ Deprecate $allowSplitSource flag in 
ConfigurationManager::registerConfigurationType()

== Implementation classes for specific node types ==

* Initiator(s): Aske Ertmann

=== Background: ===

Dealing with nodes is quite limited and not extensible in a clean way 
without AOP. If it was possible to define a implementation class name 
per node type it would allow for custom methods for specific things, 
e.g. a getLevel for normal Nodes in Neos that would return the depth 
related to the site instead of the root.
Or allow a getCount for ContentCollections that can be used in Eel 
attribute filters. Or a news node that could return properties with 
special logic. It would be very easy to implement using interfaces and 
not have any performance consequences since all nodes are built manually 
anyway.

=== CONCLUSIONS ===

* Is there a general consensus of doing it? → generally we all like the 
idea (like TypoScript @class)
→ should not be “public” currently; NOT marked as stable yet.
* Should this co-exist with proxy node capability (“attachable entities”)?
* Are there any downsides? It feels a bit duplicated with the proxy node 
approach, adds a level of complexity
→ we currently disagree whether this API faces to the user or not (Aske: 
Facing the user; Sebastian: not facing the user, more a “low-level” hook.)
→ we’d like to get practical understanding where this is used, we are 
not sure whether this is an “additional” API which duplicates other 
functionality.

== Transferring of html/body tag attributes on page change ==

* Initiator(s): Aske Ertmann

=== Background: ===

When changing a page in the backend the html/body tag attributes are not 
updated making
it impossible to use html/body classes or styles e.g. I've created a 
patch for it https://review.typo3.org/#/c/30798/, but we need to decide 
on the appropriate approach.

===CONCLUSIONS ===

* Challenges
** Generated classes from Modernizr or other JavaScript frameworks
** Should the original attributes be removed or updated?
** Transferring of .neos-* classes
* Possible solution would be to make the behavior configurable
** Merge with original attributes
** Remove original attributes
** Use a configurable regular expression for which classes to keep 
(incl. .neos-* ones)
→ Make it configurable. Off by default (non-breaking). → Maybe lateron 
add a sane default which makes sense in 98% of the cases. -> exact 
configuration to be discussed in a dedicated meeting
* Further discusssion
** Updating of tags in <head> (script, link, etc.)

== Content slide ==

* Initiator(s): Aske Ertmann

=== Background: ===

A pretty useful feature is being able to inherit content from a parent 
page in case the content
collection is empty. This unfortunately cannot be achieved with default 
FlowQuery currently.

=== CONCLUSIONS ===

* Should it be a feature of the content collection? slide = ${true} 
(using the given nodePath relative to the page)
* Should it be possible with FlowQuery to find the closest parent with a 
non-empty content collection?
** If a content collection had a count attribute, that would suffice. 
This could be done by making making it possible for nodes to have a 
static class implementation to allow arbitrary methods like getCount() 
for content collections. Otherwise it would have to be updated using 
signal/slot.
** A different solution would be a new “slide” FlowQuery operation

${q(node).children(footer[instanceof TYPO3.Neos:ContentCollection][count 
 > 0]') ? q(node).children('footer).get(0) : 
q(node).parents().has('footer[instanceof 
TYPO3.Neos:ContentCollection][count > 
0]').first().children('topImage').get(0)}

// Check if the current page has a footer containing content → if yes, 
return it. If not, return the closest.

${q(node).children('topImage[image instanceof 
TYPO3\Media\Domain\Model\ImageVariant]').get(0) ? 
q(node).children('topImage').get(0) : 
q(node).parents().has('topImage[image instanceof 
TYPO3\Media\Domain\Model\ImageVariant]').first().children('topImage').get(0)}




${q(node).slide(‘footer’) // checks for non-empty
${q(node).slide(‘footer’, ‘[....]’) // checks an arbitrary condition on 
“footer” using q(node [which is footer]).is(‘[...]’)
${q(node).slide(‘footer’, null, 3) // only slide up to 3 levels

footer[_childNodeCount > 0]

${q(node).slide(‘footer’).children().property(‘topImage[image instanceof 
TYPO3\Media\Domain\Model\ImageVariant]’)

→ have “slide” FlowQuery operation
→ Add getChildNodeCount to Node
→ Implement closures for Eel: ES6 syntax for Eel Closures :-D, e.g. 
map(n => n * 2)


== Multi site dimensions ==

* Initiator(s): Rens Admiraal

=== Background: ===

We now have a multi site installation with different languages per sites 
/ fallbacks

=== Short question: ===

* Did we think about this already? Like how do we handle different 
fallbacks?

=== CONCLUSIONS ===

* Rens will write a post to the mailing list with some general thoughts 
/ problems & solutions to get the discussion started.


-- 
Bastian Waidelich