Hey everyone, new YouTube tutorial is up where I walk through how to set up a Tulip app step that might be repeated in many apps as a centralized, separate application. The video goes over the most basic example possible, but the concept can be extrapolated in many ways to start thinking of your Tulip apps as a connected web, instead of many separate apps. The entire video is almost entirely done in one cut, which I think is helpful to learn some of the small details that go on in a Tulip app building process. Please let me know if you have any suggestions for future content
I can see how this is helpful because now you only have to manage/update your defect log in one place, even if you use it in many apps. The con here being having to create that abstract table to manage sharing information across apps.
The filpside of this, putting the defect log step in every app where defects need to be reported, keeps everything in one flow for the user, and they don’t need to be interrupted and cut into a different function. However, if someone wants to change something within the defect logging logic, they will now need to update it in every application where the module is used.
I hope Tulip will eventually provide native support for running other apps “on top” of a main app. This would make development much more efficient and less convoluted.
Late to this thread - but this is something that those of us coming from an automation/large scale MES background are used to - having class items that can be instantiated in multiple places and the master class definition can be updated in a single place. This is normal for self contained objects but being able to instantiate within an app (in Tulips case) would be the equivalent of what DeltaV calls a composite. This has the added flexibility of being able to choose whether it is linked to the master or not - i.e. selectable updating. Within Syncade the equivalent of a step in a Tulip app can be stored in a library, and instantiated in a workflow (sort of equivalent to an App). The same is then true - the master class for the step can be updated and all instances within workflows get the change. My concern with the above approach in this post - although we are using something very similar for longer running EBR apps, would be that for something as oft called as recording a defect there may be a user experience/performance impact with this back and forth transition between apps? (I would vote for a class based step functionality within Tulip!)
@andybmac With the addition of the “Go to First Step of App By Name” functionality this feature has actually gotten pretty close to being the same performance as if the steps were natively inside one app. Gotta give credit to Tulip engineering here this opens up a lot of doors like you are discussing!
