[aerogear-dev] Aerogear Forge Plugin
Sebastien Blanc
scm.blanc at gmail.com
Wed Feb 27 06:19:55 EST 2013
Richard,
You are totally right by saying than maintaining a 500 characters long line
will be a nightmare and the current implementation was just a first try.
Vineet as started to factorize the code into macros, you can see it here :
https://github.com/forge/scaffold-html5/blob/master/src/main/resources/scaffold/angularjs/views/includes/basicPropertyDetail.html.ftl
But in the same time, we are working on an architecture that will have a
single/common point of entry for the "widget choosing code" and we can plug
whatever widget renderer template into it. To make this easier, I have
created a simple project ,just for you ;) , to demonstrate the main
concept.
https://github.com/sebastienblanc/freemarkertests
You will see the default renderer (renderer.tpl) and a custom renderer
(custom.tpl). The testcases will use the same "widget selector" but their
"own" renderer. A custom widget renderer template can override all the
widgets or only some of them, it is very flexible.
Please feel free to provide any feedback.
Best Regards,
Seb
On Tue, Feb 26, 2013 at 10:49 PM, Richard Kennard <
richard at kennardconsulting.com> wrote:
> Seb,
>
> Thank you for your feedback.
>
> I'm afraid we'll need to agree to disagree that Freemarker is a good
> medium for implementing 'widget choosing' code. Your current implementation
> is
> basically a single line that is 500 characters long. I fear this will
> become a rapidly worsening maintenance problem.
>
> However you make a good point about using Freemarker for the layout. I
> will look at implementing a FreemarkerLayout into Metawidget.
>
> Regards,
>
> Richard.
>
> On 26/02/2013 8:48 PM, Sebastien Blanc wrote:
> >
> >
> > On Tue, Feb 26, 2013 at 10:40 AM, Richard Kennard <
> richard at kennardconsulting.com <mailto: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>
> > <mailto: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>> <mailto: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>> <mailto:
> 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>> <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>>>
> > > > > 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>>> <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
> > <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>> <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>> <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>> <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>
> > > 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/20130227/c85e02c4/attachment-0001.html
More information about the aerogear-dev
mailing list