Re: First post

Rick,
First of all, welcome! Great to have you on this list.

Your feedback is highly appreciated and putting the ability to model 
state into Swixml makes sense and also may not be too complicated to 
implement. Sorry for not responding earlier but there was just too much 
going on at work and with putting out the Swixml 1.1, which some 
developers really needed.
Your suggestion will be considered for the next major - hope to see 
more posting from you.

	Wolf Paulus

C a r l s b a d   C u b e s
mailto:[email protected]

CONFIDENTIALITY NOTICE:
This message is intended only for the use of the individual or entity 
to which it is addressed, and may contain information that is 
privileged, confidential and exempt from disclosure under applicable 
law.
If you are not the intended recipient, please contact the sender by 
reply email and destroy all copies of the original message.
On Feb 17, 2004, at 1:15 AM, Rick Jelliffe wrote:

> Hi
>
> I thought, since Wolf(?) was kind enough to quote from my blog
> on his pages, I should send email to thank all the people who
> have been working on SwiXML. As one of the original contributors
> to XML, it is great to see it used in this way.
>
> My company, Topologi, is just about to release the Professional
> Edition of our high-end XML markup product. You can see snapshots
> of the menus at http://www.topologi.com/products/tpro/screenshots.html
> but please don't link to them: we have a lot of menus.
>
> We only use SwiXML currently for for the frames and menus.
> Previously we used Visual Age Visual Builder for these. I liked
> using Visual Age (which has now migrated to Eclipse in some form)
> but it generated terribly verbose code all into a single file.
>
> By moving to SwiXML, we have
>  * reduced our source code size by 500K (unbelievable, but that is 
> Visual Age!)
>  * improved maintainability
>  * seemingly improved our start-up time, though we have other
> changes so I cannot measure it.
>
> Looking at the archives for SwiXML, here are some comments on
> some of recent issues: I think speed is good now so implementing
> SAX might be an unnecessary diversion; also, I think it would be
> good to have bindings to other libraries such as JGoodies, but not
> built-into the core jar (this is because I think that, ultimately,
> there needs to be co-operation and co-ordination between different
> open source software efforts to make a competitive platform
> for desktops: Sun is still thinking in terms of applets and
> servers.)
>
> Some-one also recently asked about a dispatching layer for actions:
> what we do is that every action name has a prefix and there is
> an ActionListener for each prefix: so the dispatcher gets each action
> then forwards it to the appropropriate ActionListener depending
> on the prefix. So menu items with an "EDITOR_" prefix get routed
> to the ActionListener for the editor. This decreases coupling
> very neatly.
>
> The area I suggest that SwiXML could be enhanced may seem at
> first to be out-of-scope: when developing middle-to-large
> sized applications, the issue of adjusting the interface to
> accomodate the current capabilities of the objects selected
> become important. This is primarily enabling and disabling
> menus, but can also be changing icons, colors and sizes.
>
> The trouble is that SwiXML hides a lot of complexity of
> Swing, but then when you have this kind state-behaviour,
> you need to move to code again. I think there is a
> declarative way that would be quite simple to implement
> reflectively.
>
> Add to SwiXML something like
>
> <!ELEMENT stateSets ( stateSet )+ >
> <!ELEMENT stateSet  ( state )+ >
> <!ELEMENT state     ( menu | menuItem | ... )+ >
>
> <!ATTRIBUTE stateSets
> 	name CDATA #IMPLIED >
> <!ATTRIBUTE stateSets
> 	name CDATA #REQUIRED >
> <!ATTRIBUTE state
> 	name CDATA #REQUIRED >
>
> For example, here is a stateSet to reflect that you don't
> want the Save menu item to be enabled before you have
> altered the file.
>
> <stateSet name="FileState">
> 	<state name="fresh">
> 		<menuItem name="mi_save" enabled="false" />
> 		<menuItem name="mi_undo" enabled="false" />
> 		<menuItem name="mi_redo" enabled="false" />
> 	</state>
> 	<state name="dirty">
> 		<menuItem name="mi_save" enabled="true" />
> 		<menuItem name="mi_undo" enabled="true" />
> 		<menuItem name="mi_redo" enabled="true" />
> 	</state>
> 	<state name="clean">
> 		<menuItem name="mi_save" enabled="true" />
> 		<menuItem name="mi_undo" enabled="false" />
> 		<menuItem name="mi_redo" enabled="false" />
> 	</state>
> </stateSet>
>
> The idea is that each state contains, not a new object,
> but a set of properties that get applied on an existing
> object. So my code can just say
>
>   mySwiXMLGUI.setState("FileState.dirty");
>
> and then the properties from that states will be set to
> the values supplied. Note that this only needs to use the
> same reflection that SwiXML currently uses.
>
> It is very simple: no stacks, no listeners, no undo,
> no conditions, no enforced transitions.  But because
> a state is just a bundle of property values, there
> can be several stateSets at the same time: conflict
> is the user's business. For example, in our application
> we would use a stateSet at least for the kind of Tab selected,
> for the fileState, for validation state, for
> visual mode, and for pen selection mode, if they were available.
>
> I think this would give SwiXML quite a leg-up compared
> to other GUI systems. Anyway, that is would be at the
> top-of my wishlist, because it would simplify and expose
> the GUI state, allowing Swing-specific properties to
> be removed more from application code.
>
> Cheers
> Rick Jelliffe
>
>
> _______________________________________________
> Forum mailing list
> [email protected]
> http://carlsbadcubes.com/mailman/listinfo/forum_carlsbadcubes.com