My overall question is: am I on track here?
So far so good.
do I create a LoginForm class or simply a Form class and subclass it for each type of form I use in my app? or can I handle most of what I need through concrete instances of a single, global Form class?
I'd keep it simple to start with. If you know all your forms and their requirements now, you might be able to abstract things, but abstraction for abstraction's sake isn't a very good way to ship products. A better way to approach it might be to simply develop all your forms separately, and find out what they have in common as you go along. You can always refactor to an abstract form class or an 'uber form' with everything it it and states to represent the various forms later.
where's the best place to handle initial validation? I'm assuming in myLoginForm but maybe it should be the mediator? (assume I already do validation server-side)
What's to validate in a login form? That both fields are filled? Is the username an email address? If you need to validate that it is a well-formed email address, do so in the view component itself. The component can assume the responsibility for emitting a fully populated well-formed login attempt. The system can take it from there.
Try to do as much validation as possible in the component itself. Sometimes this isn't possible, and the next place to do validation is either in a command or in the Proxy before the request is sent. Use a command if validation will be complex and possibly be based on state of the application or data gathered from multiple Proxies. Put it in the Proxy if it is strictly domain-related checking of fields that the the Proxy itself manages.
Finally, no matter how much validation you do at the front end, there must always the validation at the server itself. Particularly in the case of RIAs, since other applications might one day communicate with the same service but not do such a great job of validation.
Sometimes, if the validation is super complex, its wiser to hand a complex VO to the Proxy, who sends it to a server method for validation only. This way the complex validation logic doesn't have to be duplicated in the server and the client. Inside the client, you trade the burdon of complex validation for a little extra View<-> Model chatter. A change happens at the view, the complex VO is sent to the Proxy for validation, and if a bad result comes back the View is notified, otherwise you keep on entering your data until you're ready to submit. At which time it can be assumed to be ready for submission.
Is there an advantage to going to a command instead of directly coupling the mediator and the remote proxy?
As mentioned above, if there needs to be a complex validation step taking place inside the client when the form is submitted, you might want to route the submission through a command by having the Mediator send a note instead of invoking a Proxy method. Otherwise, just have the Mediator pass the data to the Proxy.
If all of this is handled through a single web-service, I'm curious if people tend to set up a different proxy for each type of transaction sent to the service (that way you could reroute certain functionality to other resources) or if it's all just in one mammoth proxy which divides the commands to different URLs? Or, (and this is beyond the scope of PureMVC) if you just pass the command name to the Web Service and all the data is split and rerouted server-side?
This touches on the design of the server side as well. The decision about whether to have different URLS for different functionality or to have one URL that accepts different 'commands', is affected by many factors. RESTful services tend to follow the former model, with different nodes of paths being imbued with meaning like /users/profiles/puremvc/edit. Many of the oldest CGI apps out there love to use one url and load up the query string parameters. The discussion about which way to form your services is a little outside the scope of this response, but suffice it to say, you'll probably find yourself dealing with both from time to time.
For the client side strategy, usually it's one Proxy per data type.
If there are several service endpoints with different data associated with each, it is natural to make a Proxy for each endpoint.
If there is one endpoint and many methods and types of data, a mammoth proxy is not advised. A Business Delegate pattern may be a good choice because it keeps the knowledge of that one URL, and the service that accesses it in a single class that the Proxies all talk to.
-=Cliff>
