Underlying model limitation

Hi,

First of all, let me tell you your tool is just great ! Its simplicity shines :)

I'm particularly interested in using it with MDSD frameworks such as Acceleo and openArchitectureWare:

• http://acceleo.org/
• http://www.openarchitectureware.org/

They are both EMF based so they integrate nicely with your underlying metamodel.

I look forward using your sketcher in order to generate UI code for web applications so I've been playing with it and currently, there is an issue as far as code generation is concerned. Indeed, the ui doesn't seem to allow nesting widgets though the underlying model allows it.

Is it by design or just a limitation with the current evaluation version ?

Finally, a detail stroke me. The name of the ecore root package name is "model" which introduces a risk of naming clash. Not a huge deal, but simply renaming it to something more specific like "wireframesketcher" or "screen" would eliminate that risk. This is cumbersome to achieve with EMF but possible :) I can help with that if you'd like.

Kind regards and good job !

Cédric Vidal http://vidal.biz

Hi Cédric,

Thank you for your feedback and for the compliments!

I didn't try the tools you've linked to, but I would like to see what kind of result can they generate from WireframeSketcher screens.

Missing widget nesting is by design. As I see it, screens produced by WireframeSketcher are meant to be consumed "visually". These are screen mockups and not an exact, down to the detail, model of the user interface. In my view, an exact UI model should be produced using a different kind of editor, something more close to a real UI editor with plenty of attributes to specify for each interface detail.

In any case I welcome any "misuse" of the model :). I will see about ecore file name. Shouldn't the unique namespace be enough to avoid clashes?

Best regards,

Hi Peter,

You're welcome, your tool is precisely the kind of tool I had in mind :) and I'd love to be able to use it for my MDSD needs.

Regarding what can be generated from WireframeSketcher screens, actually, not much useful in its current form because of widgets not being nested.

I managed to generate flatten things but without structure, nothing really useful can be generated. Of course, one could infer structure from (x,y) positions but that would be unecessarily complicated.

Regarding the fact that your model doesn't contain any down to the detail platform specific UI information, that's perfectly fine ! The idea is to use your model as a platform independent UI model in a chain. It would be transformed into a more platform specific UI model (Swing, JSF, Eclipse RCP, whatever) using default rules and refined by developers.

I'm personally working on an model customization language called EMF Styling that would allow such refining.

Regarding the possible naming clash, the ecore file name is perfectly fine, only the metamodel namespace which is too generic could clash and renaming it to something more specific would indeed do the job perfectly well.

Kind regards,

Cédric