Concorrentes...

[Marcelo Mrack]

Hoje, bem por acaso mesmo, acabei lendo um artigo sobre o Metawidget
- http://java.dzone.com/news/interview-creator-metawidget-a

Na pratica, ele eh o Merlin :)

A ideia é a mesma, pegar uma entrada (que pode ser um bean, um xml,
etc) e gerar em tempo de execucao das telas...

Lendo o artigo - que é uma entrevista com o cara que criou o negocio -
da pra ver que as bases sao as mesmas, e pelo marketing do cara, ja
tem suporte para varias plataformas, de onde ele partiu do JSF - nos
estamos partindo do Swing...

Trechos de codigo sao parecidos com o do Merlin (em estrutura, nao em
instrucoes), como o "getComponent( X )".

O cara quer liberar a versao 1.0 em breve (assim como nos) e o projeto
dele esta no sourceforge, em http://metawidget.sourceforge.net

Acredito ainda que estamos na frente deles, pois nosso mecanismo de
configuracao realimentada esta anos-luz de outros frameworks, e a
abordagem nossa baseada em renderizadores e binder plugaveis, com
suporte a anotacoes e agentes com OCL e EL tambem nao foram percebidas
no framework do cara.

Entretanto, isso eh um sinal de que a concorrencia esta mesmo
chegando...

[Richard Kennard]

Hello. I came across your post about Metawidget. I'm afraid I don't
speak Portuguese, and Babel Fish is not 100% accurate, but it appears
you were discussing Metawidget being competition to Merlin?

I agree there is some overlap between our two projects. I read your
CHI 2008 paper, and ironically I too am developing Metawidget as a PhD
project (I am at the University of Technology, Sydney). I am hoping to
have my first paper on Metawidget published soon. So I thought I would
'extend the olive branch' and perhaps we can learn from each other and
cite each other's papers in the years to come!

I would love any feedback you may have on Metawidget. Hopefully you
may find my feedback on Merlin useful too. From reading your CHI 2008
paper, here are the immediate things that occur to me:

1. Your @RenderAs(JCheckBox.class) would seem to introduce a compile-
time dependency between the domain and the UI? It's not too bad with
JCheckBox, because that's part of Java SE, but if I were to use
@RenderAs(SelectBooleanCheckBox.class) I'd have a compile-time
dependency between the domain and JSF, which means I couldn't reuse my
domain object in, say, a Swing app

2. I like your @Order annotation. It seems more powerful than my
@UiComesAfter.

3. What does @Dependence(":all") do?

I too am looking to extend Metawidget into using something like JBoss
Rules (or, more specifically, JBoss Business Process Modelling). I
think the CRUD approach is too general for 'what actions can be
performed'. I would be very interested in what you find when trying to
have Rules drive the UI.

I look forward to sharing ideas.

Regards,

Richard.

[Marcelo Mrack]

Hi all,

Due the sparse time, shortly (shortly?):

1. @RenderAs (like majority of Merlin annotations) support CIO
(Concrete Interface Objects) and AIO (Abstract Interface Objects). A
JCheckBox is a typical CIO, and if used, a compilation time dependency
will be rised. To prevent this situation, we can use an intermediate
and abstract element, like COMBOBOX. The COMBOBOX is an AIO example,
and can be defined freely by programmers. Whe AIO are used, at runtime
Merlin translate it to the correct CIO (with some degration if the CIO
is not available in the current ui toolkit). Speaking more about
compilation dependencies, my experience demonstrated that this is a
litle problem in any case. Therefore, CIO or AIO approach is a design
decision. In my opinion, the major benefit of CIO usage, is a directly
requirement representation. And finally, it is important explain that
Merlin has a bi-directional mapping beetwen ui elements. For example,
@RenderAs(JCheckBox.class) will be renderized like a Combo in Swing
and in a JSF too.

2. @Order is an instigate challenge for programmeres. This annotation
comprise an AIO concept. For example, @Order(FIRST) can be interpreted
like "the last element in the screen at right-bottom corner", if an
"Bottom-Up RightToLeft Layout engine are attached to the container".
Very crazy, I know :)

3. @Dependence are used to create "filling dependencies" between
componentes. The built-in dependencies are "enable/disable" and "show/
hide" comportaments. The @Dependence are used over the "master" field
to indicate the dependents, or the "slave", fields. For example,
@Dependence("email") boolean hasEmail, indicates that, if "hasEmail"
are filled, then, the "email" control will be enabled for fulfilling.
This annotation support multiple dependencies, like
@Dependence("phone1;phone2;phone3") and so. Some shortcuts are
available to. Expressions like @Dependence(":all") denotes "all
elements in the screen, except the annoted element". Programmer can
overrides or extend dependencies implementing a IActionDependence
interface.

Sincerely,

On May 22, 8:57 pm, Richard Kennard <rich...@kennardconsulting.com>
wrote: