Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Won't Fix
    • Affects Version/s: 1.0.4-core
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None
    • Environment:
      Weblogic 9, Oracle 10g, trinidad-api-1.0.4-SNAPSHOT.jar, trinidad-impl-1.0.4-SNAPSHOT.jar

      Description

      It was observed from the html view source of the page that the id of tr:message tag is regenerated as "formId:ComponentId::msg" using trinidad-api-1.0.4-SNAPSHOT.jar, trinidad-impl-1.0.4-SNAPSHOT.jar . However, if we use trinidad-impl-incubator-m1-SNAPSHOT.jar and trinidad-api-incubator-m1-SNAPAHOT.jar, we see id remains the same as we assigned for the tr:message tag during design.

      Find the attached file to replicate the issue.

      Note: we are validating the InputTextBox component on partialSubmit using a javascript method. Here we validate if id is found by the name as observed in view source of page. however, if we use the id as set during design time, the message of tr:message tag will not be rendered.

      1. FS-6779.zip
        8 kB
        Rincy Rappai

        Activity

        Hide
        Matthias Weßendorf added a comment -

        104 is pretty old, however its generation of the msg is correct

        Show
        Matthias Weßendorf added a comment - 104 is pretty old, however its generation of the msg is correct
        Hide
        Scott O'Bryan added a comment -

        This issue is now closed

        Show
        Scott O'Bryan added a comment - This issue is now closed
        Hide
        Rincy Rappai added a comment -

        Hello Scott,

        I see that this issue has been closed as invalid. May I know the reason for closure. Was this replicable in the latest version of trinidad?

        Regards,
        Rincy

        Show
        Rincy Rappai added a comment - Hello Scott, I see that this issue has been closed as invalid. May I know the reason for closure. Was this replicable in the latest version of trinidad? Regards, Rincy
        Hide
        Scott O'Bryan added a comment -

        Sorry, this should have been closed as "Won't fix". One of the problems with the Trinidad bug queue is that we have so many open bugs that issues on active branches get lost in the shuffle. As such, I'm closing all bugs reported against 1.0.x branches only (which are no longer maintained). If the problem persists in the latest Trinidad 1.0.x trunk, you are welcome to submit a patch that those interested can apply manually, but as we are no longer developing this version, we're not looking at applying any patch to a future release.

        If you discover that this is a valid problem in Trinidad 2.0, feel free to reopen this bug.

        Show
        Scott O'Bryan added a comment - Sorry, this should have been closed as "Won't fix". One of the problems with the Trinidad bug queue is that we have so many open bugs that issues on active branches get lost in the shuffle. As such, I'm closing all bugs reported against 1.0.x branches only (which are no longer maintained). If the problem persists in the latest Trinidad 1.0.x trunk, you are welcome to submit a patch that those interested can apply manually, but as we are no longer developing this version, we're not looking at applying any patch to a future release. If you discover that this is a valid problem in Trinidad 2.0, feel free to reopen this bug.

          People

          • Assignee:
            Unassigned
            Reporter:
            Rincy Rappai
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development