Need Help?

Icon

For technical questions, feel free to ask on the Swiz mailing list.

Save as HTML or PDF

Icon

You can export this entire Wiki in HTML or PDF format.

Skip to end of metadata
Go to start of metadata

The presentation model (PM) approach is the recommended view layer architecture for Swiz.
The goal is to remove any logic from the view and let the PM handle the view logic.

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.

  • No labels

22 Comments

  1. Anonymous

    The line in MyPresentationModel.as

    should be changed to

  2. Anonymous

    MyView.mxml uses model.listLabelField - this definitition is missing in the model.

  3. MyView.mxml uses model.listLabelField - this definitition is missing in the model.

  4. 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.

    1. 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

  5. Anonymous

    Can some one please fix this code for instance this is missing and what is it for?labelField="

    Unknown macro: {model.listLabelField}

    "
    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.  

  6. 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.

    1. 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.

  7. 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

    1. 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").

      1. 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.

        1. 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.

  8. 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

    1. 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.

  9. 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.

    1. 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.

      1. Anonymous

        The constructor of BeanEvent has no bubble's parameter.

        How would you like to set bubble to true with BeanEvent from the view ?

  10. 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

  11. 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?

    1. No. If you mark a property as Bindable the compiler automatically handles setting up the class to generate property change events.

  12. 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.