|
The presentation model (PM) approach is the recommended view layer architecture for Swiz. The PM has to be declared in the BeanProvider and the recommended way is to declare it as a Prototype so the PM will only be created (instantiated) when the corresponding view is added to the stage. The view gets the PM injected and binds data from it and delegates all interactions (events) to the PM. The PM is a independent unit and only gets data injected from the application layer. Having no logic in the view itself also means that you only have to unit test your PM. |
Labels:
None
22 Comments
comments.show.hideMay 19, 2010
Anonymous
The line in MyPresentationModel.as
should be changed to
Jul 19, 2010
Anonymous
MyView.mxml uses model.listLabelField - this definitition is missing in the model.
Jul 19, 2010
Prashant Pachouri
MyView.mxml uses model.listLabelField - this definitition is missing in the model.
Aug 31, 2010
Anonymous
This doesn't make much sense. Logic for the view should be handled by controller not presentation model. There should be Controller for every view which should respond to clicks and events, call service when necessery and update model. Model itself should not have any methods for handeling events or clicks but just hold data.
Aug 31, 2010
Brian Kotek
If you'd like to discuss why we recommend the Presentation Model pattern, feel free to bring this up on the mailing list. But it sounds like you're confusing a model with the Presentation Model pattern: http://martinfowler.com/eaaDev/PresentationModel.html
Sep 21, 2010
Anonymous
Can some one please fix this code for instance this is missing and what is it for?labelField="
"
and
<s:Button includeIn="DiagnosticView, DisplayView" label="Edit" click="model.edit()"
there is no model.edit()
And as far as how the examples are described is confusing to the example code throughout the whole getting started guide.
It would be really nice if all the coded steps would carry you along from the beginning from quick start. it would help a lot
and also yes it looks like you are showing a example of when you click a button you are doing an evaluation to see what
the current state is and then changing the state to the else state and when that happens a change event is fired that will
be injected to the data provider for label control and effect what ever objects.label that are in the view. But what if you had
many buttons that changed some value or fired a command or for that matter view states other than if a condition is true or not?
Thanks in advanced P.S. This is coming from a person who has bin drowning in Cairngorm for the last two years and I absolutely
hate it but on the flip side it works pretty dam well.
Oct 12, 2010
Anonymous
I think there must be an assumption that any person wishing to use Swiz most likely has experience with the Spring Framework ... thus, only sparse, poorly written documentation is available here.
I have no Java experience, but I did work in Cairngorm for a year and it was very difficult. Fortunately, I work with a developer with Java experience, so was able to get the Swiz framework in place and it is a pleasure to work with. I just wish there were more documentation because I would like to 'fill in the holes' as it were so I could do things my own way if I desire. So even with my six months in Swiz, I find the documentation here seriously lacking. (not to mention the 'page not found' links.
Oct 17, 2010
Brian Kotek
It would be much more helpful if you could state WHAT you would like to see more of in terms of documentation, and what "page not found" links you are referring to.
Dec 13, 2010
Anonymous
There has to be a better way than adding script to the view. This is reversed, the presenter should know everything about the view and the view should careless about the presenter.
Maybe I am not thinking straight but isn't the idea behind passive view to have a view that does not know how to do anything, then have a presenter class that responds to UI interaction? This interaction may be passed on to a controller to process data, etc. For instance something akin to http://blogs.adobe.com/paulw/archives/2007/11/presentation_pa_6.html
Dec 14, 2010
Brian Kotek
This isn't the Passive View pattern, it is the Presentation Model pattern (http://martinfowler.com/eaaDev/PresentationModel.html). They handle the problem in different ways. As you say, the Passive View holds a reference to the view and acts on it directly, while the Presentation Model is NOT coupled to the view (from the pattern summary, "Represent the state and behavior of the presentation independently of the GUI controls used in the interface").
Dec 14, 2010
Anonymous
Ah. You are correct. Thank you for the clarification. I think I was spending way to much time looking at code. So why is Presentation Model preferred/recommend as a best practice over Passive View? I realize it is probably a preference thing, but if it makes sense for me to convert to Presentation Model for using Swiz over Passive View then I would like to understand why. Thanks in advance.
Dec 14, 2010
Brian Kotek
I'm happy to keep discussing this but please move it to the mailing list (link in the sidebar). The wiki comments are not a great place for an ongoing discussion. Thanks.
Dec 14, 2010
Anonymous
I did a little more searching and found the answer. It requires an additional library from Brian Kotek, but it works with the 4.0 and 4.1 SDK. Thanks for the post Brian. Also, I have to ask, why is this functionality not in Swiz 1.x?
Here is the link: http://www.briankotek.com/blog/index.cfm/2010/5/19/Swiz-10RC-Released-So-heres-an-updated-example-custom-ViewMediator-and-more
Dec 14, 2010
Brian Kotek
There are plenty of things that won't be included in the framework to prevent bloat, and that's exactly what the custom metadata features of Swiz are for. I really created the ViewMediator as an experiment in using the custom metadata, but I don't actually use it because I don't want models or controllers coupled to views.
Feb 21, 2011
Anonymous
I think ! it's better to replace, in your "MyView.mxml" file, the line below :
dispatchEvent( new BeanEvent( BeanEvent.TEAR_DOWN_BEAN, model ) );
by this line :
model.dispatcher.dispatchEvent( new BeanEvent( BeanEvent.TEAR_DOWN_BEAN, model ) );
=> We must use the dispatcher (processor) of swiz framework.
=> If you keep this line, you should have a memory leak when you use the metatag [Inject] with bind property at true !
=> In this case the PresentationModel is never teardown.
Feb 21, 2011
Brian Kotek
Events dispatched from the view should have bubbles set to true, so that they bubble up the display list and are processed by Swiz, the same way events dispatched through the injected dispatcher are. As long as the event will bubble (which BeanEvent does), dispatching it from the view works fine.
Feb 22, 2011
Anonymous
The constructor of BeanEvent has no bubble's parameter.
How would you like to set bubble to true with BeanEvent from the view ?
Feb 22, 2011
Brian Kotek
It is set to bubble automatically. https://github.com/swiz/swiz-framework/blob/master/src/org/swizframework/events/BeanEvent.as
Apr 15, 2011
Anonymous
You can use AutoTearDown metadata tag if you want to automate tearing down presentation model.
Check out this post: AutoTearDown swiz custom metadata tag
May 04, 2011
Anonymous
Doesn't MyPresentationModel need to extend EventDispatcher if it has fields that are [Bindable]? That was always my impression. The binding framework tries to listen to events on MyPresentationModel corresponding to each [Bindable] element, no?
May 06, 2011
Brian Kotek
No. If you mark a property as Bindable the compiler automatically handles setting up the class to generate property change events.
Aug 05, 2011
Anonymous
Some interesting comments about this. For what it's worth, I found the Presentation Model to be a really nice way to handle HUDs in my games. Generally, the HUDS display the same data and have the same or similar actions. So I have an abstract HUD class that is inherited by the particular HUD view of my choice. This allows me to use the ViewAdded and ViewRemoved tags which I sometimes need since alot of the art is generated in Flash Pro by an art team. The HUDPresentationModel snaps together with the view and this makes swapping out HUDs for different brands/themes a snap.