Re: Replay request
Excellent André,
Glad you found an alternate way than trying to replay requests which would be
brittle if you could get it to work. Your new way is much better with the
lambdas. It’s basically blocks (like in Smalltalk) that you can execute when
you want. Javascript does this quite a bit to with functions passed as
variables. Thanks for sharing your pseudo-code :-)
> On Nov 14, 2023, at 12:01 PM, André Rothe wrote:
>
> Hi Aaron,
>
> Thank you for your reply. That is a nice idea. At the end I have solved it
> with Lambdas. The action on (3) contains not only a pageWithName(), it
> initializes also the new component by calling some public method. So I moved
> that stuff into a Lambda and store it within a class member field of the
> current page.
>
>
> @FunctionalInterface
> public interface ConfirmedAction {
> WOActionResults perform();
> }
>
> public class MyPage extends WOComponent {
>
> private ConfirmedAction userAction = null;
>
> public WOActionResults myActionMethod() {
> userAction = () -> {
> MyNextPage nextPage = pageWithName(MyNextPage.class.getName())
> nextPage.initSomething();
> nextPage.initSomeOtherThings()
> return nextPage;
> };
> return validateMyPage() ? userAction.perform() : this;
> }
>
> // some further similar action methods...
> }
>
> If the validation returns true, it executes the Lambda immediately, otherwise
> it returns "this", but during the validation the condition for the waring
> dialog overlay has been set (5b). So the dialog will be visible now.
>
> On (7b) the user clicks "Proceed" within the dialog, which executes another
> action method:
>
> public WOActionResults proceedAction() {
> hideDialog()
> fixValidationProblem();
> return userAction != null ? userAction.perform() : this;
> }
>
> This will set the dialog condition to false, so the dialog will be removed on
> the next page refresh, it fixes the validation problem and stores the changes
> on the EC and will perform the stored action (i.e. the one from
> myActionMethod) if available. In all other cases it goes to "this" again.
>
> If I move the fixValidationProblem() also into a Lambda, I can reuse the code
> structure for different warnings/validation problems. In the validateMyPage()
> I can set specific "fix me" Lambdas for every problem that will be found.
>
> Seems to work. Thanks for idea.
> André
>
> Am 12.11.2023 03:01, schrieb Aaron Rosenzweig:
>> Hi André,
>> At step 3 can you store a variable that remembers the page the user
>> intends to go to?
>> maybe you can make an enum with all the possible pages they could go
>> to on the next step and the variable would be one of those values.
>> Then, in 7b, you can reference that variable and create the page to
>> send them to.
>>> On Nov 11, 2023, at 5:33 PM, André Rothe wrote:
>>> Hi Aaron,
>>> Thank you for your answer. Here the more detailled workflow:
>>> 1. User goes to page A.
>>> 2. User clicks there on an element which submits the HTML
>>> form and should show i.e. page B later (there are a
>>> lot of possible things the user can do on page A which
>>> submit the form and forwards the user to different pages).
>>> 3. Server executes the associated action method on the
>>> PageAComponent.
>>> 4. Action method calls validateSomeThings().
>>> 5a. If validateSomeThings() returns true, the action
>>> method will return i.e. page B as ActionResults.
>>> 5b. If validateSomeThings() returns false, the action
>>> method will set a condition and returns page A again.
>>> 6. Because of the condition, the warning dialog (with two
>>> buttons) will be shown on page A (as an overlay div).
>>> 7a. If the user clicks on "cancel" within the warning dialog,
>>> a further action method on PageAComponent will be called.
>>> It sets the condition back to false and returns
>>> PageAComponent again as ActionResults.
>>> 7b. If the user clicks on "proceed" within the warning dialog,
>>> a further action method on PageAComponent will be called.
>>> It fixes the validation problem, sets the condition back
>>> to false and should return i.e. PageBComponent.
>>> The problem is, that I don't know, which action method has been called on
>>> (3) and which will be the next page, that should be shown on (7b).
>>> Therefore I try to replay the initial request from (2) on (7b) to simulate
>>> the initial action of the user.
>>> I can return PageAComponent on (7b) only, but then the user must repeat his
>>> action on page A (which will not show the warning dialog this time). But
>>> this is ugly.
>>> The question is, how I can solve that?
>>> Thanks!
>>> André
>>> Am 11.11.2023 01:46, schrieb Aaron Rosenzweig:
Hi André,
I didn’t fully understand but it sounds like maybe you are working too
hard. It’s easier to hold onto WOComponents than it is to hold onto
contexts. If you have an “old page” hold onto it and just return the
page. If you don’t have the outermost page you
Re: Replay request
Hi Aaron,
Thank you for your reply. That is a nice idea. At the end I have solved
it with Lambdas. The action on (3) contains not only a pageWithName(),
it initializes also the new component by calling some public method. So
I moved that stuff into a Lambda and store it within a class member
field of the current page.
@FunctionalInterface
public interface ConfirmedAction {
WOActionResults perform();
}
public class MyPage extends WOComponent {
private ConfirmedAction userAction = null;
public WOActionResults myActionMethod() {
userAction = () -> {
MyNextPage nextPage = pageWithName(MyNextPage.class.getName())
nextPage.initSomething();
nextPage.initSomeOtherThings()
return nextPage;
};
return validateMyPage() ? userAction.perform() : this;
}
// some further similar action methods...
}
If the validation returns true, it executes the Lambda immediately,
otherwise it returns "this", but during the validation the condition for
the waring dialog overlay has been set (5b). So the dialog will be
visible now.
On (7b) the user clicks "Proceed" within the dialog, which executes
another action method:
public WOActionResults proceedAction() {
hideDialog()
fixValidationProblem();
return userAction != null ? userAction.perform() : this;
}
This will set the dialog condition to false, so the dialog will be
removed on the next page refresh, it fixes the validation problem and
stores the changes on the EC and will perform the stored action (i.e.
the one from myActionMethod) if available. In all other cases it goes to
"this" again.
If I move the fixValidationProblem() also into a Lambda, I can reuse the
code structure for different warnings/validation problems. In the
validateMyPage() I can set specific "fix me" Lambdas for every problem
that will be found.
Seems to work. Thanks for idea.
André
Am 12.11.2023 03:01, schrieb Aaron Rosenzweig:
Hi André,
At step 3 can you store a variable that remembers the page the user
intends to go to?
maybe you can make an enum with all the possible pages they could go
to on the next step and the variable would be one of those values.
Then, in 7b, you can reference that variable and create the page to
send them to.
On Nov 11, 2023, at 5:33 PM, André Rothe
wrote:
Hi Aaron,
Thank you for your answer. Here the more detailled workflow:
1. User goes to page A.
2. User clicks there on an element which submits the HTML
form and should show i.e. page B later (there are a
lot of possible things the user can do on page A which
submit the form and forwards the user to different pages).
3. Server executes the associated action method on the
PageAComponent.
4. Action method calls validateSomeThings().
5a. If validateSomeThings() returns true, the action
method will return i.e. page B as ActionResults.
5b. If validateSomeThings() returns false, the action
method will set a condition and returns page A again.
6. Because of the condition, the warning dialog (with two
buttons) will be shown on page A (as an overlay div).
7a. If the user clicks on "cancel" within the warning dialog,
a further action method on PageAComponent will be called.
It sets the condition back to false and returns
PageAComponent again as ActionResults.
7b. If the user clicks on "proceed" within the warning dialog,
a further action method on PageAComponent will be called.
It fixes the validation problem, sets the condition back
to false and should return i.e. PageBComponent.
The problem is, that I don't know, which action method has been called
on (3) and which will be the next page, that should be shown on (7b).
Therefore I try to replay the initial request from (2) on (7b) to
simulate the initial action of the user.
I can return PageAComponent on (7b) only, but then the user must
repeat his action on page A (which will not show the warning dialog
this time). But this is ugly.
The question is, how I can solve that?
Thanks!
André
Am 11.11.2023 01:46, schrieb Aaron Rosenzweig:
Hi André,
I didn’t fully understand but it sounds like maybe you are working
too
hard. It’s easier to hold onto WOComponents than it is to hold onto
contexts. If you have an “old page” hold onto it and just return the
page. If you don’t have the outermost page you can find that quickly
by doing “context().page()”
Hope that helps,
— Aaron
On Nov 10, 2023, at 3:09 AM, André Rothe via Webobjects-dev
wrote:
Hi,
I try to replay an old WORequest after some other
request/response-loops, but I don't know, how it could work.
My application validates some values after the user clickes
somewhere on a page. In the validation routine I don't know, which
action the user has executed exactly. But the validation can be
wrong, so I display another page (an overlay dialog over the current
page), where the user can decide between "Cancel" and "Proceed". On
"Cancel" I return the current page without the overlay, on "Proceed"
I fix the pr
