5
 Followers
143
 Likes

Re-use a screenaction within a screen

Frontend
On our radar

Now you need to create a public action if you want to reuse a screen action.

Would be nice to have something like "public" screen actions

Created on 11 May 2010
Comments (58)

What would be the avantage of this compared to a user-action?

The most of my screen actions are different (little bits), only getting the records and refresh the screen is used more time. Getting the records workes fine with a user action, refresh is one ajax widget.

Think that this post: Categorize user actions is more handy so everything is together.

Imagine that you have two screen actions:
  • RefreshTable - will load data from the database and populate a table record
  • DeleteRecords - will delete selected records
If after deleting selected records you want to refresh the table record widget you should call the RefreshTable action, but that is not possible.

So you end up with two options:
  • replicate logic from RefreshTable in DeleteRecordsaction
  • use only one screen action with both Delete and Refresh logic and use an input paramenter to identify what operation you intend to execute
I think that beeing able to call screen actions from other screen actions (in the same screen, of course) will be very nice.
I'll think this is more a supplement/expansion to this post: click here

not really, it's the ability of re-using screen actions like they are user-actions only defined within the screen.

which makes perfect sense in the world of c#.

the link you gave is to be able to have a more inheritance-structure with webblocks.


Thats why I called it a supplement / expansion of that post.

Ok, I find it totally 2 different things, so imho it should be seperate ideas ;) now I stop :P
Ability to call an screen action from another screen action of the same screen

Merged from 'Ability to call an action screen from another action screen of the same screen' (idea created on 2010-07-14 09:53:43 by Ana Ramalho), on 2010-07-22 10:30:04 by Pedro Oliveira
I guess this is the same as Re-use a screenaction within a screen


Merged from 'Ability to call an action screen from another action screen of the same screen' (idea created on 2010-07-14 09:53:43 by Ana Ramalho), on 2010-07-22 10:30:04 by Pedro Oliveira
I'm sure it is

Merged from 'Ability to call an action screen from another action screen of the same screen' (idea created on 2010-07-14 09:53:43 by Ana Ramalho), on 2010-07-22 10:30:04 by Pedro Oliveira
yes, it is.

Merged from 'Ability to call an action screen from another action screen of the same screen' (idea created on 2010-07-14 09:53:43 by Ana Ramalho), on 2010-07-22 10:30:04 by Pedro Oliveira
Be able to drag a web screen action into another action in the same web screen scope. Is a sort of User Action reuse, but within the scope of a Web Screen. This would save a lot of SUs and work.


Merged from 'Reuse Action in Web Screen Scope' (idea created on 2010-08-20 11:03:21 by Pedro Ávila), on 2010-08-30 15:34:47 by Paulo Tavares
I guess this is the same as http://secure.outsystems.com/wisdomofthecrowds/IdeaComment_List.aspx?IdeaId=78

Merged from 'Reuse Action in Web Screen Scope' (idea created on 2010-08-20 11:03:21 by Pedro Ávila), on 2010-08-30 15:34:47 by Paulo Tavares
Yes, it's de same thing.

Merged from 'Reuse Action in Web Screen Scope' (idea created on 2010-08-20 11:03:21 by Pedro Ávila), on 2010-08-30 15:34:47 by Paulo Tavares
Hi Joop, I was thinking exactly along the same lines. Probably because I'm thinking to procedural, or something, but it's like having local procedures, which would be great.
Merged this idea with 'Allow use Web Sreen actions in other Web Screen actions' (created on 2011-01-13 18:03:47 by Célia Corte)
Allow use Web Sreen actions in other Web Screen actions

Merged from 'Allow use Web Sreen actions in other Web Screen actions' (idea created on 2011-01-13 18:03:47 by Célia Corte), on 2011-01-24 12:04:17 by Paulo Tavares
Duplicated with http://www.outsystems.com/WisdomOfTheCrowds/IdeaComment_List.aspx?IdeaId=78 ?

Merged from 'Allow use Web Sreen actions in other Web Screen actions' (idea created on 2011-01-13 18:03:47 by Célia Corte), on 2011-01-24 12:04:17 by Paulo Tavares
Use screen actions in other screen actions. Sometimes I need repeat the same code.
Example:


