[ANNOUNCEMENT] New Shale Committer: Paul Spencer
Please join me in welcoming Paul Spencer as the newest Shale committer. Paul has been very supportive of the Shale community over the past year. Paul is also a member of the MyFaces project. Welcome, Paul!
Re: Tiger breaking my build
From: Tyler Zale [EMAIL PROTECTED] Hi, I am having a problem with shale-tiger-1.0.5. Tiger is breaking my build because it is throwing a Digester error (no grammar found). This is happening because I tried to add RichFaces to my project and the faces-config.xml in the richfaces jars does not conform to Tiger's dtds. I came up with a kludgish solution which consists of a combination of altering the Tiger dtd and the faces-config.xml. But this solution bugs me. I also tried using a context param (as I found listed in a jira entry: http://issues.apache.org/struts/browse/SHALE-301): context-param param-nameorg.apache.shale.tiger.SCAN_PACKAGES/param-name param-valuecom.x.y.z,shale-tiger-1.0.5.jar/param-value /context-param but this had a net effect of zero. Is there an easy way to stop shale-tiger from trying to read all the jars in my lib and breaking? The SCAN_PACKAGES context param is only useful for specifying where to look for shale tiger annotations. The lifecycle listener always tries to load the faces configs in /META-INF/faces-configs.xml. I've not looked at RichFaces. What have they added to the faces config that breaks the digester?Or, it might be that rich faces uses a JSF 1.2 DTD? Tiger only supports 1.0 and 1.1. One thing that you might try is overriding the DTD's with one to support rich faces. The digest loads the DTD from the classpath. You might try creating the same packages in your project and overriding. /org/apache/shale/tiger/resources/web-facesconfig_1_1.dtd /org/apache/shale/tiger/resources/web-facesconfig_1_0.dtd Thanks, TZ Gary
Re: Can shale remoting use in web application without JSF?
-- Original message -- From: Eric Chow [EMAIL PROTECTED] Hello, Can Shalre-Remoting load static javascript from JAR without using JSF? If it can, can you show me a simple example? The shale remoting library is a value add for JSF and assumes JSF. That's true for all shale libraries. Best regards, Eric Gary
Re: Can shale remoting use in web application without JSF?
From: Wendy Smoak [EMAIL PROTECTED] On Wed, Jul 16, 2008 at 2:39 PM, Gary VanMatre [EMAIL PROTECTED] wrote: The shale remoting library is a value add for JSF and assumes JSF. That's true for all shale libraries. ... except bits of Shale Test, which can be used without JSF. True, but it's still built on and has dependencies with the JSF API's. We just provide mock implementations. -- Wendy
Re: Use of Classifiers for Shale 1.1.0 (was Re: Where is Shale1.1.0?)
-- Original message -- From: Paul Spencer [EMAIL PROTECTED] Gary VanMatre wrote: -- Original message -- From: Paul Spencer [EMAIL PROTECTED] Gary VanMatre wrote: -- Original message -- From: Paul Spencer [EMAIL PROTECTED] Greg, My understanding is Shale v1.0.x and v1.1.x works with JSF 1.x. Their may be components that are JSF version specific, but this is the exception. I agree but the shale test library for 1.1.x supports JSF 1.2 mock objects which means it has Java 1.5 JSF 1.2 dependencies. The rest of the libraries are still JSF 1.1 based. So SHALE-262 - Provide optional support for parsing faces-config.xml files in the classpath at startup time will need to be backported to 1.0.x to test a JSF 1.1 application, like Tomahawk? Are their other alternatives the backporting? Humm, it looks like the shale test pom has a 1.4 profile that excludes the JSF 1.2 objects. The 1.1 trunk has the same type of profile. Unless I'm mistaken, we would need two deployments for JSF 1.1 and 1.2. Is this what classifiers are for? I see their is are profiles for jdk 1.4, 1.5, and 1.6. 1.4 is for Servlet v 2.4 where as 1.5 and 1.6 are for Servlet v2.5. Based on this I see 2 distributions, one for JSF 1.1 (profile = shale-test-jdk14) and one for JSF 1.2 ( profile = shale-test-jdk15) Yeah, sounds like that's the ticket but it's the first I've heard of classifiers. Maybe one of our maven mavens could give some pointers on how to configure a dual deployment. Do you think we would need two maven projects? Any other apache projects doing this that we could borrow snippets? Paul Spencer Gary Paul Spencer
Re: Where is Shale1.1.0?
-- Original message -- From: Paul Spencer [EMAIL PROTECTED] Greg, My understanding is Shale v1.0.x and v1.1.x works with JSF 1.x. Their may be components that are JSF version specific, but this is the exception. I agree but the shale test library for 1.1.x supports JSF 1.2 mock objects which means it has Java 1.5 JSF 1.2 dependencies. The rest of the libraries are still JSF 1.1 based. Paul Spencer Greg Reddin wrote: On Fri, Jun 6, 2008 at 2:49 AM, Mario Buonopane [EMAIL PROTECTED] wrote: No, i don't remember that Shale 1.1.0 is meant to be used with JSF 1.2 but with 1.1. In fact i'm using with MyFaces 1.5 (JSF 1.1). What does mean GA codebase? I don't remember if JSF 1.2 is a requirement for Shale 1.1 or not. ISTR us deciding we would target JSF 1.2 but I don't think that introduces backwards incompatibility. GA means General Availability - basically a production release. Shale 1.0.4 is alpha quality because of dependencies on unreleased libraries. Greg
Re: AbstractJsfTestCase question
The shale mock value binding has limited EL support.
[] #parse -
http://svn.apache.org/viewvc/shale/framework/trunk/shale-test/src/main/java/org/apache/shale/test/mock/MockValueBinding.java?view=markup
-- Original message --
From: Venkataganesh Thoppae [EMAIL PROTECTED]
Actually I missed that part while typing a sample code.
But here is a clean test case runnable if you have shale-test-x.jar.
Appreciate if someone could try this on their box.
Two files are attached.
MyTestCase.java has test cases defined.
SomeBean is a simple POJO.
Thanks
On Tue, May 20, 2008 at 10:57 AM, Chris Keefer [EMAIL PROTECTED] wrote:
I think in JSF 1.1 you have to get the value from a ValueBinding. See
below.
@Test
public void test1 {
ValueBinding binding =
facesContext.getApplication().createValueBinding(#{someBean.prop[0]}};
String val = (String) binding.getValue(facesContext);
assertEquals(val, M);
}
Or you can try the VariableResolver like so:
@Test
public void test1 {
String val =
facesContext.getApplication().getVariableResolver().resolveVariable(facesContext
,
#{someBean.prop[0]});
assertEquals(val, M);
}
Hope this helps.
--Chris
On May 19, 2008, at 1:06 PM, Venkataganesh Thoppae wrote:
Yes, I know Shale doesn't read faces-config.
Here is a sample implementation.
public class MyTestCase extends AbstractJsfTestCase {
//A valid someBean object is created in the request scope in setUp()
@Test
public void test1 {
String val=
(String)facesContext.getApplication().createValueBinding(#{someBean.prop[0]}};
assertEquals(val, M);
}
}
The error I get is:
javax.faces.el.PropertyNotFoundException: prop0
at
org.apache.shale.test.mock.MockPropertyResolver.descriptor(MockPropertyResolver.
java:213)
at
org.apache.shale.test.mock.MockPropertyResolver.getValue(MockPropertyResolver.ja
va:69)
at
org.apache.shale.test.mock.MockValueBinding.getValue(MockValueBinding.java:126)
Regards
On Mon, May 19, 2008 at 12:08 PM, Kito D. Mann [EMAIL PROTECTED] wrote:
Hmm... What errors are you getting? Or is it just returning null? If it's
just returning null, remember that you must manually but the bean in the
proper scope - Shale doesn't read faces-config.
Sent from my iPhone
On May 19, 2008, at 11:07 AM, Venkataganesh Thoppae
[EMAIL PROTECTED]
wrote:
New user of Shale Test framework. I'm trying to write some test cases
for
JSF 1.1 implementation using AbstractJsfTestCase.
Experiencing few problems while trying to resolve some EL expressions
programmatically.
- MockVariableResolver not able to resolve array elements like
#{someBean.property[0]}
- How would I resolve an expression like #{someBean.name == John Doe}
- How could I invoke static EL functions like #{prefix:fnName}
Advance Thanks for your help.
--
--
Regards
Venkat Thoppae
(240)446-7632
---BeginMessage---
Actually I missed that part while typing a sample code.
But here is a clean test case runnable if you have shale-test-x.jar.
Appreciate if someone could try this on their box.
Two files are attached.
MyTestCase.java has test cases defined.
SomeBean is a simple POJO.
Thanks
On Tue, May 20, 2008 at 10:57 AM, Chris Keefer [EMAIL PROTECTED] wrote:
I think in JSF 1.1 you have to get the value from a ValueBinding. See
below.
@Test
public void test1 {
ValueBinding binding =
facesContext.getApplication().createValueBinding(#{someBean.prop[0]}};
String val = (String) binding.getValue(facesContext);
assertEquals(val, M);
}
Or you can try the VariableResolver like so:
@Test
public void test1 {
String val =
facesContext.getApplication().getVariableResolver().resolveVariable(facesContext,
#{someBean.prop[0]});
assertEquals(val, M);
}
Hope this helps.
--Chris
On May 19, 2008, at 1:06 PM, Venkataganesh Thoppae wrote:
Yes, I know Shale doesn't read faces-config.
Here is a sample implementation.
public class MyTestCase extends AbstractJsfTestCase {
//A valid someBean object is created in the request scope in setUp()
@Test
public void test1 {
String val=
(String)facesContext.getApplication().createValueBinding(#{someBean.prop[0]}};
assertEquals(val, M);
}
}
The error I get is:
javax.faces.el.PropertyNotFoundException: prop0
at
org.apache.shale.test.mock.MockPropertyResolver.descriptor(MockPropertyResolver.java:213)
at
org.apache.shale.test.mock.MockPropertyResolver.getValue(MockPropertyResolver.java:69)
at
org.apache.shale.test.mock.MockValueBinding.getValue(MockValueBinding.java:126)
Regards
On Mon, May 19, 2008 at 12:08 PM, Kito D. Mann [EMAIL PROTECTED] wrote:
Hmm... What errors are you getting? Or is it just returning null? If it's
just returning null, remember that you must manually but the bean
RE: More dialogs in same time
It seems like shale dialog generates an ID per view that is used to manage the dialog context and the id is attached to the view root. It's been awhile since I've looked at this code but I want to say that you should be able to managed multiple dialogs per session as long as JSF client state saving is turned on. Gary -- Original message -- From: [EMAIL PROTECTED] Rahul, thanks a lot! By Mario -Original Message- From: Rahul Akolkar [mailto:[EMAIL PROTECTED] Sent: 23 aprile 2008 23.21 To: user@shale.apache.org Subject: Re: More dialogs in same time On 4/23/08, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Uhm, how can I start more DialogContext and use the correct one for each windows? So the problem is: I start dialog A from window 1 and window 2 of the same instance browser(sharing same httpsession). How can I use two different states from the two windows/dialogs? snip/ OK, lets try to work on this together :-) but I'm heading out soon so I'll be slower to respond. What have you tried? I had one potential suggestion for trying to move forward. Did you look at the programmatic approach? What didn't work? What are the dialogs doing i.e. are they talking to session scoped beans (ugh, in this case) or dialog scoped beans? -Rahul Mario -Original Message- From: Rahul Akolkar [mailto:[EMAIL PROTECTED] Sent: 23 aprile 2008 22.50 To: user@shale.apache.org Subject: Re: More dialogs in same time On 4/23/08, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: I'm sorry Rahul for same post and also because I don't understand your response. How can I have two active dialogs at same times? I understood that shale store current state I HttpSession (or Managed beans with scope session). snip/ There is one DialogContextManager per session. You can programmatically (or otherwise) start multiple dialogs (a.k.a. DialogContext instances). Starting the same dialog more than once (and at the same time) will have some additional caveats as I mentioned -- I haven't tried it. Please send me some example snap/ I don't have any more examples that I can share. Please try to look at the example webapps (for dialogs) -- say, from the v1.0.4 release -- for working models of some of these concepts. -Rahul Thanks Mario -Original Message- From: Rahul Akolkar [mailto:[EMAIL PROTECTED] Sent: 23 aprile 2008 22.06 To: user@shale.apache.org Subject: Re: More dialogs in same time Please do not send the same post to both user and dev list separately. There is no benefit IMO to doing that. On 4/23/08, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: My customer want two or more instance of the same dialogs on different windows. The problem is that the windows are created by the same browser (window.open) and with IE (for example) this windows condivide the same HttpSession. Is there a way to do it with Shale Dialog Manager? snip/ Probably more than one. For instance, one scenario could be setting up remoting [1] such that every time you hit a particular URL, a method binding processor starts an instance of a dialog programmatically [2], configured to taste etc. You could do window.open and friends. The application-level question is how the managed beans that back the dialogs will react to multiple instances. Based on their design and scope, you could have dialog instances walking on each others toes. -Rahul [1] http://shale.apache.org/shale-remoting/ [2] http://shale.apache.org/shale-dialog/ Thank in advance Mario This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the email by you is prohibited.
Re: Need to escape special characters in Shale validator script
You might try wrapping the script in a CDATA before trying to escape the JS.
![CDATA[
script
/script
]]
-- Original message --
From: Jeff Tsay [EMAIL PROTECTED]
Hi,
I'm trying to use Shale validator with xulfaces. (XUL is a user
interface language that is a type of XML) The first problem I'm having
is that
val:validatorScript functionName=validateForm/
is encoded as follows:
script type=text/javascript language=Javascript1.1
function _required() {
this[0] = new Array(j_id_id32, null is required., new Function(x,
return
{}[x];));
}
var bCancel = false;
function validateForm(form) {
var bValid = true;
var sFormName = jcv_retrieveFormName(form);
if ((bValid !bCancel ( == sFormName))) {
bValid = (validateRequired(form));
}
return bValid;
}
...
Note the . When I load this page in Firefox, it complains that is
not valid XML, which it is not. It should be escaped to amp;amp;. I
guess because HTML browsers allow special characters like in side
script tags, this problem wasn't caught previously. I guess if the
script appeared in an XHTML document, and a browser was strict, this
problem could show up too.
So I was trying to fix this problem and looking at
org.apache.shale.validator.faces.ValidatorScript.writeValidationFunctions().
It looks like the script text is written here with
ResponseWriter.write(). The problem is ResponseWrite.write() doesn't
escape the characters as ResponseWriter.writeText() does. However,
writeText() won't work since it closes any open tags (in this case
script). So we need to escape ourselves. The trouble is, how do we
know how to escape the characters? I was thinking of using
org.apache.commons.lang.StringEscapeUtils.escapeXml() and escapeHtml(),
but how can we determine what the content type we are outputting is? If
we knew, I guess we could then create a WrappedResponseWriter that
overloads write(String) ...
Thanks,
Jeff
RE: [Shale Clay]
From: Zheng, Xiahong [EMAIL PROTECTED]
Thanks again. I have another question. How does shale work with
fileload? I am trying to use t:fileUpload from tomahawk. I copied the
component definition into my clay-config.xml
component jsfid=t:inputFileUpload
componentType=org.apache.myfaces.HtmlInputFileUpload
extends=baseOutput
attributes
set name=id bindingType=VB /
.
/attributes
/component
And I added the following in my html form
form enctype=multipart/form-data
input jsfid=t:inputFileUpload value=#{mybean.symbolsFile}
storage=file /
input type=submit action=#{mybean.getQuotes} value=Get Quotes/
/form
When I hit the submit button, action method is never invoked.
Interestingly, if I remove the enctype attribute, action method is
indeed invoked but the input is null which is expected. I have the
extension filter configured.
Any idea?
This is just a guess but you might try using the tomahawk form component too.
There might be some component coupling that is assumed in the library.
Gary
-Original Message-
From: Richard Eggert [mailto:[EMAIL PROTECTED]
Sent: Friday, April 11, 2008 7:33 AM
To: user@shale.apache.org
Subject: RE: [Shale Clay]
Yes. Basically, you would have to define a component that inherits from
h:dataTable, and give it child elements that inherit from h:column.
Each of those child elements would then contain children that make up
the content of your columns.
Rich Eggert
Member of Technical Staff
Proteus Technologies, LLC
http://www.proteus-technologies.com
-Original Message-
From: Zheng, Xiahong [mailto:[EMAIL PROTECTED]
Sent: Fri 4/11/2008 12:08 AM
To: user@shale.apache.org
Subject: RE: [Shale Clay]
Thanks a lot Rich. I was able to use your first example without having
any white space issue even if I reformatted it a bit. If I want to use
the second solution, how would I define the behavior of the dataTable?
Would it still need to inherit dataTable for the looping capability
since the number of rows are dynamic?
-Original Message-
From: Richard Eggert [mailto:[EMAIL PROTECTED]
Sent: Thursday, April 10, 2008 5:12 PM
To: user@shale.apache.org
Subject: RE: [Shale Clay]
My experience with dataTables and clay has been that they don't get
along very well, at least in the case of HTML templates (XML templates
are another story). This is mainly because h:dataTable has a
drastically different structure from HTML tables. h:dataTable expects
to have h:columns as its immediate child (with optional tags for header
and footer rows nested within each column), whereas HTML TABLE tags
expect to have TR (row) tags as its children (or TR tags nested within a
TBODY), with the column (TD) tags nested within each row. Essentially,
from the point of view of an h:dataTable, a column contains rows, but in
an HTML TABLE, a row contains columns, which makes mapping between the
two extremely difficult. It can be done, but it involves making a lot
of dummy jsfid=void tags and using SPAN tags to cause elements that
wouldn't be visible in the mockup to be rendered at runtime.
e.g.,
table jsfid=h:dataTable var=foo value=#{bar.list}
tr jsfid=void allowBody=false
thMock Heading/th
/trtr jsfid=void
td jsfid=h:column
#{foo.name}
span jsfid=h:outputText value=Real Heading
facetName=header/span
/td
/tr
/table
Note that the lack of whitespace around the TR elements is intentional
to avoid (blank) text elements winding up as children of the h:dataTable
component (which is very nasty and breaks everything!).
As you can see, writing an HTML template for a dataTable gets extremely
ugly very quickly. For this reason, I don't recommend doing it unless
you REALLY want to be able to view the mockup in a browser before
deploying it. You're better off defining the template in XML and just
referring to it in the parent template, e.g.,
table jsfid=my:customtable allowBody=false
Table goes here.
/table
What we really need is a new JSF component that provides the same
capabilities as dataTable but is structured more like HTML TABLE tags.
Rich Eggert
Member of Technical Staff
Proteus Technologies, LLC
http://www.proteus-technologies.com
-Original Message-
From: Zheng, Xiahong [mailto:[EMAIL PROTECTED]
Sent: Thu 4/10/2008 2:22 PM
To: user@shale.apache.org
Subject: FW: [Shale Clay]
I couldn't seem to understand by looking at the clay usecase example.
Can somebody post a simple example of using clay to generate a dynamic
data table, the equivalent of the JSF h:dataTable tag?
Re: AW: [ANNOUNCE] New Shale PMC Chair
From: Bernhard Slominski [EMAIL PROTECTED] -Ursprüngliche Nachricht- Von: Gary VanMatre [mailto:[EMAIL PROTECTED] Gesendet: Montag, 24. März 2008 19:31 An: user@shale.apache.org Betreff: RE: [ANNOUNCE] New Shale PMC Chair From: Congrats Gary! I hope Shale restart the development. Yeah, I have a few new Clay ideas but all are JSF 1.2ish. I also hope that Shale has some future (that were my last words at the JSF days presentation about Shale: It's not yet dead !). For the Clay vs. Facelets: I think one major problem is really the confusing naming (HTML, full HTML, full XML ...) and documentation of Clay, there should be put some effort in there. Good point. Bad terms with probably too many options. Clay can be used with JSP or as a page entry point like facelets. The template can be non-xhtml, xhtml or an abstract reference defined in XML that doesn't correspond to a physical resource similar to tiles. The templates can be loaded from the context root or from the classpath. Clay templates allow inheritance in addition to composition. Many have told me that Facelets has clearly won and we should just try to help them out JSF 2 will be featured from facelets. Bernhard Gary
RE: [ANNOUNCE] New Shale PMC Chair
From: [EMAIL PROTECTED] Congrats Gary! I hope Shale restart the development. Yeah, I have a few new Clay ideas but all are JSF 1.2ish. * Refactor clay config beans with interfaces and impl. Way back I started looking at using JPA entity beans to define clay configs. My hope was to make the entity beans implement common interfaces making them config beans. * Custom EL function support. * Defining template config using annotations. I sorta lost momentum with the popularity of facelets and JSF 2.0 planning. I think the last Clay feature that I added was metadata to represent the java final modifier [1]. The template inheritance, symbols and pre-htmlx support are really the only unique features over the others (facelets JSF templating) and they are now the de facto standard. [1] https://issues.apache.org/struts/browse/SHALE-353 Gary Mario -Original Message- From: Greg Reddin [mailto:[EMAIL PROTECTED] Sent: 20 marzo 2008 15.41 To: user@shale.apache.org; [EMAIL PROTECTED] Subject: [ANNOUNCE] New Shale PMC Chair In its meeting yesterday the Apache Board of Directors unanimously approved a resolution naming Gary VanMatre the new chair of the Apache Shale Project Management Committee. Please join us in congratulating Gary for this new role. In addition we would like to publicly thank Craig McClanahan for his service to this project and his invaluable contribution to the Java web application development community. We are endlessly grateful to him for his role in defining the JavaServer Faces framework and, more specifically, in birthing the Shale project. It is no small loss to this community that his work has made it difficult for him to be as involved as he once was. At his own request, Craig is now an emeritus member of the Shale PMC. Thank you, Greg Reddin Apache Shale PMC Member This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the email by you is prohibited.
Re: Shale Roadmap
From: Niall Pemberton [EMAIL PROTECTED] On Feb 6, 2008 7:21 PM, linux.eavilesa wrote: Hi all, I've been tracking user and development mailing lists during some time, and I think that people is getting (including me) a little bit nervous about Shale project. and rightly so - the trends are stark: Overall: http://shale.markmail.org/search/?q= Dev: http://tinyurl.com/2d3e92 Commits: http://tinyurl.com/2synvm Unless those trends start to reverse, the only glimmer of hope on the horizon is/was the proposal to move the code to MyFaces. Niall, I know you are a *very* active struts and commons committer and apache supporter so I will take this to heart. Niall Gary I think that the main reason why is the fact that there is not a well defined road map now for the project and many of as have bitten to use Shale in front of other frameworks. First of all decide if Shale has a future (that I think that it does) and redefine or reinforce the project goal. So in my opinion we should focus on defining or determining three key concepts: · Define the project team organization, mainly the project leader and the development team. · Determine the release of the stable version (date and who will lead it) · Analyze each module and decide which must eliminated and which is worth keeping alive You will say Thanks for your time. Esteve
Re: Dynamic clay in a datatable
From: Daniel del Río [EMAIL PROTECTED]
Hello, I know similar questions was made in the past but I haven't found
a response. I'm trying to render an HTML that depends of the current
datatable row value, but the result is that all render the same page:
This is the code:
t:dataTable value=#{home.banners} var=c
t:column
clay:clay id=prueba jsfid=WDynamicClay managedBeanName=c
c:symbol name=page
value=[EMAIL PROTECTED]/
/clay:clay
/t:column
/t:dataTable
And WDynamicClay is an xml component definition:
component jsfid=WDynamicClay extends=clay
attributes
set name=clayJsfid value=@page/
/attributes
/component
The managedBeanName's attribute jsfid returns a different clay html
template
but always the last template is rendered.
I tried other alternatives but always with identical result:
Unfortunately, you can not use Clay this way in a dataTable. A data table is a
UIData component. These types of components implement the flyweight pattern.
One set of component definitions for a column is applied to each row as the
model as it is iterated over. For this to work, the clay component would need
to rebuild the subtree for each row. I'm pretty sure that only one attempt to
find the clay config beans that build the subtree is made. The subtree creates
first class components that are added to the component tree under the clay
component (children). A dynamic subtree in a datatable would most likely cause
all kinds of problems with state saving too.
- Using a ShapeValidator
- Create a JSF component that adds a clay component
- Extending the Clay component
Thanks in advance.
Daniel del RÃo.
Gary
Re: Clay problem: NPE when reloading a page
From: Philippe Van Der Gucht [EMAIL PROTECTED] Hello, I use JSF RI 1.1 and Shale v1.0.4 with the Weblogic v10 server. I have tried to use clay to make a tile-like composition of a webpage. This renders just fine on the first try but when reloading I get this error: java.lang.NullPointerException: at org.apache.shale.clay.component.Clay.encodeBegin(Clay.java:305) at org.apache.shale.clay.component.Clay.recursiveRenderChildren(Clay.java:413) at org.apache.shale.clay.component.Clay.recursiveRenderChildren(Clay.java:416) at org.apache.shale.clay.component.Clay.recursiveRenderChildren(Clay.java:416) at org.apache.shale.clay.component.Clay.encodeChildren(Clay.java:445) There is not enought info to tell what's going on. Could you try the nightly builds here: http://people.apache.org/builds/shale/nightly/. What does you defintions (clay config) look like? Greetings, Philippe. Gary
Re: clay and support for jsf 1.2
From: Ryan Lubke [EMAIL PROTECTED] Gary VanMatre wrote: From: Tomasz Pasierb Hi guys, does clay support jsf 1.2, I mean should it be working when used with jsf 1.2 implementation? I've been playing with it and I'm not sure whether it's my fault or framework's. The problem is that in the rendered view I have a string . I guess this should be replaced with the actual state information somewhere around the render-response phase but isn't in my case. I placed the form component in the layout (template) file. It sounds like this issue is related to a RI API change [1]. They removed the class that I was using to determine the version of the runtime. We'll have to find another way. Actually, the class is still package, but isn't used. I left it in there so that shale wouldn't break. Wow, that was very thoughtful. Ill try to get a fix in for this so that you can clean up. Tom, are you by chance using myfaces 1.2? [1] https://issues.apache.org/struts/browse/SHALE-472 Any help appreciated :-) Regards, Tom
Re: clay and support for jsf 1.2
From: Tomasz Pasierb [EMAIL PROTECTED] Hi guys, does clay support jsf 1.2, I mean should it be working when used with jsf 1.2 implementation? I've been playing with it and I'm not sure whether it's my fault or framework's. The problem is that in the rendered view I have a string . I guess this should be replaced with the actual state information somewhere around the render-response phase but isn't in my case. I placed the form component in the layout (template) file. It sounds like this issue is related to a RI API change [1]. They removed the class that I was using to determine the version of the runtime. We'll have to find another way. [1] https://issues.apache.org/struts/browse/SHALE-472 Any help appreciated :-) Regards, Tom
Shale-test setup managed bean
Hello, I am trying to add a managed bean to the Mock Faces Context that will be used in my unit test. My test class extends AbstractJsfTestCase. This sounds like a bug. Please create a JIRA ticket [1]. [1] http://shale.apache.org/issue-tracking.html Gary
Re: Using shale-test with ValueBinding lists
From: Iain Duncan [EMAIL PROTECTED]
Hi Gary,
Thanks a lot for the information! Do you know if the mock implementation
is going to be extended at any point to include dealing with lists
reference by expressions like #{myBean.myList[0]}?
I'm not sure. The test framework is one of the best parts of Shale but the
only problem I see in expanding for more EL support is that it becomes more and
more complicated. It's easy to draw the line with the existing mock
implementation.
At one time I added a fix to support scopes like
#{requestScope['xxx.xxx.xx']} and Craig made a similar comment about keeping
the mock implementation simple.
However, Shale is used by many of the myfaces projects. I think the community
should make the decision providing there is a volunteer to contribute.
Cheers,
Iain
Gary
___
Iain Duncan
MDM Platform Services Development
IBM UK Limited
MP 188, Hursley Park, Winchester, Hants, SO21 2JN, UK
t: +44 (0)1962 816873 / Internal : 7-246873
e-mail: [EMAIL PROTECTED]
[EMAIL PROTECTED] (Gary VanMatre)
16/10/2007 16:27
Please respond to
user@shale.apache.org
To
user@shale.apache.org
cc
Subject
Re: Using shale-test with ValueBinding lists
From: Iain Duncan
Hello All,
I've just started using shale-test to test an application using JSF1.1
so
apologies if this is a dumb question and I am doing something obvious
wrong! I have been unable to get the getValue() method on a ValueBinding
that involves a list to work. Does anyone know if this has been
implemented?
Simple expressions can be evaluated. The mock implementation tokenizes
the expression based on the dot separator. So, you can evaluate
expressions like #{mybean.property}.
You have to programmatically add your beans into scope in your unit tests
or add a few lines of logic to process faces-config's.
Cheers,
Iain
Gary
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
3AU
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
Re:
From: Wendy Smoak [EMAIL PROTECTED] On 10/3/07, Lionel Port wrote: There was a bug in Shale 1.0.4 ( http://issues.apache.org/struts/browse/SHALE-409) that prevented ajax4jsf working with shale. It is fixed in the nightly builds. Just waiting on the release of shale 1.0.5, but the project seems to have stalled. There's not much development going on, but if there's interest in a release we can probably round up enough people to make it happen. I'd like to see the Tiles 2 integration sorted out first, though. I'd also like to see a 1.0.5 release. I think tiles 2 under 1.0.5 still assumes JSF 1.1. I really think we need to branch off for 1.2 support. I'll try to make some time to look at what is going on with shale tiles if you guys will roll it. -- Wendy Gary
Re: your mail
From: Crabb, Curtis [EMAIL PROTECTED] As soon as I start using Shale 1.0.4, Ajax4Jsf stops working. I believe the issue is as follows: 1.) Ajax4Jsf depends upon the javax.faces.ViewRoot being an instance of AjaxViewRoot. 2.) Shale depends upon the javax.faces.ViewRoot being an instance of ShaleViewRoot. I believe I am correct in saying that my application can only use one implementation of javax.faces.ViewRoot; the one being used in my case is simply the last jar that is being loaded, which happens to be Shale (I could also specify my own ViewRoot in my WEB-INF faces-config and then niether AjaxViewRoot or ShaleViewRoot will be used). That being the case, is it even possible to use both Ajax4Jsf and Shale in the same application? The shale view root is not required. Why not try loading the AjaxViewRoot in your application's faces-config.xml. Or, rename the shale view jar to something like aaa-shale-view.jar. Can anyone shed some light on my confusion? Why does Shale override the ViewRoot implementation when that immediately stops me from using other 3rd party products that override ViewRoot? Indeed, you could ask the same question of Ajax4Jsf? In shale's case, it was done to catch exceptions raised by JSP to make sure that the view controller callback contracts worked. In JSF 1.2 the lifecycle is an extension point that can be decorated which would be a better option now that it's avaiable. Gary A bit of extra information: Shale 1.0.3 does not provide it's own implementation of javax.faces.ViewRoot; that being the case, I can successfully use it with ajax4jsf. Also, I can use ajax4jsf with Shale 1.0.4 if I specify in the following in my own WEB-INF faces-config javax.faces.ViewRoot org.ajax4jsf.framework.ajax.AjaxViewRoot ss javax.faces.ViewRoot I believe this works simply because my copy of faces-config.xml is the last configuration loaded, so my override takes precedence. However, this can break Shale because now Shale sees an instance of AjaxViewRoot rather than ShaleViewRoot. So I am stuck with not knowing how to make both products work simultaneously.
Re: ide support for shale clay
From: Tomasz Pasierb [EMAIL PROTECTED] Hey guys, I was wondering if there is any support for developing clay xml views in Eclipse Europa - it's hard to remember all the available tag and their attributes :(. When developing jsp or jsf pages I get some content assist but can't get any for clay pages. How do you develop views using clay? The shale_clay_plugin_for_eclipse resting in the sandbox. The build only works with eclipse 3.2 but you can still get it to build with a few steps. Give it a try. It's real slick. 1) Build is dependent on the 1.1.0-SNAPSHOT svn co http://svn.apache.org/repos/asf/shale/framework/trunk shale cd shale mvn clean install 2) The plugin needs the sandbox parent pom. svn co http://svn.apache.org/repos/asf/shale/sandbox/ sandbox cd sandbox/shale-eclipse-plugins/plugins/shale_clay_plugin_for_eclipse 3) Eclipse 3.3 will not work with the maven pde-maven-plugin but the script will resolve the dependencies. The build will fail but the /lib folder will be populated with jars for the maven repos. mvn install 4) Open a workspace in eclipse 3.3 and import existing projects into workspace. Select the shale_clay_plugin_for_eclipse folder. 5) Select the /META-INF/MANIFEST.MF and use the Exporting wizzard on the overview tab (step 3) to build the plugin. 6) Drop the exported plugin jar shale_clay_plugin_1.0.0.jar into your 3.3 plugins folder. 7) Start eclipse using the -update command line arg. 8) Open up a shale/clay project. Right mouse click the clay-config.xml, Open With/Clay XML Editor Thanks Tom Gary
Re: mysterious client id using clay
From: Ryan Wynn [EMAIL PROTECTED] I am seeing the following client id being generated clayView:_idsc0:_idsc10:_idsc36:_idsc833:_idsc838_2:idsc859 I understand how that is being generated by the SequenceGenerator class, but I can't explain the _idsc838_2 ? This class has been removed from the latest build. Anybody have any idea where the _2 would be coming from? I'm not sure but it might be the SequenceGenerator is not synchronized. This guy had an internal StringBuffer that was truncating the suffix and appending the incremented number. BTW, In the 1.1.0-SNAPSHOT you will not see all of the namespaces in the client id's since Clay is no longer a naming container. I am using clay 1.0.3 Thanks, Ryan Gary
Re: Using Shale Validator with Seam
From: [EMAIL PROTECTED] Has anyone successfully integrated the Validator with Seam?? I've been trying to do so, but the Validator tags are showing up in the source code of my page and not being interpreted.? I assume I'm missing something in my web.xml file?? This is all I currently am including: The shale-validator jar includes the startup context listener in the /META-INF/validatord.tld. You should not need the config in the web.xml as long as the jar is in the classpath. snippet/ If you want to use shale common validator, you will need the following artifacts: * shale-core * shale-validator * commons-validator 1.3.1 * oro 2.0.8 (for the mask rule) The shale-validator library pom shows the dependencies [1]. There's an example in the shale-usecases [2] that might help. I don't know how well shale-validator will play with Seam. I have not tried it. You are actually better off looking for client-side validators in rich component libraries (i.e. Trinidad). Shale's common validators tries to play with any component library but still has some issues [3]. [1] http://svn.apache.org/viewvc/shale/framework/trunk/shale-validator/pom.xml?view=markup [2] http://svn.apache.org/viewvc/shale/framework/trunk/shale-apps/shale-usecases/src/main/webapp/validator/test.jsp?view=markup [3] https://issues.apache.org/struts/browse/SHALE-441 Thanks in advance!? Mike Gary AOL now offers free email to everyone. Find out more about what's free from AOL at AOL.com.
Re: Anomalies with @Prerender
From: Richard Eggert [EMAIL PROTECTED] I've been seeing weird problems with the invocation of @Prerender/prerender() methods and the handling of request-scoped backing beans. I have a HTML-templated page rendered with Clay, and a corresponding request-scoped backing bean annotated with @View. The backing bean has a method annotated with @Prerender that extracts a value from the request parameter Map. If the value has been set (via a URL parameter), the method uses it to initialize a property of the backing bean. For postbacks to the page, the value is preserved using a Tomahawk saveState component. We have four developers each running their own development instance of WebLogic Server 9.2. For two of us, everything works perfectly. However, for the other two, if the user loads the page twice in a row in different windows (or the same window) with different values for the URL parameter (or even the same value), the @Prerender-annotated method is only called during the first load, and the second instance of the page ends up with the same bean property values as the first. A custom PhaseListener that has been set up to run before the RENDER_RESPONSE phase in order to set values in the HTTP response header does run both times, however. Additionally, loading a separate page before loading this page the second time causes the @Prerender to work properly. In other words: Load pageA?param=1 in window 1. Load pageA?param=2 in window 2. Window 2 contains the same content as window 1, and checking the log reveals that prerender was called for window 1 but not for window 2. Load pageA?param=1 in window 1. Load pageB in window 3. Load pageA?param=2 in window 2. Window 2 contains content relevant to param=2, and checking the log reveals that prerender was called for both windows. Getting rid of the @View and @Prerender annonations and having the backing bean extend AbstractViewController had no effect, so the problem does not appear to be with shale-tiger's ViewController support (unless it is somehow interfering with the regular non-tiger ViewController support). Changing the STATE_SAVING_METHOD from server to client seems to fix the problem. We are using MyFaces 1.1.4 and Shale 1.0.4. Any idea of what might be causing this behavior? It sounds like myfaces is restoring the view versus creating a new view. If you can use commandLink's for navigation, with navigation rules in the faces-config, the view will be recreated each time but that might not be an option. You might also try myfaces 1.1.5 with Shale nigthly. I believe there is some changes with state management in 1.1.5. Rich Eggert Member of Technical Staff Proteus Technologies, LLC http://www.proteus-technologies.com Gary
RE: Clay not escaping strings?
From: Richard Eggert [EMAIL PROTECTED] snippet/ It sure would be nice if there were a way to tell Clay whether to escape such strings (perhaps an escapeProps attribute added to the clay:clay component). In my case, the current behavior is never what I want to happen, and I suspect that would be the case in just about any application that doesn't need to store HTML in its managed beans. Sounds like a good idea. Please create a JIRA ticket. Rich Eggert Member of Technical Staff Proteus Technologies, LLC http://www.proteus-technologies.com Gary
RE: master-detail redirection with annoteded request bean and tomahawk updateActionListener
From: [EMAIL PROTECTED]
Hi
Wrong list - Try the MyFaces list for questions regarding Tomahawk
Unless you are using Shale Clay, as Hermod stated, myfaces would be the best
community to ask tomahawk questions.
However, it looks like you are using Facelets, not that here is anything wrong
with
that :-(.
See my comments below:
Hermod
-Original Message-
From: Érico Teixeira [mailto:[EMAIL PROTECTED]
Sent: Monday, July 30, 2007 8:26 PM
To: user@shale.apache.org
Subject: master-detail redirection with annoteded request bean and
tomahawk updateActionListener
I have an use case where I need to load a dataTable with all monthly fees
from a
student and put a link in id column to redirect to an annotaded Fee Request
Bean
where I can visualize all details ...
I've tried to use :
t:dataTable id=cob var=fee
value=#{studentBean.fees} preserveDataModel=true
rows=8
...
You have a typo in your action. I think you need #{studentBean.choose}.
t:commandLink id=command_link action=#{sutendBean.choose}
immediate=true
h:outputText value=#{fee.fee} /
t:updateActionListener property=#{feeBean.fee} value=#{fee} /
/t:commandLink
In my faces_config.xml I have :
navigation-rule
from-view-id*/from-view-id
navigation-case
from-action#{studentBean.choose}/from-action
from-outcomesuccess/from-outcome
to-view-id/view/fee.xhtml/to-view-id
redirect /
/navigation-case
/navigation-rule
Using Eclipse / Tomcat Debug when I enter in feeBean I can see that my
property
#{feeBean.fee} is set to null
The object feeBean must exist before you can assign the fee object from the
data table. There also needs to be a getFee() and setFee(FeeBean) on the
feeBean.
Are those steps correct ? Is that the way to have a master-detail redirection
using these frameworks ?
Using the t:updateActionListener is a very good way to handle master-detail.
Trinidad has a similar action listener too. It's such a good idea that it was
added to JSF 1.2.
Gary
Re: Can shale-clay be used as a shared library?
From: Ryan Wynn [EMAIL PROTECTED] I am attempting to move shale-clay.jar outside the of the web application into a shared library. It looks to me from the code that this is probably not supported. I am guessing that multiple applications would clash because the ConfigBeanFactory would not be able to distinguish which application it is serving anymore since it would be shared by all applications. Is there a way that the config bean factory could be keyed by the context classloader such that it can handle multiple applications pulling from it? I think something like this was done in the myfaces javax.faces.FactoryFinder. We have a couple factories [1][2] that we would need to look at besides common chains. I believe that we would also need to look at our static reference to logger and the Message (bundle wrapper). So, it would require a bunch of refactoring. [1] http://svn.apache.org/viewvc/shale/framework/trunk/shale-clay/src/main/java/org/apache/shale/clay/config/beans/ConfigBeanFactory.java?view=markup [2] http://svn.apache.org/viewvc/shale/framework/trunk/shale-clay/src/main/java/org/apache/shale/clay/parser/builder/BuilderFactory.java?view=markup Thanks, Ryan Gary
Re: Any sucess with shale nightly 20070717 and RI JSF 1.2?
From: Esteve Avilés [EMAIL PROTECTED] HI, Does anyone know when will the next version of shale be released? The only major outstanding issue I know of is Tiles 2.x refactoring. Otherwise, I think we are just waiting on someone to find the time to roll it. thanks a lot, -- Esteve Avilés
Re: Any sucess with shale nightly 20070717 and RI JSF 1.2?
Sorry about the empty post. Let's try again. There appears to be an unresolved bug from 02/Oct/06 reported against this problem along with a workaround at: https://issues.apache.org/struts/browse/SHALE-302 http://forum.java.sun.com/thread.jspa?threadID=770686messageID=4408064 -= Gregg =- Gregg, thanks for providing more information. The issues that Shale has with regards to the proposed changes: * Shale doesnt yet have a code branch specifically focusing on JSF 1.2. We have talked about doing this but have not made it a priority. * Shale tries to be RI neutral. The solution on the forum uses classes in the implementation of the Sun RI. This solution wouldnt work with myfaces. Gary---BeginMessage--- Sorry about the empty post. Let's try again. There appears to be an unresolved bug from 02/Oct/06 reported against this problem along with a workaround at: https://issues.apache.org/struts/browse/SHALE-302 http://forum.java.sun.com/thread.jspa?threadID=770686messageID=4408064 -= Gregg =- Gregg Leichtman wrote: I have assembled a small sample project using: RI of JSF 1.2 v1.2_04_p2 Shale nightly 20070717 tiles-core-2.0-r468346-SNAPSHOT.jar from the Shale nightly distribution JSTL 1.1.2 Tomcat 6.0.13 Updated the faces-config.xml to use: faces-config xmlns=http://java.sun.com/xml/ns/javaee; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-facesconfig_1_2.xsd; version=1.2 Updated the web.xml to use: web-app version=2.5 xmlns=http://java.sun.com/xml/ns/j2ee; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_5.xsd; I have the same sample project working successfully using: myfaces 1.1.4 Shale nightly 20070409 tiles-core-2.0-r468346-SNAPSHOT.jar from the Shale nightly distribution JSTL 1.1.2 Tomcat 6.0.13 faces-config.xml: !DOCTYPE faces-config PUBLIC -//Sun Microsystems, Inc.//DTD JavaServer Faces Config 1.1//EN http://java.sun.com/dtd/web-facesconfig_1_1.dtd; web.xml: web-app version=2.4 xmlns=http://java.sun.com/xml/ns/j2ee; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd; When I attempt to display the home page of the new project, I get a blank page. I have checked the tomcat logs and there are no complaints. The web page source from the page that is displayed consists only of: html lang=en /html Using Live HTTP Headers inside FireFox yielded nothing of interest as far as I can tell. Have I mixed incompatible components? If not does anyone have a suggestion short of debugging the JSF RI or tiles source on how I can track down what is happening? -= Gregg =- signature.asc Description: OpenPGP digital signature ---End Message---
Re: shale-tiger and jsf 1.2
From: Tomasz Pasierb [EMAIL PROTECTED] I'd be grateful if someone could explain what is the proccess of shale-tiger starting up and reading the annotated beans. I mean I don't see any faces-config.xml in its jar. What class is supposed to try to start the process of scanning annotated classes? Is it somewhere in shale-core? Not shale-core but shale-view. The view library has a context listener registered in the META-INF/taglib.tld [1]. The listener tries [2] to load a complementing listener [3] in the tiger library. The context listener scans the classes for shale annotations. Later a variable resolver [4] in the tiger library uses the annotations to deliver managed beans. I think there has been some issues in the past with tiger and JSF 1.2 [5]. You might try explicitly declaring the packages to scan. I had a problem using OC4J in embedded mode. The web classpath /WEB-INF/classes was not avaiable when the context listeners loaded. context-param param-nameorg.apache.shale.tiger.SCAN_PACKAGES/param-name param-valueorg/acme/view/beans/param-value /context-param [1] http://svn.apache.org/viewvc/shale/framework/trunk/shale-view/src/main/resources/META-INF/taglib.tld?view=markup [2] http://svn.apache.org/viewvc/shale/framework/trunk/shale-view/src/main/java/org/apache/shale/view/faces/LifecycleListener.java?view=markup [3] http://svn.apache.org/viewvc/shale/framework/trunk/shale-tiger/src/main/java/org/apache/shale/tiger/view/faces/LifecycleListener2.java?view=markup [4] http://svn.apache.org/viewvc/shale/framework/trunk/shale-tiger/src/main/java/org/apache/shale/tiger/faces/VariableResolverImpl.java?view=markup [5] https://issues.apache.org/struts/browse/SHALE-345 Gary Thanks Gregg Leichtman pisze: There appear to be some problems with MyFaces 1.2.0 or Tomcat 6.0.13 and JSF tags. For example see: http://article.gmane.org/gmane.comp.jakarta.myfaces.user/38651 This does not address your specific problem, but I ran into the above referenced problem immediately. Notice that the problem was reported yesterday. -= Gregg =- Tomasz Pasierb wrote: Hi, shale-tiger doesn't seem to work with myfaces 1.2 which has recenlty been released. I have a bean annotated with @Bean and it doesn't seem to be picked up. The bean doesn't exists when I try to get/set some properties on it using EL. Everything is fine with the bean when it's declared in faces-config.xml. Additionally no messages are logged by tiger even on debug level apart from the one that states that 'original variableResolver was wrapped...' Does shale-tiger work with jsf 1.2? (I've quickly skimmed through the sources and it seems that only DTDs for jsf 1_0 and 1_1 are allowed (FacesConfigParser#REGISTRATIONS) if that's what it's used for. I've configured my webapp according to the jee5 tutorial where they use schema for 1.2. May this be the reason why shale-tiger doesn't register the annotated beans?) Regards, Tom Pasierb
Re: tld2claycfg encoding problem
From: Tomasz Pasierb [EMAIL PROTECTED] Hi guys, I'm trying to use Tld2Claycfg tool to convert trinidad, tomahawk and tomahawk tlds to clay config files. In order to do this I've checked out 3 projects, built installed tld2claycfg and mojo projects and configured pom in test project. When I run the mvn clean package goal I the the following exception indicating there's some problem with encoding (all the dependencies were downloaded to my local repo). Is there any config property or system property I should set when running the goal ? The exception is: javax.xml.stream.XMLStreamException: Underlying stream encoding 'Cp1250' and inp ut paramter for writeStartDocument() method 'utf-8' do not match. at com.sun.xml.internal.stream.writers.XMLStreamWriterImpl.writeStartDoc ument(XMLStreamWriterImpl.java:1182) at org.apache.shale.clay.util.TldToClayconfig.writeConfigFile(TldToClayc onfig.java:435) at org.apache.shale.clay.util.TldToClayconfig.convert(TldToClayconfig.ja va:275) ... [ERROR] BUILD FAILURE [INFO] [INFO] !TldToClayconfig.exception: !javax.xml.stream.XMLStreamException: Underly ing stream encoding 'Cp1250' and input paramter for writeStartDocument() method 'utf-8' do not match.: Underlying stream encoding 'Cp1250' and input paramter fo r writeStartDocument() method 'utf-8' do not match. Any help? This looks like a bug. Please create a JIRA ticket. We need to look at using the IO Reader Writer to perform character encoding conversion. Gary
Re: Integrating shale+ajax4jsf (+facelets+trinidad)
From: Bruno Aranda [EMAIL PROTECTED] Hi, I have an existing application with ajax4jsf+facelets+trinidad and I thought it was high time to test shale. Of course, I found that ajax4jsf and shale do not play well together since shale 1.0.4. I do not know the insights of shale and I don't have much time now, so what is the status of that integration between these two?. One alternative is that I use shale 1.0.3 (with that one words, but I guess I will get old stuff and new bugs) A few posts and a JIRA issue already comment on this problem. Any quickfix? :-) There is a quick-fix but I've not had time to block off an afternoon[1]. We need to move the problem code into the tiger library. I think the ViewControllerCallbacks2 would be the best place to relocate. [1] https://issues.apache.org/struts/browse/SHALE-409 Cheers, Bruno Gary
Re: f:validator and Undefined component type override
From: Ian.Priest [EMAIL PROTECTED]
I've hit a problem trying to set up a validator on an input text field.
Here's the HTML...
div class=content
xmlns:t=http://myfaces.apache.org/tomahawk;
xmlns:h=http://java.sun.com/jsf/html;
xmlns:f=http://java.sun.com/jsf/core;
...
h:inputText styleClass=x-large size=20 maxlength=20
value=[EMAIL PROTECTED]
id=username
validator=[EMAIL PROTECTED]
required=true
f:validator validatorId=com.scn.Regex suppliedRegex=[A-Za-z0-9]*
errorMessage=#{messages['customer.username_invalid_chars']} /
/h:inputText
And here's the error message
There are a couple issues here. The first issue is that the mapping logic is
only looking for a validator and not a f:validator. This one is a bug.
Please log a JIRA ticket if you get a chance.
However, you will still need to define this validator as a clay XML component
definition because it is statefull and has attributes. The HTML mapping will
only push property values on to a component that has attributes defined in
the clay config. All other HTML attributes are treated as symbols.
Consider the following:
Clay XML Config:
component jsfid=scn:regex componentType=com.scn.Regex
attributes
set name=suppliedRegex bindingType=Early /
set name=errorMessage bindingType=Early/
/attributes
/component
HTML Template:
div class=content
xmlns:t=http://myfaces.apache.org/tomahawk;
xmlns:h=http://java.sun.com/jsf/html;
xmlns:f=http://java.sun.com/jsf/core;
h:inputText styleClass=x-large size=20 maxlength=20
value=[EMAIL PROTECTED]
id=username
validator=[EMAIL PROTECTED]
required=true
f:validator jsfid=scn:regex suppliedRegex=[A-Za-z0-9]*
errorMessage=#{messages['customer.username_invalid_chars']} /
/h:inputText
/div
-- or, if you are into verbose markup --
div class=content
xmlns:clay=http://shale.apache.org/xml/clay;
clay:element jsfid=:inputText
clay:attributes
clay:set name=styleClass value=x-large/
clay:set name=size value=20 /
clay:set name=maxlength value=20/
clay:set name=value value=[EMAIL PROTECTED]/
clay:set name=id value=username/
clay:set name=validator value=[EMAIL PROTECTED] /
clay:set name=required value=true /
/clay:attributes
clay:validator jsfid=scn:regex
clay:attributes
clay:set name=suppliedRegex value=[A-Za-z0-9]* /
clay:set name=errorMessage
value=#{messages['customer.username_invalid_chars']} /
/clay:attributes
/clay:validator
/clay:element
/div
2007-06-28 17:22:52,574 [http-8443-Processor23] ERROR
[org.apache.shale.clay.component.chain.CreateComponentCommand] Cannot
create Component renderId=997 jsfid=f:validator
componentType=override extends=f:validator allowBody=null
facetName=null
javax.faces.FacesException: Undefined component type override
...
It works fine as-is, defined in component form like this...
value=[EMAIL PROTECTED]@validateMethod} /
extends=widgetsValidatedInputText
/
But unfortunately I have a requirement to strip out the component layer
and use the JSF tags direct so I can't leave it as-is. (And I also
realise it's slightly unusual to have two validators).
Cheers,
Ian.
Re: swing/swt and clay
From: Ryan Wynn [EMAIL PROTECTED] I have been thinking about the best way to go about building a wysiwyg eclipse editor for jsf views. The only ones I have seen so far create jsps. There are already existing GUI builders for Swing and SWT. Would it be possible for Clay to handle a view id which is the class name of a Swing or SWT Panel? I suppose it would just need to build a JSF tree based on the Swing/SWT tree. Any thoughts on an approach like this? That's an interesting idea. You know, the visual aspect would only be needed in the GUI builder. I wonder if you could create custom components that extended a base GUI component. Create a like component for each JSF component with corresponding properties. The GUI component would only have to hold the values of the properties and represent the composition of the page. The rendering of the component in design mode might be tricky but maybe it could just render an image of the JSF component. What if the GUI components used annotations to associate with a JSF component? On the clay side, we could have a custom handler that would map a jsfid to a swing/swt container. It would only need to instantiate the component to use it's composition to build a JSF tree. The jsfid could be used to override definitions similar to how the HTML mapping works today. Do you think there would be any strange requirements server side to create a swing component but not render it? I believe that swing is not coupled with the OS api but I don't know if the GUI component would require extra resources server side? Ryan Gary
Re: swing/swt and clay
Hi Ryan, I am not sure exactly what you want or heading to, but if the question is that is there a visual environtment to drag and drop components or widgets then you might wanna look into clay plug-in for eclipse which I believe it is in development. This is actually the same Ryan who donated the clay eclipse plugin (we are waiting for apache legal to verify the artifacts - Ryan's thinking out of the box again :--)
Re: swing/swt and clay
From: Craig McClanahan [EMAIL PROTECTED] On 6/23/07, Ryan Wynn wrote: I have been thinking about the best way to go about building a wysiwyg eclipse editor for jsf views. The only ones I have seen so far create jsps. I can throw in a couple of thoughts based on our (Sun's) experience with WYSIWIG editing for JSF views in Java Studio Creator and Visual Web Pack. * The design surface we used started life (many years ago) as a very hacked version of the Swing HTML 3.2 widget, and nowadays looks nothing at all like that code. * The hard part about rendering JSF components isn't really the widget itself ... it's the fact that any reasonable JSF component is also going to assume that CSS can be used. Emulating all of *that* is not an easy task, no matter how you approach it. (We do a fairly large percentage of CSS 2, but there's tons of edge cases -- to say nothing of the fact that you need to decide which browser's incompatible behavior you should emulate for lots of these settings.) * To say nothing of the fact that, besides support for CSS, your typical JSF component today is probably also going to assume that JavaScript and DHTML are also available, so you can build user interfaces for Ajax enabled applications. If you are not looking to build a tool that would work for all design needs, I think that the MyFaces Trinidad components are an interesting option for enterprise developers. They have a predefined css skins that apply application wide. The java script and PPR is built into the library. You really don't even need markup. There is a component for everything. The Infragistics smart client components are very popular amongst the dark-side and have the same skinning idea [1]. [1] http://www.infragistics.com/dotnet/netadvantage/winforms.aspx#Overview * Creating Swing components that take CSS, DHTML, and JavaScript into account is, I suppose, technically feasible ... but by then you've written a pretty large portion of a web browser :-). It's hard to believe that you can get these IDE's for free now. Java Rocks! * Expecting JSF component authors to write Swing component analogs for all their components doesn't seem like something the market would accept very well. No doubt, even selling JSP tags for this purpose Craig There are already existing GUI builders for Swing and SWT. Would it be possible for Clay to handle a view id which is the class name of a Swing or SWT Panel? I suppose it would just need to build a JSF tree based on the Swing/SWT tree. Any thoughts on an approach like this? Ryan
Re: using Commons validator fro JSF...?
From: Krupakar [EMAIL PROTECTED] Hi all, Iam looking for using commons validator for JSF to use to my project.But i have no clue how to use it. Though i tried shale, i was facing deployment problem in weblogic 9.1/9.2 . Shale needs Servlet 2.4. Does Weblogic 9.x support 2.4? Any help or sample would be helpful.. Regards Krupakar.T Gary LEGAL NOTICE Unless expressly stated otherwise, this message is confidential and may be privileged. It is intended for the addressee(s) only. Access to this E-mail by anyone else is unauthorized. If you are not an addressee, any disclosure or copying of the contents of this E-mail or any action taken (or not taken) in reliance on it is unauthorized and may be unlawful. If you are not an addressee, please inform the sender immediately
RE: Problem with subdialogs
From: [EMAIL PROTECTED] Rahul, I've tried shale-framework-20070606.zip because there isn't shale-framework-20070605.zip but seems that the problem is not resolved. what would have to be changed? What happens when you add a viewId attribute to the end state of the dialog config? Mario Gary -Original Message- From: Rahul Akolkar [mailto:[EMAIL PROTECTED] Sent: 5 giugno 2007 22.02 To: user@shale.apache.org Subject: Re: Problem with subdialogs On 6/5/07, [EMAIL PROTECTED] wrote: I have some problem with subdialogs using shale1.1.0-snapshot (22/05). Could you try the 20070605 build from here [1] (or try building yourself). I've made a change few minutes ago. -Rahul [1] http://people.apache.org/builds/shale/nightly/ This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the email by you is prohibited.
Re: Is there any one?
From: [EMAIL PROTECTED] This project seems to be deadi'm very afraid! Is there some one can help me? It's not dead, I think this is just a busy time for everyone. What's your problem? Gary Mario Buonopane Accenture Insurance Services Systems Via C. Colombo 112, 00147 Roma Tel: +39 06 51566543 Mobile: +39 334 6563433 Fax: +39 06 51566550 This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the email by you is prohibited.
RE: Problem with subdialogs
From: [EMAIL PROTECTED]
I have tried to set end state of dialog B without setting viewId. On
shale internet site there is this sentence:
If no view identifier was configured (meaning that the parent dialog
will be responsible for rendering the response to the current request),
simply return the logical outcome that caused this EndState to be
selected
This does not resolve the problem because the application continue to
state to test_dialogo_b/pagina_c.jsp (last view of dialog B). If I call
the dialog B not in subdialog, I expect that at the end of dialog B
shale will call the outcome avanti (last transition outcome) but does
not happens! Analyzing the code of
org.apache.shale.dialog.faces.DialogNavigationHandler this is the point
called in end state transition:
dcontext.advance(context, outcome);
if (log.isDebugEnabled()) {
log.debug(Advancing dialog '
+ dcontext.getName() + ' for FacesContext '
+ context + ' with navigation to viewId '
+ context.getViewRoot().getViewId() + ');
}
dcontext.advance does not call any view (I did not configure) and does
not call any outcome may be, in case of viewId not setted, should
call:
original.handleNavigation(context, fromAction, outcome);
?
???
The shale dialog navigation uses JSF navigation rules defined in the
faces-config.xml.
Do you have navigation rules for the viewId with outcomes for the view in
question?
When the navigation handler can not find a match rule for the outcome, it
re-renders the current view.
Mario
Gary
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
Sent: 5 giugno 2007 14.43
To: user@shale.apache.org
Subject: Problem with subdialogs
I have some problem with subdialogs using shale1.1.0-snapshot (22/05).
The first problem is:
I have a dialog B with following this configuration:
When I run this dialog not how subdialog I need this dialog end showing
/home/home.jsp.
I also need to call this dialog like subdialog of the following dialog
C:
target=Pagina B/
target=Pagina A/
The problem is that when the subdialog B ends, shale does not show
/test_dialogo_a/pagina_b.jsp but show /home/home.jsp .
When I use old shale 1.0.3 does work correctly.
The second problem is that I'm using the data property of
DialogContext to store some information but when start subdialog B, the
getData of DialogContext return an HashMap (not my class).
Please help me.
Mario
This message is for the designated recipient only and may contain privileged,
proprietary, or otherwise private information. If you have received it in
error, please notify the sender immediately and delete the original. Any
other
use of the email by you is prohibited.
Re: Question about ShaleViewRoot
From: [EMAIL PROTECTED] In faces-config.xml distributed with shale-view.jar there is the definition of ShaleViewRoot component: component-typejavax.faces.ViewRoot/component-type component-classorg.apache.shale.view.faces.ShaleViewRoot/component-class But I have a question about the jsf mechanisms: If in my WEB-INF/lib I have two jars with faces-config.xml distributed in META-INF directory, each of one define javax.faces.ViewRoot component type, witch is the component setted? Depends on the classloader order used to load the jars? Answered this question on the myfaces list: http://www.nabble.com/Qeestion-about-jsf-tf3864849.html Mario Buonopane Gary
RE: Clay jsfid=form not working
From: JS Portal Support [EMAIL PROTECTED] The s in s:form here is the myfaces sandbox, not shale, as you probably already guessed. My guess is that it has to do with command components you are using within the form. The form jsfid is the default JSF runtime component where s:form is enhanced to work with all the tomahawk bells-and- whistles. I'm not sure how it's related to the maven managed builds. Maybe it's a difference in the tomahawk or myfaces jar since maven will pull the latest snapshot? Gary -Original Message- From: JS Portal Support [mailto:[EMAIL PROTECTED] Sent: Thursday, May 31, 2007 3:31 PM To: user@shale.apache.org Subject: Clay jsfid=form not working Hi, I just transitioned my projects over to use Maven. All works quite well and I'm happy. However, I have a Clay form allowbody=true in which all links end up coming back to the page the form resides on. When I change to use jsfid=s:form, all works fine. Can this be due to a missing Maven dependency on the core JSF jar? I used the maven-myfaces-archetype to generate the project and thought that should setup the dependencies properly. Or could it be due to the clay config files? Does anyone have a clue what might cause this behaviour? Thanks, Joost
RE: SV: SV: Shale and Sandbox inputSuggestAjax
for Clay on this and if there is an interest
I
can write a small tutorial on the Wiki.
I am going to start a fix for the Shale-validator which is the cause
of
this later to day and hopefully it will be done in a day or two.
Hermod
-Opprinnelig melding-
Fra: Gary VanMatre [mailto:[EMAIL PROTECTED]
Sendt: 8. mai 2007 16:47
Til: user@shale.apache.org
Emne: Re: Shale and Sandbox inputSuggestAjax
From: Erik Govaers
Hello,
IÃÆââ'ìââm trying my hand at a very simple
example
based on the example at
http://www.irian.at/myfaces-sandbox/inputSuggestAjax.jsf. I
get an input field, but when I start typing I get no
suggestions since my backing bean
ÃÆââ'ìÃâ¹oesuggestedItemsÃÆââ'ìââ
method is never called. IÃÆââ'ìââm using server-side
saving,
but switching to client-side makes no difference.
IÃÆââ'ìââve
looked at a lot of the inputSuggestAjax related issues in the mailing lists,
but
found no solution yet.
My guess is that is has either something to do with the fact
that I'm using MyFaces 1.1.3 or with the fact that the
Shale/Clay ValidatorInputRenderer is overwriting the
InputSuggestAjax Renderer (something I noticed just now). If the
latter is true, what can I do to prevent this?
This is an open JIRA ticket [1]. We need to find a configurable
option
for specifying components in the javax.faces.Input family that should be
excluded from the commons validator renderer decorator.
This looks like a cool component. You might try a workaround. This
is
a *complete hack* but I think it should solve this problem. The trick would
be
to change the component family and rendererType.
[1] https://issues.apache.org/struts/browse/SHALE-442
Consider:
// subclass the component overriding the family and renderer type.
package com.acme.InputSuggestAjax public class InputSuggestAjax
extends
org.apache.myfaces.custom.suggestajax.inputsuggestajax.InputSuggestAjax {
public InputSuggestAjax() {
setRendererType(com.acme.InputSuggestAjax)
}
public String getFamily() {
return com.acme.Input;
}
}
// register the subclassed component in the
/WEB-INF/faces-config.xml
com.acme.InputSuggestAjax
com.acme.InputSuggestAjax
com.acme.Input
com.acme.InputSuggestAjax
org.apache.myfaces.custom.suggestajax.inputsuggestajax.InputSugg
estAjaxRenderer
Depending on if you are using JSP, Clay or Facelets you will need
some
additional setup.
Gary
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* * *
This email with attachments is solely for the use of the individual or
entity to whom it is addressed. Please also be aware that the DnB NOR
Group cannot accept any payment orders or other legally binding
correspondence with customers as a part of an email.
This email message has been virus checked by the anti virus programs
used in the DnB NOR Group.
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* * *
Re: FacesConstants.VIEW_NAME_RENDERED - requestMap parameter is missing, so prerender gets not called.
From: Torsten Krah [EMAIL PROTECTED] In the ViewPhaseListener, the view going to be rendered it taken from the requestMap. Using JSF/Shale this works fine. String viewName = (String) map.get(FacesConstants.VIEW_NAME_RENDERED); Using JSF, ViewController and SWF - viewName gets null - the VIEW_NAME_RENDERED is not in the map. Searched in the source code but did not yet found the position, where this constand is set to the requestMap, can someone give me some hints - maybe its impossible to get SWF (with flow and conversationScope) working, but maybe its possible - dont know this yet, but i'll want to investigate that a little bit. Hints are welcome. Maybe this problem is related to SHALE-409? Torsten Gary---BeginMessage--- In the ViewPhaseListener, the view going to be rendered it taken from the requestMap. Using JSF/Shale this works fine. String viewName = (String) map.get(FacesConstants.VIEW_NAME_RENDERED); Using JSF, ViewController and SWF - viewName gets null - the VIEW_NAME_RENDERED is not in the map. Searched in the source code but did not yet found the position, where this constand is set to the requestMap, can someone give me some hints - maybe its impossible to get SWF (with flow and conversationScope) working, but maybe its possible - dont know this yet, but i'll want to investigate that a little bit. Hints are welcome. Torsten smime.p7s Description: S/MIME cryptographic signature ---End Message---
Re: SHALE-409 fix
From: Torsten Krah [EMAIL PROTECTED] The question would be - as the second run is really useless - how to identify annotated tiger beans. If they can be identified (dont know if this is possible and how to do it yet), than the code in run two can be fixed to do what the comment does want to do, remove them, instead of removing the rest completely. I'm thinking that we could just remove that bit of logic because the web container should fire the ServletRequestListener [1] regardless? However, there might be a funky case that resulted in this logic in the PhaseListener - not sure. [1] http://svn.apache.org/viewvc/shale/framework/trunk/shale-view/src/main/java/org/apache/shale/view/faces/LifecycleListener.java?view=markup Torsten Gary---BeginMessage--- The question would be - as the second run is really useless - how to identify annotated tiger beans. If they can be identified (dont know if this is possible and how to do it yet), than the code in run two can be fixed to do what the comment does want to do, remove them, instead of removing the rest completely. Torsten Am Dienstag, den 22.05.2007, 15:41 +0200 schrieb [EMAIL PROTECTED]: Please fix the bug SHALE-409. Regards Mario Buonopane This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the email by you is prohibited. smime.p7s Description: S/MIME cryptographic signature ---End Message---
Re: SHALE-409 fix
From: Craig McClanahan [EMAIL PROTECTED]
On 5/23/07, Gary VanMatre wrote:
From: Craig McClanahan
On 5/23/07, Gary VanMatre wrote:
From: Torsten Krah [EMAIL PROTECTED]
The question would be - as the second run is really useless - how to
identify annotated tiger beans.
If they can be identified (dont know if this is possible and how to do
it yet), than the code in run two can be fixed to do what the comment
does want to do, remove them, instead of removing the rest completely.
I'm thinking that we could just remove that bit of logic because the
web container should fire the ServletRequestListener [1] regardless?
It will indeed get called later, but outside the JSF lifecycle ...
which means you would not be able to get to the FacesContext in a
destroy() method. That's why this logic was inserted in the first
place.
Ah, I figured there was good reason. What if we delegated to the tiger
LifecycleListener from the JSF phase listener - same pattern?
// Delegate to the Tiger Extensions instance if it exists
LifecycleListener tiger = tiger();
if (tiger != null) {
tiger.contextDestroyed(event);
}
private LifecycleListener tiger() ...
At first blush this looks good, but I'm heads down getting ready for a
trip to India next week, so I won't be able to actually play with this
until the first week of June.
Cool. I'll try to take a look this week. I don't have a Solaris box
sitting around to test but I could make the change to the 1.1.0-SNAPSHOT
and we could decide if we want to push it to the other branch later on.
Craig
Gary
Craig
Gary
However, there might be a funky case that resulted in this logic in the
PhaseListener - not sure.
[1]
http://svn.apache.org/viewvc/shale/framework/trunk/shale-view/src/main/java/org/
apache/shale/view/faces/LifecycleListener.java?view=markup
Torsten
Gary
-- Forwarded message --
From: Torsten Krah
To: user@shale.apache.org
Date: Wed, 23 May 2007 19:11:48 +
Subject: Re: SHALE-409 fix
The question would be - as the second run is really useless - how to
identify annotated tiger beans.
If they can be identified (dont know if this is possible and how to do
it yet), than the code in run two can be fixed to do what the comment
does want to do, remove them, instead of removing the rest completely.
Torsten
Am Dienstag, den 22.05.2007, 15:41 +0200 schrieb
[EMAIL PROTECTED]:
Please fix the bug SHALE-409.
Regards
Mario Buonopane
This message is for the designated recipient only and may contain
privileged, proprietary, or otherwise private information. If you have
received it in error, please notify the sender immediately and delete
the
original. Any other use of the email by you is prohibited.
Re: SV: SV: SV: Shale and Sandbox inputSuggestAjax
in the input
field.
The answer of the ajax request is:
[[detroit,nonamestreet,KL,11],[san
diego,maxstreet,SJ,12],[philadelphia,philstreet,NW,13
],[new york,newstreet,IL,14],[san
francisco,sanstreet,NY,15],]
The same.
But no popup for the suggests. No ajax or js error on the debug
console - whats wrong here?
Torsten
Am Freitag, den 11.05.2007, 09:45 +0200 schrieb Torsten Krah:
Thx - nice work.
Tried it, works so far - method gets called and i get an ajax response.
But i see no popup in the browser, must have done something wrong ;).
Torsten
Am Dienstag, den 08.05.2007, 19:57 +0200 schrieb Hermod Opstvedt:
Hi
Wiki entry in place.
Hermod
-Opprinnelig melding-
Fra: Erik Govaers [mailto:[EMAIL PROTECTED]
Sendt: 8. mai 2007 17:33
Til: user@shale.apache.org
Emne: Re: SV: Shale and Sandbox inputSuggestAjax
Hi,
It would be brilliant if you could get us a fix in a couple of days.
I'm in an advanced phase of a project and I'm reluctant to let go of
either Shale or Tomahawk-Sandbox. And yes, I would welcome a Wiki too.
Thank you,
Erik
- Oorspronkelijk bericht -
Van: Hermod Opstvedt [mailto:[EMAIL PROTECTED]
Verzonden: dinsdag, mei 8, 2007 05:14 PM
Aan: user@shale.apache.org
Onderwerp: SV: Shale and Sandbox inputSuggestAjax
Hi
I have a working setup for Clay on this and if there is an interest
I can write a small tutorial on the Wiki.
I am going to start a fix for the Shale-validator which is the cause
of this later to day and hopefully it will be done in a day or two.
Hermod
-Opprinnelig melding-
Fra: Gary VanMatre [mailto:[EMAIL PROTECTED]
Sendt: 8. mai 2007 16:47
Til: user@shale.apache.org
Emne: Re: Shale and Sandbox inputSuggestAjax
From: Erik Govaers [EMAIL PROTECTED]
Hello,
Iââ'¬â¢m trying my hand at a very simple example
based on the example at
http://www.irian.at/myfaces-sandbox/inputSuggestAjax.jsf. I
get an input field, but when I start typing I get no
suggestions since my backing bean
ââ'¬ËoesuggestedItemsââ'¬â¢ method is never called.
Iââ'¬â¢m using server-side saving, but switching to
client-side makes no difference. Iââ'¬â¢ve looked at a lot
of the inputSuggestAjax related issues in the mailing lists, but
found no solution yet.
My guess is that is has either something to do with the fact
that I'm using MyFaces 1.1.3 or with the fact that the
Shale/Clay ValidatorInputRenderer is overwriting the
InputSuggestAjax Renderer (something I noticed just now). If the
latter is true, what can I do to prevent this?
This is an open JIRA ticket [1]. We need to find a configurable
option for specifying components in the javax.faces.Input family
that should be excluded from the commons validator renderer
decorator.
This looks like a cool component. You might try a workaround. This
is a *complete hack* but I think it should solve this problem. The
trick would be to change the component family and rendererType.
[1] https://issues.apache.org/struts/browse/SHALE-442
Consider:
// subclass the component overriding the family and renderer type.
package com.acme.InputSuggestAjax public class InputSuggestAjax
extends
org.apache.myfaces.custom.suggestajax.inputsuggestajax.InputSuggestAjax
{
public InputSuggestAjax() {
setRendererType(com.acme.InputSuggestAjax)
}
public String getFamily() {
return com.acme.Input;
}
}
// register the subclassed component in the
/WEB-INF/faces-config.xml
component
component-typecom.acme.InputSuggestAjax/component-type
component-classcom.acme.InputSuggestAjax/component-class
/component
render-kit
renderer
component-familycom.acme.Input/component-family
renderer-typecom.acme.InputSuggestAjax/renderer-type
renderer-classorg.apache.myfaces.custom.suggestajax.inputsuggestajax.InputSuggestAjaxRenderer/renderer-class
/renderer
/render-kit
Depending on if you are using JSP, Clay or Facelets you will need
some additional setup.
Gary
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* * *
This email with attachments is solely for the use of the individual or
entity to whom it is addressed. Please also be aware that the DnB NOR
Re: Clay @ symbol not setting taglib mutator to null
From: Darran White [EMAIL PROTECTED] Hi, Not sure if this is a bug in clay but the clay documentation states If the result of the substitution is a zero length string, a null value is returned and the value is not apply to a property I have a clay config file using acegijsf it is configured as follows component jsfid=acegijsf:authorize componentType=net.sf.jsfcomp.acegijsf.Authorize allowBody=true attributes set name=ifAllGranted value=@ifAllGranted/ set name=ifAnyGranted value=@ifAnyGranted/ set name=ifNotGranted value=@ifNotGranted/ /attributes /component If in my html I use span jsfid=acegijsf:authorize ifAnyGranted=ROLE_ADMIN ADMIN ONLY STUFF /span The problem is that your symbol names have the same names as your attributes. When you use the Tapestry like html views, clay first tries to match the markup attributes with the component properties. Markup attributes that don't have a corresponding component property, are treated as symbols. Try something like this: component jsfid=acegijsf:authorize componentType=net.sf.jsfcomp.acegijsf.Authorize allowBody=true attributes set name=ifAllGranted value=@acegijsf:ifAllGranted/ set name=ifAnyGranted value=@acegijsf:ifAnyGranted/ set name=ifNotGranted value=@acegijsf:ifNotGranted/ /attributes /component span jsfid=acegijsf:authorize acegijsf:ifAnyGranted=ROLE_ADMIN ADMIN ONLY STUFF /span In this snippet, the component attribute name is ifNotGranted but the symbol name is acegijsf:ifNotGranted. When the page is rendered the Authorize class is having its methd public void setIfAllGranted(String ifAllGranted) snippet/ Darran White Senior Developer Gary
Re: is there any way I can tell clay parser to print a block of html code as it is without any changes?
From: AM101 [EMAIL PROTECTED] I am using a flash slide show in my html page. This slide show uses a xml file (images.xml) to configure images that needs to be displayed in the slide show. It works fine as a static html page (without clay) but when i use it with clay, clay throws NullPointerException during parsing. is there any way I can tell clay parser to print a block of html code as it is without any changes? What is the message of the NullPointerException? Clay has eleven implicitly mapped HTML elements to JSF components [1]. a/a form/form input type=text input type=checkbox input type=radio input type=submit label/label select/select select multiple/select option textarea/textarea If you want to ignore this mapping, you can wrapper the html block with an ignore jsfid. span jsfid=ignore form method=POST action=j_security_check Username:input type=text name=j_usernamebr Password:input type=password name=j_password input type=submit value=submit /form /span [1] http://shale.apache.org/shale-clay/index.html#clay-view-options Thanks, AM Gary -- View this message in context: http://www.nabble.com/is-there-any-way-I-can-tell-clay-parser-to-print-a-block-o f-html-code-as-it-is-without-any-changes--tf3754736.html#a10611556 Sent from the Shale - User mailing list archive at Nabble.com.
Re: Newbie question: Clay and Tiger
From: Brody Wong [EMAIL PROTECTED] Hi all, Can I use shale tiger annotation with clay? Sure, there is an example in the sandbox. http://svn.apache.org/viewvc/shale/sandbox/shale-clay-trinidad/ Thanks in advance -- Gary View this message in context: http://www.nabble.com/Newbie-question%3A-Clay-and-Tiger-tf3707490.html#a10369353 Sent from the Shale - User mailing list archive at Nabble.com.
Re: SV: s:inputSuggestAjax an Shale/Clay - ValidatorInputRenderer Type problem, the defaultRenderer wrapped is of the needed type - how to expose?
From: Hermod Opstvedt [EMAIL PROTECTED]
Hi
Disregard this. I had forgotten to configure Chain in my web.xml file.
However the situation remains unchanged. The configured method is not beeing
called and the Ajax post is hanging (loading according to firebug). The
PropertyListenerCommand is now beeing called and does what it is supposed to
(I think).
When I debug it, the following line:
propertyHelper.setValue(child, attributeBean.getName(), mb);
has:
child:
org.apache.myfaces.custom.suggestajax.inputsuggestajax.InputSuggestAjax
attributeBean.getName():suggestedItemsMethod
mb: #{post.getCities}
Hermod, make sure that shale-validator library is not included in the web app.
Torsten reported on the myfaces list [1] that the shale validator library was
wrapping the renderer for this component. This component uses an interface to
handle the PPR. Since the renderer was decorated, the interface was not
exposed.
[1] http://mail-archives.apache.org/mod_mbox/myfaces-users/200705.mbox/[EMAIL
PROTECTED]
Hermod
Gary
-Opprinnelig melding-
Fra: Hermod Opstvedt [mailto:[EMAIL PROTECTED]
Sendt: 4. mai 2007 18:59
Til: user@shale.apache.org
Emne: SV: s:inputSuggestAjax an Shale/Clay - ValidatorInputRenderer Type
problem, the defaultRenderer wrapped is of the needed type - how to expose?
Hi
I have tried to follow you example, but there must be something more to it.
I have set the suggestedItemsMethod and itemLabelMethod to MB
I have in the chain-config:
className=com.opstvedt.osseil.component.chain.myfaces.PropertyListenerComma
nd /
className=com.opstvedt.osseil.component.chain.myfaces.PropertyListenerComma
nd /
But when I run it i get:
javax.faces.FacesException: Could not set property suggestedItemsMethod of
component personregpanel:_id72 to value : #{post.getCities} with type :
java.lang.String
at
javax.faces.component._ComponentAttributesMap.setComponentProperty(_Componen
tAttributesMap.java:419)
at
javax.faces.component._ComponentAttributesMap.put(_ComponentAttributesMap.ja
va:312)
at
org.apache.shale.clay.component.chain.PropertyValueCommand.execute(PropertyV
alueCommand.java:193)
at
org.apache.commons.chain.impl.ChainBase.execute(ChainBase.java:190)
Hermod
-Opprinnelig melding-
Fra: Gary VanMatre [mailto:[EMAIL PROTECTED]
Sendt: 3. mai 2007 23:20
Til: user@shale.apache.org
Emne: Re: s:inputSuggestAjax an Shale/Clay - ValidatorInputRenderer Type
problem, the defaultRenderer wrapped is of the needed type - how to expose?
Hm - its a method binding expression - not a value binding one, so it
should be MB, shouldn't it?
The binding type should be MB but there is more to it. The method binding
requires defining the formal parameter list. The custom bindings are
configured by attribute name.
You will need to register your own command to create the custom binding.
This requires adding a chain to the clayCustomization catalog. The name
of the chain should correspond to the attribute name.
WEB-INF/chain-config.xml
The shale-clay-trinidad project in the sandbox has an example[1][2].
[1]
http://svn.apache.org/viewvc/shale/sandbox/shale-clay-trinidad/src/main/weba
pp/WEB-INF/chain-config.xml?view=markup
[2]
http://svn.apache.org/viewvc/shale/sandbox/shale-clay-trinidad/src/main/java
/org/apache/shale/clay/component/chain/trinidad/PropertyListenerCommand.java
?view=markup
Torsten
Gary
Am Donnerstag, den 03.05.2007, 19:01 +0200 schrieb Torsten Krah:
Did some code do get this wrapped functionality in.
Ajay encode call is made now - however, on the InputAjax class - the
method binding was not set.
What else have i have to do, to get a method binding expression on a
attribute working?
My clay sandbox xml got:
Should be enough, shouldn't it?
Torsten
RE: Clay full-xml and namespace ignoring my tags
From: Ian.Priest [mailto:[EMAIL PROTECTED] Sent: 03 May 2007 12:15 To: user@shale.apache.org Subject: Clay full-xml and namespace ignoring my tags Hi, I'm going round the bend with this one and suspect I'm missing something really obvious. I have a site set up that uses full xml views. I'm trying to add namespace tags to my pages, but they don't get rendered unless I use jsfid - here's what I mean... Page example.html: snippet/ So Clay is happily replacing my tag but isn't processing my h:outputText tag. Anyone know why not? Cheers, Ian. I'm a step closer - it's something to do with the namespace declarations. If I do this... span jsfid=h:outputText value=hello / h:outputText xmlns:h=http://java.sun.com/jsf/html; value=hello / Then the page renders as Hello hello So the question becomes: why is my namespace declaration in the tag being ignored in the content page? Further explaination: as I said, I'm using full XML views, so the tag is defined in a separate file (layout.html) and the content (example.html) is pulled in using a span jsfid=clay clayJsfid=example.html It appears that the imported content file isn't inheriting values parsed in the parent. Is there somewhere I can set up the namespaces so that all the content html pages will be aware of them; that is, is there a common root I can use? Having to re-declare the namespaces in every page will be a right pain! The clay markup parser treats each template file as a separate document. The includes are not static but dynamic. In JSPish terms the Clay template include is like a JSP include versus a page directive. jsp:include page=dynamic.jsp/ -- versus -- jsp:directive.include file=static.jsp/ Once a template is parsed, it can be reused by any number of templates without reparsing. However, the symbols are scoped from the outer template to layers of included/nested templates. Cheers, Ian. Gary
Re: s:inputSuggestAjax an Shale/Clay - ValidatorInputRenderer Type problem, the defaultRenderer wrapped is of the needed type - how to expose?
Hm - its a method binding expression - not a value binding one, so it
should be MB, shouldn't it?
The binding type should be MB but there is more to it. The method binding
requires defining the formal parameter list. The custom bindings are
configured by attribute name.
You will need to register your own command to create the custom binding. This
requires adding a chain to the clayCustomization catalog. The name of the
chain should correspond to the attribute name.
WEB-INF/chain-config.xml
catalog name=clayCustomization
chain name=suggestedItemsMethod
command className=acme.PropertyListenerCommand /
/chain
/catalog
The shale-clay-trinidad project in the sandbox has an example[1][2].
[1]
http://svn.apache.org/viewvc/shale/sandbox/shale-clay-trinidad/src/main/webapp/WEB-INF/chain-config.xml?view=markup
[2]
http://svn.apache.org/viewvc/shale/sandbox/shale-clay-trinidad/src/main/java/org/apache/shale/clay/component/chain/trinidad/PropertyListenerCommand.java?view=markup
Torsten
Gary
Am Donnerstag, den 03.05.2007, 19:01 +0200 schrieb Torsten Krah:
Did some code do get this wrapped functionality in.
Ajay encode call is made now - however, on the InputAjax class - the
method binding was not set.
What else have i have to do, to get a method binding expression on a
attribute working?
My clay sandbox xml got:
set name=suggestedItemsMethod bindingType=VB
Should be enough, shouldn't it?
Torsten
---BeginMessage---
Hm - its a method binding expression - not a value binding one, so it
should be MB, shouldn't it?
Torsten
Am Donnerstag, den 03.05.2007, 19:01 +0200 schrieb Torsten Krah:
Did some code do get this wrapped functionality in.
Ajay encode call is made now - however, on the InputAjax class - the
method binding was not set.
What else have i have to do, to get a method binding expression on a
attribute working?
My clay sandbox xml got:
set name=suggestedItemsMethod bindingType=VB
Should be enough, shouldn't it?
Torsten
Am Donnerstag, den 03.05.2007, 18:33 +0200 schrieb Torsten Krah:
Some more insights:
This gets called:
public void encodeAjax(FacesContext context)
throws IOException
{
if (context == null) throw new NullPointerException(context);
if (!isRendered()) return;
Renderer renderer = getRenderer(context);
if (renderer != null renderer instanceof AjaxRenderer)
{
((AjaxRenderer) renderer).encodeAjax(context, this);
}
}
renderer however is not an instance of AjaxRenderer, instead is a
ValidatorInputRenderer, which only extends Renderer, not AjaxRenderer.
So the code stops there.
What may we have to do here, to get it working in clay - don't know much
about the ValidatorInputRenderer yet ;)
Maybe its sufficient, to add the AjaxRenderer Interface?
Torsten
Am Donnerstag, den 03.05.2007, 17:50 +0200 schrieb Torsten Krah:
Get it now rendered, although a form in a form it does not really like.
But i am facing the same problem you've got, nothing happens - my bean
methods are not called.
Am Dienstag, den 01.05.2007, 22:59 +0200 schrieb Hermod Opstvedt:
Hi
Has anybody made the inputSuggestAjax component work in a Shale/Clay
environment. It's posting to the server, but it's not calling my method
on
the configured bean. It just disapears
Hermod
smime.p7s
Description: S/MIME cryptographic signature
---End Message---
Re: [validator] possible bug in validator script generation for child comp. inside not rendered parent comp.
From: Hasan Turksoy [EMAIL PROTECTED]
hi all,
it seems there is a buggy case at validator script generation(at
findCommonsValidators method to be exact).. issue is; when i use a component
inside another parent component(that's NOT RENDERED), it's still generating
validator scripts for my child component.. this causes script errors when i
submitted my page... Because, there is a validation script exists for a not
rendered(because parent's not rendered) component.
To visualize;
// child components won't be rendered
because parent's not rendered
client=true /
as seen above, my textbox(txt_name) won't be rendered since it's parent
won't be rendered.. But client validator scripts are still being generated
for this field. This causes javascript errors at form submit...
Should we enter an issue for this case?
Please create a JIRA ticket for this one. Thanks!
Below is a test method for the case; (necessary methods already in jar's
test package)
/*---*/
public void testScriptNotGeneratedForComponentsInsideNotRenderedParent()
throws Exception {
// find the view root
UIViewRoot root = facesContext.getViewRoot();
assertNotNull(root);
UINamingContainer namingContainer = (UINamingContainer)
application.createComponent(javax.faces.NamingContainer);
namingContainer.setId(root.createUniqueId());
root.getChildren().add(root.getChildCount(), namingContainer);
//create a form 1
UIComponent form1 = this.createForm(test1, namingContainer);
//create a dummy parent panel component
HtmlPanelBox panelbox = createPanelBox(pnl_name, form1);
//create a dummy component 1
HtmlInputText component1 = createInputText(txt_name, panelbox);
//create a required field/server rule
CommonsValidator validator1 = createValidator(component1,
required, null);
//create a script component
ValidatorScript script = createValidatorScript(root);
// render the javascript for the form
StringBuffer htmlSnippet = encode(script);
System.out.println(htmlSnippet.toString());
// search tokens to test for in the javascript
String[] searchTokens = {
test1_required(),
this[0] = new Array(\test1:txt_name\);
};
// none of search tokens exist..
checkScriptForNotExist(htmlSnippet, searchTokens);
}
private void checkScriptForNotExist(StringBuffer htmlSnippet, String[]
searchTokens) {
for (int i = 0; i searchTokens.length; i++) {
Assert.assertFalse(Found: + searchTokens[i], (
htmlSnippet.indexOf(searchTokens[i]) != -1));
}
}
/*---*/
hope the issue is clear enough...
best regards,
Hasan...
Re: ConfigDefinitionsWatchdogFilter - defintion refresh conditions?
I've configured the WatchdogFilter to refresh my page definitions. But i can change my html pages (symbols) like i want - the changes are deployed, but clay does not refresh the page with the new content when navigating to the same page. Which conditions have to be met to get this working, i guess i am missing some things. You need to change the outer template or one of the common xml config files. There was too much overhead to check every page composition for nested fragments that have changed. Torsten Gary---BeginMessage--- I've configured the WatchdogFilter to refresh my page definitions. But i can change my html pages (symbols) like i want - the changes are deployed, but clay does not refresh the page with the new content when navigating to the same page. Which conditions have to be met to get this working, i guess i am missing some things. Torsten smime.p7s Description: S/MIME cryptographic signature ---End Message---
Re: Submitted values lost - view is refilled everytime with model values
Now it gets interesting.
I tried to get it working, using scxml dialogs instead of SWF.
The same problem.
Lets take shale dialogs - i guess thats your scope, so you may have
better insights for me when using the dialogs, whats going wrong.
What version of Clay are you using? What version of Myfaces are you using?
It might be related to this issue:
https://issues.apache.org/struts/browse/SHALE-418
Torsten
Gary---BeginMessage---
Now it gets interesting.
I tried to get it working, using scxml dialogs instead of SWF.
The same problem.
Lets take shale dialogs - i guess thats your scope, so you may have
better insights for me when using the dialogs, whats going wrong.
Torsten
Am Freitag, den 27.04.2007, 14:41 + schrieb Gary VanMatre:
From: Torsten Krah [EMAIL PROTECTED]
Hm did many Debug Points.
My RequestParameterMap got the entered values.
They are applied to my components in Phase 2 - setLocalValueSet is
called with set = true.
Now Phase 3 fails and Lifecycle goes to Phase 6.
Now a fresh tree is rendered , because my components does not got a
local value set - although the RestoreViewExecutor:
Application application = facesContext.getApplication();
ViewHandler viewHandler = application.getViewHandler();
// boolean viewCreated = false;
UIViewRoot viewRoot = viewHandler.restoreView(facesContext,
viewId);
if (viewRoot == null) {
viewRoot = viewHandler.createView(facesContext, viewId);
viewRoot.setViewId(viewId);
facesContext.renderResponse();
// viewCreated = true;
}
does call the restoreView and the viewRoot is not null.
If the view gets restored, why are t he components empty?
I was speculating that the spring dialog flow was loosing track
of the current dialog. The values in the flowScope were lost
because the dialog flow was somehow disconnected.
That's why I suggested that you debug the spring FlowPhaseListener.
This guy adds a component to the view root. At first, I thought that
a Clay full view might be removing the FlowExecutionKeyStateHolder
component since there was not any Clay config on that component but
after further review, I don't think that's the issue. Clay should
only remove
components from the tree in the render phase if they are nested under
a
Clay component (AssignChildrenCommand).
This FlowExecutionKeyStateHolder component is added as a child to
the view root by the FlowPhaseListener. It's not added as a child
under a composing Clay component so I don't think that's the problem.
However, stepping through the FlowPhaseListener should point to the
problem.
I am a little bit confused now, i've missed something, but dont know
where to look now.
The PhaseListener is doing the flow story and seems to work correct -
i
hope i did not missunderstand things.
Any hints?
I'm not familiar with the spring web flow. I'm only making guesses
based
on a quick look through the javadoc. If you create an example,
and attach it to a JIRA ticket, I'll try to make time to take a look.
Torsten
E-Mail-Nachricht-Anlage
Weitergeleitete Nachricht
Von: Torsten Krah [EMAIL PROTECTED]
An: user@shale.apache.org
Betreff: Re: Submitted values lost - view is refilled everytime
with model values
Datum: Thu, 26 Apr 2007 17:38:42 +
Hm did many Debug Points.
My RequestParameterMap got the entered values.
They are applied to my components in Phase 2 - setLocalValueSet is
called with set = true.
Now Phase 3 fails and Lifecycle goes to Phase 6.
Now a fresh tree is rendered , because my components does not got a
local value set - although the RestoreViewExecutor:
Application application = facesContext.getApplication();
ViewHandler viewHandler = application.getViewHandler();
// boolean viewCreated = false;
UIViewRoot viewRoot = viewHandler.restoreView(facesContext,
viewId);
if (viewRoot == null) {
viewRoot = viewHandler.createView(facesContext, viewId);
viewRoot.setViewId(viewId);
facesContext.renderResponse();
// viewCreated = true;
}
does call the restoreView and the viewRoot is not null.
If the view gets restored, why are the components empty?
I am a little bit confused now, i've missed something, but dont know
where to look now.
The PhaseListener is doing the flow story and seems to work correct - i
hope i did not missunderstand things.
Any hints?
Torsten
Am Donnerstag, den 26.04.2007, 15:51 + schrieb Gary VanMatre:
Got a problem with clay and flowScoped Spring beans.
My view is everytime filled with the model values. The submitted values
are lost.
I can enter some data in my input fields and submit the form - if i left
some required input fields empty, a message appears that something
Re: Submitted values lost - view is refilled everytime with model values
From: Torsten Krah [EMAIL PROTECTED]
Hm did many Debug Points.
My RequestParameterMap got the entered values.
They are applied to my components in Phase 2 - setLocalValueSet is
called with set = true.
Now Phase 3 fails and Lifecycle goes to Phase 6.
Now a fresh tree is rendered , because my components does not got a
local value set - although the RestoreViewExecutor:
Application application = facesContext.getApplication();
ViewHandler viewHandler = application.getViewHandler();
// boolean viewCreated = false;
UIViewRoot viewRoot = viewHandler.restoreView(facesContext,
viewId);
if (viewRoot == null) {
viewRoot = viewHandler.createView(facesContext, viewId);
viewRoot.setViewId(viewId);
facesContext.renderResponse();
// viewCreated = true;
}
does call the restoreView and the viewRoot is not null.
If the view gets restored, why are the components empty?
I was speculating that the spring dialog flow was loosing track
of the current dialog. The values in the flowScope were lost
because the dialog flow was somehow disconnected.
That's why I suggested that you debug the spring FlowPhaseListener.
This guy adds a component to the view root. At first, I thought that
a Clay full view might be removing the FlowExecutionKeyStateHolder
component since there was not any Clay config on that component but
after further review, I don't think that's the issue. Clay should only remove
components from the tree in the render phase if they are nested under a
Clay component (AssignChildrenCommand).
This FlowExecutionKeyStateHolder component is added as a child to
the view root by the FlowPhaseListener. It's not added as a child
under a composing Clay component so I don't think that's the problem.
However, stepping through the FlowPhaseListener should point to the
problem.
I am a little bit confused now, i've missed something, but dont know
where to look now.
The PhaseListener is doing the flow story and seems to work correct - i
hope i did not missunderstand things.
Any hints?
I'm not familiar with the spring web flow. I'm only making guesses based
on a quick look through the javadoc. If you create an example,
and attach it to a JIRA ticket, I'll try to make time to take a look.
Torsten---BeginMessage---
Hm did many Debug Points.
My RequestParameterMap got the entered values.
They are applied to my components in Phase 2 - setLocalValueSet is
called with set = true.
Now Phase 3 fails and Lifecycle goes to Phase 6.
Now a fresh tree is rendered , because my components does not got a
local value set - although the RestoreViewExecutor:
Application application = facesContext.getApplication();
ViewHandler viewHandler = application.getViewHandler();
// boolean viewCreated = false;
UIViewRoot viewRoot = viewHandler.restoreView(facesContext,
viewId);
if (viewRoot == null) {
viewRoot = viewHandler.createView(facesContext, viewId);
viewRoot.setViewId(viewId);
facesContext.renderResponse();
// viewCreated = true;
}
does call the restoreView and the viewRoot is not null.
If the view gets restored, why are the components empty?
I am a little bit confused now, i've missed something, but dont know
where to look now.
The PhaseListener is doing the flow story and seems to work correct - i
hope i did not missunderstand things.
Any hints?
Torsten
Am Donnerstag, den 26.04.2007, 15:51 + schrieb Gary VanMatre:
Got a problem with clay and flowScoped Spring beans.
My view is everytime filled with the model values. The submitted values
are lost.
I can enter some data in my input fields and submit the form - if i left
some required input fields empty, a message appears that something is
missing, so far so good.
However, the same field which i left empty - and all others i may have
changed - are now populated again with values from my bean.
What might cause this? I thought the component should remember this
value and display this instead of the beans model value. Lifecycle
stopped processing at Validation phase, so the components should not be
cleared, any idea or tipps to debug this?
I took a look at the webflow javadoc [1]. It looks like they are using a
couple tricks for saving the FlowExecution. The FlowPhase listener [2] adds
a non-visual component to the view root to keep state. It also adds the flow
execution key to the view root.It looks like the flow key is used to restore
the FlowExecution. I suspect the problem you are seeing has to do with the
state not being resorted for the current flow on the postback. I would try
setting some break points in the FlowPhaseListener.
[1]
http://static.springframework.org/spring-webflow/docs/current/api/overview-summary.html
[2]
http://opensource.atlassian.com/projects/spring/secure/attachment/12520
Re: SV: SV: SV: SV: SV: How to initialize a bean before initial display
From: AM101 [EMAIL PROTECTED] That was a typo...here is exception message again after changing it to managed-bean-name... Servlet.service() for servlet jsp threw exception javax.faces.el.ReferenceSyntaxException: Invalid expression: '[EMAIL PROTECTED]' It looks like you are trying to use Clay symbols in a JSP. Clay symbols only work if the component sub-tree is built using Clay. What are you trying to achieve? Gary Hermod Opstvedt wrote: Hi Its' managed-bean-name, not member-bean-name. This is the implicit mapping that Shale does. Hermod -Opprinnelig melding- Fra: AM101 [mailto:[EMAIL PROTECTED] Sendt: 27. april 2007 19:45 Til: user@shale.apache.org Emne: Re: SV: SV: SV: SV: How to initialize a bean before initial display I added backing bean entry in my faces-config.xml file: jspx$login com.foo.ui.view.backing.Login request and I also added in my login.jspx page. But now I get ReferenceSyntaxException. Stack Trace: Servlet.service() for servlet jsp threw exception javax.faces.el.ReferenceSyntaxException: Invalid expression: '[EMAIL PROTECTED]' at org.apache.myfaces.el.ELParserHelper.parseExpression(ELParserHelper.java:97) at org.apache.myfaces.el.ValueBindingImpl$2.newInstance(ValueBindingImpl.java:8 2) at org.apache.myfaces.shared_impl.util.BiLevelCacheMap.get(BiLevelCacheMap.java :123) at org.apache.myfaces.el.ValueBindingImpl.(ValueBindingImpl.java:115) at org.apache.myfaces.application.ApplicationImpl$1.newInstance(ApplicationImpl .java:64) at org.apache.myfaces.shared_impl.util.BiLevelCacheMap.get(BiLevelCacheMap.java :123) at org.apache.myfaces.application.ApplicationImpl.createValueBinding(Applicatio nImpl.java:617) at javax.faces.webapp.UIComponentTag.createComponentInstance(UIComponentTag.jav a:708) at javax.faces.webapp.UIComponentTag.findComponent(UIComponentTag.java:596) at javax.faces.webapp.UIComponentTag.doStartTag(UIComponentTag.java:312) at oracle.adf.view.faces.webapp.UIXComponentTag.doStartTag(UIXComponentTag.java :85) at org.apache.jsp.jspx.login_jspx._jspx_meth_af_outputText_0(login_jspx.java:10 56) at org.apache.jsp.jspx.login_jspx._jspx_meth_afh_cellFormat_7(login_jspx.java:1 034) at org.apache.jsp.jspx.login_jspx._jspx_meth_afh_rowLayout_5(login_jspx.java:10 10) at org.apache.jsp.jspx.login_jspx._jspx_meth_afh_tableLayout_4(login_jspx.java: 966) at org.apache.jsp.jspx.login_jspx._jspx_meth_af_form_0(login_jspx.java:941) at org.apache.jsp.jspx.login_jspx._jspx_meth_afh_cellFormat_6(login_jspx.java:9 18) at org.apache.jsp.jspx.login_jspx._jspx_meth_afh_rowLayout_4(login_jspx.java:81 6) at org.apache.jsp.jspx.login_jspx._jspx_meth_afh_tableLayout_3(login_jspx.java: 689) at org.apache.jsp.jspx.login_jspx._jspx_meth_afh_cellFormat_3(login_jspx.java:6 62) at org.apache.jsp.jspx.login_jspx._jspx_meth_afh_rowLayout_2(login_jspx.java:55 8) at org.apache.jsp.jspx.login_jspx._jspx_meth_afh_tableLayout_2(login_jspx.java: 534) at org.apache.jsp.jspx.login_jspx._jspx_meth_afh_cellFormat_1(login_jspx.java:5 08) at org.apache.jsp.jspx.login_jspx._jspx_meth_afh_rowLayout_1(login_jspx.java:48 1) at org.apache.jsp.jspx.login_jspx._jspx_meth_afh_tableLayout_1(login_jspx.java: 459) at org.apache.jsp.jspx.login_jspx._jspx_meth_afh_cellFormat_0(login_jspx.java:4 34) at org.apache.jsp.jspx.login_jspx._jspx_meth_afh_rowLayout_0(login_jspx.java:41 1) at org.apache.jsp.jspx.login_jspx._jspx_meth_afh_tableLayout_0(login_jspx.java: 389) at org.apache.jsp.jspx.login_jspx._jspx_meth_afh_body_0(login_jspx.java:364) at org.apache.jsp.jspx.login_jspx._jspx_meth_afh_html_0(login_jspx.java:262) at org.apache.jsp.jspx.login_jspx._jspx_meth_f_view_0(login_jspx.java:229) at org.apache.jsp.jspx.login_jspx._jspService(login_jspx.java:199) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:97) at javax.servlet.http.HttpServlet.service(HttpServlet.java:802) at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:3 34) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:314) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:264) at javax.servlet.http.HttpServlet.service(HttpServlet.java:802) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Application FilterChain.java:252) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterCh ain.java:173) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.
RE: [shale-remote] SesionBeans in MyFaces/Portlet Application
From: Strittmatter, Stephan [EMAIL PROTECTED] If the Bean is in session scope I would expect only one bean per session or am I wrong? Session scope is defined to the web container by the jsessionid. Does your remote request contain the jsessionid as a query parameters? Try using the ExternalContext.encodeResourceURL method to build the URL used by the remoting call. That's probably the only option if this is truly a portlet. -Original Message- From: Hermod Opstvedt [mailto:[EMAIL PROTECTED] Sent: Monday, April 23, 2007 4:53 PM To: user@shale.apache.org Subject: SV: [shale-remote] SesionBeans in MyFaces/Portlet Application Hi Indeed - Once going in on the post, and then again going out on the render response. Hermod -Opprinnelig melding- Fra: Strittmatter, Stephan [mailto:[EMAIL PROTECTED] Sendt: 23. april 2007 16:50 Til: user@shale.apache.org Emne: [shale-remote] SesionBeans in MyFaces/Portlet Application Hi all, I have made some small tests using shale-remote to make AJAX updates within my MyFaces-Portlet, but I found, that the session scoped ManagedBean is instantiated twice! I use the: * shale-remote of SVN (last week) * Apache Portlet bridge 1.0 * MyFaces/Tomahawk 1.1.5 I think, there are created two different contexts but not shure. Has already had someone this problem? Regards, Stephan
Re: SV: valueChangeListener is breaking form submit
Fra: AM101 [mailto:[EMAIL PROTECTED] Sendt: 21. april 2007 13:30 Til: user@shale.apache.org Emne: Re: valueChangeListener is breaking form submit When I remove valueChangeListener , setter is called. But I need to use valueChangeListener. That's a hard one to diagnose but I have a couple ideas. The setters on the sub type list are not going to be called if the component is disabled. Something else to consider is validation errors. You might be hitting validation errors. If you are, the lifecycle is going to stop short and jump to the render phase bypassing the update model phase. If you are hitting validation errors, try setting the immediate attribute to true on the two select components and the command component you are using to submit the form. This will cause the value change listeners and commands to be invoked in the apply request values phase (before validation). Gary AM101 wrote: I have two selectOneMenu components (lstType and lstSubType) in my form. I want to change values in lstSubType when value in lstType changes. I am using valueChangeListener as follwong: id=lstType allowBody=false / value=[EMAIL PROTECTED] / id=lstSubType allowBody=false value=[EMAIL PROTECTED] / value=[EMAIL PROTECTED] / value=[EMAIL PROTECTED] / Everything works fine except that when I submit the form setter of sub type is never called and always remains the same . Please let me know what is missing? Thanks, AM -- View this message in context: http://www.nabble.com/valueChangeListener-is-breaking-form-submit-tf3622758. html#a10116210 Sent from the Shale - User mailing list archive at Nabble.com.
componentType=override
I am trying to use the updateActionListener from Tomahawk, using Hermods
tomahawk 1.1.5 Snapshot xml for clay.
But i get this exception:
[181892007-04-13
18:33:17,488](org.apache.myfaces.application.ApplicationImpl)**ERROR**{org.apach
e.myfaces.application.ApplicationImpl.createComponent:391} User: -Undefined
component type override
[181982007-04-13
18:33:17,497](org.apache.shale.clay.component.chain.CreateComponentCommand)**ERR
OR**{org.apache.shale.clay.component.chain.CreateComponentCommand.execute:166}
User: -Cannot create Component renderId=464 jsfid=t:updateActionListener
componentType=override extends=t:updateActionListener allowBody=null
facetName=null
javax.faces.FacesException: Undefined component type override
Hm according to the shale clay page, this componentType should be
possible.
Whats missing here?
You need to define the listener as a top-level component setting the component
type
to the fully qualified path to the action listener.
component jsfid=t:updateActionListener
componentType=org.apache.myfaces.custom.updateactionlistener.UpdateActionListener
..
...
/component...
However, this won't work without further customizations because this action
listener
is statefull and has special value binding attributes. The JSP tag has to do
some
special processing [1].
You will need to create a custom handler to create the listener. There is an
example in the sandbox for the Trinidad version of the same thing.
First you will need to add a commons chains config file to the WEB-INF folder
of your web app [2]. Add a catalog with the name clayCustomizations.
Add a chain with the name of preprocessAddActionListener the the catalog.
catalog name=clayCustomization
chain name=preprocessAddActionListener
command className=acme.tomahawk.CreateActionListenerCommand /
/chain
/catalog
Next, create a commons chains command extending
org.apache.shale.clay.component.chain.CreateActionListenerCommand.
Add the extra logic to handle the special attributes [3].
[1]
http://svn.apache.org/viewvc/myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/custom/updateactionlistener/UpdateActionListenerTag.java?view=markup
[2]
http://svn.apache.org/viewvc/shale/sandbox/shale-clay-trinidad/src/main/webapp/WEB-INF/chain-config.xml?view=markup
[3]
http://svn.apache.org/viewvc/shale/sandbox/shale-clay-trinidad/src/main/java/org/apache/shale/clay/component/chain/trinidad/CreateActionListenerCommand.java?view=markup
Torsten
Gary
Re: Alternate ViewController
From: JS Portal Support [EMAIL PROTECTED]
Hi,
Though this primarily is a jsf question, I place it here since it might
involve the Clay viewhandler.
I wish to implement a viewhandler that can understand the following
navigation rule, and followed the steps as described in [1]
navigation-rule
from-view-id*/from-view-id
navigation-case
from-outcomego_contactus/from-outcome
to-view-id/#{sessionVars.locale}/contactus.jsf/to-view-id
redirect/
/navigation-case
/navigation-rule
I extended the org.apache.shale.clay.faces.ClayViewHandler and just added
the getActionURL(FacesContext context, String viewId). Unfortunately it is
not working. The page just reloads itself and that's all.
Is there already a system in place that does this as it seems to me a
usefull feature. If not, what am I doing wrong, and should I be extending
the ClayViewHandler or the MyFaces ViewHandler?
You are not using the best extension point. The navigation handler is the
place I'd try adding this extension [1]. The shale-dialog does this sort of
thing [2]. Like the other JSF extension points, you will want to decorate the
original that will be passed via the custom navigation handler's constructor.
The custom navigation handler gets registered in the faces config [3].
Gary
[1]
http://svn.apache.org/viewvc/myfaces/core/trunk/impl/src/main/java/org/apache/myfaces/application/NavigationHandlerImpl.java?view=markup
[2]
http://svn.apache.org/viewvc/shale/framework/trunk/shale-dialog/src/main/java/org/apache/shale/dialog/faces/DialogNavigationHandler.java?view=markup
[3]
http://svn.apache.org/viewvc/shale/framework/trunk/shale-dialog/src/main/resources/META-INF/faces-config.xml?view=markup
Thank you,
Joost Schouten
Dasstraat 21
2623CB Delft
the Netherlands
[1]
http://typo.ars-subtilior.com/articles/2007/01/24/how-to-make-jsf-navigation
-rules-more-dynamic
Re: How to upload a file in clay
From: AM101 [EMAIL PROTECTED] I want to use lt; input type=file jsfid=myfileUploadId gt; in my html file and I want to define a component for jsfid 'myfileUploadId' in clay configuration xml file. can anybody please tell me hot to do that. It depends on the component library(s) that you are using. If you are using tomahawk [1], you would use the t:inputFileUpload component. If you are using Trinidad [2], you might want to use the tr:inputFile component. If you are using the IBM components, you will want to use the hx:fileupload component [3]. The [1] http://svn.apache.org/viewvc/shale/framework/trunk/shale-clay/src/main/resources/META-INF/tomahawk-1_1_3-config.xml?view=markup [2] http://svn.apache.org/viewvc/shale/sandbox/shale-clay-trinidad/src/main/resources/META-INF/tr-incubator-m1-SNAPSHOT-config.xml?view=markup [3] https://issues.apache.org/struts/secure/attachment/13379/ibm-config.xml Thanks, AM Gary -- View this message in context: http://www.nabble.com/How-to-upload-a-file-in-clay-tf3560357.html#a9942876 Sent from the Shale - User mailing list archive at Nabble.com.
Re: SV: stack traces from shale-clay-usecases
From: John Carlson [EMAIL PROTECTED] The tutorials for the shale-clay-usecases? Where are they? The Javadocs aren't even there... Why must I read a tutorial to install a war? I know how to install wars, at least I think I do. You can find the latest from the nightly builds [1]. This is the last paragraph on the shale home page [2]. [1] http://people.apache.org/builds/shale/nightly/examples/shale-blank-20070411.zip [2] http://shale.apache.org/index.html#download Am I naming the application wrong in OC4J, or the context-root? If you install the war in the nightly package, you can give it any context root you desire. Do I need a deployment plan? I think misdirecting to Eclipse or JDeveloper is not the point. I can see plenty of documentation for building. All I want to do at this point is install the out of the box shale-clay-usecases.war in a standalone OC4J...and it isn't working. I have some documents that I can send you offline that outlines setting up a maven 2 build in JDeveloper. It will not be exactly what you need but it might get you started. You need to manually register the JDeveloper/OC4J JSP and servlet libraries. This also applies if you want to use the ADF Components or JSF RI 1.1. Another approach would be to perform a svn checkout of the usecases and build from that. There is a Jdev maven 2 plugin that is part of myfaces Trinidad that you can use to generate the JDeveloper workspace and project files. I'll shoot you some docs later this evening... John At 02:09 PM 4/11/2007, Hermod Opstvedt wrote: Hi You do not need to do anything when using Eclipse - That was for JDeveloper See the tutorials on the Shale Wiki Hermod -Opprinnelig melding- Fra: John Carlson [mailto:[EMAIL PROTECTED] Sendt: 11. april 2007 23:00 Til: user@shale.apache.org Emne: Re: stack traces from shale-clay-usecases I tried renaming the taglib.tld's without success. I'm using Eclipse for my IDE, but I'm just trying to deploy the out of the box war, and when I click on the links, I get exceptions. I just tried with the 4/11 snapshot. No luck. Can the war be used, or must I do a complete build? I did rebuild core and validator with maven, and verified that the taglibs were renamed. Could there be something with having both 1.0.4 and 1.1.0-SNAPSHOT jars in the WEB-INF/lib folder? John From [EMAIL PROTECTED] (Gary VanMatre) Subject Re: stack traces from shale-clay-usecases Date Sat, 03 Feb 2007 05:10:58 GMT I was able to run the shale-clay-usecases in 10g (10.1.3.1.1) from JDeveloper Studio 10.1.3.2 but I had to make a few minor changes. For some reason, JDeveloper doesn't like that the shale-core and shale-validator jars have TLD files with the name taglib.tld? I renamed the TLD's and it was happy? I pulled down the trinidad maven plugin to build the JDeveloper project file and ran from the IDE. I had to include the JSP Runtime libraries too. I'm not sure if that's what you are seeing? It's weird that taglib.tld trips it up? Gary -- Original message -- I got a couple of stacktraces from the shale-clay-usecases using OC4J 10.1.3.1 (supposedly supports J2EE 1.4). I deployed the shale-clay-usecases.war and tried to use the rolodex use cases. None of the rolodex cases work, although the first use case page does work.
RE: Alternate ViewController
From: JS Portal Support [EMAIL PROTECTED]
Gary,
Thank you for your help. Some things are not totally clear to me though, so
excuse my ignorance in these matters. When you say:
The shale-dialog does this sort of thing [2]
Do you mean it already does it in some way like:
No, I meant that shale-dialog has a custom navigation handler.
Sorry, I was being lazy in my response.
dialog name=go_contactus start=exit
end name=exit viewId=/#{sessionVars.locale}/contactus.jsf
redirect=true/
/dialog
Which I tried and it doesn't recognize the the EL and just redirects to the
viewed as a string. The description with your link [3] seems to describe
exactly what I need, but when implemented, it doesn't behave any different
from when I don't use these definitions.
So I guess my question is, do I go and extend
org/apache/myfaces/application/NavigationHandlerImpl.java and build a way to
recognize the EL in my viewId (how would be the next question) or is it a
matter of configuring my faces-config.xml to use the correct handlers that
can already do this?
Extending the myfaces handler might work but most of the methods are private.
It looks like the getNavigationCase is public in the myfaces handler for good
reason.
The entry in the faces-config is need to register your custom handler.
Consider the following snippet:
public void handleNavigation(FacesContext context, String fromAction,
String outcome) {
...
...
NavigationCase navigationCase = getNavigationCase(facesContext, fromAction,
outcome);
if (isEL(navigationCase.getToViewId())) {
... forwards only ...
ValueBinding vb =
context.getApplication().createValueBinding(navigationCase.getToViewId());
String newViewId = (String) vb.getValue(context);
UIViewRoot viewRoot = null;
viewRoot = viewHandler.createView(facesContext, newViewId);
facesContext.setViewRoot(viewRoot);
facesContext.renderResponse();
} else {
original.handleNavigation(context, ..)
}
Thank you for your patience with my coming to grips with the issues at hand,
Joost
Gary
-Original Message-
From: Gary VanMatre [mailto:[EMAIL PROTECTED]
Sent: Thursday, April 12, 2007 2:30 AM
To: user@shale.apache.org
Subject: Re: Alternate ViewController
From: JS Portal Support
Hi,
Though this primarily is a jsf question, I place it here since it might
involve the Clay viewhandler.
I wish to implement a viewhandler that can understand the following
navigation rule, and followed the steps as described in [1]
*
go_contactus
/#{sessionVars.locale}/contactus.jsf
I extended the org.apache.shale.clay.faces.ClayViewHandler and just added
the getActionURL(FacesContext context, String viewId). Unfortunately it is
not working. The page just reloads itself and that's all.
Is there already a system in place that does this as it seems to me a
usefull feature. If not, what am I doing wrong, and should I be extending
the ClayViewHandler or the MyFaces ViewHandler?
You are not using the best extension point. The navigation handler is the
place I'd try adding this extension [1]. The shale-dialog does this sort of
thing [2]. Like the other JSF extension points, you will want to decorate
the original that will be passed via the custom navigation handler's
constructor. The custom navigation handler gets registered in the faces
config [3].
Gary
[1]
http://svn.apache.org/viewvc/myfaces/core/trunk/impl/src/main/java/org/apach
e/myfaces/application/NavigationHandlerImpl.java?view=markup
[2]
http://svn.apache.org/viewvc/shale/framework/trunk/shale-dialog/src/main/jav
a/org/apache/shale/dialog/faces/DialogNavigationHandler.java?view=markup
[3]
http://svn.apache.org/viewvc/shale/framework/trunk/shale-dialog/src/main/res
ources/META-INF/faces-config.xml?view=markup
Thank you,
Joost Schouten
Dasstraat 21
2623CB Delft
the Netherlands
[1]
http://typo.ars-subtilior.com/articles/2007/01/24/how-to-make-jsf-navigation
-rules-more-dynamic
Re: Clay nested templates
Hi,
I'm experimenting with Clay and I like it. A few things are not quite clear
to me though. I can make my page /user_calendar.jsf work with the following
clay config:
component jsfid=baseHomeLayout extends=clay id=baseHomeLayout
attributes
set name=clayJsfid value=/templates/main_template.html /
/attributes
symbols
set name=title value=#{webLabels['msg.public.headTitle']} /
set name=content value=/components/empty.html /
/symbols
/component
component jsfid=/user_calendar.jsf extends= baseHomeLayout
symbols
set name=content value=/components/empty.html /
/symbols
/component
But I wish to insert another template inside a template, and thought the
following might work:
component jsfid=/user_calendar.jsf extends=baseHomeLayout
set name=content value=/templates/column_template.html
symbols
set name=left_column value=/components/empty.html /
set name=right_column value=/components/empty.html /
/symbols
/set
/symbols
/component
The XML above shouldn't validate to the clay DTD [1]. Try adding all symbols
under the symbols node.
component jsfid=/user_calendar.jsf extends=baseHomeLayout
symbols
set name=content value=/templates/column_template.html
set name=left_column value=/components/empty.html /
set name=right_column value=/components/empty.html /
/symbols
/component
The symbols are passed on to nested layers of included templates.
There is an example of this in the shale-usecases. A table template [2]
incudes another markup template [3] that passes symbols to XML
component definitions. The component definitions are passed
symbols through 2 layers of markup templates.
component jsfid=widgetsLabel extends=baseLabel
attributes
set name=value value=@label /
set name=for value=@property /
/attributes
/component
component jsfid=widgetsText extends=inputText id=@property
attributes
set name=value value=[EMAIL PROTECTED]@property} /
set name=size value=@size /
set name=maxlength value=@maxlength /
set name=required value=@required /
set name=immediate value=@immediate /
/attributes
/component
component jsfid=widgetsMessage extends=baseMessage
attributes
set name=for value=@property /
/attributes
/component
[1] http://shale.apache.org/dtds/clay-config_1_0.dtd
[2]http://svn.apache.org/viewvc/shale/framework/trunk/shale-apps/shale-clay-usecases/src/main/webapp/symbols/businessPerson.html?view=markup
[3]
http://svn.apache.org/viewvc/shale/framework/trunk/shale-apps/shale-clay-usecases/src/main/resources/org/apache/shale/usecases/symbols/inputTextWidget.html?view=markup
but it doesn't. I get the parse error:
java.lang.NoSuchMethodException: No such accessible method: addSymbol() on
object: org.apache.shale.clay.config.beans.SymbolBean.
I guess I will need to create an Element for the inserted template, but
tried different approaches but can't seem to get it to work. I could
obviously create a second complete template hardcoding
/templates/column_template.html in /templates/main_template.html, but that
defeats the Clay purpose.
Thank you,
joost
Gary
Clay Symbols aren't namespace aware - would be nice to have, wouldnt it?
Using a full HTML clay view it is possible to do things like that in a clay view: html xmlns=http://www.w3.org/1999/xhtml; xmlns:f=http://java.sun.com/jsf/core; xmlns:h=http://java.sun.com/jsf/html; xmlns:clay=http://shale.apache.org/clay; xmlns:s=http://shale.apache.org/core; xmlns:t=http://myfaces.apache.org/tomahawk; t:table ... /t:table /html I can use the components without using spans and the jsfid parameter. But if i use symbols to craft my page this does not work. The template does got the xmlns namespaces in the root html tag, but the symbols which gets replaced with header, footer co like this: div xmlns=http://www.w3.org/1999/xhtml; xmlns:f=http://java.sun.com/jsf/core; xmlns:h=http://java.sun.com/jsf/html; xmlns:clay=http://shale.apache.org/clay; xmlns:s=http://shale.apache.org/core; xmlns:t=http://myfaces.apache.org/tomahawk; jsfid=void p This is the Header. /p /div need this surrounding div workaround, to get the t:table working for example. Without the div and the namespaces, its brokenand gets not replaced by the jsf component. You could add the namespace to the table component too. You can also add an extends attribute. t:table xmlns:t=http://myfaces.apache.org/tomahawk; extends=mytable Should this work, is this a bug? Or is this correct behaviour? I tried to model it like an XML namespace but the clay markup template parser is not validating so you have a mix of html with namespaces. It would be nice if the symbols which gets replaced can use the namespaces declared in the root template. Yeah, that's not a bad idea. We would still need the namespace to be declared in the template file. Clay treats each template as a root. Once the markup is parsed, it can be included in any number of templates without re-parsing. It works more like a dynamic include versus a static include. Are you thinking about something like this? div xmlns:t=@tomahawkns ... kind regards Torsten Gary
Re: Using validators with Clay
I've been trying to get a custom validator working with Clay, but so far I
haven't figured out how to do it.
I have a class named a.b.c.IPAddressValidator that validates that a String
is
a valid dotted-decimal IP address, as its name implies. I've registered in my
faces-config under the validator-id a.b.IPAddress.
It works fine when I invoke it using JSP (i.e., using f:validator
validatorId=a.b.IPAddress / nested within a h:input element).
However, I have not been able to get it to work with Clay views defined either
in HTML or XML.
I tried this:
component jsfid=my:inputIPAddress extends=t:inputText
element renderId=0 jsfid=f:validator
attributes
set name=validatorId value=a.b.IPAddress /
/attributes
/element
/component
There are a couple of flavors of JSF Validators. One flavor allows using a
method binding expression to a managed bean callback. Components that realize
the EditableValueHolder interface provide a validator attribute.
Using this method, you would need the following clay XML config.
component jsfid=my:inputIPAddress extends=t:inputText
attributes
set name=validator value=#{mybean.validateIPAddress} /
/attributes
/element
/component
Your managed bean registered as mybean would have the following callback
method.
public void validateIPAddress(FacesContext context, UIComponent input, Object
value) {
...
}
but I got the error Undefined component type override, presumably because
the
clay-config.xml that comes with Clay defines f:validator with a
componentType
of override.
I also tried this (as XML and also in the equivalent HTML using span tags):
component jsfid=my:validateIPAddress componentType=a.b.IPAddress
extends=validator
/component
component jsfid=my:inputIPAddress extends=t:inputText
element renderId=0 jsfid=my:validateIPAddress /
/component
but that resulted in the error Undefined component type a.b.IPAddress.
I also tried swapping out my validator with the f:validateLongRange validator,
with the same result.
How do I get this to work? The only examples of validation in the Clay intro
page show it being done with managed bean methods and the validator
attribute.
There is a second way to register a validator in the clay XML config. The
component and element allow a nested validator node. In this case, the
jsfid needs to point to a top-level component definition that defines the
validator. The componentType captures the validatorId.
component jsfid=myvalidator componentType=a.b.IPAddress
attributes
.
/attributes
/component
component jsfid=my:inputIPAddress extends=t:inputText
...
...
validator jsfid=myvalidator
attributes
overrides - like an an anonymous inner class
/attributes
/validator
/component
Now, the nomenclature is getting in the way. The Clay metadata is not really
JSF component specific. We use the component node to represent, components,
validators, converters and listeners. At one time it was called
displayElement.
There is yet another way to define a validator. If you are using the html
namespaces, you would use JSP syntax.
span jsfid=void xmlns:f=http://java.sun.com/jsf/core;
xmlns:t=http://myfaces.apache.org/tomahawk;
t:inputText ...
f:validator validatorId=a.b.IPAddress/
/t:inputText
/span
Or, yet another...
span jsfid=void
xmlns:clay=http://shale.apache.org/xml/clay;
clay:element jsfid=t:inputText
clay:attributes
clay:set/
/clay:attributes
clay:validator jsfid=a.b.IPAddress/
/clay:element
/span
Rich Eggert
Member of Technical Staff
Proteus Technologies, LLC
http://www.proteus-technologies.com
Gary
Re: Tomahawk's enabledOnUserRole attribute and Clay
Perhaps I'm overlooking something here, but from the testing I did this
afternoon, it appears that the enabledOnUserRole attribute provided with
most
of Tomahawk's components doesn't work at all in Clay HTML templates. However,
it does work properly when I use straight JSP/JSF without Clay (at least most
of
the time, anyway; t:commandButton seems to have issues with it).
I have an HTML template that contains an element that looks something like the
following:
input
type=checkbox
jsfid=t:selectBooleanCheckbox
value=#{mybean.myflag}
enabledOnUserRole=myrole
/
When I view the page while logged in as a user that does not have the myrole
role, the checkbox is still enabled, and I can use it to toggle the
corresponding flag in the underlying bean. Thinking that it might be a
problem
with the implicit mapping of the input element, I tried changing the HTML
element to just a span tag (with attributes set as above, minus the
type=checkbox part), to no avail.
I also tried setting enabledOnUserRole for a textarea, and it didn't work
correctly there, either.
visibleOnUserRole seems to work just fine, though.
Any ideas on this, or should I post it to JIRA?
This looks like another case where we need to explicitly override the
rendererType.
The shared renderer [1] is the default for the runtime but in tomahawk, there
is a renderer
override [2].
[1]
http://svn.apache.org/viewvc/myfaces/shared/branches/2_0_0/core/src/main/java/org/apache/myfaces/shared/renderkit/html/HtmlCheckboxRendererBase.java?view=markup
[2]
http://svn.apache.org/viewvc/myfaces/tomahawk/branches/1_1_3/core/src/main/java/org/apache/myfaces/renderkit/html/ext/HtmlCheckboxRenderer.java?view=markup
Could you try the following test to help troubleshoot the problem?
Extend the base check box component definition:
component jsfid=mySelectBooleanCheckbox extends=t:selectBooleanCheckbox
attributes
set name=rendererType value=org.apache.myfaces.Checkbox
bindingType=VB /
/attributes
/component
In the html template, point to the override:
input
type=checkbox
jsfid=mySelectBooleanCheckbox
value=#{mybean.myflag}
enabledOnUserRole=myrole
/
I think this should solve the problem but regardless, please create a JIRA
ticket.
For reference, I'm using MyFaces 1.1.4, Tomahawk 1.1.3, and Shale 1.0.4.
Rich Eggert
Member of Technical Staff
Proteus Technologies, LLC
http://www.proteus-technologies.com
Gary
Re: SV: Tomahawk's enabledOnUserRole attribute and Clay
From: Hermod Opstvedt [EMAIL PROTECTED]
Hi
But this is handled in the new version of TlD2ClayCfg tool, so it if you use
it against the tomahawk 1.3 jar you will get a correct config file.
Yeah, that's a good point.
However, I'm still not convinced that we do not need to package the various
library configs for the stateful converters, validators and listeners.
Hermod
Gary
-Opprinnelig melding-
Fra: Gary VanMatre [mailto:[EMAIL PROTECTED]
Sendt: 27. mars 2007 17:06
Til: user@shale.apache.org
Emne: Re: Tomahawk's enabledOnUserRole attribute and Clay
Perhaps I'm overlooking something here, but from the testing I did this
afternoon, it appears that the enabledOnUserRole attribute provided with
most
of Tomahawk's components doesn't work at all in Clay HTML templates.
However,
it does work properly when I use straight JSP/JSF without Clay (at least
most of
the time, anyway; t:commandButton seems to have issues with it).
I have an HTML template that contains an element that looks something like
the
following:
type=checkbox
jsfid=t:selectBooleanCheckbox
value=#{mybean.myflag}
enabledOnUserRole=myrole
/
When I view the page while logged in as a user that does not have the
myrole
role, the checkbox is still enabled, and I can use it to toggle the
corresponding flag in the underlying bean. Thinking that it might be a
problem
with the implicit mapping of the element, I tried changing the HTML
element to just a tag (with attributes set as above, minus the
type=checkbox part), to no avail.
I also tried setting enabledOnUserRole for a textarea, and it didn't work
correctly there, either.
visibleOnUserRole seems to work just fine, though.
Any ideas on this, or should I post it to JIRA?
This looks like another case where we need to explicitly override the
rendererType.
The shared renderer [1] is the default for the runtime but in tomahawk,
there is a renderer
override [2].
[1]
http://svn.apache.org/viewvc/myfaces/shared/branches/2_0_0/core/src/main/jav
a/org/apache/myfaces/shared/renderkit/html/HtmlCheckboxRendererBase.java?vie
w=markup
[2]
http://svn.apache.org/viewvc/myfaces/tomahawk/branches/1_1_3/core/src/main/j
ava/org/apache/myfaces/renderkit/html/ext/HtmlCheckboxRenderer.java?view=mar
kup
Could you try the following test to help troubleshoot the problem?
Extend the base check box component definition:
extends=t:selectBooleanCheckbox
bindingType=VB /
In the html template, point to the override:
type=checkbox
jsfid=mySelectBooleanCheckbox
value=#{mybean.myflag}
enabledOnUserRole=myrole
/
I think this should solve the problem but regardless, please create a JIRA
ticket.
For reference, I'm using MyFaces 1.1.4, Tomahawk 1.1.3, and Shale 1.0.4.
Rich Eggert
Member of Technical Staff
Proteus Technologies, LLC
http://www.proteus-technologies.com
Gary
Re: prerender() not called on my tiles
From: Greg Reddin [EMAIL PROTECTED] On 3/20/07, Gary VanMatre wrote: We sure need a tiles example app for Shale. Yeah, one of these days I really need to start using Tiles 2 with a JSF app. I'm really behind the curve on that one :-) Well, if your using facelets, you are probably ahead of the curve when it comes to JSF. Really ahead of the curve if you are using Clay :-) On a serious note, I wonder how tiles and JSF 1.2 will work out since the rendering issues have been fixed in JSF/JSP. I just have not had the time to check it out. Greg Gary
RE: prerender() not called on my tiles
From: JS Portal Support [EMAIL PROTECTED] Hi, No messages and no errors. If I make a direct call to my tile like /jsp/user_dashboard.jsf, it does initialize the backing bean properly. This does lead me to believe it is a tiles related thing. I use shale 1.1.0 and the tiles that ships with it. Could you please create a JIRA ticket an add you example. We sure need a tiles example app for Shale. I can't shoot from the hip on this one but an example would help us see what's going on. Cheers, JS Portal - Support Dasstraat 21 2623CB Delft the Netherlands W: www.jsportal.com Gary -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 20, 2007 6:58 PM To: user@shale.apache.org Subject: RE: prerender() not called on my tiles Hi Have you made sure that there is a in case of validation errors. Also have you checked your servers log files for any errors? Hermod -Original Message- From: JS Portal Support [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 20, 2007 7:05 AM To: user@shale.apache.org Subject: RE: prerender() not called on my tiles No they seem not to be called either. Any jsp includes within the tiles are handled correctly and all lifecycle methods are called. Cheers, JS Portal - Support Dasstraat 21 2623CB Delft the Netherlands W: www.jsportal.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 20, 2007 5:40 PM To: user@shale.apache.org Subject: RE: prerender() not called on my tiles Hi Are the other lifecycle methods beeing called (init etc.) ? Hermod -Original Message- From: JS Portal Support [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 20, 2007 6:26 AM To: user@shale.apache.org Subject: prerender() not called on my tiles Hi, I am combining shale and tiles. When I navigate to my tiles definition /user_dashboard_view through my navigation-rule go_user_dashboard called by a commanLink action, I find that the backing beans of the respective tiles (/jsp/user_dashboard.jsp)are not instantiated. Or at least, the prerender() is not called. Any clues? Regards, Joost --Tiles.xml (partly)- template=/jsp/tiles/layouts/loggedLayout.jsp --faces-config.xml (partly)-- jsp$user_dashboard com.jsportal.projectportal.web.JSFaces.jsp.Dashboard naged-bean-class request * go_user_dashboard /user_dashboard_view go_user_profile /user_profile_view go_user_calendar /user_calendar_view go_search /search_view * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * This email with attachments is solely for the use of the individual or entity to whom it is addressed. Please also be aware that DnB NOR cannot accept any payment orders or other legally binding correspondence with customers as a part of an email. This email message has been virus checked by the anti virus programs used in the DnB NOR Group. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Re: [validator] conversion error while validating listbox component's value
From: Hasan Turksoy [EMAIL PROTECTED]
hi,
i have a problem about using commons-validator(CV) with selectmanylistbox of
my JSF pages'.. the problem is; CV trying to convert my listboxes' value(an
Array of objects) to string to make a required validation... And it throws
below exception;
javax.faces.ServletException: You have requested a conversion for type [
Lmy.app.CarType;, but there is no by-type converter registered for this
type
as you can understand from exception, it's trying to find a converter for
the array of my.app.CarType.. and couldn't find as expected...
however, instead of looking directly for a converter of the coming value's
type, ConverterHelper class should control the coming value's being
array/list condition and if so; traverse that array/list and convert each
element of it separately... In JSF RI, MenuRenderer class(
com.sun.faces.renderkit.html_basic.MenuRenderer) is working as this way
while converting coming array/list values to string or object...
what do you think about this issue... i think this is an issue (and may be i
should enter it on shale-JIRA)... But is there any other solution? or
anybody used required validator with h:selectManyListBox component?
The server-side required commons validator rule is kind of bogus. I've only
seen it useful
for client side validation. This is because JSF requires a value before it
will even invoke
the server side validation logic. A component's validator will not be invoked
if the component doesn't have a value. There is a separate required
attribute for components that are EditableValueHolders.
The shale ValidatorScript component, that must be added at the end of the page,
looks through the component tree and toggles on the required attribute for
components that include the shale commons validator required server side rule.
So, the ValidatorScript component is needed even if you are only using sever
side rules.
my usage is as below;
h:selectManyListbox value=#{myPageCode.selectedCarTypesArray} ...
f:selectItems value=#{myPageCode.carTypesList}/f:selectItems
s:commonsvalidator type=required ... /
/h:selectManyListbox
regards,
hasan...
Gary
Re: [validator] conversion error while validating listbox component's value
From: Hasan Turksoy [EMAIL PROTECTED] i have implemented a workaround for this serverside required problem... shortly: if validatorscript sets the required attribute, as you say, JSF won't call my serverside validator when that field's value is empty... to overcome this, i've commented the validatorscript's required attribute setting code.. this means JSF can't see that field as required and not call any required validator for that field... So, how can we call serverside required validators? I've implemented an idea from myfaces wiki.. Implementation in short; i have developed an RequiredValidatorChecker component.. it traverses all the component tree and calls validate methods for found required validators... i have entered a blog about this solution... So, you can think that serverside required validations are being called when needed... In fact, the problem is ConverterHelper can not handle array/list types in current situation... although i can't think of any such scenario, somehow a validation may be necessary to validate an array/list value.. so, how should it work in this case? (May be such a scenario is not possible ;) ) Shale Clay has an example of using a converter for string arrays[1][2]. I don't understand your problem with the validators. I think I would have tried using the immediate flag on the commands to stop short of validation. Or, looked at one of tomahawk or trinidad's subform components but you might have a complex layout that won't let you do that. Sounds like your doing some creating stuff with the validator. [1] http://svn.apache.org/viewvc/shale/framework/trunk/shale-clay/src/main/java/org/apache/shale/clay/convert/StringArrayConverter.java?view=markup [2] http://svn.apache.org/viewvc/shale/framework/trunk/shale-clay/src/main/resources/META-INF/faces-config.xml?view=markup Hasan... On 3/16/07, Gary VanMatre wrote: The server-side required commons validator rule is kind of bogus. I've only seen it useful for client side validation. This is because JSF requires a value before it will even invoke the server side validation logic. A component's validator will not be invoked if the component doesn't have a value. There is a separate required attribute for components that are EditableValueHolders. The shale ValidatorScript component, that must be added at the end of the page, looks through the component tree and toggles on the required attribute for components that include the shale commons validator required server side rule. So, the ValidatorScript component is needed even if you are only using sever side rules. Gary
Re: Strange behavior from a tags when using Clay HTML templates
From: Richard Eggert [EMAIL PROTECTED] I'm having an issue using anchor () tags that are explicitly mapped to h:commandLink (implicitly mapped tags don't work at all in this case). Consider the following HTML template named bugTest.html loaded via an XML view named /bugTest.clay: html body form a href=some-other-page.html jsfid=h:commandLink action=/some-other-view.clay Go here /a /form /body /html When viewed offline in a web browser, this page works fine. However, when viewed online using Clay, the text within the link becomes some-other-page.html Go here instead of just Go here, and clicking on the link just causes the page to reload. Is this a bug, or am I doing something wrong? There doesn't seem to be any valid reason why the contents of the href attribute should be moved to be nested within the tag, or why the action attribute shouldn't propagate to the commandLink component. Yeah, I think this is a bug. What I think is going on here is that the implicit mapping is overriding the commandLink's value [1]. What I mean is that the anchored tag is mapped to the outputLink by default. We should check to see if there is an action symbol override before using the href. Or, just look at the componentType after the jsfid overrides to make sure it's an outputLink. The outputLink puts the href in the components value attribute where a commandLink puts the text in the value attribute. Please create a JIRA ticket for this one. [1] http://svn.apache.org/viewvc/shale/framework/trunk/shale-clay/src/main/java/org/apache/shale/clay/parser/builder/OutputLinkBuilder.java?view=markup Rich Eggert Member of Technical Staff Proteus Technologies, LLC http://www.proteus-technologies.com Gary
[ANNOUNCEMENT] New Shale Committer: Hermod Opstvedt
Please join me in welcoming Hermod Opstvedt as a new Shale committer. Hermod has been a very active supporter of Shale over the past year. Besides speaking Norwegian and English, he also speaks Maven. His recent contributions includes the clay2tld tool with a maven plug-in and the new shale-clay-starter-archetype. Welcome aboard, Hermod! Gary
RE: Clay templating
From: Bernhard Slominski [EMAIL PROTECTED] -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] I'll try to give you some more background. There are three types of clay templates. !-- Clay HTML View Suffix (default .html) -- context-param param-name org.apache.shale.clay.XML_TEMPLATE_SUFFIX /param-name param-value.fhtml/param-value /context-param Html templates use and extend common elements. This type of template can be a fragment or the entire page. If the template is the entry point to the page, it must be a physical resource meaning that it can't be a pseudo tiles like resource that doesn't exist. * The next type of template are what we call full XML views. For this type of template, the page entry point is a clay XML configuration definition. The default suffix of a full XML view is .xml but can be changed using a web.xml context param. !-- Clay XML View Suffix (default .xml) -- context-param param-name org.apache.shale.clay.XML_TEMPLATE_SUFFIX /param-name param-value.html/param-value /context-param !-- Clay Configuration Full XML view Resources -- context-param param-name org.apache.shale.clay.FULLXML_CONFIG_FILES /param-name param-value/WEB-INF/clay-tiles-config.xml/param-value /context-param This option is similar to Tiles. The page entry point is not a physical resource but a metadata definition. Gary, thanks a lot for the answer. This is nearly a full blonw tutorial you gave me here. I was trying it out and it's working fine. So I use one configuration file /WEB-INF/clay-config.xml for both my common and my full XML view resources. Interesting, I've not tried using the same file for both handlers but I don't see why it wouldn't work. !-- Clay Common Configuration Resources -- context-param param-name org.apache.shale.clay.COMMON_CONFIG_FILES /param-name param-value /WEB-INF/clay-config.xml /param-value /context-param !-- Clay Configuration Full XML view Resources -- context-param param-name org.apache.shale.clay.FULLXML_CONFIG_FILES /param-name param-value /WEB-INF/clay-config.xml /param-value /context-param The former start.html is replaced by an entry in the jsfid in my component defintion. component jsfid=/start.xml extends=basePage symbols set name=@title value=Application Home / set name=@bodycontent value=/startBody.html / /symbols /component One small thing, I guess it's a typing or copy and paste error. You metioned the same context parameter for the HTML views and for the full XML views, I guess the HTML view parameter is wrong. But in the turtorial I couldn't find the name of the context parameter of the HTML view suffix. What is it? !-- Clay HTML View Suffix (default .html) -- context-param param-name org.apache.shale.clay.XML_TEMPLATE_SUFFIX /param-name param-value.fhtml/param-value /context-param Sorry about that. The two params are very similar. context-param param-name org.apache.shale.clay.HTML_TEMPLATE_SUFFIX /param-name param-value.fhtml/param-value /context-param Bernhard Gary
RE: Client-id : _id0 is duplicated in the faces tree.
From: Richard Eggert [EMAIL PROTECTED] Thanks for the explanation! I've reported it as SHALE-418. Is there a workaround, or do I just have to wait until I'm able to upgrade to MyFaces 1.1.4 (which won't be until late next week at the earliest)? Unfortunately, I can't think of a workaround other than using clay 1.0.3. http://shale.apache.org/docs/release-notes-1.0.3.html http://shale.apache.org/docs/release-notes-1.0.4.html I'll try to get to this one this weekend... Rich Eggert Member of Technical Staff Proteus Technologies, LLC http://www.proteus-technologies.com Gary -Original Message- From: Gary VanMatre [mailto:[EMAIL PROTECTED] Sent: Wed 2/28/2007 9:45 PM To: user@shale.apache.org Subject: Re: Client-id : _id0 is duplicated in the faces tree. From: Richard Eggert I'm running into a problem using Xml views using HTML templates. Loading a page initially works fine, but if I reload the page either by clicking on a link or hitting Refresh, I get the following error. java.lang.IllegalStateException: Client-id : _id0 is duplicated in the faces tree. at org.apache.myfaces.application.jsp.JspStateManagerImpl.checkForDuplicateIds(JspS tateManagerImpl.java:241) at org.apache.myfaces.application.jsp.JspStateManagerImpl.checkForDuplicateIds(JspS tateManagerImpl.java:255) (the above line is repeated several times) at org.apache.myfaces.application.jsp.JspStateManagerImpl.savedSerializedView(JspSt ateManagerImpl.java:204) at org.apache.shale.clay.faces.ClayViewHandler.renderView(ClayViewHandler.java:418) ... The error goes away if I load the page again, and then comes back if I load the page again after that. I created a very simple test page to reproduce the problem: bugTest.html --- foo clay-views.xml (excerpt) (web.xml maps *.clay to the Faces servlet and the Shale application filter) I don't know if this is a bug in MyFaces (I'm using version 1.1.1), a bug in Clay, or if I'm doing something wrong, but I've never seen this problem before with my other (non-Clay-based) pages. Any ideas? Darn, I thought we had this one covered for all the releases but I must not have tested again with myfaces 1.1. There is some history with this issue. This has to do with how the view root generates component ids. For components that you don't explicitly assign a component id, there is a utility function on the view root to generate a unique Id. In the first versions of Myfaces and the RI, the internal sequence that generates the ids was always reset even after the view was restored. This is a significant because of components marked transient. Transient components do not save state in the view. The verbatim component is actual an outputText with the transient property tunned on. When the view is restored, we have to recreate transient components and these components will need generated component id's since this is just text. In the early version of clay, after the view was restored, we would generate, in sequence, component ids for all components including components that were restored because this counter was always reset. A clay html template contains allot of transient components because the entire template is defined using components (Thanks again to Manfred Klug who helped figure this all out). Interesting enough, making all the view represented by components is the same approach they took in JSF 1.2. The EG team determined that reseting the counter was a bug. The view root should restore the internal counter. Starting with version 1.1.2, myfaces changed the view roots to restore the counter. Clay Release 1.0.3 http://issues.apache.org/struts/browse/SHALE-195 The counter being reset made PPR or any changes to a restored component tree problematic. So, in JSF 1.2 they changed how component id's are generated. They are now generated by the the container for JSP tags implementing JspidConsumer (JSP 2.1). The JspidConsumer will always return the same id for a component. Most recently, changes were made in this area to allow Clay to work with JSF 1.2. Clay Release 1.0.4 http://issues.apache.org/struts/browse/SHALE-67 I thought that I had this covered for all releases but it sounds like it's an issue. Trying to play with all versions is challenge. I'd like to move the trunk to full JSF 1.2 support and leave the 1_0_X branch for JSF 1.1 flavors. There are features in JSF 1.2 that we can not support until we commit to the new EL API. Please create a JIRA issue on this one. Rich Eggert Member of Technical Staff Proteus Technologies, LLC http://www.proteus
Re: Client-id : _id0 is duplicated in the faces tree.
From: Ryan Wynn [EMAIL PROTECTED] Darn, I thought we had this one covered for all the releases but I must not have tested again with myfaces 1.1. There is some history with this issue. Gary, do you know if this bug is limited to a myfaces 1.1.1/ clay 1.0.4 combination. myfaces 1.1.1 + clay 1.0.3 does not seem to exhibit this bug for me. That sounds correct. The recent changes, in Clay 1.0.4, to make it JSF 1.2 friendly, caused the problem. Ryan Gary
RE: Client-id : _id0 is duplicated in the faces tree.
From: Nikish Parikh [EMAIL PROTECTED] In this case give explicit id or if you are generating component dynamically then generated that id with some dynamic logic. That's how clay handles it [1]. The trick is detecting the version and flavor of JSF to address specific behavior. The form state marker is also one of those things that fall outside of the specification [2]. [1] http://svn.apache.org/viewvc/shale/framework/trunk/shale-clay/src/main/java/org/apache/shale/clay/component/chain/CreateComponentCommand.java?view=markup [2] http://svn.apache.org/viewvc/shale/framework/trunk/shale-clay/src/main/java/org/apache/shale/clay/faces/ClayViewHandler.java?view=markup -Original Message- From: Ryan Wynn [mailto:[EMAIL PROTECTED] Sent: Thursday, March 01, 2007 7:18 PM To: user@shale.apache.org Subject: Re: Client-id : _id0 is duplicated in the faces tree. Darn, I thought we had this one covered for all the releases but I must not have tested again with myfaces 1.1. There is some history with this issue. Gary, do you know if this bug is limited to a myfaces 1.1.1/ clay 1.0.4 combination. myfaces 1.1.1 + clay 1.0.3 does not seem to exhibit this bug for me. Ryan
Re: Client-id : _id0 is duplicated in the faces tree.
From: Richard Eggert [EMAIL PROTECTED] I'm running into a problem using Xml views using HTML templates. Loading a page initially works fine, but if I reload the page either by clicking on a link or hitting Refresh, I get the following error. java.lang.IllegalStateException: Client-id : _id0 is duplicated in the faces tree. at org.apache.myfaces.application.jsp.JspStateManagerImpl.checkForDuplicateIds(JspS tateManagerImpl.java:241) at org.apache.myfaces.application.jsp.JspStateManagerImpl.checkForDuplicateIds(JspS tateManagerImpl.java:255) (the above line is repeated several times) at org.apache.myfaces.application.jsp.JspStateManagerImpl.savedSerializedView(JspSt ateManagerImpl.java:204) at org.apache.shale.clay.faces.ClayViewHandler.renderView(ClayViewHandler.java:418) ... The error goes away if I load the page again, and then comes back if I load the page again after that. I created a very simple test page to reproduce the problem: bugTest.html --- !DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.01 Strict//EN html head titleTesting/title meta http-equiv=Content-Type content=text/html;charset=UTF-8 / meta http-equiv=pragma content=no-cache meta http-equiv=cache-control content=no-cache meta http-equiv=expires content=0 /head body foo /bod y /html clay-views.xml (excerpt) component jsfid=/bugTest.clay extends=clay attributes set name=clayJsfid value=/path/to/bugTest.html / /attributes /component (web.xml maps *.clay to the Faces servlet and the Shale application filter) I don't know if this is a bug in MyFaces (I'm using version 1.1.1), a bug in Clay, or if I'm doing something wrong, but I've never seen this problem before with my other (non-Clay-based) pages. Any ideas? Darn, I thought we had this one covered for all the releases but I must not have tested again with myfaces 1.1. There is some history with this issue. This has to do with how the view root generates component ids. For components that you don't explicitly assign a component id, there is a utility function on the view root to generate a unique Id. In the first versions of Myfaces and the RI, the internal sequence that generates the ids was always reset even after the view was restored. This is a significant because of components marked transient. Transient components do not save state in the view. The verbatim component is actual an outputText with the transient property tunned on. When the view is restored, we have to recreate transient components and these components will need generated component id's since this is just text. In the early version of clay, after the view was restored, we would generate, in sequence, component ids for all components including components that were restored because this counter was always reset. A clay html template contains allot of transient components because the entire template is defined using components (Thanks again to Manfred Klug who helped figure this all out). Interesting enough, making all the view represented by components is the same approach they took in JSF 1.2. The EG team determined that reseting the counter was a bug. The view root should restore the internal counter. Starting with version 1.1.2, myfaces changed the view roots to restore the counter. Clay Release 1.0.3 http://issues.apache.org/struts/browse/SHALE-195 The counter being reset made PPR or any changes to a restored component tree problematic. So, in JSF 1.2 they changed how component id's are generated. They are now generated by the the container for JSP tags implementing JspidConsumer (JSP 2.1). The JspidConsumer will always return the same id for a component. Most recently, changes were made in this area to allow Clay to work with JSF 1.2. Clay Release 1.0.4 http://issues.apache.org/struts/browse/SHALE-67 I thought that I had this covered for all releases but it sounds like it's an issue. Trying to play with all versions is challenge. I'd like to move the trunk to full JSF 1.2 support and leave the 1_0_X branch for JSF 1.1 flavors. There are features in JSF 1.2 that we can not support until we commit to the new EL API. Please create a JIRA issue on this one. Rich Eggert Member of Technical Staff Proteus Technologies, LLC http://www.proteus-technologies.com Gary
RE: Clay templating
From: Richard Eggert [EMAIL PROTECTED] This directly contradicts one of the things Hermod said in his email (that start.html doesn't have to exist), unless I misunderstood him. Now I'm really confused! Well, you could make the suffix mapping of full XML views to .html and then make the suffix mapping of full HTML views to .fhtml. They just can not be the same. I really wish we would have used other terms than full html and full xml... It's kind of misleading.. I would rather make the full xml view suffix something like .jsf. Hermod's archetype will generate a base project that uses full xml: views [1]. [1] https://svn.apache.org/viewvc/shale/sandbox/maven/archetypes/ Rich Eggert Member of Technical Staff Proteus Technologies, LLC http://www.proteus-technologies.com Gary -Original Message- From: Gary VanMatre [mailto:[EMAIL PROTECTED] Sent: Mon 2/26/2007 11:18 AM To: user@shale.apache.org Subject: Re: Clay templating Html templates use and extend common elements. This type of template can be a fragment or the entire page. If the template is the entry point to the page, it must be a physical resource meaning that it can't be a pseudo tiles like resource that doesn't exist.
RE: Weird error for full HTML views
From: Richard Eggert [EMAIL PROTECTED] I am using the ShaleApplicationFilter. I know it's being called, since it ShaleApplicationFilter.doFilter appears in the stack trace for the error that I'm getting. My chain-config.xml looks identical to the one from the clay-usecases example (minus the commented-out parts). I have a ChainListener configured and I have chain.CONFIG_WEB_RESOURCE pointing to /WEB-INF/chain-config.xml. Is it possible that the MyFaces ExtensionsFilter is somehow interfering with it? If so, is there any way to remedy it? Sorry, I was focusing on the wrong problem before. It look like this getContentType() method is only available in the servlet 2.4. http://java.sun.com/j2ee/1.4/docs/api/javax/servlet/ServletResponse.html#getContentType() Rich Eggert Member of Technical Staff Proteus Technologies, LLC http://www.proteus-technologies.com Gary -Original Message- From: Gary VanMatre [mailto:[EMAIL PROTECTED] Sent: Mon 2/26/2007 11:49 AM To: user@shale.apache.org Subject: Re: Weird error for full HTML views From: Richard Eggert I'm trying to get full HTML views working. I was able to get partial HTML views (using JSP to load the HTML template) working, but I keep getting the same weird error: The full html and full xml views are different animals. If you are using a full HTML view, it must be a physical file similar to JSP. The full XML views allow you to define a config definition as the page entry point but it requires a unique suffix. The default suffix is .html and .xml but can be changed in the web.xml java.lang.NoSuchMethodError: javax.servlet.http.HttpServletResponse.getContentType()Ljava/lang/String; at org.apache.shale.faces.ClayViewHandler.renderView(ClayViewHandler.java:385) ... The page I'm trying to load is named /htmlTest.foo and it exists only within my clay-views.xml. I've set FULLXML_CONFIG_FILES to /WEB-INF/clay-views.xml. I've set XML_TEMPLATE_SUFFIX to .foo. I have a filter-mapping for /* to point to the ShaleApplicationFilter that I set up. I have a servlet-mapping that maps *.foo to the Faces servlet. I have a mime-mapping that maps the foo extension to text/html. I have not modified javax.faces.DEFAULT_SUFFIX (i.e., I've left it as the default of .jsp), since I still have a lot of traditional JSP-based JSF pages (I did try changing it to .foo at one point, to no effect). I don't know if it's relevant, but I did notice the following lines in my log file (note the file extensions): org.apache.shale.clay.faces.ClayViewHandler:282 - Clay template restoreView for /htmlTest.jsp org.apache.shale.clay.faces.ClayViewHandler:366 - Clay template renderView for /htmlTest.jsp Does anyone have any idea of why I'm getting this error (or, more importantly, how to fix it)? JSF really only wants you to choose one type of templating. You can mix the three types but you need the shale-application library. What happens is JSF will normalize the view suffix to the javax.faces.DEFAULT_SUFFIX value. There is a preprocess command that is invoked from a filter that captures the view suffix before the normal processing of the viewId. The captured suffix overrides the default. This won't work in a portal environment and I've heard reports of it not working all the time. I covered this in more detail in a resonse to Bernhard's question [1]. The shale-clay-usecases trys to explain the problems too [2]. Unfortunately, you are better off if you choose a single JSF view entry point. [1] http://www.nabble.com/Clay-templating-tf3292202.html (should be here but I just posted the response) [2] https://svn.apache.org/viewvc/shale/framework/trunk/shale-apps/shale-clay-usecas es/src/main/webapp/usecases.jsp?view=markup Rich Eggert Member of Technical Staff Proteus Technologies, LLC http://www.proteus-technologies.com
Re: tomahawk-1_1_?-config.xml
From: Richard Eggert [EMAIL PROTECTED] This is probably a dumb question, but is there some way to get Shale to load the tomahawk-1_1_1-config.xml or tomahawk-1_1_3-config.xml file that comes bundeled in shale-clay-*.jar's META-INF, short of extracting the file and putting it in my own WEB-INF or pasting the contents into my own clay-config.xml? I don't see it mentioned anywhere in the examples. There is one example but it's in the sandbox [1]. You need to add classpath*: before the resource name. This works with html templates too. !-- Clay Common Configuration Resources -- context-param param-name org.apache.shale.clay.COMMON_CONFIG_FILES /param-name param-value /WEB-INF/clay-config.xml, classpath*:META-INF/tomahawk-1_1_3-config.xml /param-value /context-param [1] http://svn.apache.org/viewvc/shale/sandbox/shale-clay-mailreader/src/main/webapp/WEB-INF/web.xml?view=markup Rich Eggert Member of Technical Staff Proteus Technologies, LLC http://www.proteus-technologies.com Gary
RE: Weird error for full HTML views
From: Richard Eggert [EMAIL PROTECTED] Silly me. The reason it's throwing a NoSuchMethodError on HttpServletResponse.getContentType is that there is no getContentType method in HttpServletResponse - at least not in the ancient version of the Servlets API that I'm using! Man, I hate WebLogic 8.1. It was a mistake to use this method. I had hoped to make clay J2EE 1.3 compliant but I just missed that one. If you are stuck with 8.1, I'll try to find a work around if you create a JIRA ticket. Rich Eggert Member of Technical Staff Proteus Technologies, LLC http://www.proteus-technologies.com -Original Message- From: Richard Eggert [mailto:[EMAIL PROTECTED] Sent: Mon 2/26/2007 12:08 PM To: user@shale.apache.org Subject: RE: Weird error for full HTML views I am using the ShaleApplicationFilter. I know it's being called, since it ShaleApplicationFilter.doFilter appears in the stack trace for the error that I'm getting. My chain-config.xml looks identical to the one from the clay-usecases example (minus the commented-out parts). I have a ChainListener configured and I have chain.CONFIG_WEB_RESOURCE pointing to /WEB-INF/chain-config.xml. Is it possible that the MyFaces ExtensionsFilter is somehow interfering with it? If so, is there any way to remedy it? Rich Eggert Member of Technical Staff Proteus Technologies, LLC http://www.proteus-technologies.com -Original Message- From: Gary VanMatre [mailto:[EMAIL PROTECTED] Sent: Mon 2/26/2007 11:49 AM To: user@shale.apache.org Subject: Re: Weird error for full HTML views From: Richard Eggert I'm trying to get full HTML views working. I was able to get partial HTML views (using JSP to load the HTML template) working, but I keep getting the same weird error: The full html and full xml views are different animals. If you are using a full HTML view, it must be a physical file similar to JSP. The full XML views allow you to define a config definition as the page entry point but it requires a unique suffix. The default suffix is .html and .xml but can be changed in the web.xml java.lang.NoSuchMethodError: javax.servlet.http.HttpServletResponse.getContentType()Ljava/lang/String; at org.apache.shale.faces.ClayViewHandler.renderView(ClayViewHandler.java:385) ... The page I'm trying to load is named /htmlTest.foo and it exists only within my clay-views.xml. I've set FULLXML_CONFIG_FILES to /WEB-INF/clay-views.xml. I've set XML_TEMPLATE_SUFFIX to .foo. I have a filter-mapping for /* to point to the ShaleApplicationFilter that I set up. I have a servlet-mapping that maps *.foo to the Faces servlet. I have a mime-mapping that maps the foo extension to text/html. I have not modified javax.faces.DEFAULT_SUFFIX (i.e., I've left it as the default of .jsp), since I still have a lot of traditional JSP-based JSF pages (I did try changing it to .foo at one point, to no effect). I don't know if it's relevant, but I did notice the following lines in my log file (note the file extensions): org.apache.shale.clay.faces.ClayViewHandler:282 - Clay template restoreView for /htmlTest.jsp org.apache.shale.clay.faces.ClayViewHandler:366 - Clay template renderView for /htmlTest.jsp Does anyone have any idea of why I'm getting this error (or, more importantly, how to fix it)? JSF really only wants you to choose one type of templating. You can mix the three types but you need the shale-application library. What happens is JSF will normalize the view suffix to the javax.faces.DEFAULT_SUFFIX value. There is a preprocess command that is invoked from a filter that captures the view suffix before the normal processing of the viewId. The captured suffix overrides the default. This won't work in a portal environment and I've heard reports of it not working all the time. I covered this in more detail in a resonse to Bernhard's question [1]. The shale-clay-usecases trys to explain the problems too [2]. Unfortunately, you are better off if you choose a single JSF view entry point. [1] http://www.nabble.com/Clay-templating-tf3292202.html (should be here but I just posted the response) [2] https://svn.apache.org/viewvc/shale/framework/trunk/shale-apps/shale-clay-usecas es/src/main/webapp/usecases.jsp?view=markup Rich Eggert Member of Technical Staff Proteus Technologies, LLC http://www.proteus-technologies.com
Re: [shale-validator] CommonsValidator doesn't take component converters into account!
://www.jroller.com/hasant
Gary
On 2/23/07, Gary VanMatre wrote:
From: Hasan Turksoy
jsf-ri1.1 contains converter for javax.faces.DateTime class only...
not
for java.util.Date class you can download and look at
jsf-ri-config.xml...
in fact, this is not the main problem... i can overcome my issue by
adding a
converter for java.util.Date... But this doesn't solve the problem in
the
origin
Because; in JSF, one can add custom converter for each component
separately... in such a case, using my by-type java.util.Date converter
is
meaningless! because, user assigned a custom converter for that field!!
JSF
will use it instead of by-type converter... so, commons should use it
too...
now, when assigned custom validator for fields,, JSF RI and
CommonsValidator
behaving differently!!! this is not an acceptable situation! isn't it?
I agree it is not acceptable but they are not behaving differently. The
validator assigned to the component will be invoked before the
CommonsValidator is invoked.
to realize the problem... when returned to my sample in the previous
post;
suppose that i have a java.util.Date converter... and no custom
converter... in this case, CommonsValidator and JSF RI will work same..
both will use our by-type converter...
But, if i use a custom converter for my inputtext as below;
**
/
then, JSF RI will use this custom component converter to convert it's
value
but CommonsValidator will use our by-type java.util.Date converter...
different behaviours!!...
Not exactly, the java.util.Date converter is used by commons validator
to convert a Date object to a String (within the validator's validate
method). The custom converter assigned to the component (the same component
that is using commons validator), is being invoked prior to the call to
commons validator.
I'm not disagreeing that you have uncovered a bug that will be addressed
but what I'm saying is that Shales Commons Validator is using JSF
converters
as a utility [1] for converting from one data type to another. It does this
nonsense to provide a generic way (single converter that works for any
rule)
to invoke any custom validation rule that you might add.
I'll try to summarize with code:
// Validator's interface
public void validate(FacesContext context, UIComponent component, Object
value) {
..
Date obj = (Date) value; // value is already processed by the
components converter (String -- Date)
ConverterHelper converterHelper = new ConverterHelper();
// uses the a JSF converter Object to String
String objString = converterHelper.asString(context, obj.getClass(), obj);
boolean isValid = isDate(objString, datepattern);
[1]
http://svn.apache.org/viewvc/shale/framework/trunk/shale-core/src/main/java/org/
apache/shale/util/ConverterHelper.java?view=markup
In conclusion; when we look at JSF RI code, we see that; it first looks
for
custom component converter then, if can not find, searches for a by-type
converter... CommonsValidator must work same i think...
i have injected my solution into my CommonsValidator class and it works
perfect... above suggestion should be implemented in original
CommonsValidator releases as soon as possible i think...
I agree...
i can provide code if required...
regards..
hasan..
Gary
On 2/21/07, Gary VanMatre wrote:
From: Hasan Turksoy
hi all,
Env: jsf1.1, commons-validator1.3.1, shale1.0.4..
i'am trying to put a required validator for my date entering field..
My
field has a f:convertDateTime to make conversion between String -
java.util.Date. it's like;
server=true
/
When i entered a valid value into my date field it throws a
ConverterException as below;
javax.faces.ConverterException: You have requested a conversion for
type
java.util.Date, but there is no by-type converter registered for
this
type.
I'm not sure why you are seeing this exception. I belive that the
java.util.Data
converter should be registered with the JSF runtime.
Can you tell where the exception is being raised from the stack trace?
The reason for asking is that the shale commons validator uses JSF
converters to coerce data types to match the signatures of the server
side validation methods.
as i understand; it needs a converter for the java.util.Date class..
But
in
JSF, one can assign custom converter tags as above sample...
this means, (my suggestion) commonsvalidator should get the
converter
for
that type from
Re: why the arg argument is not early binding?
From: Hasan Turksoy [EMAIL PROTECTED]
is this code working with shale.1.0.4 version? can you verify it?
because, my code exactly same as above.. it's working with 1.0.2 version but
not with 1.0.4 version... there is no problem with my bundles.. because i
can see its value in a ... like:
I'll try to take a look at it tonight. Can you verify that the validator
example in the shale-usecases [1] is not working [2] ?
--- snippet ---
h:inputText id=creditCard
size=11
value=#{validate$test.creditCard}
val:commonsValidator
type=required
arg=#{messages['prompt.creditCardNumber']}
server=true
client=false/
val:commonsValidator
type=creditCard
arg=#{messages['prompt.creditCardNumber']}
server=true
client=false/
val:commonsValidator type=mask
mask=[4-6].*
message=#{messages['validate.test.unknown.credit.card.type']}
server=false
client=true/
/h:inputText
--- snippet ---
[1] http://people.apache.org/builds/shale/nightly/examples/
[2]
http://svn.apache.org/viewvc/shale/framework/trunk/shale-apps/shale-usecases/src/main/webapp/validator/test.jsp?view=markup
hasan...
Gary
On 2/23/07, Gary VanMatre wrote:
From: Hasan Turksoy
this is not a dynamically changing value.. it is simply
internationalization!... instead of hard coding the field's name, i am
binding it to my bundle.. so that i can internationalize my app by using
bundles for my all messages, labels, field names, etc...
I see, then there should not be a problem. The following should work as
expected as long as there is a properties file supporting the locale.
hasan...
Gary
On 2/23/07, Gary VanMatre wrote:
From: Hasan Turksoy
hi all,
commonsvalidator's arg argument used as the first argument of
messages
at
validator-rules.xml... in my application, i'm using those arg
arguments to
hold some info(in general field's name) about my field which is
being
validated
it's like:
above code works as expected and gives appropriate validation
message if
that field is not valid (like: User Name is required.)
But, if i bind my arg argument to a key in my bundle, my message
is
being
as null is required... sample code is as below;
/
I dive into code and find the problem solution...
ValidatorTag class is
setting arg argument's value directly instead of evaluating the
expression
and putting the resulting value into it... Some of the arguments
(type,
message, client, server) are early binding at the tag class
but
not
arg argument...
shouldn't the arg argument set by early binding as above
attributes?
isn't
this an issue?
I'm curious as to why the value from the resouce bundle doesn't exist
at
the point the JSP tag is processed?
The reason for the late binding of the attributes is to handle the
case
where the component is in a dataTable and the validation arguments
need to
be changed for each row in the table.
I guess I just never thought there would be a usecase were someone
wanted
to dynamically change the name of an input field on a form. Is that
the
scenario you are talking about? Why do you need late binding on the
arg
property?
regards,
hasan..
http://www.jroller.com/page/hasant
Gary
Re: [shale-validator] CommonsValidator doesn't take component converters into account!
From: Matthias Wessendorf [EMAIL PROTECTED] On 2/22/07, Hasan Turksoy wrote: jsf-ri1.1 contains converter for javax.faces.DateTime class only... not for java.util.Date class you can download and look at jsf-ri-config.xml... in fact, this is not the main problem... i can overcome my issue by adding a converter for java.util.Date... But this doesn't solve the problem in the origin are you talking about this: javax.faces.DateTime javax.faces.convert.DateTimeConverter that is just the id... I think the -for-class is only there for simple converters like javax.faces.convert.FloatConverter Yeah, for some reason I was thinking that the RI already has a converter registered by type for the java.util.Date type. converter-for-classjava.util.Date/converter-for-class The shale commons validator uses the ConverterHelper [1] (uses JSF type converters) to convert the submitted value, after the components converter has already converted to a Date object, back to a String to match the commons validator methodParams. validator name=date classname=org.apache.shale.validator.CommonsValidator method=isDate methodParams=java.lang.String,java.lang.String msg=errors.date jsFunctionName=validateDate jsFunction=org.apache.commons.validator.javascript.validateDate depends=/ [1] http://svn.apache.org/viewvc/shale/framework/trunk/shale-core/src/main/java/org/apache/shale/util/ConverterHelper.java?view=markup -M Gary Because; in JSF, one can add custom converter for each component separately... in such a case, using my by-type java.util.Date converter is meaningless! because, user assigned a custom converter for that field!! JSF will use it instead of by-type converter... so, commons should use it too... now, when assigned custom validator for fields,, JSF RI and CommonsValidator behaving differently!!! this is not an acceptable situation! isn't it? to realize the problem... when returned to my sample in the previous post; suppose that i have a java.util.Date converter... and no custom converter... in this case, CommonsValidator and JSF RI will work same.. both will use our by-type converter... But, if i use a custom converter for my inputtext as below; ** / then, JSF RI will use this custom component converter to convert it's value but CommonsValidator will use our by-type java.util.Date converter... different behaviours!!... In conclusion; when we look at JSF RI code, we see that; it first looks for custom component converter then, if can not find, searches for a by-type converter... CommonsValidator must work same i think... i have injected my solution into my CommonsValidator class and it works perfect... above suggestion should be implemented in original CommonsValidator releases as soon as possible i think... i can provide code if required... regards.. hasan.. On 2/21/07, Gary VanMatre wrote: From: Hasan Turksoy hi all, Env: jsf1.1, commons-validator1.3.1, shale1.0.4.. i'am trying to put a required validator for my date entering field.. My field has a f:convertDateTime to make conversion between String - java.util.Date. it's like; server=true / When i entered a valid value into my date field it throws a ConverterException as below; javax.faces.ConverterException: You have requested a conversion for type java.util.Date, but there is no by-type converter registered for this type. I'm not sure why you are seeing this exception. I belive that the java.util.Data converter should be registered with the JSF runtime. Can you tell where the exception is being raised from the stack trace? The reason for asking is that the shale commons validator uses JSF converters to coerce data types to match the signatures of the server side validation methods. as i understand; it needs a converter for the java.util.Date class.. But in JSF, one can assign custom converter tags as above sample... this means, (my suggestion) commonsvalidator should get the converter for that type from component. if component don't have any converters assigned, it should lookup for a by-type converter then... Otherwise, i will have to define by-type converters for all my component converters! this will be stupid i think... any comments?? or solutions?? What version of the JSF runtime are you using? This sounds like a rutime issue. thanks in advance, hasan.. Gary. -- Matthias Wessendorf
Re: [shale-validator] CommonsValidator doesn't take component converters into account!
From: Hasan Turksoy [EMAIL PROTECTED]
jsf-ri1.1 contains converter for javax.faces.DateTime class only... not
for java.util.Date class you can download and look at
jsf-ri-config.xml...
in fact, this is not the main problem... i can overcome my issue by adding a
converter for java.util.Date... But this doesn't solve the problem in the
origin
Because; in JSF, one can add custom converter for each component
separately... in such a case, using my by-type java.util.Date converter is
meaningless! because, user assigned a custom converter for that field!! JSF
will use it instead of by-type converter... so, commons should use it too...
now, when assigned custom validator for fields,, JSF RI and CommonsValidator
behaving differently!!! this is not an acceptable situation! isn't it?
I agree it is not acceptable but they are not behaving differently. The
validator assigned to the component will be invoked before the CommonsValidator
is invoked.
to realize the problem... when returned to my sample in the previous post;
suppose that i have a java.util.Date converter... and no custom
converter... in this case, CommonsValidator and JSF RI will work same..
both will use our by-type converter...
But, if i use a custom converter for my inputtext as below;
**
/
then, JSF RI will use this custom component converter to convert it's value
but CommonsValidator will use our by-type java.util.Date converter...
different behaviours!!...
Not exactly, the java.util.Date converter is used by commons validator to
convert a Date object to a String (within the validator's validate method).
The custom converter assigned to the component (the same component that is
using commons validator), is being invoked prior to the call to commons
validator.
I'm not disagreeing that you have uncovered a bug that will be addressed but
what I'm saying is that Shales Commons Validator is using JSF converters as a
utility [1] for converting from one data type to another. It does this
nonsense to provide a generic way (single converter that works for any rule) to
invoke any custom validation rule that you might add.
I'll try to summarize with code:
// Validator's interface
public void validate(FacesContext context, UIComponent component, Object value)
{
..
Date obj = (Date) value;// value is already processed by the components
converter (String -- Date)
ConverterHelper converterHelper = new ConverterHelper();
// uses the a JSF converter Object to String
String objString = converterHelper.asString(context, obj.getClass(), obj);
boolean isValid = isDate(objString, datepattern);
[1]
http://svn.apache.org/viewvc/shale/framework/trunk/shale-core/src/main/java/org/apache/shale/util/ConverterHelper.java?view=markup
In conclusion; when we look at JSF RI code, we see that; it first looks for
custom component converter then, if can not find, searches for a by-type
converter... CommonsValidator must work same i think...
i have injected my solution into my CommonsValidator class and it works
perfect... above suggestion should be implemented in original
CommonsValidator releases as soon as possible i think...
I agree...
i can provide code if required...
regards..
hasan..
Gary
On 2/21/07, Gary VanMatre wrote:
From: Hasan Turksoy
hi all,
Env: jsf1.1, commons-validator1.3.1, shale1.0.4..
i'am trying to put a required validator for my date entering field.. My
field has a f:convertDateTime to make conversion between String -
java.util.Date. it's like;
server=true
/
When i entered a valid value into my date field it throws a
ConverterException as below;
javax.faces.ConverterException: You have requested a conversion for
type
java.util.Date, but there is no by-type converter registered for this
type.
I'm not sure why you are seeing this exception. I belive that the
java.util.Data
converter should be registered with the JSF runtime.
Can you tell where the exception is being raised from the stack trace?
The reason for asking is that the shale commons validator uses JSF
converters to coerce data types to match the signatures of the server
side validation methods.
as i understand; it needs a converter for the java.util.Date class.. But
in
JSF, one can assign custom converter tags as above sample...
this means, (my suggestion) commonsvalidator should get the converter
for
that type from component. if component don't have any converters
assigned,
it should lookup for a by-type converter then... Otherwise, i will have
to
define by-type converters for all my component converters! this will be
stupid i think...
any comments?? or solutions??
What version of the JSF runtime are you using? This sounds like a rutime
issue
Re: Relative paths Clay
From: Richard Eggert [EMAIL PROTECTED] I've run into a very basic problem using Clay that I'm not sure how to solve. Here's the setup: I have a JSP file (we'll call it page.jsp) that contains a single tag that points to an HTML template in a subdirectory (we'll call it /templates/blah/foo.html). The HTML template references an image file in a completely different directory (/images/bar.jpg). How do I get the image to display properly both when rendered by Clay and when just loaded as a mockup? When loaded through the JSP using Clay, the image file's relative path is images/bar.jpg. However, when the HTML is loaded directly with a browser either online or offline, the image file's relative path is instead ../../images/bar.jpg. Using the absolute path (/appName/images/bar.jpg) works for both forms of online viewing (via JSP and as mockup), but it doesn't work for offline viewing (since the absolute path then becomes /full/filesystem/path/to/appName/images/bar.jpg), and I'd also rather not hard-code my application's context root into my HTML. I thought of using a tag with jsfid=void, but that doesn't work, since only accepts full URL's and not relative paths. Does anyone know of a way around this? You might try something like this: component jsfid=imageBar extends=h:graphicImage attributes set name=url value=/images/bar.jpg/ /attributes /component img jsfid=imageBar src=/appName/images/bar.jpg/ Incidentally, the same issue arises with links to stylesheets. You would be better off looking for a component, but something like this might work too: component jsfid=mycssLink extends=clay:clayOut attributes set name=excapeXml value=false/ set name=value value=lt;link jsfid=quot;mycssLinkquot; type=quot;text/cssquot; rel=quot;stylesheetquot; id=quot;csslinkquot; href=quot;/mycss.cssquot; /gt;/ /attributes /component link jsfid=mycssLink type=text/css rel=stylesheet id=csslink href=/appName/images/mycss.css / Another option would be to use the comment blocks to remove the CSS used for developement. !-- ### clay:remove ### -- link type=text/css rel=stylesheet id=csslink href=/appName/images/mycss.css / !-- ### /clay:remove ### -- link type=text/css rel=stylesheet id=csslink href=/mycss.css / Rich Eggert Member of Technical Staff Proteus Technologies, LLC http://www.proteus-technologies.com Gary
Re: [shale-validator] CommonsValidator doesn't take component converters into account!
From: Hasan Turksoy [EMAIL PROTECTED] hi all, Env: jsf1.1, commons-validator1.3.1, shale1.0.4.. i'am trying to put a required validator for my date entering field.. My field has a f:convertDateTime to make conversion between String - java.util.Date. it's like; h:inputtext ... f:convertDateTime dateStyle=short / s:commonsvalidator type=required arg=... client=true server=true / /h:inputtext When i entered a valid value into my date field it throws a ConverterException as below; javax.faces.ConverterException: You have requested a conversion for type java.util.Date, but there is no by-type converter registered for this type. I'm not sure why you are seeing this exception. I belive that the java.util.Data converter should be registered with the JSF runtime. Can you tell where the exception is being raised from the stack trace? The reason for asking is that the shale commons validator uses JSF converters to coerce data types to match the signatures of the server side validation methods. as i understand; it needs a converter for the java.util.Date class.. But in JSF, one can assign custom converter tags as above sample... this means, (my suggestion) commonsvalidator should get the converter for that type from component. if component don't have any converters assigned, it should lookup for a by-type converter then... Otherwise, i will have to define by-type converters for all my component converters! this will be stupid i think... any comments?? or solutions?? What version of the JSF runtime are you using? This sounds like a rutime issue. thanks in advance, hasan.. Gary.
RE: Dynamically-selectable HTML templates
After playing with it some more, I figured out the answer to my question. :-)
The trick was to use the clay component (or a component derived from clay)
and pass the configurable parts to the clayJsfid attribute (instead of
trying
to pass them as part of the jsfid attribute directly), like so:
I'll try to explain the difference between the jsfid and the clayJsfid. The
clayJsfid attribute is only valid within a clay markup template. When a
template is parsed, it is loaded into a DOM like structure. Then the DOM is
processed looking for markup nodes that have a jsfid attribute. The jsfid
attribute binds the markup node to a backing component definition. So, the
parser needs to map the markup node to a clay component by jsfid. In a JSP
tag, we know that the backing component is a clay component by the use of the
JSP tag. The jsfid is assumed to be the root of the subtree under the clay
component. Used within a markup template, the clayJsfid defines the root of the
subtree but the jsfid is needed to identify that the stand-in is a clay
component.
In my JSP:
f:loadBundle basename=runtime var=runtime /
c:clay
id=testPage
jsfid=templateTestPage
c:symbol name=pageTitle value=Test of template /
c:symbol name=templatesPrefix value=#{runtime.templatesPrefix} /
c:symbol name=themeName value=#{runtime.themeName} /
/c:clay
In my clay-config.xml:
component jsfid=basePage extends=clay
attributes
set name=clayJsfid
value=@templatesPrefix/@themeName/html.html /
/attributes
/component
component jsfid=templateTestPage extends=basePage
symbols
set name=bodyTemplate
value=@templatesPrefix/@themeName/bodyTemplate.html /
/symbols
/component
In this case, I'm using a message bundle named runtime.properties to pass in
the
theme name, but presumably, one could use a managed bean in the same way to
obtain the theme name from user preferences.
That sounds like a good use. The symbols are evaluated before the property
values are passed to the component. The symbols are similar to Tiles but they
are pushed to the inner most definition where tiles symbols are not scoped the
same way (only one level).
That's one of the big reuse problems that I have with JSF using JSP. A view
fragment is bound to a managed bean using EL. Because of this, you are limited
to the context that the included view fragment can be used.
Using Clay symbols allows you to create a dictionary of reusable view
compositions.
Rich Eggert
Member of Technical Staff
Proteus Technologies, LLC
http://www.proteus-technologies.com
Gary
-Original Message-
From: Richard Eggert [mailto:[EMAIL PROTECTED]
Sent: Sat 2/17/2007 3:53 PM
To: user@shale.apache.org
Subject: Dynamically-selectable HTML templates
In an application I'm working on, I'm trying to implement a mechanism by
which
the exact HTML template file that is used for a given page is dependent upon
a
configurable (at a minimum, by the person deploying the application, but
ideally, in the profile of each user) parameter such that although the actual
information displayed by a given page remains the same, the layout and
formatting of the page may vary according to the site theme selected by the
site owner and/or user preferences. After doing some experimenting, I
discovered that expressions are not allowed in the jsfid attribute of the
clay
JSP tag. Is there some other way of implementing this? Is what I'm trying to
do even feasible with Clay?
Rich Eggert
Member of Technical Staff
Proteus Technologies, LLC
http://www.proteus-technologies.com
RE: Clay challange
From: [EMAIL PROTECTED]
Hi
Thanks, Ryan. This is what you get when you copy/paste and then go blind :)
(I
need to sit down and repeat to my self: DO NOT DO THIS! a thousand times)
You are not alone there. Hey Ryan, what's the status of that Eclipse 3.2 plug
in that you are trying to get IBM to donate?
Hermod
Gary
-Original Message-
From: Ryan Wynn [mailto:[EMAIL PROTECTED]
Sent: Tuesday, February 13, 2007 11:23 PM
To: user@shale.apache.org; [EMAIL PROTECTED]
Subject: Re: Clay challange
On 2/13/07, Hermod Opstvedt wrote:
Hi
I'm struggling with a component that I have defined:
value=#{messages['navnpanel.text']}
value=#{messages['navnpanel.text']}
It is supposed to render a fieldset with a legend, and a label inside it.
However the label never appears and there are no errors what so ever.
I think you might need to look at your renderIds. The renderId
attribute is a way of ordering component children. RenderIds are only
relevant for sibling elements. If you have 2 sibling elements with
the same renderId value then one of the elements will be
lost/replaced.
In your case the t:htmlTag and outputLabel both have the same parent
(t:htmlTag) but they also use the same renderId (2). They should
instead be 1 and 2.
My renderIds usually start at 1 for each element set and increment
from there. I think only the relative values matter, so you could
have renderIds 6 and 3 and you would still get 2 children with the 3
renderId as the first child.
With inheritance you are able to override a component's children
selectively by specifying another component with the same renderId.
...
...
..
both c1 and c2 produce a clay component with 2 children. c2 uses
inheritance and the renderId attribute to override the second
outputText in c1 with an inputText. But, c2 still inherits the first
outputText child from c1.
Hope this helps.
Hermod
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
This email with attachments is solely for the use of the individual or
entity to whom it is addressed. Please also be aware that DnB NOR cannot
accept any payment orders or other legally binding correspondence with
customers as a part of an email.
This email message has been virus checked by the anti virus programs used
in the DnB NOR Group.
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
RE: Strange Behavior with inputTextarea component
From: [EMAIL PROTECTED] Hi The magic is a missing attribute: allowBody form textarea jsfid=textAreaTest allowBody=false This is a mockup./textarea /form You can also use another Clay functionality Or, you can put this attribute in the XML config. component jsfid=textAreaTest extends=inputTextarea id=textAreaTest allowBody=false attributes set name=value value=Test was successful. / /attributes /component This was David Geary's idea originally. I guess Tapestry has a similar concept. In the future, I'd like to provide a annotation replacement for this XML stuff. After all, we need to keep up with Tapestry 5. form textarea jsfid=textAreaTest !-- ### clay:remove ### -- This is a mockup. !-- ### /clay:remove ### -- /textarea /form Hermod snippet/ From: Richard Eggert [mailto:[EMAIL PROTECTED] Sent: Monday, February 12, 2007 3:55 AM To: user@shale.apache.org Subject: Strange Behavior with inputTextarea component I've been trying to teach myself how to use Clay (despite the atrocious lack of available documentation). Well, I've been lobbying for some time for David to do some more writing on Clay. The top half of the Clay site documentation was written by David. I guess he's busy making money or something? Anyway, *hopefully* the new Shale in Action book will have some material on Clay. In the process of doing this, I put together a very simple hello world style application. However, the behavior is not as expected, and I'm not sure whether I'm doing something wrong or there's an actual bug in Clay. BTW, Hermod, thanks for all your help! Gary
Re: stack traces from shale-clay-usecases
On 2/2/07, Gary VanMatre [EMAIL PROTECTED] wrote: I was able to run the shale-clay-usecases in 10g (10.1.3.1.1) from JDeveloper Studio 10.1.3.2 but I had to make a few minor changes. For some reason, JDeveloper doesn't like that the shale-core and shale-validator jars have TLD files with the name taglib.tld? I renamed the TLD's and it was happy? I pulled down the trinidad maven plugin to build the JDeveloper project file and ran from the IDE. I had to include the JSP Runtime libraries too. I'm not sure if that's what you are seeing? It's weird that taglib.tld trips it up? Ignore the previous empty response -- that's what you get when you pet a cat who is pawing your mouse at that moment :-). That's one confused cat (wrong kind mouse). It would definitely be wierd, but I can kind of sympathize with how someone writing the server side could make a naive assumption that these resource names are unique. At any rate, I'd be fine with making all of our META-INF/xxx.tld resource names unique. After all, it won't affect any users because they should not (can not?) make any direct references to these things. I did some more research and it turns out that it's a problem with the Trinidad JDeveloper maven plugin. It has to copy the TLD's into the WEB-INF folder. Seems like this requirement is kind of old school but apparently necessary. Even though my hit ratio on the myfaces patches isn't good, I went ahead and gave it a go [1]. [1] https://issues.apache.org/jira/browse/ADFFACES-372 Gary Craig Gary
Re: stack traces from shale-clay-usecases
I was able to run the shale-clay-usecases in 10g (10.1.3.1.1) from JDeveloper Studio 10.1.3.2 but I had to make a few minor changes. For some reason, JDeveloper doesn't like that the shale-core and shale-validator jars have TLD files with the name taglib.tld? I renamed the TLD's and it was happy? I pulled down the trinidad maven plugin to build the JDeveloper project file and ran from the IDE. I had to include the JSP Runtime libraries too. I'm not sure if that's what you are seeing? It's weird that taglib.tld trips it up? Gary -- Original message -- From: John Carlson [EMAIL PROTECTED] I got a couple of stacktraces from the shale-clay-usecases using OC4J 10.1.3.1 (supposedly supports J2EE 1.4). I deployed the shale-clay-usecases.war and tried to use the rolodex use cases. None of the rolodex cases work, although the first use case page does work. Here are the 2 different kinds of stack traces I got. This is on Windows XP service pack 2. 500 Internal Server Error java.lang.NullPointerException at org.apache.shale.validator.CommonsValidator.getValidatorAction(CommonsValidator.java:739) at org.apache.shale.validator.faces.ValidatorScript.findCommonsValidators(ValidatorScript.java:260) at org.apache.shale.validator.faces.ValidatorScript.findCommonsValidators(ValidatorScript.java:301) at org.apache.shale.validator.faces.ValidatorScript.findCommonsValidators(ValidatorScript.java:301) at org.apache.shale.validator.faces.ValidatorScript.findCommonsValidators(ValidatorScript.java:301) at org.apache.shale.validator.faces.ValidatorScript.findCommonsValidators(ValidatorScript.java:301) at org.apache.shale.validator.faces.ValidatorScript.encodeBegin(ValidatorScript.java:649) at org.apache.shale.clay.component.Clay.recursiveRenderChildren(Clay.java:413) at org.apache.shale.clay.component.Clay.recursiveRenderChildren(Clay.java:416) at org.apache.shale.clay.component.Clay.encodeChildren(Clay.java:445) at org.apache.shale.clay.faces.ClayViewHandler.recursiveRender(ClayViewHandler.java:476) at org.apache.shale.clay.faces.ClayViewHandler.renderView(ClayViewHandler.java:402) at org.apache.shale.validator.faces.ValidatorViewHandler.renderView(ValidatorViewHandler.java:130) at org.apache.shale.view.faces.ViewViewHandler.renderView(ViewViewHandler.java:147) at org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:384) at javax.faces.webapp.FacesServlet.service(FacesServlet.java:138) at com.evermind[Oracle Containers for J2EE 10g (10.1.3.1.0) ].server.http.ResourceFilterChain.doFilter(ResourceFilterChain.java:64) at org.apache.shale.application.faces.ShaleApplicationFilter.doFilter(ShaleApplicationFilter.java:267) at com.evermind[Oracle Containers for J2EE 10g (10.1.3.1.0) ].server.http.ServletRequestDispatcher.invoke(ServletRequestDispatcher.java:621) at com.evermind[Oracle Containers for J2EE 10g (10.1.3.1.0) ].server.http.ServletRequestDispatcher.forwardInternal(ServletRequestDispatcher.java:368) at com.evermind[Oracle Containers for J2EE 10g (10.1.3.1.0) ].server.http.HttpRequestHandler.doProcessRequest(HttpRequestHandler.java:866) at com.evermind[Oracle Containers for J2EE 10g (10.1.3.1.0) ].server.http.HttpRequestHandler.processRequest(HttpRequestHandler.java:448) at com.evermind[Oracle Containers for J2EE 10g (10.1.3.1.0) ].server.http.HttpRequestHandler.serveOneRequest(HttpRequestHandler.java:216) at com.evermind[Oracle Containers for J2EE 10g (10.1.3.1.0) ].server.http.HttpRequestHandler.run(HttpRequestHandler.java:117) at com.evermind[Oracle Containers for J2EE 10g (10.1.3.1.0) ].server.http.HttpRequestHandler.run(HttpRequestHandler.java:110) at oracle.oc4j.network.ServerSocketReadHandler$SafeRunnable.run(ServerSocketReadHandler.java:260) at com.evermind[Oracle Containers for J2EE 10g (10.1.3.1.0) ].util.ReleasableResourcePooledExecutor$MyWorker.run(ReleasableResourcePooledExecutor.java:303) at java.lang.Thread.run(Thread.java:595) 500 Internal Server Error javax.faces.FacesException: javax.servlet.ServletException at org.apache.myfaces.context.servlet.ServletExternalContextImpl.dispatch(ServletExternalContextImpl.java:426) at org.apache.myfaces.application.jsp.JspViewHandlerImpl.renderView(JspViewHandlerImpl.java:234) at org.apache.shale.clay.faces.ClayViewHandler.renderView(ClayViewHandler.java:450) at org.apache.shale.validator.faces.ValidatorViewHandler.renderView(ValidatorViewHandler.java:130) at org.apache.shale.view.faces.ViewViewHandler.renderView(ViewViewHandler.java:147) at org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:384) at javax.faces.webapp.FacesServlet.service(FacesServlet.java:138) at com.evermind[Oracle Containers for J2EE
Re: RE : Re: Oracle ADF and Shale tiles/validator
From: Adrian Gonzalez [EMAIL PROTECTED] I've found the problem (using both Oracle ADF and some shale extensions doesn't work). It's in shale-validator and in shale-tiles (1.0.4 version). For info, I'm using adf-faces 10_1_3_0_4. To reproduce the problem with shale-validator, one just needs to put the shale-validator.jar in WEB-INF/lib. We don't need to use a validator explicitly in jsf page. To reproduce the problem with shale-tiles, one needs to put the shale-tiles.jar in WEB-INF/lib AND to call jsf page through a tile definition. I've done some debugging with shale-validator. The problem with this validator is that it changes the current renderKit (see org.apache.shale.validator.faces.setupRenderKit). I've just commented the setupRenderKit method implementation and the JSF page displays fine. Can we change something in order to use ADF with those Shale extensions ? I don't know if the two will work together. The ADF component library takes advantage of about every JSF extension point. I'm making this statement based on reviewing Trinidad's code. Both ADF and Shale Validator use a custom RenderKit. In Shale Validator's case, it decorates the original so that it can decorate renderers. This is needed because Shale is not a widget library and we are not interested in build a suite of components from the ground up as you will see with ADF. This trick allows us to modify a renderers behavior without rewritting every renderer that is a Input or Command component. If the registration of shale validator's faces-config is prior to ADF, there might be a chance to make it work however I'm doubtful. Assuming that ADF has the same validator support as Trinidad, you might rather look at their's which is couple with their components and provides client side validation. tr:validateRegExp - Validate expression using java regular expression syntax. tr:validateLongRange - Validate that the date entered is within a given range. tr:validateLength - Validate that the date entered is within a given range. tr:validateDoubleRange - Validate that the date entered is within a given range. tr:validateDateTimeRange - Validate that the date entered is within a given range. tr:validateDateRestriction - Validate that the date entered is within a given restriction. tr:validateByteLength - Validate the byte length of strings when encoded. Thanks Gary ___ Découvrez une nouvelle façon d'obtenir des réponses à toutes vos questions ! Profitez des connaissances, des opinions et des expériences des internautes sur Yahoo! Questions/Réponses http://fr.answers.yahoo.com
Re: Re : RE : Re: Oracle ADF and Shale tiles/validator
From: Adrian Gonzalez [EMAIL PROTECTED] Thank you very much Gary for this information, I'll try ADF validators instead of Shale's. Do you have similar info about Shale tiles and ADF ? Do you know if ADF (or Trinidad) has a feature similar as Tiles composition ? I've not tried Shale Tiles with ADF but I suspect the two won't play nicely together. Many will also tell you not to use JSP with JSF 1.1 due to the verbatim issue. However, Tiles/JSF 1.2 and JSP might workout since the verbatim issue is fixed but I have not heard from anyone who's tried it either. Perhaps the information about incompatibility between shale tiles/validator and ADF (and perhaps Trinidad) should be usefull for other newbies (in a wiki ?). I agree, please add it to the wiki when you have time. Gary - Message d'origine De : Gary VanMatre À : user@shale.apache.org Envoyé le : Mercredi, 31 Janvier 2007, 17h47mn 08s Objet : Re: RE : Re: Oracle ADF and Shale tiles/validator From: Adrian Gonzalez I've found the problem (using both Oracle ADF and some shale extensions doesn't work). It's in shale-validator and in shale-tiles (1.0.4 version). For info, I'm using adf-faces 10_1_3_0_4. To reproduce the problem with shale-validator, one just needs to put the shale-validator.jar in WEB-INF/lib. We don't need to use a validator explicitly in jsf page. To reproduce the problem with shale-tiles, one needs to put the shale-tiles.jar in WEB-INF/lib AND to call jsf page through a tile definition. I've done some debugging with shale-validator. The problem with this validator is that it changes the current renderKit (see org.apache.shale.validator.faces.setupRenderKit). I've just commented the setupRenderKit method implementation and the JSF page displays fine. Can we change something in order to use ADF with those Shale extensions ? I don't know if the two will work together. The ADF component library takes advantage of about every JSF extension point. I'm making this statement based on reviewing Trinidad's code. Both ADF and Shale Validator use a custom RenderKit. In Shale Validator's case, it decorates the original so that it can decorate renderers. This is needed because Shale is not a widget library and we are not interested in build a suite of components from the ground up as you will see with ADF. This trick allows us to modify a renderers behavior without rewritting every renderer that is a Input or Command component. If the registration of shale validator's faces-config is prior to ADF, there might be a chance to make it work however I'm doubtful. Assuming that ADF has the same validator support as Trinidad, you might rather look at their's which is couple with their components and provides client side validation. tr:validateRegExp - Validate expression using java regular expression syntax. tr:validateLongRange - Validate that the date entered is within a given range. tr:validateLength - Validate that the date entered is within a given range. tr:validateDoubleRange - Validate that the date entered is within a given range. tr:validateDateTimeRange - Validate that the date entered is within a given range. tr:validateDateRestriction - Validate that the date entered is within a given restriction. tr:validateByteLength - Validate the byte length of strings when encoded. Thanks Gary ___ Découvrez une nouvelle façon d'obtenir des réponses à toutes vos questions ! Profitez des connaissances, des opinions et des expériences des internautes sur Yahoo! Questions/Réponses http://fr.answers.yahoo.com ___ Découvrez une nouvelle façon d'obtenir des réponses à toutes vos questions ! Profitez des connaissances, des opinions et des expériences des internautes sur Yahoo! Questions/Réponses http://fr.answers.yahoo.com
RE: setting rowStyleClass
From: Ian.Priest [EMAIL PROTECTED] See https://issues.apache.org/jira/browse/TOMAHAWK-523 for problem and work-around. Hey, what do you know, facelets has the same problem :--). Thanks for reporting the work around. Cheers, Ian. Gary -Original Message- From: Ian.Priest [mailto:[EMAIL PROTECTED] Sent: 26 January 2007 15:30 To: user@shale.apache.org Subject: setting rowStyleClass Hi, I seem to have an error when setting the rowStyleClass attribute of a table. I'm trying to set the row class dynamically so I can have certain rows highlighted based on a bean variable. Here's my widget, which extends MyFaces Tomahawk DataTable: allowBody=false value=[EMAIL PROTECTED] / ... But no class at all is set in the rendered table. Viewing page source of the final page gives: ... ... ... If I try to set a rowStyleClass in my html as follows (I also remove the ref to rowStyleClass in the widget): All I get is an empty class declaration in my tag: ... Has anyone managed to get this working? Cheers, Ian.
