Details

    • Type: Improvement Improvement
    • Status: Open
    • Priority: Critical Critical
    • Resolution: Unresolved
    • Affects Version/s: 0.9
    • Fix Version/s: None
    • Labels:
      None
    • Environment:

      Operating System: All
      Platform: All

    • Issuezilla Id:
      275

      Description

      Until issue #274 is completed, it will be very helpful to know whether the
      native component can access the resource at your URL. Since different native
      components are implement the Browser API, potentially some of them could handle
      a particular protocol while another couldn't.

      A new method as below would enable the calling context to deal with this
      accordingly.

      public boolean supportsProtocol(String protocol)

      or alternatively make the URL the argument directly

      public boolean supports(URL url)

      I notice the willOpenURL() method, which sounds similar, but serves a different
      purpose.

        Activity

        Hide
        georgez added a comment -

        As JDIC Browser leverage the full functionality of native browsers (IE or
        Mozilla), which should support most of the available protocols.

        So, I think this new method doesn't make much senst. How it can be used in your
        case ? Thanks.

        Show
        georgez added a comment - As JDIC Browser leverage the full functionality of native browsers (IE or Mozilla), which should support most of the available protocols. So, I think this new method doesn't make much senst. How it can be used in your case ? Thanks.
        Hide
        turadg added a comment -

        Oh, I wrote most of the explanation on the other ticket, issue #274.

        Our use case makes use of "jar:" urls. We have an interface for a component
        that takes a URL. Some of the implementers use JEditorPane which can read from
        a "jar:" url, but some are implementors use the native browser component which
        can't. When it can't, I need to know that so I can make the resource accessible
        in a protocol the browser supports (e.g. file: by exploding the JAR).

        Basically the problem boils down to this: the contract of the java.net.URL has
        an openConnection() method which is the way to stream in the contents. The
        develop is free to write new protocols or URLConnectionHandlers and anything in
        that takes a java.net.URL can work with it. Except... these native browser
        components.

        If there isn't something done to bridge this change of contract, then I suggest
        that the browser component not take a java.net.URL and instead take simply a
        String (which is all it does with the URL).

        Of course, what I would most like is for the JDIC component to figure out
        whether the native component can access the URL and if not do something to make
        it work. ie. what I describe in issue 274.

        Show
        turadg added a comment - Oh, I wrote most of the explanation on the other ticket, issue #274. Our use case makes use of "jar:" urls. We have an interface for a component that takes a URL. Some of the implementers use JEditorPane which can read from a "jar:" url, but some are implementors use the native browser component which can't. When it can't, I need to know that so I can make the resource accessible in a protocol the browser supports (e.g. file: by exploding the JAR). Basically the problem boils down to this: the contract of the java.net.URL has an openConnection() method which is the way to stream in the contents. The develop is free to write new protocols or URLConnectionHandlers and anything in that takes a java.net.URL can work with it. Except... these native browser components. If there isn't something done to bridge this change of contract, then I suggest that the browser component not take a java.net.URL and instead take simply a String (which is all it does with the URL). Of course, what I would most like is for the JDIC component to figure out whether the native component can access the URL and if not do something to make it work. ie. what I describe in issue 274.
        Hide
        michael_shan added a comment -

        Assign to Michael.

        Show
        michael_shan added a comment - Assign to Michael.

          People

          • Assignee:
            michael_shan
            Reporter:
            turadg
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated: