ldriver
I'm new here

Can I pass data between two or more executables?

Jump to solution

I have an executable class that runs via FS_BUTTON.  And then another that runs via another FS_BUTTON on the same template.  The problem I'm facing is how can pass data between these two executable, or is this possible?

I cannot do a params.put(key, value), because when the second executable runs the values are null when retrieved, I guess this makes sense since the first executable runs and terminates.

So I was wondering if there is a way to store values in the session, and by session I mean the ContentCreator user session.  Sort of like storing values in an http session:

HttpSession session = request.getSession();

session.setAttribute(name, param);

Right now I am passing values using file system.  I could also use a database table if I had to.  But I don't like either of those ways.  If there is a better way for two executables to pass information I would rather do that.

0 Kudos
1 Solution

Accepted Solutions

Hi Leland,

I think in your scenario you can use a ClientService which is used to

  1. Let the first Executable store any kind of information
  2. Let other executables access that information

The needed steps are

  1. Define a java interface (e.g. MyClipboard) containing some kind of "clipboard" methods like "void storeInfo(SomeClass info)" and "SomeClass getInfo()". The "SomeClass" can be anything that suits your needs, and of course it can be just a String too.
  2. Create a class implementing that Interface, e.g. MyClipboardImpl
  3. Create a so called PermanentPlugin (e.g. MyPermanentPlugin) - in your case the CC version which is done by implementing the Interface WebeditPermanentPlugin. Add your MyPermanentPlugin class to the module.xml as PUBLIC component
  4. Inside the setUp method of your PermanentPlugin implementation, you create an instance of your clipboard class and register it as ClientService.

class MyPermanentPlugin implements WebeditPermanentPlugin {

     @Override

     public void setUp(BaseContext context){

          MyClipboard clipboard = new MyClipboardImpl();

          context.requireSpecialist(ClientServiceRegistryAgent.TYPE).registerClientService(MyClipboard.class, clipboard);

     }

     @Override

     public void tearDown(){}

}

FirstSpirit makes sure that the PermanentPlugin is loaded before any other plugin type upon client session start.

(Personally I find the name "PermanentPlugin" a little misleading because in most cases the plugin itself does nothing permanent but is just called once per client start per user session ;-))

In this case, the PermanentPlugin just registers an implementation (MyClipboardImpl) by its interface (MyClipboard) to be able to access that object "later".

Important: The clipboard object will be bound to the user session - so that is exactly what you need.

In your Executables you can now access that one session specific clipboard instance using the ServicesBroker​ from a broker/context (the broker is the one you get from the Executable's parameter map using the key "context")

//first Executable: Store some info

MyClipboard clipboard = broker.requireSpecialist(ServicesBroker.Type).getService(MyClipboard.class);

clipboard.storeInfo(someInfo);

//Second Executable: Get the information stored before

MyClipboard clipboard = broker.requireSpecialist(ServicesBroker.Type).getService(MyClipboard.class);

SomeClass info = clipboard.getInfo();

By the way, the "PermanentPlugin/ClientService" mechanism is a quite general one. This means it has (technically speaking) no special connection to Executables. In fact, it can be used to "connect" any types of plugins where you have some kind of client context.

Another application is to "centralize" client functionality in such a ClientService to be able to call it from different plugin types, so you don't have to implement the same functionality twice. This way it allows to implement some kind of "central controller instance".

Michael

View solution in original post

0 Kudos
5 Replies
mbergmann
Crownpeak employee

Hi Leland,

I understand that those Executables are executed on after the other, right? Or do you call the second one from the first one?

Are those buttons on the page or in a form?

What exactly do you want to achieve and why does the second Executable need information from the first one? What kind of information would you like to pass? Can you describe your use case?

Michael

0 Kudos

Thanks for the reply.  This is a tough question to answer because it's such a complex use case.  Basically the executables are executed one right after another.  And the two buttons are in fact in the same form.

So basically the first executable calls code to execute a dialog, and populate it with iFrame HTML, to extract data from an external web site.

Upon closing the dialog, using the call back functionality another executable is called to write that data to disk.

And the third executable is called from the 2nd FS_BUTTON in order to pass the FS_REFERENCE field, so the code can update it with the data.

Because I need the FS_REFERENCE object, I need the 2nd button, I can't pass FS_REFERENCE as a string to Javascript.  If there was a way to store this data in a session, like session.setAttribute, I could probably just retrieve values from there.

Or if I could pass parameters between executables, that may work as well.  Or is there another way I can execute FS_BUTTON?  Do I have to have a class that extends Executable?

0 Kudos

Hi Leland,

I think in your scenario you can use a ClientService which is used to

  1. Let the first Executable store any kind of information
  2. Let other executables access that information

The needed steps are

  1. Define a java interface (e.g. MyClipboard) containing some kind of "clipboard" methods like "void storeInfo(SomeClass info)" and "SomeClass getInfo()". The "SomeClass" can be anything that suits your needs, and of course it can be just a String too.
  2. Create a class implementing that Interface, e.g. MyClipboardImpl
  3. Create a so called PermanentPlugin (e.g. MyPermanentPlugin) - in your case the CC version which is done by implementing the Interface WebeditPermanentPlugin. Add your MyPermanentPlugin class to the module.xml as PUBLIC component
  4. Inside the setUp method of your PermanentPlugin implementation, you create an instance of your clipboard class and register it as ClientService.

class MyPermanentPlugin implements WebeditPermanentPlugin {

     @Override

     public void setUp(BaseContext context){

          MyClipboard clipboard = new MyClipboardImpl();

          context.requireSpecialist(ClientServiceRegistryAgent.TYPE).registerClientService(MyClipboard.class, clipboard);

     }

     @Override

     public void tearDown(){}

}

FirstSpirit makes sure that the PermanentPlugin is loaded before any other plugin type upon client session start.

(Personally I find the name "PermanentPlugin" a little misleading because in most cases the plugin itself does nothing permanent but is just called once per client start per user session ;-))

In this case, the PermanentPlugin just registers an implementation (MyClipboardImpl) by its interface (MyClipboard) to be able to access that object "later".

Important: The clipboard object will be bound to the user session - so that is exactly what you need.

In your Executables you can now access that one session specific clipboard instance using the ServicesBroker​ from a broker/context (the broker is the one you get from the Executable's parameter map using the key "context")

//first Executable: Store some info

MyClipboard clipboard = broker.requireSpecialist(ServicesBroker.Type).getService(MyClipboard.class);

clipboard.storeInfo(someInfo);

//Second Executable: Get the information stored before

MyClipboard clipboard = broker.requireSpecialist(ServicesBroker.Type).getService(MyClipboard.class);

SomeClass info = clipboard.getInfo();

By the way, the "PermanentPlugin/ClientService" mechanism is a quite general one. This means it has (technically speaking) no special connection to Executables. In fact, it can be used to "connect" any types of plugins where you have some kind of client context.

Another application is to "centralize" client functionality in such a ClientService to be able to call it from different plugin types, so you don't have to implement the same functionality twice. This way it allows to implement some kind of "central controller instance".

Michael

0 Kudos

Hi Leland,

any further questions? Smiley Happy Did Michael's answer help you with your problem? If yes, please mark is answer as the "right answer", so that other users can find the solution easily.

Regards,

Hannes

0 Kudos

I am still working on this issue, please leave this open for just a few more days and then I will close it out or post more comments.

0 Kudos