Hi,
the most important thing about controllers are their contexts. A context is, simply spoken, a bucket holding some data. The data is organized in context nodes/elements showing a simple parent/child hierachy. UI elements are bound to these contexts, i.e. if you want your UI text field to show a certain (dynamic) string, just bind it to a context element holding that string. There exists kind of a hierarchy of contexts, beginning at the model (which behaves to the outside like a context), then the custom controller (only once per WD component) and at last the view contexts (once per WD view). They can be bound together, transporting a string from the model, through the customer controller, to the view controller to the UI element (you can use of cource less if you like to, but e.g. a model has the advantage of being reusable within many WD components).
Custom controllers are not bound to any of these levels. They are used to structure the context and source code as the developer likes to, i.e. where WD defines that there exists only one customer controller per component and one per view you can build your own hierarchy of contexts (including source code separation) with customer controllers. IMHO, there is nothing more to them.
Regards,
Vedran
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.