FAQ
Hi!

i have a short (and maybe silly) question:

The user navigates thru my application. The user can access any time in any form
a help/info button to get some help about the application. The help screen has
a button "back" - but how can I handle it that the nagivation goes back to the
form last seen before the help screen? I do not want to do Javascript here - is
there a way using JSF ?

Thank you for your help in advance


--
Boris Klug, Debeka Koblenz, Germany

Search Discussions

  • Martin Marinschek at May 24, 2005 at 1:28 pm
    There are essentially two things you need to do:

    * store a stack of the views you visited last in your session data
    (you can easily hook into that when you create a decorated
    view-handler)
    * if the action-command equals some predefined command, e.g. 'back',
    take the last page out of this stack and choose this page in the
    view-handler for rendering instead of the page you would normally
    render.

    regards,

    Martin
    On 5/24/05, Klug, Boris wrote:
    Hi!

    i have a short (and maybe silly) question:

    The user navigates thru my application. The user can access any time in any form
    a help/info button to get some help about the application. The help screen has
    a button "back" - but how can I handle it that the nagivation goes back to the
    form last seen before the help screen? I do not want to do Javascript here - is
    there a way using JSF ?

    Thank you for your help in advance


    --
    Boris Klug, Debeka Koblenz, Germany



  • Sean Schofield at May 24, 2005 at 1:39 pm
    FYI there is some really cool stuff going on with dialogs in Struts
    Shale right now. Its all built on top of JSF and there are some
    "nightly" examples you can download from Craig's website.

    Of course you can accomplish this without Shale (see Martin's
    suggestions) but Shale provides a nice "standard" way of solving the
    "dialog problem."

    sean
    On 5/24/05, Martin Marinschek wrote:
    There are essentially two things you need to do:

    * store a stack of the views you visited last in your session data
    (you can easily hook into that when you create a decorated
    view-handler)
    * if the action-command equals some predefined command, e.g. 'back',
    take the last page out of this stack and choose this page in the
    view-handler for rendering instead of the page you would normally
    render.

    regards,

    Martin
    On 5/24/05, Klug, Boris wrote:
    Hi!

    i have a short (and maybe silly) question:

    The user navigates thru my application. The user can access any time in any form
    a help/info button to get some help about the application. The help screen has
    a button "back" - but how can I handle it that the nagivation goes back to the
    form last seen before the help screen? I do not want to do Javascript here - is
    there a way using JSF ?

    Thank you for your help in advance


    --
    Boris Klug, Debeka Koblenz, Germany



  • Werner Punz at May 27, 2005 at 7:17 am

    Sean Schofield wrote:
    FYI there is some really cool stuff going on with dialogs in Struts
    Shale right now. Its all built on top of JSF and there are some
    "nightly" examples you can download from Craig's website.

    Of course you can accomplish this without Shale (see Martin's
    suggestions) but Shale provides a nice "standard" way of solving the
    "dialog problem."
    Well I checked shale yesterday, it looks really nice, but I have one
    gripe with it, Callahan introduces yet another xml syntax for the page
    flow, which really is totally redundant because the pageflow already is
    covered in the faces-config description.

    The better approach would be to use some kind of dialog marker tag,
    which marks the dialog boundaries, and let JSF keep the page flow.
    JSF has way too many artefacts scattered around the filesystem already
    (a huge design mistake, it inherited from Struts), we dont neet yet
    another artefact, and even one, which ist totally redundant.
  • Craig McClanahan at May 27, 2005 at 7:56 am

    On 5/27/05, Werner Punz wrote:
    Sean Schofield wrote:
    FYI there is some really cool stuff going on with dialogs in Struts
    Shale right now. Its all built on top of JSF and there are some
    "nightly" examples you can download from Craig's website.

    Of course you can accomplish this without Shale (see Martin's
    suggestions) but Shale provides a nice "standard" way of solving the
    "dialog problem."
    Well I checked shale yesterday, it looks really nice, but I have one
    gripe with it, Callahan introduces yet another xml syntax for the page
    flow, which really is totally redundant because the pageflow already is
    covered in the faces-config description.

    The better approach would be to use some kind of dialog marker tag,
    which marks the dialog boundaries, and let JSF keep the page flow.
    JSF has way too many artefacts scattered around the filesystem already
    (a huge design mistake, it inherited from Struts), we dont neet yet
    another artefact, and even one, which ist totally redundant.
    Not really redundant, in at least a couple of areas:

    * JSF 1.x doesn't have any notion of mapping to an action state;
    it only knows about view states.

    * JSF 1.x maps outcomes to new (view) states globally per application,
    which means you cannot reuse the same view in more than one dialog.

    * Besides the "global" restriction, JSF 1.x doesn't have any support for
    a "dialog scope" (longer than a request, shorter than a session) -- you
    have to do all that kind of state management by yourself.

    None of these "limitations" of JSF 1.x should really be that
    surprising; the focus was on creating a view tier component API.
    Shale, on the other hand, is about creating a controller tier API that
    is synergistic with JSF's basic controller capabilities, rather than
    treating it as simply a custom tag library (like the Struts HTML
    tags).

    If the ideas in Shale's dialog management end up in JSF 2.0 (which
    doesn't seem unlikely to *me*, but that will be up to the JSF 2.0
    expert group), then great. In the mean time, the ability to script a
    dialog, with both action and view states, and to build a tool to
    assist a user in graphically assembling such a dialog, then reusing it
    as a black box, is pretty helpful.

    Craig
  • Werner Punz at May 27, 2005 at 8:29 am

    Craig McClanahan wrote:
    On 5/27/05, Werner Punz wrote:

    Sean Schofield wrote:
    FYI there is some really cool stuff going on with dialogs in Struts
    Shale right now. Its all built on top of JSF and there are some
    "nightly" examples you can download from Craig's website.

    Of course you can accomplish this without Shale (see Martin's
    suggestions) but Shale provides a nice "standard" way of solving the
    "dialog problem."
    Well I checked shale yesterday, it looks really nice, but I have one
    gripe with it, Callahan introduces yet another xml syntax for the page
    flow, which really is totally redundant because the pageflow already is
    covered in the faces-config description.

    The better approach would be to use some kind of dialog marker tag,
    which marks the dialog boundaries, and let JSF keep the page flow.
    JSF has way too many artefacts scattered around the filesystem already
    (a huge design mistake, it inherited from Struts), we dont neet yet
    another artefact, and even one, which ist totally redundant.

    Not really redundant, in at least a couple of areas:

    * JSF 1.x doesn't have any notion of mapping to an action state;
    it only knows about view states.
    Correct me if I am wrong, but is an action state not just another
    redirect in a page centric view... so I do not see any point except
    mapping things to the UML paradigm.
    * JSF 1.x maps outcomes to new (view) states globally per application,
    which means you cannot reuse the same view in more than one dialog.
    point taken in this regard... this is a huge hole in the specs, which I
    also hate.
    * Besides the "global" restriction, JSF 1.x doesn't have any support for
    a "dialog scope" (longer than a request, shorter than a session) -- you
    have to do all that kind of state management by yourself.
    that is resolvable with less artefacts by the introduction
    of a scope or dialog tag, which does the handling in a for the end user
    easier way.
    None of these "limitations" of JSF 1.x should really be that
    surprising; the focus was on creating a view tier component API.
    Shale, on the other hand, is about creating a controller tier API that
    is synergistic with JSF's basic controller capabilities, rather than
    treating it as simply a custom tag library (like the Struts HTML
    tags).
    If the ideas in Shale's dialog management end up in JSF 2.0 (which
    doesn't seem unlikely to *me*, but that will be up to the JSF 2.0
    expert group), then great. In the mean time, the ability to script a
    dialog, with both action and view states, and to build a tool to
    assist a user in graphically assembling such a dialog, then reusing it
    as a black box, is pretty helpful.
    Yes... but the main problem is, that it again is way to complicated
    to use by introducing another set of artefacts in an already artefact
    bloated system.

    Shale started as a project which should make things easier for the user
    (the main problem to my knowlege most people had with both Struts and
    JSF was the artefact management, which JSF is better than struts but
    still far from being easy to handle)

    To keep the number of artefacts low, I think the correct approach would
    be to try not to introduce yet another xml type and to try to cover as
    much as possible with tags and not with another layer of frameworks,
    which you force upon the user to use. (there are way to many framework
    hooks in JSF already, which sometimes are hard to grasp. The main two
    examples which come to my mind are the component model framework and the
    Datamodel, which both could have been way easier )
  • Francesco Consumi at May 27, 2005 at 8:59 am
    Hi all,

    I'd need to some user settings of my webapp, such as data filters, in cookies.
    I've found the CookieMap class, but I haven't found any documentation
    on how to use, e.g. how to get class instance for malipulating
    cookies...

    any help ?

    thanks
  • Sean Schofield at May 31, 2005 at 9:28 pm
    I'm not sure what the MyFaces CookieMap does actually. Faces provides
    you a Map of cookies using
    context.getExternalContext().getRequestCookieMap(). For an example of
    how that works see HtmlTreeRenderer.

    Not sure what o.a.m.context.servlet.CookieMap is supposed to do
    really. I will check with the developers and see.

    sean

    On 5/27/05, Francesco Consumi wrote:
    Hi all,

    I'd need to some user settings of my webapp, such as data filters, in cookies.
    I've found the CookieMap class, but I haven't found any documentation
    on how to use, e.g. how to get class instance for malipulating
    cookies...

    any help ?

    thanks
  • Sean Schofield at Jun 2, 2005 at 10:12 am
    OK we found out that the CookieMap is for. Its the *implementation*
    behind the Map that you get when you call
    context.getExternalContext().getRequestCookieMap(). Please consult
    the specification for the documentation on what its supposed to do.
    Basically it is a convenience class for dealing with cookies.

    sean
    On 5/31/05, Sean Schofield wrote:
    I'm not sure what the MyFaces CookieMap does actually. Faces provides
    you a Map of cookies using
    context.getExternalContext().getRequestCookieMap(). For an example of
    how that works see HtmlTreeRenderer.

    Not sure what o.a.m.context.servlet.CookieMap is supposed to do
    really. I will check with the developers and see.

    sean

    On 5/27/05, Francesco Consumi wrote:
    Hi all,

    I'd need to some user settings of my webapp, such as data filters, in cookies.
    I've found the CookieMap class, but I haven't found any documentation
    on how to use, e.g. how to get class instance for malipulating
    cookies...

    any help ?

    thanks
  • Francesco Consumi at Jun 2, 2005 at 12:57 pm

    Scrive Sean Schofield <sean.schofield@gmail.com>:

    OK we found out that the CookieMap is for. Its the *implementation*
    behind the Map that you get when you call
    context.getExternalContext().getRequestCookieMap(). Please consult
    the specification for the documentation on what its supposed to do.
    Basically it is a convenience class for dealing with cookies.
    Thanks a lot,

    is that class able to set cookies too ?
    and, I didn't found a lot of documentation for that class in Myfaces javadoc.
    is there any other documentation source ?

    thanks.


    --
    Francesco Consumi
    Ufficio Sistemi informativi
    Istituto degli Innocenti
    Piazza SS.Annunziata, 12
    50122 Firenze
    consumi at istitutodeglinnocenti.it
    Tel. +39 055 2037320
    ICQ# 12516133
  • Sean Schofield at Jun 2, 2005 at 2:04 pm
    Yes it can set cookies. Take a look at HtmlTreeRenderer (in tree2
    package.) It make use of cookies.

    sean
    On 6/2/05, Francesco Consumi wrote:
    Scrive Sean Schofield <sean.schofield@gmail.com>:
    OK we found out that the CookieMap is for. Its the *implementation*
    behind the Map that you get when you call
    context.getExternalContext().getRequestCookieMap(). Please consult
    the specification for the documentation on what its supposed to do.
    Basically it is a convenience class for dealing with cookies.
    Thanks a lot,

    is that class able to set cookies too ?
    and, I didn't found a lot of documentation for that class in Myfaces javadoc.
    is there any other documentation source ?

    thanks.


    --
    Francesco Consumi
    Ufficio Sistemi informativi
    Istituto degli Innocenti
    Piazza SS.Annunziata, 12
    50122 Firenze
    consumi at istitutodeglinnocenti.it
    Tel. +39 055 2037320
    ICQ# 12516133
  • Craig McClanahan at May 27, 2005 at 4:37 pm

    On 5/27/05, Werner Punz wrote:
    Craig McClanahan wrote:
    On 5/27/05, Werner Punz wrote:

    Sean Schofield wrote:
    FYI there is some really cool stuff going on with dialogs in Struts
    Shale right now. Its all built on top of JSF and there are some
    "nightly" examples you can download from Craig's website.

    Of course you can accomplish this without Shale (see Martin's
    suggestions) but Shale provides a nice "standard" way of solving the
    "dialog problem."
    Well I checked shale yesterday, it looks really nice, but I have one
    gripe with it, Callahan introduces yet another xml syntax for the page
    flow, which really is totally redundant because the pageflow already is
    covered in the faces-config description.

    The better approach would be to use some kind of dialog marker tag,
    which marks the dialog boundaries, and let JSF keep the page flow.
    JSF has way too many artefacts scattered around the filesystem already
    (a huge design mistake, it inherited from Struts), we dont neet yet
    another artefact, and even one, which ist totally redundant.

    Not really redundant, in at least a couple of areas:

    * JSF 1.x doesn't have any notion of mapping to an action state;
    it only knows about view states.
    Correct me if I am wrong, but is an action state not just another
    redirect in a page centric view... so I do not see any point except
    mapping things to the UML paradigm.
    No, as currently implemented an action state is a method call
    (configured using a method binding expression) to some public method
    on a bean -- typically a managed bean so you get the create-on-demand
    and dependency injection features -- that returns a String outcome.
    That outcome can then be used to select a transition to some other
    state. Note that you can chain action states together if you want, as
    well, to support fine grained reusable behaviors.

    The container has no notion that any of this is going on -- it's not
    implemented with RequestDispatcher.forward() or with redirects. JSF
    only knows how to navigate to views.

    A Shale ViewController provides the equivalent of a setup action for
    you (prerender), but that *requires* you to put the corresponding
    logic in the same bean as the processing logic. Some folks prefer a
    design pattern that allows you to reuse setup actions across different
    views (i.e. call the same action method for the several places where
    you need to look up all the orders for a particular customer). Dialog
    lets you do that.

    * JSF 1.x maps outcomes to new (view) states globally per application,
    which means you cannot reuse the same view in more than one dialog.
    point taken in this regard... this is a huge hole in the specs, which I
    also hate.
    Remember that it was a 1.0 spec, whose primary goal was getting the
    component APIs right. This is the sort of functionality that can be
    added later, so consider dialogs some real life research into what
    kinds of facilities like this should later be standardized.
    * Besides the "global" restriction, JSF 1.x doesn't have any support for
    a "dialog scope" (longer than a request, shorter than a session) -- you
    have to do all that kind of state management by yourself.
    that is resolvable with less artefacts by the introduction
    of a scope or dialog tag, which does the handling in a for the end user
    easier way.
    What kind of tag? I guess you're talking about a JSP custom tag of some sort?

    In the long run, I think support for something like dialog scope
    really belongs at the servlet API level so that all the web tier
    technologies could benefit from it -- but that's for the future, and
    this is now.
    None of these "limitations" of JSF 1.x should really be that
    surprising; the focus was on creating a view tier component API.
    Shale, on the other hand, is about creating a controller tier API that
    is synergistic with JSF's basic controller capabilities, rather than
    treating it as simply a custom tag library (like the Struts HTML
    tags).
    If the ideas in Shale's dialog management end up in JSF 2.0 (which
    doesn't seem unlikely to *me*, but that will be up to the JSF 2.0
    expert group), then great. In the mean time, the ability to script a
    dialog, with both action and view states, and to build a tool to
    assist a user in graphically assembling such a dialog, then reusing it
    as a black box, is pretty helpful.
    Yes... but the main problem is, that it again is way to complicated
    to use by introducing another set of artefacts in an already artefact
    bloated system.
    Sorry ... I still don't understand how your contention that the
    standard JSF configuration mechanism provides "everything you need"
    for dialog management is supported.

    And, by the way, those artifacts are part of what makes building tools
    to support developers much easier. Go grab a copy of Creator and play
    with the page navigation support (adding a navigation rule is done by
    dragging a mouse from one page to another) -- you can edit the XML if
    you really want to, but it's much nicer not to have to. The
    configuration of dialogs is very much amenable to the same kind of
    support.
    Shale started as a project which should make things easier for the user
    (the main problem to my knowlege most people had with both Struts and
    JSF was the artefact management, which JSF is better than struts but
    still far from being easy to handle)

    To keep the number of artefacts low, I think the correct approach would
    be to try not to introduce yet another xml type and to try to cover as
    much as possible with tags and not with another layer of frameworks,
    which you force upon the user to use. (there are way to many framework
    hooks in JSF already, which sometimes are hard to grasp. The main two
    examples which come to my mind are the component model framework and the
    Datamodel, which both could have been way easier )

    Minimizing configuration artifacts is not the primary measure of ease
    of use for developers. Indeed, the fact that Struts *required* a
    config file (over and above web.xml) was one of the most important
    factors in its success.

    Craig

    Craig
  • Jesse Alexander (KBSA 21) at May 24, 2005 at 2:10 pm
    Hi Boris

    I had the need for something similar (an extended search jumping to two additional
    screens before returning the selected object to original form).

    I resolved it writing my own component that gets the "back-navigation outcome"
    via a tag-parm. Such a help-case as yours would be a simplification of that component.

    hth
    Alexander

    -----Original Message-----
    From: Klug, Boris
    Sent: Tuesday, May 24, 2005 3:24 PM
    To: users@myfaces.apache.org
    Subject: Navigating "back"

    Hi!

    i have a short (and maybe silly) question:

    The user navigates thru my application. The user can access any time in any form
    a help/info button to get some help about the application. The help screen has
    a button "back" - but how can I handle it that the nagivation goes back to the
    form last seen before the help screen? I do not want to do Javascript here - is
    there a way using JSF ?

    Thank you for your help in advance


    --
    Boris Klug, Debeka Koblenz, Germany
  • Klug, Boris at May 24, 2005 at 2:50 pm
    Hi!
    I resolved it writing my own component that gets the "back-navigation
    outcome"
    via a tag-parm. Such a help-case as yours would be a simplification of that
    component.
    Can you provide your component? So I have a starting point... would be great

    --
    Boris Klug, Debeka
  • Cenk Çivici at May 27, 2005 at 1:21 pm
    Hi,

    An implementation is available at
    http://www.jroller.com/page/cenkcivici/20050512#custom_jsf_navigation_handler_for

    Cenk Çivici
    On 5/24/05, Klug, Boris wrote:
    Hi!

    i have a short (and maybe silly) question:

    The user navigates thru my application. The user can access any time in any form
    a help/info button to get some help about the application. The help screen has
    a button "back" - but how can I handle it that the nagivation goes back to the
    form last seen before the help screen? I do not want to do Javascript here - is
    there a way using JSF ?

    Thank you for your help in advance


    --
    Boris Klug, Debeka Koblenz, Germany



Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupusers @
categoriesmyfaces
postedMay 24, '05 at 1:24p
activeJun 2, '05 at 2:04p
posts15
users8
websitemyfaces.apache.org

People

Translate

site design / logo © 2019 Grokbase