…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(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