🇫🇷France @just_like_good_vibes

you are welcome, we are so happy people enjoy ui patterns 2 :)

Hello. i don’t understand your point ?
you can override getPropValue in your subclass to return what your source is supposed to return, at the same time you can also use getPropValue from the parent class, which is not private.

i will propose something

i have tested using a component with an URL prop.

when i have enabled the module "ui_patterns_ui", then the resulting configuration is not correct when i saved a component, for example, with a block. i show you before and after. i have used ui_patterns_ui custom form or the component form.

Before :

uuid: 32e7783c-85b3-4c2f-b4e1-7af075159d3e
langcode: en
status: true
dependencies:
  module:
    - ui_patterns
    - ui_patterns_blocks
  theme:
    - ui_suite_dsfr
id: ui_suite_dsfr_buttonuisuitedsfr
theme: ui_suite_dsfr
region: content
weight: 0
provider: null
plugin: 'ui_patterns:ui_suite_dsfr:button'
settings:
  id: 'ui_patterns:ui_suite_dsfr:button'
  label: 'Button (UI Suite DSFR)'
  label_display: visible
  provider: ui_patterns_blocks
  ui_patterns:
    component_id: 'ui_suite_dsfr:button'
    variant_id:
      source_id: select
      source:
        value: ''
    props:
      attributes:
        source_id: attributes
        source:
          value: ''
      url:
        source_id: url
        source:
          value: 'https://drupal.org'

    slots:
      label:
        sources:
          -
            source_id: token
            source:
              value: coucou
            _weight: '0'
visibility: {  }

After

uuid: 32e7783c-85b3-4c2f-b4e1-7af075159d3e
langcode: en
status: true
dependencies:
  module:
    - ui_patterns
    - ui_patterns_blocks
  theme:
    - ui_suite_dsfr
id: ui_suite_dsfr_buttonuisuitedsfr
theme: ui_suite_dsfr
region: content
weight: 0
provider: null
plugin: 'ui_patterns:ui_suite_dsfr:button'
settings:
  id: 'ui_patterns:ui_suite_dsfr:button'
  label: 'Button (UI Suite DSFR)'
  label_display: visible
  provider: ui_patterns_blocks
  ui_patterns:
    component_id: 'ui_suite_dsfr:button'
    variant_id:
      source_id: select
      source:
        value: ''
    props:
      attributes:
        source_id: attributes
        source:
          value: ''
    slots:
      label: {  }
    display:
      value:
        props:
          url:
            source:
              value: 'https://drupal.org'
visibility: {  }

just_like_good_vibes → created an issue.

Hello,
thank you for this issue.
the method you want to expose as protected was not really designed to be opened to subclassas and be treated like an internal API.
why not using directly getPropValue to get the tree of items ?

hello,
thank you for this interesting question :)
so there is something very important that needs to be understood when configuring components with ui patterns.

there are different places in a drupal site, where one is configuring a component through the user interface, thanks to ui patterns and its
component form.
in a block (instance placed in block layout), in views, in field ui (in manage display of an entity type of entity bundle, or field layout, layout builder)… etc
in all those cases, the configuration of the component done in the UI will be stored as drupal config.
And we absolutely don’t want to make references to content entities in drupal config.
the only good case to make that, is. when the configuration of the component is stored in a content, like in the very specific case of layout builder override for example.
sources that take external contents (files, content entities, whatever), usable in the “content”
context, do not exist yet.
for files and an upload form widget, we could think about storing them in the config (like base64 images?), but not sure we will go for that now.

such sources with reference to contents will be introduced soon (more info coming soon), especially in the case of the upcoming display builder projet. they are part of the global puzzle.

However, in a custom project, it is totally ok to create and use such sources anywhere as soon as developers are realizing what they are doing (like hardcoding in config, some references to content entities)

thanks :)

