If an event is dispatched by a service should I include the word 'service' in the event class name? For Example TwitterServiceEvent. The same applies to Models and Mediators.
In robotlegs book "Actionscript Developers Guide to Robotlegs" they are not using it that way:
_remoteService.addEventListener(TwitterEvent.OVER_CAPACITY, dispatchOverCapacity);
But if you want it and it helps you, you can have it, why not.
I use signals, but when I name signals, I name them the same as the command is named with different suffix:
ConfigureViewSignal
ConfigureViewCommand
Also, did you check out AS3 Signals and SignalCommandMap for robotlegs?
https://github.com/robertpenner/as3-signals
https://github.com/robertpenner/robotlegs-extensions-SignalCommandMap
Related
In my Robotlegs app service results often have to be persisted in models. This creates event pairs that have identical payload types:
to carry the data from service to command,
to carry the data from model to mediator
I'm wondering how to name these events. Imagine I have a service:
FooService.getProducts()
Then I have a model:
BarModel.setProducts()
BarModel.getProducts()
What is the best way to name the event dispatched by the service after it retrieves the product collection?
What is the best way to name the event dispatched by the model after BarModel.setProducts() has been invoked?
Or maybe I should use a single event with two different types:
public class ProductEvent extends Event
{
public const SERVICE_PRODUCT_CHANGE:String = 'serviceProductChange';
public const MODEL_PRODUCT_CHANGE:String = 'modelProductChange';
...
With Services I like events/signals that indicate success or failure, since services often make contact with external resources which are prone to fail for various reasons.
MyServiceLoadSuccess and MyServiceLoadFailure
Even if your service quietly fails the idea of success makes sense for services, I think.
With models they tend to need to know how to transform data they can also fail but in reality they are making decisions and then preparing data for views or other models and are often just sending update.
MyModelUpdate
Obviously your specific situation is important to the semantics you choose but this is a pattern that I've found helpful and generally applicable to all kinds of situations.
I've made up my own naming scheme that answers my question.
First of all, most often events are used to propagate data between actors:
service > model
model > mediator
mediator > model
Secondly, different events carry different data types.
Thirdly, the same data often must be passed two times: service > model > mediator.
Based on this I've decided to name my event like this:
<class>Event_<payload>
Where class is the name of the class that dispatches the event and payload is the name of the public property that changed. For example:
ProductServiceEvent_products
ProductModelEvent_products
ProductViewEvent_products
Each event has only one type called CHANGE.
I am having trouble wiring up an event listener to a fl.transitions.Transition.
Is it possible to somehow view all the events an object fires? That way I could check I am using the correct event (and possible view better ones to use).
The easiest is to override the dispatchEvent method in classes where you want to intercept events.
You can find the classes in %CS_ROOT%\Common\First Run\Classes\mx\transitions\easing\.
You can also create a subclass of EventDispatcher with a custom dispatchEvent-implementation and use that as a subclass for all classes where you'll be wanting to intercept events.
greetz
back2dos
The problem is, you have to have an event type to listen for. The only way to do this is to add listeners for all the possible events.
Now, you can add a handler with an indeterminate event type, such as:
private function myUniversalHandler(event:*) : void {
trace(event.type);
trace(event.constructor.toString());
}
And this will report any event passed to it. Nevertheless, it simply won't be called unless it is listening for an event of a particular type. And adding all those listeners is a lot of work to go through. Better to study the events available to you from whatever class you are dispatching the vent from.
I would look at TransitionManager, and the events allTransitionsOutDone and allTransitionsInDone which it dispatches. I haven't used these, but my understanding of their function matches what you seem to be looking for.
checkout the online reference, you should see there all events (and inherited events) of a Class.
On a side note if you are using flex you might be using mx.states.Transition
There is no way, at runtime, to find out all the events that fire from a component. You'll have to explore the component source code to get a complete list.
Reviewing the ASDocs, as others have suggested, is a good way to get a handle on the documented events of a component; and in most cases you'll be able to find one to suit your needs.
You cannot programmatically get a list of all events fired by any given object. You can however get a list of all events fired by a standard library object (that are part of it's public interface) from its documentation (cilck on the show inherited events link) and decide whether you're using the appropriate one.
I have scratched my head quite a bit on this issue as well.
The answer is this
you can get a list of all event listeners that an object is listening to only if attached though MXML
if not attached through MXML you cannot see the events an object is listening to (attached by AS)
if you want to see all the events an object is listening to you can check for hasEventListener although this is a long coding way
another efficient way (if you can use it, I couldn't) is to monkey patch the framework and create a dictionary of listeners for every object.
you can accomplish that by patching FlexSprite and overriding the addEventListener function.
you should keep in mind, this will not work when you are loading the framework through RSL.
I have been reading about "Fat Controllers" but most of the articles out there focus on pulling the service/repository layer logic out of the controller. However, I have run into a different situation and am wondering if anyone has any ideas for improvement.
I have a controller with too many actions and am wondering how I can break this down into many controllers with fewer actions. All these actions are responsible for inserting/updating/removing objects that all belong to the same aggregate. So I'm not quiet keen in having a seperate controller for each class that belongs to this aggregate...
To give you more details, this controller is used in a tabbed page. Each tab represents a portion of the data for editing and all the domain model objects used here belong to the same aggregate.
Any advice?
Cheers,
Mosh
For all your tabs you can use one action, that have an tab parameter, that indicate what data you need to return.
The controller job is to cast this string tab into enum type variable. Then the tab will be send to the repository, and the repository job is to return data in response to the tab value.
The controller should do its job through to services: Input Validator and Mapper.
The mapper service job is to map the user input (typically strings) into actual typed value (int, System.DateTime, enum types, etc).
The validator job is to check that the input is valid.
Following this principles should keep your controllers really tiny.
If you wanted something simple and easy I'd suggest just splitting up the controller into partial classes based on the tabs. Of course, it's still a fat controller there's just some obvious separation between the various tab functionalities.
I just started using Swiz, and, it seems like Swiz forces you to create classes with weak encapsulation. Swiz requires all event handlers to be public in order to mediate events.
Assume that component 'A' dispatches a few events, which I want to listen to in component 'B'. Traditionally, I'll just add event listeners on 'A' in 'B' and all the event handlers in 'B' can be kept private. However, if, I am using Swiz, I need to make all the handlers, mediating events, public.
Am I missing something here, is there a way to bypass this problem. I really, don't want to pollute the public interface of my class.
Thanks.
As I mentioned on the mailing list, there is no way around it, unfortunately. Since there is no way to access private members of classes, the only way B can use private event handlers for events
from A is if addEventListener() is called from within B. Since Swiz is obviously not operating within your classes, it has no way to access those members.
Swiz aims to keep your application code as free from references (including inheritance) to Swiz classes as possible. Therefore, you can think of it as configuring your app "from the outside". Unlike the JVM, Flash Player simply allows no access to private members, so for Swiz to interact with your code, it has to be public.
You can also create a custom namespace that makes them not necessarily public, but not private either. I use what Openflux originally did:
[Mediate(event="UserEvent.LOGIN")]
metadata function loginHandler(user:User):void
{
... with namespace
}
[Mediate(event="UserEvent.LOGOUT")]
public function logoutHandler(user:User):void
{
... without namespace
}
You then have to add use namespace metadata into the Swiz Processors, and probably to their metadata MediateQueue. As long as the namespace is imported in the correct classes, something that's dynamically referring to a method will work:
so in the setUpMetadataTag method in MediateProcessor (or at the top of the class):
use namespace metadata;
// bean.source[mediateTag.host.name]
// service["loginHandler"] and service["logoutHandler"] both work
addMediatorByEventType( mediateTag, bean.source[ mediateTag.host.name ], eventType );
Makes the code clean, and keeps things from being public. But some people think it's too much work :).
Best,
Lance
For something outside of and decoupled from the class to invoke the handler, the method can't be private. So you have two choices: make them public and let Swiz mediate them (and reap all the loose coupling), or keep them private and don't use the event mediation. If you think it's worth it (and most do), use it. If you don't, don't.
"Swiz requires all event handlers to be public in order to mediate events."
That's true, but Swiz's strength is that it doesn't force any (more or less) design choices on you, it just provides powerful tools (dependency injection, event mediation, et al) that you can choose to apply where you think appropriate.
Using Swiz does not require the use of the [Mediate] tag at all - you can still use addEventListener() and listen from private methods as you normally would (as I'm sure you're well aware). As far as I can tell, the Swiz event mediation is intended primarily for use with system/application level events. If you're calling event listeners within a single component, or within close family components, you would usually use the standard event listeners. To communicate between individual, otherwise-unrelated components, you can handle the message with Swiz's mediator.
In short, in any case where you have access to private event listeners (i.e. within close components), you probably wouldn't be using [Mediate] to capture the event, and so that listener could remain private. When you're using the [Mediate] tag, the event handler is generally in a completely separate location in the application (e.g. presenter -> controller) where it couldn't practically be private in any case.
I may be slightly off, but this is how it appears to me. Swiz may encourage weak encapsulation in some situations, but to me it offers greater modularisation overall.
I want to verify that a generated class (single entity or collection) from an O/RM tool is data binding compatible.
I read that supported data binding types in WCF are: one time, one way, two way, one way from source in WCF. But how about "old school" .NET 1.1 data binding ?
It looks kind of difficult to check in code what kind of data binding support there is. You also have difference in runtime and design time data binding support. When reading some webpages I read different kind of implementations: implement IList, IComponent, INotifyPropertyChanged, IBindingList.... pffffff I don't know exactly where to look for...
You can databind to virtually any class. Let's imagine you create a very simple class, with a few properties, say for instance, Person with a Name and Age. I am talking about a plain simple class with absolutely nothing fancy about it.
If you create an instance of Person, you can do several things with it, and I will assume you are working with Windows Forms, but this mostly applies to other frameworks:
- You can bind its properties to properties of controls.
- You can bind it to datagrids, lists, etc. In the former case you can set mappings of which properties bind to which columns. In the latter, which property is displayed in the list, which property is the value selected by the user.
- Even better, you can bind it to a bindingSource.
Binding a single instance to a grid or a list isn't that useful, so what usually is done is that you create a list of instances and bind those to the grid. Even more correct is to bind the list to a bindingsource and the grid to the bindingsource also.
You can see a good article here about how to do all this.
Now, about all the interfaces you mention, they all only add more value to the databinding experience. Let's talk about a few of them.
INotifyPropertyChanged. Person is not less "databindable" than any other object if it does not implement this interface. What instances of Person are not able to do, however, is notify the controls their properties are bound to that the latter have changed. Try this: Bind the Name property of a Person instance to the Text property of a TextBox. Create a button that when clicked changes the value of that instance's Name. You will see the TextBox does not update after clicking the button. If, on the other hand, you implement INotifyPropertyChanged and have the setter of the Name property raise the PropertyChangedEvent that is defined by the interface, after repeating the experience, you will see that the textbox is updated automatically.
IEnumerable. If instead of a single Person, you want to databind not to a set of people, you can create a list of people and databind to that list. Let's take for instance, List lst = new List(); How do the databinding controls like datagrid, bindingSource, etc., know you want to bind to a set of Person(s) and not to the properties of lst itself? It is because List implements IEnumerable. So, whenever you bind these controls to an instance of anything that implements IEnumerable, the controls know that you intend to bind not to the properties of the list, but to the instances the list refers to. How do they know the type of objects the list contains? To be more generic and support any type of IEnumerable implementation, they just check the type of the first element in the list and assume all others are equal.
IBindingList: Even if Person implements IPropertyChanged, if you group instances of Person into a List bind that list to a control and, by code, change the value of a property of one of the instances, you will see nothing happen in the screen. This happens because Person is notifying, not the binding source, but the list. But the list wasn't made for databinding, so it is not listening, nor propagating the event to the control. Lists that implement IBindingList, like BindingList, offer a better databinding support precisely by listening to the PropertyChangedEvent events of their contents and propagating them up to the databound control.
I am affraid I have given you no way of determining if an object is databoundable, because virtually all them are, but I hope I've given you a way of determining different levels of databinding support (INotifyPropertyChanged and IBindingList). I am assuming you know how to check for these via reflection.
Any instance of a class with properties is data bindable. (in fact instances of any class with fields or properties at all are data bindable)
Using reflection in .NET makes it very easy to discover/use data in an object. (at a small performance cost)
In order to answer this question you'd need to provide the specific usage scenarios you'll be encountering.
Rui gives some good explanation of different common data binding patterns, but each of them is for solving specific problems.
The right answer is always dependent on the context.
:)