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]
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?
-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: [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: [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 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
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 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
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]
Yes, I am use JSF1.2 RI. It's been working for me (at least, the upload
part of tomahawk). I am getting the current problem when I added shale
in the mix.
-Original Message-
From: Gary VanMatre [mailto:[EMAIL PROTECTED]
Sent: Friday, April 11, 2008 4:15 PM
To: user@shale.apache.org
Subject: RE: [Shale Clay]
-- Original message --
From: Zheng, Xiahong [EMAIL PROTECTED]
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~
Sounds like you are using JSF 1.2 with tomahawk?
Gary
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
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]
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, Facelets and JSF Templating
Ransford, Just out of curiosity, why are you interested in using Clay, Facelets, and JSF Templatin in the same application, since they all solve the same problem? ~~~ Kito D. Mann - Author, JavaServer Faces in Action http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info phone: +1 203-653-2989 fax: +1 203-653-2988 * Sign up for the JSF Central newsletter! http://oi.vresp.com/?fid=ac048d0e17 * -Original Message- From: paksegu [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 28, 2007 2:47 PM To: user@shale.apache.org Subject: Shale, Clay, Facelets and JSF Templating nameHi, nameIs is possible to use Shale, Clay, Facelets and JSF Templating in the same application and if so will the shale dialog and the standard navigation feature behave differently? Also can anyone give me tips on where it will best use jsf templating over clay or facelets? Ransford Segu-Baffoe [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.noqturnalmediasystems.com/ http://www.noqturnalmediasystems.com/Serenade/ https://serenade.dev.java.net/ - Now that's room service! Choose from over 150,000 hotels in 45,000 destinations on Yahoo! Travel to find your fit.
RE: Shale, Clay, Facelets and JSF Templating
I was thinking that the might be advantages and disadvantages, I wasn't too sure I would be able to use the EL expression langauge in shale and also I was thinking of combining the woodstock components with JSF templating to create UI for media/image album display component. Thanks Kito D. Mann [EMAIL PROTECTED] wrote: Ransford, Just out of curiosity, why are you interested in using Clay, Facelets, and JSF Templatin in the same application, since they all solve the same problem? ~~~ Kito D. Mann - Author, JavaServer Faces in Action http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info phone: +1 203-653-2989 fax: +1 203-653-2988 * Sign up for the JSF Central newsletter! http://oi.vresp.com/?fid=ac048d0e17 * -Original Message- From: paksegu [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 28, 2007 2:47 PM To: user@shale.apache.org Subject: Shale, Clay, Facelets and JSF Templating nameHi, nameIs is possible to use Shale, Clay, Facelets and JSF Templating in the same application and if so will the shale dialog and the standard navigation feature behave differently? Also can anyone give me tips on where it will best use jsf templating over clay or facelets? Ransford Segu-Baffoe [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.noqturnalmediasystems.com/ http://www.noqturnalmediasystems.com/Serenade/ https://serenade.dev.java.net/ - Now that's room service! Choose from over 150,000 hotels in 45,000 destinations on Yahoo! Travel to find your fit. Ransford Segu-Baffoe [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.noqturnalmediasystems.com/ http://www.noqturnalmediasystems.com/Serenade/ https://serenade.dev.java.net/ - Looking for earth-friendly autos? Browse Top Cars by Green Rating at Yahoo! Autos' Green Center.
Re: Shale-Clay site goes live: http://www.truphone.com
Hey Ian, Thanks so much for pointing us to your site. I'm part of a travelling road show where I teach Shale and Clay and I'm often specifically asked about commercial sites that use Clay's approach to separating HTML and components so that page authors and software developers can easily work with graphic artists. I will add a screenshot of your application to my slideshow ( http://nofluffjuststuff.com/speaker_topic_view.jsp?topicId=18) Thanks again! david 2006/9/15, Gary VanMatre [EMAIL PROTECTED]: Hi Ian, Thanks for sharing your success with us. I really appreciate your participation and for the kind words. The site looks very sexy! Gary -- Original message -- From: Ian.Priest [EMAIL PROTECTED] Hi all, I thought you might be interested to know that the site I've been working on for the past few months has now gone live. The site, http://www.truphone.com, is driven by Shale/Clay sitting on MyFaces and running inside Tomcat. Underneath there is a MySQL database and a bespoke application backend that provides the functionality and interfaces with the VoIP provider and various other third parties. Clay was chosen for the ability to write pure HTML that could then be replaced by dynamic content and for the Tiles-like layout feature. That was quite important as I was working with a third-party HTML design agency (sadly that slick look and feel isn't my design!) so JSP or similar would have been inappropriate. However, a later architecture re-design showed that Clay was a better choice than realised because I was able to exploit the full-xml and symbol replacement bits of Clay to get a very nice site that blends dynamic and static content in quite a cool manner. The pages are rendered by pulling sub-section pages into a layout to create some archetypes. The full-xml view pages extend the archetypes and use clay and clayImport to pull in the final bits of content in a nice ready for multi-language manner. Those of you who have read and answered my various postings over the last few months will have a pretty good idea of how it's put together, and now the mystery of the unusual .tru extension is solved too :-) (see previous theads). I'm sure Truphone would welcome any constructive comments and I know I would. I'd like to say thanks to everyone here. I couldn't have done it without the help and advice received on this forum, and I'd especially like to single out Gary VanMatre for help he's given me. Thanks. Hope you like the site. Cheers, Ian.
