TFG in include page

Barry is probably best to answer this about collapsable wrappers.  If I have an include that has a collapsible wrapper.  If I condition the first open to get the passed URL can this be done.


https://drive.google.com/file/d/0B409lhd9sYDcWW5VM0tRS0lwaUk/view

Can you put the button on the top of page include ? Set your model not to load on page load. Then the button action could be to query your model.

Hey Bill -

I watched the video a few times but unfortunately I’m not 100% clear on what you are trying to accomplish.

To answer your question in this post, yes, the CW can be conditioned on the URL parameter.  The way you would do this is on your containing page, add a URL parameter to the page include URL (e.g. phoneNumberState or whatever you’d like).  Then, in the conditions on the CW, use phoneNumberState to set the initial display mode of the wrapper.

From watching the videos though, I think what you want to do is defer the loading of the page include until the user clicks something?  Is that the case?  If so, you can use a Collapsible Wrapper on your outer page marked to initially collapsed.  Then, when the user clicks the CW, it would expand and load the page include.

Let me know if this would work or if I’m misunderstanding.

Barry, Is there a fundamental difference between haveibf a collapsible wrapper and just using Skuid render conditions.to render or not render a wrapper? Seems like the same thing? With Skuid rendering, if you put a page include in a wrapper that you choose to not render, then that page include is discarded from memory and when you render it again, it loads from scratch. Any unsaved changes are lost. Would the collapsible wrapper keep that page include in memory? That would be valuable to me in certain circumstances where I want to toggle back and forth between pages displayed as page includes but only want one to display at a time.

Hey Raymond - Great question.  The answer is it depends.  I’d have to look back at the code in closer detail but from what I remember, here is how it works:

1) The “contents” of the CW will only be loaded the first time the CW is opened.
2) After it’s been open (either immediately or deferred), the internal contents remain even after a close and re-open

If you apply conditional rendering to the wrapper itself or even a component inside of the wrapper (e.g. a page include), then things will be reloaded for the component(s) that were conditionally rendered.  Additionally, any conditional rendering applied to any component within the CW will trigger as would be normally expected.

You can think of the CW contents like a table drawer as it relates to when things get loaded in to the CW.  When a drawer closes/opened, it doesn’t reload it’s contents - they are only loaded in the first time it “opens”.

That help?


Yes, thanks. Tabsets versus rendering is a great illustration. If you put a page include in a tab in a tabset and then navigate to a different tab, but then back to the original tab, the page include is in the same state it was when you left. If you, however, use rendering on a page include, when the page include reappears, it reloads from scratch. Sounds like the collpsable wrapper is more like the Tabset than conditional rendering from what you describe. Thanks

Hey Raymond - Yep, accurate analogy with tabsets.  Of course, if you conditionally render the CW itself, then when it gets displayed again, everything will be reloaded.