Re: [forge-dev] How to customize generation?

I like the idea of a drop-in file set. I suggest reconsidering the heavily nested structure. One thing that people really love about RoR, Grails and so forth is that they don't overcomplicate things. A prime example is folders. In Java we are obsessed with this idea of prefixing everything with a domain name so that common names will ever have a remote chance of conflicting. But are their really going to be like a hundred tools named forge? or even two?

Having said all that, here's my suggestion: src/main/resources/forge/scaffolding or, to be less technology specific w/ regards to the scaffolding src/main/resources/scaffolding As Lincoln likes to say, keep it simple. Lincoln, is this inline with your motto? -Dan On Tue, Jan 3, 2012 at 14:40, Richard Kennard <richard(a)kennardconsulting.com&gt; wrote: Lincoln, I don't think this should be an API. It needs to be something users can 'drop in' without needing to compile any code. I'm fine with a single folder called '/resources'. I chose that name to mirror Maven /src/main/resources, since the subfolder structure from then on should be the same. This'd help people who are digging around in the plugin code to determine what resource names they needed to override. '/resources' then gets added to Forge's classpath as the first thing on the list. So when I do... .getResource("org/jboss/forge/scaffold/faces/scaffold/create.xhtml"); or compiler.compile("org/jboss/forge/scaffold/faces/scaffold/create.xhtml") ...I will always pick up the override first if there is one at /resources/org/jboss/forge/scaffold/faces/scaffold/create.xhtml. Seeing as how users may want to drop in a new metawidget.xml, we'd need some ability to add arbitrary JARs too. Either under /resources or /lib or somewhere else. They then can easily drop in a new bit of code, and configure Metawidget to use it. But Max may have a more experienced position :) Richard. On 4/01/2012 5:34 AM, Lincoln Baxter, III wrote: > This sounds like something that would be really good for users. I guess I just need to know what specifically you think this should look like, then we > can define an API or even just a config setting (using the new configuration API) might be enough. Is this just a single directory? Multiple? What does > the layout look like? Do we want a configured path for each image, stylesheet, and file, or will we look up children by a specific file-name? > > Thoughts? > ~Lincoln > > On Tue, Dec 27, 2011 at 3:11 AM, Richard Kennard <richard(a)kennardconsulting.com <mailto:richard@kennardconsulting.com>> wrote: > > I think this sounds like a great idea. It should probably be 'Forge-wide' rather than specific to the scaffolding, as I imagine other plugins might > have a > similar requirement. Lincoln can you define something? > > Regards, > > Richard. > > On 23/12/2011 11:26 PM, Max Rydahl Andersen wrote: > > In Hibernate Tools I had a notion of a template path (classpath is not appropriate for this IMO). > > > > http://docs.jboss.org/tools/3.3.0.M5/en/hibernatetools/html_single/index.... > > > > Templatepath was a list of directories and we used the the classpath as the last fallback, meaning it would pickup the tools provided ones. > > > > I also went the "extra step" and placed these templates in "packages" a.k.a. sub directory to allow the different > > template usages to be configured via just one template path. > > > > i.e. we had a view, pojo, hbm and a few others to separate them properly and to avoid name collisions. > > > > /max > > > > On Dec 23, 2011, at 06:20, Richard Kennard wrote: > > > >> Hi guys, > >> > >> I've written up a bit of documentation for the scaffolding here: https://docs.jboss.org/author/display/FORGE/UI+Scaffolding > >> > >> But I have a question around the customization. Clearly, we have some nice template files like 'create.xhtml' and 'BackingBean.jv' which can be > edited in > >> any text editor. And we have a nice separation of the CSS/image files that can be replaced to change the look and feel. > >> > >> But how are we expecting people to 'get at' these files? Are they supposed to extend the existing scaffold plugin? Or open up the JAR and edit > these files? > >> Or can they be placed 'on the classpath' somehow such that they will be found before the ones in the scaffolding JAR? Or some other way? > >> > >> Regards, > >> > >> Richard. > >> _______________________________________________ > >> forge-dev mailing list > >> forge-dev(a)lists.jboss.org <mailto:forge-dev@lists.jboss.org> > >> https://lists.jboss.org/mailman/listinfo/forge-dev > > /max > > http://about.me/maxandersen > > > > > > > > > > _______________________________________________ > > forge-dev mailing list > > forge-dev(a)lists.jboss.org <mailto:forge-dev@lists.jboss.org> > > https://lists.jboss.org/mailman/listinfo/forge-dev > > > > > > _______________________________________________ > forge-dev mailing list > forge-dev(a)lists.jboss.org <mailto:forge-dev@lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/forge-dev > > > > > -- > Lincoln Baxter, III > http://ocpsoft.com > http://scrumshark.com > "Keep it Simple" > > > _______________________________________________ > 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 -- Dan Allen Principal Software Engineer, Red Hat | Author of Seam in Action Registered Linux User #231597 http://google.com/profiles/dan.j.allen http://mojavelinux.com http://mojavelinux.com/seaminaction _______________________________________________ forge-dev mailing list forge-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/forge-dev