[aerogear-dev] Aerogear Forge Plugin
Sebastien Blanc
scm.blanc at gmail.com
Tue Feb 26 15:53:36 EST 2013
Your Forge version is okay ...
What about your maven version ?
Seb
On Tue, Feb 26, 2013 at 9:07 PM, Corinne Krych <corinnekrych at gmail.com>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 at gmail.com> wrote:
>
>>
>>
>> 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
>>>
>>
>>
>> _______________________________________________
>> 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/6d55aa89/attachment-0001.html
More information about the aerogear-dev
mailing list