RE: Broken URL's
You need to add something like this to your web.xml file: jsp-config taglib taglib-urihttp://shale.apache.org/clay/taglib-uri taglib-location/WEB-INF/lib/shale-clay.jar/taglib-location /taglib /jsp-config If that doesn't work (i.e., if the JSP engine can't find the tld file within the JAR file for some reason), pull the TLD file out of the JAR file, place it somewhere in your WEB-INF directory (perhaps in a subdirectory named tld, for example), and put this in your web.xml instead: jsp-config taglib taglib-urihttp://shale.apache.org/clay/taglib-uri taglib-location/WEB-INF/tld/shale-clay.tld/taglib-location /taglib /jsp-config Note that if you are using more than one tag library, each tag library that you use needs its own taglib entry, and all taglib elements must be contained within a single jsp-config (the XML schema validator will reject it if you have more than one jsp-config). As was already pointed out, the URI's are only unique names, and have no meaning in terms of where JSP looks for the definitions. Rich Eggert Member of Technical Staff Proteus Technologies, LLC http://www.proteus-technologies.com -Original Message- From: Cristi Magherusan [mailto:[EMAIL PROTECTED] Sent: Sun 5/11/2008 8:00 PM To: user@shale.apache.org Subject: Broken URL's Hello, I'm having a school project that must use shale, but it seems its taglibs uri's are broken links, among others. Please someone fix them, if possible. Also, is there a way to use local files instead of http:// links? Please use cc to send your answers to me since I'm not yet subscribed to the shale Mailing List. ?Thanks! Cristi
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: [Shale Clay]
This is just a shot in the dark, but have you tried wrapping the form (or the
whole page) in a tag that has jsfid=f:view?
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 3:34 PM
To: user@shale.apache.org
Subject: RE: [Shale Clay]
I tried it and didn't seem to make a difference; it doesn't invoke the
action. It's really weird; without the enctype attribute, it at least
invokes the action; I suspect on postback, JSF doesn't restore the view
correctly because if I change my javax.faces.STATE_SAVING_METHOD from
client to server, I see
~com.sun.faces.saveStateFieldMarker~
at the bottom of the page.
-Original Message-
From: Ryan Wynn [mailto:[EMAIL PROTECTED]
Sent: Friday, April 11, 2008 3:12 PM
To: user@shale.apache.org
Subject: Re: [Shale Clay]
On Fri, Apr 11, 2008 at 2:50 PM, Zheng, Xiahong [EMAIL PROTECTED]
wrote:
I thought about this, but tomahawk doesn't seem to have a form
component.
-Original Message-
From: Gary VanMatre [mailto:[EMAIL PROTECTED]
Sent: Friday, April 11, 2008 1:35 PM
To: user@shale.apache.org
Subject: 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?
Can you try this?
component jsfid=multipart-form extends=form
attributes
set name=enctype value=multipart/form-data/
/attributes
/component
+
form jsfid=multipart-form/form
That seems to be working ok for me.
Ryan
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
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: Statistic
I'm not using Shale myself at the moment, but on my previous project (which another employee of my company has taken over), I used Clay, View Controller, Tiger Extensions, and the Test Framework. Rich Eggert Member of Technical Staff Proteus Technologies, LLC http://www.proteus-technologies.com -Original Message- From: samju [mailto:[EMAIL PROTECTED] Sent: Sat 2/2/2008 6:44 AM To: user@shale.apache.org Subject: Statistic I just want to check how many user, Companies, etc. are using Shale. thanks For your feedback in advance! Sam -- View this message in context: http://www.nabble.com/Statistic-tp15242062p15242062.html Sent from the Shale - User mailing list archive at Nabble.com.
RE: Statistic
I would imagine that most people on this mailing list are using it, or at least thinking about using it. It's difficult to determine who's using it that is not on this list, though. Rich Eggert Member of Technical Staff Proteus Technologies, LLC http://www.proteus-technologies.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Mon 2/4/2008 5:12 AM To: user@shale.apache.org Subject: RE: Statistic I'm using -Original Message- From: samju [mailto:[EMAIL PROTECTED] Sent: 2 febbraio 2008 12.45 To: user@shale.apache.org Subject: Statistic I just want to check how many user, Companies, etc. are using Shale. thanks For your feedback in advance! Sam -- View this message in context: http://www.nabble.com/Statistic-tp15242062p15242062.html Sent from the Shale - User mailing list archive at Nabble.com. 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: HtmlSelectOneMenu dynamically
Oh, that's easy. In JSF, you don't explictly mark a SelectItem as being
selected (unlike OPTION tags in HTML). Instead, you set the parent
SelectOne(Menu|Radio|Checkbox) element's value field (or, more specifically,
the value of the managed bean property to which value is bound). As long as
the value of the SelectOne matches the value of one of the SelectItems, that
SelectItem will be rendered as selected.
I believe what you need to do in your case is something like this:
AttributeBean valAttr = new AttributeBean();
valAttr.setName(value);
valAttr.setValue(#{someBean.someProperty});
selectElement.addAttribute(valAttr);
and then make sure that someBean initializes someProperty to a default
value that corresponds to one of your SelectItems.
Rich Eggert
Member of Technical Staff
Proteus Technologies, LLC
http://www.proteus-technologies.com
-Original Message-
From: Mike Otto [mailto:[EMAIL PROTECTED]
Sent: Tue 9/11/2007 8:29 AM
To: user@shale.apache.org
Subject: RE: HtmlSelectOneMenu dynamically
Hello Richard,
thanks for answering. Now I have a clue about what I should do ..
The code below works like a charm, except that I don't know how
to declare a item as selected. I looked up
javax.faces.component.UISelectItem.class
and found
private String _itemDescription = null;
private Boolean _itemDisabled = null;
private String _itemLabel = null;
private Object _itemValue = null;
private Object _value = null;
(no private Object _selected)
Besides I still do not have a solution for component type
javax.faces.SelectItem_s_ But I think with Items in singular
I have more control, right?
Regards Mike
// HTMLSelectOneMenu
ElementBean selectElement = new ElementBean();
selectElement.setComponentType(javax.faces.HtmlSelectOneMenu);
selectElement.setJsfid(securitycheck);
selectElement.setId(securitycheck);
ElementBean itemElement = new ElementBean();
itemElement.setComponentType(javax.faces.SelectItem);
itemElement.setJsfid(selectItem);
itemElement.setRenderId(generateId());
AttributeBean attr = new AttributeBean();
attr.setName(itemValue);
attr.setValue(value1);
itemElement.addAttribute(attr);
attr = new AttributeBean();
attr.setName(itemLabel);
attr.setValue(Label);
itemElement.addAttribute(attr);
selectElement.addChild(itemElement);
ElementBean itemElement2 = new ElementBean();
itemElement2.setComponentType(javax.faces.SelectItem);
itemElement2.setJsfid(selectItem2);
itemElement2.setRenderId(generateId());
attr = new AttributeBean();
attr.setName(itemValue);
attr.setValue(value2);
itemElement2.addAttribute(attr);
attr = new AttributeBean();
attr.setName(disabled);
attr.setValue(true);
itemElement2.addAttribute(attr);
attr = new AttributeBean();
attr.setName(selected); // fixme
attr.setValue(true);
itemElement2.addAttribute(attr);
selectElement.addChild(itemElement2);
root.addChild(selectElement);
Anomalies with @Prerender
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? Rich Eggert Member of Technical Staff Proteus Technologies, LLC http://www.proteus-technologies.com
RE: Clay not escaping strings?
See below.
-Original Message-
From: Gary VanMatre [mailto:[EMAIL PROTECTED]
Sent: Thu 8/9/2007 11:53 AM
To: user@shale.apache.org
Subject: Re: Clay not escaping strings?
pspan jsfid=outputText escape=true#{mybean.prop}/span/p).
Actually, this doesn't work. I still get the same error message, which I can
only assume is because Clay is internally nesting an f:verbatim (with
escape=false) within the h:outputText.
As I indicated in my other email, the only way to get this to work is to do
this :
span jsfid=outputText value=#{mybean.prop} allowBody=falseMockup value
here/span
(escape=true is unnecessary here since that is the default behavior of
outputText)
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.
Rich Eggert
Member of Technical Staff
Proteus Technologies, LLC
http://www.proteus-technologies.com
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 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. Rich Eggert Member of Technical Staff Proteus Technologies, LLC http://www.proteus-technologies.com
RE: Tomahawk's enabledOnUserRole attribute and Clay
That fixed the problem.
I've submitted JIRA ticket # SHALE-431.
Rich Eggert
Member of Technical Staff
Proteus Technologies, LLC
http://www.proteus-technologies.com
-Original Message-
From: Gary VanMatre [mailto:[EMAIL PROTECTED]
Sent: Tue 3/27/2007 11:05 AM
To: user@shale.apache.org
Subject: 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
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?
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
RE: Strange behavior from a tags when using Clay HTML templates
Okay, I've reported it as SHALE-426. Rich Eggert Member of Technical Staff Proteus Technologies, LLC http://www.proteus-technologies.com -Original Message- From: Gary VanMatre [mailto:[EMAIL PROTECTED] Sent: Wed 3/14/2007 9:56 PM To: user@shale.apache.org Subject: 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
Client-id : _id0 is duplicated in the faces tree.
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(JspStateManagerImpl.java:241) at org.apache.myfaces.application.jsp.JspStateManagerImpl.checkForDuplicateIds(JspStateManagerImpl.java:255) (the above line is repeated several times) at org.apache.myfaces.application.jsp.JspStateManagerImpl.savedSerializedView(JspStateManagerImpl.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 /body /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? Rich Eggert Member of Technical Staff Proteus Technologies, LLC http://www.proteus-technologies.com
RE: Client-id : _id0 is duplicated in the faces tree.
I did include bugTest.xml. Re-read my email please. :-) I'm hoping to upgrade to MyFaces 1.1.4 some time in the near future. Unfortunately, I don't have complete control over when that happens, so I'm stuck with 1.1.1 at least until next week. Rich Eggert Member of Technical Staff Proteus Technologies, LLC http://www.proteus-technologies.com -Original Message- From: Hermod Opstvedt [mailto:[EMAIL PROTECTED] Sent: Wed 2/28/2007 4:35 PM To: user@shale.apache.org Subject: SV: Client-id : _id0 is duplicated in the faces tree. Hi Could you also post bugtest.html. That is likely to be the origin of the Exception. Also I would move to at least MyFaces 1.3 to see if the problem persists. Hermod -Opprinnelig melding- Fra: Richard Eggert [mailto:[EMAIL PROTECTED] Sendt: 28. februar 2007 20:01 Til: user@shale.apache.org Emne: Client-id : _id0 is duplicated in the faces tree. 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( JspStateManagerImpl.java:241) at org.apache.myfaces.application.jsp.JspStateManagerImpl.checkForDuplicateIds( JspStateManagerImpl.java:255) (the above line is repeated several times) at org.apache.myfaces.application.jsp.JspStateManagerImpl.savedSerializedView(J spStateManagerImpl.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 /body /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? Rich Eggert Member of Technical Staff Proteus Technologies, LLC http://www.proteus-technologies.com
RE: Client-id : _id0 is duplicated in the faces tree.
Err... I mean bugTest.html, not .xml. :-) Rich Eggert Member of Technical Staff Proteus Technologies, LLC http://www.proteus-technologies.com -Original Message- From: Richard Eggert [mailto:[EMAIL PROTECTED] Sent: Wed 2/28/2007 5:55 PM To: user@shale.apache.org Subject: RE: Client-id : _id0 is duplicated in the faces tree. I did include bugTest.xml. Re-read my email please. :-) I'm hoping to upgrade to MyFaces 1.1.4 some time in the near future. Unfortunately, I don't have complete control over when that happens, so I'm stuck with 1.1.1 at least until next week. Rich Eggert Member of Technical Staff Proteus Technologies, LLC http://www.proteus-technologies.com -Original Message- From: Hermod Opstvedt [mailto:[EMAIL PROTECTED] Sent: Wed 2/28/2007 4:35 PM To: user@shale.apache.org Subject: SV: Client-id : _id0 is duplicated in the faces tree. Hi Could you also post bugtest.html. That is likely to be the origin of the Exception. Also I would move to at least MyFaces 1.3 to see if the problem persists. Hermod -Opprinnelig melding- Fra: Richard Eggert [mailto:[EMAIL PROTECTED] Sendt: 28. februar 2007 20:01 Til: user@shale.apache.org Emne: Client-id : _id0 is duplicated in the faces tree. 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( JspStateManagerImpl.java:241) at org.apache.myfaces.application.jsp.JspStateManagerImpl.checkForDuplicateIds( JspStateManagerImpl.java:255) (the above line is repeated several times) at org.apache.myfaces.application.jsp.JspStateManagerImpl.savedSerializedView(J spStateManagerImpl.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 /body /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? Rich Eggert Member of Technical Staff Proteus Technologies, LLC http://www.proteus-technologies.com
RE: Client-id : _id0 is duplicated in the faces tree.
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)? Rich Eggert Member of Technical Staff Proteus Technologies, LLC http://www.proteus-technologies.com -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 [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: Weird error for full HTML views
Yeah. Upgrading to WebLogic 9.2 fixed the problem. Thanks anyway, though. :-) 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 4:53 PM To: user@shale.apache.org Subject: 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
Ah! I figured it was something simple. Thanks! :-) By the way, as reported here (http://issues.apache.org/jira/browse/TOMAHAWK-313?rc=1page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel) there is a bug in Tomahawk 1.1.1 that causes a NullPointerException with t:jscookMenu if you don't explicitly set the itemValue property of every instance of t:navigationMenuItem. It's fixed in Tomahawk 1.1.3, but for the sake of those of us that don't have the luxury of deciding when things get upgraded on their systems, would it be possible to have value=0 added to the itemValue attribute of t:navigationMenuItem in tomahawk-1_1_1-config.xml, so that the component works by default? I'd hate for someone else to have to go through the headache I went through on Friday as I tried to figure out why jscookMenu wouldn't work for me. 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 4:57 PM To: user@shale.apache.org Subject: 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
Relative paths Clay
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 clay 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 base tag with jsfid=void, but that doesn't work, since base only accepts full URL's and not relative paths. Does anyone know of a way around this? Incidentally, the same issue arises with links to stylesheets. Rich Eggert Member of Technical Staff Proteus Technologies, LLC http://www.proteus-technologies.com
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:
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.
Rich Eggert
Member of Technical Staff
Proteus Technologies, LLC
http://www.proteus-technologies.com
-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: Strange Behavior with inputTextarea component
Thanks. That fixed the problem. What I actually ended up doing was this: component jsfid=myTextarea extends=inputTextarea id=myTextarea allowBody=false / component jsfid=textAreaTest extends=myTextarea id=textAreaTest attributes set name=value value=Test was successful. / /attributes /component This allows me to reuse the de-bodified textarea without any additional work. I'm not quite sure why this isn't the default behavior for inputTextarea, though. What possible reason could there be for someone to want to use the current default behavior (i.e., to have the body contents rendered AFTER the /textarea, such that it becomes regular text when rendered, whereas it is the contents of a textarea field during mockup)? If someone really wanted that to happen, they could write it that way in their original HTML. It seems like it would save a lot of people some extra work if inputTextArea were defined with allowBody=false set by default (still allowing allowBody=true to be manually set by those weirdos that really want that behavior). Anyway, thanks for your help! :-) 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/12/2007 11:28 AM To: user@shale.apache.org Subject: 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
