Gui components...

[steinard]

Hi!

I'm currently building thick winform clients (all in a 3-tiered architecture) and I'm glad to see that there is a topic for rich clients. Spring is really great and Spring can help improve your application infrastructure/architecture (it has sure made our framework better). I've just taken a look at the fluffnstuff webpages and read the tutorial there.

I think it is really great that you guys are looking at validation. It is someting that most programmers need to do at some point. I just wonder why so much of the validation logic seem to be put into xml files? The same question goes for dependency injection into GUI components. Have you used these approaches in real projects? Did such approaches require much xml code to be written?

I'm just afraid of xml-hell, and I'm currently trying to avoid it... ;)

Cheers,
Steinar.

[Mark Pollack]

Hi Steinar,

Just some quick thoughts. On one project I did use DI in the winform presentation tier to get reference to a controller. In turn the controller references a service layer that could be stub for some simple integration style testing. The controller had AOP advice applied to do some logging and also exception handling. Exception handling involved logging to a database, failing back to a local file, and also popping up a dialog box so that the user could type what they were currently doing and then that form itself out post information to another web site for analysis later (pairing the ids of the underlying exception and the ids in the user description). This was done part in a mixture of pure DI and service location style. By applying this common advice across all the controllers I didn't have error of omission, it could more or less say, "the controller layer can handle all exceptions" and have the implementation look like the requirement - general AOP goodness.

As for the validation. I would very much like to have more programmatic examples on the validation framework, as it is right now mostly XML based. The reasons why people maybe drawn to xml for this is that is resembles externalizing 'rules'. If they are externalized then they could be used in other environments. So if there was any generic validtion to be done say before sending a request to the middle tier and also on the middle tier, that could be shared. Also, if the rule changes, some people prefer for that to be a configuration change rather than a code change.

Cheers,
Mark

[harald]

hi,

the richclient project originated as a real world application, i just started to pull things out of our production code into a independend library that should make the connection between spring and winforms easier.

regarding your xml question, if you use some autowiring strategy you won't have to write any additional xml at all to inject services into your winform controls, otherwise you have to write the same amount of xml files as for any other kind of application.

regarding validation, the tutorial is only a brief overview how to use the validation framework. you could aswell write your own validator by either implementing IValidator or handle the ErrorProviderErrorsRenderers Validating event.

if the week would have lets say 10 days with 40 hours each the tutorials would for sure be more elaborate ;)

[steinard]

Hi Harald!

We are currently discussing how we should do validation in our framework. When it comes to GUI in .Net I'm quite lost. But still, it just does not feel right to put validation rules in the setters of my domain data classes just to be able to use databinding (I have just discovered that some validation logic has crept in there....). Do you have any great arguments pro-con?

How is the state of Windows From Validation? I read this blog-entry (http://www.pluralsight.com/wiki/default.aspx/Craig/WinFormsValidationBroken.html), emailed the link around and then someone commented that these shortcomings had been solved for .Net2.0? Is this correct?

Thanks,
Steinar.

[harald]

We are currently discussing how we should do validation in our framework. When it comes to GUI in .Net I'm quite lost. But still, it just does not feel right to put validation rules in the setters of my domain data classes just to be able to use databinding (I have just discovered that some validation logic has crept in there....). Do you have any great arguments pro-con?


I cannot really follow you. First validation is not directly related to databinding (it prevents some typing though if you use it in combination) and second I have never proposed to inject validators into your domain objects.
Validators will only be injected into forms and maybe daos to double check that you didn't bypass validation rules in your code.


How is the state of Windows From Validation? I read this blog-entry (http://www.pluralsight.com/wiki/default.aspx/Craig/WinFormsValidationBroken.html), emailed the link around and then someone commented that these shortcomings had been solved for .Net2.0? Is this correct?


Don't quote me on that, but there is not much difference in .Net 2.0. Most of all I don't like the fact that validation is rigidly coupled with input controls.

Harald.

[steinard]

Hi!

I can see that you are not following me. What I meant is that I do not like the fact that we have written extra logic in the setters of the domain classes to check for legal value ranges, nulls, or other types of checks. I have spent half a day looking at databinding because I'm not familiar with such (coming from java), and some of the arguments I've heard for putting input checks in the setters is that it makes it easy to use databinding, while this is supposed to become difficult if validation happens in the UI? I have no clue here.

When it comes to the domain model, then I would not do any kind of injection there. They should be plain and old.

About those shortcomings, someone told me the other day that most of what were pointed out in the blog is still valid.

Thanks,
Steinar.

[harald]

I can see that you are not following me. What I meant is that I do not like the fact that we have written extra logic in the setters of the domain classes to check for legal value ranges, nulls, or other types of checks. I have spent half a day looking at databinding because I'm not familiar with such (coming from java), and some of the arguments I've heard for putting input checks in the setters is that it makes it easy to use databinding, while this is supposed to become difficult if validation happens in the UI? I have no clue here.

When it comes to the domain model, then I would not do any kind of injection there. They should be plain and old.


Ah, I thought your were talking about my approach. I'm with you here, validation shouldn't be part of the domain model, not only because you are very limited in what you can validate inside a setter (e.g. you cannot validate dependencies between entities).

Did you take a look at the RichClient validation example? I know that the docs on this are quite incomplete :)

here is the example form and domain object:
http://richclient.fluffnstuff.org/browser/trunk/SpringUtilsDemo/DemoWizard.cs

here are the validation rules (which don't need to be specified as xml but can also be implemented in a custom class implementing IValidator):
http://richclient.fluffnstuff.org/browser/trunk/SpringUtilsDemo/config/validators.xml

The main difference is, that the domain object will be validated as such and not property by property as the .net framework suggests.


About those shortcomings, someone told me the other day that most of what were pointed out in the blog is still valid.


Which would prove my previous post.

Harald