f:verbatim and myfaces 1.2.0
I'm currently trying out myfaces 1.2.0.
I noticed a small change in behaviour for the f:verbatim tag.
Before (with myfaces 1.1.6) I was able to do the following: (note I'm
using facelets)
f:verbatim
#{facesContext.externalContext.requestContextPath}
/f:verbatim
It would nicely output the contextpath.
However, If I try to do the same with 1.2.0 it doesn't output anything.
Is there a spec change for jsf 1.2 saying el expressions are not allowed
within f:verbatim?
regards,
Safurudin Mahic
Re: f:verbatim and myfaces 1.2.0
org.apache.myfaces.renderkit.html.util.ReducedHTMLParser - DOCTYPE found at line 3 10:22:38,233 DEBUG org.springframework.web.context.request.RequestContextListener - Cleared thread-bound request context: [EMAIL PROTECTED] I also notice here that the processing time for this response is 1219 ms - which is remarkably slow for such a simple page. Is this because I'm tracing to console, or could it be some performance issue with regards to how my application is configured? (I'm using spring, hibernate, ajax, facelets, myfaces) regards, Safurudin Mahic
Error when trying to use sandbox and facelets
Hello. I've added the sandbox jars to my project. Now when I try to access a jsf page, I get the following error: Is this due to some missing dependencies? (I've added the freemarker, poi and oro libs) Expression text is undefined on line 1, column 3 in outputText_children.ftl. |java.io.IOException: Expression text is undefined on line 1, column 3 in outputText_children.ftl. at org.apache.myfaces.renderkit.freemarker.FreemarkerRenderer.encodeTemplate(FreemarkerRenderer.java:64) at org.apache.myfaces.renderkit.freemarker.FreemarkerRenderer.encodeChildren(FreemarkerRenderer.java:39) at javax.faces.component.UIComponentBase.encodeChildren(UIComponentBase.java:676) at org.apache.myfaces.shared_tomahawk.renderkit.RendererUtils.renderChild(RendererUtils.java:437) at org.apache.myfaces.shared_tomahawk.renderkit.RendererUtils.renderChildren(RendererUtils.java:423) at org.apache.myfaces.shared_tomahawk.renderkit.RendererUtils.renderChild(RendererUtils.java:440) at org.apache.myfaces.renderkit.html.ext.HtmlTableRenderer.renderColumnBody(HtmlTableRenderer.java:666) at org.apache.myfaces.shared_tomahawk.renderkit.html.HtmlTableRendererBase.encodeColumnChild(HtmlTableRendererBase.java:306) at org.apache.myfaces.renderkit.html.ext.HtmlTableRenderer.encodeColumnChild(HtmlTableRenderer.java:566) at org.apache.myfaces.shared_tomahawk.renderkit.html.HtmlTableRendererBase.encodeInnerHtml(HtmlTableRendererBase.java:282) at org.apache.myfaces.shared_tomahawk.renderkit.html.HtmlTableRendererBase.encodeChildren(HtmlTableRendererBase.java:134) at org.apache.myfaces.renderkit.html.ext.HtmlTableRenderer.encodeChildren(HtmlTableRenderer.java:185) at javax.faces.component.UIComponentBase.encodeChildren(UIComponentBase.java:676) at com.sun.facelets.tag.jsf.ComponentSupport.encodeRecursive(ComponentSupport.java:244) at com.sun.facelets.tag.jsf.ComponentSupport.encodeRecursive(ComponentSupport.java:249) at com.sun.facelets.tag.jsf.ComponentSupport.encodeRecursive(ComponentSupport.java:249) at com.sun.facelets.FaceletViewHandler.renderView(FaceletViewHandler.java:573) at org.ajax4jsf.framework.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:108) at org.ajax4jsf.framework.ajax.AjaxViewHandler.renderView(AjaxViewHandler.java:233) at org.apache.myfaces.lifecycle.RenderResponseExecutor.execute(RenderResponseExecutor.java:41) at org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:132) at javax.faces.webapp.FacesServlet.service(FacesServlet.java:140) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:269) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188) at org.apache.myfaces.webapp.filter.ExtensionsFilter.doFilter(ExtensionsFilter.java:100) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:215) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188) at org.ajax4jsf.framework.ajax.xmlfilter.BaseXMLFilter.doXmlFilter(BaseXMLFilter.java:127) at org.ajax4jsf.framework.ajax.xmlfilter.BaseFilter.doFilter(BaseFilter.java:277) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:215) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188) at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:264) at org.acegisecurity.intercept.web.FilterSecurityInterceptor.invoke(FilterSecurityInterceptor.java:107) at org.acegisecurity.intercept.web.FilterSecurityInterceptor.doFilter(FilterSecurityInterceptor.java:72) at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274) at org.acegisecurity.ui.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:110) at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274) at org.acegisecurity.providers.anonymous.AnonymousProcessingFilter.doFilter(AnonymousProcessingFilter.java:125) at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274) at org.acegisecurity.wrapper.SecurityContextHolderAwareRequestFilter.doFilter(SecurityContextHolderAwareRequestFilter.java:81) at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274) at org.acegisecurity.ui.AbstractProcessingFilter.doFilter(AbstractProcessingFilter.java:217) at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274) at
t:popup attribute inflexibility
I'm currently using a t:popup in a datatable to show details about a row. One of the issues I'm facing is that the renderer for the popup always renders position:absolute; display: none; at the end of the inline style. While this is practical as a default for showing the popup next to the event, in some cases where you want the popup to be displayed at the same spot every time, this is not possible to achive by setting something like; t:popup title=Head id=test style=background-color:white;color:#11; border: 3px solid #000; width: 300px; position: fixed; top: 20px; left: 20px because the renderer always overrides with position: absolute; display: none; at the end of the rendered style. It would be far more flexible to leave this to the developer himself to decide via the use of the style attribute. If someone like it to be next to the event, use position absolute, in other cases use some other positioning method. In that case, the attributes displayAtDistanceX and Y would become redundant. Also the attributes closePopupOnExitingElement and closePopupOnExitingPopup always render the element with onmouseout events, which in some cases never will invoke. On my Nokia N800 for example, the device doesn't have a mouse, and hence doesn't support the onmouseevents, which means I can never get the popup to hide. Perhaps a facet with a close button? Would these suggestions be a hard thing to implement? If it isn't, I guess I could always do some code hacking myself Regards, Safurudin Mahic
Re: t:popup attribute inflexibility
I barely skimmed through the Renderer; writer.writeAttribute(HTML.STYLE_ATTR,(popup.getStyle()!=null?(popup.getStyle()+ (popup.getStyle().trim().endsWith(;)?:;)):)+ position:absolute;display:none;,null); As mentioned, it is not possible to put a position: fixed on the t:popup style for example, because the position: absolute always renders last, and is the one that the browser adheres to. I could always override this behaviour on my instance of tomahawk, but I think this issue doesn't necessarily affect only me.The position:absolute shouldn't be hardcoded. It will be much more flexible if it only defaults to that attribute, and if overriden, make it behave according to the overriden value, or don't default it at all, make the developer decide where it should be placed. Would the proposal to remove the hardcoded attribute be accepted by the devs? Regards, Safu Martin Marinschek skrev: Probably, the wouldn't be too hard to implement, no. Have fun hacking! regards, Martin On 7/3/07, Safurudin Mahic [EMAIL PROTECTED] wrote: I'm currently using a t:popup in a datatable to show details about a row. One of the issues I'm facing is that the renderer for the popup always renders position:absolute; display: none; at the end of the inline style. While this is practical as a default for showing the popup next to the event, in some cases where you want the popup to be displayed at the same spot every time, this is not possible to achive by setting something like; t:popup title=Head id=test style=background-color:white;color:#11; border: 3px solid #000; width: 300px; position: fixed; top: 20px; left: 20px because the renderer always overrides with position: absolute; display: none; at the end of the rendered style. It would be far more flexible to leave this to the developer himself to decide via the use of the style attribute. If someone like it to be next to the event, use position absolute, in other cases use some other positioning method. In that case, the attributes displayAtDistanceX and Y would become redundant. Also the attributes closePopupOnExitingElement and closePopupOnExitingPopup always render the element with onmouseout events, which in some cases never will invoke. On my Nokia N800 for example, the device doesn't have a mouse, and hence doesn't support the onmouseevents, which means I can never get the popup to hide. Perhaps a facet with a close button? Would these suggestions be a hard thing to implement? If it isn't, I guess I could always do some code hacking myself Regards, Safurudin Mahic
NavigationMenu and active state across redirect/
I have a sample navigationmenu implemented on my page;
-
t:panelNavigation2 id=nav1 layout=list
itemClass=mypage
activeItemClass=selected openItemClass=selected
t:navigationMenuItems
value=#{navMenu.navigationItems} /
/t:panelNavigation2
and the backing bean
public NavigationMenu() {
navigationItems = new ArrayListNavigationMenuItem();
navigationItems.add(new NavigationMenuItem(Dashboard,
dashboard));
navigationItems.add(new NavigationMenuItem(Customers,
customers));
navigationItems.add(new NavigationMenuItem(Groups, groups));
for (NavigationMenuItem n : navigationItems) {
n.setActionListener(#{navMenu.actionListener});
}
}
public List getNavigationItems() {
return navigationItems;
}
public void actionListener(ActionEvent event) {
if (event.getComponent() instanceof HtmlCommandNavigationItem) {
log.info(ActionListener:
+ ((HtmlCommandNavigationItem) event.getComponent())
.getValue());
selectedItem = (HtmlCommandNavigationItem) event.getComponent();
selectedItem.setActive(true);
}
}
My problem is when I want to invoke some of the actions on the
navigation menu -
If I define the navigationrule for the dashboard action without redirect,
navigation-rule
navigation-case
from-outcomedashboard/from-outcome
to-view-id/dashboard.xhtml/to-view-id
/navigation-case
/navigation-rule
the panelnavigation correctly renders the selected active item on the menu.
But if I put redirect in the navigationrules, the active item
is not rendered. How would I get the active navigation item to be
rendered active across redirects? Is this the same problem
as the h:message not being able to render messages across redirects?
Thanks,
Safurudin
Re: Turn off html character escaping
I simply solved it by doing
f:view xmlns:f=http://java.sun.com/jsf/core;
contentType=*/*
f:verbatim thecss .../f:verbatim
/f:view
It didn't htmlescape my special characters, and now my CSSS is valid
again + I have the power of EL expressions inside CSS
I can now simply use EL expressions to get all the images inside my CSS
files aligned with the context path, which was my main intention;
body {
background:
url(#{facesContext.externalContext.requestContextPath}/images/background.jpg);
}
Probably not the most obvious use-case, but EL expressions offer
functionality which sometimes could be
used beyond the scope of XML-type languages.
Regards,
Safurudin
Adam Winer skrev:
The issue would be that MyFaces is creating an HtmlResponseWriter
even though it's not HTML. Hard to blame it, though. The general
intent here is for XML-type languages.
In this scenario, I'd probably recommend that Facelets
specifically intercept text/css and text/plain to create
an internal PlainTextResponseWriter, one that throws
exceptions on calls to startElement(), for example, but
passes writeText() straight to write().
-- Adam
On 6/29/07, Safurudin Mahic [EMAIL PROTECTED] wrote:
I'm trying to get facelets to render my css files (especially neet to
get the url(#{facesContext.ex
Reccomended by some of the guys on the facelets mailing list, I first
tried
to do f:view contentType=text/css.../f:view
This went badly, because the html renderer kit for myfaces doesn't
support this contentType. It only support a small set of content types
defined;
private static String HTML_CONTENT_TYPE = text/html;
private static String TEXT_ANY_CONTENT_TYPE = text/*;
private static String ANY_CONTENT_TYPE = */*;
private static String APPLICATION_XML_CONTENT_TYPE = application/xml;
private static String TEXT_XML_CONTENT_TYPE = text/xml;
private static String XHTML_CONTENT_TYPE = application/xhtml+xml;
Tried then to use the */* - this went OK - the problem now however is
that either facelets or
myfaces escapes special characters in the css files:
The following perfecly valid css selector:
h2 {
font-family: Arial, Arial CE, Lucida Grande CE, lucida,
Helvetica CE, sans-serif;
}
is escaped with
h2 {
font-family: Arial, quot;Arial CEquot;, quot;Lucida Grande CEquot;,
lucida,
quot;Helvetica CEquot;, sans-serif;
}
rendering the generated css as invalid
Is there a way to turn off html entity character escaping for a
particular view?
Thanks,
Safurudin Mahic
Turn off html character escaping
I'm trying to get facelets to render my css files (especially neet to
get the url(#{facesContext.ex
Reccomended by some of the guys on the facelets mailing list, I first tried
to do f:view contentType=text/css.../f:view
This went badly, because the html renderer kit for myfaces doesn't
support this contentType. It only support a small set of content types
defined;
private static String HTML_CONTENT_TYPE = text/html;
private static String TEXT_ANY_CONTENT_TYPE = text/*;
private static String ANY_CONTENT_TYPE = */*;
private static String APPLICATION_XML_CONTENT_TYPE = application/xml;
private static String TEXT_XML_CONTENT_TYPE = text/xml;
private static String XHTML_CONTENT_TYPE = application/xhtml+xml;
Tried then to use the */* - this went OK - the problem now however is
that either facelets or
myfaces escapes special characters in the css files:
The following perfecly valid css selector:
h2 {
font-family: Arial, Arial CE, Lucida Grande CE, lucida,
Helvetica CE, sans-serif;
}
is escaped with
h2 {
font-family: Arial, quot;Arial CEquot;, quot;Lucida Grande CEquot;,
lucida,
quot;Helvetica CEquot;, sans-serif;
}
rendering the generated css as invalid
Is there a way to turn off html entity character escaping for a
particular view?
Thanks,
Safurudin Mahic
Validation error with selectitems in latest Myfaces/Tomahawk
I'm having problems getting a correct form submittal with a simple
selectOneMenu in the latest MyFaces and TomaHawk.
After issuing the command button, I'm getting Validation Error
statusid: Value is not a valid option.
The statusid is an Integer value on the backing bean.
In previous versions (1.1.1) this works fine. Doesn't MyFaces/Tomahawk
in later versions autoconvert strings to integers where appropriate?
My form looks like this:
?xml version=1.0 encoding=UTF-8?
!DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN
http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd;
html xmlns=http://www.w3.org/1999/xhtml;
xmlns:ui=http://java.sun.com/jsf/facelets;
xmlns:h=http://java.sun.com/jsf/html;
xmlns:f=http://java.sun.com/jsf/core;
xmlns:t=http://myfaces.apache.org/tomahawk;
xmlns:acegijsf=http://sourceforge.net/projects/jsf-comp/acegijsf;
xml:lang=en lang=en
body
f:view
h:form
h:messages globalOnly=false showDetail=true
showSummary=true/
h:selectOneMenu id=statusid
value=#{testBean.statusid}
styleClass=inputfield_long
f:selectItem itemValue=0
itemLabel=Test1 /
f:selectItem itemValue=1
itemLabel=Test2 /
f:selectItem itemValue=2
itemLabel=Test3 /
f:selectItem itemValue=3
itemLabel=Test4 /
/h:selectOneMenu
h:commandButton /
h:outputText value=#{testBean.statusid}/h:outputText
/h:form
/f:view
/body
/html
Re: Validation error with selectitems in latest Myfaces/Tomahawk
Ok - I tried to implement the solution -
h:selectOneMenu id=statusid
value=#{testBean.statusid}
f:selectItem itemValue=#{0}
itemLabel=Ikke paabegynt /
f:selectItem itemValue=#{1}
itemLabel=Under arbeid /
f:selectItem itemValue=#{2}
itemLabel=Kansellert /
f:selectItem itemValue=#{3}
itemLabel=Utfort /
f:convertNumber integerOnly=true/
/h:selectOneMenu
however, I still got the validation error when I didn't use the explicit
f:convertNumber.
I'm guessing the #{0} etc are integer valueexpressions, hence returning
the correct type to the value of
the selectonemenu. Wouldn't the expected behavior be that it works
without the explicit converter?
-safi
Cagatay Civici skrev:
Hi,
Sounds like;
http://wiki.apache.org/myfaces/Tomahawk_1%2e1%2e4_to_1%2e1%2e5
Cagatay
On 6/27/07, *Safurudin Mahic* [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
I'm having problems getting a correct form submittal with a simple
selectOneMenu in the latest MyFaces and TomaHawk.
After issuing the command button, I'm getting Validation Error
statusid: Value is not a valid option.
The statusid is an Integer value on the backing bean.
In previous versions (1.1.1) this works fine. Doesn't MyFaces/Tomahawk
in later versions autoconvert strings to integers where appropriate?
My form looks like this:
?xml version=1.0 encoding=UTF-8?
!DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN
http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd;
html xmlns=http://www.w3.org/1999/xhtml;
xmlns:ui= http://java.sun.com/jsf/facelets;
xmlns:h=http://java.sun.com/jsf/html;
xmlns:f=http://java.sun.com/jsf/core
http://java.sun.com/jsf/core
xmlns:t=http://myfaces.apache.org/tomahawk;
xmlns:acegijsf=http://sourceforge.net/projects/jsf-comp/acegijsf
http://sourceforge.net/projects/jsf-comp/acegijsf
xml:lang=en lang=en
body
f:view
h:form
h:messages globalOnly=false showDetail=true
showSummary=true/
h:selectOneMenu id=statusid
value=#{testBean.statusid}
styleClass=inputfield_long
f:selectItem itemValue=0
itemLabel=Test1 /
f:selectItem itemValue=1
itemLabel=Test2 /
f:selectItem itemValue=2
itemLabel=Test3 /
f:selectItem itemValue=3
itemLabel=Test4 /
/h:selectOneMenu
h:commandButton /
h:outputText value=#{ testBean.statusid}/h:outputText
/h:form
/f:view
/body
/html
Re: Validation error with selectitems in latest Myfaces/Tomahawk
the statusid property is an Integer.
What the wiki page suggests, is that the itemValue=#{3} will return a
valueexpression with
the correct type. My issue seems to be that the valueExpression #{3}
type is actually not Integer, but Long.
Therefore I must use the converter.
I was expecting the #{3} to be of type Integer instead of Long..
With a Long statusid, you don't need to use the explicit converter when
using the #{3}.
What I really want is a way to express an Integer value with a
valueexpression, which in my oppinion
should be #{3}, and the Long value would be #{3L} just like in Java.
-safi
David Delbecq skrev:
does testBean.getStatusId() return a String or a Long? If you don't
specify manually a converter, then JSF will try to find a suitable
converter based on the type of the selectonemenu value (not the select
item value!).
To check submitted value validity, as far as i know, myfaces will
compare the selectItem itemValue converte as String with the submitted
string value. Maybe, without converter, value inside your html form
looks like option value=[EMAIL PROTECTED].../option?
En l'instant précis du 27/06/07 12:14, Safurudin Mahic s'exprimait en
ces termes:
Ok - I tried to implement the solution -
h:selectOneMenu id=statusid
value=#{testBean.statusid}
f:selectItem itemValue=#{0}
itemLabel=Ikke paabegynt /
f:selectItem itemValue=#{1}
itemLabel=Under arbeid /
f:selectItem itemValue=#{2}
itemLabel=Kansellert /
f:selectItem itemValue=#{3}
itemLabel=Utfort /
f:convertNumber integerOnly=true/
/h:selectOneMenu
however, I still got the validation error when I didn't use the
explicit f:convertNumber.
I'm guessing the #{0} etc are integer valueexpressions, hence
returning the correct type to the value of
the selectonemenu. Wouldn't the expected behavior be that it works
without the explicit converter?
-safi
Cagatay Civici skrev:
Hi,
Sounds like;
http://wiki.apache.org/myfaces/Tomahawk_1%2e1%2e4_to_1%2e1%2e5
Cagatay
On 6/27/07, *Safurudin Mahic* [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
I'm having problems getting a correct form submittal with a simple
selectOneMenu in the latest MyFaces and TomaHawk.
After issuing the command button, I'm getting Validation Error
statusid: Value is not a valid option.
The statusid is an Integer value on the backing bean.
In previous versions (1.1.1) this works fine. Doesn't
MyFaces/Tomahawk
in later versions autoconvert strings to integers where appropriate?
My form looks like this:
?xml version=1.0 encoding=UTF-8?
!DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN
http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd;
html xmlns=http://www.w3.org/1999/xhtml;
xmlns:ui= http://java.sun.com/jsf/facelets;
xmlns:h=http://java.sun.com/jsf/html;
xmlns:f=http://java.sun.com/jsf/core
http://java.sun.com/jsf/core
xmlns:t=http://myfaces.apache.org/tomahawk;
xmlns:acegijsf=http://sourceforge.net/projects/jsf-comp/acegijsf
http://sourceforge.net/projects/jsf-comp/acegijsf
xml:lang=en lang=en
body
f:view
h:form
h:messages globalOnly=false showDetail=true
showSummary=true/
h:selectOneMenu id=statusid
value=#{testBean.statusid}
styleClass=inputfield_long
f:selectItem itemValue=0
itemLabel=Test1 /
f:selectItem itemValue=1
itemLabel=Test2 /
f:selectItem itemValue=2
itemLabel=Test3 /
f:selectItem itemValue=3
itemLabel=Test4 /
/h:selectOneMenu
h:commandButton /
h:outputText value=#{ testBean.statusid}/h:outputText
/h:form
/f:view
/body
/html
Re: Partial Page Rendering issue with Trinidad
The trunk is located at https://svn.apache.org/repos/asf/myfaces/trinidad/trunk If you are using windows, you could use the excellent TortoiseSVN app (tortoisesvn.tigris.org) to do the checkout. On linux you just do svn co https://svn.apache.org/repos/asf/myfaces/trinidad/trunk Also, you have the excellent Trinidad documentation at http://myfaces.apache.org/trinidad/source-repository.html - Safi Mladen Nisevic skrev: Thanks a lot to everyone who replied. Yes, I can see now that it was reloading the frame and not the whole page. I would like to use the 'real' AJAX that Matthias mentioned. How can I get the current trunk? noah wrote: Using the same version, I've noticed that it looks like a full page refresh is happening, but it actually isn't, probably due to the iframe. In other words, your browser will act like something changed, but the actual visible page is being updated piecemeal. You can test this by having an output with partialTriggers and one without. The one without will not change on partial submits. On 6/22/07, Mladen Nisevic [EMAIL PROTECTED] wrote: Thanks for such a quick reply. I am using trinidad-impl-1.0.0-incubating as I thought that was the latest stable build. Matthias Wessendorf wrote: sure. perhaps you're using a version, that has a bug. what are you using? The current trunk has real Ajax instead of IFrame (only used on uploads) ,M On 6/22/07, Mladen Nisevic [EMAIL PROTECTED] wrote: Hello, I'm having a an issue with the partial page rendering using Trinidad. The whole page is reloaded every time although I have set autoSubmit and am using partial trigger as explained in the example on partial page rendering in Trnidad in MyFaces wiki. Also, partialSubmit for Command Buttons does page reload. We also tried using panelPartialRoot with the same results i.e. full page reloading. Now, my understanding of partial page rendering (or AJAX) is that it allows for asynchronous updating of components. I.e. a portion of a page can be updated without reloading the whole page. Is it possible to have Partial Page Rendering in Trinidad without full page reload? And if yes are there any working examples? Thanks Mladen Alaric Systems Ltd. Registered in England No. 3314005 Registered Office: 108 Linton House, 164-180 Union Street, London SE1 0LH This e-mail has been scanned for all known viruses by Star. The service is powered by MessageLabs. Alaric Systems Ltd. Registered in England No. 3314005 Registered Office: 108 Linton House, 164-180 Union Street, London SE1 0LH This e-mail has been scanned for all known viruses by Star. The service is powered by MessageLabs. This e-mail has been scanned for all viruses by Star. The service is powered by MessageLabs. For more information on a proactive anti-virus service working around the clock, around the globe, visit: http://www.star.net.uk Alaric Systems Ltd. Registered in England No. 3314005 Registered Office: 108 Linton House, 164-180 Union Street, London SE1 0LH This e-mail has been scanned for all known viruses by Star. The service is powered by MessageLabs.
Re: [Trinidad] tr:chart and Adobe SVG Viewer
Trinidad doesn't depend on or use Adobe SVG viewer. Trinidad generates SVG xml, which is a W3C XML standard for describing vector graphics. Some browsers use the Adobe SVG plugin to be able to render the graphics, but as the EOL on the Adobe website says, most browsers have native support for viewing SVG nowadays. Also, discontinuing support for the SVG viewer application doesn't mean you can't download or use that application/plugin to view svg which the chart component generates. Henceforth, this is of no concern for Trinidad or the chart component. Cheers, Safi Geetha Rodricks skrev: Hi We use the Trinidad suite of components in our project. We were using the cewolf for charting and are thinking of using the Trinidad Chart component. From what I have gathered Trinidad chart uses the Adobe SVS plugin. But Adobe have decided to discontinue support for the SVG viewer. A line from their site - Please note that Adobe has announced http://www.adobe.com/svg/eol.html that it will discontinue support for Adobe SVG Viewer on January 1, 2008. Before we start using the chart component I would like to know how this affects the Trinidad chart component and what the plans are? Thanks Regards Geetha
Re: [Trinidad] PPR detection algorithm - Opera 8.5 on Nokia N800
The cache issue I last wrote about had nothing to do with Trinidad, so nevermind it. As I wrote last time, only minor changes was necesarry to get PPR to work with Opera, both on Desktop and on the N800. I could provide a patch via JIRA, but I haven't done any formal tests with it other than testing it with different versions of the browser. I'm also not sure about the guidelines of providing patches - is unit testing a necesarry part of the patch? --Safi Safurudin Mahic skrev: Your reply encouraged me to try a hack solution. I've managed to successfully test the PPR panelPageRoot and poll components with following browsers: Opera 8.54 Windows Desktop userAgent string Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; nb) Opera 8.54 Opera 9.20, Windows Desktop userAgent string Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; nb) Opera 9.20 Opera 8.5 Nokia N800, Linux userAgent String Mozilla/4.0 (compatible; MSIE 6.0; X11; Linux armv6l; U) Opera 8.5 [no_NO] Maemo browser 0.7.11 RX-34_2007SE_3.2007.10-7 Basically the reason for Opera is not rendered as PPR capable or with partially broken PPR capabilities is that the browser up to version 9.0 always spoofed itself as MSIE. What I did, was to rearrange some of the if-elses in Core.js and AgentFactoryImpl.java. and instead of Opera beeing detected falsly as MSIE because of its spoof, I've hardcoded it to be detected as Gecko by the JavaScript. I'm not sure if this breaks any compability whatsoever, but it works for PPR at least, which was my goal. I have however another issue now, at least on the N800 device, I'm not sure how to exactly test this on the desktop: Every time a PPR is issued, it seems as the device downloads the script file as well, which is rather unnecessary - could this have anything to do with the browser not respecting header repsonse/expiry date of the script file? -- Safi Adam Winer skrev: The detection and support isn't there - we'd love a patch from someone with this device who could implement and test this functionality. -- Adam On 5/3/07, Safurudin Mahic [EMAIL PROTECTED] wrote: Hi, I am using trunk builds of Trinidad, it seems as the framework isn't capable of detecting the Opera browser (mobile edition, 8.5) on the Nokia N800 device as capable of doing PPR, page refreshs that were supposed to be PPR are actually full page refreshs. The framework is able to detect a regular desktop Opera 8.5 browser as PPR-capable. I believe it should be able to detect the Opera mobile as PPR-capable also, because both the mobile and the desktop browsers support the XmlHttpRequest JS object model, and I've found the N800 device to be working on several AJAX-enabled sites. Hope someone could provide an answer, or even better, a possible workaround for correct detection. Best regards, Safurudin Mahic
Re: [Trinidad] PPR detection algorithm - Opera 8.5 on Nokia N800
Your reply encouraged me to try a hack solution. I've managed to successfully test the PPR panelPageRoot and poll components with following browsers: Opera 8.54 Windows Desktop userAgent string Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; nb) Opera 8.54 Opera 9.20, Windows Desktop userAgent string Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; nb) Opera 9.20 Opera 8.5 Nokia N800, Linux userAgent String Mozilla/4.0 (compatible; MSIE 6.0; X11; Linux armv6l; U) Opera 8.5 [no_NO] Maemo browser 0.7.11 RX-34_2007SE_3.2007.10-7 Basically the reason for Opera is not rendered as PPR capable or with partially broken PPR capabilities is that the browser up to version 9.0 always spoofed itself as MSIE. What I did, was to rearrange some of the if-elses in Core.js and AgentFactoryImpl.java. and instead of Opera beeing detected falsly as MSIE because of its spoof, I've hardcoded it to be detected as Gecko by the JavaScript. I'm not sure if this breaks any compability whatsoever, but it works for PPR at least, which was my goal. I have however another issue now, at least on the N800 device, I'm not sure how to exactly test this on the desktop: Every time a PPR is issued, it seems as the device downloads the script file as well, which is rather unnecessary - could this have anything to do with the browser not respecting header repsonse/expiry date of the script file? -- Safi Adam Winer skrev: The detection and support isn't there - we'd love a patch from someone with this device who could implement and test this functionality. -- Adam On 5/3/07, Safurudin Mahic [EMAIL PROTECTED] wrote: Hi, I am using trunk builds of Trinidad, it seems as the framework isn't capable of detecting the Opera browser (mobile edition, 8.5) on the Nokia N800 device as capable of doing PPR, page refreshs that were supposed to be PPR are actually full page refreshs. The framework is able to detect a regular desktop Opera 8.5 browser as PPR-capable. I believe it should be able to detect the Opera mobile as PPR-capable also, because both the mobile and the desktop browsers support the XmlHttpRequest JS object model, and I've found the N800 device to be working on several AJAX-enabled sites. Hope someone could provide an answer, or even better, a possible workaround for correct detection. Best regards, Safurudin Mahic
[Trinidad] PPR detection algorithm - Opera 8.5 on Nokia N800
Hi, I am using trunk builds of Trinidad, it seems as the framework isn't capable of detecting the Opera browser (mobile edition, 8.5) on the Nokia N800 device as capable of doing PPR, page refreshs that were supposed to be PPR are actually full page refreshs. The framework is able to detect a regular desktop Opera 8.5 browser as PPR-capable. I believe it should be able to detect the Opera mobile as PPR-capable also, because both the mobile and the desktop browsers support the XmlHttpRequest JS object model, and I've found the N800 device to be working on several AJAX-enabled sites. Hope someone could provide an answer, or even better, a possible workaround for correct detection. Best regards, Safurudin Mahic
