struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan Wynn <bigwy...@gmail.com>
Subject Re: [shale] clay config loading from classpath
Date Fri, 06 Jan 2006 22:13:10 GMT
On 1/6/06, Gary VanMatre <gvanmatre@comcast.net> wrote:
> >From: Ryan Wynn <bigwynnr@gmail.com>
> >
> > I know that clay will load any config files as
> > META-INF/clay-config.xml from jars on the classpath. Is there any way
> > to tell clay to load config files of any name from jars on the
> > classpath?
> >
> > I want to break up my clay config file (included in a lib) because it
> > is getting pretty big. With spring configuration files I am able to
> > do this:
> >
> ><context-param>
> >  <param-name>contextConfigLocation</param-name>
> >  <param-value>
> >     classpath*:/META-INF/context1.xml,
> >     classpath*:/META-INF/context2.xml,
> >     classpath*:/META-INF/context3.xml
> >  </param-value>
> ></context-param>
>
> Clay looks at the file prefix and if it begins with "META-INF", the class loader is used;
otherwise, the servlet context is used.
>
> http://svn.apache.org/viewcvs.cgi/struts/shale/trunk/clay-plugin/src/java/org/apache/shale/clay/config/beans/ComponentConfigBean.java?view=markup
>
> getConfigDefinitions(String configFiles)
>
> >
> >
> > If clay already supports something like this then great. But if not
> > then can I suggest we support Spring's convention or some other known
> > convention if it exists.
>
> I like the notation "classpath:" because you would be able to load from any package.
 Please write this one up as a bugzilla ticket (http://issues.apache.org/bugzilla/enter_bug.cgi).
>


Thanks, that explanation helps.  Sometimes these little gems are quite
hard to find.  It took me a while of looking into the spring source to
find out how to load config files from the classpath.



> >
> > Thanks,
> > Ryan
>
> I'd love to hear how you are using Shale/Clay and your experiences sometime when you
have a chance :-).
>

My experience with clay thus far has been a great one.  I was
initially propotyping some stuff with it for use on a large project. 
My intent with using clay was to utilize the full html views and
develop 'mega-components'.  The full html views are helping us better
utilize a dedicated UI team.  Previously, the UI team mocked up some
html passed it over to development never saw the source again. 
Hopefully, now I can see UI folks checking html views out of the
repository and making contributions further into the development
cycle.  Mega-components refers to a library that I am creating.  It
couples clay configurations with java code to create reusable
components such as tables, trees, input w/validation, page fragments,
etc.  The clay mega-components build upon one another to create very
targeted application specific components that go a long way towards
abstraction and reuse.
For example, to create a tree structure like the one seen on the
myfaces website one only needs to include

<span jsfid="kaolin:tree" managed-bean-name="treeBean" />

that's it.

kaolin:tree has a convention that managed-bean-name will correspond to
a managed bean that extends a known abstract class.  This abstract
class provides nearly all of the plumbing that a tree needs to
function except for supplying the data.  treeBean is very simple, just
supplying the data to methods of its parent. Btw, this is making me
think it might be nice to allow for type checking somehow.  Right now
it is just a convention for us.

So the kaolin:tree component coupled with an abstract class has alot
of mojo associated.  I make alot of use of the symbols functionality. 
I am really happy that you added that.
Mime
View raw message