Loading ...
Sorry, an error occurred while loading the content.

Re: [pcgen_developers] Re: Core/UI Separation and messages of failure

Expand Messages
  • Martijn Verburg
    I think the discussion is warranted - sorting out our internal messaging is an impt arch design point to solve....
    Message 1 of 7 , Dec 18, 2012
    • 0 Attachment
      I think the discussion is warranted - sorting out our internal messaging is an impt arch design point to solve....


      On 19 December 2012 09:01, thpr <thpr@...> wrote:
       

      "Sort of like a listener? This would on the face of it be a more common design pattern that I've seen used before."

      Yea, so assuming:
      thingy.sendMessage(id, "Danger!");

      ...the sendMessage method (which is effectively doing the translation from coreSpeak to UIspeak) wouldn't be much different than a "fire[blah]event" method from a class that has listeners. There would either be a single registered owner to be notified of incoming messages or there could be multiple listeners. That way the core can just say, here's something to deal with, and go on with whatever it was doing (or abort).

      "Another option could be to have an internal message queue (whatever implementation suits, a simple Queue or some sort od j.u.c collection if we're worried about threading) that the UI listens to?"

      I think there absolutely needs to be threading isolation, either because UI stuff all is supposed to happen in the UI thread or because you don't want multiple threads trying to write to the same log file at the same time (I've seen the results of that before... :) )

      This threading bit of course leads to the discussion of whether the core should gate on any listeners/consumers saying they have completed the processing of the message. That may be required in some cases and not in others (I was more trying to ask if we want to open this discussion than trying to have all the answers in one note :) ), but all of that magic of making the core wait (or not) should be hidden inside of the translating class (whatever thingy.getClass() returns)...

      TP.


    • James Dempsey
      Hi, In the core for many years and way predating the new UI we have pcgen.core.utils.ShowMessageDelegate.showMessageDialog(MessageWrapper) which handles this.
      Message 2 of 7 , Dec 18, 2012
      • 0 Attachment
        Hi,

        In the core for many years and way predating the new UI we have pcgen.core.utils.ShowMessageDelegate.showMessageDialog(MessageWrapper) which handles this. This is a singleton that works on a listener basis and has a fall back that if no listeners are registered it will just use println :)

        The new UI initialises this on startup with a listener of pcgen.gui2.util.ShowMessageGuiObserver.

        IMO UIDelegate should remain solely in the realm of the UI layer and specifically for use by the facade layer to push UI events.

        Cheers,
        James.

        On 19/12/2012 7:15 AM Martijn Verburg wrote
        I think the discussion is warranted - sorting out our internal messaging is an impt arch design point to solve....


        On 19 December 2012 09:01, thpr <thpr@...> wrote:
         

        "Sort of like a listener? This would on the face of it be a more common design pattern that I've seen used before."

        Yea, so assuming:
        thingy.sendMessage(id, "Danger!");

        ...the sendMessage method (which is effectively doing the translation from coreSpeak to UIspeak) wouldn't be much different than a "fire[blah]event" method from a class that has listeners. There would either be a single registered owner to be notified of incoming messages or there could be multiple listeners. That way the core can just say, here's something to deal with, and go on with whatever it was doing (or abort).

        "Another option could be to have an internal message queue (whatever implementation suits, a simple Queue or some sort od j.u.c collection if we're worried about threading) that the UI listens to?"

        I think there absolutely needs to be threading isolation, either because UI stuff all is supposed to happen in the UI thread or because you don't want multiple threads trying to write to the same log file at the same time (I've seen the results of that before... :) )

        This threading bit of course leads to the discussion of whether the core should gate on any listeners/consumers saying they have completed the processing of the message. That may be required in some cases and not in others (I was more trying to ask if we want to open this discussion than trying to have all the answers in one note :) ), but all of that magic of making the core wait (or not) should be hidden inside of the translating class (whatever thingy.getClass() returns)...

        TP.


      Your message has been successfully submitted and would be delivered to recipients shortly.