Skip to main content

I have a page include that renders a simple Skuid page (with a single field editor) in a tab in a popup. It renders as expected, but it moves the popup downwards, then does magical things to the other tabs in the tabset. It seems to set their CSS height to a very small value, which whilst magical, isn’t quite what we’re after.

See the black magic in action: https://www.dropbox.com/s/oanw7m5c068uzpi/PageIncludeMagic.mp4?dl=0

Any idea what might be going on here?


My guess for the other tabs’ disappearing contents is that there are Models in the Page Include with the same name as Model(s) in the main page — so what’s happening is that when the Page Include is loading, it’s overriding the JavaScript Models in the main page, so that when you open the page back up, the Models expected have been messed up.


You’re on the money, Zach. The included page had a model of the same name as one in the main page. Changing that removed the issue of the collapsing sections. The only (much smaller) issue remaining is that when the page include renders in the popup, the popup jumps about 100px down the page. If you close the popup, reopen and go to the subtab with the include, it does the same every time. Is it trying to centre the popup vertically in the screen or something? Is there an easy fix?


And while we’re on the subject of page includes in popups: another question.

In this example, my popup has three tabs, with the page include in the third tab that has a simple field editor in it. I have a single save/cancel button in a page title in the popup, but that doesn’t seem to “know” about the page include, in that the buttons don’t light up when changes are made in the page include fields. Is it possible to wire up that behaviour, so that the single save/cancel can also save the page include’s fields?


Yes that’s what it’s doing — once content is loaded into the popup, Skuid is re-centering the popup. Typically this is desired behavior because the popup has tall content and you often otherwise would have the top half of your screen empty with a popup running off the page in the bottom half… not ideal behavior.

We could potentially add an option on Popups to disable this behavior, something like “Re-center contents when child page Includes are loaded”.


Glenn,  that is one of the downsides of page includes is that the over-arching save and cancel doesn’t know about those models and can’t listen for changes or make save actions there.  We don’t have a workaround for this scenario at this point.  If you want to save data in that included page - you need to expose the save and cancel button on the field editor. 


Actually there is one way to get the single save/cancel to know about Models in the Page Include — via the Page XML Editor, add those Models’ names through to the list of that the Save/Cancel button is listening for changes on. Go into your Page XML Editor, find the in your Page Title, and it should have a child node. Add a ModelName corresponding to each model in your Page Include that you want the Save/Cancel to “know about”.


I like that idea, but I can’t get it working. Does this look OK? I’ve just pasted the section of XML from the start of the popup to the end of the page title. The model in my page insert is called InsertClient.


<popup title="" width="900"> <components> <pagetitle model="Client"> <maintitle>&amp;lt;span class="popupheader"&amp;gt;View/Edit Client Details&amp;lt;/span&amp;gt;</maintitle> <actions> <action type="savecancel" window="self"> <models> <model>Client</model> <model>InsertClient</model> </models> </action> </actions> </pagetitle>


Glenn.  This usually never happens, but in this case Zach was wrong.  I had tried the suggestion he provided before and gotten the negative results.  We tried again this week and confirmed that it will not work.  When you hack the XML with the model names that are provided by the included page - they don’t get listened to, or saved by the overarching page.  

So you are back to needing save and cancel buttons on the included sections of your page.   Sorry. 


Thanks Rob, good to know I wasn’t going nuts.


Reply