[forge-dev] Forge Scaffold x-Project { Aerogear, Arquillian, Errai, Java EE, RichFaces, Spring } - inputs and meetings

[Lincoln Baxter, III]

I'd love to see pluggable templating support! Maybe this already exists,
but an extension point / SPI to hook in whatever kind of templating is
desired.


On Thu, Mar 7, 2013 at 10:15 AM, Thomas Frühbeck <fruehbeck at aon.at> wrote:

> 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 at lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/forge-dev
> >>>
> >> _______________________________________________
> >> forge-dev mailing list
> >> forge-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/forge-dev
> >>
> >>
> > _______________________________________________
> > forge-dev mailing list
> > forge-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/forge-dev
> >
>
> _______________________________________________
> forge-dev mailing list
> forge-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/forge-dev
>



-- 
Lincoln Baxter, III
http://ocpsoft.org
"Simpler is better."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/forge-dev/attachments/20130307/62974bdd/attachment.html