Hello,
I have some code that I believe might be helpful in showcasing the
strengths of shale and clay. You can grab the code from
http://issues.apache.org/bugzilla/show_bug.cgi?id=38482.
It demonstrates usage of shale remoting for static resources and
contains examples of some clay component
On 1/6/06, Gary VanMatre [EMAIL PROTECTED] wrote:
From: Ryan Wynn [EMAIL PROTECTED]
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
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
I have had success using most of the tomahawk components including
tree2. The only tricky part is that some times the attribute names on
the UIComponents are not the same as the attribute names on the jsp
tag. In which case the tomahawk jsp tags are doing the conversion.
Here's what I have for
I was doing some work on enabling declarative component level render
permissions alongside shale-clay. What I came up with was to use the
postProcessCreateComponent pluggable command in clay's chain. In this
command I check the current component for an attribute called
'renderIfRoleIn'. This
On 11/25/05, Craig McClanahan [EMAIL PROTECTED] wrote:
On 11/25/05, Ryan Wynn [EMAIL PROTECTED] wrote:
I was doing some work on enabling declarative component level render
permissions alongside shale-clay. What I came up with was to use the
postProcessCreateComponent pluggable command
Cool, thanks Gary.
so the following
catalog name=clayCustomization
chain name=preprocessAddComponent
command className=org.apache.shale.usecases.rolodex.CustomCommand/
/chain
/catalog
would execute CustomCommand before the creation of a component,
validator, etc? I
Yes, I would need matching postprocess commands to accomplish my task.
My custom command basically checks if the ClayContext's parent
component id is 'clayView' and if it is then it goes and adds the
appropriate javascript to the top of the component child list.
I originally had thought that the
I am also hedging towards the older syntax because I have found it
very flexible and I am worried that the new syntax may be limiting.
For example, I am using the following component for labels
component jsfid=label extends=clayOut allowBody=false
attributes
set name=value value=lt;label
From my experience using clay I think it would be nice if the
ClayViewHandler accepted listeners that get invoked after the clay
component has been created but before rendering to the outputstream.
This is the case that I have. I have a render phase listener that
adds javascript, stylesheets,
-typeorg.apache.shale.clay.component.Clay/component-type
component-classfoo.bar.MyClayExtension/component-class
/component
If you can override component classes like renderer classes then I
might be in luck.
I can add what I was trying to do in encodeEnd.
On 11/16/05, Ryan Wynn [EMAIL PROTECTED] wrote:
From my experience using
was to copy the entire shale-clay-config.xml into mine and then add
the Filter command. This works but obviously is not the best
approach.
On 11/16/05, Ryan Wynn [EMAIL PROTECTED] wrote:
Actually, the more I look at this I think I can may be able to achieve
the same thing by extending the Clay
thing
to do. Does this disallow the morphing feature?
No it shouldn't effect morphing, overriding the behavior is the the right
thing to do.
Gary
-- Forwarded message --
From: Ryan Wynn [EMAIL PROTECTED]
To: Struts Developers List dev@struts.apache.org
Date: Fri, 4 Nov
I agree the validators should not have ids. Currently id is specified on the
commons validator definition in the clay-config.xml packaged with clay. I
think this probably should be removed, along with any ids in the
definitions.
On 11/7/05, Gary VanMatre [EMAIL PROTECTED] wrote:
Gary,
The latest version of clay uses a new dtd, but the file on the web has not
been updated yet at
http://struts.apache.org/dtds/shale-clay-config_1_0.dtd
Just a heads up, I can refer to it locally for now.
Right now the CommonsValidator class in shale looks explicity for a
validator-rules.xml in /WEB-INF/. It might be nice to add support for
picking up a validator-rules.xml from a jar files /META-INF directory, like
what is done with faces-config.xml. I think this approach may be flawed
because if I
not
been updated yet at
http://struts.apache.org/dtds/shale-clay-config_1_0.dtd
Just a heads up, I can refer to it locally for now.
I updated it late last night. It now includes the symbols stuff.
Gary
-- Forwarded message --
From: Ryan Wynn [EMAIL PROTECTED
I think the change to save id state in the attributes collection broke use
of commons validator.
It's throwing runtime exception in PropertyValueCommand:
try {
PropUtils.setProperty(child, attributeBean.getName(), expr);
} catch (Exception e) {
if (child instanceof UIComponentBase)
shale-dialog-config_1_0.dtd 20-Sep-2005 23:45 8.1K
struts-config_1_0.dtd 12-Dec-2004 12:21 18K
struts-config_1_1.dtd 12-Dec-2004 12:21 35K
struts-config_1_2.dtd 12-Dec-2004 12:21 34K
...
...
But, I'm pretty sure I'm crazy.
Gary
-- Forwarded message --
From: Ryan Wynn
What do you mean by letting 1 component morph into another with respect to
Validator, ValueChangeListener, and Converter?
I think overriding the behavior of those types is probably the right thing
to do. Does this disallow the morphing feature?
On 11/4/05, Gary VanMatre [EMAIL PROTECTED] wrote:
I was hoping to get the latest build of shale, to get the latest clay
changes, and I noticed that the latest nightly build is from 10/28. Is there
a reason why there is no 11/3 build?
Thanks,
Ryan
21 matches
Mail list logo
