<div dir="ltr">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.<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">
On Thu, Mar 7, 2013 at 10:15 AM, Thomas Frühbeck <span dir="ltr"><<a href="mailto:fruehbeck@aon.at" target="_blank">fruehbeck@aon.at</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Richard,<br>
<br>
I like Metawidget very much, and I am convinced that it is a framework<br>
the common scaffold could be based on - now that it supports templates ;-)<br>
In fact I found myself in similar situation as Vineet, not wanting to<br>
write a descriptor etc. for every artifact I needed to create.<br>
Personally I cannot yet imagine integrating Metawidget as integral part<br>
of a generated scaffold, seeing how hard it is to create a static<br>
_functional and stable_ UI based on JPA entities.<br>
<br>
I know how much I could take from your Aerogear plugin and I always<br>
wanted to thank you for the guidance it provided. By aggregating the<br>
existing inspectors, processors and what-nots we could build an<br>
incredible powerful templating system.<br>
<br>
Regards,<br>
Thomas<br>
<br>
<br>
Am 07.03.2013 00:35, schrieb Richard Kennard:<br>
<div class="HOEnZb"><div class="h5">> Guys,<br>
><br>
> 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).<br>
><br>
> 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<br>
> 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<br>
> 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<br>
> get at. I believe Lincoln is trying to fix that for Forge 2.<br>
><br>
> 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<br>
> scaffold can adapt as the underlying project changes, rather than force a static regeneration (which overwrites user changes). Metawidget has a common<br>
> architecture across static and runtime modes, whereas something like FreeMarker is going to lock you into static generation.<br>
><br>
> Just some thoughts. I am, obviously, very biased :)<br>
><br>
> Regards,<br>
><br>
> Richard.<br>
><br>
> On 7/03/2013 3:08 AM, Thomas Frühbeck wrote:<br>
>> Can you please point out the locations of the respective scaffold<br>
>> plugins you refer to, and give some introduction to the direction of<br>
>> planned development.<br>
>> I read from the meeting transcript:<br>
>> - extendable templates to prevent scaffold duplication<br>
>> - conventions must be established<br>
>> - scaffold generate tests<br>
>><br>
>> Knowing Faces, Aerogear plugins and my proposed Errai plugin quite well<br>
>> I find it somewhat amusing to see them all be based on frameworks and<br>
>> provide some extendability, yet each in a very distinct and not very<br>
>> congruent way - perhaps my bad?<br>
>> During building my Errai plugin I found it e.g. difficult to implement<br>
>> thorough type safety and entity relationships when the calls of the<br>
>> scaffold are either per single file/entity ("generateFromEntity") or for<br>
>> all files/entities ("generateIndex"), both not so well suited for<br>
>> handling of _relationships_.<br>
>><br>
>> Furthermore the development models are interestingly far apart:<br>
>> - Faces: unsafe JSP + converters/handlers/_named_ beans + server side<br>
>> - Errai: compile time type safety, intensive integrity validation,<br>
>> client side optimizations<br>
>><br>
>> e.g.<br>
>> - the Errai compilation would fail, if a "Form"Composite declared a<br>
>> widget that is not found in its HTML template, thus enforcing the HTML<br>
>> template be generated _together_ with its "Form"Composite<br>
>> - by _re_building only _one_ entity (generateFromEntity) in Errai<br>
>> the generated code would possibly fail miserably w/o rebuilding also its<br>
>> related entities<br>
>><br>
>> Honestly I found myself frequently in the miserable position to rebuild<br>
>> the complete entity model because of interdependencies. Anyway, while<br>
>> writing these lines I find interesting possibilities to decouple code<br>
>> for more flexibility :-)<br>
>><br>
>> I am very interesting in evolving my plugin, so I hope you can give some<br>
>> idea about the planned templating etc.<br>
>> If there are not yet clear directions I am ready to scetch out the main<br>
>> issues I encountered for open discussions.<br>
>><br>
>> Thomas<br>
>><br>
>><br>
>> Am 06.03.2013 14:38, schrieb Vineet Reynolds Pereira:<br>
>>> Hello all,<br>
>>> This is more of a follow up on Lincoln's mail sent earlier on the cross-project scaffold team.<br>
>>><br>
>>> 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).<br>
>>><br>
>>> 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.<br>
>>><br>
>>> Thanks,<br>
>>> Vineet<br>
>>> _______________________________________________<br>
>>> forge-dev mailing list<br>
>>> <a href="mailto:forge-dev@lists.jboss.org">forge-dev@lists.jboss.org</a><br>
>>> <a href="https://lists.jboss.org/mailman/listinfo/forge-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/forge-dev</a><br>
>>><br>
>> _______________________________________________<br>
>> forge-dev mailing list<br>
>> <a href="mailto:forge-dev@lists.jboss.org">forge-dev@lists.jboss.org</a><br>
>> <a href="https://lists.jboss.org/mailman/listinfo/forge-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/forge-dev</a><br>
>><br>
>><br>
> _______________________________________________<br>
> forge-dev mailing list<br>
> <a href="mailto:forge-dev@lists.jboss.org">forge-dev@lists.jboss.org</a><br>
> <a href="https://lists.jboss.org/mailman/listinfo/forge-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/forge-dev</a><br>
><br>
<br>
_______________________________________________<br>
forge-dev mailing list<br>
<a href="mailto:forge-dev@lists.jboss.org">forge-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/forge-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/forge-dev</a></div></div></blockquote></div><br><br clear="all"><br>-- <br>Lincoln Baxter, III<br><a href="http://ocpsoft.org" target="_blank">http://ocpsoft.org</a><br>
"Simpler is better."
</div>