pivot-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Brown <gkbr...@mac.com>
Subject Re: builder in progress
Date Mon, 13 Apr 2009 14:50:13 GMT
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" <noelgrandin@gmail.com> wrote:
>On Mon, Apr 13, 2009 at 16:23, Greg Brown <gkbrown@mac.com> 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.
>
>

Mime
View raw message