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

Hi C

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][1] 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