[aerogear-dev] Aerogear Forge Plugin

Sebastien Blanc scm.blanc at gmail.com
Tue Feb 26 04:48:52 EST 2013


On Tue, Feb 26, 2013 at 10:40 AM, Richard Kennard <
richard at kennardconsulting.com> 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 at kennardconsulting.com <mailto:richard at 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 at redhat.com <mailto:vpereira at redhat.com> <mailto:
> vpereira at redhat.com
> >     <mailto:vpereira at 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 at kennardconsulting.com<mailto:
> richard at kennardconsulting.com> <mailto:richard at kennardconsulting.com
> >     <mailto:richard at kennardconsulting.com>>>
> >     >     > To: aerogear-dev at lists.jboss.org <mailto:
> aerogear-dev at lists.jboss.org> <mailto:aerogear-dev at lists.jboss.org
> >     <mailto:aerogear-dev at 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-angularjs.html
> >     >     >
> >     >     > 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 at lists.jboss.org <mailto:
> aerogear-dev at lists.jboss.org> <mailto:aerogear-dev at lists.jboss.org
> >     <mailto:aerogear-dev at lists.jboss.org>> <mailto:
> aerogear-dev at lists.jboss.org <mailto:aerogear-dev at lists.jboss.org>
> >     <mailto:aerogear-dev at lists.jboss.org <mailto:
> aerogear-dev at lists.jboss.org>>>
> >     >     > >> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >     >     > >
> >     >     > >
> >     >     > >
> >     >     > > _______________________________________________
> >     >     > > aerogear-dev mailing list
> >     >     > > aerogear-dev at lists.jboss.org <mailto:
> aerogear-dev at lists.jboss.org> <mailto:aerogear-dev at lists.jboss.org<mailto:
> aerogear-dev at lists.jboss.org>>
> >     >     > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >     >     >
> >     >     > _______________________________________________
> >     >     > aerogear-dev mailing list
> >     >     > aerogear-dev at lists.jboss.org <mailto:
> aerogear-dev at lists.jboss.org> <mailto:aerogear-dev at lists.jboss.org<mailto:
> aerogear-dev at lists.jboss.org>>
> >     >     > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >     >     >
> >     >
> >     >     _______________________________________________
> >     >     aerogear-dev mailing list
> >     > aerogear-dev at lists.jboss.org <mailto:aerogear-dev at lists.jboss.org>
> <mailto:aerogear-dev at lists.jboss.org <mailto:aerogear-dev at lists.jboss.org
> >>
> >     > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >     >
> >     >
> >     >
> >     >
> >     > _______________________________________________
> >     > aerogear-dev mailing list
> >     > aerogear-dev at lists.jboss.org <mailto:aerogear-dev at lists.jboss.org>
> >     > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >
> >     _______________________________________________
> >     aerogear-dev mailing list
> >     aerogear-dev at lists.jboss.org <mailto:aerogear-dev at lists.jboss.org>
> >     https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >
> >
> >
> >
> > _______________________________________________
> > aerogear-dev mailing list
> > aerogear-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20130226/e6960622/attachment-0001.html 


More information about the aerogear-dev mailing list