List for Users of Carlsbad Cubes' Technologies and Products
Tue, 11 Oct 2005 01:47:45 -0700
List for Users of Carlsbad Cubes' Technologies and Products <Forum@carlsbadcubes.com> schrieb am 11.10.05 07:18:41: > I suggest that the Localizer should not be a parameter of Converter.convert(). > By the time Converter.convert(Class type, Attribute attr) would be > called, any kind > of localization / indirection will have already taken place in the Parser. I agree with you, this would IMHO ease the implementation of converters somewhat and helps to avoid code duplications as in each converter handling probably localized attributes. I assume you would like to change the Converter.convert(Class, Attribute, Localizer) to Converter.convert(Class, Attribute, Object localizedAttributeValue), correct? > That would be better separation of concerns for the Converter > implementations... Yes, quite right. Regarding your idea of having "by references"-references in addition to the usual "by value"-references, I think it's a good idea as well. Vitali, your problem to have automated tests for missing I18N keys could be resolved by an alternative implementation of StringConverter or PrimitiveConverter or even an alternative localizer (which is unfortunatly not changable (e.g. through a parameter to a constructor of SwingEngine) nor an interface). These changes would require more modifications to SwixML as IMHO acceptable for a new minor release because the change of Converter interface breaks existing converters. The change of SwingEngine constructor signature could be covered through an alternate constructor without parameter. Perhaps even the whole procedure of finding the correct converter could be made more flexible e.g. allowing converters to convert to arbitary method calls like methods with more than one parameter and the like. But this is definitly another subject. I will have a look at it this weekend. Yours, Frank > > Regards, > -b. > > > On 10/10/05, List for Users of Carlsbad Cubes' Technologies and > Products <Forum@carlsbadcubes.com> wrote: > > Hi all, > > > > This does sound as a not bad idea to me. > > The main reason is that it makes localization (or more generally > > indirection) explicit. > > Indeed, looking at the following snippet you can't really say whether > > "ok" is a text or a key in the localization file. > > ... > > <button text="ok" /> > > .. > > while this is selfexplained > > <button text="@ok" /> > > > > Second, this approach makes it very easy to write some automated tool > > to check whether every key in swixml descriptor has corresponding > > entry in localization file. > > This could be an issue while refactoring large applications. > > > > Thanks, > > Vitali > > > > > > 2005/9/26, List for Users of Carlsbad Cubes' Technologies and Products > > <Forum@carlsbadcubes.com>: > > > Hi there, > > > > > > I'm a new SwixML user and would like to submit > > > a proposal. > > > > > > The Need: > > > ======== > > > > > > Looking at how the StringConverter classes localizes > > > attribute values using essentially a properties file, it > > > seems to me it would be useful if we could extend this > > > model so that *all* attribute values could be indirected, > > > when necessary. > > > > > > In the following snippet ... > > > > > > <frame name="mainframe" > > > size="640,480" > > > title="S W I X M L" > > > defaultCloseOperation="JFrame.EXIT_ON_CLOSE" > > > defaultLookAndFeelDecorated="true" > > > bundle="ui.locale.swix"> > > > > > > <menubar name="menubar"> > > > <menu name="filemenu" text="mus_File" font="SansSerif--12"> > > > <menuitem name="mi_new" > > > text="mus_New" font="SansSerif--12" > > > icon="ui/icons/new.gif" > > > mnemonic="VK_N" > > > accelerator="control N" > > > action="newAction" /> > > > > > > ...the font attribute assignment (font="SansSerif--12") > > > will likely be sprinkled liberally elsewhere across the > > > file. If I change that font value in one place, I will > > > likely need to change the other font values elsewhere > > > in the file, also. So you can see a basic need for > > > indirection: I need a central place to be able to assign > > > font values to a whole bunch of components. > > > > > > Besides fonts, other component attributes might need > > > to be centralized in one place (e.g. the background > > > color). > > > > > > The Problem: > > > ========== > > > > > > I *could* try... > > > > > > <frame name="mainframe" > > > size="640,480" > > > title="S W I X M L" > > > defaultCloseOperation="JFrame.EXIT_ON_CLOSE" > > > defaultLookAndFeelDecorated="true" > > > bundle="ui.locale.swix"> > > > > > > <menubar name="menubar"> > > > <menu name="filemenu" text="mus_File" font="menu.font"> > > > <menuitem name="mi_new" > > > text="mus_New" font="menu.font" > > > icon="ui/icons/new.gif" > > > mnemonic="VK_N" > > > accelerator="control N" > > > action="newAction" /> > > > > > > ...with... > > > > > > menu.font = SansSerif--12 > > > > > > ...defined in the swix.properties file. > > > > > > This wont work of course, because only StringConverter > > > applies the PropertyResourceBundle to the parsed attribute > > > values. > > > > > > > > > Proposal: > > > ======= > > > > > > If an attribute value starts with an escape character, say '@' > > > (perhaps with '@@' escaping itself), then the *parser*--not the > > > converter, attempts to "localize" the XML attribute value before > > > passing it off to the converter. > > > > > > Alternatively, we could forget about the special escape character > > > and attempt to "localize" all attribute values, willy nilly. Personally, > > > I'm not for this: it would be better to make the indirection more > > > explicit: right now, in order to see if a string is localized, you have > > > to check the properties file; you can't tell just from looking at the > > > XML. > > > > > > What do you think? > > > > > > -Babak > > > > > > _______________________________________________ > > > Forum mailing list > > > Forum@carlsbadcubes.com > > > http://carlsbadcubes.com/mailman/listinfo/forum_carlsbadcubes.com > > > > > > > _______________________________________________ > > Forum mailing list > > Forum@carlsbadcubes.com > > http://carlsbadcubes.com/mailman/listinfo/forum_carlsbadcubes.com > > > > _______________________________________________ > Forum mailing list > Forum@carlsbadcubes.com > http://carlsbadcubes.com/mailman/listinfo/forum_carlsbadcubes.com _______________________________________________ Forum mailing list Forum@carlsbadcubes.com http://carlsbadcubes.com/mailman/listinfo/forum_carlsbadcubes.com