1. I would like have the "save" button disabled as long as the BO is not valid. As soon as the BO becomes valid the "save" button must be enabled. I had it like this for CSLA 1.5 and 2.x but how to implement this for CSLA 3.x.? Would it be unnecessary?
2. In the ReBindUI procedure there are two catch statements. If I click the "save" button without having capture data in the form, the second catch is executed. Why is this, if the BO is not valid, why don't I get the error from the first catch statement which contains the BusinessException ? Am I misunderstanding it?
3. In the CSLA. 3.0.2 PDF book, Rocky states that code in the UI should never interact with the BO but with the BindingSource. Then why do I have to call _bo.BeginEdit() and _bo.ApplyEdit()according to the PT source code examples?
4. In PT source code, would I still use "public event EventHandler CurrentPrincipalChanged" if I don't use WinPart, i.e. if my login happens before the application starts.
Thanks
Regards
Casper Erasmus
cjherasmus:
1. I would like have the "save" button disabled as long as the BO is not valid. As soon as the BO becomes valid the "save" button must be enabled. I had it like this for CSLA 1.5 and 2.x but how to implement this for CSLA 3.x.? Would it be unnecessary?
This is unchanged from 2.x.
3. In the CSLA. 3.0.2 PDF book, Rocky states that code in the UI should never interact with the BO but with the BindingSource. Then why do I have to call _bo.BeginEdit() and _bo.ApplyEdit()according to the PT source code examples?
The specific rule is that you should never interact directly with the business object while it is data bound. If the object is unbound you can do what you'd like. This is why it is unbound before calling Save() for example.
_bo.BeginEdit() is called before the object is bound. The explicit calls to BE() and AE() are to support the form-level Cancel and Apply buttons. If you don't have form-level Cancel or Apply buttons then you probably don't need to make those calls in your UI.
4. In PT source code, would I still use "public event EventHandler CurrentPrincipalChanged" if I don't use WinPart, i.e. if my login happens before the application starts.
That whole WinPart thing is my "mini-framework" for the UI. Most people have their own UI approach or UI framework. You would do whatever is appropriate for your particular UI approach.
One thing your UI approach/frameworks should do is notify your code when the current principal changes. That notification is important, because it allows any active forms to refresh their authorization to reflect the new principal.
The business object will automatically start using the new principal as soon as it changes. That's just automatic. But the user interface needs to know that it changes so it can update the presentation to match the new user's capabilities.
Rocky,
regarding point 1:
apologies, was thinking about something else. The "2.x" shouldn't be there, only 1.5x. I'm upgrading code from version 1.53 to 3.0.2 and would like to know how to implement the behaviour in 1.53 of using the hidden checkbox which either enabled or disabled the "Save/Apply" button.
regarding point 2:
you haven't answer this one :-)
regarding point 3 and 4:
Understood, thanks
Regards,
Point 1 then, is covered in an article at www.lhotka.net/cslanet (don’t
have time to find it for you – use www.lhotka.net/search.aspx for
help).
I don’t understand point 2, so I was hoping someone else
would understand and comment on it.
Rocky
Copyright (c) Marimer LLC