Merged from 'Use screen actions in other screen actions' (idea created on 2011-01-26 09:55:56 by Célia Corte), on 2011-01-31 13:28:04 by Pedro Oliveira
You can do this right now by

1) creating an action, so that you could reuse the functionality.
2) You can add a widget_Click and call it from another web screen action.



Merged from 'Use screen actions in other screen actions' (idea created on 2011-01-26 09:55:56 by Célia Corte), on 2011-01-31 13:28:04 by Pedro Oliveira
This has already been suggested here: http://www.outsystems.com/wisdomofthecrowds/IdeaComment_List.aspx?IdeaId=78

Please endorse that one by liking it.

Merged from 'Use screen actions in other screen actions' (idea created on 2011-01-26 09:55:56 by Célia Corte), on 2011-01-31 13:28:04 by Pedro Oliveira
This should be implemented in version 7. It's a must have!

I don't like the widget_click option. Why can't we reuse a screen action?
It's like any other action but it's scope is limited to that screen. So, it should be possible to reuse on another screen action of the same screen.

Without this and because I don't see the widget_click as the right solution for this limitation, we are forced to duplicate logic (many Refresh Query and Ajax Refresh Widgets) when we could reuse the same action.

Please, implement this feature. Less code, better logic and less software units (this is just an advantage for us developers :P).
A big kick.. not being able to do this is a constant source of frustration.
It should be high on the list of things to implement.
I have  been working with Oustsystems for a week now after bootcamp and this is the first "limit" I have  run into, must have !
Agreed and endorsed!
Hi guys. Take a look at this forge component, it enables screen action reusability:

https://www.outsystems.com/forge/component/597/event-system/
Agreed 2 weeks in and frustrated with this and copy and pasting

Hi all,

We have delivered this functionality in OutSystems 10 for Mobile Apps. So at this point, we will leave it as WIP but I'd like to hear from you guys what you think are the relevant use cases for such functionality in a Web App.

Thanks for your feedback!

I don't have any, just doesn't make sense in a web application so curious also.

If you would be able to use a screen action through the whole eSpace things can get a real mess.

Kind regards,
Evert

You have a use case posted here on 11 May 2010. I'm talking about reusing a screen action within other screen actions in the same screen (not reusing a screen action of another screen, like it has also been  requested here due to merging ideas).


Why do you think that this is applicable only to Mobile Apps and not Web Apps?

Hi Fernando,

We don't think that this is only applicable in Mobile, but we want to be sure to get the right use cases.

Thanks for your feedback!

I would use these types of actions to have a local action that can reuse the screen variables, and doesn't "pollute" the global name space of the eSpace. Current I typically have a folder in the action tab called "ScreenActions", and name three actions ScreenName_MyAction, but that's far from ideal.

The downside is that it perhaps stimulates putting all the business logic in the screen as well, which is of course bad practice. But nevertheless I would welcome it in screen actions, as it's proven pretty usable in mobile apps.

Note that I think this idea has been wrongly merged, as I'd be very much opposed to being able to cross-call screen actions (something I think isn't possible technically anyway, given the local state).

One use case is to refresh a data source that is bound to some widget.

Example: have a table records listing the result of a web service. The web service call must be placed in the preparation. But, if you want a button to refresh the table, you would have to repeat the same call. Refactoring the web service call into a screen action would isolate it, and the screen action could be called both in the preparation and in the refresh action. Note that this problem is already solved for aggregates, but not for other datasources.


Another use case is when the same transaction could happen in multiple screen actions.

Example: an edit screen which has a button "create" and another button "create & new". Both of them creates a new record on the database, but one of them redirects away from the edit screen, and the other refreshes the edit screen with an empty record. Right now, you have a solution which is to add a boolean input to the screen action and controlling the flow of execution with if nodes. In my opinion, by doing that, you are mixing two use cases into the same screen action, which could be fine if you only have to deal with two use cases in the same screen action, but would become unmanageable if there are more. Another option is to isolate the common parts in user actions, but that comes with its own restrictions, because you are not allowed to refresh widgets nor update validation messages. The ideal solution would be to have a screen action for "create", and another screen action for "create & new", and both could reuse logic from a third screen action.

Imagine you have a button called "Save" and another button called "Submit". 

The submit button needs to save form before sending it to a webservice. With this option we could have a screen action that saves the data and call it on both.

