FWD » Core Development » User Interface

Greg, we need this for PASOE to be complete.

Constantin Asofiei wrote:

Greg, we need this for PASOE to be complete.

Actually the customer project I've tested can work without it. Did you find some blockers?

Is it needed for existing customers?

I know one customer that uses PASOE and has a reporting processing that does use heavy redirected terminal. But that reporting process is a manually run batch session, it doesn't run under PASOE.

If existing customer's don't have this use case then I'd like to defer this work.

If the UI (widgets) is not a hard requirement for #8661, then we can postpone it.

But I'm worried about features which are still 'on the client', like MESSAGE.

It is a fair concern. We should at least test the UI functionality in OE (PASOE mode) to confirm that it all works. I say this because they might also have had quite a bit of process-wide logic in their UI implementation which they may not have wanted to fixup for a thread-safe version. It might be low odds but I'd like to confirm that in OE using redirected UI functionality actually works in PASOE mode. If it doesn't work there then we don't have to add it, we could just fail the same way.

About PASOE:

PASOE implements multiple 4GL sessions in each agent process, each of those 4GL sessions is on its own thread. In OE, PASOE allows running multiple such multi-threaded agents. In FWD, we currently only support a single agent. Regardless, the tricky part here is that all the UI usage would be done in the server process, needing to be properly separated on different contexts.

The current design for this (being implemented in #8661) is fully server side and there is NO FWD CLIENT for those PASOE contexts/sessions.

From Hynek:

Do you anticipate to identify the individual UI resources (client calls, UI features, etc.) used in SXe and somehow make them work in the server context, or a broader solution to allow to run a client-session with any UI feature in the server process?

We will do the minimum necessary at this point. If possible to just handle a subset of the UI, we will certainly do that.

From Hynek:

It sounds like you are more up to a parallel albeit limited UI implementation on the server.

I was thinking about introducing a client session and a UI context to the server. I.e. the existing design would be preserved, just the UI context would be moved to the server. I know this would be still pretty heavy, but the effort would be relatively low.

Yes, I think this is the approach. These sessions are batch/headless sessions so it isn't about full interactive code.

Constantin, do we have a comprehensive list of UI statements or UI features used on the server side?

If the list is small (for now I am only aware of MESSAGE), then we can modify the execution flow in LogicalTerminal not to forward such a call to ThinClient, but handle it explicitely (output to the logs for example). This will make the runtime leaner, no need to bring in the complex set of class dependencies (albeit limited) starting with ThinClient.

Hynek Cihlar wrote:

Constantin, do we have a comprehensive list of UI statements or UI features used on the server side?

If the list is small (for now I am only aware of MESSAGE), then we can modify the execution flow in LogicalTerminal not to forward such a call to ThinClient, but handle it explicitely (output to the logs for example). This will make the runtime leaner, no need to bring in the complex set of class dependencies (albeit limited) starting with ThinClient.

We have FRAME processing in PASOE agents - see #8661-818 The assumption was these were executing on some batch process, but they are used on the appserver, too.

Constantin Asofiei wrote:

We have FRAME processing in PASOE agents - see #8661-818 The assumption was these were executing on some batch process, but they are used on the appserver, too.

I see, no shortcuts then.

Greg, I was under an impression this issue was to allow some limited set of UI statements in business logic running in the application server context on the server (I was aware of MESSAGE and FRAME). But yesterday on the status meeting you mentioned issue #10009 and reports that must be executed on the server, too.

Having reports on the server may extend the scope of the implementation as the full set of UI features will need to be runnable on the server.

Please clarify.

Please check with Lorian who is working on those report tasks. If that code is executed in the appserver agent, then we do indeed need the full redirected terminal to work.

That was my understanding.

Greg Shah wrote:

Please check with Lorian who is working on those report tasks. If that code is executed in the appserver agent, then we do indeed need the full redirected terminal to work.

That was my understanding.

Lorian, please confirm.

+Lorian

Hynek Cihlar wrote:

Greg Shah wrote:

Please check with Lorian who is working on those report tasks. If that code is executed in the appserver agent, then we do indeed need the full redirected terminal to work.

That was my understanding.

Lorian, please confirm.

Lorian, please see above.

I created 9055a and checked in the early work. The branch allows non-alert box MESSAGE executed in server context.

Greg Shah wrote:

Please check with Lorian who is working on those report tasks. If that code is executed in the appserver agent, then we do indeed need the full redirected terminal to work.

That was my understanding.

The UI code from the reports is not executed on the appserver. There is a .sh script that starts a ClientDriver that would execute it.

Great!

Hynek: keep going with your plan and we will need to test that application once you have enough implemented.

I'd like to start testing my changes in the customer app. What instructions are best to use? Also, which person is the right one to bother with this?

I can help with running harness or smoketest if needed.

9055a fixes the regression mentioned in #10216-53. Please review.

Hynek Cihlar wrote:

9055a fixes the regression mentioned in #10216-53. Please review.

Thanks, looks good.

9055a passed GUI regression tests. I'm still not happy with the ChUI results, so ChUI testing is ongoing.

9055a passed ChUI regression tests. There are about 6 tests that fail, but the same failures are also in trunk.

I rebased 9055a against latest trunk and added file history entries. Please review, the branch is ready to be merged to trunk. After the merge some changes will be needed for one customer GUI app.

Code Review Task Branch 9055a Revisions 16071 through 16083

I don't have any objections.

Have you prepared changes for customer projects which have their own custom widgets?

Hynek Cihlar wrote:

9055a passed ChUI regression tests. There are about 6 tests that fail, but the same failures are also in trunk.

Hynek, could you please report these failed tests in #7143 to be known for all.

Sergey Ivanovskiy wrote:

Hynek Cihlar wrote:

9055a passed ChUI regression tests. There are about 6 tests that fail, but the same failures are also in trunk.

Hynek, could you please report these failed tests in #7143 to be known for all.

All of these were duplicates of already reported failures.

9055a rebased against latest trunk.

Please merge 9055a to trunk now.