Richard,
I like Metawidget very much, and I am convinced that it is a framework
the common scaffold could be based on - now that it supports templates ;-)
In fact I found myself in similar situation as Vineet, not wanting to
write a descriptor etc. for every artifact I needed to create.
Personally I cannot yet imagine integrating Metawidget as integral part
of a generated scaffold, seeing how hard it is to create a static
_functional and stable_ UI based on JPA entities.
I know how much I could take from your Aerogear plugin and I always
wanted to thank you for the guidance it provided. By aggregating the
existing inspectors, processors and what-nots we could build an
incredible powerful templating system.
Regards,
Thomas
Am 07.03.2013 00:35, schrieb Richard Kennard:
Guys,
If it helps, just to let you know I have now released version 3.2 of Metawidget. This
version includes FreeMarker support (inspired by Vineet).
I believe Metawidget is common to all the Faces, Spring and Errai plugins, as well as my
original AeroGear prototype plugin. I know Vineet is unsure if
Metawidget is the direction he wants to go, but if so I think it would be reasonable to
push it 'down' into some kind of common scaffold base. That may
help standardise things a little? Note that Metawidget *does* provide an easy way to
configure/override generation, it's just that Forge 1 makes it hard to
get at. I believe Lincoln is trying to fix that for Forge 2.
It may also be worth bearing in mind: Lincoln, Jay and Burr have all, at different times,
expressed a desire for a *runtime* scaffold. This is so the
scaffold can adapt as the underlying project changes, rather than force a static
regeneration (which overwrites user changes). Metawidget has a common
architecture across static and runtime modes, whereas something like FreeMarker is going
to lock you into static generation.
Just some thoughts. I am, obviously, very biased :)
Regards,
Richard.
On 7/03/2013 3:08 AM, Thomas Frühbeck wrote:
> Can you please point out the locations of the respective scaffold
> plugins you refer to, and give some introduction to the direction of
> planned development.
> I read from the meeting transcript:
> - extendable templates to prevent scaffold duplication
> - conventions must be established
> - scaffold generate tests
>
> Knowing Faces, Aerogear plugins and my proposed Errai plugin quite well
> I find it somewhat amusing to see them all be based on frameworks and
> provide some extendability, yet each in a very distinct and not very
> congruent way - perhaps my bad?
> During building my Errai plugin I found it e.g. difficult to implement
> thorough type safety and entity relationships when the calls of the
> scaffold are either per single file/entity ("generateFromEntity") or for
> all files/entities ("generateIndex"), both not so well suited for
> handling of _relationships_.
>
> Furthermore the development models are interestingly far apart:
> - Faces: unsafe JSP + converters/handlers/_named_ beans + server side
> - Errai: compile time type safety, intensive integrity validation,
> client side optimizations
>
> e.g.
> - the Errai compilation would fail, if a "Form"Composite declared a
> widget that is not found in its HTML template, thus enforcing the HTML
> template be generated _together_ with its "Form"Composite
> - by _re_building only _one_ entity (generateFromEntity) in Errai
> the generated code would possibly fail miserably w/o rebuilding also its
> related entities
>
> Honestly I found myself frequently in the miserable position to rebuild
> the complete entity model because of interdependencies. Anyway, while
> writing these lines I find interesting possibilities to decouple code
> for more flexibility :-)
>
> I am very interesting in evolving my plugin, so I hope you can give some
> idea about the planned templating etc.
> If there are not yet clear directions I am ready to scetch out the main
> issues I encountered for open discussions.
>
> Thomas
>
>
> Am 06.03.2013 14:38, schrieb Vineet Reynolds Pereira:
>> Hello all,
>> This is more of a follow up on Lincoln's mail sent earlier on the
cross-project scaffold team.
>>
>> Sebastian and I have been working on fleshing out the details of the new
scaffold plugin to handle several requirements, as part of the single collaborative
scaffold initiative. We're going to attempt making this work on Forge 1, and port the
design over to Forge 2. While our work so far has covered fairly decent ground, it is
mostly due to the commonalities in the scaffolds we work on - AngularJS and Aerogear.
JSF/RichFaces, Errai are notable exceptions, and I'd like to propose a
weekly/bi-weekly cross-scaffold team meeting to pour over the details of this new scaffold
plugin, so that design decisions will attempt to accomodate all projects (instead of only
HTML5 ones). 30 mins should be fine to start with, stretching to a maximum of an hour (if
there are too many topics to discuss).
>>
>> I'd like to know what time would be suitable for this discussion. If we
cannot find a suitable time for everyone to join in, or if you schedules are busy, we
could have impromptu meetings.
>>
>> Thanks,
>> Vineet
>> _______________________________________________
>> forge-dev mailing list
>> forge-dev(a)lists.jboss.org
>>
https://lists.jboss.org/mailman/listinfo/forge-dev
>>
> _______________________________________________
> forge-dev mailing list
> forge-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/forge-dev
>
>
_______________________________________________
forge-dev mailing list
forge-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/forge-dev