Hi
I stumbled again today upon the known problem of SplitPanel cannot be docked programmatically again today.
I see in the issue was scheduled for 7.2 and still open, what’s the status ?
Missing ability to dock programmatically needs the developer to spend much more time finding another solution where it should be a no-brainer.
And there is more. There is a very interesting feature of SplitPanel
: it computes the proper split position depending on calculated width of internal components. Which makes workarounds much less desirable, let’s see an example.
See following code extracted from a screen helping user to match two objects displayed in two screen fragments of different widths.
<split id="splitPanel" orientation="horizontal">
<scrollBox id="leftScroll" height="100%" width="100%" spacing="true">
<groupBox id="adBox" caption="Annonce">
<fragment id="adFragment" screen="svp_CarSearchAdFragment"/>
</groupBox>
</scrollBox>
<scrollBox id="rightScroll" height="100%" width="100%" spacing="true">
<vbox id="opportunityBox" width="100%">
<fragment id="opportunityFragment" screen="svp_OpportunityFragment"/>
</vbox>
</scrollBox>
</split>
You will get following display.
In my project, sometimes there is nothing in the right panel (left object not yet associated to a right object). So in that case I would like to dock the right panel in the beforeShow
event of the screen, because the fragment will be empty. Not possible.
An alternative that I tried is following the rationale "let’s use the split panel to compute panels widths, i.e define his own split position, then store it as the initial position, then hide the right panel.
It works, but the screen can be reloaded and at this point the right object can be defined. So the code should set the right panel visible again. Cool, I stored the initial position, so lets just setting it back.
New problem: you can store the initial position with such code, for instance in the afterShow
event.
float initialSplitPosition = splitPanel.getSplitPosition()
SizeUnit initialSplitPositionSizeUnit = splitPanel.getSplitPositionSizeUnit()
First question I asked to myself here, what is the initial (by default) SizeUnit used by the splitPanel when added to UI ? Percentage or Pixel ? That would be handy to find the info in the documentation. Or I have to launch an app and debug just to get the info, which I get to do quite some times with CUBA when the documentation is lacking (it happens), or lacking precision (it happens). Debugging an app is very time-consuming and it interrupts code writing, which is not productive.
But let’s continue. So when the screen is reloaded and there is actually a right object, right panel should become visible, it should have been as simple as:
splitPanel.setSplitPosition(initialSplitPosition, initialSplitPositionSizeUnit)
But the setSplitPosition
method takes an int
for the position parameter, not a float
. What should I do ? Debug to see what’s happening ? Again no, I’m writing code.
So I falled back to use the following code. My eyes were saying 1/3 to 2/3 ratio, that was ok. Code finished, let’s move to next item. But this is not future-proof : when fragments get modified and change size, you need to tune again the expand ratio.
<hbox id="mainBox" width="100%" expand="rightScroll">
<scrollBox id="leftScroll" height="100%" width="100%" spacing="true" box.expandRatio="0.33">
<groupBox id="adBox" caption="Annonce">
<fragment id="adFragment" screen="svp_CarSearchAdFragment"/>
</groupBox>
</scrollBox>
<scrollBox id="rightScroll" height="100%" width="100%" spacing="true" box.expandRatio="0.67" >
<vbox id="opportunityBox" width="100%">
<fragment id="opportunityFragment" screen="svp_OpportunityFragment"/>
</vbox>
</scrollBox>
</hbox>
All of that because we miss just one method in SplitPanel
.
splitPanel.setDocked(false);
Et voila ! Especially when this method implementation should be a no brainer, just a call to existing GWT code.
And you know what ? I’m still using CUBA 7.2 . So no chance to have it before migrating to JMix. But at least let me know if this method exists in JMix (if so it could have been mentionned in the issue)
Regards
Michael