| Mylyn Intent for UI specification [message #996320] |
Tue, 01 January 2013 14:29  |
Jeremie Bresson Messages: 385 Registered: October 2011 |
Senior Member |
|
|
I am trying to figure out if I can use Mylyn Intent in oder to write a „user interface specification". In my company, we are programming form-based applications. This kind of specifications is a textual description of the forms.
Take this form as example:

Basically for each form in each mode (eg edit or new) the description looks like this:
* a title
* some text
* a screenshot
* For each field in the form:
** label
** type of field (text, number, combo, listbox...)
** indication if the field is mandatory
** indication if the field is read only
** textual description of the possible actions (menus, validation rules, specific business logic...)
If I understood Mylyn Intent correctly, this structure is a kind of model ("textual representation") of my forms. Do I need to develop an EMF Model of this?
I have a mechanism to obtain an EMF technical representation of the forms and the fields. Here the EMF Model of the form displayed in the basic tree-editor:

For the moment this is a semi-automatic process, but I am sure that it can become an automated mechanism. (I know a tool that open each form and take a screenshot from each form. I just need to plug my EMF-Serializer to this tool).
I am also confident that it is possible to map this technical model to the textual representation I want to obtain (but I do not have it yet).
Now the big question:
Do you think that I can use Mylyn Intent for this purpose?
In my opinion, this is near to what Mylyn Intent is doing... I imagine this is a kind of new use-case. I can understand that I might need to develop some configurations / specific document model / extension to Mylyn Intent. If so please, indicate what is currently missing (I need to evaluate the requested time).
If Mylyn Intent is not the tool for a such use-case please tell me.
Thanks a lot for your answer.
.
|
|
|
| Re: Mylyn Intent for UI specification [message #997177 is a reply to message #996320] |
Fri, 04 January 2013 04:44  |
Alex Lagarde Messages: 132 Registered: May 2010 |
Senior Member |

|
|
Hi Jeremie,
first of all, thanks for your interest in Intent !
Sorry for the delay, I was in holidays...
What you are trying to do, i.e. synchronizing your software UI with its
documentation, is exactly in Intent scope.
However, as this is a new use case, Intent does not provide the
Synchronization bridge
(http://www.eclipse.org/intent/pages/transcripts/2012_EclipseConEurope/Intent_EConEurope2012.html#28)
allowing to synchronize UI with doc yet.
A "Synchronization bridge" is a piece of code that allows to:
- represent the artifact you want to synchronize with the doc (in your
case, the UI) as an EMF model
- OPTIONAL: detect when the artifact changes, so that synchronization
issues can be detected in real-time. If you do not provide to your
Synchronization Bridge the ability to detect changes, then the
synchronization issues will be detected when the Intent document gets saved.
In a previous post, I detailled how can you write such a Synchronization
bridge
http://www.eclipse.org/forums/index.php/mv/msg/367801/896873/#msg_896873
Please let me know if the explanations are not clear or if you have
trouble implementing your Synchronization bridge. I'm willing to change
the API if needed. I think this would be quite straightforward as you
said you are already able to represent forms as EMF models.
Of course, if you want me to, I would gladly contribute this bridge
directly inside Intent, so that people can use it to document their UI :)
Once the Synchronization bridge is plugged inside Intent, we will be
able to handle such a document :
Section Form1 description {
The Form1 prupose is to ....
* a title
* some text
* a screenshot....
@M
softwareUI {
forms += new Form form1 {
title = 'a title';
text = 'some text';
...
};
}
M@
}
If you change Form1 (from the code or the specifications in the Intent
document), then Intent will raise synchronization issues inside the
model fragment, pointing out the documentation that needs to be updated.
Please let me know if you have further questions, and thanks again !
Alex
Le 01/01/2013 20:29, Jeremie Bresson a écrit :
> I am trying to figure out if I can use Mylyn Intent in oder to write a „user interface specification". In my company, we are programming form-based applications. This kind of specifications is a textual description of the forms.
>
> Take this form as example:
>
>
>
> Basically for each form in each mode (eg edit or new) the description looks like this:
> * a title
> * some text
> * a screenshot
> * For each field in the form:
> ** label
> ** type of field (text, number, combo, listbox...)
> ** indication if the field is mandatory
> ** indication if the field is read only
> ** textual description of the possible actions (menus, validation rules, specific business logic...)
>
> If I understood Mylyn Intent correctly, this structure is a kind of model ("textual representation") of my forms. Do I need to develop an EMF Model of this?
>
>
> I have a mechanism to obtain an EMF technical representation of the forms and the fields. Here the EMF Model of the form displayed in the basic tree-editor:
>
>
>
> For the moment this is a semi-automatic process, but I am sure that it can become an automated mechanism. (I know a tool that open each form and take a screenshot from each form. I just need to plug my EMF-Serializer to this tool).
>
> I am also confident that it is possible to map this technical model to the textual representation I want to obtain (but I do not have it yet).
>
>
> Now the big question:
> Do you think that I can use Mylyn Intent for this purpose?
>
> In my opinion, this is near to what Mylyn Intent is doing... I imagine this is a kind of new use-case. I can understand that I might need to develop some configurations / specific document model / extension to Mylyn Intent. If so please, indicate what is currently missing (I need to evaluate the requested time).
>
> If Mylyn Intent is not the tool for a such use-case please tell me.
>
> Thanks a lot for your answer.
>
|
|
|
Powered by
FUDForum. Page generated in 0.01463 seconds