Failed model update
With following code, I was trying to udpate a variable in a backing bean with a
HtmlInputText component in viewRoot. But the model is never updated. the value
is stil the initial one. Could anyone see what went wrong here? this is from a
previous post code sample.
thank you so much
Jane
vc = new CredentialBean();
UIViewRoot root=facesContext.getViewRoot();
UIForm credForm = new HtmlForm();
credForm.setId("credForm");
credForm.setParent(root);
UIInput label = new HtmlInputText();
label.setId("label");
label.setParent(credForm);
ValueBinding vb =
facesContext.getApplication().createValueBinding("#{credentialBean.passwordAgain}");
label.setValueBinding("value", vb);
facesContext.getExternalContext().getRequestMap().put("credentialBean", vc);
facesContext.getExternalContext().getRequestParameterMap().put("credForm:label","myLabel");
root.processDecodes(facesContext);
root.processValidators(facesContext);
root.processApplication(facesContext);
root.processUpdates(facesContext);
assertEquals(vc.getPasswordAgain(), "myLabel");
RE: [Shale Clay]
-- Original message -- From: "Zheng, Xiahong" <[EMAIL PROTECTED]> > 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. > I see. It sounds like the clay view handler is having trouble replacing the state token then. Something you might try is using the clay JSP tag. That would help isolate the problem. You could create a JSP page that has a f:view and shale:clay [1]. Then, for the jsfid, include the target template. The token can be an HTML template or an entry in a clay config. clay:clay id="address1" jsfid="classpath*:org/apache/shale/usecases/rolodex/address.html" ... ... When the component is used with JSP, the default JSF runtime field marker replacement is used. Please file a bug and a test case would be really nice :-) [1] http://svn.apache.org/viewvc/shale/framework/trunk/shale-apps/shale-clay-usecases/src/main/webapp/rolodex/jsprolodex.jsp?view=markup Thanks, Gary > -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 > > > > > > > > > > > componentType="org.apache.myfaces.HtmlInputFileUpload" > > > > extends="baseOutput> > > > > > > > > > > > > . > > > > > > > > > > > > > > > > And I added the following in my html form > > > > > > > > > > > > > > > > > > > storage="file" /> > > > > > > > > > > > > > > > > > > > > > > > > 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? > > > > > > > > > > > > > > > > + > > > > > > > > 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
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 > > > > > > > > componentType="org.apache.myfaces.HtmlInputFileUpload" > > > extends="baseOutput> > > > > > > > > > . > > > > > > > > > > > > And I added the following in my html form > > > > > > > > > > > > > > storage="file" /> > > > > > > > > > > > > > > > > > > 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? > > > > > > > > + > > > > 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
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
> > >
> > > > > componentType="org.apache.myfaces.HtmlInputFileUpload"
> > > extends="baseOutput>
> > >
> > >
> > > .
> > >
> > >
> > >
> > > And I added the following in my html form
> > >
> > >
> > >
> > > > > storage="file" />
> > >
> > >
> > >
> > >
> > >
> > > 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?
>
>
>
>
>
>
>
> +
>
>
>
> 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.,
> > >
> > > > > >
> > >Mock Heading
> > > > >>
> > > #{foo.name}
> > > > > facetName="header">
> > >
> > >
> > >
> > >
> > > Note that the lack of whitespace around the T
RE: [Shale Clay]
Yes, I had in my tempalte.
-Original Message-
From: Richard Eggert [mailto:[EMAIL PROTECTED]
Sent: Friday, April 11, 2008 3:47 PM
To: user@shale.apache.org
Subject: 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
> >
> > > componentType="org.apache.myfaces.HtmlInputFileUpload"
> > extends="baseOutput>
> >
> >
> > .
> >
> >
> >
> > And I added the following in my html form
> >
> >
> >
> > > storage="file" />
> >
> >
> >
> >
> >
> > 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?
+
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.,
> >
> > > >
> >Mock Heading
> > >>
> > #{foo.name}
> >> facetName="header">
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
> >
> > > componentType="org.apache.myfaces.HtmlInputFileUpload"
> > extends="baseOutput>
> >
> >
> > .
> >
> >
> >
> > And I added the following in my html form
> >
> >
> >
> > > storage="file" />
> >
> >
> >
> >
> >
> > 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?
+
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.,
> >
> > > >
> >Mock Heading
> > >>
> > #{foo.name}
> >> facetName="header">
> >
> >
> >
> >
> > 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
> >
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
> >
> > > componentType="org.apache.myfaces.HtmlInputFileUpload"
> > extends="baseOutput>
> >
> >
> > .
> >
> >
> >
> > And I added the following in my html form
> >
> >
> >
> > > storage="file" />
> >
> >
> >
> >
> >
> > 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?
+
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.,
> >
> > > >
> >Mock Heading
> > >>
> > #{foo.name}
> >> facetName="header">
> >
> >
> >
> >
> > 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
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
> >
> > > componentType="org.apache.myfaces.HtmlInputFileUpload"
> > extends="baseOutput>
> >
> >
> > .
> >
> >
> >
> > And I added the following in my html form
> >
> >
> >
> > > storage="file" />
> >
> >
> >
> >
> >
> > 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?
+
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.,
> >
> > > >
> >Mock Heading
> > >>
> > #{foo.name}
> >> facetName="header">
> >
> >
> >
> >
> > 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 goes here.
> >
> >
> >
> > 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 Cla
RE: [Shale Clay]
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
>
>componentType="org.apache.myfaces.HtmlInputFileUpload"
> extends="baseOutput>
>
>
> .
>
>
>
> And I added the following in my html form
>
>
>
> storage="file" />
>
>
>
>
>
> 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.,
>
> >
>Mock Heading
> >
> #{foo.name}
> facetName="header">
>
>
>
>
> 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 goes here.
>
>
>
> 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
>
>componentType="org.apache.myfaces.HtmlInputFileUpload"
> extends="baseOutput>
>
>
> .
>
>
>
> And I added the following in my html form
>
>
>
> storage="file" />
>
>
>
>
>
> 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.,
>
> >
>Mock Heading
> >
> #{foo.name}
> facetName="header">
>
>
>
>
> 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 goes here.
>
>
>
> 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]
I don't see anything wrong with what you've written there (I would add
type="file" to your tag so that it looks right if you view it offline
in a browser, but that shouldn't affect how Clay treats it). Does it let you
select a file before submitting?
Double-check to make sure that you don't have any mistakes in your
configuration (especially in web.xml). Check the log for errors as well (you
may need to tweak the log settings to get useful information). I've used
t:inputFileUpload with Clay many times, so I'm sure it works.
By the way, it generally isn't necessary to copy the component definitions into
your clay-config.xml file. Just add
classpath*:META-INF/tomahawk-1_1_3-config.xml to the
org.apache.shale.clay.COMMON_CONFIG_FILES context parameter in your web.xml
file, and you'll get the definitions of all the Tomahawk components.
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:19 PM
To: user@shale.apache.org
Subject: 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
.
And I added the following in my html 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.,
Mock Heading
#{foo.name}
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 goes here.
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
.
And I added the following in my html 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.,
Mock Heading
#{foo.name}
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 goes here.
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: Need to escape special characters in Shale validator script
You might try wrapping the script in a CDATA before trying to escape the JS. -- Original message -- From: Jeff Tsay <[EMAIL PROTECTED]> > Hi, > > I'm trying to use Shale validator with xulfaces. (XUL is a user > interface language that is a type of XML) The first problem I'm having > is that > > > is encoded as follows: > >
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.,
Mock Heading
#{foo.name}
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 goes here.
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?
