Re: A setClient method in SwixEngine

Ted,
Don't be afraid of using a SwingEngine for each of your panels. :-)
Swixml was built to be fast to only use very little resources.
In fact, static resources are being used often.
For instance, the SwingTaglibrary is implemented a s a Singleton:
http://www.swixml.org/apidocs/org/swixml/SwingTagLibrary.html
Now, in the SwingEngine we this:
private final TagLibrary taglib = SwingTagLibrary.getInstance();
The getter returns just a ref. to the Singleton.
i.e. mySwingEngine.getTaglib()

The idmap is not a static member (used to be until a couple months ago)
so no need really to mess around with that. Don't start "optimizing" before
you have to.

I don't know how you could lose a registered Tag just buy instantiating a
new SwingEngine.
Anyway, here is a method that I have recently used to register a couple of
custom Tags.
This is done once in the applications lifetime - a SwingEngine is instanced
many times.

  public static void registerTags() {
    if (REGISTER_TAGS) {
      //  register resource bundle
      SwingEngine.setResourceBundleName(Constant.BUNDLE_NAME);

      //  register converters
      PrimitiveConverter.addConstantProvider(CharSetConstants.class);
      PrimitiveConverter.addConstantProvider(SearchModeConstants.class);

      //  register tags
      SwingEngine swix = new SwingEngine();
      swix.getTaglib().registerTag("Button", XButton.class);
      swix.getTaglib().registerTag("FormattedLabel", FormattedLabel.class);
      swix.getTaglib().registerTag("Legend", Legend.class);
      swix.getTaglib().registerTag("LocationBar", LocationBar.class);
      swix.getTaglib().registerTag("MenuItem", LOJMenuItem.class);
      swix.getTaglib().registerTag("Menu", LOMenu.class);
      swix.getTaglib().registerTag("OKCancelPanel", OKCancelPanel.class);
      swix.getTaglib().registerTag("SearchBar", SearchBar.class);
      swix.getTaglib().registerTag("StatusPanel", StatusPanel.class);
      swix.getTaglib().registerTag("TextField", RestrictedTextField.class);
      swix.getTaglib().registerTag("ToolBarButton", LOToolBarButton.class);
      REGISTER_TAGS = false;
    }
  }

I just parsed the code for the afore mentioned project:
    "new SwingEngine(" was found 62 times,
    the forget() method is never explicitly called.


Wolf

"Ted Hesselroth" <[email protected]> wrote in message
news:<[email protected]>...
> Wolf,
>
> I am using swixml for a medium-size java application, and have found it
> to be very useful. I like the fact that it is quite focussed and works
> well. I was pretty impressed upon reading the source code, too.
>
> The application I am writing is highly modularized. Using swixml I have
> been able to write generic model-view-controller functions and have the
> view components filled in upon reading an xml file. I have a dozen or so
> different panels, and they can all use the same class for the view. For
> each panel I have only to write the swixml file and the action listeners.
>
> For modularities sake I want the action listeners to be in separate
> classes. Therefore I am using the swix engine construction which allows
> the "client" to be specified. This requires the creation of a new swix
> engine object every time a new panel is created. I'm concerned about the
> speed as the application grows larger. Would it be possible to include a
> setClient call in SwixEngine so that the client could be changed in an
> existing swixengine? Seeing how client is used in the code, it seems so,
> assuming that idmap would be cleared in this step. Another reason for
> this addition is in the use of registerTag in this situation. I'd like
> the individual modules to be able to register custom components and have
> them be available to all subsequent panels, but this information gets
> lost for a new swix engine occurrence unless I somehow maintain it and
> reregister everthing. So I think the setClient and a tag that registers
> custom components would be very powerful.
>
> Another suggestion would be to make comboboxes easier, some alternative
> to coding a special class for each combo box. A list of strings as nodes
> or an attribute would be fine. As mentioned above, my goal is to have a
> single view class and a single action class for each panel.
>
> Thanks for writing a very nice package, and please feel free to explain
> if I am not fully understanding its use.
>
> Ted Hesselroth

"Ted Hesselroth" <[email protected]> wrote in message
news:[email protected]...
> Wolf,
>
> I am using swixml for a medium-size java application, and have found it
> to be very useful. I like the fact that it is quite focussed and works
> well. I was pretty impressed upon reading the source code, too.
>
> The application I am writing is highly modularized. Using swixml I have
> been able to write generic model-view-controller functions and have the
> view components filled in upon reading an xml file. I have a dozen or so
> different panels, and they can all use the same class for the view. For
> each panel I have only to write the swixml file and the action listeners.
>
> For modularities sake I want the action listeners to be in separate
> classes. Therefore I am using the swix engine construction which allows
> the "client" to be specified. This requires the creation of a new swix
> engine object every time a new panel is created. I'm concerned about the
> speed as the application grows larger. Would it be possible to include a
> setClient call in SwixEngine so that the client could be changed in an
> existing swixengine? Seeing how client is used in the code, it seems so,
> assuming that idmap would be cleared in this step. Another reason for
> this addition is in the use of registerTag in this situation. I'd like
> the individual modules to be able to register custom components and have
> them be available to all subsequent panels, but this information gets
> lost for a new swix engine occurrence unless I somehow maintain it and
> reregister everthing. So I think the setClient and a tag that registers
> custom components would be very powerful.
>
> Another suggestion would be to make comboboxes easier, some alternative
> to coding a special class for each combo box. A list of strings as nodes
> or an attribute would be fine. As mentioned above, my goal is to have a
> single view class and a single action class for each panel.
>
> Thanks for writing a very nice package, and please feel free to explain
> if I am not fully understanding its use.
>
> Ted Hesselroth