As we approach the end of this year I reflect on what has been a varied and somewhat busy time for me (us!).
As far as exploring EA, I haven’t been able to do as much as I would have hoped this year, and there haven’t been many post. However, the list of experiments continues to grow rather than reduce and I continue to enjoy using EA and still find new stuff – so that’s all good.
Commercially our main product focus has been with eaForms, however we recognise that the world continues to change and a “fat client” is not always the best solution, especially when trying to expand access to a wider audience. Over the years I have received several queries regarding a web interfaces to EA and this year was no different with questions such as – “does eaForms provide a web interface?” The simple answer is no – it is a traditional EA addin. But the need to provide access in different ways and possibly to a wider audience is clear.
Last year (2015), we experimented with a small standalone windows client for EA using eaForms. As illustrated in the screenshot below, a simple project browser tree with tab(s) to present the relevant eaForm were provided. The user could view/edit element/package information and using buttons in the toolbar add or delete items.
At the same time as developing this windows client I did an initial design for a web based version but didn’t progress. So with the growing interest in web interfaces I thought it was about time I’d verified my idea with a working demo.
The basis of my design is to use the same concepts of eaForms where:
- A request is made, for example by selecting an item in a project browser
- The required item element/connector information is retrieved
- The item information is presented as defined by the eaForm, including running scripts and providing relevant action buttons
For my experiment I took some short cuts and didn’t code everything myself but used an open source library to provide the test project browser. As a result I used a standard web server to host this library and our launch page; all the other code is within the web service.
The main components in the design are:
- Request handler which receives requests on a specific port from the web client, does request validation sending valid requests to the relevant sub-service for futher processing, handles response returning results to the appropriate caller
- Model information provider – used to query the EA datasource and provide the information needed to populate the project browse.
- Form generator – used to access the element information and generate the web page. And handle any events e.g. updating the EA datasource.
All the code and form definitions are stored on the server, with design option to accommodate different eaForm definition sets for different users/roles so that the information that work with is relevant to their task.
One positive aspect of this design is that the information passed to the client is restricted to the information defined by the eaForm.
Now I will admit I’m not a web developer (ours is too busy doing real work, so I had a go which is part of the fun!). And I haven’t finished writing all the control presentation code for the forms (no lists yet), but as a taster below is a screen shot of an eaForm in a web browser. Selecting an item in the project browser on the left and the relevant form is generated and presented in the window on the right. The form definitions were created within the eaForms addin and are used without modifications (what we expect) – below we are using one of our example class forms
So my experiment a success demonstrating that it was fairly straightforward to produce a simple web interface to EA, but as always a product is a completely different task.
In this experiment I discovered so much and was amazed about what can now be down within the web browser environment – so more experiments when time permits. In particular, it made me aware that producing a fully flexible graphical interface to support the presentation/generation of EA diagrams, and in our case eaForms definitions, is feasible. Perhaps Sparx have something just around the corner???
There are EA aware web-based products around, usually tailored to a specific target market, so accessing information on anything from a phone upwards is possible. So this and the queries I received are all testament to the need to access information within EA anywhere anytime.
Not sure if we will do anything – to start with I’ll probably just tinker and see what happens. Perhaps we could make this web code open source, although it will probably a bit of a tidy up, so won’t happen quickly!
XMAS 2016 giveaway
Finally, as we enter the holiday season and it’s a time for giving, we are offering those interested a free personal eaForms professional version licence (time limited offer), so do check out the eaForms XMAS 2016 licence giveaway – if nothing more than something to play with over the holiday period.
With best wishes and happy new year to all