# Calling methods from Sibling Components

**URL:** <https://forum.inductiveautomation.com/t/calling-methods-from-sibling-components/93330>\
**Category:** Ignition\
**Tags:** perspective\
**Created:** [July 17, 2024, 12:42pm UTC](https://forum.inductiveautomation.com/t/calling-methods-from-sibling-components/93330 "2024-07-17T12:42:47Z")\
**Posts on this page:** 1\
**Showing post:** 6

<div class="post-metadata">

**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:** [July 17, 2024, 5:50pm UTC](https://forum.inductiveautomation.com/t/calling-methods-from-sibling-components/93330/6 "2024-07-17T17:50:51Z")

</div>

> [@paul-griffith](#):
>
> cleanly versionable and maintainable

Yes, the main driver. Keeping python in resource files that are cleanly identifiable as python by external tool in source code control is part of that motivation.

> [@paul-griffith](#):
>
> would you still advocate pushing all logic into the project library?

Yes.

> [@paul-griffith](#):
>
> going all the way out to the project library

?

What do you mean by "all the way out" ? Library scripts are easily floated to be accessible while working on UI components and all kinds of gateway resources. Total win. And even if not floated, the script editors help you pick the function you need. 🤷‍♂️

> [@paul-griffith](#):
>
> nicer editing experience

Oy! The designer's plethora of event resource dialogs are **not**"nice", IMNSHO.

And further, the business/presentation boundary, in a well-organized gateway, is managed with inheritance, like the hierarchy I recommend over here:

> [@Where do/should Gateway Scripts live with respect to an inherited project structure?](https://forum.inductiveautomation.com/t/where-do-should-gateway-scripts-live-with-respect-to-an-inherited-project-structure/83460/3):
>
> Put all of the logic in project library scripts, in the "universe" project at the root of your hierarchy, if you must. Then, in leaf projects, use one-line calls to the appropriate logic from event scripts and message handlers. (I don't agree with your desire, but this is what you must do to achieve it.) I recommend you not put all your scripts (eggs) in one inheritable project (basket). I recommend a hierarchy something like this: universe ├bg\_common │├gsp │├background1 │├background2 │└we…

Well tested business logic, that is not context-specific, belongs in that "universe" project. **Shared** presentation logic belongs in "ui\_common", "perspective\_common", or "vision\_common". Project-specific presentation logic stays at the leaf, but in a project library script, to cover its possible future promotion to a shared resource.

---

_[View the full topic](https://forum.inductiveautomation.com/t/calling-methods-from-sibling-components/93330)._