Closed bwaidelich closed 4 years ago
I used the exemplary package and I'm (and the clients too) are very happy with it. For more advanced stuff (like child nodes creation, etc) there is also Flowpack.NodeTemplates available, but this approach solved many, many use cases for me.
How about joining this with NodeTemplates and making this a single CoreFeature. I see valid use cases for both approaches and often end up writing needlessly complex node templates where for 90% of the properties (values set directly and editors are a 1:1 copy of the propertiy-configuration) but one or two need a complex definition like prefilling the main-collection.
How about joining this with NodeTemplates and making this a single CoreFeature
I'd be fine with that for sure but IMO the node templates package would need some tweaking:
And personally I have some issues with using Fusion or Eel within YAML. I know that we already do that for rendering node labels but IMO it would have been better to refer to a LabelGenerator
class instead.
I don't know how we could work around this in the NodeTemplates package but I fear that allowing the EEL-YAML-Mix is a dangerous path
I agree, maybe this is a good topic for discussion at the salzburg sprint.
Hi Folks, this would be awesome for the/any next release. @dimaip and @daniellienert do you guys think mergin it with NodeTemplates and make it a core feature is a valid strategy for moving foward?
I like NodeTemplates, but people generally find it too complicated I think... Anyways, don't have a definitive opinion on this topic, only my personal preferences :)
@davidspiola I like the idea of NodeTemplates but I think the current implementation still needs some tweaks (as commented above https://github.com/neos/neos-development-collection/issues/2173#issuecomment-433954500). I don't think we have to "merge" these features upfront because I don't see any issues in adding NodeTemplates later on.
BTW: You prefixed the ticket label with "[Feature]" is that a new practice that I missed and – if so – should it be used instead or combined with the labels?
sorry @bwaidelich, my bad. It's not a PR and prefixing was wrong anyway (I mixed it up)
Regarding the feature itself, I just wanted know if it is something to consider for 5.1
@bwaidelich I found a bug in the implementation. If you test the current 5.1 branch you will notice that the property creation popup will be shown anyway. Even if I don't set any property to be in the dialog.
I found a bug in the implementation
Yes, I'm on it. Sorry for the delay. PR incoming
@davidspiola There you go: #2830
I want to tweak this a bit further (e.g. support inline editable properties), but will create a separate PR for that
It would be nice if it was (easily) possible to mark certain properties to appear in the Creation Dialog. as suggested here: https://neos-project.slack.com/archives/C0U0KEGDQ/p1513932060000034
Back then I created an exemplary package to see how this could work out and it does a pretty good job and clients are happy with it. After using it for a while I really think this functionality should be added to the core. Especially to solve the issue of required properties. I.e. if a
NewsArticle
node requires atitle
there is currently no way to enforce this without 3rd party packages.