in addition to the work done today, i did the following changes :

 -  getSdcComponentId => getComponentId 
 - ComponentController::load => components are now sorted by provider and label 

 - BUGFIX in ComponentController,
    -  'component_form_display.' . $component->getPluginId() . '.add_form'; => 'entity.component_form_display.' . $component->getPluginId() . '.add_form';
 - Improve UiPComponentFormDisplayForm::buildForm
    - any source settings form not deriving from SourcePluginPropValue, was proposing widgets without titles.. i implemented a method to properly set a title in the other cases.
 - in ComponentFormDisplay, removed two functions not part of the interface and unused 
    - removed : public function getSdcComponentId():string {
    - removed : public function getSdcComponentDefinition():array {
 - renamed the hook "ui_patterns_component_prepare_view" to an alter hook "ui_patterns_component_pre_build" =>  hook_ui_patterns_component_pre_build_alter
 - add cache management to ui_patterns_ui_ui_patterns_component_pre_build_alter

hello, the issue from https://www.drupal.org/project/commerce_shipping/issues/3377870 ✨ ShippingRateWidget ajax refresh does not refresh other form elements Needs work seems fixed.
maybe this issue could be closed?

Hello,
any update on this one?

just_like_good_vibes → created an issue.

just_like_good_vibes → created an issue. See original summary → .

ready for merge :)

@goz & Christian, would you like to review too ?

just_like_good_vibes → changed the visibility of the branch 2.0.x to hidden.

just_like_good_vibes → changed the visibility of the branch 3510596-boolean-prop-with to hidden.

guys, i will take that one.
After discussing with Christian, i think we may have something nice

checked with @goz.

We need to be able to differentiate because those cases for the value injected into a boolean prop :

- NULL value => today's we don't inject the prop
- FALSE value => today's we don't inject the prop
- TRUE value => we inject true.

we need to inject False, when an explicit false was injected

ok, ready for review

We will propose something to cope with those errors before a proper fix is proposed at the right place, i mean in the drupal_cms_olivero SDC component definitions... stay tuned, it will come quickly.

i am surprised of those mistakes in the component definitions of the contrib theme drupal_cms_olivero, we will fill an issue if not already done to help them correct.

Hello again,
i have made the test and yes.
Clearly the problem is coming from experience_builder.
I am so surprises they have put it in drupal_cms whereas it is not ready...

here is the full trace on my install

The website encountered an unexpected error. Try again later.

JsonSchema\Exception\ResourceNotFoundException: file_get_contents(json-schema-definitions://experience_builder.module/image): Failed to open stream: No such file or directory in JsonSchema\Uri\Retrievers\FileGetContents->retrieve() (line 38 of /var/www/html/vendor/justinrainbow/json-schema/src/JsonSchema/Uri/Retrievers/FileGetContents.php).

JsonSchema\Uri\UriRetriever->loadSchema() (Line: 181)
JsonSchema\Uri\UriRetriever->retrieve() (Line: 52)
JsonSchema\SchemaStorage->addSchema() (Line: 115)
JsonSchema\SchemaStorage->getSchema() (Line: 138)
JsonSchema\SchemaStorage->resolveRef() (Line: 162)
JsonSchema\SchemaStorage->resolveRefSchema() (Line: 31)
Drupal\ui_patterns\SchemaManager\ReferencesResolver->resolve() (Line: 246)
Drupal\ui_patterns\ComponentPluginManager->annotateProp() (Line: 231)
Drupal\ui_patterns\ComponentPluginManager->annotateProps() (Line: 161)
Drupal\ui_patterns\ComponentPluginManager->alterDefinition()
array_map() (Line: 242)
Drupal\Core\Theme\ComponentPluginManager->alterDefinitions() (Line: 341)
Drupal\Core\Plugin\DefaultPluginManager->findDefinitions() (Line: 321)
Drupal\ui_patterns\ComponentPluginManager->findDefinitions() (Line: 213)
Drupal\Core\Plugin\DefaultPluginManager->getDefinitions() (Line: 134)
Drupal\Core\Theme\ComponentPluginManager->find() (Line: 73)
Drupal\Core\Template\Loader\ComponentLoader->exists() (Line: 100)
Twig\Loader\ChainLoader->getCacheKey() (Line: 318)
Twig\Environment->getTemplateClass() (Line: 204)
Drupal\Core\Template\TwigEnvironment->getTemplateClass() (Line: 296)
Twig\Template->loadTemplate() (Line: 54)
__TwigTemplate_6c14f1eef299f2f3809ad0c3fca020e7->doDisplay() (Line: 388)
Twig\Template->yield() (Line: 64)
__TwigTemplate_5d6f3398ef26ce387a50b8d23c021440->doDisplay() (Line: 388)
Twig\Template->yield() (Line: 68)
__TwigTemplate_0ac52a8eecb896edfa663d5786a718fc->doDisplay() (Line: 388)
Twig\Template->yield() (Line: 344)
Twig\Template->display() (Line: 359)
Twig\Template->render() (Line: 51)
Twig\TemplateWrapper->render() (Line: 33)
twig_render_template() (Line: 348)
Drupal\Core\Theme\ThemeManager->render() (Line: 446)
Drupal\Core\Render\Renderer->doRender() (Line: 459)
Drupal\Core\Render\Renderer->doRender() (Line: 459)
Drupal\Core\Render\Renderer->doRender() (Line: 203)
Drupal\Core\Render\Renderer->render() (Line: 484)
Drupal\Core\Template\TwigExtension->escapeFilter() (Line: 94)
__TwigTemplate_0e31e843b5da39bfd546c4ab4d41b777->doDisplay() (Line: 388)
Twig\Template->yield() (Line: 344)
Twig\Template->display() (Line: 359)
Twig\Template->render() (Line: 51)
Twig\TemplateWrapper->render() (Line: 33)
twig_render_template() (Line: 348)
Drupal\Core\Theme\ThemeManager->render() (Line: 446)
Drupal\Core\Render\Renderer->doRender() (Line: 203)
Drupal\Core\Render\Renderer->render() (Line: 158)
Drupal\Core\Render\MainContent\HtmlRenderer->Drupal\Core\Render\MainContent\{closure}() (Line: 593)
Drupal\Core\Render\Renderer->executeInRenderContext() (Line: 153)
Drupal\Core\Render\MainContent\HtmlRenderer->renderResponse() (Line: 90)
Drupal\Core\EventSubscriber\MainContentViewSubscriber->onViewRenderArray() (Line: 246)
Symfony\Component\EventDispatcher\EventDispatcher::Symfony\Component\EventDispatcher\{closure}() (Line: 206)
Symfony\Component\EventDispatcher\EventDispatcher->callListeners() (Line: 56)
Symfony\Component\EventDispatcher\EventDispatcher->dispatch() (Line: 188)
Symfony\Component\HttpKernel\HttpKernel->handleRaw() (Line: 76)
Symfony\Component\HttpKernel\HttpKernel->handle() (Line: 53)
Drupal\Core\StackMiddleware\Session->handle() (Line: 48)
Drupal\Core\StackMiddleware\KernelPreHandle->handle() (Line: 28)
Drupal\Core\StackMiddleware\ContentLength->handle() (Line: 32)
Drupal\big_pipe\StackMiddleware\ContentLength->handle() (Line: 116)
Drupal\page_cache\StackMiddleware\PageCache->pass() (Line: 90)
Drupal\page_cache\StackMiddleware\PageCache->handle() (Line: 48)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle() (Line: 51)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle() (Line: 36)
Drupal\Core\StackMiddleware\AjaxPageState->handle() (Line: 51)
Drupal\Core\StackMiddleware\StackedHttpKernel->handle() (Line: 709)
Drupal\Core\DrupalKernel->handle() (Line: 19)

Hello,
we will check this,
thank you for reporting.

just_like_good_vibes → created an issue.

Guys, i corrected the wording, i hope it fits our needs and reached consensus.

With @goz, we also investigate a strange behavior using layout paragraphs and we corrected a bug :)
list_class in the field type.

it may be ready to be merge right now...

field type :

"UI Patterns Source"

field widget :

- All Slot Sources (UI Patterns)
- Components only (UI Patterns)

just_like_good_vibes → created an issue.

we need to finish this for 1.1.0

do we have an update?

just_like_good_vibes → created an issue.

Yes good idea

i forgot to mention that :
- i added a kernel test : it allows to test that the field is working (accepting the value) and the new mapping source also.
- i corrected a few sources that were not tagged as widgets.
- as you can remark, i introduced a few new properties to our component render elements. It allows us better control on how the forms are rendered by default (wrap into details or not, headings or not, hide/show sources for props, only show some props). The opens an even nicer "API" for other modules when they embed the component related forms (component form, slot form, prop form)

Back at it !
i did the change, even better than expected.

Also i re-introduced the component widget but with a way nicer default mode and i took care of previous comments from Christian about how props were filtered.
now it's a quite super clean default mode for editors, when ui_patterns_ui is not enabled.

yes, only the plugins acting on a single prop type are available in the UI.
the conversion plugins are internal only.

so let me rephrase :
- a new plugin type to apply an operation from one prop type to the same prop type. those plugins may be used in components prop forms and component slot forms. One would select a source first, and one would optionally add a sequence of those plugins.
- a new plugin type to declare a conversion from one prop type to another. the introduction of those plugins would be done with a renovation of the prop type conversion system (declaration and conversion paths computation)

A new plugin type yes, we already talked about it, and that seems to be clearly a new plugin type.
maybe we would need it also for conversion from one prop type to another.
In other words, we could also renovates our conversion mechanism which is now very simple and not easily alterable...

sorry for the disappearance, Christian was a bit disturbed by that widget, and thought ui patterns ui could be better, which would be true but would clearly need additional configuration to create that form
and apply it. Maybe we reintroduce?

the custom data type is ok for me, but i will give a try to map, every data type needs to have a chance 🤣

All good without the component widget, because ui_patterns_ui will provide a better one with customized form.
previous bugs may be fixed, please review :)

