Hello all, This is more of a follow up on Lincoln's mail sent earlier on the cross-project scaffold team. Sebastian and I have been working on fleshing out the details of the new scaffold plugin to handle several requirements, as part of the single collaborative scaffold initiative. We're going to attempt making this work on Forge 1, and port the design over to Forge 2. While our work so far has covered fairly decent ground, it is mostly due to the commonalities in the scaffolds we work on - AngularJS and Aerogear. JSF/RichFaces, Errai are notable exceptions, and I'd like to propose a weekly/bi-weekly cross-scaffold team meeting to pour over the details of this new scaffold plugin, so that design decisions will attempt to accomodate all projects (instead of only HTML5 ones). 30 mins should be fine to start with, stretching to a maximum of an hour (if there are too many topics to discuss). I'd like to know what time would be suitable for this discussion. If we cannot find a suitable time for everyone to join in, or if you schedules are busy, we could have impromptu meetings. Thanks, Vineet _______________________________________________ forge-dev mailing list forge-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/forge-dev

Guys, If it helps, just to let you know I have now released version 3.2 of Metawidget. This version includes FreeMarker support (inspired by Vineet). I believe Metawidget is common to all the Faces, Spring and Errai plugins, as well as my original AeroGear prototype plugin. I know Vineet is unsure if Metawidget is the direction he wants to go, but if so I think it would be reasonable to push it 'down' into some kind of common scaffold base. That may help standardise things a little? Note that Metawidget *does* provide an easy way to configure/override generation, it's just that Forge 1 makes it hard to get at. I believe Lincoln is trying to fix that for Forge 2. It may also be worth bearing in mind: Lincoln, Jay and Burr have all, at different times, expressed a desire for a *runtime* scaffold. This is so the scaffold can adapt as the underlying project changes, rather than force a static regeneration (which overwrites user changes). Metawidget has a common architecture across static and runtime modes, whereas something like FreeMarker is going to lock you into static generation. Just some thoughts. I am, obviously, very biased :) Regards, Richard. On 7/03/2013 3:08 AM, Thomas Frühbeck wrote: > Can you please point out the locations of the respective scaffold > plugins you refer to, and give some introduction to the direction of > planned development. > I read from the meeting transcript: > - extendable templates to prevent scaffold duplication > - conventions must be established > - scaffold generate tests > > Knowing Faces, Aerogear plugins and my proposed Errai plugin quite well > I find it somewhat amusing to see them all be based on frameworks and > provide some extendability, yet each in a very distinct and not very > congruent way - perhaps my bad? > During building my Errai plugin I found it e.g. difficult to implement > thorough type safety and entity relationships when the calls of the > scaffold are either per single file/entity ("generateFromEntity") or for > all files/entities ("generateIndex"), both not so well suited for > handling of _relationships_. > > Furthermore the development models are interestingly far apart: > - Faces: unsafe JSP + converters/handlers/_named_ beans + server side > - Errai: compile time type safety, intensive integrity validation, > client side optimizations > > e.g. > - the Errai compilation would fail, if a "Form"Composite declared a > widget that is not found in its HTML template, thus enforcing the HTML > template be generated _together_ with its "Form"Composite > - by _re_building only _one_ entity (generateFromEntity) in Errai > the generated code would possibly fail miserably w/o rebuilding also its > related entities > > Honestly I found myself frequently in the miserable position to rebuild > the complete entity model because of interdependencies. Anyway, while > writing these lines I find interesting possibilities to decouple code > for more flexibility :-) > > I am very interesting in evolving my plugin, so I hope you can give some > idea about the planned templating etc. > If there are not yet clear directions I am ready to scetch out the main > issues I encountered for open discussions. > > Thomas > > > Am 06.03.2013 14:38, schrieb Vineet Reynolds Pereira: >> Hello all, >> This is more of a follow up on Lincoln's mail sent earlier on the cross-project scaffold team. >> >> Sebastian and I have been working on fleshing out the details of the new scaffold plugin to handle several requirements, as part of the single collaborative scaffold initiative. We're going to attempt making this work on Forge 1, and port the design over to Forge 2. While our work so far has covered fairly decent ground, it is mostly due to the commonalities in the scaffolds we work on - AngularJS and Aerogear. JSF/RichFaces, Errai are notable exceptions, and I'd like to propose a weekly/bi-weekly cross-scaffold team meeting to pour over the details of this new scaffold plugin, so that design decisions will attempt to accomodate all projects (instead of only HTML5 ones). 30 mins should be fine to start with, stretching to a maximum of an hour (if there are too many topics to discuss). >> >> I'd like to know what time would be suitable for this discussion. If we cannot find a suitable time for everyone to join in, or if you schedules are busy, we could have impromptu meetings. >> >> Thanks, >> Vineet >> _______________________________________________ >> forge-dev mailing list >> forge-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/forge-dev >> > _______________________________________________ > forge-dev mailing list > forge-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/forge-dev > > _______________________________________________ forge-dev mailing list forge-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/forge-dev

