I did break apart the website and comparison-part and create a nodeType to collect them together only in frontEnd. But at the end I guess there are all of them in the content structure tree (didn’t count them one by one):
1 day later,
- the less-many-node-test-website got 1’013 in 6 parts.
- the test-with-many-elements 1’834 in 8 parts.
Yes, thats also the tendency in my suspicion . I torment still myself, and think, how could I simplify it???
The approach in demoSite or neos in general with grids, is for lots of websites OK - for sure. But what’s about websites within columns don’t behavior only different in medium (col-sm-6, or col-sm-3)? Than it looks like an oversimplification. Unfortunately I can’t design a useful and more flexible derivation out of them – Because:
####more flexible task?
What about the situation if the first col have to be 12 in small, 4 in medium and 6 in large, and simultaneously «col 2,3,4,5» has to be different behavior depend on viewport-width (3 small, 4 medium, 2 large). Or some other a more complex requirements.
So I guess:
In this complex case and with your recommendation for more specific nodeTypes, I have to create a nodetype with fix 5 columns, and hardcoded classes, because of to many variants. All of them push in one dropDown select-box would neither simple for template-layout creation nor self-explanatory in inspector.
And the same website has at least 5 totally different grid-divisions. So I would need to create for each one a particular nodeType, but this will mess-up my «create new …»-popup and it would be really hard to pic the particular nodeType.
But maybe I try it in future to have a comparison.
If you or someone-else have a good idea to simplify, I would be thrilled!
For this website I create a foundation-6 approach on dimaip’s f5-grid. It is perfect for flexibility, but at the end, there are long pauses while Aloha is building «?what ever?». Maybe because of this approach? I don’t know.
Maybe Aloha is too lovely and says «hello» to everyone
Strangely the backend-website with all the stuff for Aloha (in dev-tools the source-Code has all the additionally Divs filled full with Aloha-stuff) appears immediately. But then there is a extremely long waiting-time for (I think Inspector). But I don’t know why, if Inspector would only have connection with the current selected element?
The structure-panel do lazy-loading for next deeper grid-nesting. So I guess this should not go nuts.
Big question mark in my head?!
####What I’m doing and why
Sorry for all the read-stuff, but you are asking for … I don’t like to «not really saying»!
In this particular website I have to show a comparsion. This should use in grid for responsive design.
In large the layout should be like in picture further down. In small, the group-headers (Fringile, Trisique …, Cras …) should show 12 column, but the first column in sub-group (medium-grey) should go to 12, the others 3. In medium quite the same, with a smooth split between col 3 and 4.
If the user click on Group-Header, the sub-items will shown. If the user click on sub-line, the «additional Info» will appear (violet bordered: Ipsum Magna Pe…).
at the end:
for each Group-header: 4 nodeElements ( X 6 other groups) = 24 nodeElements
for each comparsion-line: 19 nodeElements (X 10 comparsion-items on average X 6 groups) 1140 nodeElements
A few of the «additional Info» has also images and links grouped in grid (= more nodeElements).
And then, all the other website-Layout-Elements = more nodeTypes/nodeElements
It rocks in frontEnd-Website. All the challenges are well resolved and the ui works smoothly.
I would like…
to reduce the nodeElements, and change the approach. But with the default-neos grid, I have problem to do not oversimplification with big draw-backs for layout and responsiveness - I guess.
But I’m more than interested in, if someone found a cool genius solution!
Elements that don’t even have inline editable properties == HOT-POINT ?
Thats also a point, that I would like to optimize. Because of row- and column-nodeTypes have no inline-editing inside. So I could delete the «inlineEditable: TRUE» or set it on FALSE. But for some reason, if I delete the Line 16 or set on «FALSE» , in backend > this edit-area is hurtling down further and the scroll area is growing immediately gigantic.
Maybe I have to set an other value? Or how I could command Aloha, don’t say hello to Elements without «inline-editable-values»?
Hope this really saying: how, what and why
Would be great if we could find some better solution for simplification in backend-structure and for Aloha less go berserk!