In Prims, there are two common approaches to implementing user interactions in the MVVM pattern. http://msdn.microsoft.com/en-us/library/gg405494(v=pandp.40).aspx#sec10
1. Implement a service that can be used by the view model to initiate interaction with the user
2. Uses events raised by the view model to express the intent to interact with the user, along with components in the view that are bound to these events and that manage the visual aspects of the interaction.
I think MvxPresentationHint should be the first approach. How about support the second approach?
I don't believe anyone has implemented any formal documented common cross-platform dialog interaction patterns between viewmodel and view at this stage.
I personally have used several mechanisms including :
using a messenger for the viewmodel to send a general 'ask y/n' request and then for the view to send an 'answer was y/n' response.
using a custom presenter to override ShowViewModel behaviour with a popup dialog
Both of these approaches worked well, were testable, used only a small amount of 'code behind', provided easy customization and used only weak references - so didn't cause any memory issues in iOS. In general, where faced with similar ux requirements in the future I think I'd consider the messenger approach as my first choice - but that's a personal design preference - not some 'best practice' essay like in prism.
Related
I'm looking for suggestions on how to "separate" a front-end and back-end without too much added complexity. The purpose is for a blog application (I know others exist, I just want to roll my own). A couple simple index/view views for a front-end with more complex (index, create, update) views on the back-end.
For example, I'm am currently building a website using the advanced template and it's working as desired: different layouts for the front-end and back-end admin area, navigating to "/admin" takes you to the admin area, etc.
However, I don't need separate authentication, don't really care about separate controller logic, don't need a "view" action on the back-end or a "create" on the front-end. Though, it would be nice to have the URL include the "/admin" prefix for those administrative functions
Is there some easier way to give myself the experience of a separate admin area without going through the added complexity of separating backend/frontend/common apps/configs?
The simplest way of doing that is to create a module entitled admin and set up some access rules on it.
Even simpler is to create a controller called admin..
What you choose, depends on how many admin actions you need.
The advanced application template is indeed going to be overkill for the majority of Yii applications.
A careful mix of RBAC and module/controller magic will get you where you want to go, I hope. ;)
Edit:
I recommend integrating as much admin functionality into your application (views) as possible.
if (\Yii::$app->user->can('whatever')) {
// do whatever
}
That way, the amount of stuff that the admin has to manage in the pseudo-backend can be shaved down considerably. :)
See: Yii Guide - Role Based Access Control (RBAC)
I've been looking at the N=36 tutorial which introduces new RIO support in MvvmCross 3.09. Is it safe to combine INC fields and old school properties in the same class? I ask because some of my property setters and getters are complex so it maybe be easier to leave them as-is. However the vast majority of my existing properties are simple and as such seem excellent candidates for fields.
Thanks
Mark
'safe' is an interesting word to use here - I'm not entirely sure what it means in this context.
I personally believe it is safe to mix and match INotifyChanged and INotifyPropertyChanged in the same project and in the same view model - there's nothing that should go bang as a result and the memory and processing speed performance of INotifyChanged should be as good as or better than the performance of INotifyPropertyChanged.
The only potential areas of unsafe risk I can think of are:
team development and later code maintenance - using the two different approaches together might confuse yourself or other coders either now or later in maintenance - it would be fair for them to ask "where do I use one approach or the other?" and "why?"
lack of 'change all' support - INotifyPropertyChanged allows ViewModels to send a everything has changed notification - they can do this using a null or empty property name. INotifyChanged does not currently join in with this notification. In my experience, this 'change all' mechanism is used very infrequently and is not well known by Mvvm developers - so the risk here is small. However, if anyone did try to use it, then they might be surprised that the INotifyChanged bound-fields didn't update.
portability to other Mvvm libraries - Rio is a binding mechanism MvvmCross has introduced - so it isn't yet available in other Mvvm platforms. If you were ever to port back to something like Prism then this might be a risk for you (you might have to rewrite those fields as properties)
confusing to Windows developers - experienced Xaml developers have been used to using INotifyPropertyChanged all the way back to 2005 - so it might confuse them to have to use the MvvmCross Xaml Binding Extensions in order to get the fields bound inside Xaml. (Whether or not this confusion is good or bad for them depends on your world view!)
I'm working on a web application (Java EE backend) which contains a fairly complex input modal. This input modal allows the user to capture data, but it has a bunch of (JavaScript) restrictions, such as mandatory fields, fields only being available if a specific value is entered, etc.
I have to expose this functionality to external systems and allow them to submit this data to my server. These external systems can be both web or client based (but I can assume that the clients will have internet access). My first thought is to provide some kind of definition of the fields and stuff like mandatory to these systems through services, and have them render the input modal however they want. This has been met with resistance though, because the types of fields and restrictions will likely change quite a bit during the next few months of development. These external systems have different deployment timelines, and for this to work we'll have to firstly duplicate all the logic handling these restrictions across all systems, and secondly synchronize our deployments.
An alternative which has been proposed is to have the external systems call my modal through standard HTTP and render it either in an iframe or in an embedded rendered. This solves all of the previous complaints, but it leaves me feeling a little uneasy.
Are there any alternatives we are not thinking of? Maybe some kind of UI schema with existing render libraries for the different platforms? What are your thoughts on the second proposal, any major concerns or is this the "best" solution?
Edit: To clarify, I'll of course still perform backend validation regardless of the frontend decision, as I can't just trust the incoming data.
The constraints that you mention (mandatory fields etc.) really have nothing to do with the user interface. You are also right that it is not a good idea to have your backend render web content.
Your first proposal sounds like a good idea, here's how I would solve the issues you mentioned:
Do all the validation on the backend and send a model object to the client, representing the current state of the UI (field name, type, enabled/disabled, error message etc.).
Keep the client as dumb as possible. It should only be responsible for rendering the model on a window / webpage. Whenever a field is changed and it requires validation, submit the model to the backend for validation and get back a new model to be displayed. (You could optimize this by only returning the fields that changed.)
Doing it this way will keep your validation logic in one place (the backend) and the clients rarely need to be modified.
I have been faced with same issues in several previous projects. Based on this experience I can honestly say that server-side validation is the thing you will likely have to implement to avoid rubbish being committed from client side regardless if it comes from GUI or other third party system via API. You can choose one of available validation frameworks, I used Apache Commons Validator and think it is well, or you can implement your own one. On the other hand client side pre-validation, auto-completion and data look up are the solutions you should have to make human users happy. Do not consider about code duplication, just make your system right way from the business point of view.
Which presentation patterns do you think Ext favors or have you successfully used to achieve high testability and also maintainability?
Since Ext component instances usually come tightly coupled with state and some sort of presentation logic (e.g. format validation for text fields), Passive View is not a natural fit. Supervising Presenter seems like it can work (and I've painlessly used it in one occasion). How about the suitability of Presentation Model? Any others?
While this question is specifically for Ext, it can apply to similar frameworks like SmartClient and even RIA technologies like Flex. So, if you have any first-hand pattern experiences with any other web UI technologies, your input would still be appreciated.
When thinking of presentation patterns, this is a great quote:
Separating user interface code from
everything else is a key principle in
well-engineered software. But it’s not
always easy to follow and it leads to
more abstraction in an application
that is hard to understand. Quite a
lot design patterns try to target this
scenario: MVC, MVP, Supervising
Controller, Passive View,
PresentationModel,
Model-View-ViewModel, etc. The reason
for this variety of patterns is that
this problem domain is too big to be
solved by one generic solution.
However, each UI Framework has its own
unique characteristics and so they
work better with some patterns than
with others.
As far as Ext is concerned, in my opinion the closest pattern would be the Model-View-Viewmodel, however this pattern is inherently difficult to code for whilst maintaining the separation of the key tenets (state, view, model).
That said, as per the quote above, each pattern tries to solve/compartmentalise/simplify a problem/situation often too complex for the individual application at hand, or which often fails when you try and take it to its absolute. As such, think about getting a 'best fit' as opposed to an absolute when pattern matching application development.
And remember:
The reason
for this variety of patterns is that
this problem domain is too big to be
solved by one generic solution.
I hope this helps!
2 yeas have passed since this question was aksed and now Ext-JS 4 has a built-in implementation of the MVC pattern. However, instead of an MVP (which I prefer), it favors a straight controller because the views attachment themselves to the models through stores.
Here's the docs on the controller:
http://docs.sencha.com/ext-js/4-1/#!/api/Ext.app.Controller
Nonetheless it can be made to act more like a supervising controller. One nice aspect of Ext-JS is the global application objects ability to act like an event bus for handling controller to controller communication. See this post on how to do that:
http://www.sencha.com/forum/showthread.php?176495-How-to-listen-for-custom-events-fired-in-application
Of course the definitive explanation of all these patterns can be found here:
http://martinfowler.com/eaaDev/uiArchs.html
Do you know a decent MVC framework for AS3? I am currently looking into PureMVC but I need some reassurance that it's the best choice.
Do I really need to use a framework? or would it be better for me to implement MVC myself?
I'm assuming by AS3 you mean flex/AS3. Cairngorm is the defacto standard and was written by adobe consulting; Hence, you will find a lot of community support. There are a few others including PureMVC. There is an article on the adobe/flex website which gives a good description of all of them.
i followed MVC Design Pattern in AS3
i.e,
The model represents the information (the data) of the application and the business rules used to manipulate the data
The view corresponds to elements of the user interface such as text, checkbox items, and so forth
The controller manages details involving the communication to the model of user actions such as keystrokes and mouse movements.
if you have any doubts about implemention of MVC you can refer actionscriptworkouts.blogspot.in
Carnigorm and PureMVC are good choices, but my personal opinion is that Robotlegs is far easier to work with.
http://www.robotlegs.org