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