I'd love to see pluggable templating support! Maybe this already exists, but an extension point / SPI to hook in whatever kind of templating is desired. On Thu, Mar 7, 2013 at 10:15 AM, Thomas Frühbeck <fruehbeck(a)aon.at&gt; wrote: > Richard, > > I like Metawidget very much, and I am convinced that it is a framework > the common scaffold could be based on - now that it supports templates ;-) > In fact I found myself in similar situation as Vineet, not wanting to > write a descriptor etc. for every artifact I needed to create. > Personally I cannot yet imagine integrating Metawidget as integral part > of a generated scaffold, seeing how hard it is to create a static > _functional and stable_ UI based on JPA entities. > > I know how much I could take from your Aerogear plugin and I always > wanted to thank you for the guidance it provided. By aggregating the > existing inspectors, processors and what-nots we could build an > incredible powerful templating system. > > Regards, > Thomas > > > Am 07.03.2013 00:35, schrieb Richard Kennard: > > Guys, > > > > If it helps, just to let you know I have now released version 3.2 of > Metawidget. This version includes FreeMarker support (inspired by Vineet). > > > > I believe Metawidget is common to all the Faces, Spring and Errai > plugins, as well as my original AeroGear prototype plugin. I know Vineet is > unsure if > > Metawidget is the direction he wants to go, but if so I think it would > be reasonable to push it 'down' into some kind of common scaffold base. > That may > > help standardise things a little? Note that Metawidget *does* provide > an easy way to configure/override generation, it's just that Forge 1 makes > it hard to > > get at. I believe Lincoln is trying to fix that for Forge 2. > > > > It may also be worth bearing in mind: Lincoln, Jay and Burr have all, > at different times, expressed a desire for a *runtime* scaffold. This is so > the > > scaffold can adapt as the underlying project changes, rather than force > a static regeneration (which overwrites user changes). Metawidget has a > common > > architecture across static and runtime modes, whereas something like > FreeMarker is going to lock you into static generation. > > > > Just some thoughts. I am, obviously, very biased :) > > > > Regards, > > > > Richard. > > > > On 7/03/2013 3:08 AM, Thomas Frühbeck wrote: > >> Can you please point out the locations of the respective scaffold > >> plugins you refer to, and give some introduction to the direction of > >> planned development. > >> I read from the meeting transcript: > >> - extendable templates to prevent scaffold duplication > >> - conventions must be established > >> - scaffold generate tests > >> > >> Knowing Faces, Aerogear plugins and my proposed Errai plugin quite well > >> I find it somewhat amusing to see them all be based on frameworks and > >> provide some extendability, yet each in a very distinct and not very > >> congruent way - perhaps my bad? > >> During building my Errai plugin I found it e.g. difficult to implement > >> thorough type safety and entity relationships when the calls of the > >> scaffold are either per single file/entity ("generateFromEntity") or > for > >> all files/entities ("generateIndex"), both not so well suited for > >> handling of _relationships_. > >> > >> Furthermore the development models are interestingly far apart: > >> - Faces: unsafe JSP + converters/handlers/_named_ beans + > server side > >> - Errai: compile time type safety, intensive integrity > validation, > >> client side optimizations > >> > >> e.g. > >> - the Errai compilation would fail, if a "Form"Composite > declared a > >> widget that is not found in its HTML template, thus enforcing the HTML > >> template be generated _together_ with its "Form"Composite > >> - by _re_building only _one_ entity (generateFromEntity) in > Errai > >> the generated code would possibly fail miserably w/o rebuilding also > its > >> related entities > >> > >> Honestly I found myself frequently in the miserable position to rebuild > >> the complete entity model because of interdependencies. Anyway, while > >> writing these lines I find interesting possibilities to decouple code > >> for more flexibility :-) > >> > >> I am very interesting in evolving my plugin, so I hope you can give > some > >> idea about the planned templating etc. > >> If there are not yet clear directions I am ready to scetch out the main > >> issues I encountered for open discussions. > >> > >> Thomas > >> > >> > >> Am 06.03.2013 14:38, schrieb Vineet Reynolds Pereira: > >>> Hello all, > >>> This is more of a follow up on Lincoln's mail sent earlier on > the cross-project scaffold team. > >>> > >>> Sebastian and I have been working on fleshing out the details > of the new scaffold plugin to handle several requirements, as part of the > single collaborative scaffold initiative. We're going to attempt making > this work on Forge 1, and port the design over to Forge 2. While our work > so far has covered fairly decent ground, it is mostly due to the > commonalities in the scaffolds we work on - AngularJS and Aerogear. > JSF/RichFaces, Errai are notable exceptions, and I'd like to propose a > weekly/bi-weekly cross-scaffold team meeting to pour over the details of > this new scaffold plugin, so that design decisions will attempt to > accomodate all projects (instead of only HTML5 ones). 30 mins should be > fine to start with, stretching to a maximum of an hour (if there are too > many topics to discuss). > >>> > >>> I'd like to know what time would be suitable for this > discussion. If we cannot find a suitable time for everyone to join in, or > if you schedules are busy, we could have impromptu meetings. > >>> > >>> Thanks, > >>> Vineet > >>> _______________________________________________ > >>> forge-dev mailing list > >>> forge-dev(a)lists.jboss.org > >>> https://lists.jboss.org/mailman/listinfo/forge-dev > >>> > >> _______________________________________________ > >> forge-dev mailing list > >> forge-dev(a)lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/forge-dev > >> > >> > > _______________________________________________ > > forge-dev mailing list > > forge-dev(a)lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/forge-dev > > > > _______________________________________________ > forge-dev mailing list > forge-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/forge-dev > -- Lincoln Baxter, III http://ocpsoft.org "Simpler is better."

