Re: [Tobago] Text of labels is too much shifted to the top.

2010-10-28 Thread Udo Schnurpfeil 

Hi dom,

I totally agree with you. Please file a ticket in Jira.

Regard,

Udo

Am 27.10.10 12:02, schrieb d.o@gmx.net:

Hi all,

the text of all labels is too much shifted to the top. Examples can be seen in 
the Tobago Demo for any of those themes: Richmond, Speyside, Charlotteville 
(http://www.irian.biz/tobago-example-demo). This happens to me with Firefox 
3.6.11 and Tobago 1.0.30 (and obviously the Tobago version currently used in 
the demo).

So, I think it should rather be vertically centered. Of course, one could do this by 
manipulating the CSS style, however I think the default behavior should be vertically 
centered. Since this might simply be a matter of taste, I didn't want to file a ticket in 
Jira and wanted to discuss it here first.

What do you think?
Best, dom

Re: TRinidad + Portlet-Bridge ViewExpired in Internet Explorer

2010-10-28 Thread Yves Deschamps 

Thank you all,

The problem is now resolved.
In fact I use the first page  home.jsf  which activates an action (a 
javascript which presses on a button) and thus passes in  / stylesheets 
/ desktop / welcome.jsf  if I am in desktop mode or  / stylesheets / 
mobile / welcome.jsf  if I am in mobile mode.
The fact of indicating   redirect /   in navigation-rules resolved 
my problem.


I hope not to have made you lose too much time.

Le 27/10/2010 22:48, Michael Freedman a écrit :

Can you give us some additional details?

  1. Can you confirm that /stylesheets/desktop/welcome.jsf is a valid
 viewId/view you have provided in the app?  I.e. its not a
 resource/stylesheet referenced in the markup of a view?
  2. Describe the various steps you take before this problem occurs ...
 something like:
 * Hit portal page:  portlet renders view /.jsf
 * Invoke action in portlet results in rendering view /.jsf
 * At this point I (do something?/do nothing?) in then shortly
   the (page?/portlet?) auto rerenders and generates the error
   message.
  3. Does this problem only occur in uPortal?  I.e. since uPortal seems
 to use the pluto portlet container can you reproduce on Apache 
Pluto?

  4. Have you enabled trace logging in Faces?  If not can you?  Can you
 send me the logged results?
  5. Can you reproduce in a simplified test case that you can submit
 with a JIRA bug?

-Mike-

On 10/26/2010 12:16 AM, Yves Deschamps wrote:

I am using

IE 8.0
Faces 1.2.9
Portlet-Bridge 1.0.0
Trinidad 1.2.13
uPortal 3.1.2

Thanks

Le 25/10/2010 23:00, Scott O'Bryan a écrit :

Which version of IE, Faces, Bridge, and Trinidad are you using?

On 10/25/2010 10:17 AM, Yves Deschamps wrote:

Hi All,

I have this issue in IE, not in Firefox ? The portlet it's Ok but a 
few seconds later, it's down without action !


javax.faces.application.ViewExpiredException: 
/stylesheets/desktop/welcome.jsfNo saved view state could be found 
for the view identifier: /stylesheets/desktop/welcome.jsf
at 
org.apache.myfaces.lifecycle.RestoreViewExecutor.execute(RestoreViewExecutor.java:88) 

at 
org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:103) 

at 
org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:76)
at 
org.apache.myfaces.portlet.faces.bridge.BridgeImpl.doFacesRender(BridgeImpl.java:636) 

at 
org.apache.myfaces.portlet.faces.bridge.BridgeImpl.doFacesRequest(BridgeImpl.java:545) 

at 
javax.portlet.faces.GenericFacesPortlet.doBridgeDispatch(GenericFacesPortlet.java:506) 

at 
javax.portlet.faces.GenericFacesPortlet.doRenderDispatchInternal(GenericFacesPortlet.java:461) 

at 
javax.portlet.faces.GenericFacesPortlet.doView(GenericFacesPortlet.java:231) 

at 
javax.portlet.GenericPortlet.doDispatch(GenericPortlet.java:247)
at 
javax.portlet.faces.GenericFacesPortlet.doDispatch(GenericFacesPortlet.java:202) 


at javax.portlet.GenericPortlet.render(GenericPortlet.java:175)
at 
org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:208)
at 
org.apache.pluto.core.PortletServlet.doGet(PortletServlet.java:139)

at javax.servlet.http.HttpServlet.service(HttpServlet.java:617)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) 

at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) 

at 
org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:646) 

at 
org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:551) 

at 
org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:488) 

