Re: [aerogear-dev] Aerogear Forge Plugin

Your Forge version is okay ... What about your maven version ? Seb On Tue, Feb 26, 2013 at 9:07 PM, Corinne Krych <corinnekrych(a)gmail.com&gt;wrote: > Hi Seb > > Same error on Fedora with jdk1.7.0_09. > Running with forge 1.2.0.Final > > Could it be the forge version? > > ++ > Corinne > > > On 26 February 2013 10:48, Sebastien Blanc <scm.blanc(a)gmail.com&gt; wrote: > >> >> >> On Tue, Feb 26, 2013 at 10:40 AM, Richard Kennard < >> richard(a)kennardconsulting.com&gt; wrote: >> >>> Seb, >>> >>> It sounds like there may be some convergence here. Your 'macros' >>> library may end up looking very similar to Metawidget's existing HTML5 >>> WidgetBuilder. And >>> your 'composition plugins' may end up similar to Metawidget's >>> LayoutDecorators and Layouts. >>> >>> I'd like to make sure you're not re-inventing the wheel here? Is your >>> main driver that you prefer writing templates in Freemarker to Java code? >>> >> >> Absolutely :) ! A user should be able to read and understand a template >> / overload them and not forced to write a Java class, a mid-term vision is >> to be more and more polyglot. >> Seb >> >> >>> Regards. >>> >>> Richard. >>> >>> On 26/02/2013 8:31 PM, Sebastien Blanc wrote: >>> > Hi Richard, >>> > Thanks for your remarks and questions, see my comments inline. >>> > >>> > On Tue, Feb 26, 2013 at 10:06 AM, Richard Kennard < >>> richard(a)kennardconsulting.com <mailto:richard@kennardconsulting.com>> >>> wrote: >>> > >>> > Hi Vineet, >>> > >>> > Thanks for your detailed response. >>> > >>> > I'm not opposed to the idea of a FreemarkerWidget (or >>> VelocityWidget, or StringTemplateWidget). Indeed, the early versions of >>> Metawidget looked much like >>> > you describe: a separate, pluggable inspection layer, then a >>> Metawidget to render it. >>> > >>> > However, we subsequently got a lot of feedback and did many >>> interviews, adoption studies and case studies. This ultimately led to the >>> architecture of >>> > pluggable WidgetBuilders, WidgetProcessors and Layouts. Let me >>> give you 3 examples of the feedback we got: >>> > >>> > 1. Widget choice needs to be orthogonal to layout. If you look at >>> your 'master.html.ftl' and 'detail.html.ftl' you have a lot of duplicated >>> code between >>> > them. Both templates contain <#if... #else to choose between a >>> 'select' box and a 'text' box. This code is going to inflate rapidly once >>> you add your >>> > date >>> > pickers, telephone numbers, URLs etc. to the mix. Worse, such >>> code will need to be duplicated across both templates. >>> > >>> > >>> > Vineet is currently factorizing all the duplicated code into >>> Freemarker's Macros, this Macros library will be shared along the different >>> plugins. >>> > >>> > >>> > 2. Equally, layout needs to be orthogonal to the wider page. Say >>> I decide I want to use tables with rows and columns, instead of a div-based >>> layout. >>> > Or say >>> > I want to use different CSS classes to your 'control-group' and >>> 'controls'. I will have to do it in both templates. But what is *actually* >>> different >>> > about >>> > the templates is the choice of search buttons/results versus >>> save/cancel buttons. So the 'middle bit' of each page needs to be >>> orthogonal. This will get >>> > worse as you add more templates, such as separate 'search', >>> 'view' and 'edit' templates (see the JSF scaffold). >>> > >>> > With Forge 2.0 in mind, where Plugins/addons will be able to be >>> dependent from each other, inherit from each other, we plan to end up with >>> some basic >>> > plugins which will offer a lot of flexibility to deliver "Composition >>> plugins". We are also going to introduce a lot of convention over >>> configuration but >>> > with keeping in mind that the user can always override the >>> conventions. >>> > >>> > >>> > 3. Developers like to use third-party widget libraries, and also >>> in-house custom widget libraries. If I want to add RichFaces, or >>> PrimeFaces, or a >>> > mixture >>> > of both, I want to be able to do so in a way that is orthogonal >>> to all of the above >>> > >>> > So my concern would be that a FreemarkerWidget would tightly >>> couple widget choice (WidgetBuilders) and layout, and not allow widget >>> processing (which is >>> > important for other reasons I haven't touched upon). Freemarker >>> does, I agree, offer an attractive level of immedicay and ease-of-editing >>> templates. >>> > But I >>> > wonder what your thoughts are on how it scales for some of the >>> points above? >>> > >>> > >>> > "Scaling" will be partly solved by the new architecture explained >>> above. For sure, there will always be situations where the user wants to >>> introduce his >>> > supra cool custom widget that don't fits without a lot of hacking but >>> IMO that's beyond the scope of scaffolding. Scaffolding is just to "boost >>> up" a new >>> > project, it's a one time action, for sure, we can offer entry points >>> for customization but we can't (or don't want to) cover all the specific >>> situations. >>> > >>> > Regards, >>> > Seb >>> > >>> > >>> > Regards, >>> > >>> > Richard. >>> > >>> > > On 22 February 2013 13:56, Vineet Reynolds Pereira < >>> vpereira(a)redhat.com <mailto:vpereira@redhat.com> <mailto: >>> vpereira(a)redhat.com >>> > <mailto:vpereira@redhat.com>>> wrote: >>> > > >>> > > Hi Richard, >>> > > >>> > > I'm glad you brought this up, since we've been looking >>> to provide feedback once we've finalized on our usage of the Metawidget >>> APIs. By the way, >>> > > I'm the one responsible for the use (or abuse) of >>> Metawidget in this manner. >>> > > >>> > > The rationale behind the use of Metawidget inspectors >>> alone, is mostly because we want to allow users to modify the generated >>> scaffold. One >>> > of the >>> > > examples thrown around was to enable users to generate >>> master-detail views instead of the plain CRUD forms generated by Forge. >>> Another driving >>> > factor >>> > > was the need to create or enable creation of scaffold >>> generators for several JS frameworks including but not restricted to >>> AngularJS, Backbone.js, >>> > > Aerogear etc. Furthermore, there is also a possibility of >>> users needing to bring in plugins and extensions to these frameworks, like >>> Angular-UI or >>> > > Backbone.Forms, since the base frameworks may not satisfy >>> all needs. From my understanding of the Metawidget pipeline and it's use in >>> the Forge >>> > Faces >>> > > and (the earlier) Aerogear scaffold plugins, this would >>> have been possible if a metawidget were created for every use case (one per >>> framework, per >>> > > widget-type). We attempted to bring in the use of templates >>> written in a familiar templating langu! >>> > > age (like Freemarker/Velocity/StringTemplate) into the >>> scaffold generation phase to make it easier for users to modify the >>> generated scaffold. >>> > This >>> > > is somewhat on the lines of what the Yeoman generators do. >>> > > >>> > > Thanks to the APIs you've made available for the >>> Metawidget pipeline, the inspection results could be processed before >>> feeding them to the >>> > > templates. Every scaffold plugin that could potentially be >>> written, would more or less use this approach, with the sole difference >>> being in the >>> > > contents of the templates themselves. I hope this explains >>> why I used the Inspectors alone, and not the InspectionResultProcessors and >>> the rest of >>> > > the pipeline. The inspectors just fit in naturally into the >>> Forge scaffold generation pipeline. >>> > > >>> > > Based on the above, I personally think that a >>> FreemarkerWidget (or VelocityWidget, or StringTemplateWidget) would be >>> something to investigate. >>> > > This is of course a raw idea of mine, and I would like to >>> see if it is possible to use such a metawidget in a type-safe manner with >>> the ability to >>> > > configure the templates that it would consume. I'm not sure >>> if creating such a widget would deviate from the intention behind the >>> Metawidget >>> > project. >>> > > >>> > > As a side note, I'd also like to point out that there >>> has been interest in supporting various additional HTML5 form input types >>> (telephone >>> > > numbers, URLs etc.) in the generated scaffold, and this >>> would require extending the JPA/Bean Validation Inspectors in Metawidget. >>> > > >>> > > Best regards, >>> > > Vineet >>> > > >>> > > PS: CC'ing the forge-dev list. >>> > > >>> > > ----- Original Message ----- >>> > > > From: "Richard Kennard" <richard(a)kennardconsulting.com&lt;mailto: >>> richard(a)kennardconsulting.com&gt; <mailto:richard@kennardconsulting.com >>> > <mailto:richard@kennardconsulting.com>>> >>> > > > To: aerogear-dev(a)lists.jboss.org <mailto: >>> aerogear-dev(a)lists.jboss.org&gt; <mailto:aerogear-dev@lists.jboss.org >>> > <mailto:aerogear-dev@lists.jboss.org>> >>> > > > Sent: Thursday, February 21, 2013 5:17:29 AM >>> > > > Subject: Re: [aerogear-dev] Aerogear Forge Plugin >>> > > > >>> > > > Seb, >>> > > > >>> > > > This looks very cool. I see you have used parts of >>> Metawidget for >>> > > > some of the implementation? I'd love to hear your >>> thoughts on how it >>> > > > went and/or any >>> > > > changes you'd like me to make to Metawidget. For example: >>> > > > >>> > > > 1. You have some code in Html5Scaffold that processes the >>> inspection >>> > > > result returned by CompositeInspector. It does things like >>> > > > 'Canonicalize all numerical >>> > > > types in Java to "number" for HTML5 form input type >>> support' and >>> > > > 'Extract simple type name of the relationship types'. Was >>> there a >>> > > > reason you didn't factor >>> > > > this into a Metawidget InspectionResultProcessor >>> > > > (http://metawidget.org/doc/reference/en/html/ch02s03.html >>> )? >>> > > > Specifically BaseInspectionResultProcessor has >>> > > > some methods to help? >>> > > > >>> > > > 2. You appear to be using FreeMarker templates rather than >>> > > > Metawidget's WidgetBuilders, WidgetProcessors and Layouts >>> (see the >>> > > > existing Forge JSF scaffold, >>> > > > Forge GWT scaffold, and Forge Spring scaffold). Could I >>> ask what the >>> > > > reasons were behind this? >>> > > > >>> > > > 3. I have recently implemented a pure client-side, pure >>> run-time, >>> > > > AngularJS version of Metawidget. If you were interested >>> in a >>> > > > non-static version of your >>> > > > scaffold, perhaps you could give it a try? >>> > > > >>> http://blog.kennardconsulting.com/2013/01/metawidget-meets-jquery-ui-and-... >>> > > > >>> > > > Regards, >>> > > > >>> > > > Richard. >>> > > > >>> > > > On 20/02/2013 11:49 PM, Jay Balunas wrote: >>> > > > > Wow!!! Really awesome work guys!!! >>> > > > > >>> > > > > On Feb 15, 2013, at 11:15 AM, Sebastien Blanc wrote: >>> > > > > >>> > > > >> Hi all ! >>> > > > >> I'm pleased to announce that the first version of the >>> Aerogear >>> > > > >> Scaffold Plugin for forge is available ! >>> > > > >> It's still an alpha but thanks to the excellent work >>> and help from >>> > > > >> Vineet we have a working plugin : >>> > > > >> >>> > > > >> - CRUD Scaffolding based on your entities. >>> > > > >> - One-to-one , many-to-one relation supported. >>> > > > >> - AngularJS and bootstrap responsive based. >>> > > > >> - Aerogear Pipe and Store used. >>> > > > >> >>> > > > >> There is still a lot to do but you can already play >>> with it, a >>> > > > >> quickstart is available here and you should be able to >>> create >>> > > > >> your first Aerogear App in >>> > > > >> 5 minutes ;) >>> https://gist.github.com/sebastienblanc/4961324 >>> > > > >> >>> > > > >> An example of a generated application can also be >>> found here : >>> > > > >> https://github.com/sebastienblanc/scaffoldtester , >>> please review >>> > > > >> the generated code (at >>> > > > >> least the JS and HTML) and report it to me and I will >>> update the >>> > > > >> templates accordingly. >>> > > > >> >>> > > > >> Next steps are : >>> > > > >> - Integrate Search feature (using the DataStore filter >>> facilities) >>> > > > >> - Integrate Aerogear Pagination (although generic >>> pagination is >>> > > > >> present now) >>> > > > >> - Integrate jQueryMobile (will probably be another >>> plugin) >>> > > > >> >>> > > > >> Enjoy ! >>> > > > >> >>> > > > >> Seb >>> > > > >> >>> > > > >> _______________________________________________ >>> > > > >> aerogear-dev mailing list >>> > > > >> aerogear-dev(a)lists.jboss.org <mailto: >>> aerogear-dev(a)lists.jboss.org&gt; <mailto:aerogear-dev@lists.jboss.org >>> > <mailto:aerogear-dev@lists.jboss.org>> <mailto: >>> aerogear-dev(a)lists.jboss.org <mailto:aerogear-dev@lists.jboss.org> >>> > <mailto:aerogear-dev@lists.jboss.org <mailto: >>> aerogear-dev(a)lists.jboss.org&gt;&gt;&gt; >>> > > > >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> > > > > >>> > > > > >>> > > > > >>> > > > > _______________________________________________ >>> > > > > aerogear-dev mailing list >>> > > > > aerogear-dev(a)lists.jboss.org <mailto: >>> aerogear-dev(a)lists.jboss.org&gt; <mailto:aerogear-dev@lists.jboss.org<mailto: >>> aerogear-dev(a)lists.jboss.org&gt;&gt; >>> > > > > https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> > > > >>> > > > _______________________________________________ >>> > > > aerogear-dev mailing list >>> > > > aerogear-dev(a)lists.jboss.org <mailto: >>> aerogear-dev(a)lists.jboss.org&gt; <mailto:aerogear-dev@lists.jboss.org<mailto: >>> aerogear-dev(a)lists.jboss.org&gt;&gt; >>> > > > https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> > > > >>> > > >>> > > _______________________________________________ >>> > > aerogear-dev mailing list >>> > > aerogear-dev(a)lists.jboss.org <mailto: >>> aerogear-dev(a)lists.jboss.org&gt; <mailto:aerogear-dev@lists.jboss.org<mailto: >>> aerogear-dev(a)lists.jboss.org&gt;&gt; >>> > > https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> > > >>> > > >>> > > >>> > > >>> > > _______________________________________________ >>> > > aerogear-dev mailing list >>> > > aerogear-dev(a)lists.jboss.org <mailto: >>> aerogear-dev(a)lists.jboss.org&gt; >>> > > https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> > >>> > _______________________________________________ >>> > aerogear-dev mailing list >>> > aerogear-dev(a)lists.jboss.org <mailto:aerogear-dev@lists.jboss.org >>> > >>> > https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> > >>> > >>> > >>> > >>> > _______________________________________________ >>> > aerogear-dev mailing list >>> > aerogear-dev(a)lists.jboss.org >>> > https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev >