event-dependent responses/form actions

[ghost]

Reported by @cristianbogdan on 20 Oct 2002 17:49 UTC lots of events can result during form response, e.g. activityChanged

currently the only way to set an event-dependent response is the response message. instead of just one message, entire sequences of JSP (including email-sending) should be insertable at the response. since, in the makumba philosophy, the response page is not related to the form (in that any page can be a response to any form), the "event JSPs" should not be contained in the response page.

one idea is to have them contained in a JSP page that has the name of the event, e.g. activityChanged.jsp

most events can be foreseen in the form page (e.g. activityChanged can) but others will be generated in the BL itself. a mechanism for that will be needed

Migrated-From: http://trac.makumba.org/ticket/29

[ghost]

Comment by @cristianbogdan on 20 Oct 2002 19:03 UTC there should also be a way to get hold of the exception object, not just the exception message. maybe exceptions should be regarded as special events

[ghost]

Comment by @cristianbogdan on 22 May 2003 19:24 UTC Bug 446 has been marked as a duplicate of this bug.

[ghost]

Comment by @cristianbogdan on 13 Nov 2005 15:10 UTC Rudi just asked me to set higher prio to this. The actual difficulty as I see it is lack of design, not the implementation as such. So I propose a design below.

Showing the same form in case of error is another idea, probably related to bug

281. Still, if the form is not annotated, it may be that showing the same form as a result of some event in the BL is easier to do.

In retrospect, i think nameOfEvent.jsp or nameOfException.jsp (as suggested at comment 0) is minimalistic but may get mysterious for the mak:user. so my current suggestion is this:

<mak:XXXform ... > <mak:action .../>

</mak:XXXform>

action is supposed to load the indicated pages if the exception occurs. i put 2 because one can send email and the other can display something for the user. i don't see any other use of this besides e-mail though. maybe dealing with a long wait (showing something entertaining for the user while waiting... but how can Jsp1 know that it's time for Jsp2?)

reloadFormPage would get back to the same page. if it has the value "refill" it will present the form readily filled with the data that was filled and produced the error. this of course is a first step to fixing bug 281. the other step is to make a makumba exception type that would contain data about which fields are wrong and why.

later on we can have <onEvent type="org.eu.best.johnny.ActivityChanged" .... /> which would let us deal with stuff other than exceptions, i.e. events.

once you agree on this design, we can look into implementing it. should be easy to do it in the controller/responder.

[ghost]

Comment by radu.epure@best.eu.org on 16 Aug 2007 14:05 UTC Bug 974 has been marked as a duplicate of this bug.

[ghost]

Comment by @rudolfmayer on 28 Aug 2007 14:39 UTC even though the design in comment 4 covers some cases (and should maybe be considered for bug 281), it seems difficult to imagine how this could solve the issues described in bug 974, with having a different action depending on what login was done.

a design proposal from marius would be

• make a globally available method, e.g.

MakumbaSystem.changeAction("asd.jsp?asd") { make some singleton contain "asd.jsp?asd"; }

• after the controller filter have another filter, ActionChangeFilter.java

public void doFilter(...) { if (the same singleton has something) { response.setHeader("location", "the URL") } else { chain.doFilter(...) } }

this could be made even more generic

[ghost]

Comment by risto.koivunen@best.eu.org on 28 Aug 2007 15:15 UTC Besides the example presented by Ducu (login forms, where you do not know what kind of user a given user is before he has logged in), another case is all new/edit/addForms where the validity of the content needs to be checked by the business logics.

I such a case, if the business logics do not accept the content (throwing an exception) it could be good to return the user back to same editing page with the error message (instead of finding himself in the next page with a message to go back). Where as if the business logics are happy the user could be directed to the next step.

[ghost]