If we use a User Action, we would have to send to it all the inputs and that could be a big mess if we have a huge number of inputs.

I know that this ideia is tagged as WIP, but while the feature is not implemented, i´ve created an extension that allows the reuse of screen actions:

https://www.outsystems.com/forge/component/3558/screen-action/

It uses reflection to invoke the screen actions by their name.

I'm aware that this is not the ideal solution, since it doesn't take advantage of the auto refactoring of the platform, but i believe it is the best way if compare to other available ways to do it, since it does't require unnecessary network traffic.

Once this feature got into the platform, the necessary adjustments would by to replace the component usage by the native functionality.

PS: Currently the component does not support actions with input parameters.

When we want to re-use code, definitely within things like a Save or Submit, we have occasionally in desperation used parameters to the screen action and thrown extra Ifs around, but it can really mess the place up. I'd use something like this in a heartbeat :)

Even if all they did on the implementation side behind the scenes was emit the code every time it was called, it would be worth it.

That would be a different option on Extract To Action as well (Extract To Common/Shared/Screen Action/Action Part/Actionlet?) and you could pull out things that currently say "You are selecting elements that cannot be extracted: Refresh Data, Ajax Refresh"

Merged this idea with 'Call Screen Action from another Screen Action' (created on 14 May 2014 08:02:46 by Chris_)
Much better if we can call multiple screen action in one button's/link's destination screen action.

This comment was:
- originally posted on idea 'Call Screen Action from another Screen Action' (created on 14 May 2014 by Chris_)
- merged to idea 'Re-use a screenaction within a screen' on 06 Sep 2018 16:15:34 by Vasco Pessanha
I'm pretty sure we've seen this idea before, but I can't find it right now.

This comment was:
- originally posted on idea 'Call Screen Action from another Screen Action' (created on 14 May 2014 by Chris_)
- merged to idea 'Re-use a screenaction within a screen' on 06 Sep 2018 16:15:34 by Vasco Pessanha
Same here. It's been suggested at least once before.

J.Ja


This comment was:
- originally posted on idea 'Call Screen Action from another Screen Action' (created on 14 May 2014 by Chris_)
- merged to idea 'Re-use a screenaction within a screen' on 06 Sep 2018 16:15:34 by Vasco Pessanha
Thanks, I hope Outsystems team will implement this.

This comment was:
- originally posted on idea 'Call Screen Action from another Screen Action' (created on 14 May 2014 by Chris_)
- merged to idea 'Re-use a screenaction within a screen' on 06 Sep 2018 16:15:34 by Vasco Pessanha
Hi,

Indeed, this is similar to this one and this one.
They should be merged to sume up the likes :)

Cheers,
JA

This comment was:
- originally posted on idea 'Call Screen Action from another Screen Action' (created on 14 May 2014 by Chris_)
- merged to idea 'Re-use a screenaction within a screen' on 06 Sep 2018 16:15:34 by Vasco Pessanha
The maintainability would be horror.

if you enter screenaction 1, you refresh a part
if you enter screenaction2, you refresh a part.
so, how do you tell, what part is going to be refreshed first?
what happens, then, does it trigger something else which ends up clicking an action in jquery?

or do you get simply 2 refreshes of a container, which you don;t want.
so you have to implement logic to check if it comes from screen-action1, or from a button.


In the other ideas.
create a plain action for reusablity parts.
and refresh-query is the most commonly used part, which Outsystems already implemented nicely.


so, imho, just no :)



This comment was:
- originally posted on idea 'Call Screen Action from another Screen Action' (created on 14 May 2014 by Chris_)
- merged to idea 'Re-use a screenaction within a screen' on 06 Sep 2018 16:15:34 by Vasco Pessanha
Hi Forum Users!

I have asked myself this question recently and come up with a solution.

I, personally, believe that being able to call screen actions as if they were Private Methods gives the power of functionalising Web Block and Web Screen specific logic within the Web Block/Web Screen.

The way to do this is by using Event System (on forge). It has an action called InvokeNotifyWidget which calls the OnNotify on a Widget using the widget's RuntimeId (using reflection I think). Unlike the normal NotifyWidget, this one runs synchronously (an added bonus).

