+1 one view would be great! Maybe with the ability to hide/show the DOM elements?
2 Likes
If you just stay in the DOM view don’t you have the same access as showing everything? I find I almost never have to switch to DOM view unless I have to fix something I screwed up. Just curious.
1 Like
I am afraid you don’t have the same access.
There is a very strong choice to separate App Structure from the DOM from the beginning of Wappler.
It was based on all our experience in components design and building and the feedback we got in during the initial beta.
App Structure is a high level overview of your component hierarchy and major building blocks. It that gives you a great overview of your app and its functionality.
Each component in it has its own properties - just like any component building system.
The exact DOM on the other side, altought it has some similarities, is just a detailed implementation.
When dealing with high level over view you don’t want to be bothered with 20 nested DIV’s, you want to see the single component. and that is what App Structure is.
For all the detailed underground work, you switch to DOM panel. But that is a bit more like looking at separate bolts instead of the engine and the whole car 
So when you want and need the details, you go to the DOM panel. But normally you will just stick to the App Structure as you are not much concerned about the details, but just want a higher level view of all the components, working and hierarchy.
1 Like
I imagine there was a huge design decision behind that. That is why I mentioned that I knew that it wasn’t an easy change. To sell and to implement.
I do feel however that a single view with appropriate filters could accomplish the same but giving the flexibility of not having to break focus to move to another view.
In my case I work always with split view, App Structure and DOM view.
That means that I have 2 sets of 3 views:
a) Design, code and App Structure
b) Design, code and Dom Tree
Focus is broken each time I have to move between sets as it’s not only moving the mouse and clicking a tab. It’s moving mouse, clicking tab, look for element, select it, recall information from previous set, make changes, verify by clicking back you recalled correctly, etc
For me it is quite the focus pooper.
I would love to work only with one set that has the single source of truth available at a glance. Design view, code view and tree view. If I click on any element of any view it will highlight the same elements in the other 2 views. And all app connect components and html properties would be available for that element in the properties panel.
The level of detail of the tree and the properties panel could be controlled with filters so nobody(basic, intermediate and advanced users) feels left out.
IMO that would improve building focus.
Anyway this is just me presenting the business case. Deep in my UX/productivity heart I know it is a good one 
2 Likes
I do like the single focus view idea and having some kind of zoom in maybe.
Something what Sketch and Figma (and event photoshop - bah - with their smart components) has with components, that you can break up / zoom in by double clicking on going into a “parts” view.
We were actually thinking of implementing something like this in design view.
As design view is currently actually the other way around it allows you to click on every detailed DOM element - not only on components.
Keep the ideas coming, we are already gathering ideas and feedback for a larger App Structure rewrite - after we get all the other major parts that we have planned
2 Likes
Keep App structure separate from DOM view. I’m part of the category of Wapplerions who understand web technologies and how it works, but not good at working at DOM level. What I love about Wappler is staying true to what it claims to be (visual tool)!
I’m not sure how much you gain by merging both these, but you will lose a lot if you do so!
1 Like
Care to expand on this? Why would I lose?
App structure (simple) and DOM (complex) are separate now. Merging them both will make it complex unless the merge still has a way to keep these views separately.
I totally understand your concern.
If you read again my posts you will see that I mention that some kind of level of detail filters would be needed so nobody feels left out.
On the other side I wanted to bring some light about the DOM tree as there seems to be some confusion about it. The DOM view is not complex per se. It is just a view that offers two things mainly:
a) A tree view of all the elements in your page
b) Access to some additional html attributes per element
Those two things are not complex at all. Having access to them might help you when working with 3rd party libraries. But having access to them don’t make things more complex. On the contrary it simplifies the workflow for those that need them.
So lets call it that it might add unneeded information for those that can work just with the App Structure view. And for that I proposed the filters. You can have a simple view or a detailed view.
2 Likes
Thanks for taking the time to explain @JonL. Love your idea, and the Wappler UI will become more simplified for a better ux. Cheers!
2 Likes
The more I delve deep into bootstrap based designing, I find constantly shifting between the app-tree & dom-tree quite tiring as the app-tree keeps on losing focus.
I can now greatly appreciate the need for a better tree-view.
I have also created another related feature request which can be a quick win to solve the app-tree losing focus here until we get a better tree view in wappler.
I literally started exploring other bootstrap visual editors like pinegrow to see if I can design easily there, and use wappler only for app-connect, but came back to wappler with hope!
1 Like
Hi @George,
div & para both are block level containers… div to group elements, para to wrap para text
I was wondering why para is available as a component in app-tree, while div is not? I just wanted to understand the reasoning behind this, just to make sure I’m not missing something…
Wouldn’t it be better to have div as an app-tree component, so that it shows the nested content clearly?
Especially it would be easy to apply all the generic properties like spacing, sizing, border, colour etc? See below sample content under dom-tree vs app-tree, and why it’s not very intuitive
I could understand why span tag & other less-frequently used container tags ended up in the dom-tree, but surprised to see div ended up there!
This has been discussed quite a few times already.
App Structure is NOT a DOM panel and we are not planing on making it a DOM panel, it shows only the App Connect and Bootstrap 4 Components.
A div element is not a Bootstrap 4 component, same as span and many others.
If you want to work with regular HTML elements (not App Structure or BS4 components) just use the DOM panel.
2 Likes
@Teodor, this is a feature request…
I’m sure you can see the reason why I asked that question…
para is also a html element, and it’s still available as a bootstrap component…
I’m very surprised why you shut people up so quickly (not everyone of course) when we are trying to give constructive feedback… and trying to involve in healthy discussion…
I don’t really see this happening in other forums where there is a great amount of professionalism…
It’s quite painful to pay my subscription every month when I have been struggling with a bug-filled product… it doesn’t matter you release a hundred new features, if we can’t use the basics on a day-today basis, then what’s the point…
that’s quite new to us - the “Bug filled” part of your message. Looking at the showcases we receive almost weekly i was not aware that the product is bug filled.
If there are bugs we are fixing them in our weekly updates as quickly as possible
1 Like
I get it, i’m not here to argue with you… but you have to understand there are lot of things getting broken every release… I have rolled-back multiple times in the past 6 months…
There are still many outstanding… fundamental ones getting fixes after more than a month or two delay… You have no idea how much time and effort gets wasted and it’s really painful to see my $ going out every month… Especially variables were broken for a long time, and I have raised multiple bugs on it… It takes a lot of effort for me to identify, isolate and report a bug clearly and get to live with it and get things moving…
Wappler is amazing product, but we need to be appreciative of each other… you can take this feedback either positively or otherwise, but clearly this community expects more professionalism from the main staff like you… not the first time this has been flagged in this forum…
FYI, here are some i have raised that are still outstanding…
Only 6 months old…
https://community.wappler.io/t/nested-repeat-region-data-binding-issue-in-the-2nd-level/15709
Only 4 months old…
https://community.wappler.io/t/api-action-component-json-data-not-taking-dynamic-data/18605
One month old ones…
https://community.wappler.io/t/flows-global-variable-issue/20175
https://community.wappler.io/t/inline-flow-runjs-data-binding-closing-single-quote-issues/20174
https://community.wappler.io/t/api-schema-editor-issue/20603
1 Like
Back on the topic I must say that I rarely use any more the App Connect or DOM panel. I was losing too much focus moving from to another.
So basically I just use code view and select elements in the code which will render the AC properties or the html properties.
Maybe we are a just a minority that relies on switching from AC to DOM.
But the fact that I browse the code and don’t use AC or DOM tree just proves how I unproductive I am when using AC and DOM trees.
Therefore this FR to merge both and add filters to select what type of nodes are shown. Just AC, just html or both.
2 Likes
I totally agree with you @JonL!
For several (paid and free) BS themes and UI kits I tried, the templates always contain div and span elements which can be identified in code view or DOM panel of course, but don’t appear in the AC components tree.
A lot of switching from code view or DOM panel to AC is required to use and populate these templates and convert html elements to components that can be recognized and managed by AC, which makes using external custom themes very inefficient. As you mentioned here using external themes will never be a plug&play thing, but a single view tree with node filters would definitely make this a lot easier. You got my vote 
1 Like