apache.org
Subject: RE: Backwards compatibility for WTKXSerializer
I've already built something that works well for me. Essentially, it
consists of events, event listeners, and event dispatchers. Component
event dispatchers are tied in one-to-one correspondence with components
thro
That makes sense. Adapter classes can help here, but what you are describing
sounds a bit like what you get with delegates in C#.
I was going to add that it took me a long time to appreciate anonymous inner
classes, and so far the only real use case I have found for them is internal
event liste
On Mon, 26 Jul 2010, Greg Brown wrote:
nobody likes defining anonymous classes
I like anonymous inner classes. They are great for defining internal
event handlers.
Ahhh... I'm just referring to using a method instead of a class that
defines a single method. My event listener interface loo
> nobody likes defining anonymous classes
I like anonymous inner classes. They are great for defining internal event
handlers.
id;
public Class ownerType;
public Routing routing;
...
-Original Message-
From: Michael Allman [mailto:m...@allman.ms]
Sent: Monday, July 26, 2010 12:29 AM
To: dev@pivot.apache.org
Subject: Re: Backwards compatibility for WTKXSerializer
On Mon, 19 Jul 2010, Greg Brown wrote:
What ot
public Class ownerType;
public Routing routing;
...
-Original Message-
From: Michael Allman [mailto:m...@allman.ms]
Sent: Monday, July 26, 2010 12:29 AM
To: dev@pivot.apache.org
Subject: Re: Backwards compatibility for WTKXSerializer
On Mon, 19 Jul 2010, Greg Brown wrote:
>>> What
What other aspects of MXML would you like to see added to BXML?
>>>
>>> Simple support for listening for custom bubbling events.
>>
>> As I mentioned in a previous email, I think a pub/sub API is probably better
>> suited to the use case you describe.
>
> I guess you're referring to Messag
On Mon, 19 Jul 2010, Greg Brown wrote:
What other aspects of MXML would you like to see added to BXML?
Simple support for listening for custom bubbling events.
As I mentioned in a previous email, I think a pub/sub API is probably
better suited to the use case you describe.
I guess you're
>> What other aspects of MXML would you like to see added to BXML?
>
> Simple support for listening for custom bubbling events.
As I mentioned in a previous email, I think a pub/sub API is probably better
suited to the use case you describe.
> Also, being able to bind to arbitrary properties on
On Mon, 19 Jul 2010, Greg Brown wrote:
I think one way to approach this goal is to consider BXML as a sort of
intermediate language---an input to a serializer that builds a
component hierarchy. You could keep that completely clean as a sort of
souped-up javabean serialization format, hell, ev
On Mon, 19 Jul 2010, Greg Brown wrote:
There's another enhancement to the serialization of WTKX => "Component
instance" that would be useful: lossless transformation. There's some
useful information in the wtkx file (maybe bxml, I don't know that yet)
that you don't get back from it. I'd lik
> There's another enhancement to the serialization of WTKX => "Component
> instance" that would be useful: lossless transformation. There's some useful
> information in the wtkx file (maybe bxml, I don't know that yet) that you
> don't get back from it. I'd like to be able to get a reference t
On Mon, 19 Jul 2010, Michael Allman wrote:
On Fri, 16 Jul 2010, Greg Brown wrote:
Well, personally I'm not too happy with the direction BXMLSerializer is
taking things... from UI-centric to UI-agnostic.
I think you may have missed the point. WTKX was never UI-centric, except in
name. There
> WTKX was never UI-centric, but it looked like it, and being a "subproject" of
> WTK it had the whiff of UI-ness to it. :)
Forgot to comment on this - that's actually one of the reasons we moved it.
Calling it WTKX and including it in the WTK JAR obviously implied that it was
tied to WTK. Tha
> I think one way to approach this goal is to consider BXML as a sort of
> intermediate language---an input to a serializer that builds a component
> hierarchy. You could keep that completely clean as a sort of souped-up
> javabean serialization format, hell, even cleaner than it is now.
If yo
On Fri, 16 Jul 2010, Greg Brown wrote:
Well, personally I'm not too happy with the direction BXMLSerializer is
taking things... from UI-centric to UI-agnostic.
I think you may have missed the point. WTKX was never UI-centric, except
in name. There was nothing specific to the org.apache.pivot.
> Well, personally I'm not too happy with the direction BXMLSerializer is
> taking things... from UI-centric to UI-agnostic.
I think you may have missed the point. WTKX was never UI-centric, except in
name. There was nothing specific to the org.apache.pivot.wtk package in there.
Moving it to
Well, personally I'm not too happy with the direction BXMLSerializer is
taking things... from UI-centric to UI-agnostic. But I think I've made
this argument in other messages so I'm not going to get into it here.
I guess the best compromise I can think of is to keep WTKX as an extension
of BX
-Original Message-
From: Greg Brown [mailto:gkbr...@mac.com]
Sent: Thursday, July 15, 2010 11:45 AM
To: dev@pivot.apache.org
Subject: Backwards compatibility for WTKXSerializer
Given the recent changes to the resource bundle naming conventions, I am
wondering if trying to preserve backwards
Given the recent changes to the resource bundle naming conventions, I am
wondering if trying to preserve backwards compatibility with WTKXSerializer is
sort of an empty gesture. Anyone using resources is going to have to rename
those files anyways (it didn't look like there would be an easy way
20 matches
Mail list logo
