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

[Lincoln Baxter, III]

Aka, not just FreeMarker, but Velocity, MVEL, Seam Render, Etc..


On Thu, Mar 7, 2013 at 10:19 AM, Lincoln Baxter, III <
lincolnbaxter at gmail.com> wrote:

> 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."
>



-- 
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/df4d52bd/attachment-0001.html