# Getting PageModel from component delegate **URL:** \ **Category:** Module Development\ **Tags:** perspective\ **Created:** [October 29, 2024, 4:23pm UTC](https://forum.inductiveautomation.com/t/getting-pagemodel-from-component-delegate/97909 "2024-10-29T16:23:15Z")\ **Posts on this page:** 9\ **Page:** 1
**Author:** ![bmusson](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/bmusson/32/87530_2.png) [@bmusson](https://forum.inductiveautomation.com/u/bmusson)\ **Post date:** [October 29, 2024, 4:23pm UTC](https://forum.inductiveautomation.com/t/getting-pagemodel-from-component-delegate/97909/1 "2024-10-29T16:23:15Z")
In a component model delegate, how safe is: ```kotlin val pageModel = component.page as PageModel ``` ? Am I correct in assuming it’ll either be a `PageModel` or a `DesignerPageModel`? ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [October 29, 2024, 4:32pm UTC](https://forum.inductiveautomation.com/t/getting-pagemodel-from-component-delegate/97909/2 "2024-10-29T16:32:55Z")
`ComponentModel` doesn't have `page`, as shown here: > **[ComponentModel](https://files.inductiveautomation.com/sdk/javadoc/ignition81/8.1.38/com/inductiveautomation/perspective/gateway/model/ComponentModel.html)** > > declaration: package: com.inductiveautomation.perspective.gateway.model, class: ComponentModel And the `ViewModel`'s `getPage()` method returns a `Page` Interface. Which isn't assured to be `PageModel`. I'd test it. ---
**Author:** ![paul-griffith](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/paul-griffith/32/37249_2.png) [@paul-griffith](https://forum.inductiveautomation.com/u/paul-griffith)\ **Post date:** [October 29, 2024, 5:00pm UTC](https://forum.inductiveautomation.com/t/getting-pagemodel-from-component-delegate/97909/3 "2024-10-29T17:00:28Z")
`PerspectiveElement` defines `getPage(): Page?`. What do you need from `PageModel` that you don't get from `Page`? I can tell you that _right now_ there's only `PageModel` and `DesignerPageModel`, and the latter directly extends the former, and I don't _imagine_ that changing anytime soon, but 🤷‍♂️ ---
**Author:** ![bmusson](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/bmusson/32/87530_2.png) [@bmusson](https://forum.inductiveautomation.com/u/bmusson)\ **Post date:** [October 29, 2024, 6:51pm UTC](https://forum.inductiveautomation.com/t/getting-pagemodel-from-component-delegate/97909/4 "2024-10-29T18:51:10Z")
> [@paul-griffith](#): > > What do you need from `PageModel` that you don't get from `Page`? I want to tell a page to pre-emptively start a view from within my ComponentModelDelegate, instead of waiting for the client to send a `view-start` message. That way the view is already ready to go (with starting parameters) by the time the client requests it. So basically I want to poke at the [receive method](https://files.inductiveautomation.com/sdk/javadoc/ignition81/8.1.38-rc1/com/inductiveautomation/perspective/gateway/model/PageModel.html#receive(com.inductiveautomation.perspective.gateway.model.MessageChannel,java.lang.String,java.io.Reader)) and the [Handlers class](https://files.inductiveautomation.com/sdk/javadoc/ignition81/8.1.38-rc1/com/inductiveautomation/perspective/gateway/model/PageModel.Handlers.html). ---
**Author:** ![bmusson](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/bmusson/32/87530_2.png) [@bmusson](https://forum.inductiveautomation.com/u/bmusson)\ **Post date:** [October 29, 2024, 7:33pm UTC](https://forum.inductiveautomation.com/t/getting-pagemodel-from-component-delegate/97909/5 "2024-10-29T19:33:03Z")
I think it's got legs... ---
**Author:** ![bmusson](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/bmusson/32/87530_2.png) [@bmusson](https://forum.inductiveautomation.com/u/bmusson)\ **Post date:** [October 31, 2024, 12:19pm UTC](https://forum.inductiveautomation.com/t/getting-pagemodel-from-component-delegate/97909/6 "2024-10-31T12:19:44Z")
It doesn't seem to cause any problems with deeply nested views (as long as you do a good job of keeping track of your `mountPaths`, lol). In this example, an input parameter (random UUID) is being passed down from the root into 6 nested views (Nesting 1 - 5, + the card at the end). ---
**Author:** ![bmusson](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/bmusson/32/87530_2.png) [@bmusson](https://forum.inductiveautomation.com/u/bmusson)\ **Post date:** [November 7, 2024, 11:46pm UTC](https://forum.inductiveautomation.com/t/getting-pagemodel-from-component-delegate/97909/7 "2024-11-07T23:46:50Z")
![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/f/b/fbac16e3960d76caa22857531a0f42af47b14353.jpeg) ### _The Magic_ 1. View instances properties are linked together through gateway-side subscriptions. The native flex repeater uses the client stores to pass parameters around, which is the lag you see in the demo (each additional layer requires an additional ping-pong). The `FlexRepeater+` requires no back and forth. 2. Views are preemptively started on the gateway, then joined by the client. This required silencing the `view-start` message sent by the `viewStore` on startup, and replacing it with a new delegate-handled `view-join` message that doesn't try and restart running views. Seems stable, but I really have no idea what larger implications this approach has. Please help me break it. [Embr-Periscope-0.3.0.modl](https://forum.inductiveautomation.com/uploads/short-url/pXr3qLMgXnSNzuDUDcply6HwISn.modl) (1.9 MB) [https://github.com/mussonindustrial/embr/tree/feat/periscope-flexrepeater-serversideloading/modules/periscope](https://github.com/mussonindustrial/embr/tree/feat/periscope-flexrepeater-serversideloading/modules/periscope) ---
**Author:** ![Samuel\_Sueur](https://avatars.discourse-cdn.com/v4/letter/s/e36b37/32.png) [@Samuel\_Sueur](https://forum.inductiveautomation.com/u/Samuel_Sueur)\ **Post date:** [November 8, 2024, 8:27am UTC](https://forum.inductiveautomation.com/t/getting-pagemodel-from-component-delegate/97909/8 "2024-11-08T08:27:29Z")
I think this is an amazing improvement. I'm unfortunately not familiar enough with everything module-related, but you mention that everything happens on the gateway. Does that mean there is a higher load on the gateway than without using your module or not ? Thanks ! ---
**Author:** ![bmusson](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/bmusson/32/87530_2.png) [@bmusson](https://forum.inductiveautomation.com/u/bmusson)\ **Post date:** [November 8, 2024, 12:54pm UTC](https://forum.inductiveautomation.com/t/getting-pagemodel-from-component-delegate/97909/9 "2024-11-08T12:54:13Z")
Yes, the gateway does have to drive everything. But ultimately I’d argue this approach is not doing much extra work, this just changes _when_ the work is done. Like you’re always going to need to start/load views, and you’re always going to need to respond to property sync messages. This module just does that work preemptively. That being said, right now this component 100% does more work than it needs to. It’s not very smart about when it recreates subscriptions and when it writes into the child view params tree, basically anytime the instances prop changes _ALL_ children are updated. But there’s no reason it has to be this way, I just need time to make it suck less (make it work, then make it good). Edit: Also just realized there’s absolutely no care given to whether a views parameters are configured as inputs or outputs 🤷🏻‍♂️