Different validations for different command links
I have used myfaces-1.1.2 and sandbox-1.1.2 in my application. I have created a form which has many command links/buttons for different actions (add entry, delete entry and save). I am also using validations for various input fields. But I want to make these validations applicable only to SAVE action, others to bypass all the validations. I have tried with immediate=true but all the entered data get lost. And if I use custom validator which I thought to check the nature of action while applying validations, it doesnt work on empty fields even if I remove required=true. Is there a way to write custom validator for 'required validation'? or How can i bypass validation for an action(other than cancel action) as I need model values to be persisted? Thanks Nikhil -- View this message in context: http://www.nabble.com/Different-validations-for-different-command-links-tf4309598.html#a12268674 Sent from the MyFaces - Users mailing list archive at Nabble.com.
Re: [Trinidad] iframe popup skinning
The same problem I have with 1.0.3 trunk. Simon Lessard wrote: Hello all, Using latest 1.2.2 branch, I have a problem with iframe popup skinning where the style class does not get converted. The markup looks like: div style=padding: 0px; overflow: auto; position: absolute; z-index: 201; top: 319.5px; left: 558.5px; visibility: visible; class=af|panelPopup::container div class=af|panelPopup::title-text af|panelPopup::title-bar style=display: block;Pick a Date/div iframe width=323 height=243 frameborder=0 name=_blank class=af|panelPopup::content/ /div Anyone got it working? Regards, ~ Simon
[Tobago] More layout problems with 1.0.12
Hi, with the current Tobago 1.0.12 snapshot I've got some new layout problems in popups. With 1.0.11 and older 1.0.12 snapshots the layout is ok. Please have a look at the attached screenshot. The input elements on the popup are cut off at their right sides. This is the jsp code: tc:page id=inputPage width=500px height=300px tc:panel id=inputPanel tc:button id=popupButton label=Popup f:facet name=popup tc:popup id=popup width=400 height=220 tc:box id=box label=Popup f:facet name=layout tc:gridLayout rows=*;fixed;fixed;fixed;54px;fixed columns=*;*;*/ /f:facet tc:cell spanX=3 tc:out value=Text/ /tc:cell tc:cell spanX=2 tc:label value=label1/ /tc:cell tc:cell/ tc:cell spanX=2 tc:selectOneChoice id=choice tc:selectItem itemLabel= itemValue=/ /tc:selectOneChoice /tc:cell tc:cell/ tc:cell spanX=3 tc:label value=label2/ /tc:cell tc:cell spanX=3 tc:textarea id=textarea/ /tc:cell tc:cell/ tc:button id=saveButton label=save tc:attribute name=popupClose value=afterSubmit/ /tc:button tc:button id=cancelButton label=cancel tc:attribute name=popupClose value=immediate/ /tc:button /tc:box /tc:popup /f:facet /tc:button /tc:panel /tc:page Regards Helmut attachment: popup.jpg
Re: [Trinidad] iframe popup skinning
I probably found one of the culprits, but it's not the only one as it
doesn't fix the issue... Since keys in JavaScript structures does not need
quotes, I changed
out.writeText(TrPage.getInstance().addStyleClassMap( {', null);
out.writeText(SkinSelectors.AF_PANEL_POPUP_CONTAINER_STYLE_CLASS + ':',
null);
out.writeText(arc.getStyleClass(
SkinSelectors.AF_PANEL_POPUP_CONTAINER_STYLE_CLASS), null);
out.writeText(',' + SkinSelectors.AF_PANEL_POPUP_CONTENT_STYLE_CLASS +
':', null);
out.writeText(arc.getStyleClass(
SkinSelectors.AF_PANEL_POPUP_CONTENT_STYLE_CLASS), null);
out.writeText(',' + SkinSelectors.AF_PANEL_POPUP_TITLE_STYLE_CLASS +
':', null);
out.writeText(arc.getStyleClass(
SkinSelectors.AF_PANEL_POPUP_TITLE_STYLE_CLASS), null);
out.writeText(',' + SkinSelectors.AF_PANEL_POPUP_TITLEBAR_STYLE_CLASS +
':', null);
out.writeText(arc.getStyleClass(
SkinSelectors.AF_PANEL_POPUP_TITLEBAR_STYLE_CLASS), null);
out.writeText('} ); , null);
to
out.writeText(TrPage.getInstance().addStyleClassMap( {, null);
out.writeText(SkinSelectors.AF_PANEL_POPUP_CONTAINER_STYLE_CLASS + :',
null);
out.writeText(arc.getStyleClass(
SkinSelectors.AF_PANEL_POPUP_CONTAINER_STYLE_CLASS), null);
out.writeText(', + SkinSelectors.AF_PANEL_POPUP_CONTENT_STYLE_CLASS +
:', null);
out.writeText(arc.getStyleClass(
SkinSelectors.AF_PANEL_POPUP_CONTENT_STYLE_CLASS), null);
out.writeText(', + SkinSelectors.AF_PANEL_POPUP_TITLE_STYLE_CLASS + :',
null);
out.writeText(arc.getStyleClass(
SkinSelectors.AF_PANEL_POPUP_TITLE_STYLE_CLASS), null);
out.writeText(', + SkinSelectors.AF_PANEL_POPUP_TITLEBAR_STYLE_CLASS +
:', null);
out.writeText(arc.getStyleClass(
SkinSelectors.AF_PANEL_POPUP_TITLEBAR_STYLE_CLASS), null);
out.writeText('} ); , null);
But, as I said, this is probably not everything that need to be done as I
still have the issue.
Regards,
~ Simon
On 8/22/07, Simon Lessard [EMAIL PROTECTED] wrote:
Personally, I use JDeveloper 11 to run JSF 1.2.
Also, I got two more issues with the iframe popup as well. One with
inputDate where the popup get bigger and bigger when I change the month or
year (I'll have to test navigation in the popup to see if it's generalized).
The other is that the popup's DIV does not get cleared from the DOM after
being closed so if you keep selecting a date then reopen the calendar, the
DOM slowly get bloated.
Regards,
~ Simon
On 8/22/07, Luka Surija [EMAIL PROTECTED] wrote:
The same problem I have with 1.0.3 trunk.
Simon Lessard wrote:
Hello all,
Using latest 1.2.2 branch, I have a problem with iframe popup skinning
where the style class does not get converted. The markup looks like:
div style=padding: 0px; overflow: auto; position: absolute; z-index:
201; top: 319.5px; left: 558.5px; visibility: visible;
class=af|panelPopup::container
div class=af|panelPopup::title-text af|panelPopup::title-bar
style=display: block;Pick a Date/div
iframe width=323 height=243 frameborder=0 name=_blank
class=af|panelPopup::content/
/div
Anyone got it working?
Regards,
~ Simon
Re: [Trinidad] iframe popup skinning
On 8/22/07, Simon Lessard [EMAIL PROTECTED] wrote:
I probably found one of the culprits, but it's not the only one as it
doesn't fix the issue... Since keys in JavaScript structures does not need
quotes, I changed
FWIW: quotes don't hurt, and they're necessary if your keys
are not valid JS identifiers. If you know your key is a valid
JS identifier, then it's a waste of space, and is worth getting
deleted.
-- Adam
out.writeText(TrPage.getInstance().addStyleClassMap( {', null);
out.writeText(SkinSelectors.AF_PANEL_POPUP_CONTAINER_STYLE_CLASS
+ ':', null);
out.writeText(arc.getStyleClass(SkinSelectors.AF_PANEL_POPUP_CONTAINER_STYLE_CLASS),
null);
out.writeText(',' +
SkinSelectors.AF_PANEL_POPUP_CONTENT_STYLE_CLASS + ':',
null);
out.writeText(arc.getStyleClass(SkinSelectors.AF_PANEL_POPUP_CONTENT_STYLE_CLASS),
null);
out.writeText(',' +
SkinSelectors.AF_PANEL_POPUP_TITLE_STYLE_CLASS + ':',
null);
out.writeText(arc.getStyleClass(SkinSelectors.AF_PANEL_POPUP_TITLE_STYLE_CLASS),
null);
out.writeText(',' +
SkinSelectors.AF_PANEL_POPUP_TITLEBAR_STYLE_CLASS + ':',
null);
out.writeText(arc.getStyleClass(SkinSelectors.AF_PANEL_POPUP_TITLEBAR_STYLE_CLASS),
null);
out.writeText('} ); , null);
to
out.writeText(TrPage.getInstance().addStyleClassMap( {, null);
out.writeText(SkinSelectors.AF_PANEL_POPUP_CONTAINER_STYLE_CLASS
+ :', null);
out.writeText(arc.getStyleClass(SkinSelectors.AF_PANEL_POPUP_CONTAINER_STYLE_CLASS),
null);
out.writeText(', +
SkinSelectors.AF_PANEL_POPUP_CONTENT_STYLE_CLASS + :',
null);
out.writeText(arc.getStyleClass(SkinSelectors.AF_PANEL_POPUP_CONTENT_STYLE_CLASS),
null);
out.writeText(', +
SkinSelectors.AF_PANEL_POPUP_TITLE_STYLE_CLASS + :',
null);
out.writeText(arc.getStyleClass(SkinSelectors.AF_PANEL_POPUP_TITLE_STYLE_CLASS),
null);
out.writeText(', +
SkinSelectors.AF_PANEL_POPUP_TITLEBAR_STYLE_CLASS + :',
null);
out.writeText(arc.getStyleClass(SkinSelectors.AF_PANEL_POPUP_TITLEBAR_STYLE_CLASS
), null);
out.writeText('} ); , null);
But, as I said, this is probably not everything that need to be done as I
still have the issue.
Regards,
~ Simon
On 8/22/07, Simon Lessard [EMAIL PROTECTED] wrote:
Personally, I use JDeveloper 11 to run JSF 1.2.
Also, I got two more issues with the iframe popup as well. One with
inputDate where the popup get bigger and bigger when I change the month or
year (I'll have to test navigation in the popup to see if it's generalized).
The other is that the popup's DIV does not get cleared from the DOM after
being closed so if you keep selecting a date then reopen the calendar, the
DOM slowly get bloated.
Regards,
~ Simon
On 8/22/07, Luka Surija [EMAIL PROTECTED] wrote:
The same problem I have with 1.0.3 trunk.
Simon Lessard wrote:
Hello all,
Using latest 1.2.2 branch, I have a problem with iframe popup skinning
where the style class does not get converted. The markup looks like:
div style=padding: 0px; overflow: auto; position: absolute; z-index:
201; top: 319.5px; left: 558.5px; visibility: visible;
class=af|panelPopup::container
div class=af|panelPopup::title-text
af|panelPopup::title-bar
style=display: block;Pick a Date/div
iframe width=323 height=243 frameborder=0 name=_blank
class=af|panelPopup::content/
/div
Anyone got it working?
Regards,
~ Simon
Re: [Trinidad] iframe popup skinning
Good to know... are you seeing other styles get converted, or is it just this? -- Adam On 8/22/07, Luka Surija [EMAIL PROTECTED] wrote: The same problem I have with 1.0.3 trunk. Simon Lessard wrote: Hello all, Using latest 1.2.2 branch, I have a problem with iframe popup skinning where the style class does not get converted. The markup looks like: div style=padding: 0px; overflow: auto; position: absolute; z-index: 201; top: 319.5px; left: 558.5px; visibility: visible; class=af|panelPopup::container div class=af|panelPopup::title-text af|panelPopup::title-bar style=display: block;Pick a Date/div iframe width=323 height=243 frameborder=0 name=_blank class=af|panelPopup::content/ /div Anyone got it working? Regards, ~ Simon
Re: [Trinidad] iframe popup skinning
I just tested panelPopup.jspx in the trinidad-demo with 1.2.2, and the classes are getting compressed there; but this isn't the iframe popup code. -- Adam On 8/21/07, Simon Lessard [EMAIL PROTECTED] wrote: Hello all, Using latest 1.2.2 branch, I have a problem with iframe popup skinning where the style class does not get converted. The markup looks like: div style=padding: 0px; overflow: auto; position: absolute; z-index: 201; top: 319.5px; left: 558.5px; visibility: visible; class=af|panelPopup::container div class=af|panelPopup::title-text af|panelPopup::title-bar style=display: block;Pick a Date/div iframe width=323 height=243 frameborder=0 name=_blank class=af|panelPopup::content/ /div Anyone got it working? Regards, ~ Simon
Re: [Trinidad] iframe popup skinning
Ah, then they're needed in this case since the key contains | and ::. I'm
going to degrade to a simpler page and less installed components (phase
listeners and such) to see if the problem still occurs.
On 8/22/07, Adam Winer [EMAIL PROTECTED] wrote:
On 8/22/07, Simon Lessard [EMAIL PROTECTED] wrote:
I probably found one of the culprits, but it's not the only one as it
doesn't fix the issue... Since keys in JavaScript structures does not
need
quotes, I changed
FWIW: quotes don't hurt, and they're necessary if your keys
are not valid JS identifiers. If you know your key is a valid
JS identifier, then it's a waste of space, and is worth getting
deleted.
-- Adam
out.writeText(TrPage.getInstance().addStyleClassMap( {', null);
out.writeText(SkinSelectors.AF_PANEL_POPUP_CONTAINER_STYLE_CLASS
+ ':', null);
out.writeText(arc.getStyleClass(
SkinSelectors.AF_PANEL_POPUP_CONTAINER_STYLE_CLASS),
null);
out.writeText(',' +
SkinSelectors.AF_PANEL_POPUP_CONTENT_STYLE_CLASS + ':',
null);
out.writeText(arc.getStyleClass(
SkinSelectors.AF_PANEL_POPUP_CONTENT_STYLE_CLASS),
null);
out.writeText(',' +
SkinSelectors.AF_PANEL_POPUP_TITLE_STYLE_CLASS + ':',
null);
out.writeText(arc.getStyleClass(
SkinSelectors.AF_PANEL_POPUP_TITLE_STYLE_CLASS),
null);
out.writeText(',' +
SkinSelectors.AF_PANEL_POPUP_TITLEBAR_STYLE_CLASS + ':',
null);
out.writeText(arc.getStyleClass(
SkinSelectors.AF_PANEL_POPUP_TITLEBAR_STYLE_CLASS),
null);
out.writeText('} ); , null);
to
out.writeText(TrPage.getInstance().addStyleClassMap( {, null);
out.writeText(SkinSelectors.AF_PANEL_POPUP_CONTAINER_STYLE_CLASS
+ :', null);
out.writeText(arc.getStyleClass(
SkinSelectors.AF_PANEL_POPUP_CONTAINER_STYLE_CLASS),
null);
out.writeText(', +
SkinSelectors.AF_PANEL_POPUP_CONTENT_STYLE_CLASS + :',
null);
out.writeText(arc.getStyleClass(
SkinSelectors.AF_PANEL_POPUP_CONTENT_STYLE_CLASS),
null);
out.writeText(', +
SkinSelectors.AF_PANEL_POPUP_TITLE_STYLE_CLASS + :',
null);
out.writeText(arc.getStyleClass(
SkinSelectors.AF_PANEL_POPUP_TITLE_STYLE_CLASS),
null);
out.writeText(', +
SkinSelectors.AF_PANEL_POPUP_TITLEBAR_STYLE_CLASS + :',
null);
out.writeText(arc.getStyleClass(
SkinSelectors.AF_PANEL_POPUP_TITLEBAR_STYLE_CLASS
), null);
out.writeText('} ); , null);
But, as I said, this is probably not everything that need to be done as
I
still have the issue.
Regards,
~ Simon
On 8/22/07, Simon Lessard [EMAIL PROTECTED] wrote:
Personally, I use JDeveloper 11 to run JSF 1.2.
Also, I got two more issues with the iframe popup as well. One with
inputDate where the popup get bigger and bigger when I change the month
or
year (I'll have to test navigation in the popup to see if it's
generalized).
The other is that the popup's DIV does not get cleared from the DOM
after
being closed so if you keep selecting a date then reopen the calendar,
the
DOM slowly get bloated.
Regards,
~ Simon
On 8/22/07, Luka Surija [EMAIL PROTECTED] wrote:
The same problem I have with 1.0.3 trunk.
Simon Lessard wrote:
Hello all,
Using latest 1.2.2 branch, I have a problem with iframe popup
skinning
where the style class does not get converted. The markup looks
like:
div style=padding: 0px; overflow: auto; position: absolute;
z-index:
201; top: 319.5px; left: 558.5px; visibility: visible;
class=af|panelPopup::container
div class=af|panelPopup::title-text
af|panelPopup::title-bar
style=display: block;Pick a Date/div
iframe width=323 height=243 frameborder=0 name=_blank
class=af|panelPopup::content/
/div
Anyone got it working?
Regards,
~ Simon
Re: [Trinidad] iframe popup skinning
Interesting... inputDate give me the non compressed style classes, and
normal dialog framework give me the following:
ATTENTION: No RenderingContext available
2007-08-22 10:29:51 org.apache.myfaces.trinidad.context.RenderingContextattach
ATTENTION: Trying to attach RenderingContext to a thread that already had
one.
2007-08-22 10:29:51
org.apache.myfaces.trinidadinternal.renderkit.core.CoreRenderKitencodeFinally
ATTENTION: No RenderingContext available
I'll try from a new application rather than a degraded one, just to see.
On 8/22/07, Simon Lessard [EMAIL PROTECTED] wrote:
Ah, then they're needed in this case since the key contains | and ::. I'm
going to degrade to a simpler page and less installed components (phase
listeners and such) to see if the problem still occurs.
On 8/22/07, Adam Winer [EMAIL PROTECTED] wrote:
On 8/22/07, Simon Lessard [EMAIL PROTECTED] wrote:
I probably found one of the culprits, but it's not the only one as it
doesn't fix the issue... Since keys in JavaScript structures does not
need
quotes, I changed
FWIW: quotes don't hurt, and they're necessary if your keys
are not valid JS identifiers. If you know your key is a valid
JS identifier, then it's a waste of space, and is worth getting
deleted.
-- Adam
out.writeText(TrPage.getInstance().addStyleClassMap( {', null);
out.writeText(SkinSelectors.AF_PANEL_POPUP_CONTAINER_STYLE_CLASS
+ ':', null);
out.writeText(arc.getStyleClass(
SkinSelectors.AF_PANEL_POPUP_CONTAINER_STYLE_CLASS),
null);
out.writeText(',' +
SkinSelectors.AF_PANEL_POPUP_CONTENT_STYLE_CLASS + ':',
null);
out.writeText(arc.getStyleClass(
SkinSelectors.AF_PANEL_POPUP_CONTENT_STYLE_CLASS),
null);
out.writeText(',' +
SkinSelectors.AF_PANEL_POPUP_TITLE_STYLE_CLASS + ':',
null);
out.writeText(arc.getStyleClass(
SkinSelectors.AF_PANEL_POPUP_TITLE_STYLE_CLASS),
null);
out.writeText(',' +
SkinSelectors.AF_PANEL_POPUP_TITLEBAR_STYLE_CLASS + ':',
null);
out.writeText(arc.getStyleClass(
SkinSelectors.AF_PANEL_POPUP_TITLEBAR_STYLE_CLASS),
null);
out.writeText('} ); , null);
to
out.writeText(TrPage.getInstance().addStyleClassMap( {, null);
out.writeText(SkinSelectors.AF_PANEL_POPUP_CONTAINER_STYLE_CLASS
+ :', null);
out.writeText (arc.getStyleClass(
SkinSelectors.AF_PANEL_POPUP_CONTAINER_STYLE_CLASS),
null);
out.writeText(', +
SkinSelectors.AF_PANEL_POPUP_CONTENT_STYLE_CLASS + :',
null);
out.writeText(arc.getStyleClass(
SkinSelectors.AF_PANEL_POPUP_CONTENT_STYLE_CLASS),
null);
out.writeText(', +
SkinSelectors.AF_PANEL_POPUP_TITLE_STYLE_CLASS + :',
null);
out.writeText(arc.getStyleClass(
SkinSelectors.AF_PANEL_POPUP_TITLE_STYLE_CLASS),
null);
out.writeText(', +
SkinSelectors.AF_PANEL_POPUP_TITLEBAR_STYLE_CLASS + :',
null);
out.writeText(arc.getStyleClass(
SkinSelectors.AF_PANEL_POPUP_TITLEBAR_STYLE_CLASS
), null);
out.writeText('} ); , null);
But, as I said, this is probably not everything that need to be done
as I
still have the issue.
Regards,
~ Simon
On 8/22/07, Simon Lessard [EMAIL PROTECTED] wrote:
Personally, I use JDeveloper 11 to run JSF 1.2.
Also, I got two more issues with the iframe popup as well. One with
inputDate where the popup get bigger and bigger when I change the
month or
year (I'll have to test navigation in the popup to see if it's
generalized).
The other is that the popup's DIV does not get cleared from the DOM
after
being closed so if you keep selecting a date then reopen the calendar,
the
DOM slowly get bloated.
Regards,
~ Simon
On 8/22/07, Luka Surija [EMAIL PROTECTED] wrote:
The same problem I have with 1.0.3 trunk.
Simon Lessard wrote:
Hello all,
Using latest 1.2.2 branch, I have a problem with iframe popup
skinning
where the style class does not get converted. The markup looks
like:
div style=padding: 0px; overflow: auto; position: absolute;
z-index:
201; top: 319.5px; left: 558.5px; visibility: visible;
class=af|panelPopup::container
div class=af|panelPopup::title-text
af|panelPopup::title-bar
style=display: block;Pick a Date/div
iframe width=323 height=243 frameborder=0 name=_blank
class=af|panelPopup::content/
/div
Anyone got it working?
Regards,
~ Simon
Re: [Trinidad] iframe popup skinning
Nope, I'm just being stupid as usual and was getting those warning because I
made a typo in the navigation case...
On 8/22/07, Simon Lessard [EMAIL PROTECTED] wrote:
Interesting... inputDate give me the non compressed style classes, and
normal dialog framework give me the following:
ATTENTION: No RenderingContext available
2007-08-22 10:29:51 org.apache.myfaces.trinidad.context.RenderingContextattach
ATTENTION: Trying to attach RenderingContext to a thread that already had
one.
2007-08-22 10:29:51
org.apache.myfaces.trinidadinternal.renderkit.core.CoreRenderKitencodeFinally
ATTENTION: No RenderingContext available
I'll try from a new application rather than a degraded one, just to see.
On 8/22/07, Simon Lessard [EMAIL PROTECTED] wrote:
Ah, then they're needed in this case since the key contains | and ::.
I'm going to degrade to a simpler page and less installed components (phase
listeners and such) to see if the problem still occurs.
On 8/22/07, Adam Winer [EMAIL PROTECTED] wrote:
On 8/22/07, Simon Lessard [EMAIL PROTECTED] wrote:
I probably found one of the culprits, but it's not the only one as
it
doesn't fix the issue... Since keys in JavaScript structures does
not need
quotes, I changed
FWIW: quotes don't hurt, and they're necessary if your keys
are not valid JS identifiers. If you know your key is a valid
JS identifier, then it's a waste of space, and is worth getting
deleted.
-- Adam
out.writeText(TrPage.getInstance().addStyleClassMap( {', null);
out.writeText(SkinSelectors.AF_PANEL_POPUP_CONTAINER_STYLE_CLASS
+ ':', null);
out.writeText(arc.getStyleClass(
SkinSelectors.AF_PANEL_POPUP_CONTAINER_STYLE_CLASS),
null);
out.writeText(',' +
SkinSelectors.AF_PANEL_POPUP_CONTENT_STYLE_CLASS + ':',
null);
out.writeText(arc.getStyleClass(
SkinSelectors.AF_PANEL_POPUP_CONTENT_STYLE_CLASS),
null);
out.writeText(',' +
SkinSelectors.AF_PANEL_POPUP_TITLE_STYLE_CLASS + ':',
null);
out.writeText(arc.getStyleClass(
SkinSelectors.AF_PANEL_POPUP_TITLE_STYLE_CLASS),
null);
out.writeText(',' +
SkinSelectors.AF_PANEL_POPUP_TITLEBAR_STYLE_CLASS + ':',
null);
out.writeText(arc.getStyleClass(
SkinSelectors.AF_PANEL_POPUP_TITLEBAR_STYLE_CLASS),
null);
out.writeText('} ); , null);
to
out.writeText(TrPage.getInstance().addStyleClassMap( {, null);
out.writeText(SkinSelectors.AF_PANEL_POPUP_CONTAINER_STYLE_CLASS
+ :', null);
out.writeText (arc.getStyleClass(
SkinSelectors.AF_PANEL_POPUP_CONTAINER_STYLE_CLASS),
null);
out.writeText(', +
SkinSelectors.AF_PANEL_POPUP_CONTENT_STYLE_CLASS + :',
null);
out.writeText(arc.getStyleClass(
SkinSelectors.AF_PANEL_POPUP_CONTENT_STYLE_CLASS),
null);
out.writeText(', +
SkinSelectors.AF_PANEL_POPUP_TITLE_STYLE_CLASS + :',
null);
out.writeText(arc.getStyleClass(
SkinSelectors.AF_PANEL_POPUP_TITLE_STYLE_CLASS),
null);
out.writeText(', +
SkinSelectors.AF_PANEL_POPUP_TITLEBAR_STYLE_CLASS + :',
null);
out.writeText(arc.getStyleClass(
SkinSelectors.AF_PANEL_POPUP_TITLEBAR_STYLE_CLASS
), null);
out.writeText('} ); , null);
But, as I said, this is probably not everything that need to be done
as I
still have the issue.
Regards,
~ Simon
On 8/22/07, Simon Lessard [EMAIL PROTECTED] wrote:
Personally, I use JDeveloper 11 to run JSF 1.2.
Also, I got two more issues with the iframe popup as well. One
with
inputDate where the popup get bigger and bigger when I change the
month or
year (I'll have to test navigation in the popup to see if it's
generalized).
The other is that the popup's DIV does not get cleared from the DOM
after
being closed so if you keep selecting a date then reopen the
calendar, the
DOM slowly get bloated.
Regards,
~ Simon
On 8/22/07, Luka Surija [EMAIL PROTECTED] wrote:
The same problem I have with 1.0.3 trunk.
Simon Lessard wrote:
Hello all,
Using latest 1.2.2 branch, I have a problem with iframe popup
skinning
where the style class does not get converted. The markup looks
like:
div style=padding: 0px; overflow: auto; position: absolute;
z-index:
201; top: 319.5px; left: 558.5px; visibility: visible;
class=af|panelPopup::container
div class=af|panelPopup::title-text
af|panelPopup::title-bar
style=display: block;Pick a Date/div
iframe width=323 height=243 frameborder=0
name=_blank
class=af|panelPopup::content/
/div
Anyone got it working?
Regards,
~ Simon
Re: [Trinidad] iframe popup skinning
Ok, finally, after numerous stupid mistakes, I can say that the problem
occurs only with inputDate component and not with standard dialogs nor
inputListOfValues. Furthermore, for some even more obscure reasons, if I
ever popup a working dialog (through inputListOfValues or any dialog:xyz
outcome) then inputDate starts to work...
Regards,
~ Simon
On 8/22/07, Simon Lessard [EMAIL PROTECTED] wrote:
Nope, I'm just being stupid as usual and was getting those warning because
I made a typo in the navigation case...
On 8/22/07, Simon Lessard [EMAIL PROTECTED] wrote:
Interesting... inputDate give me the non compressed style classes, and
normal dialog framework give me the following:
ATTENTION: No RenderingContext available
2007-08-22 10:29:51
org.apache.myfaces.trinidad.context.RenderingContextattach
ATTENTION: Trying to attach RenderingContext to a thread that already
had one.
2007-08-22 10:29:51
org.apache.myfaces.trinidadinternal.renderkit.core.CoreRenderKitencodeFinally
ATTENTION: No RenderingContext available
I'll try from a new application rather than a degraded one, just to see.
On 8/22/07, Simon Lessard [EMAIL PROTECTED] wrote:
Ah, then they're needed in this case since the key contains | and ::.
I'm going to degrade to a simpler page and less installed components
(phase
listeners and such) to see if the problem still occurs.
On 8/22/07, Adam Winer [EMAIL PROTECTED] wrote:
On 8/22/07, Simon Lessard [EMAIL PROTECTED] wrote:
I probably found one of the culprits, but it's not the only one as
it
doesn't fix the issue... Since keys in JavaScript structures does
not need
quotes, I changed
FWIW: quotes don't hurt, and they're necessary if your keys
are not valid JS identifiers. If you know your key is a valid
JS identifier, then it's a waste of space, and is worth getting
deleted.
-- Adam
out.writeText(TrPage.getInstance().addStyleClassMap( {', null);
out.writeText(SkinSelectors.AF_PANEL_POPUP_CONTAINER_STYLE_CLASS
+ ':', null);
out.writeText(arc.getStyleClass(
SkinSelectors.AF_PANEL_POPUP_CONTAINER_STYLE_CLASS),
null);
out.writeText(',' +
SkinSelectors.AF_PANEL_POPUP_CONTENT_STYLE_CLASS + ':',
null);
out.writeText(arc.getStyleClass(
SkinSelectors.AF_PANEL_POPUP_CONTENT_STYLE_CLASS),
null);
out.writeText(',' +
SkinSelectors.AF_PANEL_POPUP_TITLE_STYLE_CLASS + ':',
null);
out.writeText(arc.getStyleClass(
SkinSelectors.AF_PANEL_POPUP_TITLE_STYLE_CLASS),
null);
out.writeText(',' +
SkinSelectors.AF_PANEL_POPUP_TITLEBAR_STYLE_CLASS + ':',
null);
out.writeText(arc.getStyleClass(
SkinSelectors.AF_PANEL_POPUP_TITLEBAR_STYLE_CLASS),
null);
out.writeText('} ); , null);
to
out.writeText(TrPage.getInstance().addStyleClassMap( {, null);
out.writeText(SkinSelectors.AF_PANEL_POPUP_CONTAINER_STYLE_CLASS
+ :', null);
out.writeText (arc.getStyleClass(
SkinSelectors.AF_PANEL_POPUP_CONTAINER_STYLE_CLASS),
null);
out.writeText(', +
SkinSelectors.AF_PANEL_POPUP_CONTENT_STYLE_CLASS + :',
null);
out.writeText(arc.getStyleClass(
SkinSelectors.AF_PANEL_POPUP_CONTENT_STYLE_CLASS),
null);
out.writeText(', +
SkinSelectors.AF_PANEL_POPUP_TITLE_STYLE_CLASS + :',
null);
out.writeText(arc.getStyleClass(
SkinSelectors.AF_PANEL_POPUP_TITLE_STYLE_CLASS),
null);
out.writeText(', +
SkinSelectors.AF_PANEL_POPUP_TITLEBAR_STYLE_CLASS + :',
null);
out.writeText(arc.getStyleClass(
SkinSelectors.AF_PANEL_POPUP_TITLEBAR_STYLE_CLASS
), null);
out.writeText('} ); , null);
But, as I said, this is probably not everything that need to be
done as I
still have the issue.
Regards,
~ Simon
On 8/22/07, Simon Lessard [EMAIL PROTECTED] wrote:
Personally, I use JDeveloper 11 to run JSF 1.2.
Also, I got two more issues with the iframe popup as well. One
with
inputDate where the popup get bigger and bigger when I change the
month or
year (I'll have to test navigation in the popup to see if it's
generalized).
The other is that the popup's DIV does not get cleared from the
DOM after
being closed so if you keep selecting a date then reopen the
calendar, the
DOM slowly get bloated.
Regards,
~ Simon
On 8/22/07, Luka Surija [EMAIL PROTECTED] wrote:
The same problem I have with 1.0.3 trunk.
Simon Lessard wrote:
Hello all,
Using latest 1.2.2 branch, I have a problem with iframe
popup skinning
where the style class does not get converted. The markup
looks like:
div style=padding: 0px; overflow: auto; position:
absolute; z-index:
Re: [TRINIDAD] 1.0.3: new PPR features
Hi, Feedback we need: currently, this API is called *after* the DOM replacement has happened, and gives you no way of preventing or overriding the DOM replacement. I'm far from convinced that's the right choice: it might be better to run this before replacement and allow this function to return false;, in which case no replacement would happen. Nice feature, this API. running it up front the replacement, to skip (for instance) might be the right choice. .M Cheers, Adam Winer -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ mail: matzew-at-apache-dot-org
Re: [Trinidad] iframe popup skinning
Found it. It's because the client-side style map isn't initialized by
inputDate, but it is by using a dialog, so once you open a dialog, then
inputDate works. The fix needs some thought as inputDate launches the popup
via _ldp() and not via the dialog framework and hence doesn't have a place
where we can easily insert the style map. Thoughts anyone!
On 8/22/07, Simon Lessard [EMAIL PROTECTED] wrote:
Ok, finally, after numerous stupid mistakes, I can say that the problem
occurs only with inputDate component and not with standard dialogs nor
inputListOfValues. Furthermore, for some even more obscure reasons, if I
ever popup a working dialog (through inputListOfValues or any dialog:xyz
outcome) then inputDate starts to work...
Regards,
~ Simon
On 8/22/07, Simon Lessard [EMAIL PROTECTED] wrote:
Nope, I'm just being stupid as usual and was getting those warning
because I made a typo in the navigation case...
On 8/22/07, Simon Lessard [EMAIL PROTECTED] wrote:
Interesting... inputDate give me the non compressed style classes, and
normal dialog framework give me the following:
ATTENTION: No RenderingContext available
2007-08-22 10:29:51
org.apache.myfaces.trinidad.context.RenderingContext attach
ATTENTION: Trying to attach RenderingContext to a thread that already
had one.
2007-08-22 10:29:51
org.apache.myfaces.trinidadinternal.renderkit.core.CoreRenderKitencodeFinally
ATTENTION: No RenderingContext available
I'll try from a new application rather than a degraded one, just to
see.
On 8/22/07, Simon Lessard [EMAIL PROTECTED] wrote:
Ah, then they're needed in this case since the key contains | and
::. I'm going to degrade to a simpler page and less installed components
(phase listeners and such) to see if the problem still occurs.
On 8/22/07, Adam Winer [EMAIL PROTECTED] wrote:
On 8/22/07, Simon Lessard [EMAIL PROTECTED] wrote:
I probably found one of the culprits, but it's not the only one
as it
doesn't fix the issue... Since keys in JavaScript structures
does not need
quotes, I changed
FWIW: quotes don't hurt, and they're necessary if your keys
are not valid JS identifiers. If you know your key is a valid
JS identifier, then it's a waste of space, and is worth getting
deleted.
-- Adam
out.writeText(TrPage.getInstance().addStyleClassMap( {',
null);
out.writeText(SkinSelectors.AF_PANEL_POPUP_CONTAINER_STYLE_CLASS
+ ':', null);
out.writeText(arc.getStyleClass(
SkinSelectors.AF_PANEL_POPUP_CONTAINER_STYLE_CLASS),
null);
out.writeText(',' +
SkinSelectors.AF_PANEL_POPUP_CONTENT_STYLE_CLASS + ':',
null);
out.writeText(arc.getStyleClass(
SkinSelectors.AF_PANEL_POPUP_CONTENT_STYLE_CLASS),
null);
out.writeText(',' +
SkinSelectors.AF_PANEL_POPUP_TITLE_STYLE_CLASS + ':',
null);
out.writeText(arc.getStyleClass(
SkinSelectors.AF_PANEL_POPUP_TITLE_STYLE_CLASS),
null);
out.writeText(',' +
SkinSelectors.AF_PANEL_POPUP_TITLEBAR_STYLE_CLASS + ':',
null);
out.writeText(arc.getStyleClass(
SkinSelectors.AF_PANEL_POPUP_TITLEBAR_STYLE_CLASS),
null);
out.writeText('} ); , null);
to
out.writeText(TrPage.getInstance().addStyleClassMap( {, null);
out.writeText(SkinSelectors.AF_PANEL_POPUP_CONTAINER_STYLE_CLASS
+ :', null);
out.writeText (arc.getStyleClass(
SkinSelectors.AF_PANEL_POPUP_CONTAINER_STYLE_CLASS),
null);
out.writeText(', +
SkinSelectors.AF_PANEL_POPUP_CONTENT_STYLE_CLASS + :',
null);
out.writeText(arc.getStyleClass(
SkinSelectors.AF_PANEL_POPUP_CONTENT_STYLE_CLASS),
null);
out.writeText(', +
SkinSelectors.AF_PANEL_POPUP_TITLE_STYLE_CLASS + :',
null);
out.writeText(arc.getStyleClass(
SkinSelectors.AF_PANEL_POPUP_TITLE_STYLE_CLASS),
null);
out.writeText(', +
SkinSelectors.AF_PANEL_POPUP_TITLEBAR_STYLE_CLASS + :',
null);
out.writeText(arc.getStyleClass(
SkinSelectors.AF_PANEL_POPUP_TITLEBAR_STYLE_CLASS
), null);
out.writeText('} ); , null);
But, as I said, this is probably not everything that need to be
done as I
still have the issue.
Regards,
~ Simon
On 8/22/07, Simon Lessard [EMAIL PROTECTED] wrote:
Personally, I use JDeveloper 11 to run JSF 1.2.
Also, I got two more issues with the iframe popup as well. One
with
inputDate where the popup get bigger and bigger when I change
the month or
year (I'll have to test navigation in the popup to see if it's
generalized).
The other is that the popup's DIV does not get cleared from the
DOM after
being closed so if you keep selecting a date then
Re: MyFaces 1.2 have problems with enum
Hello,
You need to use a converter.
For my project, Cobia, I have built
a generic enum converter and enum
UISelectItems component/tag.
These are used like this:
h:selectOneRadio value=#{form.education}
layout=pageDirection
cobia:enumSelectItems type=org.example.EducationEnum/
cobia:enumConverter type=org.example.EducationEnum/
/h:selectOneRadio
The 'type' attribute is the fully-qualified
class name for the enum type. These mechanisms
use resource bundles for I18N support.
If you don't need such flexibility,
then I would recommend building your
own Converter specifically for the
Education enum. However, if you use
a lot of enums that are exposed in the
UI, then you will probably want to invest
in a more general solution.
Contact me personally if you want to see
the Cobia code for this.
Regards,
Bryan
Re: MyFaces 1.2 have problems with enum
Hello Bryan,
Actually, in JSF 1.2, enums should be natively supported I think. Let me
check the spec some more to be sure.
Regards,
~ Simon
On 8/22/07, Bryan Basham [EMAIL PROTECTED] wrote:
Hello,
You need to use a converter.
For my project, Cobia, I have built
a generic enum converter and enum
UISelectItems component/tag.
These are used like this:
h:selectOneRadio value=#{form.education}
layout=pageDirection
cobia:enumSelectItems type=org.example.EducationEnum/
cobia:enumConverter type=org.example.EducationEnum/
/h:selectOneRadio
The 'type' attribute is the fully-qualified
class name for the enum type. These mechanisms
use resource bundles for I18N support.
If you don't need such flexibility,
then I would recommend building your
own Converter specifically for the
Education enum. However, if you use
a lot of enums that are exposed in the
UI, then you will probably want to invest
in a more general solution.
Contact me personally if you want to see
the Cobia code for this.
Regards,
Bryan
Re: [TRINIDAD] 1.0.3: new PPR features
Sounds great Adam
Any idea on the time line of a 1.0.3 release?
On 8/21/07, Adam Winer [EMAIL PROTECTED] wrote:
Just added:
- PPR should be a good bit more efficient, as most input + output
components will not render anything unless they are being PPR'd,
and tables, trees, treeTables, navigationPanes and trains
will be entirely skipped unless they or one of their contents
is being PPR'd.
Until now, PPR rendered everything and a ResponseWriter trimmed
out what shouldn't be rendered. That's still the case in part, but
we can now entirely skip some branches of the UIComponent hierarchy.
(The client validation code had to be somewhat overhauled to make
this possible.)
- A new addDomReplaceListener() method provides notification
of DOM changes from PPR. A trivial example is:
function notePpr(oldDom, newDom)
{
console.log(old, oldDom);
console.log(new, newDom);
}
TrPage.getInstance().addDomReplaceListener(notePpr);
... which logs to Firebug any DOM elements that have been
added or removed.
Feedback we need: currently, this API is called *after*
the DOM replacement has happened, and gives you no
way of preventing or overriding the DOM replacement. I'm
far from convinced that's the right choice: it might be better
to run this before replacement and allow this function to return
false;, in which case no replacement would happen.
Cheers,
Adam Winer
Re: [TRINIDAD] 1.0.3: new PPR features
Excellent!
Will 1.0.3 include real AJAX like 1.2.1? Or AJAX is not intented to be a
part of the JSF 1.1 branch?
On 8/22/07, Andrew Robinson [EMAIL PROTECTED] wrote:
Sounds great Adam
Any idea on the time line of a 1.0.3 release?
On 8/21/07, Adam Winer [EMAIL PROTECTED] wrote:
Just added:
- PPR should be a good bit more efficient, as most input + output
components will not render anything unless they are being PPR'd,
and tables, trees, treeTables, navigationPanes and trains
will be entirely skipped unless they or one of their contents
is being PPR'd.
Until now, PPR rendered everything and a ResponseWriter trimmed
out what shouldn't be rendered. That's still the case in part, but
we can now entirely skip some branches of the UIComponent hierarchy.
(The client validation code had to be somewhat overhauled to make
this possible.)
- A new addDomReplaceListener() method provides notification
of DOM changes from PPR. A trivial example is:
function notePpr(oldDom, newDom)
{
console.log(old, oldDom);
console.log(new, newDom);
}
TrPage.getInstance().addDomReplaceListener(notePpr);
... which logs to Firebug any DOM elements that have been
added or removed.
Feedback we need: currently, this API is called *after*
the DOM replacement has happened, and gives you no
way of preventing or overriding the DOM replacement. I'm
far from convinced that's the right choice: it might be better
to run this before replacement and allow this function to return
false;, in which case no replacement would happen.
Cheers,
Adam Winer
Which components to use?
Hello, I know this kind of question is sometimes annoying, but with so much components being created and enhancements on the existing ones, it is hard to make a decision, in a formal process, for the components to start an professional enteprise application. We are using Spring, then I think it could be a clue in which directions we could go. I am thinking in MyFaces with its variations: Trinidad, Tomahawk, etc. Another alternative would be to use Seam integrating with Myfaces and Spring, but I am not sure about how it has been working in production. The main aspect here, is that I would not like to start with a componet, and suddenly find that there are so many bugs to be corrected or there are limitation to integrate with other components to provide more features. You people, that have been working with those components in production (or at least close to it), would you mind to share you thought? Thank you very much. Be a better Globetrotter. Get better travel answers from someone who knows. Yahoo! Answers - Check it out. http://answers.yahoo.com/dir/?link=listsid=396545469
Re: Different validations for different command links
Use the sandbox subForm component. Each subform can perform custom partial validation. On 8/22/07, Nikhil Gahlot [EMAIL PROTECTED] wrote: I have used myfaces-1.1.2 and sandbox-1.1.2 in my application. I have created a form which has many command links/buttons for different actions (add entry, delete entry and save). I am also using validations for various input fields. But I want to make these validations applicable only to SAVE action, others to bypass all the validations. I have tried with immediate=true but all the entered data get lost. And if I use custom validator which I thought to check the nature of action while applying validations, it doesnt work on empty fields even if I remove required=true. Is there a way to write custom validator for 'required validation'? or How can i bypass validation for an action(other than cancel action) as I need model values to be persisted? Thanks Nikhil -- View this message in context: http://www.nabble.com/Different-validations-for-different-command-links-tf4309598.html#a12268674 Sent from the MyFaces - Users mailing list archive at Nabble.com.
[Trinidad] Simple skinning question - inputText
Hello all! I intend to know what I need to define in my skin to be able to do something like this. If I use: tr:inputText styleClass=inputStyle1 I want my inputText label to be bold. And if I use: tr:inputText styleClass=inputStyle2 I want my inputText label to not be bold. I know that I can use the css class af|inputText::label to define global inputText behaviour. But in this case, I want to define specific behaviour. I chose this example, because it clearly illustrates my need to have more than one kind of component style within the same skin.
Re: MyFaces 1.2 have problems with enum
yeah,
there is already a bug, with a patch too.
need to apply next days.
On 8/22/07, Simon Lessard [EMAIL PROTECTED] wrote:
Hello Bryan,
Actually, in JSF 1.2, enums should be natively supported I think. Let me
check the spec some more to be sure.
Regards,
~ Simon
On 8/22/07, Bryan Basham [EMAIL PROTECTED] wrote:
Hello,
You need to use a converter.
For my project, Cobia, I have built
a generic enum converter and enum
UISelectItems component/tag.
These are used like this:
h:selectOneRadio value=#{form.education}
layout=pageDirection
cobia:enumSelectItems type=org.example.EducationEnum/
cobia:enumConverter type=org.example.EducationEnum/
/h:selectOneRadio
The 'type' attribute is the fully-qualified
class name for the enum type. These mechanisms
use resource bundles for I18N support.
If you don't need such flexibility,
then I would recommend building your
own Converter specifically for the
Education enum. However, if you use
a lot of enums that are exposed in the
UI, then you will probably want to invest
in a more general solution.
Contact me personally if you want to see
the Cobia code for this.
Regards,
Bryan
--
Matthias Wessendorf
further stuff:
blog: http://matthiaswessendorf.wordpress.com/
mail: matzew-at-apache-dot-org
Re: [TRINIDAD] 1.0.3: new PPR features
Hello Francisco,
Release 1.0.2 includes real AJAX already. For now, new features are always
mirrored in both JSF 1.1 and 1.2, matching with the last release number
digit. i.e. features in 1.0.2 can be also found in 1.2.2.
Regards,
~ Simon
On 8/22/07, Francisco Passos [EMAIL PROTECTED] wrote:
Excellent!
Will 1.0.3 include real AJAX like 1.2.1? Or AJAX is not intented to be a
part of the JSF 1.1 branch?
On 8/22/07, Andrew Robinson [EMAIL PROTECTED] wrote:
Sounds great Adam
Any idea on the time line of a 1.0.3 release?
On 8/21/07, Adam Winer [EMAIL PROTECTED] wrote:
Just added:
- PPR should be a good bit more efficient, as most input + output
components will not render anything unless they are being PPR'd,
and tables, trees, treeTables, navigationPanes and trains
will be entirely skipped unless they or one of their contents
is being PPR'd.
Until now, PPR rendered everything and a ResponseWriter trimmed
out what shouldn't be rendered. That's still the case in part, but
we can now entirely skip some branches of the UIComponent hierarchy.
(The client validation code had to be somewhat overhauled to make
this possible.)
- A new addDomReplaceListener() method provides notification
of DOM changes from PPR. A trivial example is:
function notePpr(oldDom, newDom)
{
console.log(old, oldDom);
console.log(new, newDom);
}
TrPage.getInstance().addDomReplaceListener(notePpr);
... which logs to Firebug any DOM elements that have been
added or removed.
Feedback we need: currently, this API is called *after*
the DOM replacement has happened, and gives you no
way of preventing or overriding the DOM replacement. I'm
far from convinced that's the right choice: it might be better
to run this before replacement and allow this function to return
false;, in which case no replacement would happen.
Cheers,
Adam Winer
Re: [TRINIDAD] 1.0.3: new PPR features
Hi,
102 release does.
1.2.2 (for JSF 1.2) as well
-M
On 8/22/07, Francisco Passos [EMAIL PROTECTED] wrote:
Excellent!
Will 1.0.3 include real AJAX like 1.2.1? Or AJAX is not intented to be a
part of the JSF 1.1 branch?
On 8/22/07, Andrew Robinson [EMAIL PROTECTED] wrote:
Sounds great Adam
Any idea on the time line of a 1.0.3 release?
On 8/21/07, Adam Winer [EMAIL PROTECTED] wrote:
Just added:
- PPR should be a good bit more efficient, as most input + output
components will not render anything unless they are being PPR'd,
and tables, trees, treeTables, navigationPanes and trains
will be entirely skipped unless they or one of their contents
is being PPR'd.
Until now, PPR rendered everything and a ResponseWriter trimmed
out what shouldn't be rendered. That's still the case in part, but
we can now entirely skip some branches of the UIComponent hierarchy.
(The client validation code had to be somewhat overhauled to make
this possible.)
- A new addDomReplaceListener() method provides notification
of DOM changes from PPR. A trivial example is:
function notePpr(oldDom, newDom)
{
console.log(old, oldDom);
console.log(new, newDom);
}
TrPage.getInstance().addDomReplaceListener(notePpr);
... which logs to Firebug any DOM elements that have been
added or removed.
Feedback we need: currently, this API is called *after*
the DOM replacement has happened, and gives you no
way of preventing or overriding the DOM replacement. I'm
far from convinced that's the right choice: it might be better
to run this before replacement and allow this function to return
false;, in which case no replacement would happen.
Cheers,
Adam Winer
--
Matthias Wessendorf
further stuff:
blog: http://matthiaswessendorf.wordpress.com/
mail: matzew-at-apache-dot-org
Re: [TRINIDAD] 1.0.3: new PPR features
currently we run the 1.2.2
some more days/weeks after 1.2.2, to test 1.0.3 I think..
On 8/22/07, Andrew Robinson [EMAIL PROTECTED] wrote:
Sounds great Adam
Any idea on the time line of a 1.0.3 release?
On 8/21/07, Adam Winer [EMAIL PROTECTED] wrote:
Just added:
- PPR should be a good bit more efficient, as most input + output
components will not render anything unless they are being PPR'd,
and tables, trees, treeTables, navigationPanes and trains
will be entirely skipped unless they or one of their contents
is being PPR'd.
Until now, PPR rendered everything and a ResponseWriter trimmed
out what shouldn't be rendered. That's still the case in part, but
we can now entirely skip some branches of the UIComponent hierarchy.
(The client validation code had to be somewhat overhauled to make
this possible.)
- A new addDomReplaceListener() method provides notification
of DOM changes from PPR. A trivial example is:
function notePpr(oldDom, newDom)
{
console.log(old, oldDom);
console.log(new, newDom);
}
TrPage.getInstance().addDomReplaceListener(notePpr);
... which logs to Firebug any DOM elements that have been
added or removed.
Feedback we need: currently, this API is called *after*
the DOM replacement has happened, and gives you no
way of preventing or overriding the DOM replacement. I'm
far from convinced that's the right choice: it might be better
to run this before replacement and allow this function to return
false;, in which case no replacement would happen.
Cheers,
Adam Winer
--
Matthias Wessendorf
further stuff:
blog: http://matthiaswessendorf.wordpress.com/
mail: matzew-at-apache-dot-org
Re: [Trinidad] Simple skinning question - inputText
I haven't tested this but I believe this should be valid:
tr:inputText styleClass=inputStyle1 label=I a bold label value=test/
tr:inputText styleClass=inputStyle2 label=I a non-bold label
value=test/
af|inputText.inputStyle1 af|inputText::label {
font-weight: bold;
}
As long as the styleClass gets applied to the root DOM element of the
inputText, that root DOM element also has af|inputText as its default
style class, then this should work. If that isn't the case then we can
investigate alternatives.
Thanks,
Matt
On 8/22/07, Francisco Passos [EMAIL PROTECTED] wrote:
Hello all!
I intend to know what I need to define in my skin to be able to do
something like this.
If I use:
tr:inputText styleClass=inputStyle1
I want my inputText label to be bold.
And if I use:
tr:inputText styleClass=inputStyle2
I want my inputText label to not be bold.
I know that I can use the css class af|inputText::label to define global
inputText behaviour.
But in this case, I want to define specific behaviour. I chose this
example, because it clearly illustrates my need to have more than one kind
of component style within the same skin.
Re: Testing JSF 1.2 Managed Beans vs. JSF 1.1
It seems I need jsp-api 2.1 in my classpath or I get the following error: java.lang.NoClassDefFoundError: javax/el/ELResolver After I add that in, I get the following error. Adding/removing commons-el doesn't seem to have an effect. My BasePageTestCase is at http://tinyurl.com/yv68y7. ERROR - DefaultFacesInitializer.initFaces(126) | Error initializing MyFaces: null java.lang.NullPointerException at org.apache.myfaces.webapp.DefaultFacesInitializer.initFaces(DefaultFacesInitializer.java:102) at org.apache.myfaces.webapp.StartupServletContextListener.contextInitialized(StartupServletContextListener.java:57) at org.appfuse.web.BasePageTestCase.performFacesContextConfig(BasePageTestCase.java:57) I'd love to develop a BasePageTestCase that's a bit more implementation agnostic, but that seems somewhat difficult to do. Matt Werner Punz-2 wrote: Ok Matt I ran into a similar problem in a testmigration of an old project to myfaces 1.2. Following, make sure that you are on a current container version implementing the newest jsp and servlet apis (in my case tomcat running on java 5) then remove all traces to the jsp-api and any el-implementation (however commons-el has to be still there if you use tomahawk otherwise you will get an error, tomahawk references commons-el logger somewhere) if done it should work. The main problem with the migration is that old installs relied on a hogde podge of various deps into el implementations and servlet specs, 1.2 is pure jee5 so any older version of the servlet spec or el or jsp in your runtime classpath is a source of possible problems. mraible schrieb: I had the following BasePageTestCase class that I've been using to test my JSF 1.1 pages. Unfortunately, after upgrading to JSF 1.2, it no longer works. Here's the stack trace: ERROR - DefaultFacesInitializer.initFaces(126) | Error initializing MyFaces: null java.lang.NullPointerException at org.apache.myfaces.webapp.DefaultFacesInitializer.initFaces(DefaultFacesInitializer.java:102) at org.apache.myfaces.webapp.StartupServletContextListener.contextInitialized(StartupServletContextListener.java:57) at org.appfuse.web.BasePageTestCase.performFacesContextConfig(BasePageTestCase.java:58) at org.appfuse.web.BasePageTestCase.clinit(BasePageTestCase.java:50) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) org.apache.maven.surefire.booter.SurefireExecutionException: org.appfuse.web.UserFormTest; nested exception is java.lang.ExceptionInInitializerError: null; nested exception is org.apache.maven.surefire.testset.TestSetFailedException: org.appfuse.web.UserFormTest; nested exception is java.lang.ExceptionInInitializerError: null org.apache.maven.surefire.testset.TestSetFailedException: org.appfuse.web.UserFormTest; nested exception is java.lang.ExceptionInInitializerError: null java.lang.ExceptionInInitializerError at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) at java.lang.reflect.Constructor.newInstance(Constructor.java:494) at junit.framework.TestSuite.createTest(TestSuite.java:54) at junit.framework.TestSuite.addTestMethod(TestSuite.java:280) at junit.framework.TestSuite.init(TestSuite.java:140) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) at java.lang.reflect.Constructor.newInstance(Constructor.java:494) at org.apache.maven.surefire.junit.JUnitTestSet.constructTestObject(JUnitTestSet.java:151) at org.apache.maven.surefire.junit.JUnitTestSet.getTestCount(JUnitTestSet.java:247) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.locateTestSets(AbstractDirectoryTestSuite.java:104) at org.apache.maven.surefire.Surefire.createSuiteFromDefinition(Surefire.java:150) at org.apache.maven.surefire.Surefire.run(Surefire.java:111) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at
panelTabbedPane selectedIndex ignored
We have an application that uses tabbed panes to edit different sections of data records. For example one panel is for managing addresses while another has account information. An initial summary tab is show that allows a user to choose an activity which will submit the value, which renders the associated edit tab and makes it active using a selectedIndex bind variable. When the application is first loaded, this logic works well, the selectedIndex is respected and the correct tab displays properly. However, we've noticed that if a user clicks on a tab during the edit process, subsequent submits and re-rendering totally ignores the selectedIndex variable, and instead goes back to the previously selected tab, even though the selectedIndex bind variable is set to something else. Is this something that would be better handled by binding the Panel to a backing bean and setting an index variable there? I've overcome this with other controls by using this approach, or by nulling out the submitted value to force a JSF refresh from the model after re-rendering. Is there a correct way to force a tab index programmatically even if a user has manually picked a tab in the client. We are using server-side switching with this tab. -- View this message in context: http://www.nabble.com/panelTabbedPane-selectedIndex-ignored-tf4313361.html#a12280566 Sent from the MyFaces - Users mailing list archive at Nabble.com.
Re: [Trinidad] Skinnning dev guide now available!
Hi Jeanne, This looks great! Do you think we need to call out that *-tr-inhibit* will only perform server-side inhibiting; it will not inhibit styles that resolve in the browser bases on things like selector specificity. Thank you, Matt On 8/22/07, Jeanne Waldman [EMAIL PROTECTED] wrote: Hi there, I finally took some time to put together a skinning dev guide. This is the first draft. I'll give myself a break from looking at it and then proofread it, unless anyone else wants to. :) Feel free to give suggestions on new sections or sections that are confusing. You can create a JIRA issue if you want. The link is: http://myfaces.apache.org/trinidad/devguide/skinning.html I just noticed that I didn't link to it from the devguide's index page. I'll look into doing that right now. - Jeanne
Re: [Trinidad] Skinnning dev guide now available!
Looks great Jeanne, much needed. Next step if for us to get the skin selectors reference page back up-to-date and linked into the docs. On 8/22/07, Matt Cooper [EMAIL PROTECTED] wrote: Hi Jeanne, This looks great! Do you think we need to call out that *-tr-inhibit* will only perform server-side inhibiting; it will not inhibit styles that resolve in the browser bases on things like selector specificity. Thank you, Matt On 8/22/07, Jeanne Waldman [EMAIL PROTECTED] wrote: Hi there, I finally took some time to put together a skinning dev guide. This is the first draft. I'll give myself a break from looking at it and then proofread it, unless anyone else wants to. :) Feel free to give suggestions on new sections or sections that are confusing. You can create a JIRA issue if you want. The link is: http://myfaces.apache.org/trinidad/devguide/skinning.html I just noticed that I didn't link to it from the devguide's index page. I'll look into doing that right now. - Jeanne -- Chordiant Software Inc. www.chordiant.com
[Trinidad] How to skin tr:table
Is it possible to skin tr:table?
When a tr:table is rendered, should it add the class=af_table_content? I
expected that class to be added to the component - but it is not added.
I am trying to add width: 100% to some tables (and not others).
Thoughts?
I am using trinidad 1.0.0.
I have the following snippet:
tr:panelGroupLayout layout=vertical
tr:panelHorizontalLayout
f:facet name=separatortr:spacer width=8px//f:facet
tr:panelHeader text=Credit Cards/
tr:panelButtonBar
tr:commandLink action=#{editor.new} value=Add
/tr:panelButtonBar
/tr:panelHorizontalLayout
tr:table var=pm
value=#{cards}
id=tbl_paymethod
tr:column headerText=Card Name
tr:outputText value=#{pm.name}/
/tr:column
/tr:table
/tr:panelGroupLayout
Chris
Re: [Trinidad] Skinnning dev guide now available!
Thank you very much, appreciate it. One note, I see that it says that changes should be picked up on the fly, but I have seen that is not true with icons. I have to restart my application to get changes to the icons picked up. Is this true, or is there something I am missing? -Andrew On 8/22/07, Danny Robinson [EMAIL PROTECTED] wrote: Looks great Jeanne, much needed. Next step if for us to get the skin selectors reference page back up-to-date and linked into the docs. On 8/22/07, Matt Cooper [EMAIL PROTECTED] wrote: Hi Jeanne, This looks great! Do you think we need to call out that -tr-inhibit will only perform server-side inhibiting; it will not inhibit styles that resolve in the browser bases on things like selector specificity. Thank you, Matt On 8/22/07, Jeanne Waldman [EMAIL PROTECTED] wrote: Hi there, I finally took some time to put together a skinning dev guide. This is the first draft. I'll give myself a break from looking at it and then proofread it, unless anyone else wants to. :) Feel free to give suggestions on new sections or sections that are confusing. You can create a JIRA issue if you want. The link is: http://myfaces.apache.org/trinidad/devguide/skinning.html I just noticed that I didn't link to it from the devguide's index page. I'll look into doing that right now. - Jeanne -- Chordiant Software Inc. www.chordiant.com
[Trinidad] Upgrading to 1.0.2
Hi, I'm testing my project with 1.0.2 and I am having several issues. 1. No PPR activity works, I get a javascript error Invalid PPR response any time I try to submit a PPR action Can anyone give me a clue as to what's wrong and how to fix it? 2. My skin no longer works, it seems that a few of the selectors have changed, namely: a) the panelHeader is rendering with af_messages_header class b) the panelBox has lost its background, it seems like there is no longer a distinction between panelBox transparent, light, etc. I looked at the JIRA issues attached to the 1.0.2 release and did not see an obvious item that applied to either of these discoveriescan anyone verify exactly what it was that changed for each of these? Nate Perkins 480-441-3667 [EMAIL PROTECTED] This email message is for the sole use of the intended recipient(s) and may contain GDC4S confidential or privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not an intended recipient, please contact the sender by reply email and destroy all copies of the original message.
RE: [Trinidad] Upgrading to 1.0.2
I should note that everything worked correctly using 1.0.1. Nate Perkins 480-441-3667 [EMAIL PROTECTED] This email message is for the sole use of the intended recipient(s) and may contain GDC4S confidential or privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not an intended recipient, please contact the sender by reply email and destroy all copies of the original message. From: Perkins, Nate-P63196 [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 22, 2007 12:31 PM To: MyFaces Discussion Subject: [Trinidad] Upgrading to 1.0.2 Hi, I'm testing my project with 1.0.2 and I am having several issues. 1. No PPR activity works, I get a javascript error Invalid PPR response any time I try to submit a PPR action Can anyone give me a clue as to what's wrong and how to fix it? 2. My skin no longer works, it seems that a few of the selectors have changed, namely: a) the panelHeader is rendering with af_messages_header class b) the panelBox has lost its background, it seems like there is no longer a distinction between panelBox transparent, light, etc. I looked at the JIRA issues attached to the 1.0.2 release and did not see an obvious item that applied to either of these discoveriescan anyone verify exactly what it was that changed for each of these? Nate Perkins 480-441-3667 [EMAIL PROTECTED] This email message is for the sole use of the intended recipient(s) and may contain GDC4S confidential or privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not an intended recipient, please contact the sender by reply email and destroy all copies of the original message.
Re: [Trinidad] How to skin tr:table
Here is the HTML that is generated (edited for readability?):
div id=tbl_paymethod
table cellspacing=0 cellpadding=0 border=0 summary=
tbody
tr
td
table width=100% cellspacing=0 cellpadding=1 border=0
class=af_table_content
tbody
tr
th class=af_column_header-text OraTableBorder0001
scope=colCard Name
/th
/tr
tr
tdVANNA WHITE/td
/tr
/tbody
/table
/td
/tr
/tbody
/table
/div
I noticed that two tables are created. The inner one contains that correct
skin: af_table_content. It is the outer one that I need to set the width:
100% on.
Is this possible?
I can't seem to figure out which component is generating the second, outer
table.
Thanks,
Chris
Chris Hane wrote:
Is it possible to skin tr:table?
When a tr:table is rendered, should it add the
class=af_table_content? I expected that class to be added to the
component - but it is not added.
I am trying to add width: 100% to some tables (and not others).
Thoughts?
I am using trinidad 1.0.0.
I have the following snippet:
tr:panelGroupLayout layout=vertical
tr:panelHorizontalLayout
f:facet name=separatortr:spacer width=8px//f:facet
tr:panelHeader text=Credit Cards/
tr:panelButtonBar
tr:commandLink action=#{editor.new} value=Add
/tr:panelButtonBar
/tr:panelHorizontalLayout
tr:table var=pm
value=#{cards}
id=tbl_paymethod
tr:column headerText=Card Name
tr:outputText value=#{pm.name}/
/tr:column
/tr:table
/tr:panelGroupLayout
Chris
RE: [Trinidad] How to skin tr:table
Have you tried to set the width attribute of the tr:table to 100%? I
think that will occur on the outer table.
Nate Perkins
480-441-3667
[EMAIL PROTECTED]
This email message is for the sole use of the intended recipient(s) and
may contain GDC4S
confidential or privileged information. Any unauthorized review, use,
disclosure or distribution
is prohibited. If you are not an intended recipient, please contact
the sender by reply email and
destroy all copies of the original message.
-Original Message-
From: Chris Hane [mailto:[EMAIL PROTECTED]
Sent: Wednesday, August 22, 2007 12:38 PM
To: MyFaces Discussion
Subject: Re: [Trinidad] How to skin tr:table
Here is the HTML that is generated (edited for readability?):
div id=tbl_paymethod
table cellspacing=0 cellpadding=0 border=0 summary=
tbody
tr
td
table width=100% cellspacing=0 cellpadding=1 border=0
class=af_table_content
tbody
tr
th class=af_column_header-text OraTableBorder0001
scope=colCard Name
/th
/tr
tr
tdVANNA WHITE/td
/tr
/tbody
/table
/td
/tr
/tbody
/table
/div
I noticed that two tables are created. The inner one contains that
correct
skin: af_table_content. It is the outer one that I need to set the
width:
100% on.
Is this possible?
I can't seem to figure out which component is generating the second,
outer
table.
Thanks,
Chris
Chris Hane wrote:
Is it possible to skin tr:table?
When a tr:table is rendered, should it add the
class=af_table_content? I expected that class to be added to the
component - but it is not added.
I am trying to add width: 100% to some tables (and not others).
Thoughts?
I am using trinidad 1.0.0.
I have the following snippet:
tr:panelGroupLayout layout=vertical
tr:panelHorizontalLayout
f:facet name=separatortr:spacer width=8px//f:facet
tr:panelHeader text=Credit Cards/
tr:panelButtonBar
tr:commandLink action=#{editor.new} value=Add
/tr:panelButtonBar
/tr:panelHorizontalLayout
tr:table var=pm
value=#{cards}
id=tbl_paymethod
tr:column headerText=Card Name
tr:outputText value=#{pm.name}/
/tr:column
/tr:table
/tr:panelGroupLayout
Chris
Re: [Trinidad] Skinnning dev guide now available!
yes, that's true. I'll have to update that. Anything that gets registered with the Skin object needs a server-restart (icons, skin-properties). Styles don't. - Jeanne Andrew Robinson wrote: Thank you very much, appreciate it. One note, I see that it says that changes should be picked up on the fly, but I have seen that is not true with icons. I have to restart my application to get changes to the icons picked up. Is this true, or is there something I am missing? -Andrew On 8/22/07, Danny Robinson [EMAIL PROTECTED] wrote: Looks great Jeanne, much needed. Next step if for us to get the skin selectors reference page back up-to-date and linked into the docs. On 8/22/07, Matt Cooper [EMAIL PROTECTED] wrote: Hi Jeanne, This looks great! Do you think we need to call out that -tr-inhibit will only perform server-side inhibiting; it will not inhibit styles that resolve in the browser bases on things like selector specificity. Thank you, Matt On 8/22/07, Jeanne Waldman [EMAIL PROTECTED] wrote: Hi there, I finally took some time to put together a skinning dev guide. This is the first draft. I'll give myself a break from looking at it and then proofread it, unless anyone else wants to. :) Feel free to give suggestions on new sections or sections that are confusing. You can create a JIRA issue if you want. The link is: http://myfaces.apache.org/trinidad/devguide/skinning.html I just noticed that I didn't link to it from the devguide's index page. I'll look into doing that right now. - Jeanne -- Chordiant Software Inc. www.chordiant.com
Re: [Trinidad] Skinnning dev guide now available!
Hi Matt, Can you elaborate so I'm sure what you are saying? Thanks, Jeanne Matt Cooper wrote: Hi Jeanne, This looks great! Do you think we need to call out that -tr-inhibit will only perform server-side inhibiting; it will not inhibit styles that resolve in the browser bases on things like selector specificity. Thank you, Matt On 8/22/07, Jeanne Waldman [EMAIL PROTECTED] wrote: Hi there, I finally took some time to put together a skinning dev guide. This is the first draft. I'll give myself a break from looking at it and then proofread it, unless anyone else wants to. :) Feel free to give suggestions on new sections or sections that are confusing. You can create a JIRA issue if you want. The link is: http://myfaces.apache.org/trinidad/devguide/skinning.html I just noticed that I didn't link to it from the devguide's index page. I'll look into doing that right now. - Jeanne
Re: [Trinidad] How to skin tr:table
Nate,
Thanks for the suggestion. That works like a charm. And we can use it as
a workaround.
However, I was hoping to be able to do this in the CSS skin file with the
correct selectors. Maybe it is not possible?
Thanks again for your help. I appreciate it.
Chris
Perkins, Nate-P63196 wrote:
Have you tried to set the width attribute of the tr:table to 100%? I
think that will occur on the outer table.
Nate Perkins
480-441-3667
[EMAIL PROTECTED]
This email message is for the sole use of the intended recipient(s) and
may contain GDC4S
confidential or privileged information. Any unauthorized review, use,
disclosure or distribution
is prohibited. If you are not an intended recipient, please contact
the sender by reply email and
destroy all copies of the original message.
-Original Message-
From: Chris Hane [mailto:[EMAIL PROTECTED]
Sent: Wednesday, August 22, 2007 12:38 PM
To: MyFaces Discussion
Subject: Re: [Trinidad] How to skin tr:table
Here is the HTML that is generated (edited for readability?):
div id=tbl_paymethod
table cellspacing=0 cellpadding=0 border=0 summary=
tbody
tr
td
table width=100% cellspacing=0 cellpadding=1 border=0
class=af_table_content
tbody
tr
th class=af_column_header-text OraTableBorder0001
scope=colCard Name
/th
/tr
tr
tdVANNA WHITE/td
/tr
/tbody
/table
/td
/tr
/tbody
/table
/div
I noticed that two tables are created. The inner one contains that
correct
skin: af_table_content. It is the outer one that I need to set the
width:
100% on.
Is this possible?
I can't seem to figure out which component is generating the second,
outer
table.
Thanks,
Chris
Chris Hane wrote:
Is it possible to skin tr:table?
When a tr:table is rendered, should it add the
class=af_table_content? I expected that class to be added to the
component - but it is not added.
I am trying to add width: 100% to some tables (and not others).
Thoughts?
I am using trinidad 1.0.0.
I have the following snippet:
tr:panelGroupLayout layout=vertical
tr:panelHorizontalLayout
f:facet name=separatortr:spacer width=8px//f:facet
tr:panelHeader text=Credit Cards/
tr:panelButtonBar
tr:commandLink action=#{editor.new} value=Add
/tr:panelButtonBar
/tr:panelHorizontalLayout
tr:table var=pm
value=#{cards}
id=tbl_paymethod
tr:column headerText=Card Name
tr:outputText value=#{pm.name}/
/tr:column
/tr:table
/tr:panelGroupLayout
Chris
RE: [Trinidad] How to skin tr:table
I don't believe it is currently possible and would require a
rearrangement or the table skinning capabilities, but I agree with you
that it ought to be possibleperhaps a JIRA for an improvement?
Nate Perkins
480-441-3667
[EMAIL PROTECTED]
This email message is for the sole use of the intended recipient(s) and
may contain GDC4S
confidential or privileged information. Any unauthorized review, use,
disclosure or distribution
is prohibited. If you are not an intended recipient, please contact
the sender by reply email and
destroy all copies of the original message.
-Original Message-
From: Chris Hane [mailto:[EMAIL PROTECTED]
Sent: Wednesday, August 22, 2007 12:53 PM
To: MyFaces Discussion
Subject: Re: [Trinidad] How to skin tr:table
Nate,
Thanks for the suggestion. That works like a charm. And we can use it
as
a workaround.
However, I was hoping to be able to do this in the CSS skin file with
the
correct selectors. Maybe it is not possible?
Thanks again for your help. I appreciate it.
Chris
Perkins, Nate-P63196 wrote:
Have you tried to set the width attribute of the tr:table to 100%? I
think that will occur on the outer table.
Nate Perkins
480-441-3667
[EMAIL PROTECTED]
This email message is for the sole use of the intended recipient(s)
and
may contain GDC4S
confidential or privileged information. Any unauthorized review, use,
disclosure or distribution
is prohibited. If you are not an intended recipient, please contact
the sender by reply email and
destroy all copies of the original message.
-Original Message-
From: Chris Hane [mailto:[EMAIL PROTECTED]
Sent: Wednesday, August 22, 2007 12:38 PM
To: MyFaces Discussion
Subject: Re: [Trinidad] How to skin tr:table
Here is the HTML that is generated (edited for readability?):
div id=tbl_paymethod
table cellspacing=0 cellpadding=0 border=0 summary=
tbody
tr
td
table width=100% cellspacing=0 cellpadding=1
border=0
class=af_table_content
tbody
tr
th class=af_column_header-text OraTableBorder0001
scope=colCard Name
/th
/tr
tr
tdVANNA WHITE/td
/tr
/tbody
/table
/td
/tr
/tbody
/table
/div
I noticed that two tables are created. The inner one contains that
correct
skin: af_table_content. It is the outer one that I need to set the
width:
100% on.
Is this possible?
I can't seem to figure out which component is generating the second,
outer
table.
Thanks,
Chris
Chris Hane wrote:
Is it possible to skin tr:table?
When a tr:table is rendered, should it add the
class=af_table_content? I expected that class to be added to the
component - but it is not added.
I am trying to add width: 100% to some tables (and not others).
Thoughts?
I am using trinidad 1.0.0.
I have the following snippet:
tr:panelGroupLayout layout=vertical
tr:panelHorizontalLayout
f:facet name=separatortr:spacer width=8px//f:facet
tr:panelHeader text=Credit Cards/
tr:panelButtonBar
tr:commandLink action=#{editor.new} value=Add
/tr:panelButtonBar
/tr:panelHorizontalLayout
tr:table var=pm
value=#{cards}
id=tbl_paymethod
tr:column headerText=Card Name
tr:outputText value=#{pm.name}/
/tr:column
/tr:table
/tr:panelGroupLayout
Chris
Re: [Trinidad] Upgrading to 1.0.2
On 8/22/07, Perkins, Nate-P63196 [EMAIL PROTECTED] wrote: Hi, I'm testing my project with 1.0.2 and I am having several issues. 1. No PPR activity works, I get a javascript error Invalid PPR response any time I try to submit a PPR action PPR's been overhauled. But also tested quite a lot. I could really use a testcase. Can anyone give me a clue as to what's wrong and how to fix it? Could you use Firebug and look at the responses you're getting from the server? 2. My skin no longer works, it seems that a few of the selectors have changed, namely: a) the panelHeader is rendering with af_messages_header class b) the panelBox has lost its background, it seems like there is no longer a distinction between panelBox transparent, light, etc. I think there was a fix just after 1.0.2 that affected panelBox, and perhaps panelHeader as well. Deleting af:messages works around it (with the obvious harm), or moving af:messages to the bottom of the page. It's fixed in the 1.0.3 nightlies. -- Adam I looked at the JIRA issues attached to the 1.0.2 release and did not see an obvious item that applied to either of these discoveries….can anyone verify exactly what it was that changed for each of these? Nate Perkins 480-441-3667 [EMAIL PROTECTED] This email message is for the sole use of the intended recipient(s) and may contain GDC4S confidential or privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not an intended recipient, please contact the sender by reply email and destroy all copies of the original message.
Re: [Trinidad] Skinnning dev guide now available!
Hi Jeanne,
To folks that are not CSS and skinning experts, it is not always clear what
this means:
[-tr-inhibit] is used to inhibit/reset css properties that you are
inheriting from a base skin
I've seen someone use:
af|panelGroupLayout {
font-size: 18pt;
}
af|commandButton {
-tr-inhibit: font-size;
}
tr:panelGroupLayout
tr:commandButton text=Hello/
/tr:panelGroupLayout
and expect the button's font size to be the browser default, thinking that
since it inherits the font-size from the panelGroupLayout, putting the
inhibit statement in the commandButton will take care of it.
Also it isn't clear what will happen if the skins look like this:
/* definitions in the base skin */
af|commandButton.foo {
font-size: 18pt;
}
.bar af|commandButton {
font-size: 24pt;
}
/* definition in the extended skin */
af|commandButton {
-tr-inhibit: font-size;
}
I think the docs explain the differences between padding and
padding-right clearly but perhaps the inheriting aspect of what gets
inhibited could be clearer.
I was thinking that the docs should say something along the lines of this:
The inhibitions are server-side only, any styles that get applied based on
cascading rules in the browser will not be inhibited.
However, if examples are easier to understand (as seen above), then let's
put them in.
Thanks,
Matt
On 8/22/07, Jeanne Waldman [EMAIL PROTECTED] wrote:
Hi Matt,
Can you elaborate so I'm sure what you are saying?
Thanks,
Jeanne
Matt Cooper wrote:
Hi Jeanne,
This looks great!
Do you think we need to call out that *-tr-inhibit* will only perform
server-side inhibiting; it will not inhibit styles that resolve in the
browser bases on things like selector specificity.
Thank you,
Matt
On 8/22/07, Jeanne Waldman [EMAIL PROTECTED] wrote:
Hi there,
I finally took some time to put together a skinning dev guide. This is
the first draft. I'll give myself
a break from looking at it and then proofread it, unless anyone else
wants to. :) Feel free to give suggestions
on new sections or sections that are confusing. You can create a JIRA
issue if you want.
The link is:
http://myfaces.apache.org/trinidad/devguide/skinning.html
I just noticed that I didn't link to it from the devguide's index page.
I'll look into doing that right now.
- Jeanne
Re: Which components to use?
Situation here: using here: Facelets + Myfaces + Tomahawk + Sandbox + Ajax4JSF + RichFaces+ Custom components. Only limit we found is that one of our really big forms (around 200+ components in it, with lots of Javascript enabled components like t:calendar and lots of ui:include)take around 2 seconds to be first time generated to user. We still have to investigate whever it comes from JSF tree or from the database backend which has a few tables to explore :) We are probably not the best example, as we use it for a reasonable traffic intranet. But for component compatibility we did not notice things that make them unusable. Of course each component has it's limitations, but they are not that hard to cope with. x y a écrit : Hello, I know this kind of question is sometimes annoying, but with so much components being created and enhancements on the existing ones, it is hard to make a decision, in a formal process, for the components to start an professional enteprise application. We are using Spring, then I think it could be a clue in which directions we could go. I am thinking in MyFaces with its variations: Trinidad, Tomahawk, etc. Another alternative would be to use Seam integrating with Myfaces and Spring, but I am not sure about how it has been working in production. The main aspect here, is that I would not like to start with a componet, and suddenly find that there are so many bugs to be corrected or there are limitation to integrate with other components to provide more features. You people, that have been working with those components in production (or at least close to it), would you mind to share you thought? Thank you very much. Looking for a deal? Find great prices on flights and hotels http://us.rd.yahoo.com/evt=47094/*http://farechase.yahoo.com/;_ylc=X3oDMTFicDJoNDllBF9TAzk3NDA3NTg5BHBvcwMxMwRzZWMDZ3JvdXBzBHNsawNlbWFpbC1uY20- with Yahoo! FareChase.
RE: [Trinidad] Upgrading to 1.0.2
Sorry for the weird formatting...please note that most of my post is after my signature :~ Nate Perkins 480-441-3667 [EMAIL PROTECTED] This email message is for the sole use of the intended recipient(s) and may contain GDC4S confidential or privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not an intended recipient, please contact the sender by reply email and destroy all copies of the original message. -Original Message- From: Perkins, Nate-P63196 [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 22, 2007 3:24 PM To: MyFaces Discussion Subject: RE: [Trinidad] Upgrading to 1.0.2 A simple usecase is to call launchDialog Nate Perkins 480-441-3667 [EMAIL PROTECTED] I will try to make a minimal example as, admittably, my pages are somewhat complex, but it is not limited to a certain action or a certain behaviour, across the board no PPR action (anything with partialSubmit, autoSubmit, or a launchDialog()) while all other actions work as expected. In the meantime, the full javascript error is as follows: [Invalid PPR response: The response-headers were:\nServer: Apache-Coyote/1.1\nX-powered-by: Servlet 2.4...] I have attached screenshots of my firebug output, this occurred when I attempted to click a button whose action method calls RequestContext.launchDialog(); This email message is for the sole use of the intended recipient(s) and may contain GDC4S confidential or privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not an intended recipient, please contact the sender by reply email and destroy all copies of the original message. -Original Message- From: Adam Winer [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 22, 2007 1:35 PM To: MyFaces Discussion Subject: Re: [Trinidad] Upgrading to 1.0.2 On 8/22/07, Perkins, Nate-P63196 [EMAIL PROTECTED] wrote: Hi, I'm testing my project with 1.0.2 and I am having several issues. 1. No PPR activity works, I get a javascript error Invalid PPR response any time I try to submit a PPR action PPR's been overhauled. But also tested quite a lot. I could really use a testcase. Can anyone give me a clue as to what's wrong and how to fix it? Could you use Firebug and look at the responses you're getting from the server? 2. My skin no longer works, it seems that a few of the selectors have changed, namely: a) the panelHeader is rendering with af_messages_header class b) the panelBox has lost its background, it seems like there is no longer a distinction between panelBox transparent, light, etc. I think there was a fix just after 1.0.2 that affected panelBox, and perhaps panelHeader as well. Deleting af:messages works around it (with the obvious harm), or moving af:messages to the bottom of the page. It's fixed in the 1.0.3 nightlies. -- Adam I looked at the JIRA issues attached to the 1.0.2 release and did not see an obvious item that applied to either of these discoveriescan anyone verify exactly what it was that changed for each of these? Nate Perkins 480-441-3667 [EMAIL PROTECTED] This email message is for the sole use of the intended recipient(s) and may contain GDC4S confidential or privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not an intended recipient, please contact the sender by reply email and destroy all copies of the original message.
Removing Text Icons (* and X)
Hi all, I would like to substitute the text icons * and X for required and error markers on fields with my own markup (an image and/or other text). Is there any way to do this? If so, how? Thanks, --Dave Shape Yahoo! in your own image. Join our Network Research Panel today! http://surveylink.yahoo.com/gmrs/yahoo_panel_invite.asp?a=7
RE: [Trinidad] Upgrading to 1.0.2
Regarding the problem with PPR, I had a similar problem with that soon after the PPR stuff was changed for 1.0.2 (see topic in the dev list named [Trinidad] AJAX PPR - Invalid PPR Response error). The problem only happened when using Weblogic and JSP. When using Weblogic with Facelets or Tomcat and either JSP or Facelets, PPR works fine. The problem was tracked down to the contentType being wrong for the response... it needs to be text/xml, but it was being changed to text/html somewhere. I wasn't able to track down a solution for this and, since it works with Facelets (which I'm using), it unfortunately fell down my priority list. Not sure if this has anything to do with your problem, but maybe it'll help... Dave From: Perkins, Nate-P63196 [mailto:[EMAIL PROTECTED] Sent: Wed 8/22/2007 3:31 PM To: MyFaces Discussion Subject: [Trinidad] Upgrading to 1.0.2 Hi, I'm testing my project with 1.0.2 and I am having several issues. 1. No PPR activity works, I get a javascript error Invalid PPR response any time I try to submit a PPR action Can anyone give me a clue as to what's wrong and how to fix it? 2. My skin no longer works, it seems that a few of the selectors have changed, namely: a) the panelHeader is rendering with af_messages_header class b) the panelBox has lost its background, it seems like there is no longer a distinction between panelBox transparent, light, etc. I looked at the JIRA issues attached to the 1.0.2 release and did not see an obvious item that applied to either of these discoveriescan anyone verify exactly what it was that changed for each of these? Nate Perkins 480-441-3667 [EMAIL PROTECTED] This email message is for the sole use of the intended recipient(s) and may contain GDC4S confidential or privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not an intended recipient, please contact the sender by reply email and destroy all copies of the original message. The information transmitted herewith is sensitive information of Chordiant Software or its customers and is intended only for use to the individual or entity to which it is addressed. If the reader of this message is not the intended recipient, you are hereby notified that any review, retransmission, dissemination, distribution, copying or other use of, or taking of any action in reliance upon, this information is strictly prohibited. If you have received this communication in error, please contact the sender and delete the material from your computer. winmail.dat
RE: [Trinidad] Upgrading to 1.0.2
I am using JSP without Facelets, but I am using JBoss w/ Tomcatbut sounds like it could be the same cause. Nate Perkins 480-441-3667 [EMAIL PROTECTED] This email message is for the sole use of the intended recipient(s) and may contain GDC4S confidential or privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not an intended recipient, please contact the sender by reply email and destroy all copies of the original message. From: David Brunette [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 22, 2007 4:28 PM To: MyFaces Discussion Subject: RE: [Trinidad] Upgrading to 1.0.2 Regarding the problem with PPR, I had a similar problem with that soon after the PPR stuff was changed for 1.0.2 (see topic in the dev list named [Trinidad] AJAX PPR - Invalid PPR Response error). The problem only happened when using Weblogic and JSP. When using Weblogic with Facelets or Tomcat and either JSP or Facelets, PPR works fine. The problem was tracked down to the contentType being wrong for the response... it needs to be text/xml, but it was being changed to text/html somewhere. I wasn't able to track down a solution for this and, since it works with Facelets (which I'm using), it unfortunately fell down my priority list. Not sure if this has anything to do with your problem, but maybe it'll help... Dave From: Perkins, Nate-P63196 [mailto:[EMAIL PROTECTED] Sent: Wed 8/22/2007 3:31 PM To: MyFaces Discussion Subject: [Trinidad] Upgrading to 1.0.2 Hi, I'm testing my project with 1.0.2 and I am having several issues. 1. No PPR activity works, I get a javascript error Invalid PPR response any time I try to submit a PPR action Can anyone give me a clue as to what's wrong and how to fix it? 2. My skin no longer works, it seems that a few of the selectors have changed, namely: a) the panelHeader is rendering with af_messages_header class b) the panelBox has lost its background, it seems like there is no longer a distinction between panelBox transparent, light, etc. I looked at the JIRA issues attached to the 1.0.2 release and did not see an obvious item that applied to either of these discoveriescan anyone verify exactly what it was that changed for each of these? Nate Perkins 480-441-3667 [EMAIL PROTECTED] This email message is for the sole use of the intended recipient(s) and may contain GDC4S confidential or privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not an intended recipient, please contact the sender by reply email and destroy all copies of the original message.
RE: [Trinidad] Upgrading to 1.0.2
I looked at the response header and it is correctly set to text/xmlso I don't believe this is the exact same problem. Nate Perkins 480-441-3667 [EMAIL PROTECTED] This email message is for the sole use of the intended recipient(s) and may contain GDC4S confidential or privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not an intended recipient, please contact the sender by reply email and destroy all copies of the original message. From: David Brunette [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 22, 2007 4:28 PM To: MyFaces Discussion Subject: RE: [Trinidad] Upgrading to 1.0.2 Regarding the problem with PPR, I had a similar problem with that soon after the PPR stuff was changed for 1.0.2 (see topic in the dev list named [Trinidad] AJAX PPR - Invalid PPR Response error). The problem only happened when using Weblogic and JSP. When using Weblogic with Facelets or Tomcat and either JSP or Facelets, PPR works fine. The problem was tracked down to the contentType being wrong for the response... it needs to be text/xml, but it was being changed to text/html somewhere. I wasn't able to track down a solution for this and, since it works with Facelets (which I'm using), it unfortunately fell down my priority list. Not sure if this has anything to do with your problem, but maybe it'll help... Dave From: Perkins, Nate-P63196 [mailto:[EMAIL PROTECTED] Sent: Wed 8/22/2007 3:31 PM To: MyFaces Discussion Subject: [Trinidad] Upgrading to 1.0.2 Hi, I'm testing my project with 1.0.2 and I am having several issues. 1. No PPR activity works, I get a javascript error Invalid PPR response any time I try to submit a PPR action Can anyone give me a clue as to what's wrong and how to fix it? 2. My skin no longer works, it seems that a few of the selectors have changed, namely: a) the panelHeader is rendering with af_messages_header class b) the panelBox has lost its background, it seems like there is no longer a distinction between panelBox transparent, light, etc. I looked at the JIRA issues attached to the 1.0.2 release and did not see an obvious item that applied to either of these discoveriescan anyone verify exactly what it was that changed for each of these? Nate Perkins 480-441-3667 [EMAIL PROTECTED] This email message is for the sole use of the intended recipient(s) and may contain GDC4S confidential or privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not an intended recipient, please contact the sender by reply email and destroy all copies of the original message.
RE: [Trinidad] Upgrading to 1.0.2
Ok,
Here's the simplest example I could muster, this results in the same
problem. I am deploying to JBoss-4.0.5 using Trinidad 1.0.2 and using
the RI 1.1
Test.jspx:
?xml version=1.0 encoding=UTF-8?
jsp:root
xmlns:jsp=http://java.sun.com/JSP/Page;
version=2.0
xmlns:f=http://java.sun.com/jsf/core;
xmlns:trh=http://myfaces.apache.org/trinidad/html;
xmlns:tr=http://myfaces.apache.org/trinidad;
xmlns:h=http://java.sun.com/jsf/html;
f:view
trh:html
jsp:output
omit-xml-declaration=false
doctype-root-element=html
doctype-system=http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd;
doctype-public=-//W3C//DTD XHTML 1.0
Strict//EN /
jsp:scriptlet
response.addHeader(pragma, no-store,no-cache);
response.setHeader(cache-control, no-cache, no-store, must
re-validate,max-age=-1);
response.addHeader(cache-control, pre-check=0,
post-check=0);
response.setDateHeader(expires, 0);
/jsp:scriptlet
jsp:directive.page
contentType=text/html;charset=UTF-8 /
trh:head title=Trinidad 1.0.2 PPR Test
meta
http-equiv=Content-Type
content=text/html; charset=UTF-8 /
t:stylesheet
path=#{NMSPanelPageUtil.cssLocation} /
/trh:head
trh:body
tr:form id=theForm
tr:panelPage
!--jsp:directive.include
file=/menu.jspx /--
tr:panelHeader text=Partial
Submit Test
tr:inputText
id=input
value=#{testBB.input}
label=Input:
partialTriggers=partialTestButton /
tr:commandButton
id=partialTestButton
text=PPR Test
action=#{testBB.action}
partialSubmit=true /
tr:outputText
id=partialOutput
value=#{testBB.output}
partialTriggers=partialTestButton /
tr:commandButton
id=fullTestButton
text=Full
Submission Test
action=#{testBB.action}/
tr:outputText
id=fullOutput
value=#{testBB.output}/
/tr:panelHeader
/tr:panelPage
/tr:form
/trh:body
/trh:html
/f:view
/jsp:root
Backing Bean:
import org.apache.myfaces.trinidad.context.RequestContext;
public class TestBb
{
private RequestContext rc = RequestContext.getCurrentInstance();
public TestBb()
{
setOutput(output);
setInput(input);
}
public void action()
{
setOutput(getInput());
}
public String getOutput()
{
return (String) rc.getPageFlowScope().get(output);
}
public void setOutput(String output)
{
rc.getPageFlowScope().put(output, output);
}
public String getInput()
{
return (String) rc.getPageFlowScope().get(input);
}
public void setInput(String input)
{
rc.getPageFlowScope().put(input, input);
}
}
Nate Perkins
480-441-3667
[EMAIL PROTECTED]
This email message is for the sole use of the intended recipient(s) and
may contain GDC4S
confidential or privileged information. Any unauthorized review, use,
disclosure or distribution
is prohibited. If you are not an intended recipient, please contact
the sender by reply email and
destroy all copies of the original message.
-Original Message-
From: Adam Winer [mailto:[EMAIL PROTECTED]
Sent: Wednesday, August 22, 2007 1:35 PM
To: MyFaces Discussion
Subject: Re: [Trinidad] Upgrading to 1.0.2
On 8/22/07, Perkins, Nate-P63196 [EMAIL PROTECTED] wrote:
Hi,
I'm testing my project with 1.0.2 and I am having several issues.
1. No PPR activity works, I get a javascript error Invalid PPR
response
any time I try to submit a PPR action
PPR's been overhauled. But also tested quite a lot. I could
really use a testcase.
Can anyone give me a clue as to what's wrong and how to fix it?
Could you use Firebug and look at the responses you're getting
from the server?
2. My skin no longer works, it seems that a few of the selectors have
changed, namely:
a) the panelHeader is rendering with af_messages_header class
b) the panelBox has lost its background, it seems like there
is
Re: [Trinidad] Skinnning dev guide now available!
I see. Thanks for the detailed explanation. I think the examples are
easier to understand.
Matt Cooper wrote:
Hi Jeanne,
To folks that are not CSS and skinning experts, it is not always clear
what this means:
"[-tr-inhibit] is used to inhibit/reset css properties that you are
inheriting from a base skin"
I've seen someone use:
af|panelGroupLayout {
font-size: 18pt;
}
af|commandButton {
-tr-inhibit: font-size;
}
tr:panelGroupLayout
tr:commandButton text="Hello"/
/tr:panelGroupLayout
and expect the button's font size to be the browser default, thinking
that since it inherits the font-size from the panelGroupLayout, putting
the inhibit statement in the commandButton will take care of it.
Also it isn't clear what will happen if the skins look like this:
/* definitions in the base skin */
af|commandButton.foo {
font-size: 18pt;
}
.bar af|commandButton {
font-size: 24pt;
}
/* definition in the extended skin */
af|commandButton {
-tr-inhibit: font-size;
}
I think the docs explain the differences between "padding" and
"padding-right" clearly but perhaps the inheriting aspect of what gets
inhibited could be clearer.
I was thinking that the docs should say something along the lines of
this:
"The inhibitions are server-side only, any styles that get applied
based on cascading rules in the browser will not be inhibited."
However, if examples are easier to understand (as seen above), then
let's put them in.
Thanks,
Matt
On 8/22/07, Jeanne Waldman
[EMAIL PROTECTED] wrote:
Hi Matt,
Can you elaborate so I'm sure what you are saying?
Thanks,
Jeanne
Matt Cooper wrote:
Hi Jeanne,
This looks great!
Do you think we need to call out that -tr-inhibit
will only perform server-side inhibiting; it will not inhibit styles
that resolve in the browser bases on things like selector specificity.
Thank you,
Matt
On 8/22/07, Jeanne Waldman [EMAIL PROTECTED]
wrote:
Hi
there,
I finally took some time to put together a skinning dev guide. This is
the first draft. I'll give myself
a break from looking at it and then proofread it, unless anyone else
wants to. :) Feel free to give suggestions
on new sections or sections that are confusing. You can create a JIRA
issue if you want.
The link is:
http://myfaces.apache.org/trinidad/devguide/skinning.html
I just noticed that I didn't link to it from the devguide's index page.
I'll look into doing that right now.
- Jeanne
Re: [Trinidad] Upgrading to 1.0.2
Adam Winer wrote: 2. My skin no longer works, it seems that a few of the selectors have changed, namely: a) the panelHeader is rendering with af_messages_header class b) the panelBox has lost its background, it seems like there is no longer a distinction between panelBox transparent, light, etc. I think there was a fix just after 1.0.2 that affected panelBox, and perhaps panelHeader as well. Deleting af:messages works around it (with the obvious harm), or moving af:messages to the bottom of the page. It's fixed in the 1.0.3 nightlies. -- Adam Any idea which patch fixed this? I would like to move from 1.0.0 to 1.0.2; but this one stops me. I am hoping the patch is small/simple enough that it can easily be applied to 1.0.2 without any of the other changes in HEAD. Thanks, Chris
Datatable won't reneder when added message with FacesMessage.SEVERITY_ERROR
Hi All, I am facing this strange problem with dataTable. I am using myfaces 1.1.4 and tomahawk 1.1.5. I have a jsp page with datatable backed up by collection in Managed Bean. First the datatable is renedrerd properly. After submiting the page there's some validations in the bean. If there's any error then I add a message in the Context with severity FacesMessage.SEVERITY_ERROR. This works fine and I do see a error message on the page. But my datatable won't reneder. I have checked that the backing collection is not null and the get method never gets called. If I change the severity to FacesMessage.SEVERITY_INFO or FacesMessage.SEVERITY_WARN then the datatabse is renederd. Any ideas how to resolve this? Thanks Susheel -- View this message in context: http://www.nabble.com/Datatable-won%27t-reneder-when-added-message-with-FacesMessage.SEVERITY_ERROR-tf4315164.html#a12286746 Sent from the MyFaces - Users mailing list archive at Nabble.com.
Re: [Trinidad] Upgrading to 1.0.2
Ok - I think I found my answer in SVN. I basically replaced the version of MessageBoxRenderer in 1.0.2 (559575) with the one in HEAD (565851). After replacing and doing a maven install (all tests passed), the issue is fixed in my app. Here is a link to the diff: http://svn.apache.org/viewvc/myfaces/trinidad/trunk/trinidad/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/renderkit/core/xhtml/MessageBoxRenderer.java?r1=559575r2=565851diff_format=h Chris Chris Hane wrote: Adam Winer wrote: 2. My skin no longer works, it seems that a few of the selectors have changed, namely: a) the panelHeader is rendering with af_messages_header class b) the panelBox has lost its background, it seems like there is no longer a distinction between panelBox transparent, light, etc. I think there was a fix just after 1.0.2 that affected panelBox, and perhaps panelHeader as well. Deleting af:messages works around it (with the obvious harm), or moving af:messages to the bottom of the page. It's fixed in the 1.0.3 nightlies. -- Adam Any idea which patch fixed this? I would like to move from 1.0.0 to 1.0.2; but this one stops me. I am hoping the patch is small/simple enough that it can easily be applied to 1.0.2 without any of the other changes in HEAD. Thanks, Chris
Re: [Trinidad] Upgrading to 1.0.2
If you remove the doctype-root-element, doctype-system,
and doctype-public off of jsp:output, does the problem
go away? It looks as though that doctype is getting
pushed straight into the content stream. There's code
in Trinidad to trim out the doctype (XmlHttpServletResponse
and XmlOutput) during an XMLHttp request - don't know
why it's not functioning here.
-- Adam
On 8/22/07, Perkins, Nate-P63196 [EMAIL PROTECTED] wrote:
Ok,
Here's the simplest example I could muster, this results in the same
problem. I am deploying to JBoss-4.0.5 using Trinidad 1.0.2 and using
the RI 1.1
Test.jspx:
?xml version=1.0 encoding=UTF-8?
jsp:root
xmlns:jsp=http://java.sun.com/JSP/Page;
version=2.0
xmlns:f=http://java.sun.com/jsf/core;
xmlns:trh=http://myfaces.apache.org/trinidad/html;
xmlns:tr=http://myfaces.apache.org/trinidad;
xmlns:h=http://java.sun.com/jsf/html;
f:view
trh:html
jsp:output
omit-xml-declaration=false
doctype-root-element=html
doctype-system=http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd;
doctype-public=-//W3C//DTD XHTML 1.0
Strict//EN /
jsp:scriptlet
response.addHeader(pragma, no-store,no-cache);
response.setHeader(cache-control, no-cache, no-store, must
re-validate,max-age=-1);
response.addHeader(cache-control, pre-check=0,
post-check=0);
response.setDateHeader(expires, 0);
/jsp:scriptlet
jsp:directive.page
contentType=text/html;charset=UTF-8 /
trh:head title=Trinidad 1.0.2 PPR Test
meta
http-equiv=Content-Type
content=text/html; charset=UTF-8 /
t:stylesheet
path=#{NMSPanelPageUtil.cssLocation} /
/trh:head
trh:body
tr:form id=theForm
tr:panelPage
!--jsp:directive.include
file=/menu.jspx /--
tr:panelHeader text=Partial
Submit Test
tr:inputText
id=input
value=#{testBB.input}
label=Input:
partialTriggers=partialTestButton /
tr:commandButton
id=partialTestButton
text=PPR Test
action=#{testBB.action}
partialSubmit=true /
tr:outputText
id=partialOutput
value=#{testBB.output}
partialTriggers=partialTestButton /
tr:commandButton
id=fullTestButton
text=Full
Submission Test
action=#{testBB.action}/
tr:outputText
id=fullOutput
value=#{testBB.output}/
/tr:panelHeader
/tr:panelPage
/tr:form
/trh:body
/trh:html
/f:view
/jsp:root
Backing Bean:
import org.apache.myfaces.trinidad.context.RequestContext;
public class TestBb
{
private RequestContext rc = RequestContext.getCurrentInstance();
public TestBb()
{
setOutput(output);
setInput(input);
}
public void action()
{
setOutput(getInput());
}
public String getOutput()
{
return (String) rc.getPageFlowScope().get(output);
}
public void setOutput(String output)
{
rc.getPageFlowScope().put(output, output);
}
public String getInput()
{
return (String) rc.getPageFlowScope().get(input);
}
public void setInput(String input)
{
rc.getPageFlowScope().put(input, input);
}
}
Nate Perkins
480-441-3667
[EMAIL PROTECTED]
This email message is for the sole use of the intended recipient(s) and
may contain GDC4S
confidential or privileged information. Any unauthorized review, use,
disclosure or distribution
is prohibited. If you are not an intended recipient, please contact
the sender by reply email and
destroy all copies of the original message.
-Original Message-
From: Adam Winer [mailto:[EMAIL PROTECTED]
Sent: Wednesday, August 22, 2007 1:35 PM
To: MyFaces Discussion
Subject: Re: [Trinidad] Upgrading to 1.0.2
On 8/22/07, Perkins, Nate-P63196 [EMAIL PROTECTED] wrote:
Hi,
I'm testing my project with 1.0.2 and I am having several issues.
1. No PPR activity works, I get a javascript error Invalid PPR
response
any time I try to submit a PPR action
PPR's