wrote:

Hi Thomas, Thanks for raising all of this in a single mail. I've more or less faced the same problems. My response is inline. Best regards, Vineet ----- Original Message ----- > From: "Thomas Frühbeck" <fruehbeck(a)aon.at&gt; > To: "forge-dev List" <forge-dev(a)lists.jboss.org&gt; > Sent: Wednesday, March 6, 2013 9:38:07 PM > Subject: Re: [forge-dev] Forge Scaffold x-Project { Aerogear, Arquillian, Errai, Java EE, RichFaces, Spring } - > inputs and meetings > > Can you please point out the locations of the respective scaffold > plugins you refer to, and give some introduction to the direction of > planned development. We have two scaffold plugins now whose learnings are being used to create this new plugin: 1) https://github.com/forge/scaffold-html5 This is the AngularJS plugin I've been working on 2) https://github.com/sebastienblanc/scaffold-html5/tree/scaffold-aerogear This is a prototype Aerogear+AmgularJS plugin (not to be confused with https://github.com/forge/scaffold-aerogear/). Sebastian worked on this, and it is based on an older version of the AngularJS plugin. The differences between the two, are mostly in - a) the templates used to create the scaffold, b) the static AG libraries and Angular services that are to be created in the generated scaffold. If you notice carefully, we've decoupled the inspection of entities (using Metawidget inspectors) and the generation of the scaffold (using Freemarker templates) based on the inspection results. This has been basis for the design of the new scaffold plugin. We've put down some notes and event diagram for now: a. Notes: https://docs.google.com/document/d/16gi5xQbh1Yk9K0sHUTpWZUhxcDedYFBqzBtUa... b. Event diagram: https://docs.google.com/drawings/d/1sCgEUHtqiItIsLH40SEW0KOZefuq9bzLzE6Fg... I dont have your GMail address at hand, so if you can provide it, Sebastian can give you access. These are very early days, so nothing is set in stone, and this is bound to change as we cater to more usecases. > I read from the meeting transcript: > - extendable templates to prevent scaffold duplication > - conventions must be established > - scaffold generate tests > > Knowing Faces, Aerogear plugins and my proposed Errai plugin quite > well > I find it somewhat amusing to see them all be based on frameworks and > provide some extendability, yet each in a very distinct and not very > congruent way - perhaps my bad? > During building my Errai plugin I found it e.g. difficult to > implement > thorough type safety and entity relationships when the calls of the > scaffold are either per single file/entity ("generateFromEntity") or > for > all files/entities ("generateIndex"), both not so well suited for > handling of _relationships_. I concur with you on this. I'm facing a similar problem involving relationships across classes, but perhaps on a much smaller scale. I need to access the classes on the other side of the relationship, to choose one among a set of properties, to be used for display in the views. For example, if I have a model having a Customer -> StoreOrder relation of type 1:M, then I need to know what property of StoreOrder should I display in the Customer views. If you're interested, you can see the relevant code in lines 66-83 in the IntrospectorClient class, of the AngularJS plugin: https://github.com/forge/scaffold-html5/blob/master/src/main/java/org/jbo... Right now, this need hasn't been considered in the new plugin, since this looked more like an edge case that didn't need "standardization" across scaffold providers. But we can move towards incorporating this into the design, since there are atleast two plugins now that would need something similar. Personally, I need access to the Metawidget inspection results (or something similar) of the related entity, but I don't want to incorporate this as is into the design. That's mostly because we'd like to see your usecases as well, and how they could be incorporated into the event model. > > Furthermore the development models are interestingly far apart: > - Faces: unsafe JSP + converters/handlers/_named_ beans + server > side > - Errai: compile time type safety, intensive integrity > validation, > client side optimizations > > e.g. > - the Errai compilation would fail, if a "Form"Composite > declared a > widget that is not found in its HTML template, thus enforcing the > HTML > template be generated _together_ with its "Form"Composite > - by _re_building only _one_ entity (generateFromEntity) in > Errai > the generated code would possibly fail miserably w/o rebuilding also > its > related entities > > Honestly I found myself frequently in the miserable position to > rebuild > the complete entity model because of interdependencies. Anyway, while > writing these lines I find interesting possibilities to decouple code > for more flexibility :-) > > I am very interesting in evolving my plugin, so I hope you can give > some > idea about the planned templating etc. Well, we're using Freemarker in both the plugins. But, we're leaving the choice of the template engine to the scaffold provider for now, so you could use the Forge parser API if you want to generate new Java classes without relying entirely on text-based templates, or for that matter rely on Seam-Render that you seem to be using, or even use multiple template engines if some of them are better suited than others for emitting certain types of artifacts. There are however some considerations to make though, since the inspection result may not be available in a form that the template engine expects, so an adapter may be necessary. For Freemarker, the inspection result (the input data model for templating) is provided as a Map to the template engine. I may not have understood the bit about "rebuilding the complete entity model", and my assumption here is that the generated scaffold needs to be rebuilt from scratch when changes are made to the JPA entities. This is something that we may not fix right away in the scaffold plugin design, but yes, it would be something to consider. Perhaps it would make sense to have an in-memory model of what needs rebuilding, and what parts of the generated scaffold are "dirty" and need to be regenerated. My answer here may be incomplete, since I've just briefly looked inside your plugin-errai project, so we could discuss this in depth. > If there are not yet clear directions I am ready to scetch out the > main > issues I encountered for open discussions. That would be great. We're also preparing a POC (as a Forge plugin) for the new scaffold plugin design and once we have it ready for discussion, we shall be sending out another mail. We could consider these issues of yours during the construction of the POC. > > Thomas > > > Am 06.03.2013 14:38, schrieb Vineet Reynolds Pereira: > > Hello all, > > This is more of a follow up on Lincoln's mail sent earlier on > > the cross-project scaffold team. > > > > Sebastian and I have been working on fleshing out the details > > of the new scaffold plugin to handle several requirements, as > > part of the single collaborative scaffold initiative. We're > > going to attempt making this work on Forge 1, and port the > > design over to Forge 2. While our work so far has covered > > fairly decent ground, it is mostly due to the commonalities > > in the scaffolds we work on - AngularJS and Aerogear. > > JSF/RichFaces, Errai are notable exceptions, and I'd like to > > propose a weekly/bi-weekly cross-scaffold team meeting to > > pour over the details of this new scaffold plugin, so that > > design decisions will attempt to accomodate all projects > > (instead of only HTML5 ones). 30 mins should be fine to start > > with, stretching to a maximum of an hour (if there are too > > many topics to discuss). > > > > I'd like to know what time would be suitable for this > > discussion. If we cannot find a suitable time for everyone to > > join in, or if you schedules are busy, we could have impromptu > > meetings. > > > > Thanks, > > Vineet > > _______________________________________________ > > forge-dev mailing list > > forge-dev(a)lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/forge-dev > > > > _______________________________________________ > forge-dev mailing list > forge-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/forge-dev > _______________________________________________ forge-dev mailing list forge-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/forge-dev

