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

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