Using this feature, just add a Web Block that has nothing but a dummy call to Notify Widget (put an IF in Preparation with condition set to False that leads to NotifyWidget on its True branch). This means you can now set a Screen Action as the OnNotify in a consuming Web Block/Web Screen.
Next, set the "Name" property of this empty web block to something in the consumer (for this example "FuncTrigger") and then call InvokeNotifyWidget in your origin screen action and pass in the empty web block's id ("FuncTrigger.Id"). The OnNotify handler will then be called, effectively calling that screen action from the origin screen action.


This comment was:
- originally posted on idea 'Call Screen Action from another Screen Action' (created on 14 May 2014 by Chris_)
- merged to idea 'Re-use a screenaction within a screen' on 06 Sep 2018 16:15:34 by Vasco Pessanha
It's too much back-and-forth to the client. It's basically doing two post-backs, one for the original call, and then a second for the REAL call. So viewstate goes to the client and back to the server twice, user sees two post backs occur, etc.

J.Ja


This comment was:
- originally posted on idea 'Call Screen Action from another Screen Action' (created on 14 May 2014 by Chris_)
- merged to idea 'Re-use a screenaction within a screen' on 06 Sep 2018 16:15:34 by Vasco Pessanha
Justin James, it doesn't! At least if you're using Event System, which invokes the OnNotify via reflection (Sea Millo got it right), therefore not requiring two postbacks.

This comment was:
- originally posted on idea 'Call Screen Action from another Screen Action' (created on 14 May 2014 by Chris_)
- merged to idea 'Re-use a screenaction within a screen' on 06 Sep 2018 16:15:34 by Vasco Pessanha
Ah, good to know!

J.Ja


This comment was:
- originally posted on idea 'Call Screen Action from another Screen Action' (created on 14 May 2014 by Chris_)
- merged to idea 'Re-use a screenaction within a screen' on 06 Sep 2018 16:15:34 by Vasco Pessanha
+1
I would like calling screen actions from screen actions to be implemented!
So strange this request has so little votes, i was sure there would be a huge topic about this when i ran into this problem.

The Event System in the forge is pratically the same then a for the Widget Click (which is a workaround that requires extra work)
Incorporating all functionality in the RefreshTable screenaction seems very dirty to me, and is also a workaround.
While i do understand the problematics, the multiple callbacks possibly being disruptive to the client, this is not in all situations the case.
They should allow it at least for those situations. (detect them, otherwise warn or block)

Also how hard is it for Outsystems to design the functionality of the screenactions mechanic so that it aggregates callbacks thus preventing back-and-forth's?


This comment was:
- originally posted on idea 'Call Screen Action from another Screen Action' (created on 14 May 2014 by Chris_)
- merged to idea 'Re-use a screenaction within a screen' on 06 Sep 2018 16:15:34 by Vasco Pessanha
It would be useful to have a way of refreshing/re-executing actions in a Screen Action context (similar to Refresh Data ).

Example:

The source of a Table Records called MyTableRecords is a list returned by an action called MyAction instead of an aggregate or adv. query directly.

Currently, if we desire to get an updated list from MyAction, in the RefreshMyTableRecords action we must call MyAction again and assign the newly returned list to the previous MyAction in the preparation.

This is messy and could be simplified with a Refresh Action feature.


Merged from 'Refresh Actions' (idea created on 2016-06-30 15:14:27 by Caio Santana), on 2016-07-01 09:07:08 by Goncalo Borrega

This comment was:
- originally posted on idea 'Call Screen Action from another Screen Action' (created on 14 May 2014 by Chris_)
- merged to idea 'Re-use a screenaction within a screen' on 06 Sep 2018 16:15:34 by Vasco Pessanha
I see my idea has been merged to this one but I don't think they were related. I wished for a "Refresh Action" feature, and it would apply only to Actions, not Screen Actions.

Also I don't see how that could be achieved by calling Screen Actions recursively.


This comment was:
- originally posted on idea 'Call Screen Action from another Screen Action' (created on 14 May 2014 by Chris_)
- merged to idea 'Re-use a screenaction within a screen' on 06 Sep 2018 16:15:34 by Vasco Pessanha

Sometimes I need to reuse same code inside the screen. One difference between this idea and function is that I need to reuse the elements and page context. Another is that I could transfer the flow avoiding code duplication



