It sounds like this serializer might have some hard-coded dependencies on
specific WTK classes. If so, might it be better to attempt to generalize it
such that we could actually put the serialization code in
WTKXSerializer#writeObject()? I'm not suggesting that this is definitely the
right approach - but I do think it is worth considering.
On Monday, April 13, 2009, at 10:35AM, "Noel Grandin" <[email protected]>
wrote:
>On Mon, Apr 13, 2009 at 16:23, Greg Brown <[email protected]> wrote:
>>>Includes aren't handled yet, but I don't expect them to be a problem -
>>>a marker node in the tree should suffice.
>>
>> Possibly. Did you actually implement WTKXSerializer#writeObject(), or are
>> you handling it elsewhere?
>>
>I wrote my own WTKX_OutputSerializer, borrowing heavily from the
>original WKTXSerializer.
>
>>
>>>Non-primitive properties seems to be working fine. Not sure why this
>>>should be a problem?
>>
>> For example, Component#getLocation() returns a Dimensions instance. How are
>> you writing this to the output stream? It could theoretically be written as
>> follows (if we supported a String-based setter, which we could add in the
>> future):
>>
>> <Component location="{x:0, y:0}">
>>
>It uses this style. Insets, CornerRadii and Color are also handled
>idiomatically.
>
>
>>
>>>Nested collections I haven't seen in any wtkx files yet, so that won't work.
>>
>> Couple of examples:
>>
>> - ListView#getListData() - do we always want to serialize this value?
>> Probably not.
>> - Component#getStyles() - we probably do want to always serialize this.
>>
>Styles is serialised, and it is smart enough to only serialise style
>data that is non-default.
>
>ListData is not handled yet.
>
>
