|
|
|
Re: Converting a TUI user interface (former Clipper application) towards scout [message #1396436 is a reply to message #1396069] |
Tue, 08 July 2014 09:38 |
Jeremie Bresson Messages: 1252 Registered: October 2011 |
Senior Member |
|
|
Hi,
As Matthias Nick wrote, scout brings a lot out of the box. A typical scout application will work like this:
* Client side:
Validation of each field (checking user input: like min/max value for number field, date not in the past for a date...).
You have also the notion of mandatory field, of master/slave fields...
* Server side:
When the form is stored, we do business validation and tell the user if he could save its form or not.
Project specific requirements
Your project will probably have additional requirement. It is possible to define what the scout-way to implement them is. I can give you examples taken from the project where I am currently involved. It is also a migration project. I hope it will give you a feeling of what is possible with scout behind what comes out of the box.
1/
In our project, the server computes error message that we need to display on each field.
I have discussed my approach in this thread: "Server side mapping of validations coming from a backend". As I told in the thread, I could share some code if anyone is interested.
It is not out of the box in the scout runtime framework, but the implementation we choose is now used in each form and can be used by the developers without having to think about it every time (same pattern everywhere).
2/
Another pattern we implemented might be near to your requirement:
When a value is changed in a field, we do a server roundtrip to calculate the state of the form to set values in other fields. It is absolutely possible.
Because our backend is not always quick, sometimes the user needs to wait. This is not the best user experience you could imagine as desktop application developer, but it was a requirement in this project. We had to reuse the backend logic, without having to rewrite it (programming against a black box on the server side), so it was our only option.
The first user-tests demonstrate that the performances and user experience are similar to what was in the old application. So again: not a typical use case for a scout application, but a pragmatic solution.
Really important: we introduced a pattern at form level (we have a doCalculate() method, similar to the existing doSave() method). It can be seen as a small framework extension. Now every migrated Form uses this pattern.
3/
Last example: we had a pattern where you have a table with some entries and a group box containing details to the selected row. I have discussed it here: "Table and GroupBox for details on row selection"
It is not something you get out-of the box, but we managed to define a pattern that can be used for those cases.
The implementation discussed in the forum is an "everything in the client" approach.
The current implementation has evolved, because we figured out that in some cases, the backend wants to know about the selected row. For those cases, we need also to do a server roundtrip when the selection in the table changes.
Conclusion
Feel free to ask if you need more detail about what scout can and how.
I am confident scout could be a good framework for what you want to do. You will not get everything out of the box, but I think that solutions can be found depending on your requirements. Without knowing your constraints (architecture, existing logic...), it is difficult to discuss how a scout "Proof of Concept" could look like.
After having worked on a migration after several months, I can give you one advice:
Define a target architecture (a set of patterns). It is really difficult to identify them in advance especially if you are migrating an existing application. In the early phase of your project it is important to identify the patterns and to implement them the same way everywhere.
I hope we hear from you (even if you chose another framework)
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.03860 seconds