at 
org.apache.pluto.core.DefaultPortletInvokerService.invoke(DefaultPortletInvokerService.java:167) 

at 
org.apache.pluto.core.DefaultPortletInvokerService.render(DefaultPortletInvokerService.java:101) 

at 
org.apache.pluto.core.PortletContainerImpl.doRender(PortletContainerImpl.java:172) 

at 
org.jasig.portal.channels.portlet.SpringPortletChannelImpl.render(SpringPortletChannelImpl.java:553) 

at 
org.jasig.portal.channels.portlet.CSpringPortletAdaptor.renderCharacters(CSpringPortletAdaptor.java:197) 

at 
org.jasig.portal.ChannelRenderer$Worker.execute(ChannelRenderer.java:607)

at org.jasig.portal.utils.threading.BaseTask.run(BaseTask.java:27)
at sun.reflect.GeneratedMethodAccessor212.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) 


at java.lang.reflect.Method.invoke(Method.java:616)
at 
org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:307) 

at 
org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:182) 

at

Re: [Tobago] Text of labels is too much shifted to the top.

2010-10-28 Thread d . o . m . e 
Hi Udo,

Thanks for your feedback :)
Here is the ticket number: TOBAGO-932.

Best, dom

 Original-Nachricht 
 Datum: Thu, 28 Oct 2010 10:47:08 +0200
 Von: Udo Schnurpfeil u...@schnurpfeil.de
 An: MyFaces Discussion users@myfaces.apache.org
 Betreff: Re: [Tobago] Text of labels is too much shifted to the top.

 Hi dom,
 
 I totally agree with you. Please file a ticket in Jira.
 
 Regard,
 
 Udo
 
 Am 27.10.10 12:02, schrieb d.o@gmx.net:
  Hi all,
 
  the text of all labels is too much shifted to the top. Examples can be
 seen in the Tobago Demo for any of those themes: Richmond, Speyside,
 Charlotteville (http://www.irian.biz/tobago-example-demo). This happens to me 
 with
 Firefox 3.6.11 and Tobago 1.0.30 (and obviously the Tobago version
 currently used in the demo).
 
  So, I think it should rather be vertically centered. Of course, one
 could do this by manipulating the CSS style, however I think the default
 behavior should be vertically centered. Since this might simply be a matter
 of taste, I didn't want to file a ticket in Jira and wanted to discuss it
 here first.
 
  What do you think?
  Best, dom

-- 
GRATIS! Movie-FLAT mit über 300 Videos. 
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome

ExtVal latest snapshot

2010-10-28 Thread Walter Mourão 
I just tried https://issues.apache.org/jira/browse/EXTVAL-115 with the
snapshot from http://people.apache.org/repo/m2-snapshot-repository/ and the
error continues. Is this the latest snapshot ?

Thanks,

Walter Mourão
http://waltermourao.com.br
http://arcadian.com.br
http://oriens.com.br

Re: TRinidad + Portlet-Bridge ViewExpired in Internet Explorer

2010-10-28 Thread Michael Freedman 
Any chance you can put together a simple/stripped down form of this use 
case and send to me?  Yes, the redirect / works around the problem 
because it gets the bridge to think it should render the view in create 
mode (no existing state to restore) but its not clear that the the 
original way you coded it is incorrect. Hence I would like to take a 
look at the details of this (if possible) and see if its something that 
is a bug/needs to be fixed.

-Mike-

On 10/28/2010 2:00 AM, Yves Deschamps wrote:

Thank you all,

The problem is now resolved.
In fact I use the first page  home.jsf  which activates an action (a 
javascript which presses on a button) and thus passes in  / 
stylesheets / desktop / welcome.jsf  if I am in desktop mode or  / 
stylesheets / mobile / welcome.jsf  if I am in mobile mode.
The fact of indicating   redirect /   in navigation-rules 
resolved my problem.


I hope not to have made you lose too much time.

Le 27/10/2010 22:48, Michael Freedman a écrit :

Can you give us some additional details?

  1. Can you confirm that /stylesheets/desktop/welcome.jsf is a valid
 viewId/view you have provided in the app?  I.e. its not a
 resource/stylesheet referenced in the markup of a view?
  2. Describe the various steps you take before this problem occurs ...
 something like:
 * Hit portal page:  portlet renders view /.jsf
 * Invoke action in portlet results in rendering view /.jsf
 * At this point I (do something?/do nothing?) in then shortly
   the (page?/portlet?) auto rerenders and generates the error
   message.
  3. Does this problem only occur in uPortal?  I.e. since uPortal seems
 to use the pluto portlet container can you reproduce on Apache 
Pluto?

  4. Have you enabled trace logging in Faces?  If not can you?  Can you
 send me the logged results?
  5. Can you reproduce in a simplified test case that you can submit
 with a JIRA bug?

-Mike-

On 10/26/2010 12:16 AM, Yves Deschamps wrote:

I am using

IE 8.0
Faces 1.2.9
Portlet-Bridge 1.0.0
Trinidad 1.2.13
uPortal 3.1.2

Thanks

Le 25/10/2010 23:00, Scott O'Bryan a écrit :

Which version of IE, Faces, Bridge, and Trinidad are you using?

On 10/25/2010 10:17 AM, Yves Deschamps wrote:

Hi All,

I have this issue in IE, not in Firefox ? The portlet it's Ok but 
a few seconds later, it's down without action !


javax.faces.application.ViewExpiredException: 
/stylesheets/desktop/welcome.jsfNo saved view state could be found 
for the view identifier: /stylesheets/desktop/welcome.jsf
at 
org.apache.myfaces.lifecycle.RestoreViewExecutor.execute(RestoreViewExecutor.java:88) 

at 
org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:103) 

