As I am getting deeper and deeper into more complicated applications I am finding that I often land up breaking the App Structure panel because I am removing the classes it needs in order to display it correctly.
The reason I remove the classes is because of creating content management systems for my end users to have the greatest possible control over their design layouts.
Here is a really silly and simple example. <div class="container"></div>
This would show up in the App Structure panel correctly, however what if I wanted to allow my end user to create fixed width or fluid width containers via their CMS, then I would alter this to obtain the class needed from the database. <div dmx-bind:class="db-container-type"></div>
This works great but breaks the App Structure panel in Wappler.
I wonder how many other users run into a similar situation pretty often and if there would be a way for Wappler to work around this. Maybe a false class that is only read by Wappler internally like <div dmx-app-structure="container" dmx-bind:class="db-container-type"></div>
Would love to hear some other users experiences with this same sort of issue of breaking the App Structure Panel on purpose, but having no real alternative.
Thanks @Tom, I tried it out, it does fix the design display at least, but still not the app structure panel funnily enough, which I do find kind of strange.
I am really just in the testing phase so mine is still pretty simple.
NodeJS, docker, with a layout and template page, and this test is in a partial which literally only has your code and a row / col inside it.
So currently really simple, but as this grows it will certainly become far far more complicated, considering i broke it this fast, was some kind of record.
I need a āhero to zeroā badge for this speed to break a Wappler project on purpose, haha
You could keep the container class as is.
Then in the dynamic class, donāt use any of the Bootstrap classes. Instead create your own style sheet & CSS classes which would override each property of container class as needed.
So, when page is rendered, the div will have both container and your custom class, and applied CSS would only be from your custom class.
I assume having the separate dmx-app-structure-class would put a lot of load on the tree view, causing performance issues.
For such complicated custom UI elements, there have been discussions previously about storing HTML in DB and having a Wappler way to render it like its part of the page - complete with dmx bidnings and stuff. That would be a better implementation, becuase down the line, you will probably need that too.
I think long term it may be better for Wappler too, I mean just from BS4 to BS5 to read correctly in the app structure they would have had to have added checks to say read as container for 6 different container types vs 2 before. If they add more frameworks later and a container can be reused then having something like is:dmx-container could keep track of it.
I have no idea how they do this, but if I had to guess, first check would be what the BS version is, and then do the checks to build the tree, which is still efficient.
Yeah, HTML bloat is also my concern, so not really sure the best way to do it, however I do not think the current way of using the built in class names as type identifiers in the App Structure is a good permanent solution when considering larger scale CMS customisations, maybe there would be a way to combine the 2, so either set the tree type in the App Structure by class name, or if specified some custom piece of HTML such as is=ādmx-containerā or something similar to identify it.