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

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(a)aon.at&gt; 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(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 > > > > _______________________________________________ > forge-dev mailing list > forge-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/forge-dev > -- Lincoln Baxter, III http://ocpsoft.org "Simpler is better."