[forge-dev] How to customize generation?

Richard Kennard richard at kennardconsulting.com
Tue Jan 10 17:24:08 EST 2012 

I'm not sure I understand this objection. Is it because things can end up on the classpath in all sorts of ways and it can be unclear where a file is 
coming from?

My concern is it's not just scaffolding that will need this. As a compromise, can I have some kind of Forge-level thing for looking up a resource?

Regards,

Richard.

On 10/01/2012 11:28 PM, Max Rydahl Andersen wrote:
> …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 at kennardconsulting.com<mailto:richard at 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 at kennardconsulting.com<mailto:richard at kennardconsulting.com>
>>>     <mailto:richard at kennardconsulting.com<mailto:richard at 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 at kennardconsulting.com<mailto:richard at kennardconsulting.com>
>>>     <mailto:richard at kennardconsulting.com<mailto:richard at kennardconsulting.com>>
>>>> <mailto:richard at kennardconsulting.com<mailto:richard at kennardconsulting.com>  <mailto:richard at kennardconsulting.com
>>>     <mailto:richard at 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.html
>>>>>>
>>>>>> 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 at lists.jboss.org<mailto:forge-dev at lists.jboss.org>  <mailto:forge-dev at lists.jboss.org<mailto:forge-dev at lists.jboss.org>>
>>>     <mailto:forge-dev at lists.jboss.org<mailto:forge-dev at lists.jboss.org>  <mailto:forge-dev at lists.jboss.org<mailto:forge-dev at lists.jboss.org>>>
>>>>>>> https://lists.jboss.org/mailman/listinfo/forge-dev
>>>>>> /max
>>>>>> http://about.me/maxandersen
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> forge-dev mailing list
>>>>>> forge-dev at lists.jboss.org<mailto:forge-dev at lists.jboss.org>  <mailto:forge-dev at lists.jboss.org<mailto:forge-dev at lists.jboss.org>>
>>>     <mailto:forge-dev at lists.jboss.org<mailto:forge-dev at lists.jboss.org>  <mailto:forge-dev at lists.jboss.org<mailto:forge-dev at lists.jboss.org>>>
>>>>>> https://lists.jboss.org/mailman/listinfo/forge-dev
>>>>>>
>>>>>>
>>>>>     _______________________________________________
>>>>>     forge-dev mailing list
>>>>> forge-dev at lists.jboss.org<mailto:forge-dev at lists.jboss.org>  <mailto:forge-dev at lists.jboss.org<mailto:forge-dev at lists.jboss.org>>
>>>     <mailto:forge-dev at lists.jboss.org<mailto:forge-dev at lists.jboss.org>  <mailto:forge-dev at lists.jboss.org<mailto:forge-dev at 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 at lists.jboss.org<mailto:forge-dev at lists.jboss.org>  <mailto:forge-dev at lists.jboss.org<mailto:forge-dev at lists.jboss.org>>
>>>>> https://lists.jboss.org/mailman/listinfo/forge-dev
>>>>     _______________________________________________
>>>>     forge-dev mailing list
>>>> forge-dev at lists.jboss.org<mailto:forge-dev at lists.jboss.org>  <mailto:forge-dev at lists.jboss.org<mailto:forge-dev at 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 at lists.jboss.org<mailto:forge-dev at lists.jboss.org>
>>>> https://lists.jboss.org/mailman/listinfo/forge-dev
>>>     _______________________________________________
>>>     forge-dev mailing list
>>>     forge-dev at lists.jboss.org<mailto:forge-dev at 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 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
> /max
> http://about.me/maxandersen
>
>
>
>
> _______________________________________________
> forge-dev mailing list
> forge-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/forge-dev
>
>

More information about the forge-dev mailing list