WebGui design

[maeste]

Hi all,
it's time to start the webgui design.
FDG has already started coding something (its work is already committed on our svn), but he (or better the project) needs an open discussion about its design and of course he needs also an hand in coding.
I try to put here my thoughts and question to open this discussion. Please discuss my thoughts and answer my question, and of course ad yours.

THOUGHT: We agreed in a previous post the best tool to implement our webgui is GWT (without extension).
QUESTION: Do we need a wiki page with some sketch of the interface?
THOUGHT: webgui must be an easy to use interface to call webservice for non technical people. Webgui must provide also tools for technical people (aka developer) to generate config, smooks config, and eventually code to make developer life easy. Let me remark the worst part of developing wise client is smooks file writing. They are never easy to write, but Wise and dynamic generation of client classes make things even worst. We need tools here.
THOUGHT: at some stage webgui have to provide some manner to save tests request/result and/or a way to generate unit tests from these data. It would be good since non technical people (aka QA) use wise-webgui to run acceptance tests, and would be good to convert it to unit/regression test in some phases of project.
THOUGHT: Wise-core should provide APIs on which webgui would be build. IOW Wise-core should have base APIs on which should be easy to implement a graphical interface. Our webgui will be the only implementation we will provide, but APIs could be used to implement SWT/Swing gui for example.
THOUGHT: we have to start core APIs design as first stage (very soon)
QUESTION: could webgui support JAX-RS too?

That's all for the moment, I'll add my other thoughts/questions here when they'll come to my mind. Please do the same.

[fdg]

So, actual gui is OK as starting point, with some tweaks, for a first kind of users: non technical people. More use cases may come later. You summarized some of them.

I thought to do some sketches to show how the UI will like. But actually it is not necessary if we figure out an early milestone were the UI is like the old one. For further improvement it will be useful to some drawings and take the right decisions before writing the code.

A more pressing issue is the missing of some way to represent the structure of the data type of a service call inputs and outputs. In wise core is quite easy to browse services, endpoints, calls. However, as Stefano told me in a talk, the inspection of the data structures is upon the client code. This means that some code had to be written. Thus, if this code gone inside the core, it will be available to other UIs implementors.

I agree with this point.

So, we need some hierarchical representation of the data structures.

There is a problem to solve that arises when dealing with GWT: if a data type has to be used by the interface, it has to be compiled as javascript. This means that if we would like to build the interface in the client code, as I think it should be, the gwtgui module needs the source code of the classes whose instances are used to represents data structures. Unfortunately GWT does not generates client code from byte code.

Solutions?
One: provide the source code within the jar of the core.
Two: use different classes and translate the data when it goes back and forth.
Tree: represents these structures using JRE classes supported by the GWT runtime.
Four: use XML?
Five: I have a vague idea about using GWT generators to build proxy POJOs... It's something that I have to think about more.

By my opinion, this is a general problem with GWT. It's difficult to apply TDO pattern until you don't provide the source code of DTOs. If we provide a solution here, we'll provide a solution for a lot of people ;)

Any idea?

[fdg]

It is not possible to edit posts? Ok, please don't worry about my bad english grammar :D

[fdg]

To be clear, TDO it's a misprint. I mean DTO.

[asoldano]

Fabrizio, I have to say that I have almost no knowledge of GTW, anyway generally speaking I think we would probably need some kind of model to be used by the GUI. That should be able to map every possible data structure coming from the core, which would not change because of the gui. In the legacy implementation (perhaps you already know this) we used to have TreeElement instances; those were mapped to the classes representing the soap message and used to dinamically build the interface. See: http://jax-wise.svn.sourceforge.net/viewvc/jax-wise/tags/Wise-1.0.1/src/it/javalinux/wise/seam/entities/treeElement/
http://jax-wise.svn.sourceforge.net/viewvc/jax-wise/tags/Wise-1.0.1/src/it/javalinux/wise/converter/treeElement/