9:56 p.m.
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 language (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>
To: aerogear-dev(a)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@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