Bindings missing inside partials

Wappler Version : 4.0.1
Operating System : MacOS Big Sur 11.4
Server Model: NodeJS 14
Database Type: MariaDB 10.5.x
Hosting Type: Digital Ocean Docker Engine

Expected behavior

What do you think should happen?

When using layout to content pages with partials, components such as Browser, Toasts, Notifications, Alerts should be able to be added once on the layout page only, which will add the components .js/.css to the head as well as it’s relevant base code, such as.

<body is="dmx-app" id="main">
    <div is="dmx-view" id="content">
        <div is="dmx-browser" id="browser1"></div>
        <div is="dmx-bs5-toasts" id="toasts1"></div>
        <dmx-notifications id="notifies1"></dmx-notifications>
        <div class="alert" id="alert1" is="dmx-bs5-alert" role="alert">
            <p>This is a nice alert!</p>
        </div>

        <%- await include(content, locals); %>
    </div>

    <script src="https://cdn.jsdelivr.net/npm/bootstrap@5.0.2/dist/js/bootstrap.bundle.min.js" integrity="sha384-MrcW6ZMFYlzcLA8Nl+NtUVF0sA7MsXsP1UyJoMp4YLEuNSfAP+JcXn/tWtIaxVXM" crossorigin="anonymous"></script>
</body>

From the layout or content page all of the added components are now accessible through the data bindings, like this.


If I add a partial to this content page now, I would still like to access the same bindings.

Actual behavior

What actually happens?

From a partial page the bindings are missing as per below.

How to reproduce

  • Create a new NodeJS project, add browser, notifications, alerts, toasts to the main.ejs page, and save.
  • Open the content page index.ejs and add a <p> tag with some content in it, click it in the app structure and say move to partial. and save.
  • Open newly saved partial and try add a binding from any of the components, and all are missing.

Even if trying this in a more Wappler correct way, which will not allow the components in the main.ejs layout page file, but rather wants them in the index.ejs content page, as soon as i move to partial, i can not access the bindings from inside the partial itself.

This seems like normal behaviour. A partial is not bound to any content page.
It can be used in any content page.
So, there is no way to show the bindings in the picker like you suggest.

Although, when partial is used inside any content, if the expression can be resolved, you will see dynamic data in runtime.

Yeah, I figure about the same Sid, however there is a path going back from a partial all the way back to a layout page, but it would have to follow the breadcrumbs, so partial links to content and content links layout, therefore is there are components such as browser, i would imagine those browser properties should be available in any one of the files.
Unless I am wrong and I should be adding a browser component in the content page or layout page, and then again inside the partials, but that does not sound right to me.

I wonder if a partial could just have something added to the comment section at the top like the existing head-page="index" telling it also what layout page it comes from, but make it optional, so if we want we can choose it for a SPA but if we have many layout pages then we can leave it out.

In the end it would maybe look like

<!-- Wappler include head-page="index" layout-page="layouts/main" appConnect="local" is="dmx-app" bootstrap5="local" fontawesome_5="cdn" components="{dmxNotifications:{},dmxBootstrap5Alert:{},dmxBootstrap5Toasts:{},dmxBrowser:{}}" -->

Browser indeed should only be added in content or layout page, and not on the partial page in an ideal scenario. But the partial is allowed to have its own browser component - that is not restricted.

The limitation here is a logical one, from my perspective, rather than a Wppler bug. Let me know if I am going in a different direction than your requirement.

When you create a partial, it could be used in content/layout A or B or X or Z. The partial has no way to know where it is going to be used.
So, without that knowledge, there is no way to populate dynamic picker UI when editing a partial page.

One potential solution could be to just show all the bindings from all project pages - content or layout - but it will just cause more confusion, specially in NodeJS because all content pages are just under “content” object. (In ASP .NET & PHP, there are route objects which provide some distinction.) But because the items could have same names etc, it would be a nightmare.

In one of our projects, where we have numerous partials (you know which one :wink:) , and use dynamic bindings from content pages - we have to make sure explicitly that all content pages that are going to use that partial have SC or other components with the same name & data structure, so that the partial bindings can be evaluated on runtime to show correct data.
This is a manual process to setup in both Partial and Content/Layout pages.

If you absolutely need to access bindings via picker, copy-paste partial code into the content page of your choice, setup the bindings etc, then cut that code back into partial page. :sweat_smile:

Bahahhaha, yes I have an idea, lol.

I see what you are saying though, and do agree, thats why I think if Wappler UI gave the option on a partial to explicitly tell it which content page to link back to then in that case it could populate the picker with its parents bindings. If on the other hand you have a partial that you want to use over many different content pages that could be linked to different Layout pages, then we just leave the link blank and it remains a sort of stand alone partial.

Not certain if that would cause more trouble in the end, but it makes sense in my mind at least. lol.

For now it’s not a big issue for me personally as I live in code view anyway and do not use pickers all the time, so I can manually enter what I want, but this could be worth looking into improvement for any low-coder users.

Edit: Off the top of my head, I do not see any reason why Notifications, Alerts, Toasts, and Browser components could not all be common on the Layout page and have their data dynamically added with the data bindings from the action accessing them.

1 Like