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

[Lincoln Baxter, III]

And of course, Thomas, if you want to join in you are most welcome to!! You
always do really crazy awesome things.


On Thu, Mar 7, 2013 at 5:09 AM, Vineet Reynolds Pereira <vpereira at redhat.com
> 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 at aon.at>
> > To: "forge-dev List" <forge-dev at lists.jboss.org>
> > 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/16gi5xQbh1Yk9K0sHUTpWZUhxcDedYFBqzBtUagrN-ZI/edit?usp=sharing
> b. Event diagram:
> https://docs.google.com/drawings/d/1sCgEUHtqiItIsLH40SEW0KOZefuq9bzLzE6FggaMbaA/edit?usp=sharing
>
> 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/jboss/forge/scaffold/html5/IntrospectorClient.java#L66
>
> 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 at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/forge-dev
> > >
> >
> > _______________________________________________
> > forge-dev mailing list
> > forge-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/forge-dev
> >
>
> _______________________________________________
> forge-dev mailing list
> forge-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/forge-dev
>



-- 
Lincoln Baxter, III
http://ocpsoft.org
"Simpler is better."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/forge-dev/attachments/20130307/36a284d8/attachment-0001.html