at 
org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:76)
at 
org.apache.myfaces.portlet.faces.bridge.BridgeImpl.doFacesRender(BridgeImpl.java:636) 

at 
org.apache.myfaces.portlet.faces.bridge.BridgeImpl.doFacesRequest(BridgeImpl.java:545) 

at 
javax.portlet.faces.GenericFacesPortlet.doBridgeDispatch(GenericFacesPortlet.java:506) 

at 
javax.portlet.faces.GenericFacesPortlet.doRenderDispatchInternal(GenericFacesPortlet.java:461) 

at 
javax.portlet.faces.GenericFacesPortlet.doView(GenericFacesPortlet.java:231) 

at 
javax.portlet.GenericPortlet.doDispatch(GenericPortlet.java:247)
at 
javax.portlet.faces.GenericFacesPortlet.doDispatch(GenericFacesPortlet.java:202) 


at javax.portlet.GenericPortlet.render(GenericPortlet.java:175)
at 
org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:208) 

at 
org.apache.pluto.core.PortletServlet.doGet(PortletServlet.java:139)

at javax.servlet.http.HttpServlet.service(HttpServlet.java:617)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) 

at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) 

at 
org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:646) 

at 
org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:551) 

at 
org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:488) 

at 
org.apache.pluto.core.DefaultPortletInvokerService.invoke(DefaultPortletInvokerService.java:167) 

at 
org.apache.pluto.core.DefaultPortletInvokerService.render(DefaultPortletInvokerService.java:101) 

at 
org.apache.pluto.core.PortletContainerImpl.doRender(PortletContainerImpl.java:172) 

at 
org.jasig.portal.channels.portlet.SpringPortletChannelImpl.render(SpringPortletChannelImpl.java:553) 

at 
org.jasig.portal.channels.portlet.CSpringPortletAdaptor.renderCharacters(CSpringPortletAdaptor.java:197) 

at 
org.jasig.portal.ChannelRenderer$Worker.execute(ChannelRenderer.java:607)
at

Re: composite components: optional method-expression-attributes

2010-10-28 Thread Jakob Korherr 
Hi Thomas,

Use the targets attribute of cc:attribute and it should work.

Regards,
Jakob

2010/10/27 Thomas Möller thomas.moel...@continentale.de:

 Hi,

 what is the recommended way how to deal with optional attributes that refer
 to a method expression?

 For example imagine a simple component that uses a commandLink and has two
 attributes: action and actionListener:

 cc:interface
  cc:attribute name=action method-signature=java.lang.String action()
 default=??? /
  cc:attribute name=actionListener method-signature=void
 actionListener(javax.faces.event.ActionEvent) default=??? /
 /cc:interface

 cc:implementation
  tr:commandLink action=#{cc.attrs.action}
 actionListener=#{cc.attrs.actionListener} /
 /cc:implementation

 My problems:
 1) omitting the defaults results in NullPointerExceptions
 2) the spec says that a default-attribute must evaluate to a
 java.lang.String

 What is the solution for this simple problem?

 Thanks in advance.
 --
 View this message in context: 
 http://old.nabble.com/composite-components%3A-optional-method-expression-attributes-tp30067392p30067392.html
 Sent from the MyFaces - Users mailing list archive at Nabble.com.





-- 
Jakob Korherr

blog: http://www.jakobk.com
twitter: http://twitter.com/jakobkorherr
work: http://www.irian.at