[TOBAGO] renderedPartially does not work with defaultCommand
Hi all,
I have button that does some search and reloads the panel for results
tc:button id=submit
label=#{someBundle.search}
action=#{searchTermSimple.search}
tc:attribute name=renderedPartially
value=termSimpleSearchPanel /
/tc:button
if I add defaultCommand=true partial rendering does not work anymore :(
Any solution, please?
Thanks,
Stojan
[jira] Created: (TOBAGO-504) tc:time should have a step attribute
tc:time should have a step attribute -- Key: TOBAGO-504 URL: https://issues.apache.org/jira/browse/TOBAGO-504 Project: MyFaces Tobago Issue Type: New Feature Components: Core Affects Versions: 1.0.11 Environment: all Reporter: Zied Hamdi Hi, There's no way to say that time that isn't a multiple of 5 isn't relevant: the idea is to add a step (or minuteStep) attribute to tc:time so that when we click on the arrows the incremantal is done by this step instead of by one unconditionally. Regards, Zied Hamdi -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TRINIDAD-753) Open TODOs in SimpleSelectOneRenderer are breaking my session/log-in handling
Open TODOs in SimpleSelectOneRenderer are breaking my session/log-in handling - Key: TRINIDAD-753 URL: https://issues.apache.org/jira/browse/TRINIDAD-753 Project: MyFaces Trinidad Issue Type: Bug Affects Versions: 1.0.3-core Reporter: Stephen Friedrich Currently __getIndex() throws an exception if the submittedValue is not in the list of select items, or is not a number. That code is annotated with // TODO Don't throw exception: message!. It would be great if that TODO could be DONE ;-) In general the issue isn't really tragic, as the situation should not occur. However I just came across a situation where it actually is a problem: In my page there's a tr:selectOneChoice with autoSubmit=true. The nested selectItems tag calls a method on the server which depending on the logged-in user returns different items. Nothing exotic so far, right? Now if the session time out (or the user already logged out from a different tab/window), then that list is empty and that triggers the exception in the renderer, because the value from the select isn't in the list. Usually when the page is about to get redisplayed, the time-outed session would be detected and a redirect to a login page occurs. Only, I don't get that far because Trinidad throws an exception. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TRINIDAD-144) AJAX client validation creates blank space underneath inputs in IE6
[ https://issues.apache.org/jira/browse/TRINIDAD-144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12532391 ] Abhijit S Ghosh commented on TRINIDAD-144: -- Hi, Can you please attach a simple jsp testcase? Also does this problem repro only on IE6 and not on IE7? I can try to provide a patch upon investigation. Thanks, Abhi AJAX client validation creates blank space underneath inputs in IE6 --- Key: TRINIDAD-144 URL: https://issues.apache.org/jira/browse/TRINIDAD-144 Project: MyFaces Trinidad Issue Type: Bug Components: Build Affects Versions: 1.0.1-core, 1.0.2-core Environment: This will manifest itself using IE 6 Reporter: Nate Perkins Priority: Minor Due to the new AJAX based client validation, Inputs are expanded to show unnecessary space underneath them, as if an error message was going to be displayed under each one. The problem has been traced to the MessageRenderer class and its use of a span with style class OraInlineInfoText. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TOBAGO-505) tx:selectBooleanCheckbox with attribute labelWidth doesn't work
tx:selectBooleanCheckbox with attribute labelWidth doesn't work --- Key: TOBAGO-505 URL: https://issues.apache.org/jira/browse/TOBAGO-505 Project: MyFaces Tobago Issue Type: Bug Components: Facelets Affects Versions: 1.0.12 Environment: myfaces 1.1.6 (snap 11.09.2007), tobago 1.0.12 (snap 29.09.2007), facelets 1.1.13 Reporter: Guido Dubois tx:selectBooleanCheckbox with attribute labelWidth doesn't work together with facelets. If you indicate a value for labelwith, the label is rendered over the full width and the checkbox in a second line... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Maven Snapshot Build out of date?
Hello, I'm just wondering if there are other Maven Snapshot repositories beside http://people.apache.org/repo/m2-snapshot-repository/; as it seems that this repository is out of date. The myfaces-core artifacts haven't been modified since Sept 01, 2007 (for example see: http://people.apache.org/repo/m2-snapshot-repository/org/apache/myfaces/core/myfaces-impl/1.2.1-SNAPSHOT/). regards, Bernhard
[jira] Created: (TOBAGO-506) renderedPartially doesn't work with tc:cell, tc:tab and tc:tabgroup
renderedPartially doesn't work with tc:cell, tc:tab and tc:tabgroup --- Key: TOBAGO-506 URL: https://issues.apache.org/jira/browse/TOBAGO-506 Project: MyFaces Tobago Issue Type: Bug Affects Versions: 1.0.12 Environment: facelets, JSF 1.2 RI, ie7 and firefox2, tomahawk is installed too Reporter: Zied Hamdi Priority: Minor Commands with attribute name=renderedPartially doesn't work with tc:cell, tc:tab, tc:tabgroup. In addition, when pointed to tc:tab and tc:tabgroup javascript errors are generated and doesn't let the main job (action and actionListener) be executed. When pointed to tc:cell the action is executed and no message says it's not valid in the log. I think a sort of tree view building-time compiler could be of good help to community saying: component with id:xx of type yy can't be rendered partially for components that doesnt support partial rendering (eg. because they have no correspondance in the final tree). Finally if the id doesn't exist in the structure (mistyped), there's no warning message in the log, this could be a good developer friendly feature. I have put the bug as minor because we can surround tags by tc:panel and point these latters, then it works. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TOBAGO-507) renderedPartially with a null value throws a NullPointerException
renderedPartially with a null value throws a NullPointerException
-
Key: TOBAGO-507
URL: https://issues.apache.org/jira/browse/TOBAGO-507
Project: MyFaces Tobago
Issue Type: Bug
Components: Core
Affects Versions: 1.0.12
Environment: -
Reporter: Zied Hamdi
Priority: Minor
renderedPartially commands with a null value throws a NullPointerException
we can obtain null when we use templating.
java.lang.NullPointerException
at
org.apache.myfaces.tobago.renderkit.html.CommandRendererHelper.initOnclick(CommandRendererHelper.java:100)
at org.apache.myfaces.tobago.renderkit.html.CommandRendererHelper
.init(CommandRendererHelper.java:61)
at
org.apache.myfaces.tobago.renderkit.html.scarborough.standard.tag.TreeOldRenderer.getTreeNodeCommandVar(TreeOldRenderer.java:292)
at
org.apache.myfaces.tobago.renderkit.html.scarborough.standard.tag.TreeOldRenderer.createJavascript
(TreeOldRenderer.java:251)
in } else if (command instanceof
org.apache.myfaces.tobago.component.UICommand
((org.apache.myfaces.tobago.component.UICommand)
command).getRenderedPartially().length 0) {
we should have } else if (command instanceof
org.apache.myfaces.tobago.component.UICommand
((org.apache.myfaces.tobago.component.UICommand)
command).getRenderedPartially() != null
((org.apache.myfaces.tobago.component.UICommand)
command).getRenderedPartially().length 0) {
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (TOBAGO-508) defaultCommand does not work with renderedPartially
defaultCommand does not work with renderedPartially
---
Key: TOBAGO-508
URL: https://issues.apache.org/jira/browse/TOBAGO-508
Project: MyFaces Tobago
Issue Type: Bug
Components: Core
Affects Versions: 1.0.12
Environment: jdk1.6.0, Firefox, IE, Tomcat 5.x, 6.x
Reporter: Stojan Pesov
A button with renderedPartially attribute does not render partially if
defaultCommand=true is used
tc:button id=submit
label=#{someBundle.search}
action=#{searchTermSimple.search}
tc:attribute name=renderedPartially
value=termSimpleSearchPanel /
/tc:button
if I add defaultCommand=true partial rendering does not work anymore :(
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (TRINIDAD-754) NullPointerException if inputText in table is required in 1.2.2 branch
NullPointerException if inputText in table is required in 1.2.2 branch
--
Key: TRINIDAD-754
URL: https://issues.apache.org/jira/browse/TRINIDAD-754
Project: MyFaces Trinidad
Issue Type: Bug
Affects Versions: 1.2.3-core
Reporter: Jeanne Waldman
This bug only reproduces in the 1.2.2 branch, not in the 1.0.3 branch.
Open the table.jspx page in the trinidad-demo to edit it.
Change the second table's inputText to be required:
tr:inputText value=#{row.symbol} shortDesc=#{row.symbol}
required=true/
Run the demo page.
Clear one of the row's inputText that you made required.
Submit.
You will get the following NPE:
java.lang.NullPointerException
at
org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.MessageBoxRenderer._renderMessageAnchor(MessageBoxRenderer.java:295)
at
org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.MessageBoxRenderer._renderComponentMessages(MessageBoxRenderer.java:253)
at
org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.MessageBoxRenderer._renderContent(MessageBoxRenderer.java:194)
at
org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.MessageBoxRenderer$BoxRenderer.renderBody(MessageBoxRenderer.java:443)
at
org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.PanelBoxRenderer._renderMiddleRow(PanelBoxRenderer.java:267)
at
org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.PanelBoxRenderer.encodeAll(PanelBoxRenderer.java:115)
at
org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.MessageBoxRenderer.encodeAll(MessageBoxRenderer.java:135)
at
org.apache.myfaces.trinidad.render.CoreRenderer.encodeEnd(CoreRenderer.java:220)
at
org.apache.myfaces.trinidad.component.UIXComponentBase.encodeEnd(UIXComponentBase.java:749)
at
org.apache.myfaces.trinidad.render.RenderUtils.encodeRecursive(RenderUtils.java:69)
at
org.apache.myfaces.trinidad.render.CoreRenderer.encodeChild(CoreRenderer.java:294)
at
org.apache.myfaces.trinidad.render.CoreRenderer.encodeAllChildren(CoreRenderer.java:316)
at
org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.PanelPartialRootRenderer.renderContent(PanelPartialRootRenderer.java:64)
at
org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.BodyRenderer.renderContent(BodyRenderer.java:139)
at
org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.PanelPartialRootRenderer.encodeAll(PanelPartialRootRenderer.java:119)
at
org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.BodyRenderer.encodeAll(BodyRenderer.java:79)
at
org.apache.myfaces.trinidad.render.CoreRenderer.delegateRenderer(CoreRenderer.java:330)
at
org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.DocumentRenderer.encodeAll(DocumentRenderer.java:80)
at
org.apache.myfaces.trinidad.render.CoreRenderer.encodeEnd(CoreRenderer.java:220)
at
org.apache.myfaces.trinidad.component.UIXComponentBase.encodeEnd(UIXComponentBase.java:749)
at
org.apache.myfaces.trinidad.component.UIXComponentBase.__encodeRecursive(UIXComponentBase.java:1287)
at
org.apache.myfaces.trinidad.component.UIXComponentBase.encodeAll(UIXComponentBase.java:769)
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:892)
at
com.sun.faces.application.ViewHandlerImpl.doRenderView(ViewHandlerImpl.java:244)
at
com.sun.faces.application.ViewHandlerImpl.renderView(ViewHandlerImpl.java:175)
at
javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:178)
at
org.apache.myfaces.trinidadinternal.application.ViewHandlerImpl.renderView(ViewHandlerImpl.java:175)
at
com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:106)
at com.sun.faces.lifecycle.LifecycleImpl.phase(LifecycleImpl.java:251)
at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:144)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:245)
at com.evermind[Oracle Containers for J2EE 10g (11.1.1.0.0)
].server.http.ResourceFilterChain.doFilter(ResourceFilterChain.java:65)
at
org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl._invokeDoFilter(TrinidadFilterImpl.java:241)
at
org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl._doFilterImpl(TrinidadFilterImpl.java:198)
at
org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl.doFilter(TrinidadFilterImpl.java:141)
at
org.apache.myfaces.trinidad.webapp.TrinidadFilter.doFilter(TrinidadFilter.java:92)
at com.evermind[Oracle Containers for J2EE 10g (11.1.1.0.0)
].server.http.EvermindFilterChain.doFilter(EvermindFilterChain.java:15)
at
org.apache.myfaces.trinidaddemo.webapp.RedirectFilter.doFilter(RedirectFilter.java:97)
at com.evermind[Oracle Containers for J2EE 10g (11.1.1.0.0)
].server.http.ServletRequestDispatcher.invoke(ServletRequestDispatcher.java:611)
at com.evermind[Oracle Containers for J2EE 10g (11.1.1.0.0)
].server.http.ServletRequestDispatcher.forwardInternal(ServletRequestDispatcher.java:362)
at
[Portal] API Approved
Hey guys, Good news!! I got permission to change the copyrights on the API for the portlet bridge code donation. The JSR EG is simply going to copyright the spec and the JavaDocs (like what's in the Faces Spec). I've got a local environment which fixes some of the issues I've been writing JIRA tickets for and I will be switching the licensing this weekend so I'll upload the new code donation and get the paperwork done so we can get this thing rolling. Thanks for all your patience. BTW- What do I have to do to become an administrator of the JSR-301 Jira project. I'd like to assign some issue to myself and be able to close them and whatnot. Scott
[jira] Commented: (TOBAGO-505) tx:selectBooleanCheckbox with attribute labelWidth doesn't work
[ https://issues.apache.org/jira/browse/TOBAGO-505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12532509 ] Guido Dubois commented on TOBAGO-505: - Same behaviour for tx:in tx:selectBooleanCheckbox with attribute labelWidth doesn't work --- Key: TOBAGO-505 URL: https://issues.apache.org/jira/browse/TOBAGO-505 Project: MyFaces Tobago Issue Type: Bug Components: Facelets Affects Versions: 1.0.12 Environment: myfaces 1.1.6 (snap 11.09.2007), tobago 1.0.12 (snap 29.09.2007), facelets 1.1.13 Reporter: Guido Dubois tx:selectBooleanCheckbox with attribute labelWidth doesn't work together with facelets. If you indicate a value for labelwith, the label is rendered over the full width and the checkbox in a second line... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[orchestra] combining OrchestraServletFilter and RequestParameterServletFilter
G'day, There are three servlet filters provided by orchestra: * filter.OrchestraServletFilter is optional, and just provides some nice to have stuff. * JsfFrameworkAdapterFilter (formerly FrameworkAdapterFilter) sets up the jsf adapter for orchestra. * RequestProviderServletFilter intercepts calls to encodeURL. Class conversation.jsf.OrchestraServletFilter combines the first two, so that the user has to only configure one filter not two. Should we make conversation.jsf.OrchestraServletFilter also include the RequestProviderServletFilter to make it a one stop shop? Regards, Simon
[orchestra] ConversationContext.removeConversation
Hi,
We have this method in ConversationContext:
/**
* Remove the conversation from this context.
*
* pNotice: It is assumed that the conversation has already been
invalidated./p
*/
protected void removeConversation(Conversation conversation)
{
synchronized (this)
{
touch();
conversations.remove(conversation.getName());
}
}
If the conversation is assumed to be invalidated, then perhaps we should
check, and throw an exception if it is not? What do you think?
It is currently called only from the Conversation.destroy() method and
ConversationManager.removeConversation. In the first case, the
conversation is definitely invalidated. In the second, there do not
appear to be any existing callers of that method.
Regards, Simon
[jira] Updated: (TRINIDAD-713) Using name as the id for a component breaks form submission. name appears to be an undocumented reserved identifier.
[
https://issues.apache.org/jira/browse/TRINIDAD-713?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leonardo Uribe updated TRINIDAD-713:
Status: Patch Available (was: Open)
Using name as the id for a component breaks form submission. name appears
to be an undocumented reserved identifier.
Key: TRINIDAD-713
URL: https://issues.apache.org/jira/browse/TRINIDAD-713
Project: MyFaces Trinidad
Issue Type: Bug
Components: Components
Affects Versions: 1.2.2-core
Reporter: Mike Hanafey
Attachments: patchInvalidIdNameComponent.patch
Using the trinidad-blank as an example, if the the id of the input field in
page1.jspx is changed from:
tr:inputText label=Your name id=input1
value=#{helloWorldBacking.name} required=true/
to:
tr:inputText label=Your name id=name
value=#{helloWorldBacking.name} required=true/
nothing happens when the press me button is pushed (the form is not posted).
The following JavaScript error is reported:
Error ``TypeError: a0.split is not a function'' [xs] in file
``http://localhost:8080/trinidad/adf/jsLibs/Common1_2_2.js'', line 4512,
character 0.
In the code fragment below a0 has been resolved to the HTMLFormElement, but
apparently because the form contains a button element named name, a0.name
does not return the form name, but instead the button instance, and split
is not a method on HTMLButtonElement.
4861 if(!a0)
4862 return false;
4863 var a6=window[_+_getJavascriptId(a0.name)+Validator];
4864 if(a6==(void 0))
function _getJavascriptId(a0)
4511 {
4512 return a0.split(':').join('_');
4513 }
Is there a way in JavaScript to avoid this name conflict? It does not seem
reasonable it is illegal to add an element called name to a form.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (TRINIDAD-755) Positions of required and message label should be skinnable
Positions of required and message label should be skinnable --- Key: TRINIDAD-755 URL: https://issues.apache.org/jira/browse/TRINIDAD-755 Project: MyFaces Trinidad Issue Type: New Feature Components: Skinning Affects Versions: 1.0.3-core Reporter: Stephen Friedrich Currently Trinidad always shows icon and text of a label in this order: message-icon required-.icon text It should be able to specify a different order in the skin. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TRINIDAD-755) Positions of required and message label should be skinnable
[ https://issues.apache.org/jira/browse/TRINIDAD-755?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Friedrich updated TRINIDAD-755: --- Status: Patch Available (was: Open) Positions of required and message label should be skinnable --- Key: TRINIDAD-755 URL: https://issues.apache.org/jira/browse/TRINIDAD-755 Project: MyFaces Trinidad Issue Type: New Feature Components: Skinning Affects Versions: 1.0.3-core Reporter: Stephen Friedrich Attachments: positions.patch Currently Trinidad always shows icon and text of a label in this order: message-icon required-.icon text It should be able to specify a different order in the skin. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: required icon after label: How to best implement skinning?
Thanks Simon, implementation is done, please see https://issues.apache.org/jira/browse/TRINIDAD-755 I tried to to keep the code changes small, but failed. First, if the position of the required icon is skinnable, then the position of the message icon should sure be skinnable, too. Yet, now one must care for the relative ordering in between both icons, too. I solved that by specify the position as an integer index relative to the text position, so -2 for message icon and -1 for required icon is the default, -1 for message and +1 for required would show the message icon in front of and the required icon after the text. There is so much code just to determine whether an icon is shown at all. I need to check that first, to figure out if a nbsp; is needed in front of and/or behind the label's text. Most of that code would be needed again if the icon is finally really rendered. To avoid that you can of course remember each icon's details (message type, alt text, ...). Well, to remember it, it makes sense to encapsulate it. If you encapsulate it, you can just as well move icon specific code to the encapsulation class, using it as a delegate from within the renderer. Then it makes sense to move code that is common for both delegates to a base class. Two utility methods that were available from within the renderer at a base class were not accessible from the delegates. I made them static, which is probably ok, because several other methods of the same kind were already static. All in all I think the code is more readable now. Would be great of you could review and comment. If the overall scheme is acceptable, please commit. I'll integrate your comments from there. Thanks again, Stephen Simon Lessard wrote: Hello Stephen, This is definitely a skin property case, not per component. There's no strict rule though. About the name, maybe -tr-required-icon-position? ~ Simon On 10/1/07, *Stephen Friedrich* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: I have just changed the OutputLabelRenderer to optionally render the required icon _after_ the label. How should I implement skinning for that? (Currently I check a system property, that I set in my test code.) What is the practical difference between defining a new skinning property vs. a component key? Any preference regarding a name and possible value for the property/key? Will you accept a patch if I supply it? After all IMHO it is much more common to append the required indicator to the label.
[jira] Created: (TRINIDAD-756) Event delivery phases get overwritten
Event delivery phases get overwritten - Key: TRINIDAD-756 URL: https://issues.apache.org/jira/browse/TRINIDAD-756 Project: MyFaces Trinidad Issue Type: Bug Components: Build Affects Versions: 1.2.3-plugins, 1.2.2-plugins Reporter: Bud Osterberg Attachments: phases.patch The description for a lot of events looks something like this: mfp:event mfp:event-typeorg.apache.myfaces.trinidad.AttributeChange/mfp:event-type mfp:event-delivery-phaseInvoke Application/mfp:event-delivery-phase mfp:event-delivery-phaseApply Request Values/mfp:event-delivery-phase /mfp:event However, the setEventDeliveryPhases method just assigns the input array to _deliveryPhases. This results in the tagdoc only listing the last phase (Apply Request Values in the example above). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TRINIDAD-756) Event delivery phases get overwritten
[ https://issues.apache.org/jira/browse/TRINIDAD-756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bud Osterberg updated TRINIDAD-756: --- Status: Patch Available (was: Open) Event delivery phases get overwritten - Key: TRINIDAD-756 URL: https://issues.apache.org/jira/browse/TRINIDAD-756 Project: MyFaces Trinidad Issue Type: Bug Components: Build Affects Versions: 1.2.2-plugins, 1.2.3-plugins Reporter: Bud Osterberg Attachments: phases.patch The description for a lot of events looks something like this: mfp:event mfp:event-typeorg.apache.myfaces.trinidad.AttributeChange/mfp:event-type mfp:event-delivery-phaseInvoke Application/mfp:event-delivery-phase mfp:event-delivery-phaseApply Request Values/mfp:event-delivery-phase /mfp:event However, the setEventDeliveryPhases method just assigns the input array to _deliveryPhases. This results in the tagdoc only listing the last phase (Apply Request Values in the example above). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
