Ozben, I'm currently working on the upcoming Swixml Beta 6, which will not have any of your suggestions implemented. However, by the end of next week I should be able to spend some time playing with your idea - still are you sure that simply implementing and registering a new Converter doesn't do it for you?
Wolf -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Ozben Evren Sent: Tuesday, July 22, 2003 12:49 PM To: Forum@carlsbadcubes.com Subject: [Forum] Extending Swix parser with Decorator/plug-ins Hi, I've been working on an application that needs to be changed/extended/updated after deployment. Swix seems to be the perfect lib for the UI part, but I also need to develop some mechanism(s) that could be changed by the (power?)user.(*) To achieve this, I am using the client properties of the components to pass the information from the xml file to an extended SwingEngine. However, I think a better solution would be to add a plug-in system to the parser. This way, one can write plugins that will set-up model data, or controller logic by using tag values from the xml file. For example one can write a plug-in to handle this: <frame> ... <combobox id="customer-name-combo" model-class="com.acme.MyComboModel" event-handler-class="com.acme.MyItemListener" /> ... </frame> What I am proposing is something similar to the converters. Rather than converting values(String) of attributes to objects, one can convert custom attributes themselves to objects/behaviors. For example, the parser section that converts unknown attributes into client properties can be made as a plug-in using an interface similar to this: public interface ParserPlugin { public void handleAttributes(JComponent component, List attributes); } What do you think? (*): For the curious: I am working on a project that requires highly customizable user interfaces that are bound to a database with (mostly) unknown structure. I am required to develop dialogs/frames that can do search/filter/updates on the database and can be plugged into a program, or run as stand-alone applications. Moreover, most of these components need to be reusable, i.e. a user should be able to create a dialog for himself by just writing an xml file and maybe adding one or two java class files to a plugin directory. For example, I have a frame like this: <frame> ... <combo context="filter" table="customers" display-field="company" /> <combo context="filter" table="designers" display-field="name" /> <label text="Design Index:" /> <textfield context="filter" table="designs" field="designindex" /> ... <list id="design.list" context="filter" controls-context="display" controller-class="com.acme.ComponentUpdater" /> .... <label text="Created On:" /> <label context="display" table="designs" field="createdon" /> ... <button controls-context="filter" text="Filter" controller-class="com.acme.ResultListUpdater" controller-param="design.list" /> ... </frame> Which basically does this: When the dialog comes up, the first two combo boxes are filled in with available values (primary keys, and displayed values) from their corresponding tables. Then the user can select these values, or enter a design index in the text field, all of which makes up a query. When the "filter" button is pressed it signals the controller-class with the parameter "controls-context". controller class goes through all the components in the context="filter", makes up the query, and fills in the JList with id=result.list. If user selects one of those entries, the controller-class (ComponentUpdater) of the list object traverses all the components in context="display" and updates their values from the database that are related to that selection. It is a bit complex, and I am trying to simplify it. Suggestions, comments are welcome. Ozben Evren Software Engineer Dimensional Impressions (818) 379 7039 x19 ------------------------------------ I love deadlines. I especially like the whooshing sound they make as they go flying by. -Douglas Adams
