You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@pivot.apache.org by Greg Brown <gk...@mac.com> on 2010/07/15 20:44:52 UTC
Backwards compatibility for WTKXSerializer
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 to support both .json and .resources extensions in the Resources class). So I'm not sure how much value preserving only support for .wtkx files will offer.
My vote would be to include a detailed 1.5 -> 2.0 migration guide in the README or RELEASE-NOTES that explain specifically what has changed and what needs to be updated.
Thoughts?
Re: Backwards compatibility for WTKXSerializer
Posted by Greg Brown <gk...@mac.com>.
> 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. That was misleading - the new location more clearly reflects its intent and capabilities.
Re: Backwards compatibility for WTKXSerializer
Posted by Michael Allman <ms...@allman.ms>.
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 like to be able to get a
>> reference to the serializer used to build a given component if at all.
>> That would in fact be incredibly helpful as I would like access to the
>> serializer's named objects after the fact.
>
> You can do this via the Bindable interface. In Pivot 2.0, initialize()
> is defined as follows:
>
> http://svn.apache.org/repos/asf/pivot/trunk/core/src/org/apache/pivot/beans/Bindable.java
>
> The first argument contains the named objects.
I will try that when I move to the Pivot 2.0 branch. I'm on 1.5 now.
Cheers,
Michael
Re: Backwards compatibility for WTKXSerializer
Posted by Greg Brown <gk...@mac.com>.
> 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 to the serializer used to build a given component if at all. That would in fact be incredibly helpful as I would like access to the serializer's named objects after the fact.
You can do this via the Bindable interface. In Pivot 2.0, initialize() is defined as follows:
http://svn.apache.org/repos/asf/pivot/trunk/core/src/org/apache/pivot/beans/Bindable.java
The first argument contains the named objects.
Re: Backwards compatibility for WTKXSerializer
Posted by Michael Allman <ms...@allman.ms>.
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 was nothing specific to the org.apache.pivot.wtk package in
>> there. Moving it to org.apache.pivot.beans required no refactoring other
>> than changing the name.
>
> I don't think I expressed myself well. 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. :)
>
> If it isn't UI-centric, I consider that an opportunity for growth. If Pivot
> has a markup language for making UI-building easier, it should make some
> assumptions about its problem domain to simplify that task.
>
> 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.
>
> On top of BXML would be a DSL that makes some UI-centered assumptions. It
> might make some assumptions about the use of some style language, like CSS,
> to make it easier to work with. It might use CSS inheritence and cascading.
> It might allow closer integration with scripting (*cough PIVOT-573 ahem*) and
> richer event-driven binding support.
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
to the serializer used to build a given component if at all. That would
in fact be incredibly helpful as I would like access to the serializer's
named objects after the fact.
Michael
Re: Backwards compatibility for WTKXSerializer
Posted by Greg Brown <gk...@mac.com>.
>>>> 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 MessageBus in trunk. If not, let me know.
>
> Anyway, I think using MessageBus for event bubbling is---to use an old cliche---like hammering a square peg into a round hole. For one thing, it uses classes for event/message keys. I want to select on a message name---a string. For another, MessageBus is global. A subscriber does not know the source of the message without examining the message. I would like to be able to subscribe for messages from an event dispatcher of my choosing. Thus, I can have multiple event dispatchers dispatch the same type of event and take a different action depending on which event dispatcher dispatched the event. Finally, there's bubbling itself. MessageBus does not provide support for bubbling, probably because it doesn't know anything about the component hierarchy. I would like to be able to "consume" events in such a way that ancestor listeners do not receive them.
OK.
>>> Also, being able to bind to arbitrary properties on suitably annotated objects would be very helpful
>>
>> This is already supported. The BXML annotation supports an "id" property you can use to bind to any named object in the BXML file. It just defaults to the name of the member variable.
>
> I think we're referring to two different kinds of binding. I'm referring to the event-driven kind. Are you?
I am talking about mapping BXML variables to class members. I guess I don't understand what you mean by event-driven binding.
Re: Backwards compatibility for WTKXSerializer
Posted by Greg Brown <gk...@mac.com>.
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 listeners. In fact, I suspect that is why they were originally created, since (way back) Java was originally about AWT.
They really are handy in this context because they get around the potential memory leak issues associated with hard references. If you attach an anonymous inner class instance as a listener and don't maintain a reference to it yourself, the listener will be garbage collected with the event source.
BXML listener list elements serve a similar purpose. When you define a listener as follows, you are creating something that acts like an anonymous inner class, since it can see the other (effectively private) variables declared within the page:
<PushButton>
<buttonPressListeners>
function buttonPressed(button) {
...
}
</buttonPressListeners>
<PushButton>
Syntactically, this might be a bit cleaner than an anonymous inner class, but the downside is obviously that the script is uncompiled.
G
On Jul 26, 2010, at 7:16 PM, Michael Allman wrote:
> 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 looks like
>
> public interface EventListener {
> public void invoke(Event e);
> }
>
> and my event listener factory looks like
>
> static MethodEventListener create(Object target, String listenerMethodName) {
> final Method listenerMethod;
>
> try {
> Class<?> targetClass = target.getClass();
> listenerMethod = targetClass.getMethod(listenerMethodName, Event.class);
> } catch (RuntimeException ex) {
> throw ex;
> } catch (Exception ex) {
> throw new RuntimeException(ex);
> }
>
> return new MethodEventListener(target, listenerMethod);
> }
>
> Cheers,
>
> Michael
Re: Backwards compatibility for WTKXSerializer
Posted by Michael Allman <ms...@allman.ms>.
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 looks like
public interface EventListener {
public void invoke(Event e);
}
and my event listener factory looks like
static MethodEventListener create(Object target, String listenerMethodName) {
final Method listenerMethod;
try {
Class<?> targetClass = target.getClass();
listenerMethod = targetClass.getMethod(listenerMethodName, Event.class);
} catch (RuntimeException ex) {
throw ex;
} catch (Exception ex) {
throw new RuntimeException(ex);
}
return new MethodEventListener(target, listenerMethod);
}
Cheers,
Michael
Re: Backwards compatibility for WTKXSerializer
Posted by Greg Brown <gk...@mac.com>.
> nobody likes defining anonymous classes
I like anonymous inner classes. They are great for defining internal event handlers.
RE: Backwards compatibility for WTKXSerializer
Posted by aappddeevv <aa...@verizon.net>.
The EventBus and spring integration are already in existence. For
parent-tree items, I put in the tree events but that's not a focus as I
really only cared about consistent definitions of triggers, styles and
templates which does not require a full event capability.
I used AOP to make the API consistent across all components everywhere and
consistent in BXML specification. You don't have to do it that way as point
out and as has been discussed on the list.
-----Original Message-----
From: Michael Allman [mailto:msa@allman.ms]
Sent: Monday, July 26, 2010 7:04 PM
To: dev@pivot.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
through a component attribute. The component dispatcher does bubbling.
There's a factory for turning Java methods into event listeners, because
nobody likes defining anonymous classes. That's pretty much it.
The event bus you describe with routing rules and whatnot sounds more
complicated than what I need. Thanks for the tip, though. What's your
name?
Michael
On Mon, 26 Jul 2010, aappddeevv wrote:
> Message bus for inter-object communication versus parent-tree messaging
> conceptually is the same, however, parent-tree messaging can be simplified
> somewhat and built to be more optimized then a general-purpose message-bus
> approach. There is general message bus, like spring integration, message
> brokering like EventBus/e4 and then parent-tree bubbling like wpf. In
terms
> of routing strategy, parent-tree is pretty straight forward. Routing based
> on strings/ids/header like EventBus can be managed well and adopting
general
> purpose mechanisms like spring integration is much more challenging.
>
> You can implement a bubbling router using attached properties, however,
for
> robustness, something more like WPF's style is a bit better and I switched
> to AOP for a couple of reasons when I implemented events. You can create
the
> synthetic events by attaching listeners to all of the listeners in a
> component (and other objects) and translate that into event message types.
> One balance between the listener style in pivot and data-driven events is
> that you have to flatten the listeners into event types...not hard at all.
> When I built pivot-aspects, I flattened all the listeners into two common
> APIs for PCL and events in order to go data driven and do event
processing.
> Doing this was the only way to be uniform throughout although there are
> probably 2-3 ways to do it. Pivot already bubbles some events such as keys
> and mousing which covers a lot of what people are usually after.
>
> I found that MessageBus does not solve enough of a problem to warrant its
> use for many scenarios. It works fine for simple messaging though which is
> what it was designed to do. EventBus has richer support for inter-object
> communication and works fine and is easy to start using. I did not find
> bubbling of a general event to be critical yet but flattening was
important
> for triggering.
>
> If you are looking for bubbling, I suggest you look at AOP to implement it
> cleanly although build complexity increases. It would also allow to
> implement handlers consistently without API requirements. I implemented
> handlers for Execute/CanExecute and a pluggable handler framework so you
can
> have your own handler protocol but tastes vary. Because mouse/keys are
> already handled okay, the need for robust bubbling was decreased as
> supporting triggers required less infrastructure. In some cases where a
> bubbling event could be helpful, walking the parent-child tree is a
> quick-easy alternative to full event support.
>
> Here's some starting code for "tree events"
>
>
>
> /**
> * A class for tree events to inherit from. Essentially, TreeEvent is the
> "type" of event and this class is an instance of a TreeEvent.
> Subclasses should extend for their event types.
> *
> */
> public class TreeEventInstance {
>
> public TreeEvent event;
> /**
> * The logical element that raised the event.
> */
> public Component source;
> /**
> * The visual that raised the event.
> */
> private Component originalSource;
> /**
> * The last sender of this event.
> */
> private Object sender;
> private boolean handled = false;
> private Map<String, Object> attributes = new HashMap<String, Object>();
> ....
>
>
> /**
> * An event occurring in the tree. There are no
> * interface or method requirements on the handlers for
> * receiving these events. A tree event is
> * really a message that has a potentially
> * predefined notion of the direction to route. Instead of the class
> * of the object indicating a payload type, essentially the id
> * indicates a payload type in the message.
> *
> */
> public class TreeEvent {
>
> /**
> * The routing strategy. This helps indicate
> * how it should be routed when the context of routing up or down
> * is well-defined.
> *
> */
> public enum Routing {
> /**
> * Event goes up the tree.
> */
> UP,
> /**
> * Event goes down the tree.
> */
> DOWN,
> /**
> * Event is only raised on the element and does not route up or down.
> */
> DIRECT
> };
> public String id;
> public Class<?> ownerType;
> public Routing routing;
> ...
>
>
> -----Original Message-----
> From: Michael Allman [mailto:msa@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 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 MessageBus in trunk. If not, let me know.
>
> Anyway, I think using MessageBus for event bubbling is---to use an old
> cliche---like hammering a square peg into a round hole. For one thing, it
> uses classes for event/message keys. I want to select on a message
> name---a string. For another, MessageBus is global. A subscriber does
> not know the source of the message without examining the message. I would
> like to be able to subscribe for messages from an event dispatcher of my
> choosing. Thus, I can have multiple event dispatchers dispatch the same
> type of event and take a different action depending on which event
> dispatcher dispatched the event. Finally, there's bubbling itself.
> MessageBus does not provide support for bubbling, probably because it
> doesn't know anything about the component hierarchy. I would like to be
> able to "consume" events in such a way that ancestor listeners do not
> receive them.
>
>>> Also, being able to bind to arbitrary properties on suitably annotated
>>> objects would be very helpful
>>
>> This is already supported. The BXML annotation supports an "id" property
>> you can use to bind to any named object in the BXML file. It just
>> defaults to the name of the member variable.
>
> I think we're referring to two different kinds of binding. I'm referring
> to the event-driven kind. Are you?
>
> Cheers,
>
> Michael
>
RE: Backwards compatibility for WTKXSerializer
Posted by Michael Allman <ms...@allman.ms>.
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
through a component attribute. The component dispatcher does bubbling.
There's a factory for turning Java methods into event listeners, because
nobody likes defining anonymous classes. That's pretty much it.
The event bus you describe with routing rules and whatnot sounds more
complicated than what I need. Thanks for the tip, though. What's your
name?
Michael
On Mon, 26 Jul 2010, aappddeevv wrote:
> Message bus for inter-object communication versus parent-tree messaging
> conceptually is the same, however, parent-tree messaging can be simplified
> somewhat and built to be more optimized then a general-purpose message-bus
> approach. There is general message bus, like spring integration, message
> brokering like EventBus/e4 and then parent-tree bubbling like wpf. In terms
> of routing strategy, parent-tree is pretty straight forward. Routing based
> on strings/ids/header like EventBus can be managed well and adopting general
> purpose mechanisms like spring integration is much more challenging.
>
> You can implement a bubbling router using attached properties, however, for
> robustness, something more like WPF's style is a bit better and I switched
> to AOP for a couple of reasons when I implemented events. You can create the
> synthetic events by attaching listeners to all of the listeners in a
> component (and other objects) and translate that into event message types.
> One balance between the listener style in pivot and data-driven events is
> that you have to flatten the listeners into event types...not hard at all.
> When I built pivot-aspects, I flattened all the listeners into two common
> APIs for PCL and events in order to go data driven and do event processing.
> Doing this was the only way to be uniform throughout although there are
> probably 2-3 ways to do it. Pivot already bubbles some events such as keys
> and mousing which covers a lot of what people are usually after.
>
> I found that MessageBus does not solve enough of a problem to warrant its
> use for many scenarios. It works fine for simple messaging though which is
> what it was designed to do. EventBus has richer support for inter-object
> communication and works fine and is easy to start using. I did not find
> bubbling of a general event to be critical yet but flattening was important
> for triggering.
>
> If you are looking for bubbling, I suggest you look at AOP to implement it
> cleanly although build complexity increases. It would also allow to
> implement handlers consistently without API requirements. I implemented
> handlers for Execute/CanExecute and a pluggable handler framework so you can
> have your own handler protocol but tastes vary. Because mouse/keys are
> already handled okay, the need for robust bubbling was decreased as
> supporting triggers required less infrastructure. In some cases where a
> bubbling event could be helpful, walking the parent-child tree is a
> quick-easy alternative to full event support.
>
> Here's some starting code for "tree events"
>
>
>
> /**
> * A class for tree events to inherit from. Essentially, TreeEvent is the
> "type" of event and this class is an instance of a TreeEvent.
> Subclasses should extend for their event types.
> *
> */
> public class TreeEventInstance {
>
> public TreeEvent event;
> /**
> * The logical element that raised the event.
> */
> public Component source;
> /**
> * The visual that raised the event.
> */
> private Component originalSource;
> /**
> * The last sender of this event.
> */
> private Object sender;
> private boolean handled = false;
> private Map<String, Object> attributes = new HashMap<String, Object>();
> ....
>
>
> /**
> * An event occurring in the tree. There are no
> * interface or method requirements on the handlers for
> * receiving these events. A tree event is
> * really a message that has a potentially
> * predefined notion of the direction to route. Instead of the class
> * of the object indicating a payload type, essentially the id
> * indicates a payload type in the message.
> *
> */
> public class TreeEvent {
>
> /**
> * The routing strategy. This helps indicate
> * how it should be routed when the context of routing up or down
> * is well-defined.
> *
> */
> public enum Routing {
> /**
> * Event goes up the tree.
> */
> UP,
> /**
> * Event goes down the tree.
> */
> DOWN,
> /**
> * Event is only raised on the element and does not route up or down.
> */
> DIRECT
> };
> public String id;
> public Class<?> ownerType;
> public Routing routing;
> ...
>
>
> -----Original Message-----
> From: Michael Allman [mailto:msa@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 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 MessageBus in trunk. If not, let me know.
>
> Anyway, I think using MessageBus for event bubbling is---to use an old
> cliche---like hammering a square peg into a round hole. For one thing, it
> uses classes for event/message keys. I want to select on a message
> name---a string. For another, MessageBus is global. A subscriber does
> not know the source of the message without examining the message. I would
> like to be able to subscribe for messages from an event dispatcher of my
> choosing. Thus, I can have multiple event dispatchers dispatch the same
> type of event and take a different action depending on which event
> dispatcher dispatched the event. Finally, there's bubbling itself.
> MessageBus does not provide support for bubbling, probably because it
> doesn't know anything about the component hierarchy. I would like to be
> able to "consume" events in such a way that ancestor listeners do not
> receive them.
>
>>> Also, being able to bind to arbitrary properties on suitably annotated
>>> objects would be very helpful
>>
>> This is already supported. The BXML annotation supports an "id" property
>> you can use to bind to any named object in the BXML file. It just
>> defaults to the name of the member variable.
>
> I think we're referring to two different kinds of binding. I'm referring
> to the event-driven kind. Are you?
>
> Cheers,
>
> Michael
>
RE: Backwards compatibility for WTKXSerializer
Posted by aappddeevv <aa...@verizon.net>.
Message bus for inter-object communication versus parent-tree messaging
conceptually is the same, however, parent-tree messaging can be simplified
somewhat and built to be more optimized then a general-purpose message-bus
approach. There is general message bus, like spring integration, message
brokering like EventBus/e4 and then parent-tree bubbling like wpf. In terms
of routing strategy, parent-tree is pretty straight forward. Routing based
on strings/ids/header like EventBus can be managed well and adopting general
purpose mechanisms like spring integration is much more challenging.
You can implement a bubbling router using attached properties, however, for
robustness, something more like WPF's style is a bit better and I switched
to AOP for a couple of reasons when I implemented events. You can create the
synthetic events by attaching listeners to all of the listeners in a
component (and other objects) and translate that into event message types.
One balance between the listener style in pivot and data-driven events is
that you have to flatten the listeners into event types...not hard at all.
When I built pivot-aspects, I flattened all the listeners into two common
APIs for PCL and events in order to go data driven and do event processing.
Doing this was the only way to be uniform throughout although there are
probably 2-3 ways to do it. Pivot already bubbles some events such as keys
and mousing which covers a lot of what people are usually after.
I found that MessageBus does not solve enough of a problem to warrant its
use for many scenarios. It works fine for simple messaging though which is
what it was designed to do. EventBus has richer support for inter-object
communication and works fine and is easy to start using. I did not find
bubbling of a general event to be critical yet but flattening was important
for triggering.
If you are looking for bubbling, I suggest you look at AOP to implement it
cleanly although build complexity increases. It would also allow to
implement handlers consistently without API requirements. I implemented
handlers for Execute/CanExecute and a pluggable handler framework so you can
have your own handler protocol but tastes vary. Because mouse/keys are
already handled okay, the need for robust bubbling was decreased as
supporting triggers required less infrastructure. In some cases where a
bubbling event could be helpful, walking the parent-child tree is a
quick-easy alternative to full event support.
Here's some starting code for "tree events"
/**
* A class for tree events to inherit from. Essentially, TreeEvent is the
"type" of event and this class is an instance of a TreeEvent.
Subclasses should extend for their event types.
*
*/
public class TreeEventInstance {
public TreeEvent event;
/**
* The logical element that raised the event.
*/
public Component source;
/**
* The visual that raised the event.
*/
private Component originalSource;
/**
* The last sender of this event.
*/
private Object sender;
private boolean handled = false;
private Map<String, Object> attributes = new HashMap<String, Object>();
....
/**
* An event occurring in the tree. There are no
* interface or method requirements on the handlers for
* receiving these events. A tree event is
* really a message that has a potentially
* predefined notion of the direction to route. Instead of the class
* of the object indicating a payload type, essentially the id
* indicates a payload type in the message.
*
*/
public class TreeEvent {
/**
* The routing strategy. This helps indicate
* how it should be routed when the context of routing up or down
* is well-defined.
*
*/
public enum Routing {
/**
* Event goes up the tree.
*/
UP,
/**
* Event goes down the tree.
*/
DOWN,
/**
* Event is only raised on the element and does not route up or down.
*/
DIRECT
};
public String id;
public Class<?> ownerType;
public Routing routing;
...
-----Original Message-----
From: Michael Allman [mailto:msa@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 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 MessageBus in trunk. If not, let me know.
Anyway, I think using MessageBus for event bubbling is---to use an old
cliche---like hammering a square peg into a round hole. For one thing, it
uses classes for event/message keys. I want to select on a message
name---a string. For another, MessageBus is global. A subscriber does
not know the source of the message without examining the message. I would
like to be able to subscribe for messages from an event dispatcher of my
choosing. Thus, I can have multiple event dispatchers dispatch the same
type of event and take a different action depending on which event
dispatcher dispatched the event. Finally, there's bubbling itself.
MessageBus does not provide support for bubbling, probably because it
doesn't know anything about the component hierarchy. I would like to be
able to "consume" events in such a way that ancestor listeners do not
receive them.
>> Also, being able to bind to arbitrary properties on suitably annotated
>> objects would be very helpful
>
> This is already supported. The BXML annotation supports an "id" property
> you can use to bind to any named object in the BXML file. It just
> defaults to the name of the member variable.
I think we're referring to two different kinds of binding. I'm referring
to the event-driven kind. Are you?
Cheers,
Michael
Re: Backwards compatibility for WTKXSerializer
Posted by Michael Allman <ms...@allman.ms>.
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 referring to MessageBus in trunk. If not, let me know.
Anyway, I think using MessageBus for event bubbling is---to use an old
cliche---like hammering a square peg into a round hole. For one thing, it
uses classes for event/message keys. I want to select on a message
name---a string. For another, MessageBus is global. A subscriber does
not know the source of the message without examining the message. I would
like to be able to subscribe for messages from an event dispatcher of my
choosing. Thus, I can have multiple event dispatchers dispatch the same
type of event and take a different action depending on which event
dispatcher dispatched the event. Finally, there's bubbling itself.
MessageBus does not provide support for bubbling, probably because it
doesn't know anything about the component hierarchy. I would like to be
able to "consume" events in such a way that ancestor listeners do not
receive them.
>> Also, being able to bind to arbitrary properties on suitably annotated
>> objects would be very helpful
>
> This is already supported. The BXML annotation supports an "id" property
> you can use to bind to any named object in the BXML file. It just
> defaults to the name of the member variable.
I think we're referring to two different kinds of binding. I'm referring
to the event-driven kind. Are you?
Cheers,
Michael
Re: Backwards compatibility for WTKXSerializer
Posted by Greg Brown <gk...@mac.com>.
>> 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 suitably annotated objects would be very helpful
This is already supported. The BXML annotation supports an "id" property you can use to bind to any named object in the BXML file. It just defaults to the name of the member variable.
Re: Backwards compatibility for WTKXSerializer
Posted by Michael Allman <ms...@allman.ms>.
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, even cleaner than it is
>> now.
>
> If you want to generate an intermediate hierarchy, you can do that in
> any number of ways: XML DOM, JSON, or even BXML - but you'll face the
> same performance issue as with your CSS approach: it requires walking
> the tree multiple times. BXML allows you to construct and populate the
> tree in a single pass.
>
>> On top of BXML would be a DSL that makes some UI-centered assumptions.
>> It might make some assumptions about the use of some style language,
>> like CSS, to make it easier to work with. It might use CSS inheritence
>> and cascading. It might allow closer integration with scripting
>> (*cough PIVOT-573 ahem*) and richer event-driven binding support.
>
> All of these things are already supported. Even PIVOT-573 could be
> easily supported if we wanted to. The DSLs are defined by the beans
> themselves - for example, the reason JSON can be used in a "styles"
> attribute is because Component#setStyles(String) is coded to parse JSON.
> Any bean class can define its own DSL using a similar approach.
>
>> There is a lot of crap in MXML. I'm not holding it up as an example of
>> greatness, but at the same time it does have some very useful,
>> time-saving features, some of which I noted above.
>
> Can you provide some specific examples of things that MXML does that
> BXML/WTK does not? Clearly some features were missing prior to Pivot
> 2.0:
>
> - default properties
> - dynamic data binding
> - stylesheet support
>
> However, all of these features have since been added. What other aspects
> of MXML would you like to see added to BXML?
Simple support for listening for custom bubbling events. In my current
implementation, it looks like
Events.listeners="{ eventName1: 'eventListenerName1', eventName2: 'eventListenerName2' }"
which isn't horrible but it's a lot more verbose than
eventName1="eventListenerName1" eventName2="eventListenerName2"
Also, being able to bind to arbitrary properties on suitably annotated
objects would be very helpful as that is the primary means for model
objects like domain objects to notify its listeners in general but its
views and validators in particular of its changes. I'm "working" on an
implementation of that. Don't know when I will "finish" it.
Can't think of anything else off the top of my head, but if I do you know
you will hear from me! :)
Michael
Re: Backwards compatibility for WTKXSerializer
Posted by Greg Brown <gk...@mac.com>.
> 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 you want to generate an intermediate hierarchy, you can do that in any number of ways: XML DOM, JSON, or even BXML - but you'll face the same performance issue as with your CSS approach: it requires walking the tree multiple times. BXML allows you to construct and populate the tree in a single pass.
> On top of BXML would be a DSL that makes some UI-centered assumptions. It might make some assumptions about the use of some style language, like CSS, to make it easier to work with. It might use CSS inheritence and cascading. It might allow closer integration with scripting (*cough PIVOT-573 ahem*) and richer event-driven binding support.
All of these things are already supported. Even PIVOT-573 could be easily supported if we wanted to. The DSLs are defined by the beans themselves - for example, the reason JSON can be used in a "styles" attribute is because Component#setStyles(String) is coded to parse JSON. Any bean class can define its own DSL using a similar approach.
> There is a lot of crap in MXML. I'm not holding it up as an example of greatness, but at the same time it does have some very useful, time-saving features, some of which I noted above.
Can you provide some specific examples of things that MXML does that BXML/WTK does not? Clearly some features were missing prior to Pivot 2.0:
- default properties
- dynamic data binding
- stylesheet support
However, all of these features have since been added. What other aspects of MXML would you like to see added to BXML?
Re: Backwards compatibility for WTKXSerializer
Posted by Michael Allman <ms...@allman.ms>.
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.wtk package
> in there. Moving it to org.apache.pivot.beans required no refactoring
> other than changing the name.
I don't think I expressed myself well. 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. :)
If it isn't UI-centric, I consider that an opportunity for growth. If
Pivot has a markup language for making UI-building easier, it should make
some assumptions about its problem domain to simplify that task.
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.
On top of BXML would be a DSL that makes some UI-centered assumptions.
It might make some assumptions about the use of some style language, like
CSS, to make it easier to work with. It might use CSS inheritence and
cascading. It might allow closer integration with scripting (*cough
PIVOT-573 ahem*) and richer event-driven binding support.
> XAML works the same way - it isn't tied to WPF. On the other hand, MXML
> is tied to the mx namespace, which I think is a limitation. It makes the
> markup language more complex and more difficult to maintain, because it
> allows for "special cases". We try to stay away from special-case code
> in Pivot.
There is a lot of crap in MXML. I'm not holding it up as an example of
greatness, but at the same time it does have some very useful, time-saving
features, some of which I noted above.
Cheers,
Michael
Re: Backwards compatibility for WTKXSerializer
Posted by Greg Brown <gk...@mac.com>.
> 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 org.apache.pivot.beans required no refactoring other than changing the name.
XAML works the same way - it isn't tied to WPF. On the other hand, MXML is tied to the mx namespace, which I think is a limitation. It makes the markup language more complex and more difficult to maintain, because it allows for "special cases". We try to stay away from special-case code in Pivot.
Moving BXML support to the core package allows it to be used in other contexts. For example, I may want to use it on the server (or in some other headless context, such as a background thread). You may not have a currently use case for that, but other developers may.
Re: Backwards compatibility for WTKXSerializer
Posted by Michael Allman <ms...@allman.ms>.
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 BXML and make WTKXSerlializer a subclass of BXMLSerializer. Not just
for backwards compatibility, but for future development of WTKX.
Cheers,
Michael
On Thu, 15 Jul 2010, Greg Brown wrote:
> 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 to support both .json and .resources extensions in
> the Resources class). So I'm not sure how much value preserving only
> support for .wtkx files will offer.
>
> My vote would be to include a detailed 1.5 -> 2.0 migration guide in the README or RELEASE-NOTES that explain specifically what has changed and what needs to be updated.
>
> Thoughts?
>
RE: Backwards compatibility for WTKXSerializer
Posted by "Roger L. Whitcomb" <Ro...@ingres.com>.
+1 for including a detailed migration guide. I got bit by the small
change to attributes from 1.4 to 1.5 :)
Roger Whitcomb | Architect, Engineering | Roger.Whitcomb@ingres.com |
Ingres | 500 Arguello Street | Suite 200 | Redwood City | CA | 94063 |
USA +1 650-587-5596 | fax: +1 650-587-5550
-----Original Message-----
From: Greg Brown [mailto:gkbrown@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 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 to support both .json and .resources extensions in
the Resources class). So I'm not sure how much value preserving only
support for .wtkx files will offer.
My vote would be to include a detailed 1.5 -> 2.0 migration guide in the
README or RELEASE-NOTES that explain specifically what has changed and
what needs to be updated.
Thoughts?