5:15 p.m.
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
11:50 p.m.
Ow great news!
On Feb 15, 2013, at 2:15 PM, Sebastien Blanc <scm.blanc(a)gmail.com> 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
https://lists.jboss.org/mailman/listinfo/aerogear-dev
12:58 a.m.
Awesome news...but for those people with JBDS6
Attempting to use the Forge in JBDS6
***ERROR*** Exception encountered: Could not install plugin
[org.jboss.forge.scaffold.html5.plugin-scaffold-html5] because it references Forge API
version [1.2.0.Final] which may not be compatible with my current version [1.1.2.Final].
Please consider upgrading forge, by typing 'forge update'. Otherwise, try
installing an older version of the plugin. (type "set VERBOSE true" to enable
stack traces)
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
https://lists.jboss.org/mailman/listinfo/aerogear-dev
1:32 a.m.
I upgraded my forge runtime within JBDS and it all ran successfully!
A couple of gotchas:
- jquery.min.js causes Eclipse to produce errors - perhaps we the Forge Plugin for Eclipse
could turn of JS validation in this situation?
- the validation error messages were not visible to the end-user - so, the StoreOrder
submit basically does nothing (from the end-user perspective) when he submits an amount
over 50. The error shows up on the server console.
Overall, this is really cool stuff! Vineet & Sebastian - fantastic work in a very
short timeframe.
I hope to have pieces of this in several demos during the Red Hat Summit in June. :-)
On Feb 18, 2013, at 6:58 PM, Burr Sutter wrote:
Awesome news...but for those people with JBDS6
Attempting to use the Forge in JBDS6
***ERROR*** Exception encountered: Could not install plugin
[org.jboss.forge.scaffold.html5.plugin-scaffold-html5] because it references Forge API
version [1.2.0.Final] which may not be compatible with my current version [1.1.2.Final].
Please consider upgrading forge, by typing 'forge update'. Otherwise, try
installing an older version of the plugin. (type "set VERBOSE true" to enable
stack traces)
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
> 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
8:45 a.m.
----- Original Message -----
From: "Burr Sutter" <bsutter(a)redhat.com>
To: "AeroGear Developer Mailing List" <aerogear-dev(a)lists.jboss.org>
Cc: "Vineet Reynolds Pereira" <vpereira(a)redhat.com>, "Lincoln
Baxter, III" <lincolnbaxter(a)gmail.com>, "Koen Aers"
<koen.aers(a)jboss.com>
Sent: Tuesday, February 19, 2013 6:02:00 AM
Subject: Re: [aerogear-dev] Aerogear Forge Plugin
I upgraded my forge runtime within JBDS and it all ran successfully!
A couple of gotchas:
- jquery.min.js causes Eclipse to produce errors - perhaps we the
Forge Plugin for Eclipse could turn of JS validation in this
situation?
This is a bit frustrating because minified versions of libraries always trip up the
Eclipse JS validator.
The development versions do not cause this problem, hence the reason including angular.js
instead of angular.min.js.
I have to revisit this though, since having a single version alone in different contexts
(development/production) is bound to raise eyebrows.
Perhaps, we could borrow something from yeoman here.
I'd like to hear the AG team's take on this.
- the validation error messages were not visible to the end-user -
so, the StoreOrder submit basically does nothing (from the end-user
perspective) when he submits an amount over 50. The error shows up
on the server console.
Building in 'robust' error handling into the scaffold at the client and the server
is still in the works. I hope to have nailed this down by next week.
For now, the AngularJS scaffold does some client-side validation, while preventing the
form submit [1]; note the disabled save button in the screenshots.
The aerogear scaffold generator would need to merge the changes from the plain angular
one, to have this capability.
The REST resources (and the error handling protocol) are however a different thing to
tackle, and this is what needs nailing down.
[1]: http://imgur.com/a/ucNcU
P.S. The plain AngularJS (no AG) generated app is available here:
https://github.com/VineetReynolds/scaffold-tester
Overall, this is really cool stuff! Vineet & Sebastian - fantastic
work in a very short timeframe.
I hope to have pieces of this in several demos during the Red Hat
Summit in June. :-)
On Feb 18, 2013, at 6:58 PM, Burr Sutter wrote:
Awesome news...but for those people with JBDS6
Attempting to use the Forge in JBDS6
***ERROR*** Exception encountered: Could not install plugin
[org.jboss.forge.scaffold.html5.plugin-scaffold-html5] because it
references Forge API version [1.2.0.Final] which may not be
compatible with my current version [1.1.2.Final]. Please consider
upgrading forge, by typing 'forge update'. Otherwise, try installing
an older version of the plugin. (type "set VERBOSE true" to enable
stack traces)
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
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
8:09 a.m.
Well, that error was also reported by a friend of mine trying out the plugin on JBoss
Tools 3.3 (Indigo). We need to sort out the lowest version of the Forge API that this
scaffold plugin would support; some or most of the other plugins (like as7, arquillian)
are compiled against lower versions (1.0.2, 1.0.5 ?). But thanks again for bringing this
up, since otherwise this is just a task on my personal trello.
Lincoln,
Do you think it would be a good idea to have this scaffold plugin as a blessed
plugin?
Vineet
----- Original Message -----
From: "Burr Sutter" <bsutter(a)redhat.com>
To: "AeroGear Developer Mailing List" <aerogear-dev(a)lists.jboss.org>
Cc: vpereira(a)redhat.com, "Lincoln Baxter, III" <lincolnbaxter(a)gmail.com>
Sent: Tuesday, February 19, 2013 5:28:16 AM
Subject: Re: [aerogear-dev] Aerogear Forge Plugin
Awesome news...but for those people with JBDS6
Attempting to use the Forge in JBDS6
***ERROR*** Exception encountered: Could not install plugin
[org.jboss.forge.scaffold.html5.plugin-scaffold-html5] because it
references Forge API version [1.2.0.Final] which may not be
compatible with my current version [1.1.2.Final]. Please consider
upgrading forge, by typing 'forge update'. Otherwise, try installing
an older version of the plugin. (type "set VERBOSE true" to enable
stack traces)
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
https://lists.jboss.org/mailman/listinfo/aerogear-dev
1:49 p.m.
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
https://lists.jboss.org/mailman/listinfo/aerogear-dev
12:47 a.m.
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
1: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
12:39 a.m.
Hello Seb,
I wanted to try the new plugin but when intalling it
as explained in https://gist.github.com/sebastienblanc/4961324
I run into:
[INFO] -------------------------------------------------------------
[ERROR] COMPILATION ERROR :
[INFO] -------------------------------------------------------------
[ERROR]
/private/var/folders/cl/80xt717d7d1_xbm129m6t6c00000gn/T/forgetemp8490423288991539154/repo/src/main/java/org/jboss/forge/scaffold/html5/metawidget/inspector/propertystyle/ForgePropertyStyle.java:[153,22]
incompatible types; inferred type argument(s) java.lang.Object do not
conform to bounds of type variable(s) O
found : <O>void
required: void
[INFO] 1 error
[INFO] -------------------------------------------------------------
[INFO]
------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO]
------------------------------------------------------------------------
[INFO] Total time: 2.277s
[INFO] Finished at: Mon Feb 25 00:33:24 CET 2013
[INFO] Final Memory: 14M/81M
[INFO]
------------------------------------------------------------------------
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-compiler-plugin:2.3.2:compile
(default-compile) on project plugin-scaffold-html5: Compilation failure
[ERROR]
/private/var/folders/cl/80xt717d7d1_xbm129m6t6c00000gn/T/forgetemp8490423288991539154/repo/src/main/java/org/jboss/forge/scaffold/html5/metawidget/inspector/propertystyle/ForgePropertyStyle.java:[153,22]
incompatible types; inferred type argument(s) java.lang.Object do not
conform to bounds of type variable(s) O
[ERROR] found : <O>void
[ERROR] required: void
[ERROR] -> [Help 1]
Any idea, where it could come from?
Thks,
Corinne
On 22 February 2013 13:56, Vineet Reynolds Pereira <vpereira(a)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>
> 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
>
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
8:37 a.m.
Corinne,
could you put the project in github so that I yake a look. Did you get a
error when running the mod or at the install moment ?
Seb
On Mon, Feb 25, 2013 at 12:39 AM, Corinne Krych <corinnekrych(a)gmail.com>wrote:
Hello Seb,
I wanted to try the new plugin but when intalling it
as explained in https://gist.github.com/sebastienblanc/4961324
I run into:
[INFO] -------------------------------------------------------------
[ERROR] COMPILATION ERROR :
[INFO] -------------------------------------------------------------
[ERROR]
/private/var/folders/cl/80xt717d7d1_xbm129m6t6c00000gn/T/forgetemp8490423288991539154/repo/src/main/java/org/jboss/forge/scaffold/html5/metawidget/inspector/propertystyle/ForgePropertyStyle.java:[153,22]
incompatible types; inferred type argument(s) java.lang.Object do not
conform to bounds of type variable(s) O
found : <O>void
required: void
[INFO] 1 error
[INFO] -------------------------------------------------------------
[INFO]
------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO]
------------------------------------------------------------------------
[INFO] Total time: 2.277s
[INFO] Finished at: Mon Feb 25 00:33:24 CET 2013
[INFO] Final Memory: 14M/81M
[INFO]
------------------------------------------------------------------------
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-compiler-plugin:2.3.2:compile
(default-compile) on project plugin-scaffold-html5: Compilation failure
[ERROR]
/private/var/folders/cl/80xt717d7d1_xbm129m6t6c00000gn/T/forgetemp8490423288991539154/repo/src/main/java/org/jboss/forge/scaffold/html5/metawidget/inspector/propertystyle/ForgePropertyStyle.java:[153,22]
incompatible types; inferred type argument(s) java.lang.Object do not
conform to bounds of type variable(s) O
[ERROR] found : <O>void
[ERROR] required: void
[ERROR] -> [Help 1]
Any idea, where it could come from?
Thks,
Corinne
On 22 February 2013 13:56, Vineet Reynolds Pereira <vpereira(a)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>
> > 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
> >
>
> _______________________________________________
> 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
11:16 a.m.
Corinne,
Forget my comment about "when running the mod" , was not waked up totally
:) , I thought you were talking about the vertx scaffolding tool :)
Seb
On Mon, Feb 25, 2013 at 8:37 AM, Sebastien Blanc <scm.blanc(a)gmail.com>wrote:
Corinne,
could you put the project in github so that I yake a look. Did you get a
error when running the mod or at the install moment ?
Seb
On Mon, Feb 25, 2013 at 12:39 AM, Corinne Krych <corinnekrych(a)gmail.com>wrote:
> Hello Seb,
>
> I wanted to try the new plugin but when intalling it
> as explained in https://gist.github.com/sebastienblanc/4961324
>
> I run into:
> [INFO] -------------------------------------------------------------
> [ERROR] COMPILATION ERROR :
> [INFO] -------------------------------------------------------------
> [ERROR]
>
/private/var/folders/cl/80xt717d7d1_xbm129m6t6c00000gn/T/forgetemp8490423288991539154/repo/src/main/java/org/jboss/forge/scaffold/html5/metawidget/inspector/propertystyle/ForgePropertyStyle.java:[153,22]
> incompatible types; inferred type argument(s) java.lang.Object do not
> conform to bounds of type variable(s) O
> found : <O>void
> required: void
> [INFO] 1 error
> [INFO] -------------------------------------------------------------
> [INFO]
> ------------------------------------------------------------------------
> [INFO] BUILD FAILURE
> [INFO]
> ------------------------------------------------------------------------
> [INFO] Total time: 2.277s
> [INFO] Finished at: Mon Feb 25 00:33:24 CET 2013
> [INFO] Final Memory: 14M/81M
> [INFO]
> ------------------------------------------------------------------------
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-compiler-plugin:2.3.2:compile
> (default-compile) on project plugin-scaffold-html5: Compilation failure
> [ERROR]
>
/private/var/folders/cl/80xt717d7d1_xbm129m6t6c00000gn/T/forgetemp8490423288991539154/repo/src/main/java/org/jboss/forge/scaffold/html5/metawidget/inspector/propertystyle/ForgePropertyStyle.java:[153,22]
> incompatible types; inferred type argument(s) java.lang.Object do not
> conform to bounds of type variable(s) O
> [ERROR] found : <O>void
> [ERROR] required: void
> [ERROR] -> [Help 1]
>
> Any idea, where it could come from?
>
> Thks,
> Corinne
>
>
>
> On 22 February 2013 13:56, Vineet Reynolds Pereira <vpereira(a)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>
>> > 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
>> >
>>
>> _______________________________________________
>> 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
>
11:21 a.m.
Seb
I'm trying the HTML5 scaffolding and get the error when installing the
plugin on forge:
when typing the command:
forge git-plugin git://github.com/sebastienblanc/scaffold-html5 --ref
scaffold-aerogear
Anything obvious, I'm doing wrong?
++
Corinne
On 25 February 2013 11:16, Sebastien Blanc <scm.blanc(a)gmail.com> wrote:
Corinne,
Forget my comment about "when running the mod" , was not waked up totally
:) , I thought you were talking about the vertx scaffolding tool :)
Seb
On Mon, Feb 25, 2013 at 8:37 AM, Sebastien Blanc <scm.blanc(a)gmail.com>wrote:
> Corinne,
> could you put the project in github so that I yake a look. Did you get a
> error when running the mod or at the install moment ?
> Seb
>
>
> On Mon, Feb 25, 2013 at 12:39 AM, Corinne Krych <corinnekrych(a)gmail.com>wrote:
>
>> Hello Seb,
>>
>> I wanted to try the new plugin but when intalling it
>> as explained in https://gist.github.com/sebastienblanc/4961324
>>
>> I run into:
>> [INFO] -------------------------------------------------------------
>> [ERROR] COMPILATION ERROR :
>> [INFO] -------------------------------------------------------------
>> [ERROR]
>>
/private/var/folders/cl/80xt717d7d1_xbm129m6t6c00000gn/T/forgetemp8490423288991539154/repo/src/main/java/org/jboss/forge/scaffold/html5/metawidget/inspector/propertystyle/ForgePropertyStyle.java:[153,22]
>> incompatible types; inferred type argument(s) java.lang.Object do not
>> conform to bounds of type variable(s) O
>> found : <O>void
>> required: void
>> [INFO] 1 error
>> [INFO] -------------------------------------------------------------
>> [INFO]
>> ------------------------------------------------------------------------
>> [INFO] BUILD FAILURE
>> [INFO]
>> ------------------------------------------------------------------------
>> [INFO] Total time: 2.277s
>> [INFO] Finished at: Mon Feb 25 00:33:24 CET 2013
>> [INFO] Final Memory: 14M/81M
>> [INFO]
>> ------------------------------------------------------------------------
>> [ERROR] Failed to execute goal
>> org.apache.maven.plugins:maven-compiler-plugin:2.3.2:compile
>> (default-compile) on project plugin-scaffold-html5: Compilation failure
>> [ERROR]
>>
/private/var/folders/cl/80xt717d7d1_xbm129m6t6c00000gn/T/forgetemp8490423288991539154/repo/src/main/java/org/jboss/forge/scaffold/html5/metawidget/inspector/propertystyle/ForgePropertyStyle.java:[153,22]
>> incompatible types; inferred type argument(s) java.lang.Object do not
>> conform to bounds of type variable(s) O
>> [ERROR] found : <O>void
>> [ERROR] required: void
>> [ERROR] -> [Help 1]
>>
>> Any idea, where it could come from?
>>
>> Thks,
>> Corinne
>>
>>
>>
>> On 22 February 2013 13:56, Vineet Reynolds Pereira
<vpereira(a)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>
>>> > 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
>>> >
>>>
>>> _______________________________________________
>>> 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
10:06 a.m.
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.
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).
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?
Regards,
Richard.
On 22 February 2013 13:56, Vineet Reynolds Pereira
<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
<mailto:richard@kennardconsulting.com>>
> To: aerogear-dev(a)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@lists.jboss.org> <mailto:aerogear-dev@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 <mailto:aerogear-dev@lists.jboss.org>
> > 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 <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
10:31 a.m.
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> 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(a)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
<mailto:
richard(a)kennardconsulting.com>>
> > To: aerogear-dev(a)lists.jboss.org <mailto:
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(a)lists.jboss.org> <mailto:aerogear-dev@lists.jboss.org<mailto:
aerogear-dev(a)lists.jboss.org>>
> > >> 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>
> > > 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 <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
10:40 a.m.
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?
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@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
<mailto:richard@kennardconsulting.com> <mailto:richard@kennardconsulting.com
<mailto:richard@kennardconsulting.com>>>
> > To: aerogear-dev(a)lists.jboss.org
<mailto:aerogear-dev@lists.jboss.org> <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@lists.jboss.org> <mailto:aerogear-dev@lists.jboss.org
<mailto:aerogear-dev@lists.jboss.org>>
<mailto:aerogear-dev@lists.jboss.org <mailto:aerogear-dev@lists.jboss.org>
<mailto:aerogear-dev@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
<mailto:aerogear-dev@lists.jboss.org> <mailto:aerogear-dev@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
<mailto:aerogear-dev@lists.jboss.org> <mailto:aerogear-dev@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 <mailto:aerogear-dev@lists.jboss.org>
<mailto:aerogear-dev@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 <mailto:aerogear-dev@lists.jboss.org>
> 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
10:48 a.m.
On Tue, Feb 26, 2013 at 10:40 AM, Richard Kennard <
richard(a)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(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<mailto:
richard(a)kennardconsulting.com> <mailto:richard@kennardconsulting.com
> <mailto:richard@kennardconsulting.com>>>
> > > To: aerogear-dev(a)lists.jboss.org <mailto:
aerogear-dev(a)lists.jboss.org> <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> <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>>>
> > > >> 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> <mailto:aerogear-dev@lists.jboss.org<mailto:
aerogear-dev(a)lists.jboss.org>>
> > > > 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> <mailto:aerogear-dev@lists.jboss.org<mailto:
aerogear-dev(a)lists.jboss.org>>
> > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > >
> >
> > _______________________________________________
> > aerogear-dev mailing list
> > aerogear-dev(a)lists.jboss.org <mailto:aerogear-dev@lists.jboss.org>
<mailto:aerogear-dev@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 <mailto:aerogear-dev@lists.jboss.org>
> > 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
9:07 p.m.
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> wrote:
On Tue, Feb 26, 2013 at 10:40 AM, Richard Kennard <
richard(a)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(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<mailto:
> richard(a)kennardconsulting.com> <mailto:richard@kennardconsulting.com
> > <mailto:richard@kennardconsulting.com>>>
> > > > To: aerogear-dev(a)lists.jboss.org <mailto:
> aerogear-dev(a)lists.jboss.org> <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> <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>>>
> > > > >>
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> <mailto:aerogear-dev@lists.jboss.org<mailto:
> aerogear-dev(a)lists.jboss.org>>
> > > > > 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> <mailto:aerogear-dev@lists.jboss.org<mailto:
> aerogear-dev(a)lists.jboss.org>>
> > > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > > >
> > >
> > > _______________________________________________
> > > aerogear-dev mailing list
> > > aerogear-dev(a)lists.jboss.org
<mailto:aerogear-dev@lists.jboss.org>
> <mailto:aerogear-dev@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 <mailto:aerogear-dev@lists.jboss.org
> >
> > > 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
9:53 p.m.
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>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> wrote:
>
>
> On Tue, Feb 26, 2013 at 10:40 AM, Richard Kennard <
> richard(a)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(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<mailto:
>> richard(a)kennardconsulting.com> <mailto:richard@kennardconsulting.com
>> > <mailto:richard@kennardconsulting.com>>>
>> > > > To: aerogear-dev(a)lists.jboss.org <mailto:
>> aerogear-dev(a)lists.jboss.org> <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> <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>>>
>> > > > >>
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>
<mailto:aerogear-dev@lists.jboss.org<mailto:
>> aerogear-dev(a)lists.jboss.org>>
>> > > > >
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>
<mailto:aerogear-dev@lists.jboss.org<mailto:
>> aerogear-dev(a)lists.jboss.org>>
>> > > > 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>
<mailto:aerogear-dev@lists.jboss.org<mailto:
>> aerogear-dev(a)lists.jboss.org>>
>> > > 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>
>> > > 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
10:03 p.m.
And also openJDK or Oracle JDK ?
Just asking because I'm out of ideas :)
Seb
On Tue, Feb 26, 2013 at 9:53 PM, Sebastien Blanc <scm.blanc(a)gmail.com>wrote:
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>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> wrote:
>
>>
>>
>> On Tue, Feb 26, 2013 at 10:40 AM, Richard Kennard <
>> richard(a)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(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<mailto:
>>> richard(a)kennardconsulting.com> <mailto:richard@kennardconsulting.com
>>> > <mailto:richard@kennardconsulting.com>>>
>>> > > > To: aerogear-dev(a)lists.jboss.org <mailto:
>>> aerogear-dev(a)lists.jboss.org> <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> <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>>>
>>> > > > >>
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>
<mailto:aerogear-dev@lists.jboss.org<mailto:
>>> aerogear-dev(a)lists.jboss.org>>
>>> > > > >
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>
<mailto:aerogear-dev@lists.jboss.org<mailto:
>>> aerogear-dev(a)lists.jboss.org>>
>>> > > > 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>
<mailto:aerogear-dev@lists.jboss.org<mailto:
>>> aerogear-dev(a)lists.jboss.org>>
>>> > > 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>
>>> > > 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
>
10:09 p.m.
Apache Maven 3.0.3 (r1075438; 2011-02-28 18:31:09+0100)
Java version: 1.6.0_37, vendor: Apple Inc.
On 26 February 2013 22:03, Sebastien Blanc <scm.blanc(a)gmail.com> wrote:
And also openJDK or Oracle JDK ?
Just asking because I'm out of ideas :)
Seb
On Tue, Feb 26, 2013 at 9:53 PM, Sebastien Blanc <scm.blanc(a)gmail.com>wrote:
> 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>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> wrote:
>>
>>>
>>>
>>> On Tue, Feb 26, 2013 at 10:40 AM, Richard Kennard <
>>> richard(a)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(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<mailto:
>>>> richard(a)kennardconsulting.com>
<mailto:richard@kennardconsulting.com
>>>> > <mailto:richard@kennardconsulting.com>>>
>>>> > > > To: aerogear-dev(a)lists.jboss.org <mailto:
>>>> aerogear-dev(a)lists.jboss.org> <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> <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>>>
>>>> > > > >>
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>
<mailto:aerogear-dev@lists.jboss.org<mailto:
>>>> aerogear-dev(a)lists.jboss.org>>
>>>> > > > >
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>
<mailto:aerogear-dev@lists.jboss.org<mailto:
>>>> aerogear-dev(a)lists.jboss.org>>
>>>> > > >
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>
<mailto:aerogear-dev@lists.jboss.org<mailto:
>>>> aerogear-dev(a)lists.jboss.org>>
>>>> > > 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>
>>>> > > 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>
>>>> > 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
>>
>
>
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
10:15 p.m.
Ok , could you try to run Maven with jdk 1.7 ?
On Tue, Feb 26, 2013 at 10:09 PM, Corinne Krych <corinnekrych(a)gmail.com>wrote:
Apache Maven 3.0.3 (r1075438; 2011-02-28 18:31:09+0100)
Java version: 1.6.0_37, vendor: Apple Inc.
On 26 February 2013 22:03, Sebastien Blanc <scm.blanc(a)gmail.com> wrote:
> And also openJDK or Oracle JDK ?
> Just asking because I'm out of ideas :)
> Seb
>
>
> On Tue, Feb 26, 2013 at 9:53 PM, Sebastien Blanc <scm.blanc(a)gmail.com>wrote:
>
>> 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>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>
wrote:
>>>
>>>>
>>>>
>>>> On Tue, Feb 26, 2013 at 10:40 AM, Richard Kennard <
>>>> richard(a)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(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<mailto:
>>>>> richard(a)kennardconsulting.com>
<mailto:richard@kennardconsulting.com
>>>>> > <mailto:richard@kennardconsulting.com>>>
>>>>> > > > To: aerogear-dev(a)lists.jboss.org <mailto:
>>>>> aerogear-dev(a)lists.jboss.org>
<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>
<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>>>
>>>>> > > > >>
>>>>> 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>
<mailto:aerogear-dev@lists.jboss.org<mailto:
>>>>> aerogear-dev(a)lists.jboss.org>>
>>>>> > > > >
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>
<mailto:aerogear-dev@lists.jboss.org<mailto:
>>>>> aerogear-dev(a)lists.jboss.org>>
>>>>> > > >
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>
<mailto:aerogear-dev@lists.jboss.org<mailto:
>>>>> aerogear-dev(a)lists.jboss.org>>
>>>>> > > 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>
>>>>> > > 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>
>>>>> > 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
>>>
>>
>>
>
> _______________________________________________
> 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
10:48 p.m.
Indeed you were right:
[INFO]
------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO]
------------------------------------------------------------------------
with
Apache Maven 3.0.3 (r1075438; 2011-02-28 18:31:09+0100)
Maven home: /usr/share/maven
Java version: 1.7.0_15, vendor: Oracle Corporation
++
Corinne
On 26 February 2013 22:15, Sebastien Blanc <scm.blanc(a)gmail.com> wrote:
Ok , could you try to run Maven with jdk 1.7 ?
On Tue, Feb 26, 2013 at 10:09 PM, Corinne Krych <corinnekrych(a)gmail.com>wrote:
> Apache Maven 3.0.3 (r1075438; 2011-02-28 18:31:09+0100)
> Java version: 1.6.0_37, vendor: Apple Inc.
>
>
> On 26 February 2013 22:03, Sebastien Blanc <scm.blanc(a)gmail.com> wrote:
>
>> And also openJDK or Oracle JDK ?
>> Just asking because I'm out of ideas :)
>> Seb
>>
>>
>> On Tue, Feb 26, 2013 at 9:53 PM, Sebastien Blanc
<scm.blanc(a)gmail.com>wrote:
>>
>>> 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>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>wrote:
>>>>
>>>>>
>>>>>
>>>>> On Tue, Feb 26, 2013 at 10:40 AM, Richard Kennard <
>>>>> richard(a)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(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<mailto:
>>>>>> richard(a)kennardconsulting.com>
<mailto:richard@kennardconsulting.com
>>>>>> > <mailto:richard@kennardconsulting.com>>>
>>>>>> > > > To: aerogear-dev(a)lists.jboss.org
<mailto:
>>>>>> aerogear-dev(a)lists.jboss.org>
<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>
<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>>>
>>>>>> > > > >>
>>>>>> 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>
<mailto:aerogear-dev@lists.jboss.org<mailto:
>>>>>> aerogear-dev(a)lists.jboss.org>>
>>>>>> > > > >
>>>>>> 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>
<mailto:aerogear-dev@lists.jboss.org<mailto:
>>>>>> aerogear-dev(a)lists.jboss.org>>
>>>>>> > > >
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>
<mailto:aerogear-dev@lists.jboss.org<mailto:
>>>>>> aerogear-dev(a)lists.jboss.org>>
>>>>>> > >
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>
>>>>>> > >
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>
>>>>>> > 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
>>>>
>>>
>>>
>>
>> _______________________________________________
>> 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
10:49 p.m.
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(a)kennardconsulting.com
<mailto:richard@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(a)kennardconsulting.com <mailto:richard@kennardconsulting.com>
<mailto:richard@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@redhat.com
<mailto:vpereira@redhat.com>> <mailto:vpereira@redhat.com
<mailto:vpereira@redhat.com>
> <mailto:vpereira@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 <mailto:richard@kennardconsulting.com>
<mailto:richard@kennardconsulting.com
<mailto:richard@kennardconsulting.com>>
<mailto:richard@kennardconsulting.com <mailto:richard@kennardconsulting.com>
> <mailto:richard@kennardconsulting.com
<mailto:richard@kennardconsulting.com>>>>
> > > To: aerogear-dev(a)lists.jboss.org
<mailto:aerogear-dev@lists.jboss.org> <mailto:aerogear-dev@lists.jboss.org
<mailto:aerogear-dev@lists.jboss.org>>
<mailto:aerogear-dev@lists.jboss.org <mailto:aerogear-dev@lists.jboss.org>
> <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@lists.jboss.org> <mailto:aerogear-dev@lists.jboss.org
<mailto:aerogear-dev@lists.jboss.org>>
<mailto:aerogear-dev@lists.jboss.org <mailto:aerogear-dev@lists.jboss.org>
> <mailto:aerogear-dev@lists.jboss.org
<mailto:aerogear-dev@lists.jboss.org>>>
<mailto:aerogear-dev@lists.jboss.org
<mailto:aerogear-dev@lists.jboss.org> <mailto:aerogear-dev@lists.jboss.org
<mailto:aerogear-dev@lists.jboss.org>>
> <mailto:aerogear-dev@lists.jboss.org
<mailto:aerogear-dev@lists.jboss.org> <mailto:aerogear-dev@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
<mailto:aerogear-dev@lists.jboss.org> <mailto:aerogear-dev@lists.jboss.org
<mailto:aerogear-dev@lists.jboss.org>>
<mailto:aerogear-dev@lists.jboss.org <mailto:aerogear-dev@lists.jboss.org>
<mailto:aerogear-dev@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
<mailto:aerogear-dev@lists.jboss.org> <mailto:aerogear-dev@lists.jboss.org
<mailto:aerogear-dev@lists.jboss.org>>
<mailto:aerogear-dev@lists.jboss.org <mailto:aerogear-dev@lists.jboss.org>
<mailto:aerogear-dev@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
<mailto:aerogear-dev@lists.jboss.org> <mailto:aerogear-dev@lists.jboss.org
<mailto:aerogear-dev@lists.jboss.org>>
<mailto:aerogear-dev@lists.jboss.org <mailto:aerogear-dev@lists.jboss.org>
<mailto:aerogear-dev@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
<mailto:aerogear-dev@lists.jboss.org> <mailto:aerogear-dev@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 <mailto:aerogear-dev@lists.jboss.org>
<mailto:aerogear-dev@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 <mailto:aerogear-dev@lists.jboss.org>
> 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
12:19 p.m.
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/sc...
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(a)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(a)kennardconsulting.com <mailto:richard@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(a)kennardconsulting.com <mailto:richard@kennardconsulting.com>
> <mailto:richard@kennardconsulting.com <mailto:
richard(a)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>> <mailto:vpereira@redhat.com
<mailto:
vpereira(a)redhat.com>
> > <mailto:vpereira@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<mailto:
richard(a)kennardconsulting.com> <mailto:richard@kennardconsulting.com
> <mailto:richard@kennardconsulting.com>> <mailto:
richard(a)kennardconsulting.com <mailto:richard@kennardconsulting.com>
> > <mailto:richard@kennardconsulting.com <mailto:
richard(a)kennardconsulting.com>>>>
> > > > To: aerogear-dev(a)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 <mailto:aerogear-dev@lists.jboss.org>
> > <mailto:aerogear-dev@lists.jboss.org <mailto:
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(a)lists.jboss.org> <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>>> <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> <mailto:aerogear-dev@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 <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 <mailto:aerogear-dev@lists.jboss.org>
> <mailto:aerogear-dev@lists.jboss.org <mailto:
aerogear-dev(a)lists.jboss.org>>>
> > > > >
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> <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>>>
> > > > 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> <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>>>
> > > 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> <mailto:aerogear-dev@lists.jboss.org<mailto:
aerogear-dev(a)lists.jboss.org>>
> > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >
> > _______________________________________________
> > aerogear-dev mailing list
> > aerogear-dev(a)lists.jboss.org <mailto:aerogear-dev@lists.jboss.org>
<mailto:aerogear-dev@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 <mailto:aerogear-dev@lists.jboss.org>
> > 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
1:42 a.m.
Seb,
Thanks for putting that together. It appears we agree more than we disagree! To recap:
1. We agree 'inspecting metadata' needs to be orthogonal to 'widget
building'. You are re-using Metawidget's Inspectors, which is great
2. We agree 'widget building' needs to be orthogonal to layout. Not just to avoid
duplicating code, but also so you can make it pluggable (i.e. your
'custom.tpl')
3. We agree that layout needs to be orthogonal to the wider page (i.e. we do everything
inside a 'div' or 'table' - neither of us are trying to render
everything from the 'html' tag down)
You decided FreeMarker was a good fit for #3, and I agree with you. I've implemented a
FreemarkerLayout for the next version of Metawidget. I've blogged
about it and put together an example you can download here:
http://blog.kennardconsulting.com/2013/02/metawidget-meets-freemarker.html
So our main area of disagreement remains: is FreeMarker a good fit for #2?
I think not. Not because of FreeMarker's templating language per se, but because
*FreeMarker returns strings*. This makes it hard to do meaningful
post-processing on the chosen widget before inserting it into the layout. There are many
examples of why post-processing is important. Let me give you one:
1. In the existing JSF scaffold, some fields are 'required' (i.e. not-null)
fields. We add the JSF 'required' attribute to these widgets. You do something
similar in your code:
<#if (property.required!"false") == "true">
required</#if>
However, we do this in a separate RequiredAttributeProcessor - not in the WidgetBuilder.
The reason is, although we use RequiredAttributeProcessor on the
editing screen, we swap it out for the search screen. The search screen still needs to
read the same metadata, and generate the same widgets, and lay out
in the same way, as the editing screen. But it does *not* want those widgets to be
'required', because search fields are optional.
Search screens are used in a different way to editing screens. So there is value in making
'required/not required' orthogonal to 'choice of widget'. We
don't want to duplicate the whole 'widget choosing' code just so we can relax
the 'required' attribute.
Regards,
Richard.
On 27/02/2013 10:19 PM, Sebastien Blanc wrote:
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/sc...
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(a)kennardconsulting.com
<mailto:richard@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(a)kennardconsulting.com <mailto:richard@kennardconsulting.com>
<mailto:richard@kennardconsulting.com
<mailto:richard@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(a)kennardconsulting.com <mailto:richard@kennardconsulting.com>
<mailto:richard@kennardconsulting.com
<mailto:richard@kennardconsulting.com>>
> <mailto:richard@kennardconsulting.com
<mailto:richard@kennardconsulting.com> <mailto:richard@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@redhat.com
<mailto:vpereira@redhat.com>> <mailto:vpereira@redhat.com
<mailto:vpereira@redhat.com>
> <mailto:vpereira@redhat.com <mailto:vpereira@redhat.com>>>
<mailto:vpereira@redhat.com <mailto:vpereira@redhat.com>
<mailto:vpereira@redhat.com
<mailto:vpereira@redhat.com>>
> > <mailto:vpereira@redhat.com <mailto:vpereira@redhat.com>
<mailto:vpereira@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 <mailto:richard@kennardconsulting.com>
<mailto:richard@kennardconsulting.com
<mailto:richard@kennardconsulting.com>> <mailto:richard@kennardconsulting.com
<mailto:richard@kennardconsulting.com>
> <mailto:richard@kennardconsulting.com
<mailto:richard@kennardconsulting.com>>>
<mailto:richard@kennardconsulting.com
<mailto:richard@kennardconsulting.com> <mailto:richard@kennardconsulting.com
<mailto:richard@kennardconsulting.com>>
> > <mailto:richard@kennardconsulting.com
<mailto:richard@kennardconsulting.com> <mailto:richard@kennardconsulting.com
<mailto:richard@kennardconsulting.com>>>>>
> > > > To: aerogear-dev(a)lists.jboss.org
<mailto:aerogear-dev@lists.jboss.org> <mailto:aerogear-dev@lists.jboss.org
<mailto:aerogear-dev@lists.jboss.org>>
<mailto:aerogear-dev@lists.jboss.org <mailto:aerogear-dev@lists.jboss.org>
> <mailto:aerogear-dev@lists.jboss.org
<mailto:aerogear-dev@lists.jboss.org>>>
<mailto:aerogear-dev@lists.jboss.org
<mailto:aerogear-dev@lists.jboss.org> <mailto:aerogear-dev@lists.jboss.org
<mailto:aerogear-dev@lists.jboss.org>>
> > <mailto:aerogear-dev@lists.jboss.org
<mailto:aerogear-dev@lists.jboss.org> <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@lists.jboss.org> <mailto:aerogear-dev@lists.jboss.org
<mailto:aerogear-dev@lists.jboss.org>>
<mailto:aerogear-dev@lists.jboss.org <mailto:aerogear-dev@lists.jboss.org>
> <mailto:aerogear-dev@lists.jboss.org
<mailto:aerogear-dev@lists.jboss.org>>>
<mailto:aerogear-dev@lists.jboss.org
<mailto:aerogear-dev@lists.jboss.org> <mailto:aerogear-dev@lists.jboss.org
<mailto:aerogear-dev@lists.jboss.org>>
> > <mailto:aerogear-dev@lists.jboss.org
<mailto:aerogear-dev@lists.jboss.org> <mailto:aerogear-dev@lists.jboss.org
<mailto:aerogear-dev@lists.jboss.org>>>>
<mailto:aerogear-dev@lists.jboss.org <mailto:aerogear-dev@lists.jboss.org>
> <mailto:aerogear-dev@lists.jboss.org
<mailto:aerogear-dev@lists.jboss.org>> <mailto:aerogear-dev@lists.jboss.org
<mailto:aerogear-dev@lists.jboss.org> <mailto:aerogear-dev@lists.jboss.org
<mailto:aerogear-dev@lists.jboss.org>>>
> > <mailto:aerogear-dev@lists.jboss.org
<mailto:aerogear-dev@lists.jboss.org> <mailto:aerogear-dev@lists.jboss.org
<mailto:aerogear-dev@lists.jboss.org>>
<mailto:aerogear-dev@lists.jboss.org <mailto:aerogear-dev@lists.jboss.org>
> <mailto:aerogear-dev@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
<mailto:aerogear-dev@lists.jboss.org> <mailto:aerogear-dev@lists.jboss.org
<mailto:aerogear-dev@lists.jboss.org>>
<mailto:aerogear-dev@lists.jboss.org <mailto:aerogear-dev@lists.jboss.org>
> <mailto:aerogear-dev@lists.jboss.org
<mailto:aerogear-dev@lists.jboss.org>>>
<mailto:aerogear-dev@lists.jboss.org
<mailto:aerogear-dev@lists.jboss.org> <mailto:aerogear-dev@lists.jboss.org
<mailto:aerogear-dev@lists.jboss.org>>
> <mailto:aerogear-dev@lists.jboss.org
<mailto:aerogear-dev@lists.jboss.org> <mailto:aerogear-dev@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
<mailto:aerogear-dev@lists.jboss.org> <mailto:aerogear-dev@lists.jboss.org
<mailto:aerogear-dev@lists.jboss.org>>
<mailto:aerogear-dev@lists.jboss.org <mailto:aerogear-dev@lists.jboss.org>
> <mailto:aerogear-dev@lists.jboss.org
<mailto:aerogear-dev@lists.jboss.org>>>
<mailto:aerogear-dev@lists.jboss.org
<mailto:aerogear-dev@lists.jboss.org> <mailto:aerogear-dev@lists.jboss.org
<mailto:aerogear-dev@lists.jboss.org>>
> <mailto:aerogear-dev@lists.jboss.org
<mailto:aerogear-dev@lists.jboss.org> <mailto:aerogear-dev@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
<mailto:aerogear-dev@lists.jboss.org> <mailto:aerogear-dev@lists.jboss.org
<mailto:aerogear-dev@lists.jboss.org>>
<mailto:aerogear-dev@lists.jboss.org <mailto:aerogear-dev@lists.jboss.org>
> <mailto:aerogear-dev@lists.jboss.org
<mailto:aerogear-dev@lists.jboss.org>>>
<mailto:aerogear-dev@lists.jboss.org
<mailto:aerogear-dev@lists.jboss.org> <mailto:aerogear-dev@lists.jboss.org
<mailto:aerogear-dev@lists.jboss.org>>
> <mailto:aerogear-dev@lists.jboss.org
<mailto:aerogear-dev@lists.jboss.org> <mailto:aerogear-dev@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
<mailto:aerogear-dev@lists.jboss.org> <mailto:aerogear-dev@lists.jboss.org
<mailto:aerogear-dev@lists.jboss.org>>
<mailto:aerogear-dev@lists.jboss.org <mailto:aerogear-dev@lists.jboss.org>
<mailto:aerogear-dev@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
<mailto:aerogear-dev@lists.jboss.org> <mailto:aerogear-dev@lists.jboss.org
<mailto:aerogear-dev@lists.jboss.org>>
<mailto:aerogear-dev@lists.jboss.org <mailto:aerogear-dev@lists.jboss.org>
<mailto:aerogear-dev@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
<mailto:aerogear-dev@lists.jboss.org> <mailto:aerogear-dev@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 <mailto:aerogear-dev@lists.jboss.org>
<mailto:aerogear-dev@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 <mailto:aerogear-dev@lists.jboss.org>
> 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
10:39 a.m.
Hi Richard,
Thanks for the detailed feedback. Your "attribute required" use case is
indeed interesting but I think this could be solved by following a
convention, I'm a big fan of Convention Over Configuration : I prefer
having a convention like "When processing search macro/template/partial
attributes are not required" rather than configure a bundle of XML files
and implement Java classes.
The two approaches are valid and even if we follow the coc way there must
always be a way to override the convention.
Seb
On Thu, Feb 28, 2013 at 1:42 AM, Richard Kennard <
richard(a)kennardconsulting.com> wrote:
Seb,
Thanks for putting that together. It appears we agree more than we
disagree! To recap:
1. We agree 'inspecting metadata' needs to be orthogonal to 'widget
building'. You are re-using Metawidget's Inspectors, which is great
2. We agree 'widget building' needs to be orthogonal to layout. Not just
to avoid duplicating code, but also so you can make it pluggable (i.e. your
'custom.tpl')
3. We agree that layout needs to be orthogonal to the wider page (i.e. we
do everything inside a 'div' or 'table' - neither of us are trying to
render
everything from the 'html' tag down)
You decided FreeMarker was a good fit for #3, and I agree with you. I've
implemented a FreemarkerLayout for the next version of Metawidget. I've
blogged
about it and put together an example you can download here:
http://blog.kennardconsulting.com/2013/02/metawidget-meets-freemarker.html
So our main area of disagreement remains: is FreeMarker a good fit for #2?
I think not. Not because of FreeMarker's templating language per se, but
because *FreeMarker returns strings*. This makes it hard to do meaningful
post-processing on the chosen widget before inserting it into the layout.
There are many examples of why post-processing is important. Let me give
you one:
1. In the existing JSF scaffold, some fields are 'required' (i.e.
not-null) fields. We add the JSF 'required' attribute to these widgets. You
do something
similar in your code:
<#if (property.required!"false") == "true">
required</#if>
However, we do this in a separate RequiredAttributeProcessor - not in the
WidgetBuilder. The reason is, although we use RequiredAttributeProcessor on
the
editing screen, we swap it out for the search screen. The search screen
still needs to read the same metadata, and generate the same widgets, and
lay out
in the same way, as the editing screen. But it does *not* want those
widgets to be 'required', because search fields are optional.
Search screens are used in a different way to editing screens. So there is
value in making 'required/not required' orthogonal to 'choice of widget'.
We
don't want to duplicate the whole 'widget choosing' code just so we can
relax the 'required' attribute.
Regards,
Richard.
On 27/02/2013 10:19 PM, Sebastien Blanc wrote:
> 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/sc...
>
> 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(a)kennardconsulting.com <mailto:richard@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(a)kennardconsulting.com <mailto:richard@kennardconsulting.com>
> <mailto:richard@kennardconsulting.com <mailto:
richard(a)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(a)kennardconsulting.com <mailto:richard@kennardconsulting.com>
> <mailto:richard@kennardconsulting.com <mailto:
richard(a)kennardconsulting.com>>
> > <mailto:richard@kennardconsulting.com <mailto:
richard(a)kennardconsulting.com> <mailto:richard@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>> <mailto:vpereira@redhat.com
<mailto:
vpereira(a)redhat.com>
> > <mailto:vpereira@redhat.com
<mailto:vpereira@redhat.com>>>
<mailto:vpereira@redhat.com <mailto:vpereira@redhat.com> <mailto:
vpereira(a)redhat.com
> <mailto:vpereira@redhat.com>>
> > > <mailto:vpereira@redhat.com
<mailto:vpereira@redhat.com>
<mailto:vpereira@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 <mailto:richard@kennardconsulting.com>
> <mailto:richard@kennardconsulting.com <mailto:
richard(a)kennardconsulting.com>> <mailto:richard@kennardconsulting.com
> <mailto:richard@kennardconsulting.com>
> > <mailto:richard@kennardconsulting.com <mailto:
richard(a)kennardconsulting.com>>> <mailto:richard@kennardconsulting.com
> <mailto:richard@kennardconsulting.com> <mailto:
richard(a)kennardconsulting.com <mailto:richard@kennardconsulting.com>>
> > > <mailto:richard@kennardconsulting.com <mailto:
richard(a)kennardconsulting.com> <mailto:richard@kennardconsulting.com
> <mailto:richard@kennardconsulting.com>>>>>
> > > > > To: aerogear-dev(a)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 <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 <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>>>>
> > > > > 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> <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>>> <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> <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>> <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> <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>>>>>
> > > > > >>
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> <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>>> <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> <mailto:aerogear-dev@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 <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 <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 <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>>>>
> > > > >
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> <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>>> <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> <mailto:aerogear-dev@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 <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 <mailto:aerogear-dev@lists.jboss.org>
> <mailto:aerogear-dev@lists.jboss.org <mailto:
aerogear-dev(a)lists.jboss.org>>>
> > > > 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> <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>>>
> > > 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> <mailto:aerogear-dev@lists.jboss.org<mailto:
aerogear-dev(a)lists.jboss.org>>
> > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >
> > _______________________________________________
> > aerogear-dev mailing list
> > aerogear-dev(a)lists.jboss.org <mailto:aerogear-dev@lists.jboss.org>
<mailto:aerogear-dev@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 <mailto:aerogear-dev@lists.jboss.org>
> > 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
11:10 a.m.
Seb,
To translate what I'm talking about into your language, I note these two files contain
a lot of duplication:
https://github.com/forge/scaffold-html5/blob/master/src/main/resources/sc...
https://github.com/forge/scaffold-html5/blob/master/src/main/resources/sc...
Presumably they will contain *more* duplication once searchFormInput.html.ftl supports
numbers, dates etc.
One of the main differences between them is the 'required' attribute. Are you
planning to refactor these files further?
Regards,
Richard.
On 1/03/2013 8:39 PM, Sebastien Blanc wrote:
Hi Richard,
Thanks for the detailed feedback. Your "attribute required" use case is indeed
interesting but I think this could be solved by following a convention,
I'm a big fan of Convention Over Configuration : I prefer having a convention like
"When processing search macro/template/partial attributes are not
required" rather than configure a bundle of XML files and implement Java classes.
The two approaches are valid and even if we follow the coc way there must always be a way
to override the convention.
Seb
On Thu, Feb 28, 2013 at 1:42 AM, Richard Kennard <richard(a)kennardconsulting.com
<mailto:richard@kennardconsulting.com>> wrote:
Seb,
Thanks for putting that together. It appears we agree more than we disagree! To
recap:
1. We agree 'inspecting metadata' needs to be orthogonal to 'widget
building'. You are re-using Metawidget's Inspectors, which is great
2. We agree 'widget building' needs to be orthogonal to layout. Not just to
avoid duplicating code, but also so you can make it pluggable (i.e. your
'custom.tpl')
3. We agree that layout needs to be orthogonal to the wider page (i.e. we do
everything inside a 'div' or 'table' - neither of us are trying to render
everything from the 'html' tag down)
You decided FreeMarker was a good fit for #3, and I agree with you. I've
implemented a FreemarkerLayout for the next version of Metawidget. I've blogged
about it and put together an example you can download here:
http://blog.kennardconsulting.com/2013/02/metawidget-meets-freemarker.html
So our main area of disagreement remains: is FreeMarker a good fit for #2?
I think not. Not because of FreeMarker's templating language per se, but because
*FreeMarker returns strings*. This makes it hard to do meaningful
post-processing on the chosen widget before inserting it into the layout. There are
many examples of why post-processing is important. Let me give
you one:
1. In the existing JSF scaffold, some fields are 'required' (i.e. not-null)
fields. We add the JSF 'required' attribute to these widgets. You do
something
similar in your code:
<#if (property.required!"false") == "true">
required</#if>
However, we do this in a separate RequiredAttributeProcessor - not in the
WidgetBuilder. The reason is, although we use RequiredAttributeProcessor on the
editing screen, we swap it out for the search screen. The search screen still needs
to read the same metadata, and generate the same widgets, and lay out
in the same way, as the editing screen. But it does *not* want those widgets to be
'required', because search fields are optional.
Search screens are used in a different way to editing screens. So there is value in
making 'required/not required' orthogonal to 'choice of widget'. We
don't want to duplicate the whole 'widget choosing' code just so we can
relax the 'required' attribute.
Regards,
Richard.
On 27/02/2013 10:19 PM, Sebastien Blanc wrote:
> 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/sc...
>
> 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(a)kennardconsulting.com <mailto:richard@kennardconsulting.com>
<mailto:richard@kennardconsulting.com
<mailto:richard@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(a)kennardconsulting.com <mailto:richard@kennardconsulting.com>
<mailto:richard@kennardconsulting.com
<mailto:richard@kennardconsulting.com>>
> <mailto:richard@kennardconsulting.com
<mailto:richard@kennardconsulting.com> <mailto:richard@kennardconsulting.com
<mailto:richard@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(a)kennardconsulting.com <mailto:richard@kennardconsulting.com>
<mailto:richard@kennardconsulting.com
<mailto:richard@kennardconsulting.com>>
> <mailto:richard@kennardconsulting.com
<mailto:richard@kennardconsulting.com> <mailto:richard@kennardconsulting.com
<mailto:richard@kennardconsulting.com>>>
> > <mailto:richard@kennardconsulting.com
<mailto:richard@kennardconsulting.com> <mailto:richard@kennardconsulting.com
<mailto:richard@kennardconsulting.com>>
<mailto:richard@kennardconsulting.com <mailto:richard@kennardconsulting.com>
> <mailto:richard@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@redhat.com
<mailto:vpereira@redhat.com>> <mailto:vpereira@redhat.com
<mailto:vpereira@redhat.com>
> <mailto:vpereira@redhat.com <mailto:vpereira@redhat.com>>>
<mailto:vpereira@redhat.com <mailto:vpereira@redhat.com>
<mailto:vpereira@redhat.com
<mailto:vpereira@redhat.com>>
> > <mailto:vpereira@redhat.com <mailto:vpereira@redhat.com>
<mailto:vpereira@redhat.com <mailto:vpereira@redhat.com>>>>
<mailto:vpereira@redhat.com <mailto:vpereira@redhat.com>
<mailto:vpereira@redhat.com <mailto:vpereira@redhat.com>>
<mailto:vpereira@redhat.com
<mailto:vpereira@redhat.com>
> <mailto:vpereira@redhat.com <mailto:vpereira@redhat.com>>>
> > > <mailto:vpereira@redhat.com
<mailto:vpereira@redhat.com> <mailto:vpereira@redhat.com
<mailto:vpereira@redhat.com>>
<mailto:vpereira@redhat.com <mailto:vpereira@redhat.com>
<mailto:vpereira@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 <mailto:richard@kennardconsulting.com>
<mailto:richard@kennardconsulting.com
<mailto:richard@kennardconsulting.com>>
> <mailto:richard@kennardconsulting.com
<mailto:richard@kennardconsulting.com> <mailto:richard@kennardconsulting.com
<mailto:richard@kennardconsulting.com>>>
<mailto:richard@kennardconsulting.com <mailto:richard@kennardconsulting.com>
> <mailto:richard@kennardconsulting.com
<mailto:richard@kennardconsulting.com>>
> > <mailto:richard@kennardconsulting.com
<mailto:richard@kennardconsulting.com> <mailto:richard@kennardconsulting.com
<mailto:richard@kennardconsulting.com>>>>
<mailto:richard@kennardconsulting.com <mailto:richard@kennardconsulting.com>
> <mailto:richard@kennardconsulting.com
<mailto:richard@kennardconsulting.com>> <mailto:richard@kennardconsulting.com
<mailto:richard@kennardconsulting.com> <mailto:richard@kennardconsulting.com
<mailto:richard@kennardconsulting.com>>>
> > > <mailto:richard@kennardconsulting.com
<mailto:richard@kennardconsulting.com> <mailto:richard@kennardconsulting.com
<mailto:richard@kennardconsulting.com>>
<mailto:richard@kennardconsulting.com <mailto:richard@kennardconsulting.com>
> <mailto:richard@kennardconsulting.com
<mailto:richard@kennardconsulting.com>>>>>>
> > > > > To: aerogear-dev(a)lists.jboss.org
<mailto:aerogear-dev@lists.jboss.org> <mailto:aerogear-dev@lists.jboss.org
<mailto:aerogear-dev@lists.jboss.org>>
<mailto:aerogear-dev@lists.jboss.org <mailto:aerogear-dev@lists.jboss.org>
> <mailto:aerogear-dev@lists.jboss.org
<mailto:aerogear-dev@lists.jboss.org>>>
<mailto:aerogear-dev@lists.jboss.org
<mailto:aerogear-dev@lists.jboss.org> <mailto:aerogear-dev@lists.jboss.org
<mailto:aerogear-dev@lists.jboss.org>>
> > <mailto:aerogear-dev@lists.jboss.org
<mailto:aerogear-dev@lists.jboss.org> <mailto:aerogear-dev@lists.jboss.org
<mailto:aerogear-dev@lists.jboss.org>>>>
<mailto:aerogear-dev@lists.jboss.org <mailto:aerogear-dev@lists.jboss.org>
> <mailto:aerogear-dev@lists.jboss.org
<mailto:aerogear-dev@lists.jboss.org>> <mailto:aerogear-dev@lists.jboss.org
<mailto:aerogear-dev@lists.jboss.org> <mailto:aerogear-dev@lists.jboss.org
<mailto:aerogear-dev@lists.jboss.org>>>
> > > <mailto:aerogear-dev@lists.jboss.org
<mailto:aerogear-dev@lists.jboss.org> <mailto:aerogear-dev@lists.jboss.org
<mailto:aerogear-dev@lists.jboss.org>>
<mailto:aerogear-dev@lists.jboss.org <mailto:aerogear-dev@lists.jboss.org>
> <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@lists.jboss.org> <mailto:aerogear-dev@lists.jboss.org
<mailto:aerogear-dev@lists.jboss.org>>
<mailto:aerogear-dev@lists.jboss.org <mailto:aerogear-dev@lists.jboss.org>
> <mailto:aerogear-dev@lists.jboss.org
<mailto:aerogear-dev@lists.jboss.org>>>
<mailto:aerogear-dev@lists.jboss.org
<mailto:aerogear-dev@lists.jboss.org> <mailto:aerogear-dev@lists.jboss.org
<mailto:aerogear-dev@lists.jboss.org>>
> > <mailto:aerogear-dev@lists.jboss.org
<mailto:aerogear-dev@lists.jboss.org> <mailto:aerogear-dev@lists.jboss.org
<mailto:aerogear-dev@lists.jboss.org>>>>
<mailto:aerogear-dev@lists.jboss.org <mailto:aerogear-dev@lists.jboss.org>
> <mailto:aerogear-dev@lists.jboss.org
<mailto:aerogear-dev@lists.jboss.org>> <mailto:aerogear-dev@lists.jboss.org
<mailto:aerogear-dev@lists.jboss.org> <mailto:aerogear-dev@lists.jboss.org
<mailto:aerogear-dev@lists.jboss.org>>>
> > > <mailto:aerogear-dev@lists.jboss.org
<mailto:aerogear-dev@lists.jboss.org> <mailto:aerogear-dev@lists.jboss.org
<mailto:aerogear-dev@lists.jboss.org>>
<mailto:aerogear-dev@lists.jboss.org <mailto:aerogear-dev@lists.jboss.org>
> <mailto:aerogear-dev@lists.jboss.org
<mailto:aerogear-dev@lists.jboss.org>>>>>
<mailto:aerogear-dev@lists.jboss.org
<mailto:aerogear-dev@lists.jboss.org> <mailto:aerogear-dev@lists.jboss.org
<mailto:aerogear-dev@lists.jboss.org>>
> > <mailto:aerogear-dev@lists.jboss.org
<mailto:aerogear-dev@lists.jboss.org> <mailto:aerogear-dev@lists.jboss.org
<mailto:aerogear-dev@lists.jboss.org>>>
<mailto:aerogear-dev@lists.jboss.org <mailto:aerogear-dev@lists.jboss.org>
> <mailto:aerogear-dev@lists.jboss.org
<mailto:aerogear-dev@lists.jboss.org>> <mailto:aerogear-dev@lists.jboss.org
<mailto:aerogear-dev@lists.jboss.org> <mailto:aerogear-dev@lists.jboss.org
<mailto:aerogear-dev@lists.jboss.org>>>>
> > > <mailto:aerogear-dev@lists.jboss.org
<mailto:aerogear-dev@lists.jboss.org> <mailto:aerogear-dev@lists.jboss.org
<mailto:aerogear-dev@lists.jboss.org>>
<mailto:aerogear-dev@lists.jboss.org <mailto:aerogear-dev@lists.jboss.org>
> <mailto:aerogear-dev@lists.jboss.org
<mailto:aerogear-dev@lists.jboss.org>>>
<mailto:aerogear-dev@lists.jboss.org
<mailto:aerogear-dev@lists.jboss.org> <mailto:aerogear-dev@lists.jboss.org
<mailto:aerogear-dev@lists.jboss.org>>
> > <mailto:aerogear-dev@lists.jboss.org
<mailto:aerogear-dev@lists.jboss.org> <mailto:aerogear-dev@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
<mailto:aerogear-dev@lists.jboss.org> <mailto:aerogear-dev@lists.jboss.org
<mailto:aerogear-dev@lists.jboss.org>>
<mailto:aerogear-dev@lists.jboss.org <mailto:aerogear-dev@lists.jboss.org>
> <mailto:aerogear-dev@lists.jboss.org
<mailto:aerogear-dev@lists.jboss.org>>>
<mailto:aerogear-dev@lists.jboss.org
<mailto:aerogear-dev@lists.jboss.org> <mailto:aerogear-dev@lists.jboss.org
<mailto:aerogear-dev@lists.jboss.org>>
> > <mailto:aerogear-dev@lists.jboss.org
<mailto:aerogear-dev@lists.jboss.org> <mailto:aerogear-dev@lists.jboss.org
<mailto:aerogear-dev@lists.jboss.org>>>>
<mailto:aerogear-dev@lists.jboss.org <mailto:aerogear-dev@lists.jboss.org>
> <mailto:aerogear-dev@lists.jboss.org
<mailto:aerogear-dev@lists.jboss.org>> <mailto:aerogear-dev@lists.jboss.org
<mailto:aerogear-dev@lists.jboss.org> <mailto:aerogear-dev@lists.jboss.org
<mailto:aerogear-dev@lists.jboss.org>>>
> > <mailto:aerogear-dev@lists.jboss.org
<mailto:aerogear-dev@lists.jboss.org> <mailto:aerogear-dev@lists.jboss.org
<mailto:aerogear-dev@lists.jboss.org>>
<mailto:aerogear-dev@lists.jboss.org <mailto:aerogear-dev@lists.jboss.org>
> <mailto:aerogear-dev@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
<mailto:aerogear-dev@lists.jboss.org> <mailto:aerogear-dev@lists.jboss.org
<mailto:aerogear-dev@lists.jboss.org>>
<mailto:aerogear-dev@lists.jboss.org <mailto:aerogear-dev@lists.jboss.org>
> <mailto:aerogear-dev@lists.jboss.org
<mailto:aerogear-dev@lists.jboss.org>>>
<mailto:aerogear-dev@lists.jboss.org
<mailto:aerogear-dev@lists.jboss.org> <mailto:aerogear-dev@lists.jboss.org
<mailto:aerogear-dev@lists.jboss.org>>
> > <mailto:aerogear-dev@lists.jboss.org
<mailto:aerogear-dev@lists.jboss.org> <mailto:aerogear-dev@lists.jboss.org
<mailto:aerogear-dev@lists.jboss.org>>>>
<mailto:aerogear-dev@lists.jboss.org <mailto:aerogear-dev@lists.jboss.org>
> <mailto:aerogear-dev@lists.jboss.org
<mailto:aerogear-dev@lists.jboss.org>> <mailto:aerogear-dev@lists.jboss.org
<mailto:aerogear-dev@lists.jboss.org> <mailto:aerogear-dev@lists.jboss.org
<mailto:aerogear-dev@lists.jboss.org>>>
> > <mailto:aerogear-dev@lists.jboss.org
<mailto:aerogear-dev@lists.jboss.org> <mailto:aerogear-dev@lists.jboss.org
<mailto:aerogear-dev@lists.jboss.org>>
<mailto:aerogear-dev@lists.jboss.org <mailto:aerogear-dev@lists.jboss.org>
> <mailto:aerogear-dev@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
<mailto:aerogear-dev@lists.jboss.org> <mailto:aerogear-dev@lists.jboss.org
<mailto:aerogear-dev@lists.jboss.org>>
<mailto:aerogear-dev@lists.jboss.org <mailto:aerogear-dev@lists.jboss.org>
> <mailto:aerogear-dev@lists.jboss.org
<mailto:aerogear-dev@lists.jboss.org>>>
<mailto:aerogear-dev@lists.jboss.org
<mailto:aerogear-dev@lists.jboss.org> <mailto:aerogear-dev@lists.jboss.org
<mailto:aerogear-dev@lists.jboss.org>>
> > <mailto:aerogear-dev@lists.jboss.org
<mailto:aerogear-dev@lists.jboss.org> <mailto:aerogear-dev@lists.jboss.org
<mailto:aerogear-dev@lists.jboss.org>>>>
<mailto:aerogear-dev@lists.jboss.org <mailto:aerogear-dev@lists.jboss.org>
> <mailto:aerogear-dev@lists.jboss.org
<mailto:aerogear-dev@lists.jboss.org>> <mailto:aerogear-dev@lists.jboss.org
<mailto:aerogear-dev@lists.jboss.org> <mailto:aerogear-dev@lists.jboss.org
<mailto:aerogear-dev@lists.jboss.org>>>
> > <mailto:aerogear-dev@lists.jboss.org
<mailto:aerogear-dev@lists.jboss.org> <mailto:aerogear-dev@lists.jboss.org
<mailto:aerogear-dev@lists.jboss.org>>
<mailto:aerogear-dev@lists.jboss.org <mailto:aerogear-dev@lists.jboss.org>
> <mailto:aerogear-dev@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
<mailto:aerogear-dev@lists.jboss.org> <mailto:aerogear-dev@lists.jboss.org
<mailto:aerogear-dev@lists.jboss.org>>
<mailto:aerogear-dev@lists.jboss.org <mailto:aerogear-dev@lists.jboss.org>
> <mailto:aerogear-dev@lists.jboss.org
<mailto:aerogear-dev@lists.jboss.org>>>
<mailto:aerogear-dev@lists.jboss.org
<mailto:aerogear-dev@lists.jboss.org> <mailto:aerogear-dev@lists.jboss.org
<mailto:aerogear-dev@lists.jboss.org>>
> <mailto:aerogear-dev@lists.jboss.org
<mailto:aerogear-dev@lists.jboss.org> <mailto:aerogear-dev@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
<mailto:aerogear-dev@lists.jboss.org> <mailto:aerogear-dev@lists.jboss.org
<mailto:aerogear-dev@lists.jboss.org>>
<mailto:aerogear-dev@lists.jboss.org <mailto:aerogear-dev@lists.jboss.org>
> <mailto:aerogear-dev@lists.jboss.org
<mailto:aerogear-dev@lists.jboss.org>>>
<mailto:aerogear-dev@lists.jboss.org
<mailto:aerogear-dev@lists.jboss.org> <mailto:aerogear-dev@lists.jboss.org
<mailto:aerogear-dev@lists.jboss.org>>
> <mailto:aerogear-dev@lists.jboss.org
<mailto:aerogear-dev@lists.jboss.org> <mailto:aerogear-dev@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
<mailto:aerogear-dev@lists.jboss.org> <mailto:aerogear-dev@lists.jboss.org
<mailto:aerogear-dev@lists.jboss.org>>
<mailto:aerogear-dev@lists.jboss.org <mailto:aerogear-dev@lists.jboss.org>
<mailto:aerogear-dev@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
<mailto:aerogear-dev@lists.jboss.org> <mailto:aerogear-dev@lists.jboss.org
<mailto:aerogear-dev@lists.jboss.org>>
<mailto:aerogear-dev@lists.jboss.org <mailto:aerogear-dev@lists.jboss.org>
<mailto:aerogear-dev@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
<mailto:aerogear-dev@lists.jboss.org> <mailto:aerogear-dev@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 <mailto:aerogear-dev@lists.jboss.org>
<mailto:aerogear-dev@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 <mailto:aerogear-dev@lists.jboss.org>
> 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
12:47 p.m.
Hi Richard,
I'm sorry I couldn't respond much earlier on this topic. All of them are valid
points.
You're right in that the files contain duplicate expressions at this point. To use
the Freemarker terms, I've merely segregated various parts out, and
"included" them back into composites, through the #include directive. At a later
point, I'll also be creating Freemarker "macros" to further simplify the
templates. The reasons why I started off with #include vs #macro all boil down to
testability. Freemarker includes can be tested in isolation, provided that the required
data model can be provided to the templates. Macros, on the other hand require an
additional Freemarker template onto which they should be harnessed. I've kept macros
out of the equation for now, and would consider them once we've stabilized the use of
the AngularJS directives. The macros might eventually look similar to the ones in Spring
Web MVC:
https://github.com/SpringSource/spring-framework/blob/3.2.x/spring-webmvc...
but would not be the same since angular directives may have their own macros.
So, the answer to your question on whether the files would be refactored further, it
would be yes, until the point where they cannot be simplified further for ease of
maintenance and testing. I'd foresee that the Freemarker view templates authored by
anyone be composed of a few lines, using both includes and macros to keep them down to
around 10 lines per file. There's an orthogonal point about how different Forge
plugins/addons would use or reuse these templates, and how end users would provide their
own, and we might first address that before writing the macros.
On the topic of the search forms containing more duplication, there is a slight
possibility that this might happen. But for now, I do not think I'd add in support for
additional types. The underlying rationale is that the search functionality treats only
properties involved in relationships in a special manner. All other types, including
numerical and temporal types are treated as text. This might be a gross simplification,
but it makes for easier implementation. I would have preferred specialized widgets for
searching numerical and temporal types, to allow for better user experience here.
Searching by date ranges and numerical ranges is what I had in mind, and it might be an
overkill and complicate scaffolding since new widgets need to be written for these use
cases. Drop downs, i.e. Html Select widgets may not have been appropriate, and hence the
choice for simple textual searches.
Finally, about the 'required' attribute usage, I'd agree that it is vastly
complicated now. It's more down to the datamodel passed into the Freemarker templates.
Since this data model had been parsed from the XML inspection result into Strings, the
check is a bit complicated. This could be simplified further, either through a macro, or
through using a typed data model.
Hope this clarifies a few points about how the Freemarker usage would shape up. I
havent taken a look at the Freemarker metawidget, but I'll be considering it's use
here.
Regards,
Vineet
----- Original Message -----
From: "Richard Kennard"
<richard(a)kennardconsulting.com>
To: aerogear-dev(a)lists.jboss.org
Sent: Friday, March 1, 2013 3:40:10 PM
Subject: Re: [aerogear-dev] Aerogear Forge Plugin
Seb,
To translate what I'm talking about into your language, I note these
two files contain a lot of duplication:
https://github.com/forge/scaffold-html5/blob/master/src/main/resources/sc...
https://github.com/forge/scaffold-html5/blob/master/src/main/resources/sc...
Presumably they will contain *more* duplication once
searchFormInput.html.ftl supports numbers, dates etc.
One of the main differences between them is the 'required' attribute.
Are you planning to refactor these files further?
Regards,
Richard.
On 1/03/2013 8:39 PM, Sebastien Blanc wrote:
> Hi Richard,
> Thanks for the detailed feedback. Your "attribute required" use
> case is indeed interesting but I think this could be solved by
> following a convention,
> I'm a big fan of Convention Over Configuration : I prefer having a
> convention like "When processing search macro/template/partial
> attributes are not
> required" rather than configure a bundle of XML files and implement
> Java classes.
> The two approaches are valid and even if we follow the coc way
> there must always be a way to override the convention.
> Seb
>
>
> On Thu, Feb 28, 2013 at 1:42 AM, Richard Kennard
> <richard(a)kennardconsulting.com
> <mailto:richard@kennardconsulting.com>> wrote:
>
> Seb,
>
> Thanks for putting that together. It appears we agree more than
> we disagree! To recap:
>
> 1. We agree 'inspecting metadata' needs to be orthogonal to
> 'widget building'. You are re-using Metawidget's Inspectors,
> which is great
> 2. We agree 'widget building' needs to be orthogonal to layout.
> Not just to avoid duplicating code, but also so you can make
> it pluggable (i.e. your
> 'custom.tpl')
> 3. We agree that layout needs to be orthogonal to the wider
> page (i.e. we do everything inside a 'div' or 'table' -
> neither of us are trying to render
> everything from the 'html' tag down)
>
> You decided FreeMarker was a good fit for #3, and I agree with
> you. I've implemented a FreemarkerLayout for the next version
> of Metawidget. I've blogged
> about it and put together an example you can download here:
>
> http://blog.kennardconsulting.com/2013/02/metawidget-meets-freemarker.html
>
> So our main area of disagreement remains: is FreeMarker a good
> fit for #2?
>
> I think not. Not because of FreeMarker's templating language
> per se, but because *FreeMarker returns strings*. This makes
> it hard to do meaningful
> post-processing on the chosen widget before inserting it into
> the layout. There are many examples of why post-processing is
> important. Let me give
> you one:
>
> 1. In the existing JSF scaffold, some fields are 'required'
> (i.e. not-null) fields. We add the JSF 'required' attribute to
> these widgets. You do
> something
> similar in your code:
>
> <#if (property.required!"false") == "true">
required</#if>
>
> However, we do this in a separate RequiredAttributeProcessor -
> not in the WidgetBuilder. The reason is, although we use
> RequiredAttributeProcessor on the
> editing screen, we swap it out for the search screen. The
> search screen still needs to read the same metadata, and
> generate the same widgets, and lay out
> in the same way, as the editing screen. But it does *not* want
> those widgets to be 'required', because search fields are
> optional.
>
> Search screens are used in a different way to editing screens.
> So there is value in making 'required/not required' orthogonal
> to 'choice of widget'. We
> don't want to duplicate the whole 'widget choosing' code just
> so we can relax the 'required' attribute.
>
> Regards,
>
> Richard.
>
> On 27/02/2013 10:19 PM, Sebastien Blanc wrote:
> > 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/sc...
> >
> > 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(a)kennardconsulting.com
> > <mailto:richard@kennardconsulting.com>
> <mailto:richard@kennardconsulting.com
> <mailto:richard@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(a)kennardconsulting.com
> > > <mailto:richard@kennardconsulting.com>
> <mailto:richard@kennardconsulting.com
> <mailto:richard@kennardconsulting.com>>
> > <mailto:richard@kennardconsulting.com
> > <mailto:richard@kennardconsulting.com>
> > <mailto:richard@kennardconsulting.com
> <mailto:richard@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(a)kennardconsulting.com
> > > > <mailto:richard@kennardconsulting.com>
> <mailto:richard@kennardconsulting.com
> <mailto:richard@kennardconsulting.com>>
> > <mailto:richard@kennardconsulting.com
> > <mailto:richard@kennardconsulting.com>
> > <mailto:richard@kennardconsulting.com
> <mailto:richard@kennardconsulting.com>>>
> > > <mailto:richard@kennardconsulting.com
> > > <mailto:richard@kennardconsulting.com>
> > > <mailto:richard@kennardconsulting.com
> <mailto:richard@kennardconsulting.com>>
> <mailto:richard@kennardconsulting.com
> <mailto:richard@kennardconsulting.com>
> > <mailto:richard@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@redhat.com
> <mailto:vpereira@redhat.com>> <mailto:vpereira@redhat.com
> <mailto:vpereira@redhat.com>
> > <mailto:vpereira@redhat.com
> > <mailto:vpereira@redhat.com>>>
> > <mailto:vpereira@redhat.com <mailto:vpereira@redhat.com>
> > <mailto:vpereira@redhat.com
> <mailto:vpereira@redhat.com>>
> > > <mailto:vpereira@redhat.com
> > > <mailto:vpereira@redhat.com>
> > > <mailto:vpereira@redhat.com
> > > <mailto:vpereira@redhat.com>>>>
> <mailto:vpereira@redhat.com <mailto:vpereira@redhat.com>
> <mailto:vpereira@redhat.com <mailto:vpereira@redhat.com>>
> <mailto:vpereira@redhat.com
> <mailto:vpereira@redhat.com>
> > <mailto:vpereira@redhat.com
> > <mailto:vpereira@redhat.com>>>
> > > > <mailto:vpereira@redhat.com
> > > > <mailto:vpereira@redhat.com>
> > > > <mailto:vpereira@redhat.com
> > > > <mailto:vpereira@redhat.com>>
> <mailto:vpereira@redhat.com <mailto:vpereira@redhat.com>
> <mailto:vpereira@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
> > > > > >
<mailto:richard@kennardconsulting.com>
> <mailto:richard@kennardconsulting.com
> <mailto:richard@kennardconsulting.com>>
> > <mailto:richard@kennardconsulting.com
> > <mailto:richard@kennardconsulting.com>
> > <mailto:richard@kennardconsulting.com
> <mailto:richard@kennardconsulting.com>>>
> <mailto:richard@kennardconsulting.com
> <mailto:richard@kennardconsulting.com>
> > <mailto:richard@kennardconsulting.com
> > <mailto:richard@kennardconsulting.com>>
> > > <mailto:richard@kennardconsulting.com
> > > <mailto:richard@kennardconsulting.com>
> > > <mailto:richard@kennardconsulting.com
> <mailto:richard@kennardconsulting.com>>>>
> <mailto:richard@kennardconsulting.com
> <mailto:richard@kennardconsulting.com>
> > <mailto:richard@kennardconsulting.com
> > <mailto:richard@kennardconsulting.com>>
> > <mailto:richard@kennardconsulting.com
> <mailto:richard@kennardconsulting.com>
> <mailto:richard@kennardconsulting.com
> <mailto:richard@kennardconsulting.com>>>
> > > > <mailto:richard@kennardconsulting.com
> > > > <mailto:richard@kennardconsulting.com>
> > > > <mailto:richard@kennardconsulting.com
> <mailto:richard@kennardconsulting.com>>
> <mailto:richard@kennardconsulting.com
> <mailto:richard@kennardconsulting.com>
> > <mailto:richard@kennardconsulting.com
> > <mailto:richard@kennardconsulting.com>>>>>>
> > > > > > To: aerogear-dev(a)lists.jboss.org
> > > > > >
<mailto:aerogear-dev@lists.jboss.org>
> > > > > >
<mailto:aerogear-dev@lists.jboss.org
> <mailto:aerogear-dev@lists.jboss.org>>
> <mailto:aerogear-dev@lists.jboss.org
> <mailto:aerogear-dev@lists.jboss.org>
> > <mailto:aerogear-dev@lists.jboss.org
> > <mailto:aerogear-dev@lists.jboss.org>>>
> > <mailto:aerogear-dev@lists.jboss.org
> <mailto:aerogear-dev@lists.jboss.org>
> <mailto:aerogear-dev@lists.jboss.org
> <mailto:aerogear-dev@lists.jboss.org>>
> > > <mailto:aerogear-dev@lists.jboss.org
> > > <mailto:aerogear-dev@lists.jboss.org>
> > > <mailto:aerogear-dev@lists.jboss.org
> <mailto:aerogear-dev@lists.jboss.org>>>>
> <mailto:aerogear-dev@lists.jboss.org
> <mailto:aerogear-dev@lists.jboss.org>
> > <mailto:aerogear-dev@lists.jboss.org
> > <mailto:aerogear-dev@lists.jboss.org>>
> > <mailto:aerogear-dev@lists.jboss.org
> <mailto:aerogear-dev@lists.jboss.org>
> <mailto:aerogear-dev@lists.jboss.org
> <mailto:aerogear-dev@lists.jboss.org>>>
> > > > <mailto:aerogear-dev@lists.jboss.org
> > > > <mailto:aerogear-dev@lists.jboss.org>
> > > > <mailto:aerogear-dev@lists.jboss.org
> <mailto:aerogear-dev@lists.jboss.org>>
> <mailto:aerogear-dev@lists.jboss.org
> <mailto:aerogear-dev@lists.jboss.org>
> > <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@lists.jboss.org>
> > > > > > >>
<mailto:aerogear-dev@lists.jboss.org
> <mailto:aerogear-dev@lists.jboss.org>>
> <mailto:aerogear-dev@lists.jboss.org
> <mailto:aerogear-dev@lists.jboss.org>
> > <mailto:aerogear-dev@lists.jboss.org
> > <mailto:aerogear-dev@lists.jboss.org>>>
> > <mailto:aerogear-dev@lists.jboss.org
> <mailto:aerogear-dev@lists.jboss.org>
> <mailto:aerogear-dev@lists.jboss.org
> <mailto:aerogear-dev@lists.jboss.org>>
> > > <mailto:aerogear-dev@lists.jboss.org
> > > <mailto:aerogear-dev@lists.jboss.org>
> > > <mailto:aerogear-dev@lists.jboss.org
> <mailto:aerogear-dev@lists.jboss.org>>>>
> <mailto:aerogear-dev@lists.jboss.org
> <mailto:aerogear-dev@lists.jboss.org>
> > <mailto:aerogear-dev@lists.jboss.org
> > <mailto:aerogear-dev@lists.jboss.org>>
> > <mailto:aerogear-dev@lists.jboss.org
> <mailto:aerogear-dev@lists.jboss.org>
> <mailto:aerogear-dev@lists.jboss.org
> <mailto:aerogear-dev@lists.jboss.org>>>
> > > > <mailto:aerogear-dev@lists.jboss.org
> > > > <mailto:aerogear-dev@lists.jboss.org>
> > > > <mailto:aerogear-dev@lists.jboss.org
> <mailto:aerogear-dev@lists.jboss.org>>
> <mailto:aerogear-dev@lists.jboss.org
> <mailto:aerogear-dev@lists.jboss.org>
> > <mailto:aerogear-dev@lists.jboss.org
> > <mailto:aerogear-dev@lists.jboss.org>>>>>
> > <mailto:aerogear-dev@lists.jboss.org
> <mailto:aerogear-dev@lists.jboss.org>
> <mailto:aerogear-dev@lists.jboss.org
> <mailto:aerogear-dev@lists.jboss.org>>
> > > <mailto:aerogear-dev@lists.jboss.org
> > > <mailto:aerogear-dev@lists.jboss.org>
> > > <mailto:aerogear-dev@lists.jboss.org
> <mailto:aerogear-dev@lists.jboss.org>>>
> <mailto:aerogear-dev@lists.jboss.org
> <mailto:aerogear-dev@lists.jboss.org>
> > <mailto:aerogear-dev@lists.jboss.org
> > <mailto:aerogear-dev@lists.jboss.org>>
> > <mailto:aerogear-dev@lists.jboss.org
> <mailto:aerogear-dev@lists.jboss.org>
> <mailto:aerogear-dev@lists.jboss.org
> <mailto:aerogear-dev@lists.jboss.org>>>>
> > > > <mailto:aerogear-dev@lists.jboss.org
> > > > <mailto:aerogear-dev@lists.jboss.org>
> > > > <mailto:aerogear-dev@lists.jboss.org
> <mailto:aerogear-dev@lists.jboss.org>>
> <mailto:aerogear-dev@lists.jboss.org
> <mailto:aerogear-dev@lists.jboss.org>
> > <mailto:aerogear-dev@lists.jboss.org
> > <mailto:aerogear-dev@lists.jboss.org>>>
> > <mailto:aerogear-dev@lists.jboss.org
> <mailto:aerogear-dev@lists.jboss.org>
> <mailto:aerogear-dev@lists.jboss.org
> <mailto:aerogear-dev@lists.jboss.org>>
> > > <mailto:aerogear-dev@lists.jboss.org
> > > <mailto:aerogear-dev@lists.jboss.org>
> > > <mailto:aerogear-dev@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
> > > > > > >
<mailto:aerogear-dev@lists.jboss.org>
> > > > > > >
<mailto:aerogear-dev@lists.jboss.org
> <mailto:aerogear-dev@lists.jboss.org>>
> <mailto:aerogear-dev@lists.jboss.org
> <mailto:aerogear-dev@lists.jboss.org>
> > <mailto:aerogear-dev@lists.jboss.org
> > <mailto:aerogear-dev@lists.jboss.org>>>
> > <mailto:aerogear-dev@lists.jboss.org
> <mailto:aerogear-dev@lists.jboss.org>
> <mailto:aerogear-dev@lists.jboss.org
> <mailto:aerogear-dev@lists.jboss.org>>
> > > <mailto:aerogear-dev@lists.jboss.org
> > > <mailto:aerogear-dev@lists.jboss.org>
> > > <mailto:aerogear-dev@lists.jboss.org
> <mailto:aerogear-dev@lists.jboss.org>>>>
> <mailto:aerogear-dev@lists.jboss.org
> <mailto:aerogear-dev@lists.jboss.org>
> > <mailto:aerogear-dev@lists.jboss.org
> > <mailto:aerogear-dev@lists.jboss.org>>
> > <mailto:aerogear-dev@lists.jboss.org
> <mailto:aerogear-dev@lists.jboss.org>
> <mailto:aerogear-dev@lists.jboss.org
> <mailto:aerogear-dev@lists.jboss.org>>>
> > > <mailto:aerogear-dev@lists.jboss.org
> > > <mailto:aerogear-dev@lists.jboss.org>
> > > <mailto:aerogear-dev@lists.jboss.org
> <mailto:aerogear-dev@lists.jboss.org>>
> <mailto:aerogear-dev@lists.jboss.org
> <mailto:aerogear-dev@lists.jboss.org>
> > <mailto:aerogear-dev@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
> > > > > >
<mailto:aerogear-dev@lists.jboss.org>
> > > > > >
<mailto:aerogear-dev@lists.jboss.org
> <mailto:aerogear-dev@lists.jboss.org>>
> <mailto:aerogear-dev@lists.jboss.org
> <mailto:aerogear-dev@lists.jboss.org>
> > <mailto:aerogear-dev@lists.jboss.org
> > <mailto:aerogear-dev@lists.jboss.org>>>
> > <mailto:aerogear-dev@lists.jboss.org
> <mailto:aerogear-dev@lists.jboss.org>
> <mailto:aerogear-dev@lists.jboss.org
> <mailto:aerogear-dev@lists.jboss.org>>
> > > <mailto:aerogear-dev@lists.jboss.org
> > > <mailto:aerogear-dev@lists.jboss.org>
> > > <mailto:aerogear-dev@lists.jboss.org
> <mailto:aerogear-dev@lists.jboss.org>>>>
> <mailto:aerogear-dev@lists.jboss.org
> <mailto:aerogear-dev@lists.jboss.org>
> > <mailto:aerogear-dev@lists.jboss.org
> > <mailto:aerogear-dev@lists.jboss.org>>
> > <mailto:aerogear-dev@lists.jboss.org
> <mailto:aerogear-dev@lists.jboss.org>
> <mailto:aerogear-dev@lists.jboss.org
> <mailto:aerogear-dev@lists.jboss.org>>>
> > > <mailto:aerogear-dev@lists.jboss.org
> > > <mailto:aerogear-dev@lists.jboss.org>
> > > <mailto:aerogear-dev@lists.jboss.org
> <mailto:aerogear-dev@lists.jboss.org>>
> <mailto:aerogear-dev@lists.jboss.org
> <mailto:aerogear-dev@lists.jboss.org>
> > <mailto:aerogear-dev@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
> > > > > <mailto:aerogear-dev@lists.jboss.org>
> > > > > <mailto:aerogear-dev@lists.jboss.org
> <mailto:aerogear-dev@lists.jboss.org>>
> <mailto:aerogear-dev@lists.jboss.org
> <mailto:aerogear-dev@lists.jboss.org>
> > <mailto:aerogear-dev@lists.jboss.org
> > <mailto:aerogear-dev@lists.jboss.org>>>
> > <mailto:aerogear-dev@lists.jboss.org
> <mailto:aerogear-dev@lists.jboss.org>
> <mailto:aerogear-dev@lists.jboss.org
> <mailto:aerogear-dev@lists.jboss.org>>
> > > <mailto:aerogear-dev@lists.jboss.org
> > > <mailto:aerogear-dev@lists.jboss.org>
> > > <mailto:aerogear-dev@lists.jboss.org
> <mailto:aerogear-dev@lists.jboss.org>>>>
> <mailto:aerogear-dev@lists.jboss.org
> <mailto:aerogear-dev@lists.jboss.org>
> > <mailto:aerogear-dev@lists.jboss.org
> > <mailto:aerogear-dev@lists.jboss.org>>
> > <mailto:aerogear-dev@lists.jboss.org
> <mailto:aerogear-dev@lists.jboss.org>
> <mailto:aerogear-dev@lists.jboss.org
> <mailto:aerogear-dev@lists.jboss.org>>>
> > > <mailto:aerogear-dev@lists.jboss.org
> > > <mailto:aerogear-dev@lists.jboss.org>
> > > <mailto:aerogear-dev@lists.jboss.org
> <mailto:aerogear-dev@lists.jboss.org>>
> <mailto:aerogear-dev@lists.jboss.org
> <mailto:aerogear-dev@lists.jboss.org>
> > <mailto:aerogear-dev@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
> > > > > <mailto:aerogear-dev@lists.jboss.org>
> > > > > <mailto:aerogear-dev@lists.jboss.org
> <mailto:aerogear-dev@lists.jboss.org>>
> <mailto:aerogear-dev@lists.jboss.org
> <mailto:aerogear-dev@lists.jboss.org>
> > <mailto:aerogear-dev@lists.jboss.org
> > <mailto:aerogear-dev@lists.jboss.org>>>
> > <mailto:aerogear-dev@lists.jboss.org
> <mailto:aerogear-dev@lists.jboss.org>
> <mailto:aerogear-dev@lists.jboss.org
> <mailto:aerogear-dev@lists.jboss.org>>
> > <mailto:aerogear-dev@lists.jboss.org
> > <mailto:aerogear-dev@lists.jboss.org>
> > <mailto:aerogear-dev@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
> > > > <mailto:aerogear-dev@lists.jboss.org>
> > > > <mailto:aerogear-dev@lists.jboss.org
> <mailto:aerogear-dev@lists.jboss.org>>
> <mailto:aerogear-dev@lists.jboss.org
> <mailto:aerogear-dev@lists.jboss.org>
> > <mailto:aerogear-dev@lists.jboss.org
> > <mailto:aerogear-dev@lists.jboss.org>>>
> > <mailto:aerogear-dev@lists.jboss.org
> <mailto:aerogear-dev@lists.jboss.org>
> <mailto:aerogear-dev@lists.jboss.org
> <mailto:aerogear-dev@lists.jboss.org>>
> > <mailto:aerogear-dev@lists.jboss.org
> > <mailto:aerogear-dev@lists.jboss.org>
> > <mailto:aerogear-dev@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
> > > > <mailto:aerogear-dev@lists.jboss.org>
> > > > <mailto:aerogear-dev@lists.jboss.org
> <mailto:aerogear-dev@lists.jboss.org>>
> <mailto:aerogear-dev@lists.jboss.org
> <mailto:aerogear-dev@lists.jboss.org>
> <mailto:aerogear-dev@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
> > > <mailto:aerogear-dev@lists.jboss.org>
> > > <mailto:aerogear-dev@lists.jboss.org
> <mailto:aerogear-dev@lists.jboss.org>>
> <mailto:aerogear-dev@lists.jboss.org
> <mailto:aerogear-dev@lists.jboss.org>
> <mailto:aerogear-dev@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
> > > <mailto:aerogear-dev@lists.jboss.org>
> > > <mailto:aerogear-dev@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
> > <mailto:aerogear-dev@lists.jboss.org>
> > <mailto:aerogear-dev@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
> > <mailto:aerogear-dev@lists.jboss.org>
> > 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
4074
days inactive
4088
days old
28 comments
7 participants
participants (7)
-
Bruno Oliveira -
Burr Sutter -
Corinne Krych -
Jay Balunas -
Richard Kennard -
Sebastien Blanc -
Vineet Reynolds Pereira