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 > https://lists.jboss.org/mailman/listinfo/forge-dev /max http://about.me/maxandersen _______________________________________________ forge-dev mailing list forge-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/forge-dev

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

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

Agree 100%. If Lincoln can set up the 'override folder' mechanism, I'll refactor the existing scaffolding resources to be much 'flatter'. Twill be sweet! Richard. On 4/01/2012 4:26 PM, Dan Allen wrote: > 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 <mailto:richard@kennardconsulting.com>> 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> > <mailto:richard@kennardconsulting.com <mailto: richard(a)kennardconsulting.com&gt;&gt;&gt; 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> <mailto:forge-dev@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> <mailto:forge-dev@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> <mailto:forge-dev@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 <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 > > > > > -- > 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 _______________________________________________ forge-dev mailing list forge-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/forge-dev

Yes, I think it should be a plain folder *but* Forge needs to add it to the classpath automatically. That way this will become a general-purpose mechanism that can override any code that does 'getResource'. Otherwise we'll have to rewrite all our plugins to first check this folder for every resource we load. Richard. On 4/01/2012 5:26 PM, Lincoln Baxter, III wrote: > Yeah, I like simple. > > I'm even suggesting we don't use the classpath for this. Just use a plain folder somewhere. > > Thoughts? > Lincoln > > On Wed, Jan 4, 2012 at 12:29 AM, Richard Kennard <richard(a)kennardconsulting.com <mailto:richard@kennardconsulting.com>> wrote: > > Agree 100%. If Lincoln can set up the 'override folder' mechanism, I'll refactor the existing scaffolding resources to be much 'flatter'. > > Twill be sweet! > > Richard. > > On 4/01/2012 4:26 PM, Dan Allen wrote: >> 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 <mailto:richard@kennardconsulting.com> > <mailto:richard@kennardconsulting.com <mailto:richard@kennardconsulting.com>>> 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> > <mailto:richard@kennardconsulting.com <mailto:richard@kennardconsulting.com>> >> <mailto:richard@kennardconsulting.com <mailto:richard@kennardconsulting.com> <mailto:richard@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> <mailto:forge-dev@lists.jboss.org <mailto:forge-dev@lists.jboss.org>> > <mailto:forge-dev@lists.jboss.org <mailto:forge-dev@lists.jboss.org> <mailto:forge-dev@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> <mailto:forge-dev@lists.jboss.org <mailto:forge-dev@lists.jboss.org>> > <mailto:forge-dev@lists.jboss.org <mailto:forge-dev@lists.jboss.org> <mailto:forge-dev@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> <mailto:forge-dev@lists.jboss.org <mailto:forge-dev@lists.jboss.org>> > <mailto:forge-dev@lists.jboss.org <mailto:forge-dev@lists.jboss.org> <mailto:forge-dev@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 <mailto:forge-dev@lists.jboss.org> <mailto:forge-dev@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> <mailto:forge-dev@lists.jboss.org <mailto:forge-dev@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 <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

On Tue, Jan 10, 2012 at 07:28, Max Rydahl Andersen < max.andersen(a)redhat.com&gt; wrote: > …but these things should *not* be loaded via a class path bound > getResource API imo. > I don't see a reason to link this to the classpath either. Though, it would be nice to support archives (you'd have to read from a JAR then). Through extension, it should be possible to load from a directory or the classpath. My point is, just don't hard link it to a classpath location. -Dan -- 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

No there isn't. On 11/01/2012 3:33 AM, Lincoln Baxter, III wrote: > I agree. I wouldn't want this to be tied to the classpath. Richard/Max, is there a JIRA for this? > > Thanks, > Lincoln > > On Tue, Jan 10, 2012 at 10:51 AM, Dan Allen <dan.j.allen(a)gmail.com&lt;mailto: dan.j.allen(a)gmail.com&gt;&gt; wrote: > > On Tue, Jan 10, 2012 at 07:28, Max Rydahl Andersen < max.andersen(a)redhat.com <mailto:max.andersen@redhat.com>> wrote: > > …but these things should *not* be loaded via a class path bound getResource API imo. > > > I don't see a reason to link this to the classpath either. Though, it would be nice to support archives (you'd have to read from a JAR then). > > Through extension, it should be possible to load from a directory or the classpath. My point is, just don't hard link it to a classpath location. > > -Dan > > -- > 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 <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