Hi Vineet, I thought about how to summarize the most important issues and hope to have found the most important ones: 1) very detailed knowledge of the properties, relationships of the entity model (EmbeddedID, owning side of OneToOne/ManyToMany, Version field, generic type, array properties (e.g. char[]), lob) see: https://github.com/shadogray/plugin-errai/blob/master/src/main/java/org/j... and: https://github.com/shadogray/plugin-errai/blob/master/src/main/java/org/j...

2) a concise and inuitive naming convention for variables of templates it is tedious and error prone to create and maintain a naming convention like: entity, entityRef, refType, entityType, inverseField, field etc. a common understanding of such variable names would foster readability and maintainability across plugins

3) a templating system allowing complex decisions based on the roles of properties/relationships and their related entites That's the hardest point, let me try to explain using an analogy: the UI artifact like a play (theater) When designing a UI generator for entities I assigned kind of roles to each property, like a director directing actors in a play. During the course of the play different groups of actors show up at different times in different dresses and say some lines of text. They interact with each other to give a complete picture. Some talk a lot when present, some say only one line. According the roles of the actors they change the groups they belong to. MetaWidget isolates properties, so I had to pass quite a lot of information as context to each builder. Finally I had to prerecord many of the different "scenes" to be able to finally put it all together and generate a complete flow of the "piece". Perhaps it makes sense to generate a kind of meta database describing the entities and relationships, which can then be passed to a template like FreeMarker. This way the analysis would be separatable from the rendering, a naming convention could be well established. And by storing the metadata between executions it could be possible to identify "dirty" properties which were changed and provide the user with precise information about necessary rebuilds. I am sure this has been "invented" hundreds of times already :-)

WDYT? Thomas

