I like the idea of a drop-in file set.<div><br></div><div>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?</div>
<div><br></div><div>Having said all that, here's my suggestion:</div><div><br></div><div>src/main/resources/forge/scaffolding</div><div><br></div><div>or, to be less technology specific w/ regards to the scaffolding</div>
<div><br></div><div>src/main/resources/scaffolding</div><div><br></div><div>As Lincoln likes to say, keep it simple. Lincoln, is this inline with your motto?</div><div><br></div><div>-Dan<br><div><br><div class="gmail_quote">
On Tue, Jan 3, 2012 at 14:40, Richard Kennard <span dir="ltr"><<a href="mailto:richard@kennardconsulting.com">richard@kennardconsulting.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Lincoln,<br>
<br>
I don't think this should be an API. It needs to be something users can 'drop in' without needing to compile any code.<br>
<br>
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<br>
be the same. This'd help people who are digging around in the plugin code to determine what resource names they needed to override.<br>
<br>
'/resources' then gets added to Forge's classpath as the first thing on the list. So when I do...<br>
<br>
.getResource("org/jboss/forge/scaffold/faces/scaffold/create.xhtml"); or<br>
compiler.compile("org/jboss/forge/scaffold/faces/scaffold/create.xhtml")<br>
<br>
...I will always pick up the override first if there is one at /resources/org/jboss/forge/scaffold/faces/scaffold/create.xhtml.<br>
<br>
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<br>
somewhere else. They then can easily drop in a new bit of code, and configure Metawidget to use it.<br>
<br>
But Max may have a more experienced position :)<br>
<br>
Richard.<br>
<div class="im"><br>
On 4/01/2012 5:34 AM, Lincoln Baxter, III wrote:<br>
> 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<br>
> 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<br>
> 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?<br>
><br>
> Thoughts?<br>
> ~Lincoln<br>
><br>
</div><div><div class="h5">> On Tue, Dec 27, 2011 at 3:11 AM, Richard Kennard <<a href="mailto:richard@kennardconsulting.com">richard@kennardconsulting.com</a> <mailto:<a href="mailto:richard@kennardconsulting.com">richard@kennardconsulting.com</a>>> wrote:<br>
><br>
> 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<br>
> have a<br>
> similar requirement. Lincoln can you define something?<br>
><br>
> Regards,<br>
><br>
> Richard.<br>
><br>
> On 23/12/2011 11:26 PM, Max Rydahl Andersen wrote:<br>
> > In Hibernate Tools I had a notion of a template path (classpath is not appropriate for this IMO).<br>
> ><br>
> > <a href="http://docs.jboss.org/tools/3.3.0.M5/en/hibernatetools/html_single/index.html" target="_blank">http://docs.jboss.org/tools/3.3.0.M5/en/hibernatetools/html_single/index.html</a><br>
> ><br>
> > Templatepath was a list of directories and we used the the classpath as the last fallback, meaning it would pickup the tools provided ones.<br>
> ><br>
> > I also went the "extra step" and placed these templates in "packages" a.k.a. sub directory to allow the different<br>
> > template usages to be configured via just one template path.<br>
> ><br>
> > i.e. we had a view, pojo, hbm and a few others to separate them properly and to avoid name collisions.<br>
> ><br>
> > /max<br>
> ><br>
> > On Dec 23, 2011, at 06:20, Richard Kennard wrote:<br>
> ><br>
> >> Hi guys,<br>
> >><br>
> >> I've written up a bit of documentation for the scaffolding here: <a href="https://docs.jboss.org/author/display/FORGE/UI+Scaffolding" target="_blank">https://docs.jboss.org/author/display/FORGE/UI+Scaffolding</a><br>
> >><br>
> >> But I have a question around the customization. Clearly, we have some nice template files like 'create.xhtml' and 'BackingBean.jv' which can be<br>
> edited in<br>
> >> any text editor. And we have a nice separation of the CSS/image files that can be replaced to change the look and feel.<br>
> >><br>
> >> 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<br>
> these files?<br>
> >> 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?<br>
> >><br>
> >> Regards,<br>
> >><br>
> >> Richard.<br>
> >> _______________________________________________<br>
> >> forge-dev mailing list<br>
</div></div>> >> <a href="mailto:forge-dev@lists.jboss.org">forge-dev@lists.jboss.org</a> <mailto:<a href="mailto:forge-dev@lists.jboss.org">forge-dev@lists.jboss.org</a>><br>
<div class="im">> >> <a href="https://lists.jboss.org/mailman/listinfo/forge-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/forge-dev</a><br>
> > /max<br>
> > <a href="http://about.me/maxandersen" target="_blank">http://about.me/maxandersen</a><br>
> ><br>
> ><br>
> ><br>
> ><br>
> > _______________________________________________<br>
> > forge-dev mailing list<br>
</div>> > <a href="mailto:forge-dev@lists.jboss.org">forge-dev@lists.jboss.org</a> <mailto:<a href="mailto:forge-dev@lists.jboss.org">forge-dev@lists.jboss.org</a>><br>
<div class="im">> > <a href="https://lists.jboss.org/mailman/listinfo/forge-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/forge-dev</a><br>
> ><br>
> ><br>
><br>
> _______________________________________________<br>
> forge-dev mailing list<br>
</div>> <a href="mailto:forge-dev@lists.jboss.org">forge-dev@lists.jboss.org</a> <mailto:<a href="mailto:forge-dev@lists.jboss.org">forge-dev@lists.jboss.org</a>><br>
<div class="HOEnZb"><div class="h5">> <a href="https://lists.jboss.org/mailman/listinfo/forge-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/forge-dev</a><br>
><br>
><br>
><br>
><br>
> --<br>
> Lincoln Baxter, III<br>
> <a href="http://ocpsoft.com" target="_blank">http://ocpsoft.com</a><br>
> <a href="http://scrumshark.com" target="_blank">http://scrumshark.com</a><br>
> "Keep it Simple"<br>
><br>
><br>
> _______________________________________________<br>
> forge-dev mailing list<br>
> <a href="mailto:forge-dev@lists.jboss.org">forge-dev@lists.jboss.org</a><br>
> <a href="https://lists.jboss.org/mailman/listinfo/forge-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/forge-dev</a><br>
<br>
_______________________________________________<br>
forge-dev mailing list<br>
<a href="mailto:forge-dev@lists.jboss.org">forge-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/forge-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/forge-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div>Dan Allen</div>Principal Software Engineer, Red Hat | Author of Seam in Action<br>Registered Linux User #231597<br><br><div><a href="http://google.com/profiles/dan.j.allen" target="_blank">http://google.com/profiles/dan.j.allen</a><br>
<a href="http://mojavelinux.com" target="_blank">http://mojavelinux.com</a><br><a href="http://mojavelinux.com/seaminaction" target="_blank">http://mojavelinux.com/seaminaction</a><br></div><br>
</div></div>