Re: Re: SwiXML robustitude

Hi Chuck,
Good suggestions you are making here.
Allowing to register Actions etc. would also help to decouple and 
enable to have Actions implemented elsewhere but as inner classes.
I will keep this idea in the top 10 of things to do for the next 
distribution.

Wolf


--
Wolf Paulus

[email protected]

C a r l s b a d  C u b e s
Dedicated to Excellence


On Jan 14, 2005, at 7:51 AM, Chuck Dillon wrote:

> Frank Meissner wrote:
>>>>
>>>>> Q5) How well does it support GUI glue functionality?  ...  Can 
>>>>> object A reference object B in the XML?
>>>>
>>>> This is not a builitin facility in swixml. You may try to solve 
>>>> this through
>>>> custom converters, but I'm not sure whether this is possible...
>>>
>>> Unfortunate, it would be a powerful feature.
>> But not that easy to implement if the requirements are somewhat 
>> advanced. E.g. I had the problem I wanted to disable a button if the 
>> number of lines is less than one. This is not that trivial 
>> (describable in XML) but perhaps it's out of your intended scope...
>
> Let me preface the following comments with admitting I'm basing them 
> on limited information about SwiXML.  I've been looking at the samples 
> and browsing the JavaDoc.  But since I can't find any detail 
> functional description of it's capabilities I'm assuming what's in the 
> samples is what there is.
>
> From the samples it appears the XML references Java Objects by name 
> using tags like "id" and "action".  This direct reference by name is a 
> useful feature but if it is the only way to bind the XML to the code 
> it is too limiting IMHO.  It forces me to mirrow the GUI structure 
> with Java code which has marginal utility.  What is needed is an 
> indirect way of referencing objects so that I don't need Java code 
> that shadows the GUI structure.  I want to be able to build the 
> majority of my action code so that it can be applied to the GUI by 
> indirect reference so that my business logic is as agnostic as 
> possible about the GUI.
>
> What I'm suggesting is that the engine needs an indirect way to 
> revolve what tags like "id" and "action" are referring to.  I envision 
> the SwingEngine class (or something within) to have a methods  like:
>  - registerActionClass(String nameToBeUsedInXML,Class class)
>  - registerActionInstance(String nameToBeUsedInXML,AbstractAction 
> action)
>  - registerDataObject(String nameToBeUsedInXML,Object object)
> Then I can create an action class or instance or a data object, 
> register it and use it whereever I want in the GUI.  I'm not seeing 
> this kind of capability.  Is it there?
>
> Another powerful feature would be a means of specifying data to be 
> passed to actions in the XML.  The API could, for example, include an 
> extension of ActionEvent that carries a payload of data defined in 
> XML.  It could be as simple as a Properties object.
>
> In the Java code I do:
>   engine.registerActionClass("changefg",ForegroundChanger.getClass());
>   engine.registerDataObject("blue",Color.blue);
> In the XML I specify a button:
>   <solelabel Foreground="green">Some Label</label>
>   <button enabled="true" Action="changefg(somelabel,blue)"/>
>
> The action declares that an instance of "changefg" class should be 
> created and a reference to the "somelabel" label and the "blue" data 
> object should be passed to it via a SwiXMLActionEvent, or some such.
>
> The above wouldn't be difficult to implement.  What's needed is a few 
> hashes, a definition of the precedence of each possible class of 
> things that can be referenced and logic to do the lookups in order of 
> precedence.  The event could simply hold a Properties object or a hash 
> containing the objects declared in the XML and what they resolved to.
>
> It's also useful to allow declaration of multiple action handlers.
>
> One last, extrememly useful, feature would be to add Swing object 
> create time actions...
>   <button enabled="true" Action="whatever" Create="registerAsAThingy"/>
> The Create attribute is like Action except that it gets "fired" 
> immediately after the button is created.  What this does is saves the 
> applications code from having to lookup a bunch of GUI objects by 
> name.  It reduces the direct litereal String references in the Java 
> code and can save a lot of code.
>
>
>>>
>>> How does SwiXML support things like radio button groups without such 
>>> a utility?
>> Groups of radio buttons *are* supported. There is no magic (or, at 
>> least, not much ;)) ...
>
> So in XML I can declare a container with CheckBoxes in it.  And IN XML 
> I can declare a ButtonGroup and the CheckBoxes I want it to control. 
> As separate XML declarations?  IOW, in the ButtonGroup declaration I 
> can reference the CheckBox objects declared elsewhere in XML?
>
> Thanks for the information.  Sorry if all of the above is already 
> there and I'm just missing it.
>
> -- ced
>
>> Frank
>
>
> -- 
> Chuck Dillon
> Senior Software Engineer
> NimbleGen Systems Inc.
>
>
> _______________________________________________
> Forum mailing list
> [email protected]
> http://carlsbadcubes.com/mailman/listinfo/forum_carlsbadcubes.com