Am 07.03.2013 11:09, schrieb Vineet Reynolds Pereira: > Hi Thomas, > Thanks for raising all of this in a single mail. I've more or less faced the same problems. My response is inline. > > Best regards, > Vineet > > ----- Original Message ----- >> From: "Thomas Frühbeck" <fruehbeck(a)aon.at&gt; >> To: "forge-dev List" <forge-dev(a)lists.jboss.org&gt; >> Sent: Wednesday, March 6, 2013 9:38:07 PM >> Subject: Re: [forge-dev] Forge Scaffold x-Project { Aerogear, Arquillian, Errai, Java EE, RichFaces, Spring } - >> inputs and meetings >> >> Can you please point out the locations of the respective scaffold >> plugins you refer to, and give some introduction to the direction of >> planned development. > We have two scaffold plugins now whose learnings are being used to create this new plugin: > > 1) https://github.com/forge/scaffold-html5 > This is the AngularJS plugin I've been working on > 2) https://github.com/sebastienblanc/scaffold-html5/tree/scaffold-aerogear > This is a prototype Aerogear+AmgularJS plugin (not to be confused with https://github.com/forge/scaffold-aerogear/). > Sebastian worked on this, and it is based on an older version of the AngularJS plugin. > The differences between the two, are mostly in - > a) the templates used to create the scaffold, > b) the static AG libraries and Angular services that are to be created in the generated scaffold. > > If you notice carefully, we've decoupled the inspection of entities (using Metawidget inspectors) and the generation of the scaffold (using Freemarker templates) based on the inspection results. > This has been basis for the design of the new scaffold plugin. We've put down some notes and event diagram for now: > a. Notes: https://docs.google.com/document/d/16gi5xQbh1Yk9K0sHUTpWZUhxcDedYFBqzBtUa... > b. Event diagram: https://docs.google.com/drawings/d/1sCgEUHtqiItIsLH40SEW0KOZefuq9bzLzE6Fg... > > I dont have your GMail address at hand, so if you can provide it, Sebastian can give you access. > > These are very early days, so nothing is set in stone, and this is bound to change as we cater to more usecases. > >> I read from the meeting transcript: >> - extendable templates to prevent scaffold duplication >> - conventions must be established >> - scaffold generate tests >> >> Knowing Faces, Aerogear plugins and my proposed Errai plugin quite >> well >> I find it somewhat amusing to see them all be based on frameworks and >> provide some extendability, yet each in a very distinct and not very >> congruent way - perhaps my bad? >> During building my Errai plugin I found it e.g. difficult to >> implement >> thorough type safety and entity relationships when the calls of the >> scaffold are either per single file/entity ("generateFromEntity") or >> for >> all files/entities ("generateIndex"), both not so well suited for >> handling of _relationships_. > I concur with you on this. I'm facing a similar problem involving relationships across classes, but perhaps on a much smaller scale. > I need to access the classes on the other side of the relationship, to choose one among a set of properties, to be used for display in the views. > For example, if I have a model having a Customer -> StoreOrder relation of type 1:M, then I need to know what property of StoreOrder should I display in the Customer views. > If you're interested, you can see the relevant code in lines 66-83 in the IntrospectorClient class, of the AngularJS plugin: > https://github.com/forge/scaffold-html5/blob/master/src/main/java/org/jbo... > > Right now, this need hasn't been considered in the new plugin, since this looked more like an edge case that didn't need "standardization" across scaffold providers. > But we can move towards incorporating this into the design, since there are atleast two plugins now that would need something similar. > Personally, I need access to the Metawidget inspection results (or something similar) of the related entity, but I don't want to incorporate this as is into the design. > That's mostly because we'd like to see your usecases as well, and how they could be incorporated into the event model. > >> Furthermore the development models are interestingly far apart: >> - Faces: unsafe JSP + converters/handlers/_named_ beans + server >> side >> - Errai: compile time type safety, intensive integrity >> validation, >> client side optimizations >> >> e.g. >> - the Errai compilation would fail, if a "Form"Composite >> declared a >> widget that is not found in its HTML template, thus enforcing the >> HTML >> template be generated _together_ with its "Form"Composite >> - by _re_building only _one_ entity (generateFromEntity) in >> Errai >> the generated code would possibly fail miserably w/o rebuilding also >> its >> related entities >> >> Honestly I found myself frequently in the miserable position to >> rebuild >> the complete entity model because of interdependencies. Anyway, while >> writing these lines I find interesting possibilities to decouple code >> for more flexibility :-) >> >> I am very interesting in evolving my plugin, so I hope you can give >> some >> idea about the planned templating etc. > Well, we're using Freemarker in both the plugins. But, we're leaving the choice of the template engine to the scaffold provider for now, so you could use the Forge parser API if you want to generate new Java classes without relying entirely on text-based templates, or for that matter rely on Seam-Render that you seem to be using, or even use multiple template engines if some of them are better suited than others for emitting certain types of artifacts. There are however some considerations to make though, since the inspection result may not be available in a form that the template engine expects, so an adapter may be necessary. For Freemarker, the inspection result (the input data model for templating) is provided as a Map to the template engine. > > I may not have understood the bit about "rebuilding the complete entity model", and my assumption here is that the generated scaffold needs to be rebuilt from scratch when changes are made to the JPA entities. This is something that we may not fix right away in the scaffold plugin design, but yes, it would be something to consider. Perhaps it would make sense to have an in-memory model of what needs rebuilding, and what parts of the generated scaffold are "dirty" and need to be regenerated. > > My answer here may be incomplete, since I've just briefly looked inside your plugin-errai project, so we could discuss this in depth. > >> If there are not yet clear directions I am ready to scetch out the >> main >> issues I encountered for open discussions. > That would be great. We're also preparing a POC (as a Forge plugin) for the new scaffold plugin design and once we have it ready for discussion, we shall be sending out another mail. We could consider these issues of yours during the construction of the POC. > >> Thomas >> >> >> Am 06.03.2013 14:38, schrieb Vineet Reynolds Pereira: >>> Hello all, >>> This is more of a follow up on Lincoln's mail sent earlier on >>> the cross-project scaffold team. >>> >>> Sebastian and I have been working on fleshing out the details >>> of the new scaffold plugin to handle several requirements, as >>> part of the single collaborative scaffold initiative. We're >>> going to attempt making this work on Forge 1, and port the >>> design over to Forge 2. While our work so far has covered >>> fairly decent ground, it is mostly due to the commonalities >>> in the scaffolds we work on - AngularJS and Aerogear. >>> JSF/RichFaces, Errai are notable exceptions, and I'd like to >>> propose a weekly/bi-weekly cross-scaffold team meeting to >>> pour over the details of this new scaffold plugin, so that >>> design decisions will attempt to accomodate all projects >>> (instead of only HTML5 ones). 30 mins should be fine to start >>> with, stretching to a maximum of an hour (if there are too >>> many topics to discuss). >>> >>> I'd like to know what time would be suitable for this >>> discussion. If we cannot find a suitable time for everyone to >>> join in, or if you schedules are busy, we could have impromptu >>> meetings. >>> >>> Thanks, >>> Vineet >>> _______________________________________________ >>> forge-dev mailing list >>> forge-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/forge-dev >>> >> _______________________________________________ >> forge-dev mailing list >> forge-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/forge-dev >> > _______________________________________________ > forge-dev mailing list > forge-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/forge-dev _______________________________________________ forge-dev mailing list forge-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/forge-dev