Comment by @cristianbogdan on 30 Aug 2007 23:06 UTC (In reply to comment #7)

I such a case, if the business logics do not accept the content (throwing an exception) it could be good to return the user back to same editing page with the error message (instead of finding himself in the next page with a message to go back). Where as if the business logics are happy the user could be directed to the next step.

this is currently being fixed by rudi in bug 281

[ghost]

Comment by @cristianbogdan on 30 Aug 2007 23:16 UTC (In reply to comment #7)

Besides the example presented by Ducu (login forms, where you do not know what kind of user a given user is before he has logged in), another case is all

i guess this can be generalized like "different stuff is shown depending on data submitted, even if there's no error".

but this (however designed) would have to be implemented in both mak:login (the only place where you know is needed for now) and mak:*form.

i would wait for more other needs before suggesting a design. for now, the simple solution is a servlet that redirects to different parts of the site.

[ghost]

Comment by @manuelbernhardt on 31 Aug 2007 14:48 UTC (In reply to comment #6)

a design proposal from marius would be

• make a globally available method, e.g.

MakumbaSystem.changeAction("asd.jsp?asd") { make some singleton contain "asd.jsp?asd"; }

• after the controller filter have another filter, ActionChangeFilter.java

public void doFilter(...) { if (the same singleton has something) { response.setHeader("location", "the URL") } else { chain.doFilter(...) } }

Instead of using MakumbaSystem, what about adding some method in the Attributes or having a redirect Attribute, e.g.

a.setRedirect("asd.jsp?asd")

or

a.setAttribute("redirect", "asd.jsp?asd")

and the filter looks that one up. Would that also work for the login?

Ruby on Rails has a sort of redirect mechanism, we should look into their design. This would help Makumba get closer to Model 2.

[ghost]

Comment by mgilbir@gmail.com on 2 Sep 2007 12:42 UTC Another scenario in which this bug appear would be when you select an option in a combo box and instead of returning the same page to the user to continue configuring related options, he is forced to navigate back to the page to continue the configuration.

Example: In the personal profile -> my account. When you set up the default welcome page that you want to have upon login in PA, after submission you are taken back to the initial page. Then the user is forced to go to the page that allows configuration of the new option that he has enabled. Adding unnecessary clicks from the user and hindering the usability of the process.

[ghost]

Comment by @rudolfmayer on 2 Sep 2007 13:49 UTC (In reply to comment #11)

Example: In the personal profile -> my account. When you set up the default welcome page that you want to have upon login in PA, after submission you are taken back to the initial page. Then the user is forced to go to the page that allows configuration of the new option that he has enabled. Adding unnecessary clicks from the user and hindering the usability of the process.

to maybe clarify this a bit more - there are 3 or so options, and for all of them but one, going to the view-page afterwards is the desired option, while for that one option the edit page shows some extra form to edit the more detailed options for this one option

[ghost]

Comment by @rudolfmayer on 2 Sep 2007 21:18 UTC (In reply to comment #10)

Instead of using MakumbaSystem, what about adding some method in the Attributes or having a redirect Attribute, e.g.

a.setRedirect("asd.jsp?asd")

or

a.setAttribute("redirect", "asd.jsp?asd")

and the filter looks that one up. Would that also work for the login?

i am not in favour of the setAttribute solution, that is IMHO not explicit enough.

For adding the method to the Attributes, i just wonder how much it has to do with the Attributes object actually?

If MakumbaSystem is not the desidered place, i think then it is better to find/create a more fitting one than using Attributes

[ghost]

Comment by @manuelbernhardt on 9 Sep 2007 12:07 UTC (In reply to comment #13)

For adding the method to the Attributes, i just wonder how much it has to do with the Attributes object actually?

well from a BL point of view, Attributes seems to me to be the link between the view, that's why I proposed it. We could use MakumbaSystem now but I try to get as few dependency on it as possible in the refactored version, so as to ensure interdepenendency of the different Makumba products.

About creating another place - I'd wait for that, since we don't know yet exactly how the new controller provider and so on will look.

[ghost]

Comment by @cristianbogdan on 3 Dec 2007 05:29 UTC one interesting case is when you need to load 2 pages in response. for example when you want to send e-mail from one page, and show another

below you find some filter code that loads the mail page behind the scenes (and ignores its output), if it is indicated in the form.

(this of course doesn't solve the case where you have a number of possible response pages, but i feel that the form should be the place for them, what's left to formalize is a selector between these pages)

public void doFilter(ServletRequest req, ServletResponse resp, FilterChain chain) throws ServletException,
        java.io.IOException {

    Attributes a= (Attributes)req.getAttribute("makumba.attributes");
    String mailPage=null;
    try {
        mailPage = (String)a.getAttribute("mailPage");
    } catch (LogicException e) {
    }
    if(mailPage!=null)
    {
        final ByteArrayOutputStream baos= new ByteArrayOutputStream();
        final ServletOutputStream sos= new ServletOutputStream(){
            @Override
            public void write(int i){baos.write(i);} 
        };
        StringWriter sprs= new StringWriter();
        final PrintWriter prs= new PrintWriter(sprs);
        ServletResponse resp1 = new HttpServletResponseWrapper((HttpServletResponse) resp) {
            @Override
            public ServletOutputStream getOutputStream(){ return sos; }
            public PrintWriter getWriter(){
                return prs;
            }
        };

        req.getRequestDispatcher(mailPage).forward(req, resp1);
    }
    chain.doFilter(req, resp);

}

[ghost]

Comment by @manuelbernhardt on 9 Sep 2008 11:10 UTC It seems that changes in the page-flow can be triggered at two levels:

1) the forms itself

there are several examples in K! in which the submitted page depends on some input of a form

a) data-related flow

in comment 11, the example describes a situation where an input can get different values (it is an intEnum which can have 3 options)

in that case, depending on what is the value of the submitted option, the action should be different

b) form-related flow / "wizards" / multi-step forms

this is something that often happens on account creation or for more complicated forms. basically the flow can be described directly on the form page

2) business logic

in this case the processing of the BL determines the action page. a sort of design already exists in comment 6.

Struts has this kind of mechanism, in a more elaborate way: the BL returns an ActionForward object:

someContextObject.findForward("index")

and "index" is mapped in the general Struts configuration file and goes to e.g. some JSP or some servlet

that is, this applies to Java BL and maybe instead of re-writing Struts-like forwards we could look into how to integrate Struts with makumba.

for MDD-BL, it seems to me that we first need a good design for processing in order to also support such model 2 forwards. also the issue of scalability (one general struts-like file vs. per-page configured flows) should be addressed

---

for the moment, here are some design proposals for 1)

a) data-related flow

taking the example of comment 11, I could think of something like:

so "on" takes boolean QFs and actually those could be QFs in the MDD, like b) "wizards" let's say you create a new account and want to go to a different page depending on one option. then instead of having data like in a) you could directly specify it like this: some fields of the form I'm not a BEST member I'm an active BEST member I'm a former BEST member ------- writing the design of 1) a. gave me an idea of what MDD BL forwards could look like: in general.Person (assuming our form is a newForm for a general.Person) forwardAlumni%(personalProfileView = 'Alumni welcome page') ? $currentContextPath/someDir/somePage.jsp forwardStudent%(isStudentAccount() AND age > 18) : ? $currentContextPath/someDir/someOtherPage.jsp : error("You're not old enough, buddy") forwardMember%(isMember()) : ? $currentContextPath/someDir/memberPage.jsp : $currentContextPath/someDir/defaultPage.jsp that could be improved...like, have a "case" or "c:when / c:otherwise" kind of structure. but you get the idea

[ghost]

Modified by @manuelbernhardt on 28 Jun 2010 07:36 UTC

[ghost]

Modified by @manuelbernhardt on 28 Jun 2010 09:16 UTC