just_like_good_vibes → made their first commit to this issue’s fork.

we should also think about the storage.
for a given source attached to a prop or to a slot delta, we have "source_id" and "source".
if we introduce a native mechanism to chain, we should think about how it would/cloud be stored.

There are multiple nice usecases.

for example, to invert a boolean value, to filter an output, to trim a string... etc etc

Christian, Fabien (@goz), and Pierre, would you review please?

there may be a last private comment from Pierre, unaddressed :

- why do we use datatype custom, isn't map enough?

thanks, i will merge

please review :)

just_like_good_vibes → created an issue.

i am not so fan of items neither :)

i have created another issue to push some fixes (currently in the MR of this issue) in another MR first.
see 🐛 [2.0.3] Various bugfixes and edgecases when using sources outside of ui_patterns Active

just_like_good_vibes → created an issue.

also, the term configuration for the source refers to the global configuration, whereas we wanted the settings, i would keep settings to avoid confusion

getMinimalConfiguration does not need any parameter, unless it is static, which could be a nice idea after all.

i don’t like collection, because it reminds of the plugin collections in drupal which are managed differently…

just_like_good_vibes → created an issue.

Hello, thank you for reporting.

When i read for example FieldDefinitionInterface in drupal core, in the comments :
"Returns the ID of the entity type the field is attached to.", "@return string".
But it is not in the signature, only in the comments.