Merged from 'create a command to reuse screen actions' (idea created on 2016-07-19 22:04:24 by Luciano Schiavo), on 2016-08-02 11:09:44 by Goncalo Borrega

This comment was:
- originally posted on idea 'Call Screen Action from another Screen Action' (created on 14 May 2014 by Chris_)
- merged to idea 'Re-use a screenaction within a screen' on 06 Sep 2018 16:15:34 by Vasco Pessanha

Can't you create a Action and reuse the same logic in multiple screens.



Merged from 'create a command to reuse screen actions' (idea created on 2016-07-19 22:04:24 by Luciano Schiavo), on 2016-08-02 11:09:44 by Goncalo Borrega

This comment was:
- originally posted on idea 'Call Screen Action from another Screen Action' (created on 14 May 2014 by Chris_)
- merged to idea 'Re-use a screenaction within a screen' on 06 Sep 2018 16:15:34 by Vasco Pessanha

Luciano, 

While not supported by OutSystems, a great forge component for achieving this is the Event System: http://www.outsystems.com/forge/component/597/Event+System/

It allows you to make event handlers and point them to screen actions. You can then trigger an event handler from another screen action, making your screen actions reusable.

Justin



Merged from 'create a command to reuse screen actions' (idea created on 2016-07-19 22:04:24 by Luciano Schiavo), on 2016-08-02 11:09:44 by Goncalo Borrega

This comment was:
- originally posted on idea 'Call Screen Action from another Screen Action' (created on 14 May 2014 by Chris_)
- merged to idea 'Re-use a screenaction within a screen' on 06 Sep 2018 16:15:34 by Vasco Pessanha
Merged this idea with 'Refresh Actions' (created on 2016-06-30 15:14:27 by Caio Santana)

This comment was:
- originally posted on idea 'Call Screen Action from another Screen Action' (created on 14 May 2014 by Chris_)
- merged to idea 'Re-use a screenaction within a screen' on 06 Sep 2018 16:15:34 by Vasco Pessanha

We had the same problem, but solved it by reusing the same screen action and adding a parameter for the different functionality required.



This comment was:
- originally posted on idea 'Call Screen Action from another Screen Action' (created on 14 May 2014 by Chris_)
- merged to idea 'Re-use a screenaction within a screen' on 06 Sep 2018 16:15:34 by Vasco Pessanha

It's utterly ridiculous that this can't be done, and it leads to massive duplication of code.


Someone at outsystems need to sort this out.  If someone there is blocking the addition of this basic fundamental programming concept, someone in charge there needs to move them sideways into another role.



This comment was:
- originally posted on idea 'Call Screen Action from another Screen Action' (created on 14 May 2014 by Chris_)
- merged to idea 'Re-use a screenaction within a screen' on 06 Sep 2018 16:15:34 by Vasco Pessanha

To add:  We are using Matheus Medeiros's excelent Screen Action extension to get around this.


Can someone at OutSystems please look at this extension and implement it as built-in functionality, ideally with the ability to include parameters.  Seriously, guys this is like what... a few hours work?


In fact, I could list a handful of extensions where OutSystems should have imported the functionality to the product... Text, String, FeedbackMessage, CSVUtil, EventSystem... end users shouldn't have to be dependent on third party extensions for basic functionality.


All credit to the guys that wrote these extensions by the way... maybe give them some branded goodies or a months free licence?

Nathan -


Writing good Forge components is HARD WORK. A lot of them are internal use stuff which someone put the effort into making useful for everyone, documenting, putting together sample code, etc. AND asking permission to post publicly. Very few projects get assistance from anyone else, they are one-person efforts for the most part.

If you like someone's component a lot, I'd suggest reaching out to them directly and doing something nice for them yourself. As someone who has a lot of extensions, components, etc. in the Forge, some of which are super duper important for a lot of customers... yet no one *once* has every said, "wow, that saved me a week, can I send you an Amazon gift certificate or PayPal you some $$$ or something?" I've received less than 5 direct "thanks buddy!" despite the tens of thousands of downloads of my components. At best, you get selected for MVP status and there's some perks and swag and recognition and so on there.

But yeah, suggest that if Matheus' component is blowing your socks off, that you step up to the plate and thank them and maybe hit them up with a gift certificate or something.

J.Ja

views
2570
Followers
5