Re: [forge-dev] Forge Scaffold x-Project { Aerogear, Arquillian, Errai, Java EE, RichFaces, Spring } - inputs and meetings

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