…but these things should *not* be loaded via a class path bound getResource API imo. i.e. instead of "getResource() { return getClassLoader().getResource() } I would have something like: getScaffoldingResource() { …do the magic to look in project local and then forge wide resources… if nothing found then return getResource(); // which will get the actual forge scaffolding built-in resources. } /max On Jan 4, 2012, at 07:30, Richard Kennard wrote: > Yes, I think it should be a plain folder *but* Forge needs to add it to the classpath automatically. > > That way this will become a general-purpose mechanism that can override any code that does 'getResource'. Otherwise we'll have to rewrite all our plugins > to first check this folder for every resource we load. > > Richard. > > On 4/01/2012 5:26 PM, Lincoln Baxter, III wrote: >> Yeah, I like simple. >> >> I'm even suggesting we don't use the classpath for this. Just use a plain folder somewhere. >> >> Thoughts? >> Lincoln >> >> On Wed, Jan 4, 2012 at 12:29 AM, Richard Kennard<richard@kennardconsulting.com<mailto:richard@kennardconsulting.com>> wrote: >> >> Agree 100%. If Lincoln can set up the 'override folder' mechanism, I'll refactor the existing scaffolding resources to be much 'flatter'. >> >> Twill be sweet! >> >> Richard. >> >> On 4/01/2012 4:26 PM, Dan Allen wrote: >>> 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@kennardconsulting.com<mailto:richard@kennardconsulting.com> >> <mailto:richard@kennardconsulting.com<mailto:richard@kennardconsulting.com>>> 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@kennardconsulting.com<mailto:richard@kennardconsulting.com> >> <mailto:richard@kennardconsulting.com<mailto:richard@kennardconsulting.com>> >>> <mailto:richard@kennardconsulting.com<mailto:richard@kennardconsulting.com> <mailto:richard@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@lists.jboss.org<mailto:forge-dev@lists.jboss.org> <mailto:forge-dev@lists.jboss.org<mailto:forge-dev@lists.jboss.org>> >> <mailto:forge-dev@lists.jboss.org<mailto:forge-dev@lists.jboss.org> <mailto:forge-dev@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@lists.jboss.org<mailto:forge-dev@lists.jboss.org> <mailto:forge-dev@lists.jboss.org<mailto:forge-dev@lists.jboss.org>> >> <mailto:forge-dev@lists.jboss.org<mailto:forge-dev@lists.jboss.org> <mailto:forge-dev@lists.jboss.org<mailto:forge-dev@lists.jboss.org>>> >>>>> https://lists.jboss.org/mailman/listinfo/forge-dev >>>>> >>>>> >>>> _______________________________________________ >>>> forge-dev mailing list >>>> forge-dev@lists.jboss.org<mailto:forge-dev@lists.jboss.org> <mailto:forge-dev@lists.jboss.org<mailto:forge-dev@lists.jboss.org>> >> <mailto:forge-dev@lists.jboss.org<mailto:forge-dev@lists.jboss.org> <mailto:forge-dev@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@lists.jboss.org<mailto:forge-dev@lists.jboss.org> <mailto:forge-dev@lists.jboss.org<mailto:forge-dev@lists.jboss.org>> >>>> https://lists.jboss.org/mailman/listinfo/forge-dev >>> _______________________________________________ >>> forge-dev mailing list >>> forge-dev@lists.jboss.org<mailto:forge-dev@lists.jboss.org> <mailto:forge-dev@lists.jboss.org<mailto:forge-dev@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@lists.jboss.org<mailto:forge-dev@lists.jboss.org> >>> https://lists.jboss.org/mailman/listinfo/forge-dev >> _______________________________________________ >> forge-dev mailing list >> forge-dev@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 /max http://about.me/maxandersen _______________________________________________ forge-dev mailing list forge-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/forge-dev

scaffolding/index.html. I prefer the latter IMO :)