We still haven't worked out whether the templates would be acted upon after the inspection for all the entities is complete, or after the inspection of a single one. But going by your analogy and also with the needs we have, the former makes sense.

Hi Thomas, Adding my response to Sebastian's inline. Regards, Vineet ----- Original Message ----- > From: "Sebastien Blanc" <sblanc(a)redhat.com&gt; > To: forge-dev(a)lists.jboss.org > Sent: Monday, March 11, 2013 1:29:29 PM > Subject: Re: [forge-dev] Forge Scaffold x-Project { Aerogear, Arquillian, Errai, Java EE, RichFaces, Spring } - > inputs and meetings > > Hi Thomas, > Thnaks for your feedback and see my answers inline. > On 03/11/2013 12:54 AM, Thomas Frühbeck wrote: >> Hi Vineet, >> >> I thought about how to summarize the most important issues and hope >> to >> have found the most important ones: >> >> 1) very detailed knowledge of the properties, relationships of the >> entity model >> (EmbeddedID, owning side of OneToOne/ManyToMany, Version >> field, >> generic type, array properties (e.g. char[]), lob) >> see: >> https://github.com/shadogray/plugin-errai/blob/master/src/main/java/org/j... >> and: >> https://github.com/shadogray/plugin-errai/blob/master/src/main/java/org/j... > Exactly, I know Vineet has done a lot of work around all the > different > combinations of relations, types etc ... He is setting up a complete > test suite that covers the different scenarios. I see we're more or less converging on what we need the Forge inspector(s) to do here, and the responsibilities of the classes that post-process the inspection result. Referring to the code you pointed out, I believe some of the logic (like the Id/EmbeddedId detection) could lie in the Metawidget inspectors themselves. This (id detection) probably needs to be fixed in the Metawidget JPA inspector, since I'm of the opinion that only auto-generated Ids should be hidden and not required, whereas "normal" Ids should not be hidden. This can be done only at inspection time; currently the JPA inspector can be configured to omit Ids and Versions thus treating them as hidden fields. I'm not sure why you've duplicated some of the logic in the JPA inspector, but I'm more interested in knowing why - is it to override the JPA inspector? I definitely agree about retrieving information the owning side of the relationships, among other information, like the presence of bi-directional and cyclic relationships. Perhaps most of the work we're doing here fits into FORGE-368 : https://issues.jboss.org/browse/FORGE-368. I'm working on a related problem involving entity relationships for the Forge REST plugin, and it might be a good idea to share notes on this. Perhaps it is not a good thing to inspect an entity at a time. >> 2) a concise and inuitive naming convention for variables of >> templates >> it is tedious and error prone to create and maintain a >> naming >> convention like: entity, entityRef, refType, entityType, >> inverseField, >> field etc. >> a common understanding of such variable names would >> foster >> readability and maintainability across plugins > +1 , I'm a fervent fan of Convention over Configuration and we should > definitely brainstorm all together to define these conventions. Agreed. To state the obvious, variable names require a consistent naming convention. Another place where conventions can help, is the data model supplied to the templates. I haven't worked extensively with Seam Render, but in FreeMarker, methods can be invoked on objects in the data model. So expressions like ${entity.type} (which delegates to entity.getType()) can help a long way in reducing the number of variables themselves. Of course, we may not be able to standardize on FreeMarker for all plugins, so having template-engine specific utilities to create out rich data models for templates to process would help. >> 3) a templating system allowing complex decisions based on the >> roles of >> properties/relationships and their related entites >> That's the hardest point, let me try to explain using an analogy: >> the UI >> artifact like a play (theater) >> When designing a UI generator for entities I assigned kind of roles >> to >> each property, like a director directing actors in a play. >> During the course of the play different groups of actors show up at >> different times in different dresses and say some lines of text. >> They >> interact with each other to give a complete picture. Some talk a >> lot >> when present, some say only one line. According the roles of the >> actors >> they change the groups they belong to. >> >> MetaWidget isolates properties, so I had to pass quite a lot of >> information as context to each builder. Finally I had to prerecord >> many >> of the different "scenes" to be able to finally put it all together >> and >> generate a complete flow of the "piece". >> >> Perhaps it makes sense to generate a kind of meta database >> describing >> the entities and relationships, which can then be passed to a >> template >> like FreeMarker. >> This way the analysis would be separatable from the rendering, a >> naming >> convention could be well established. It definitely makes sense. This is one of the reasons why we're trying to decouple the inspection from the scaffold generation. For now, this meta database could be just the collection of all the inspection results. We still haven't worked out whether the templates would be acted upon after the inspection for all the entities is complete, or after the inspection of a single one. But going by your analogy and also with the needs we have, the former makes sense. >> And by storing the metadata between executions it could be possible >> to >> identify "dirty" properties which were changed and provide the user >> with >> precise information about necessary rebuilds. >> I am sure this has been "invented" hundreds of times already :-) > Excellent ! I really like your play analogy :) > And I'm even happier because we are totally on the same track on this > point. We need indeed more than a model containing just the > attributes, > we need a "context" which belong to a particular template or > fragment. > We start designing this, please send me a gmail email if you have one > so > I can add you to the google docs we are working on. > But basically, the idea is to have a TemplateContext object that we > can > pass to the template engine, like (pseudo code) : > new TemplateContext(model, template, outputPath,PER_ENTITY) > Here the model we contain more than just the attributes, we have to > agree all together how to enrich this. > I also invite you to take a look at the small POC I wrote to show > how > we can use Freemarker to keep a generic "widget controller" and use > custom renderers (depending on the context) : > https://github.com/sebastienblanc/freemarkertests > > >> WDYT? >> >> Thomas >> > Regards, > Seb > >> Am 07.03.2013 11:09, schrieb Vineet Reynolds Pereira: >>> Hi Thomas, >>> Thanks for raising all of this in a single mail. I've more or >>> less faced the same problems. My response is inline. >>> >>> Best regards, >>> Vineet >>> >>> ----- Original Message ----- >>>> From: "Thomas Frühbeck" <fruehbeck(a)aon.at&gt; >>>> To: "forge-dev List" <forge-dev(a)lists.jboss.org&gt; >>>> Sent: Wednesday, March 6, 2013 9:38:07 PM >>>> Subject: Re: [forge-dev] Forge Scaffold x-Project { Aerogear, >>>> Arquillian, Errai, Java EE, RichFaces, Spring } - >>>> inputs and meetings >>>> >>>> Can you please point out the locations of the respective scaffold >>>> plugins you refer to, and give some introduction to the direction >>>> of >>>> planned development. >>> We have two scaffold plugins now whose learnings are being used to >>> create this new plugin: >>> >>> 1) https://github.com/forge/scaffold-html5 >>> This is the AngularJS plugin I've been working on >>> 2) >>> https://github.com/sebastienblanc/scaffold-html5/tree/scaffold-aerogear >>> This is a prototype Aerogear+AmgularJS plugin (not to be confused >>> with https://github.com/forge/scaffold-aerogear/). >>> Sebastian worked on this, and it is based on an older version of >>> the AngularJS plugin. >>> The differences between the two, are mostly in - >>> a) the templates used to create the scaffold, >>> b) the static AG libraries and Angular services that are to >>> be created in the generated scaffold. >>> >>> If you notice carefully, we've decoupled the inspection of >>> entities (using Metawidget inspectors) and the generation of the >>> scaffold (using Freemarker templates) based on the inspection >>> results. >>> This has been basis for the design of the new scaffold plugin. >>> We've put down some notes and event diagram for now: >>> a. Notes: >>> https://docs.google.com/document/d/16gi5xQbh1Yk9K0sHUTpWZUhxcDedYFBqzBtUa... >>> b. Event diagram: >>> https://docs.google.com/drawings/d/1sCgEUHtqiItIsLH40SEW0KOZefuq9bzLzE6Fg... >>> >>> I dont have your GMail address at hand, so if you can provide it, >>> Sebastian can give you access. >>> >>> These are very early days, so nothing is set in stone, and this is >>> bound to change as we cater to more usecases. >>> >>>> I read from the meeting transcript: >>>> - extendable templates to prevent scaffold duplication >>>> - conventions must be established >>>> - scaffold generate tests >>>> >>>> Knowing Faces, Aerogear plugins and my proposed Errai plugin >>>> quite >>>> well >>>> I find it somewhat amusing to see them all be based on frameworks >>>> and >>>> provide some extendability, yet each in a very distinct and not >>>> very >>>> congruent way - perhaps my bad? >>>> During building my Errai plugin I found it e.g. difficult to >>>> implement >>>> thorough type safety and entity relationships when the calls of >>>> the >>>> scaffold are either per single file/entity ("generateFromEntity") >>>> or >>>> for >>>> all files/entities ("generateIndex"), both not so well suited for >>>> handling of _relationships_. >>> I concur with you on this. I'm facing a similar problem involving >>> relationships across classes, but perhaps on a much smaller >>> scale. >>> I need to access the classes on the other side of the >>> relationship, to choose one among a set of properties, to be used >>> for display in the views. >>> For example, if I have a model having a Customer -> StoreOrder >>> relation of type 1:M, then I need to know what property of >>> StoreOrder should I display in the Customer views. >>> If you're interested, you can see the relevant code in lines 66-83 >>> in the IntrospectorClient class, of the AngularJS plugin: >>> https://github.com/forge/scaffold-html5/blob/master/src/main/java/org/jbo... >>> >>> Right now, this need hasn't been considered in the new plugin, >>> since this looked more like an edge case that didn't need >>> "standardization" across scaffold providers. >>> But we can move towards incorporating this into the design, since >>> there are atleast two plugins now that would need something >>> similar. >>> Personally, I need access to the Metawidget inspection results (or >>> something similar) of the related entity, but I don't want to >>> incorporate this as is into the design. >>> That's mostly because we'd like to see your usecases as well, and >>> how they could be incorporated into the event model. >>> >>>> Furthermore the development models are interestingly far apart: >>>> - Faces: unsafe JSP + converters/handlers/_named_ beans + >>>> server >>>> side >>>> - Errai: compile time type safety, intensive integrity >>>> validation, >>>> client side optimizations >>>> >>>> e.g. >>>> - the Errai compilation would fail, if a "Form"Composite >>>> declared a >>>> widget that is not found in its HTML template, thus enforcing the >>>> HTML >>>> template be generated _together_ with its "Form"Composite >>>> - by _re_building only _one_ entity (generateFromEntity) >>>> in >>>> Errai >>>> the generated code would possibly fail miserably w/o rebuilding >>>> also >>>> its >>>> related entities >>>> >>>> Honestly I found myself frequently in the miserable position to >>>> rebuild >>>> the complete entity model because of interdependencies. Anyway, >>>> while >>>> writing these lines I find interesting possibilities to decouple >>>> code >>>> for more flexibility :-) >>>> >>>> I am very interesting in evolving my plugin, so I hope you can >>>> give >>>> some >>>> idea about the planned templating etc. >>> Well, we're using Freemarker in both the plugins. But, we're >>> leaving the choice of the template engine to the scaffold >>> provider for now, so you could use the Forge parser API if you >>> want to generate new Java classes without relying entirely on >>> text-based templates, or for that matter rely on Seam-Render that >>> you seem to be using, or even use multiple template engines if >>> some of them are better suited than others for emitting certain >>> types of artifacts. There are however some considerations to make >>> though, since the inspection result may not be available in a >>> form that the template engine expects, so an adapter may be >>> necessary. For Freemarker, the inspection result (the input data >>> model for templating) is provided as a Map to the template >>> engine. >>> >>> I may not have understood the bit about "rebuilding the complete >>> entity model", and my assumption here is that the generated >>> scaffold needs to be rebuilt from scratch when changes are made >>> to the JPA entities. This is something that we may not fix right >>> away in the scaffold plugin design, but yes, it would be >>> something to consider. Perhaps it would make sense to have an >>> in-memory model of what needs rebuilding, and what parts of the >>> generated scaffold are "dirty" and need to be regenerated. >>> >>> My answer here may be incomplete, since I've just briefly looked >>> inside your plugin-errai project, so we could discuss this in >>> depth. >>> >>>> If there are not yet clear directions I am ready to scetch out >>>> the >>>> main >>>> issues I encountered for open discussions. >>> That would be great. We're also preparing a POC (as a Forge >>> plugin) for the new scaffold plugin design and once we have it >>> ready for discussion, we shall be sending out another mail. We >>> could consider these issues of yours during the construction of >>> the POC. >>> >>>> Thomas >>>> >>>> >>>> Am 06.03.2013 14:38, schrieb Vineet Reynolds Pereira: >>>>> Hello all, >>>>> This is more of a follow up on Lincoln's mail sent >>>>> earlier on >>>>> the cross-project scaffold team. >>>>> >>>>> Sebastian and I have been working on fleshing out the >>>>> details >>>>> of the new scaffold plugin to handle several >>>>> requirements, as >>>>> part of the single collaborative scaffold initiative. >>>>> We're >>>>> going to attempt making this work on Forge 1, and port >>>>> the >>>>> design over to Forge 2. While our work so far has covered >>>>> fairly decent ground, it is mostly due to the >>>>> commonalities >>>>> in the scaffolds we work on - AngularJS and Aerogear. >>>>> JSF/RichFaces, Errai are notable exceptions, and I'd like >>>>> to >>>>> propose a weekly/bi-weekly cross-scaffold team meeting to >>>>> pour over the details of this new scaffold plugin, so >>>>> that >>>>> design decisions will attempt to accomodate all projects >>>>> (instead of only HTML5 ones). 30 mins should be fine to >>>>> start >>>>> with, stretching to a maximum of an hour (if there are >>>>> too >>>>> many topics to discuss). >>>>> >>>>> I'd like to know what time would be suitable for this >>>>> discussion. If we cannot find a suitable time for everyone >>>>> to >>>>> join in, or if you schedules are busy, we could have >>>>> impromptu >>>>> meetings. >>>>> >>>>> Thanks, >>>>> Vineet >>>>> _______________________________________________ >>>>> forge-dev mailing list >>>>> forge-dev(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/forge-dev >>>>> >>>> _______________________________________________ >>>> forge-dev mailing list >>>> forge-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/forge-dev >>>> >>> _______________________________________________ >>> forge-dev mailing list >>> forge-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/forge-dev >> _______________________________________________ >> forge-dev mailing list >> forge-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/forge-dev > > _______________________________________________ > forge-dev mailing list > forge-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/forge-dev _______________________________________________ forge-dev mailing list forge-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/forge-dev

Hello all, This is more of a follow up on Lincoln's mail sent earlier on the cross-project scaffold team. Sebastian and I have been working on fleshing out the details of the new scaffold plugin to handle several requirements, as part of the single collaborative scaffold initiative. We're going to attempt making this work on Forge 1, and port the design over to Forge 2. While our work so far has covered fairly decent ground, it is mostly due to the commonalities in the scaffolds we work on - AngularJS and Aerogear. JSF/RichFaces, Errai are notable exceptions, and I'd like to propose a weekly/bi-weekly cross-scaffold team meeting to pour over the details of this new scaffold plugin, so that design decisions will attempt to accomodate all projects (instead of only HTML5 ones). 30 mins should be fine to start with, stretching to a maximum of an hour (if there are too many topics to discuss). I'd like to know what time would be suitable for this discussion. If we cannot find a suitable time for everyone to join in, or if you schedules are busy, we could have impromptu meetings.