Skip to main content

I’m able to access API of a page include as such:


let skuidPageInclude = skuid.$C(pageIncludeId).state.includedPageComponent.getPageAPI()

Which allows me to do things like:


skuidPageInclude.$M('SomeModel').save()

\\ or

skuidPageInclude.snippet.getSnippet('someSnippet').call()

Another approach to the above would be to publish/subscribe to events. Though, it get’s messy if I need some communication back and forward.


Therefore, I’m highly interested in using the above examples. I understand Skuid API might change, but what is the risk of doing above compared to getting component on local page, e.g.:


skuid.$C('localComponent');

\\ vs

skuidPageInclude.$C('pageIncludeComponent');

Thank you,

Lukas

Interesting approach. I wasn’t aware this was possible, though I think it might depend on what SKUID version you’re using, I can’t seem to get it to work in mine.


In scenarios where I want page includes to communicate with each other I’ve always just used the javascript “window” object to set up “global” objects that pages can use to communicate with each other. (eg. store a model in window.myModel, and all page includes on that page have access to that model via the window.myModel variable)


I’ve also made it a habit of prepending all of my model names with the pagename they are on to prevent naming conflicts between page includes, eg. “MyPageIncludePageName__ModelName”.


I’m not sure what the best approach here is, but this method has worked nicely for me in the past.

I should have mentioned in original post, but that’s for V2.


Given the issue of of having to manage names spaces for models I assume you’re working on v1.


Pre-pending namespace to Models and other resources is a nice. Also, I would suggest encapsulating code into a Module. Though, this is just a way of organizing code and everyone has their own way.
http://www.adequatelygood.com/JavaScript-Module-Pattern-In-Depth.html

Reply


View our Community Site Map

Nintex Community Sitemap
Terms & ConditionsCookie settings