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.