FAQ
You could run your pages through a filter that would make them valid
xhtml. JTidy for example works fine.

Kalle
-----Original Message-----
From: hendrik-neumann@web.de
Sent: Monday, May 30, 2005 2:00 PM
To: MyFaces Discussion
Subject: HTML-Frames, "one-way" commandLinks and forced frame reloads

Hi,

I'm still migrating from from x:panelLayout to classic
html-frames because I have the problem, that I need 100%
valid xhtml-code which is valid for the mime type
application/xhtml+xml but this is extremly hard because JSF
produces invalid xhtml code (I have descriped this problem in
the "Serious problems with MyFaces ID allocation which is not
conform to XHTML!"-mail).
THerefore I try to seperate my whole web-app into several
frames with minimal, but valid xhtml-code.

Now I have the following (simplified) situation: I have 2
frames: one navigation-frame on the left side and one big
mainframe. The navigation frame contains a tree2-component
which loads folders and documents from a database and gernate
for each tree-item a navigation case which targets the
mainframe and loads a new site in the mainframe. This new
loaded mainframe-site then contains a self-made
article-renderer or a folder-renderer which renders the
content. Now if the user clicks on the an item in the
tree2-component in the navigation-frame, the mainframe is
loaded and the navigation-frame is of course NOT reloaded
(because I have frames). If the user then clicks again in the
nav-frame on a link, the jsf-site will just be reloaded (and
showed in the mainframe) instead of processing the
action-link. Only after this forced reload the commandLinks
are working again. So I have to reload the navigation frame
ON EVERY CLICK in the tree2-components which causes A LOT of troubles.

This seems to be a generally problem, that after clicking on
a rendered commandLink the site which contains this link must
to be reloaded. Is there a reason why it is like this? Is
there a workaround?

Greetings,
Hendrik

Search Discussions

  • Hendrik Neumann at Jun 7, 2005 at 2:44 pm
    Hi everybody,

    I need specific, predictable IDs for the links in my tree2-component.
    Therefore I played a little bit with forcedID and forcedIDIndex; for example
    I tried something like this:

    <x:tree2 value="#{currentUser.myTree}" id="myTree" var="node"
    varNodeToggler="t">
    <f:facet name="category">
    <x:commandLink actionListener="#{t.setNodeSelected}"
    action="#{currentUser.userSelectsCategory}"
    immediate="true" [...]>
    <x:outputText value="#{node.description}"
    forceIdIndex="category-#{node.identifier}"
    forceId="category-#{node.identifier}"/>
    [...]

    I need this predictable IDs because I want to adress the tree-links in the
    HTML-page with a javascript-methods (something like:
    "document.anchors[category-4711].xyz..").

    But I always get these extremly ugly jsf-specific IDs with "_" and ":" and so
    on. Therefore I can not use something like
    "document.anchors[category-4711].xyz.." because the IDs are still dynamicly
    generated...

    What am I doing wrong???

    Greetings,
    hendrik
  • Korhonen, Kalle at Jun 7, 2005 at 6:02 pm
    It's not forcedID, it's forceID=[true | false]. I.e. set it to true to
    guide MyFaces to leave the id as is, to whatever you've set it to.
    Granted, the name is misleading IMHO as well.

    Kalle
    -----Original Message-----
    From: hendrik-neumann@web.de
    Sent: Tuesday, June 07, 2005 7:44 AM
    To: MyFaces Discussion
    Subject: ForcedID is not working

    Hi everybody,

    I need specific, predictable IDs for the links in my tree2-component.
    Therefore I played a little bit with forcedID and
    forcedIDIndex; for example I tried something like this:

    <x:tree2 value="#{currentUser.myTree}" id="myTree" var="node"
    varNodeToggler="t">
    <f:facet name="category">
    <x:commandLink actionListener="#{t.setNodeSelected}"
    action="#{currentUser.userSelectsCategory}"
    immediate="true" [...]>
    <x:outputText
    value="#{node.description}"

    forceIdIndex="category-#{node.identifier}"

    forceId="category-#{node.identifier}"/>
    [...]

    I need this predictable IDs because I want to adress the
    tree-links in the HTML-page with a javascript-methods
    (something like:
    "document.anchors[category-4711].xyz..").

    But I always get these extremly ugly jsf-specific IDs with
    "_" and ":" and so on. Therefore I can not use something like
    "document.anchors[category-4711].xyz.." because the IDs are
    still dynamicly generated...

    What am I doing wrong???

    Greetings,
    hendrik
  • Hendrik Neumann at Jun 7, 2005 at 7:31 pm
    *lol*, thanks I'll give it a try ;)

    By the way: why can't I do something like <tag
    id="category-#{node.identifier}" />

    The #{}-expression isn't evaluated in the id-attribute, why not???

    Am Dienstag, 7. Juni 2005 20:03 schrieb Korhonen, Kalle:
    true to
    guide MyFaces to leave the id as is, to whatever you've set it to.
    Granted, the name is misleading IMHO as well.
  • Mike Burati at Jun 7, 2005 at 7:55 pm
    The #{}-expression isn't evaluated in the id-attribute, why not???
    The #{} expression support for Value Binding is a runtime/request-time
    facility.

    The id attributes are used as component identifiers, by JSF, to build up
    a component tree with unique identifiers per naming container.

    See Section 3.1 of the JSF1.1 specification for more information on
    component identifiers and value binding. Per the spec, the id and
    parent are the only attributes of the UI components not enabled for
    value binding...


    **********************************
    Michael Burati
    Senior Software Engineer
    Bowstreet
    200 Ames Pond Drive
    Tewksbury, MA 01876
    T 978-863-1512
    F 978-863-1555
    www.bowstreet.com

    Get the latest information on Bowstreet's events and web seminars.



    -----Original Message-----
    From: hendrik-neumann@web.de
    Sent: Tuesday, June 07, 2005 3:28 PM
    To: MyFaces Discussion
    Subject: Re: ForcedID is not working

    *lol*, thanks I'll give it a try ;)

    By the way: why can't I do something like <tag
    id="category-#{node.identifier}" />

    The #{}-expression isn't evaluated in the id-attribute, why not???

    Am Dienstag, 7. Juni 2005 20:03 schrieb Korhonen, Kalle:
    true to
    guide MyFaces to leave the id as is, to whatever you've set it to.
    Granted, the name is misleading IMHO as well.
  • Martin Marinschek at Jun 7, 2005 at 8:01 pm
    rational explanation:

    a value in a value-binding can change

    - the unique id must stay the same over the whole lifetime of a view,
    if not, where will you post the value of an input to if its id has
    changed?

    regards,

    Martin
    On 6/7/05, Mike Burati wrote:

    The #{}-expression isn't evaluated in the id-attribute, why not???
    The #{} expression support for Value Binding is a runtime/request-time
    facility.

    The id attributes are used as component identifiers, by JSF, to build up
    a component tree with unique identifiers per naming container.

    See Section 3.1 of the JSF1.1 specification for more information on
    component identifiers and value binding. Per the spec, the id and
    parent are the only attributes of the UI components not enabled for
    value binding...


    **********************************
    Michael Burati
    Senior Software Engineer
    Bowstreet
    200 Ames Pond Drive
    Tewksbury, MA 01876
    T 978-863-1512
    F 978-863-1555
    www.bowstreet.com

    Get the latest information on Bowstreet's events and web seminars.



    -----Original Message-----
    From: hendrik-neumann@web.de
    Sent: Tuesday, June 07, 2005 3:28 PM
    To: MyFaces Discussion
    Subject: Re: ForcedID is not working

    *lol*, thanks I'll give it a try ;)

    By the way: why can't I do something like <tag
    id="category-#{node.identifier}" />

    The #{}-expression isn't evaluated in the id-attribute, why not???

    Am Dienstag, 7. Juni 2005 20:03 schrieb Korhonen, Kalle:
    true to
    guide MyFaces to leave the id as is, to whatever you've set it to.
    Granted, the name is misleading IMHO as well.
  • Sylvain Vieujot at Jun 13, 2005 at 8:56 am
    I'm just getting in a problem because the id doesn't support EL right
    now.

    I have a table that displays a webmail inbox.
    On each row, I have a delete this email checkbox.

    It works fine except that it you receive a new email before you submit
    your form, the wrong email is deleted, as the checkbox's name is based
    on the row number, and the emails have all been shifted one row down.

    The only solution I've found to this (and other similar) problem(s) is
    to use the email's id in the checkbox's id :
    <x:selectBooleanCheckbox id="Delete_#{email.unid}_CB"
    value="#{inboxFace.removeEmailUnid[email.unid]}"/>

    This doesn't work right now, but I think the only solution to this
    problem IS TO ALLOW EL in id attributes.

    The 1.1 & 1.2PR Spec. section 3.1.4 says that "all properties other than
    id and parent, are value binding enabled".
    But we could partialy enable it. I mean use the value binding the first
    time the component's id is used, and then freeze this value.

    Any thoughts ?
    On Tue, 2005-06-07 at 22:01 +0200, Martin Marinschek wrote:

    rational explanation:

    a value in a value-binding can change

    - the unique id must stay the same over the whole lifetime of a view,
    if not, where will you post the value of an input to if its id has
    changed?

    regards,

    Martin
    On 6/7/05, Mike Burati wrote:

    The #{}-expression isn't evaluated in the id-attribute, why not???
    The #{} expression support for Value Binding is a runtime/request-time
    facility.

    The id attributes are used as component identifiers, by JSF, to build up
    a component tree with unique identifiers per naming container.

    See Section 3.1 of the JSF1.1 specification for more information on
    component identifiers and value binding. Per the spec, the id and
    parent are the only attributes of the UI components not enabled for
    value binding...


    **********************************
    Michael Burati
    Senior Software Engineer
    Bowstreet
    200 Ames Pond Drive
    Tewksbury, MA 01876
    T 978-863-1512
    F 978-863-1555
    www.bowstreet.com

    Get the latest information on Bowstreet's events and web seminars.



    -----Original Message-----
    From: hendrik-neumann@web.de
    Sent: Tuesday, June 07, 2005 3:28 PM
    To: MyFaces Discussion
    Subject: Re: ForcedID is not working

    *lol*, thanks I'll give it a try ;)

    By the way: why can't I do something like <tag
    id="category-#{node.identifier}" />

    The #{}-expression isn't evaluated in the id-attribute, why not???

    Am Dienstag, 7. Juni 2005 20:03 schrieb Korhonen, Kalle:
    true to
    guide MyFaces to leave the id as is, to whatever you've set it to.
    Granted, the name is misleading IMHO as well.
  • Craig McClanahan at Jun 13, 2005 at 4:46 pm

    On 6/13/05, Sylvain Vieujot wrote:
    I'm just getting in a problem because the id doesn't support EL right now.

    I have a table that displays a webmail inbox.
    On each row, I have a delete this email checkbox.

    It works fine except that it you receive a new email before you submit your
    form, the wrong email is deleted, as the checkbox's name is based on the row
    number, and the emails have all been shifted one row down.

    The only solution I've found to this (and other similar) problem(s) is to
    use the email's id in the checkbox's id :
    <x:selectBooleanCheckbox id="Delete_#{email.unid}_CB"
    value="#{inboxFace.removeEmailUnid[email.unid]}"/>

    This doesn't work right now, but I think the only solution to this problem
    IS TO ALLOW EL in id attributes.

    The 1.1 & 1.2PR Spec. section 3.1.4 says that "all properties other than id
    and parent, are value binding enabled".
    But we could partialy enable it. I mean use the value binding the first
    time the component's id is used, and then freeze this value.

    Any thoughts ?
    If the TCK inludes tests to verify that "id" is *not* value binding
    enabled (which wouldn't surprise me since it is a stated spec
    requirement), then this solution would just have to be undone again in
    order to pass the tests.

    An alternative appropach would be to include a hidden field in one of
    the columns that contains the information you need to identify the
    correct model data (the message identifier for a mailbox screen, for
    example). As decoding occurs and events are fired, the value of this
    hidden field (along with all the others on the current row) will have
    been restored to what it was, so that if the checkbox is checked you
    can go find the relevant message to update or delete.

    Craig
    On Tue, 2005-06-07 at 22:01 +0200, Martin Marinschek wrote:
    rational explanation:

    a value in a value-binding can change

    - the unique id must stay the same over the whole lifetime of a view,
    if not, where will you post the value of an input to if its id has
    changed?

    regards,

    Martin
    On 6/7/05, Mike Burati wrote:

    The #{}-expression isn't evaluated in the id-attribute, why not???
    The #{} expression support for Value Binding is a runtime/request-time
    facility.

    The id attributes are used as component identifiers, by JSF, to build up
    a component tree with unique identifiers per naming container.

    See Section 3.1 of the JSF1.1 specification for more information on
    component identifiers and value binding. Per the spec, the id and
    parent are the only attributes of the UI components not enabled for
    value binding...


    **********************************
    Michael Burati
    Senior Software Engineer
    Bowstreet
    200 Ames Pond Drive
    Tewksbury, MA 01876
    T 978-863-1512
    F 978-863-1555
    www.bowstreet.com

    Get the latest information on Bowstreet's events and web seminars.



    -----Original Message-----
    From: hendrik-neumann@web.de
    Sent: Tuesday, June 07, 2005 3:28 PM
    To: MyFaces Discussion
    Subject: Re: ForcedID is not working

    *lol*, thanks I'll give it a try ;)

    By the way: why can't I do something like <tag
    id="category-#{node.identifier}" />

    The #{}-expression isn't evaluated in the id-attribute, why not???

    Am Dienstag, 7. Juni 2005 20:03 schrieb Korhonen, Kalle:
    true to
    guide MyFaces to leave the id as is, to whatever you've set it to.
    Granted, the name is misleading IMHO as well.
  • Sylvain Vieujot at Jun 13, 2005 at 11:51 pm
    Hello Craig,

    I understand your concern about the TCK tests.
    But I don't see how to use the hidden field you suggest.

    In the table, I have a checkbox for each email, and each email whose
    check box is checked should be deleted.
    I had a similar problem with a list of images whose titles could be
    edited directly in the table.
    I don't see how with a hidden field (or hidden fields) you can fix the
    problem.

    Could you give me a clue ?

    Thanks,

    Sylvain.
    On Mon, 2005-06-13 at 09:45 -0700, Craig McClanahan wrote:
    On 6/13/05, Sylvain Vieujot wrote:
    I'm just getting in a problem because the id doesn't support EL right now.

    I have a table that displays a webmail inbox.
    On each row, I have a delete this email checkbox.

    It works fine except that it you receive a new email before you submit your
    form, the wrong email is deleted, as the checkbox's name is based on the row
    number, and the emails have all been shifted one row down.

    The only solution I've found to this (and other similar) problem(s) is to
    use the email's id in the checkbox's id :
    <x:selectBooleanCheckbox id="Delete_#{email.unid}_CB"
    value="#{inboxFace.removeEmailUnid[email.unid]}"/>

    This doesn't work right now, but I think the only solution to this problem
    IS TO ALLOW EL in id attributes.

    The 1.1 & 1.2PR Spec. section 3.1.4 says that "all properties other than id
    and parent, are value binding enabled".
    But we could partialy enable it. I mean use the value binding the first
    time the component's id is used, and then freeze this value.

    Any thoughts ?
    If the TCK inludes tests to verify that "id" is *not* value binding
    enabled (which wouldn't surprise me since it is a stated spec
    requirement), then this solution would just have to be undone again in
    order to pass the tests.

    An alternative appropach would be to include a hidden field in one of
    the columns that contains the information you need to identify the
    correct model data (the message identifier for a mailbox screen, for
    example). As decoding occurs and events are fired, the value of this
    hidden field (along with all the others on the current row) will have
    been restored to what it was, so that if the checkbox is checked you
    can go find the relevant message to update or delete.

    Craig
    On Tue, 2005-06-07 at 22:01 +0200, Martin Marinschek wrote:
    rational explanation:

    a value in a value-binding can change

    - the unique id must stay the same over the whole lifetime of a view,
    if not, where will you post the value of an input to if its id has
    changed?

    regards,

    Martin
    On 6/7/05, Mike Burati wrote:

    The #{}-expression isn't evaluated in the id-attribute, why not???
    The #{} expression support for Value Binding is a runtime/request-time
    facility.

    The id attributes are used as component identifiers, by JSF, to build up
    a component tree with unique identifiers per naming container.

    See Section 3.1 of the JSF1.1 specification for more information on
    component identifiers and value binding. Per the spec, the id and
    parent are the only attributes of the UI components not enabled for
    value binding...


    **********************************
    Michael Burati
    Senior Software Engineer
    Bowstreet
    200 Ames Pond Drive
    Tewksbury, MA 01876
    T 978-863-1512
    F 978-863-1555
    www.bowstreet.com

    Get the latest information on Bowstreet's events and web seminars.



    -----Original Message-----
    From: hendrik-neumann@web.de
    Sent: Tuesday, June 07, 2005 3:28 PM
    To: MyFaces Discussion
    Subject: Re: ForcedID is not working

    *lol*, thanks I'll give it a try ;)

    By the way: why can't I do something like <tag
    id="category-#{node.identifier}" />

    The #{}-expression isn't evaluated in the id-attribute, why not???

    Am Dienstag, 7. Juni 2005 20:03 schrieb Korhonen, Kalle:
    true to
    guide MyFaces to leave the id as is, to whatever you've set it to.
    Granted, the name is misleading IMHO as well.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupusers @
categoriesmyfaces
postedJun 2, '05 at 11:48p
activeJun 13, '05 at 11:51p
posts9
users6
websitemyfaces.apache.org

People

Translate

site design / logo © 2019 Grokbase