That sounds like a very odd and strange case, where a field formatter would not have an entity_type_id to which it is attached.
i tried to patch the function and treat the case of entity_type_id being null, but my guess is that something else won't work at another place.

please review

i haven’t posted the updated code yet, i have a large update to this MR i. preparation

@miiimooo, let me know if the pushed code is solving something to your issue?
i still can't reproduce on my side.

i can't reproduce right now your issue.
there is a code in ui_patterns_blocks in the .module which does this.
The problem is introduced by "layout_builder_restrictions"...

Hello,
thank you for clarification, indeed very strange, it seems like a regression.
we need to figure this out. thank you for reporting. i will work on that one.

just_like_good_vibes → created an issue.

hello there :) interesting issue and discussion. from my point of view, it would be nice to have some new tests (with the solution or without any solution if no solution is required) of this issue. Ideally, those tests would cover different "classic" situations.

just_like_good_vibes → created an issue.

we voted for ui_patterns_source_value, let the magic happens now

sorry, just one small thing about the addRequired for checkbox

just_like_good_vibes → created an issue.

hello Christian, i guess it is still on your side, ping me when you are ready for review :))

ui_patterns_entity:x:x blocks are for layout builder and only appears in layout builder, because it requires an entity context to work.

ui_patterns:x:x are global blocks without any context required, they won't show in layout builder by design (and by code).

in which screen, by which contrib module, are the blocks shown twice? i guess this is where the code is wrong. Because when you properly require the list of blocks for layout builder, only one block per component is returned.

g4mbini → credited just_like_good_vibes → .