[jira] Commented: (TRINIDAD-773) Inefficient way to create faces ben in FacesBeanFactory
[
https://issues.apache.org/jira/browse/TRINIDAD-773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12545187
]
Adam Winer commented on TRINIDAD-773:
-
At a quick glance, this checkin has a big thread-safety problem:
FacesBeanFactory can be called from multiple threads, but you're using a
non-threadsafe data structure.
Switch that HashMap to a ConcurrentHashMap and it'll be safe.
Inefficient way to create faces ben in FacesBeanFactory
---
Key: TRINIDAD-773
URL: https://issues.apache.org/jira/browse/TRINIDAD-773
Project: MyFaces Trinidad
Issue Type: Bug
Reporter: Stevan Malesevic
Assignee: Jeanne Waldman
Fix For: 1.0.5-core
It seems that the way FacesBeanFactory::createFacesBean creates faces bean is
were inefficient. The problem is that for the case where we have deep
subclass structure and root class defines the bean we will make a numerouse
calls to createFacesBean before we find out the type for the bean. This will
burn the CPU and use memory to create all the keys. One possible optimization
might be to create a map between ownerClass|rendererType and calss for the
bean at the top level where the createFacesBean is called. So, next call will
find it right away. I played with the dirty prototype for this and I was able
to see memory improvement of about 140K per request (I have not measure CPU
improvement).
The prototype I had looked like (were dirty but it works):
/*
* Licensed to the Apache Software Foundation (ASF) under one
* or more contributor license agreements. See the NOTICE file
* distributed with this work for additional information
* regarding copyright ownership. The ASF licenses this file
* to you under the Apache License, Version 2.0 (the
* License); you may not use this file except in compliance
* with the License. You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing,
* software distributed under the License is distributed on an
* AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
* KIND, either express or implied. See the License for the
* specific language governing permissions and limitations
* under the License.
*/
package org.apache.myfaces.trinidad.bean;
import java.io.InputStream;
import java.io.IOException;
import java.net.URL;
import java.util.ArrayList;
import java.util.Collections;
import java.util.Enumeration;
import java.util.HashMap;
import java.util.List;
import java.util.Map;
import java.util.Properties;
import org.apache.myfaces.trinidad.logging.TrinidadLogger;
/**
* Base interface for FacesBean storage.
*
*/
public class FacesBeanFactory
{
/**
* Create a FacesBean for a component class.
*/
// TODO change from ownerClass to componentFamily?
static public FacesBean createFacesBean(
Class? ownerClass,
String rendererType)
{
if (ownerClass == null)
return null;
String className = ownerClass.getName();
FacesBean bean = createFacesBean(className, rendererType);
if (bean == null rendererType != null)
{
bean = createFacesBean(className, null);
if(bean != null)
{
String typeKey = (rendererType != null)
? new
StringBuilder(className).append(|).append(rendererType).toString()
: className;
_TYPES_CLASS.put(typeKey, bean.getClass());
}
}
if (bean == null)
{
bean = createFacesBean(ownerClass.getSuperclass(), rendererType);
if(bean != null)
{
String typeKey = (rendererType != null)
? new
StringBuilder(className).append(|).append(rendererType).toString()
: className;
_TYPES_CLASS.put(typeKey, bean.getClass());
}
}
return bean;
}
static public FacesBean createFacesBean(
String beanType,
String rendererType)
{
String typeKey = (rendererType != null)
? new
StringBuilder(beanType).append(|).append(rendererType).toString()
: beanType;
Class? type = _TYPES_CLASS.get(typeKey);
if(type == null)
{
String className = (String) _TYPES_MAP.get(typeKey);
if (className == null)
return null;
try
{
type = _getClassLoader().loadClass(className);
_TYPES_CLASS.put(typeKey, type);
}
catch (ClassNotFoundException cnfe)
{
_LOG.severe(CANNOT_FIND_FACESBEAN, className);
_LOG.severe(cnfe);
}
}
try
{
return (FacesBean) type.newInstance
Re: [Trinidad] Dialog - DialogRequest.java
Sounds like the right thing to do. -- Adam On 11/4/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: ok, no complains, here On 10/30/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: Hi Mario, yes, but since this isn't there since a long time, I am asking. Orchestra is really nice :-) -M On 10/30/07, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi Matthias! but Orchestra expects a conversationContext param in that URL, like /__ADFv__.xhtml?_afPfm=5c4a2651_t=fred_vir=/gmap/map.xhtmlloc=enconversationContext=1 Doing this as well: context.getExternalContext().encodeActionURL(theUrlWeCreated); I don't know anything about Trinidad, but I am pretty sure it is save to add this encoding, else, the windowing stuff will fail with cookies-only environments as then the ;jsessionid= is missing too. Ciao, Mario -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ mail: matzew-at-apache-dot-org -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ mail: matzew-at-apache-dot-org
[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
]
Adam Winer updated TRINIDAD-713:
Resolution: Fixed
Fix Version/s: 1.0.4-core
Assignee: Adam Winer
Status: Resolved (was: Patch Available)
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
Assignee: Adam Winer
Fix For: 1.0.4-core
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] 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 ] Adam Winer updated TRINIDAD-756: Resolution: Fixed Fix Version/s: 1.2.4-plugins Status: Resolved (was: Patch Available) 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 Fix For: 1.2.4-plugins 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.
Re: [Trinidad] Patches! Fresh patches! Patches anybody?
Hey, Stephen, a couple of comments: - The patch for 755 includes a lot of changes that aren't specific to your work (removing unnecessary imports, whitespace adjustments, etc.) If you want to create separate, minor issues of Unnecessary imports, and attach a separate patch there, that's cool. - It's really good to have some discussions over the APIs, instead of asking for patches to be checked in as is. - Looking at the patch, it seems as though you're using properties including af|outputLabel; yet the skin selector doc just referred to -tr-required-icon-position. I think this is a skinning property that is not at all specific to outputLabel, so the doc is right, the code wrong. -- Adam On 10/12/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: What is the best way to contribute to Trinidad? I went ahead and supplied two patches for issues I was having with missing skinning features: TRINIDAD-755, TRINIDAD-745 Right now, I am missing another feature (putting labels _above_ fields). I am a little hesitant to supply yet another patch while I haven't heard anything on my older patches. Can a committer please have a look at my previous patches and comment on them? I am willing to put some more work into them if you see any flaws, but it would be great if in the end the features would make it into the code base. Thanks a lot!
[jira] Resolved: (TRINIDAD-754) NullPointerException if inputText in table is required in 1.2.2 branch
[
https://issues.apache.org/jira/browse/TRINIDAD-754?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adam Winer resolved TRINIDAD-754.
-
Resolution: Fixed
Fix Version/s: 1.2.3-core
Assignee: Adam Winer
Fixed in the real 1.2.3 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
Reporter: Jeanne Waldman
Assignee: Adam Winer
Fix For: 1.2.3-core
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
Re: [Trinidad] please comment on the following bug
On 10/8/07, Andrew Robinson [EMAIL PROTECTED] wrote: My recommendation is to change the code and documentation to: - If the component is a naming container, search relative to the parent; otherwise search relative to the component But what if the person does want to search the children? If the parent was used, they would have to refer to themselves, which is more confusing IMO. I agree, that's confusing. But, IMO, I think that requiring :: for finding peers: af:commandLink id=foo .../ af:table partialTriggers=::foo.../af:table is also really confusing, and suspect that searching for peers is much more common than searching for children. Plus, it's existing behavior, and breaking existing behavior is never a good thing. -- Adam Example: my:namingContainer partialTriggers=link tr:commandLink id=link partialSubmit=true / /my:namingContainer versus: my:namingContainer id=nc partialTriggers=nc:link tr:commandLink id=link partialSubmit=true / /my:namingContainer So, if it was left as-is in terms of documentation, the following would be the correct way to refer to a child and refer to a sibling: tr:commandLink id=outsideLink / my:namingContainer partialTriggers=link, ::outsideLink tr:commandLink id=link partialSubmit=true / /my:namingContainer That seems to make sense to me at least -Andrew
Re: [Trinidad] navigationTree not refactored???
It's desperately in need of refactoring to extend off of the new TreeRenderer, and not the old 'uix' one. -- Adam On 10/8/07, Cristi Toth [EMAIL PROTECTED] wrote: Hi all! I need I really need the navigationTree and I noticed the renderer is still in the 'uix' package and that the code is... still old style and I don't understand nothing. It's extremely short and I didn't figure it out where's all the rendering implemented. Can somebody help me with some hints? I would like to refactor it and enhance its skinning (which for now seems to be disabled) -- Cristi Toth - Codebeat www.codebeat.ro
Re: [Trinidad] navigationTree not refactored???
Ah, OK, I see the confusion. The renderer in uix handles the decoding side of things. The renderer in uinode handles just the rendering thing, 'cause it's from an old architecture that didn't have any built-in decoding. Ideally, we'd have one new renderer in core.xhtml that extends TreeRenderer in core.xhtml. -- Adam On 10/8/07, Cristi Toth [EMAIL PROTECTED] wrote: Hi Adam! No problem, I'll do it. But I need to know some start points... i.e. It took me some 1/2 hour to figure that the actual renderer that does the job is the NavigationTreeRenderer from ui.laf.desktop package not the close to useless one from the uix package. Is something from the uix package classes really needed in this case? Should I rely on the old ComandNavigationRenderer or refactor that too? Please tell from where to start (so I don't loose to much time) and what things should I look for (not to mess it up). I really need this and I have a very short time for this. (wednesday at noon) On 10/9/07, Adam Winer [EMAIL PROTECTED] wrote: It's desperately in need of refactoring to extend off of the new TreeRenderer, and not the old 'uix' one. -- Adam On 10/8/07, Cristi Toth [EMAIL PROTECTED] wrote: Hi all! I need I really need the navigationTree and I noticed the renderer is still in the 'uix' package and that the code is... still old style and I don't understand nothing. It's extremely short and I didn't figure it out where's all the rendering implemented. Can somebody help me with some hints? I would like to refactor it and enhance its skinning (which for now seems to be disabled) -- Cristi Toth - Codebeat www.codebeat.ro -- Cristi Toth - Codebeat www.codebeat.ro
Re: [Trinidad] please comment on the following bug
Here's the background: - The ::, ::: support is relatively recent. - Because of that, there originally was no way for a table to be triggered by anything but its own children, since a table is a naming container! This was a high priority issue back in the day, and the fix (then) was to change addPartialTriggerListeners() from using the component itself to the parent. And, sadly, the documentation didn't follow. So, to answer one question - how many users are dependent on this broken behavior - the answer is TONS. Change it, and you'll break partialTriggers on all tables. Which is bad. The question of how many people rely on the behavior of :: when you're on a non-naming container whose immediate parent is a naming container is far trickier to answer. Someone out there will care, and have their code broken, but it's not the massive hell that changing it for components that are themselves naming containers would be. My recommendation is to change the code and documentation to: - If the component is a naming container, search relative to the parent; otherwise search relative to the component Then the next question is whether, on failure for the non-NC case, we should do a second search relative to the parent, just for backwards compatibility, but deprecate that pattern (perhaps by logging at INFO that a deprecated usage of partialTriggers is in effect). -- Adam On 10/5/07, Andrew Robinson [EMAIL PROTECTED] wrote: The API for the partialTriggers seems to be broken for Trinidad trunk components. The bug is: https://issues.apache.org/jira/browse/TRINIDAD-757 Please review the comments and offer any opinions on changing the current method to match the documentation. Also please check that we are right. Thanks, Andrew
Re: [Trinidad] ValueExpression in 1.2 and ValueBinding in 1.1
For brand new APIs, I'm very tempted not to add backwards compatibility to the 1.2 branch. Dunno, could go either way on this one. -- Adam On 9/27/07, Jeanne Waldman [EMAIL PROTECTED] wrote: Matthias Wessendorf wrote: Hi, My understanding is that Trinidad trunk cannot use ValueExpression. Is this true? yes, the ValueExpression comes from the unified el, which is part of JSP 2.1 If so, is it ok to have an API that takes ValueBinding in trunk and ValueExpression in 1.2*branch? In other words, does the 1.2* branch of Trinidad have to keep backward compatibility, thus I would have a deprecated constructor that takes ValueBinding and another constructor that takes ValueExpression. I think doing the two constructors, where one takes VBinding and is deprecated is OK. JSF API itself also keeps the old methods for backward compatibility and adds new APIs that work w/ the javax.el clazzes Yeah, I was wondering what our policy is for backward compatibility between ValueExpression and ValueBinding. I see we do it in some places (e.g., FacesBean) but not others (e.g., DateTimeRangeValidator). -M Thanks, Jeanne
Re: Opinion on a possible page flow scope bug
It's a long-standing problem with form URL encoding.
If you don't add anything to pageFlowScope until Render Response,
those objects will be lost, 'cause the token is written out on the
form too early. We try to be conservative and not generate new
pageFlowScopes unless its necessary.
The workaround is to make sure that at least one object
gets set on the pageFlowScope by beforePhase() of
Render Response. Could be :
pageFlowScope.put(foo, bar);
... doesn't matter what.
-- Adam
On 9/28/07, Simon Lessard [EMAIL PROTECTED] wrote:
Hi all,
We have a client who played with page flow scope and bit and came to the
following. Of course, the use case is extremely synthetic, but it's still
strange:
page.jspx
f:view
tr:document
tr:form
tr:inputText value=#{bean.value}/
tr:commandButton text=Go/
/tr:form
/tr:document
/f:view
Bean.java
public class Bean
{
public Bean()
{
RequestContext rContext =
RequestContext.getCurrentInstance ();
MapString, Object pageFlowScope = rContext.getPageFlowScope();
if (!pageFlowScope.containsKey(someKey))
{
System.out.println(Creating the long to create object and we sure
don't want to create it twice for the page flow);
pageFlowScope.put(someKey, getAnExpensiveToCreate Object());
}
}
public String getValue()
{
RequestContext rContext =
RequestContext.getCurrentInstance ();
MapString, Object pageFlowScope = rContext.getPageFlowScope();
return
((SomeClass)pageFlowScope.get(someKey)).getStringAttribute();
}
public void setValue(String value)
{
RequestContext rContext =
RequestContext.getCurrentInstance();
MapString, Object pageFlowScope = rContext.getPageFlowScope();
((SomeClass)pageFlowScope.get(someKey)).setStringAttribute(value
);
}
}
With that code, the expensive object is going to be created twice, when the
page is first rendered and on first postback. This happen because at the
time the form is rendered, the page flow scope is still empty (bean was
never referenced) and the default behavior in that case is to not add the
token to the action url thus losing the object. Therefore, if you change the
page to
page.jspx
f:view
tr:document
tr:outputText value=#{bean.value}/
tr:form
tr:inputText value=#{bean.value}/
tr:commandButton text=Go/
/tr:form
/tr:document
/f:view
Then the expensive object get created only once. Personally I think we
should consider that a bug as it's very counter intuitive and hard to debug.
Am I missing something?
Regards,
~ Simon
Re: Opinion on a possible page flow scope bug
Yeah, absolutely a hack.
Option #2 that I can think of is caching the action URL at
the start of the FormRenderer encoding, then re-querying it
at the end. If it's changed, add Javascript to find the form
and overwrite the action. Also gross, but at least it's not
as bad as adding a configuration switch.
-- Adam
On 9/28/07, Simon Lessard [EMAIL PROTECTED] wrote:
Yeah, that's what we figured while playing with it, but it's not the most
elegant solution. Maybe we should make that configurable in trinidad-config
(not supporting EL)? Most users can probably deal with the issue so it
should not save the scope by default when it's empty, but users needing it
would be able to without using that hack, because that's really what it is.
~ Simon
On 9/28/07, Adam Winer [EMAIL PROTECTED] wrote:
It's a long-standing problem with form URL encoding.
If you don't add anything to pageFlowScope until Render Response,
those objects will be lost, 'cause the token is written out on the
form too early. We try to be conservative and not generate new
pageFlowScopes unless its necessary.
The workaround is to make sure that at least one object
gets set on the pageFlowScope by beforePhase() of
Render Response. Could be :
pageFlowScope.put (foo, bar);
... doesn't matter what.
-- Adam
On 9/28/07, Simon Lessard [EMAIL PROTECTED] wrote:
Hi all,
We have a client who played with page flow scope and bit and came to the
following. Of course, the use case is extremely synthetic, but it's
still
strange:
page.jspx
f:view
tr:document
tr:form
tr:inputText value=#{bean.value}/
tr:commandButton text=Go/
/tr:form
/tr:document
/f:view
Bean.java
public class Bean
{
public Bean()
{
RequestContext rContext =
RequestContext.getCurrentInstance ();
MapString, Object pageFlowScope = rContext.getPageFlowScope();
if (!pageFlowScope.containsKey(someKey))
{
System.out.println(Creating the long to create object and we sure
don't want to create it twice for the page flow);
pageFlowScope.put(someKey, getAnExpensiveToCreate Object());
}
}
public String getValue()
{
RequestContext rContext =
RequestContext.getCurrentInstance ();
MapString, Object pageFlowScope = rContext.getPageFlowScope();
return
((SomeClass)pageFlowScope.get(someKey)).getStringAttribute();
}
public void setValue(String value)
{
RequestContext rContext =
RequestContext.getCurrentInstance();
MapString, Object pageFlowScope = rContext.getPageFlowScope();
((SomeClass)pageFlowScope.get(someKey)).setStringAttribute(value
);
}
}
With that code, the expensive object is going to be created twice, when
the
page is first rendered and on first postback. This happen because at the
time the form is rendered, the page flow scope is still empty (bean was
never referenced) and the default behavior in that case is to not add
the
token to the action url thus losing the object. Therefore, if you change
the
page to
page.jspx
f:view
tr:document
tr:outputText value=#{ bean.value}/
tr:form
tr:inputText value=#{bean.value}/
tr:commandButton text=Go/
/tr:form
/tr:document
/f:view
Then the expensive object get created only once. Personally I think we
should consider that a bug as it's very counter intuitive and hard to
debug.
Am I missing something?
Regards,
~ Simon
Re: [Trinidad] Skinning the tree
I agree with Jeanne's suggestions - and also with Martin!
These will be great (and long overdue) improvements.
Cheers,
Adam
On 9/27/07, Martin Marinschek [EMAIL PROTECTED] wrote:
Perfect.
With these additions and some more detailed skinning of the table
paging and sorting, we might get rid of the +/- statement about
design for Trinidad at http://www.jsfmatrix.net.
regards,
Martin
On 9/27/07, Jeanne Waldman [EMAIL PROTECTED] wrote:
Cristi Toth wrote:
Hi all,
I've done some work on the tree renderer in Trinidad
I added the connecting lines, like in Tomahawk (or any other tree) behind
the expanded/collapsed icon (-, +)
I now have 5 skin-selectors for the tree:
af|tree::expanded-icon
af|tree::collapsed-icon
- these are the [-], [+] icons
af|tree::line-icon - this one is the vertical line
af|tree::line-middle-icon - this one is the horizontal line for each entry
(used in the back of the expanded/collapsed icon)
af|tree::line-last-icon - this one is like the one above, but it is used in
the case of the last sibling (the corner)
now some questions:
1) should I add a 'renderLines' attribute to the 'tree' component to
enable/disable the lines ?
I would make this a skin property, not a per instance component property.
Something like:
af|tree { -tr-render-lines: true}
2) should I let the lines be skinnable and add them to the base skin?
it's up to you. Showing/hiding them with the skin property probably is
enough.
3) if I let them be skinnable, then should I ommit the 'renderLines' attr
and let the user just override the line icons with blank ones?
again, I think this should be a skin property.
Next, I worked on the TreeTable renderer. I made the 'Expand All / Collapse
All' links skinnable.
1. should I move the the 'Expand All / Collapse All' links on the first row
and get rid of the 2nd ?
It seems quite useless to have 2 rows
not sure what you mean.
2. should I also make the focus link 'X' skinnable (it looks kind of lame
right now) ?
sure. I'm surprised it isn't already.
3. should I add some attributes for disabling the focus column and the
breadCrumbs, for people who don't need them?
4. I noticed a bug in the row banding, it's not correctly rendered, I
suppose it would be nice if I fix it...
You can see here a pictures with the results of what I did until now:
http://people.apache.org/~ckormos/tree_skinning.png
Is this welcomed by you guys?
I like it.
regards,
--
Cristi Toth
-
Codebeat
www.codebeat.ro
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
Re: VOTE-RESULT (was Re: [vote] release of Trinidad plugins (1.2.3))
Yeah, absolutely, I agree. Any reasonable -1 should be taken seriously, even from a non-committer. -- Adam On 9/26/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: that was not related to your vote :-) That was just an update on the release-voting process ;-) If for instance, a user finds a very important thing, that REALLY needs to be fixed before doing a release. Her/His -1 vote will get attention as well ;-) -Matthias On 9/26/07, Andrew Robinson [EMAIL PROTECTED] wrote: FYI, remember that my vote is not official, I am a committer, not a PMC/voting member. -Andrew On 9/26/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: Hi, we got five +1 votes: -Matthias Wessendorf -Andrew Robinson -Grant Smith -Simon Lessard -Adam Winer Afterwards, we got a -1 from Andrew Robinson, but he made a withdraw of his -1 vote. Note, that there is no veto on a release: http://www.apache.org/foundation/voting.html#ReleaseVotes But usually a -1 is a valid reason to rethink the release! Not needed here, because the withdraw of Andrew's -1 ;-) I'll follow up w/ the required announcement etc. -Matthias On 9/23/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: Hi, I was running the needed tasks to get the 1.2.3 release of the Apache MyFaces Trinidad Maven 2 Plugins out. Note, that this is the first version of the unified Trinidad plugins, that will be used for our JSF 1.1 and JSF 1.2 CORE. The artifacts are deployed to my private Apache account ([1]). Please take a look at the 1.2.3 artifacts and vote. How to test those JARs ? 1. there is now a zip file (org.zip) (see [1]) 2. use the stage repo inside your pom.xml file: ... pluginRepositories pluginRepository idapache.stage/id nameApache Stage Repository/name urlhttp://people.apache.org/~matzew/123-plugins/url layoutdefault/layout /pluginRepository /pluginRepositories ... [ ] +1 for community members who have reviewed the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released, and why.. Thanks, Matthias -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ mail: matzew-at-apache-dot-org -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ mail: matzew-at-apache-dot-org -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ mail: matzew-at-apache-dot-org
Re: [vote] release of Trinidad plugins (1.2.3)
Yeah, no one has had any incentive yet to implement non-Trinidad 1.1 component generation. I don't know anyone that's working on it. -- Adam On 9/26/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: Should this be filed as a bug, or is it a known issue / work in progress? I think that is the case, because Bruno enabled it (maven-faces-plg) to generate our JSF 1.2 MyFaces Core stuff. -Matthias -Andrew On 9/23/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: Hi, I was running the needed tasks to get the 1.2.3 release of the Apache MyFaces Trinidad Maven 2 Plugins out. Note, that this is the first version of the unified Trinidad plugins, that will be used for our JSF 1.1 and JSF 1.2 CORE. The artifacts are deployed to my private Apache account ([1]). Please take a look at the 1.2.3 artifacts and vote. How to test those JARs ? 1. there is now a zip file (org.zip) (see [1]) 2. use the stage repo inside your pom.xml file: ... pluginRepositories pluginRepository idapache.stage/id nameApache Stage Repository/name urlhttp://people.apache.org/~matzew/123-plugins/url layoutdefault/layout /pluginRepository /pluginRepositories ... [ ] +1 for community members who have reviewed the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released, and why.. Thanks, Matthias -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ mail: matzew-at-apache-dot-org -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ mail: matzew-at-apache-dot-org
[jira] Created: (TRINIDAD-742) RenderKit test framework doesn't load RenderKitFactories from faces-config.xml
RenderKit test framework doesn't load RenderKitFactories from faces-config.xml -- Key: TRINIDAD-742 URL: https://issues.apache.org/jira/browse/TRINIDAD-742 Project: MyFaces Trinidad Issue Type: Test Affects Versions: 1.0.2-core Reporter: Adam Winer Assignee: Adam Winer The RenderKit test framework currently hardcodes CoreRenderKitFactory, but doesn't support any 3rd party renderkit factories. This makes it hard to test anything that relies on an extended factory. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (TRINIDAD-742) RenderKit test framework doesn't load RenderKitFactories from faces-config.xml
[ https://issues.apache.org/jira/browse/TRINIDAD-742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Winer resolved TRINIDAD-742. - Resolution: Fixed Fixed. RenderKit test framework doesn't load RenderKitFactories from faces-config.xml -- Key: TRINIDAD-742 URL: https://issues.apache.org/jira/browse/TRINIDAD-742 Project: MyFaces Trinidad Issue Type: Test Affects Versions: 1.0.2-core Reporter: Adam Winer Assignee: Adam Winer The RenderKit test framework currently hardcodes CoreRenderKitFactory, but doesn't support any 3rd party renderkit factories. This makes it hard to test anything that relies on an extended factory. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [vote] release of Trinidad core (1.0.3)
Oops... I just checked in a fix for TRINIDAD-742: RenderKit test framework doesn't load RenderKitFactories from faces-config.xml Any chance of re-spinning the release candidate? -- Adam On 9/26/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: +1 On 9/26/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: Hi, I was running the needed tasks to get the 1.0.3 release of the Apache MyFaces Trinidad CORE out. The artifacts are deployed to my private Apache account ([1]). Please take a look at the 1.0.3 artifacts and vote [ ] +1 for community members who have reviewed the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released, and why.. Thanks, Matthias [1] http://people.apache.org/~matzew/core103/ -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ mail: matzew-at-apache-dot-org -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ mail: matzew-at-apache-dot-org
Re: [vote] release of Trinidad core (1.0.3)
And Danny Robinson also just checked in a fix for TRINIDAD-736... -- Adam On 9/26/07, Adam Winer [EMAIL PROTECTED] wrote: Oops... I just checked in a fix for TRINIDAD-742: RenderKit test framework doesn't load RenderKitFactories from faces-config.xml Any chance of re-spinning the release candidate? -- Adam On 9/26/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: +1 On 9/26/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: Hi, I was running the needed tasks to get the 1.0.3 release of the Apache MyFaces Trinidad CORE out. The artifacts are deployed to my private Apache account ([1]). Please take a look at the 1.0.3 artifacts and vote [ ] +1 for community members who have reviewed the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released, and why.. Thanks, Matthias [1] http://people.apache.org/~matzew/core103/ -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ mail: matzew-at-apache-dot-org -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ mail: matzew-at-apache-dot-org
Re: [vote] release of Trinidad plugins (1.2.3)
On 9/25/07, Andrew Robinson [EMAIL PROTECTED] wrote: I'm planning on help with the documentation, and plan to add a new page to the WIKI for a getting started on using the maven-faces-plugin with facelets and jsf 1.1. That'd be awesome! On the topic of what I brought up, would it be better to have the component type ID filter be placed on the dynamic content only and not on the included content (meaning the component tags from the plugin, but do not filter the faces-config-base.xml content)? That would be great, but... it'd require some fun rearchitecting. The filtering is done in XSLT, after the merge with the base doc has already happened. I agree that it's totally wacky that you explicitly define something explicitly in faces-config-base.xml and then the tool says nope, you must not have *really* wanted that! -- Adam Is there a good reason that I can't think of at the moment to filter all the faces-config content and not just the generated content? -Andrew On 9/24/07, Adam Winer [EMAIL PROTECTED] wrote: We should probably get serious about at least documenting the big gotchas of the faces plugin. I've started a subsection at http://wiki.apache.org/myfaces/Trinidad_Plugins so we at least have somewhere to put this sort of info. Andrew, stuff like this that you discover would be great additions. -- Adam On 9/24/07, Andrew Robinson [EMAIL PROTECTED] wrote: After investigating the code more, it is working as designed, I just expected different results. Please disregard this previous email of mine. Thanks, Andrew On 9/24/07, Andrew Robinson [EMAIL PROTECTED] wrote: Changing my vote to a possible -1 for the release. I just posted an email about the plugin not including elements from the faces-config-base.xml into the faces-config.xml. Unless I screwed up somehow, I'd like to see if this can be fixed before the release. -Andrew On 9/24/07, Adam Winer [EMAIL PROTECTED] wrote: On 9/23/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: [x] +1 for community members who have reviewed the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released, and why.. -- Adam
Re: [Trinidad] Branch for 1.0.3 core ?
I think Danny still has some things? -- Adam On 9/25/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: anyone else that has some changes to commit ? Otherwise I start the branch tomorrow morning (German time) -Matthias On 9/25/07, Adam Winer [EMAIL PROTECTED] wrote: OK, I've fixed 735, and checked in the patches for 674 and 676. -- Adam On 9/24/07, Adam Winer [EMAIL PROTECTED] wrote: We've also got patches available for TRINIDAD-718 and TRINIDAD-665 (actually looks like TRINIDAD-718 has already been checked in, but the JIRA wasn't closed). TRINIDAD-735 would be nice, but isn't critical. I'll check in the fixes for TRINIDAD-674 and TRINIDAD-676 ASAP - straightforward fixes from Tomas Havelka, a shame to let them go unused. Anyone else have something they really want fixed for 1.0.3? Going forward, I don't think we need to have a strict release the plugins, then release core rule - I think we can mostly get away with just releasing core, when it's ready. Which is good. :) -- Adam On 9/24/07, Simon Lessard [EMAIL PROTECTED] wrote: Ok, commit is done on my side. On 9/24/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: Sounds good to me, this email was just a heads-up ;-) On 9/24/07, Simon Lessard [EMAIL PROTECTED] wrote: I need to commit the patch for statusIndicator. I'll do that later today, we should not release until it's done. On 9/24/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: one more. from September 30th = October 15th (incl.) I am away from any computer ! :-) (vacation) So, the goal of this email was to prepare as much as possible to get the release out by end of this week ;-) Otherwise someone else needs to do the release procedure. -Matthias On 9/24/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: On 9/24/07, Danny Robinson [EMAIL PROTECTED] wrote: Did I miss the conversation leading up to this, or is this it? there was no thread regarding this. Usually after the release of the plugins, we start with the release procedure of the core. Since the vote on plugins is already ongoing, I was asking if we should wait more days or not. Looks like you've something for the 1.0.3, so we wait. That's fine. -M To Do * resolve the current xOffset/yOffset conversation and fix the plugins * Update AutoSubmitUtils to output ' TrPage._autoSubmit()' as the onchange handler Danny On 9/24/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: Hi, I'd like to branch today for the upcoming 1.0.3-core release of Trinidad. Does one need to commit something before ? thx, Matthias -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ mail: matzew-at-apache-dot-org -- Chordiant Software Inc. www.chordiant.com -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ mail: matzew-at-apache-dot-org -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ mail: matzew-at-apache-dot-org -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ mail: matzew-at-apache-dot-org -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ mail: matzew-at-apache-dot-org
Re: [Trinidad] Branch for 1.0.3 core ?
This looks like it fails if validation is set to alert mode; _autoSubmit
always calls _validateInput, which calls _validateInline.
Also, if immediate is true, the _autoSubmit param validateForm is true?
That seems weird...
I think I've seen this code:
+ if (_agent.isIE)
+ {
+// in many forms there is a hidden field named event
+// Sometimes IE gets confused and sends us that instead of
+// the true event, so...
+if (event[type] == hidden)
+ event = window.event;
+ }
+
... elsewhere. Never a good thing to cut-and-paste in JS.
-- Adam
On 9/25/07, Danny Robinson [EMAIL PROTECTED] wrote:
I'd like some quick eyes on the patch I've attached to TRINIDAD-37 which I'd
like to commit if there are no issues.
On 9/25/07, Adam Winer [EMAIL PROTECTED] wrote:
I think Danny still has some things?
-- Adam
On 9/25/07, Matthias Wessendorf [EMAIL PROTECTED] wrote:
anyone else that has some changes to commit ?
Otherwise I start the branch tomorrow morning (German time)
-Matthias
On 9/25/07, Adam Winer [EMAIL PROTECTED] wrote:
OK, I've fixed 735, and checked in the patches
for 674 and 676.
-- Adam
On 9/24/07, Adam Winer [EMAIL PROTECTED] wrote:
We've also got patches available for TRINIDAD-718 and
TRINIDAD-665 (actually looks like TRINIDAD-718 has
already been checked in, but the JIRA wasn't closed).
TRINIDAD-735 would be nice, but isn't critical.
I'll check in the fixes for TRINIDAD-674 and TRINIDAD-676
ASAP - straightforward fixes from Tomas Havelka, a shame
to let them go unused.
Anyone else have something they really want fixed for 1.0.3?
Going forward, I don't think we need to have a strict
release the plugins, then release core rule - I think we
can mostly get away with just releasing core, when it's
ready. Which is good. :)
-- Adam
On 9/24/07, Simon Lessard [EMAIL PROTECTED] wrote:
Ok, commit is done on my side.
On 9/24/07, Matthias Wessendorf [EMAIL PROTECTED] wrote:
Sounds good to me,
this email was just a heads-up ;-)
On 9/24/07, Simon Lessard [EMAIL PROTECTED] wrote:
I need to commit the patch for statusIndicator. I'll do that
later
today, we
should not release until it's done.
On 9/24/07, Matthias Wessendorf [EMAIL PROTECTED] wrote:
one more.
from September 30th = October 15th (incl.) I am away from
any
computer !
:-)
(vacation)
So, the goal of this email was to prepare as much as
possible to get
the release out
by end of this week ;-)
Otherwise someone else needs to do the release procedure.
-Matthias
On 9/24/07, Matthias Wessendorf [EMAIL PROTECTED] wrote:
On 9/24/07, Danny Robinson [EMAIL PROTECTED]
wrote:
Did I miss the conversation leading up to this, or is
this it?
there was no thread regarding this.
Usually after the release of the plugins, we start with
the release
procedure of the core.
Since the vote on plugins is already ongoing, I was asking
if we
should wait more days or not.
Looks like you've something for the 1.0.3, so we wait.
That's fine.
-M
To Do
* resolve the current xOffset/yOffset conversation and
fix the
plugins
* Update AutoSubmitUtils to output '
TrPage._autoSubmit()' as the
onchange
handler
Danny
On 9/24/07, Matthias Wessendorf [EMAIL PROTECTED]
wrote:
Hi,
I'd like to branch today for the upcoming 1.0.3-core
release of
Trinidad. Does one need to commit something before ?
thx,
Matthias
--
Matthias Wessendorf
further stuff:
blog:
http://matthiaswessendorf.wordpress.com/
mail: matzew-at-apache-dot-org
--
Chordiant Software Inc.
www.chordiant.com
--
Matthias Wessendorf
further stuff:
blog:
http://matthiaswessendorf.wordpress.com/
mail: matzew-at-apache-dot-org
--
Matthias Wessendorf
further stuff:
blog:
http://matthiaswessendorf.wordpress.com/
mail: matzew-at-apache-dot-org
--
Matthias Wessendorf
further stuff:
blog: http://matthiaswessendorf.wordpress.com/
mail: matzew-at-apache-dot-org
Re: [jira] Resolved: (TRINIDAD-731) xOffset/yOffset don't get correctly processed by plugins, switch to horzOffset/vertOffset for simplicity and clarity.
It's probably the case that the component and JSP tag methods need to be setxOffset instead of setXOffset() - or you need to supply a BeanInfo. But the best and simplest option, I think, is just to rename the properties to xoffset and yoffset, no caps - like halign and valign. -- Adam On 9/25/07, Danny Robinson [EMAIL PROTECTED] wrote: Both. If you grab the trunk and tweak the CorePanelPopup.xml attributes back to using xOffset/yOffset, then also tweak findTypeConstants() in the renderer, then... In JSP, you get /components/panelPopup.jspx(39,102) Unable to find setter method for attribute: yOffset In Facelets, you get java.lang.ClassCastException: java.lang.String at org.apache.myfaces.trinidad.render.CoreRenderer.toInt(CoreRenderer.java:127) at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.PanelPopupRenderer.getHorzOffset (PanelPopupRenderer.java:103) as the attribute gets read, but is held internally as a String I took a look around the generated artifacts, but nothing jumps out as wrong. D. On 9/24/07, Adam Winer [EMAIL PROTECTED] wrote: Remind me what the issue is? Is it JSP tags, Facelets, both, something else? -- Adam On 9/24/07, Danny Robinson [EMAIL PROTECTED] wrote: I know. When I made the name changes, I knew the plugins should really get fixed ;-). Any hints on where to look in the plugins would really help (unknown territory), then I can get the attribute names reverted. D. On 9/21/07, Adam Winer [EMAIL PROTECTED] wrote: Yech, why don't we just fix the plugins??? -- Adam On 9/21/07, Danny Robinson [EMAIL PROTECTED] wrote: Hard to say that they are breaking, because I'm not certain they ever worked ;-) I'll update the release notes to cover this though. D. On 9/21/07, Andrew Robinson [EMAIL PROTECTED] wrote: Is this a compatibility breaking change (meaning that the old attributes were removed)? If so, were are these items documented so that users know what happened? -Andrew On 9/21/07, Danny Robinson (JIRA) dev@myfaces.apache.org wrote: [ https://issues.apache.org/jira/browse/TRINIDAD-731?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Danny Robinson resolved TRINIDAD-731. - Resolution: Fixed Fix Version/s: 1.0.3-core Switched attribute names to horzOffset and vertOffset. xOffset/yOffset don't get correctly processed by plugins, switch to horzOffset/vertOffset for simplicity and clarity. - Key: TRINIDAD-731 URL: https://issues.apache.org/jira/browse/TRINIDAD-731 Project: MyFaces Trinidad Issue Type: Improvement Components: Components Affects Versions: 1.0.3-core Reporter: Danny Robinson Assignee: Danny Robinson Priority: Minor Fix For: 1.0.3-core -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. -- Chordiant Software Inc. www.chordiant.com -- Chordiant Software Inc. www.chordiant.com -- Chordiant Software Inc. www.chordiant.com
Re: [Trinidad] Branch for 1.0.3 core ?
On 9/25/07, Danny Robinson [EMAIL PROTECTED] wrote:
This looks like it fails if validation is set to alert mode; _autoSubmit
always calls _validateInput, which calls _validateInline.
Thanks, fixed.
Also, if immediate is true, the _autoSubmit param validateForm is true?
That seems weird...
BodyRenderer actually uses the snippet below, so whole-form validation
shouldn't happen if immediate is true.
builder.append(immediate ? 0 : 1);
I think I've seen this code:
+ if (_agent.isIE)
+ {
+// in many forms there is a hidden field named event
+// Sometimes IE gets confused and sends us that instead of
+// the true event, so...
+if (event[type] == hidden)
+ event = window.event;
+ }
+
... elsewhere. Never a good thing to cut-and-paste in JS.
Do you mean abstract both copies into a common method, or are you
questioning the actual code.
Both should go into a common method, I think. Maybe
we could start to use some polymorphism on the agent object,
so you could just call event = _agent.getEvent(event)?
-- Adam
If that's the case, I spent a few hours one
evening trying to understand why I wasn't getting the 'real' event object in
IE.
-- Adam
On 9/25/07, Danny Robinson [EMAIL PROTECTED] wrote:
I'd like some quick eyes on the patch I've attached to TRINIDAD-37 which
I'd
like to commit if there are no issues.
On 9/25/07, Adam Winer [EMAIL PROTECTED] wrote:
I think Danny still has some things?
-- Adam
On 9/25/07, Matthias Wessendorf [EMAIL PROTECTED] wrote:
anyone else that has some changes to commit ?
Otherwise I start the branch tomorrow morning (German time)
-Matthias
On 9/25/07, Adam Winer [EMAIL PROTECTED] wrote:
OK, I've fixed 735, and checked in the patches
for 674 and 676.
-- Adam
On 9/24/07, Adam Winer [EMAIL PROTECTED] wrote:
We've also got patches available for TRINIDAD-718 and
TRINIDAD-665 (actually looks like TRINIDAD-718 has
already been checked in, but the JIRA wasn't closed).
TRINIDAD-735 would be nice, but isn't critical.
I'll check in the fixes for TRINIDAD-674 and TRINIDAD-676
ASAP - straightforward fixes from Tomas Havelka, a shame
to let them go unused.
Anyone else have something they really want fixed for 1.0.3?
Going forward, I don't think we need to have a strict
release the plugins, then release core rule - I think we
can mostly get away with just releasing core, when it's
ready. Which is good. :)
-- Adam
On 9/24/07, Simon Lessard [EMAIL PROTECTED] wrote:
Ok, commit is done on my side.
On 9/24/07, Matthias Wessendorf [EMAIL PROTECTED] wrote:
Sounds good to me,
this email was just a heads-up ;-)
On 9/24/07, Simon Lessard [EMAIL PROTECTED]
wrote:
I need to commit the patch for statusIndicator. I'll do
that
later
today, we
should not release until it's done.
On 9/24/07, Matthias Wessendorf [EMAIL PROTECTED]
wrote:
one more.
from September 30th = October 15th (incl.) I am away
from
any
computer !
:-)
(vacation)
So, the goal of this email was to prepare as much as
possible to get
the release out
by end of this week ;-)
Otherwise someone else needs to do the release
procedure.
-Matthias
On 9/24/07, Matthias Wessendorf [EMAIL PROTECTED]
wrote:
On 9/24/07, Danny Robinson [EMAIL PROTECTED]
wrote:
Did I miss the conversation leading up to this, or
is
this it?
there was no thread regarding this.
Usually after the release of the plugins, we start
with
the release
procedure of the core.
Since the vote on plugins is already ongoing, I was
asking
if we
should wait more days or not.
Looks like you've something for the 1.0.3, so we wait.
That's fine.
-M
To Do
* resolve the current xOffset/yOffset conversation
and
fix the
plugins
* Update AutoSubmitUtils to output '
TrPage._autoSubmit()' as the
onchange
handler
Danny
On 9/24/07, Matthias Wessendorf [EMAIL PROTECTED]
wrote:
Hi,
I'd like to branch today for the upcoming
1.0.3-core
release of
Trinidad. Does one need to commit something before
?
thx,
Matthias
Re: [Trinidad] Branch for 1.0.3 core ?
Sure, no prob. :) -- Adam On 9/25/07, Danny Robinson [EMAIL PROTECTED] wrote: Both should go into a common method, I think. Maybe we could start to use some polymorphism on the agent object, so you could just call event = _agent.getEvent(event)? That would be no bad thing, there's also addEventHandler/removeEventHandler stuff we could also add there. Given the timing, I'm going to put a comment in the code and create an issue for this down stream. Danny
Re: [vote] release of Trinidad plugins (1.2.3)
On 9/23/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: [x] +1 for community members who have reviewed the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released, and why.. -- Adam
[jira] Commented: (TRINIDAD-695) tr:form skips c/s validation on submit by 'defaultCommand'
[ https://issues.apache.org/jira/browse/TRINIDAD-695?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12529893 ] Adam Winer commented on TRINIDAD-695: - Easy to turn on client-side validation: in Core.js, _submitOnEnter, change submitForm(frm,0,params); to submitForm(frm,1,params); But we can only change that 0 to 1 if the button isn't immediate, which is not easy. tr:form skips c/s validation on submit by 'defaultCommand' -- Key: TRINIDAD-695 URL: https://issues.apache.org/jira/browse/TRINIDAD-695 Project: MyFaces Trinidad Issue Type: Bug Affects Versions: 1.0.2-core Reporter: Vadim Dmitriev tr:form skips client-side validation when submitted by defaultCommand. For example: tr:form defaultCommand=submitter tr:inputText value= required=true / tr:commandButton id=submitter / /tr:form will produce c/s validation errors when tr:commandButton clicked, but will submit form to server if 'enter' is pressed while in tr:inputText. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [Trinidad] Branch for 1.0.3 core ?
We've also got patches available for TRINIDAD-718 and TRINIDAD-665 (actually looks like TRINIDAD-718 has already been checked in, but the JIRA wasn't closed). TRINIDAD-735 would be nice, but isn't critical. I'll check in the fixes for TRINIDAD-674 and TRINIDAD-676 ASAP - straightforward fixes from Tomas Havelka, a shame to let them go unused. Anyone else have something they really want fixed for 1.0.3? Going forward, I don't think we need to have a strict release the plugins, then release core rule - I think we can mostly get away with just releasing core, when it's ready. Which is good. :) -- Adam On 9/24/07, Simon Lessard [EMAIL PROTECTED] wrote: Ok, commit is done on my side. On 9/24/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: Sounds good to me, this email was just a heads-up ;-) On 9/24/07, Simon Lessard [EMAIL PROTECTED] wrote: I need to commit the patch for statusIndicator. I'll do that later today, we should not release until it's done. On 9/24/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: one more. from September 30th = October 15th (incl.) I am away from any computer ! :-) (vacation) So, the goal of this email was to prepare as much as possible to get the release out by end of this week ;-) Otherwise someone else needs to do the release procedure. -Matthias On 9/24/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: On 9/24/07, Danny Robinson [EMAIL PROTECTED] wrote: Did I miss the conversation leading up to this, or is this it? there was no thread regarding this. Usually after the release of the plugins, we start with the release procedure of the core. Since the vote on plugins is already ongoing, I was asking if we should wait more days or not. Looks like you've something for the 1.0.3, so we wait. That's fine. -M To Do * resolve the current xOffset/yOffset conversation and fix the plugins * Update AutoSubmitUtils to output ' TrPage._autoSubmit()' as the onchange handler Danny On 9/24/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: Hi, I'd like to branch today for the upcoming 1.0.3-core release of Trinidad. Does one need to commit something before ? thx, Matthias -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ mail: matzew-at-apache-dot-org -- Chordiant Software Inc. www.chordiant.com -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ mail: matzew-at-apache-dot-org -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ mail: matzew-at-apache-dot-org -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ mail: matzew-at-apache-dot-org
[jira] Resolved: (TRINIDAD-676) Component selectRangeChoiceBar not properly rendered (2nd issue)
[ https://issues.apache.org/jira/browse/TRINIDAD-676?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Winer resolved TRINIDAD-676. - Resolution: Fixed Fix Version/s: 1.0.3-core Assignee: Adam Winer Checked in patch, thanks! Component selectRangeChoiceBar not properly rendered (2nd issue) Key: TRINIDAD-676 URL: https://issues.apache.org/jira/browse/TRINIDAD-676 Project: MyFaces Trinidad Issue Type: Bug Affects Versions: 1.0.1-core, 1.0.2-core Reporter: Tomas Havelka Assignee: Adam Winer Fix For: 1.0.3-core Another issue with selectRangeChoiceBar and not known model row count. As I see, SelectRangeChoiceBarRenderer rendering routine is one-indexed, but model is zero-based. Then when searching for next value by asking model's isRowAvailable method, value has to be decreased. Solution: Modify encodeAll method on line 374 of SelectRangeChoiceBarRenderer like this. hasNextRecords = isRowAvailable(component, (int)nextValue - 1); -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (TRINIDAD-674) Component selectRangeChoiceBar not properly rendered
[
https://issues.apache.org/jira/browse/TRINIDAD-674?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adam Winer resolved TRINIDAD-674.
-
Resolution: Fixed
Fix Version/s: 1.0.3-core
Assignee: Adam Winer
Checked in patch, thanks!
Component selectRangeChoiceBar not properly rendered
Key: TRINIDAD-674
URL: https://issues.apache.org/jira/browse/TRINIDAD-674
Project: MyFaces Trinidad
Issue Type: Bug
Affects Versions: 1.0.1-core, 1.0.2-core
Reporter: Tomas Havelka
Assignee: Adam Winer
Fix For: 1.0.3-core
When component selectRangeChoiceBar is rendered for the last page and model
row count is not known (-1), the link for the navigation to next page should
be rendered as disabled (now it's rendered as enabled even if no onclick
event is attached).
Solution:
Modify _renderLink method of SelectRangeChoiceBarRenderer similarly to
_renderArrow method. For example like this.
String text = getBlockString(arc, isNext, records);
boolean isEnabled = ((records 0) (onclick != null)); // here is the
place to check whether link is to be rendered as disabled
ResponseWriter writer = context.getResponseWriter();
if (isEnabled)
{
writer.startElement(a, null);
writer.writeURIAttribute(href, #, null);
writer.writeAttribute(onclick, onclick, null);
// The navBar needs its initial focus to be on the Next button,
// according to the BLAF. Render a special id on the Next button
// if this navBar is to have the initial focus. (unless it needs
// initial focus, the Next button does not have an id on it)
if (isNext)
{
String linkID = _getIDForFocus(arc, id);
writer.writeAttribute(id, linkID, null);
}
renderStyleClass(context, arc, SkinSelectors.NAV_BAR_ALINK_STYLE_CLASS);
}
else
{
writer.startElement(span, null);
renderStyleClass(context, arc, SkinSelectors.NAV_BAR_ILINK_STYLE_CLASS);
}
writer.writeText(text, null);
if (isEnabled)
{
writer.endElement(a);
}
else
{
writer.endElement(span);
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (TRINIDAD-642) UIXTable.createCollectionModel throws null pointer exception if selectedRowKeys evaluates to null
[ https://issues.apache.org/jira/browse/TRINIDAD-642?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Winer updated TRINIDAD-642: Status: Patch Available (was: Open) UIXTable.createCollectionModel throws null pointer exception if selectedRowKeys evaluates to null - Key: TRINIDAD-642 URL: https://issues.apache.org/jira/browse/TRINIDAD-642 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 1.2.1-core Reporter: Max Starets Attachments: jira-642.patch UIXTable.createCollectionModel() expects that selectedRowKeys and disclosedRowKeys are always non-null. To avoid null-pointer exceptions, we need two fixes: 1) Call _init() in UIXCollection.invokeOnComponent() to ensure that these properties are initialized; 2) If the properties are still null in createColelctionModel() (presumably because the values were EL-bound and got evaluated to null, but the _init() did not proceed because UIXColelction has already been initialized), we need to manually allocate RowKeySetImpl object and set the properties -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TRINIDAD-734) EL expression used for node labels gets evaluated only once
[ https://issues.apache.org/jira/browse/TRINIDAD-734?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Winer updated TRINIDAD-734: Status: Patch Available (was: Open) EL expression used for node labels gets evaluated only once --- Key: TRINIDAD-734 URL: https://issues.apache.org/jira/browse/TRINIDAD-734 Project: MyFaces Trinidad Issue Type: Bug Reporter: Gary Kind Attachments: 122Branch.patch, trunk.patch The first time the actionListener calls the getLabel() method for a menu node, if the stored label is an EL expression, it gets evaluated correctly and the returned String is set on the label. However, before this fix, the evaluated String was set as the label for the menu item node. This means that the next time the getLabel() method is called, the EL expression is not again evaluated as it should. The String from the first time it was evaluated is returned instead. This is incorrect as it prevents an EL expression from changing the label dynamically. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TRINIDAD-734) EL expression used for node labels gets evaluated only once
[ https://issues.apache.org/jira/browse/TRINIDAD-734?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Winer updated TRINIDAD-734: Resolution: Fixed Fix Version/s: 1.0.3-core Assignee: Jeanne Waldman Status: Resolved (was: Patch Available) Fix checked in by Jeanne. EL expression used for node labels gets evaluated only once --- Key: TRINIDAD-734 URL: https://issues.apache.org/jira/browse/TRINIDAD-734 Project: MyFaces Trinidad Issue Type: Bug Reporter: Gary Kind Assignee: Jeanne Waldman Fix For: 1.0.3-core Attachments: 122Branch.patch, trunk.patch The first time the actionListener calls the getLabel() method for a menu node, if the stored label is an EL expression, it gets evaluated correctly and the returned String is set on the label. However, before this fix, the evaluated String was set as the label for the menu item node. This means that the next time the getLabel() method is called, the EL expression is not again evaluated as it should. The String from the first time it was evaluated is returned instead. This is incorrect as it prevents an EL expression from changing the label dynamically. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [jira] Resolved: (TRINIDAD-731) xOffset/yOffset don't get correctly processed by plugins, switch to horzOffset/vertOffset for simplicity and clarity.
Remind me what the issue is? Is it JSP tags, Facelets, both, something else? -- Adam On 9/24/07, Danny Robinson [EMAIL PROTECTED] wrote: I know. When I made the name changes, I knew the plugins should really get fixed ;-). Any hints on where to look in the plugins would really help (unknown territory), then I can get the attribute names reverted. D. On 9/21/07, Adam Winer [EMAIL PROTECTED] wrote: Yech, why don't we just fix the plugins??? -- Adam On 9/21/07, Danny Robinson [EMAIL PROTECTED] wrote: Hard to say that they are breaking, because I'm not certain they ever worked ;-) I'll update the release notes to cover this though. D. On 9/21/07, Andrew Robinson [EMAIL PROTECTED] wrote: Is this a compatibility breaking change (meaning that the old attributes were removed)? If so, were are these items documented so that users know what happened? -Andrew On 9/21/07, Danny Robinson (JIRA) dev@myfaces.apache.org wrote: [ https://issues.apache.org/jira/browse/TRINIDAD-731?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Danny Robinson resolved TRINIDAD-731. - Resolution: Fixed Fix Version/s: 1.0.3-core Switched attribute names to horzOffset and vertOffset. xOffset/yOffset don't get correctly processed by plugins, switch to horzOffset/vertOffset for simplicity and clarity. - Key: TRINIDAD-731 URL: https://issues.apache.org/jira/browse/TRINIDAD-731 Project: MyFaces Trinidad Issue Type: Improvement Components: Components Affects Versions: 1.0.3-core Reporter: Danny Robinson Assignee: Danny Robinson Priority: Minor Fix For: 1.0.3-core -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. -- Chordiant Software Inc. www.chordiant.com -- Chordiant Software Inc. www.chordiant.com
[jira] Resolved: (TRINIDAD-735) '_checkLoad is not defined' error opening lightweight dialog in FireFox
[ https://issues.apache.org/jira/browse/TRINIDAD-735?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Winer resolved TRINIDAD-735. - Resolution: Fixed Fix Version/s: 1.0.3-core Fixed. '_checkLoad is not defined' error opening lightweight dialog in FireFox --- Key: TRINIDAD-735 URL: https://issues.apache.org/jira/browse/TRINIDAD-735 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 1.0.3-core Reporter: Danny Robinson Assignee: Adam Winer Priority: Minor Fix For: 1.0.3-core The FF console reports '_checkLoad is not defined' when a lightweight dialog is opened. Nothing fails, but why this error is reported is very strange. It is somehow related to TrPopupDailog._initDialogPage(), which preceeds the _checkLoad() call in the body onload handler, but in the two out of three times is is called during a dialog open, _checkLoad seems to work fine. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TRINIDAD-737) Need To Establish Currency for Table Events
[ https://issues.apache.org/jira/browse/TRINIDAD-737?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Winer updated TRINIDAD-737: Resolution: Fixed Fix Version/s: 1.0.3-core Status: Resolved (was: Patch Available) Checked in the patch - thanks! Need To Establish Currency for Table Events --- Key: TRINIDAD-737 URL: https://issues.apache.org/jira/browse/TRINIDAD-737 Project: MyFaces Trinidad Issue Type: Improvement Affects Versions: 1.2.2-core Reporter: Max Starets Fix For: 1.0.3-core Attachments: TRINIDAD-737.diff We should establish currency for listeners to events filed by table, tree and treeTable and by components contained within their facets. Note that this does not include events fired by specific rows (these are establishing currency already). The currency should be set to the first entry in the selected row key set. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [Trinidad] Branch for 1.0.3 core ?
OK, I've fixed 735, and checked in the patches for 674 and 676. -- Adam On 9/24/07, Adam Winer [EMAIL PROTECTED] wrote: We've also got patches available for TRINIDAD-718 and TRINIDAD-665 (actually looks like TRINIDAD-718 has already been checked in, but the JIRA wasn't closed). TRINIDAD-735 would be nice, but isn't critical. I'll check in the fixes for TRINIDAD-674 and TRINIDAD-676 ASAP - straightforward fixes from Tomas Havelka, a shame to let them go unused. Anyone else have something they really want fixed for 1.0.3? Going forward, I don't think we need to have a strict release the plugins, then release core rule - I think we can mostly get away with just releasing core, when it's ready. Which is good. :) -- Adam On 9/24/07, Simon Lessard [EMAIL PROTECTED] wrote: Ok, commit is done on my side. On 9/24/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: Sounds good to me, this email was just a heads-up ;-) On 9/24/07, Simon Lessard [EMAIL PROTECTED] wrote: I need to commit the patch for statusIndicator. I'll do that later today, we should not release until it's done. On 9/24/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: one more. from September 30th = October 15th (incl.) I am away from any computer ! :-) (vacation) So, the goal of this email was to prepare as much as possible to get the release out by end of this week ;-) Otherwise someone else needs to do the release procedure. -Matthias On 9/24/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: On 9/24/07, Danny Robinson [EMAIL PROTECTED] wrote: Did I miss the conversation leading up to this, or is this it? there was no thread regarding this. Usually after the release of the plugins, we start with the release procedure of the core. Since the vote on plugins is already ongoing, I was asking if we should wait more days or not. Looks like you've something for the 1.0.3, so we wait. That's fine. -M To Do * resolve the current xOffset/yOffset conversation and fix the plugins * Update AutoSubmitUtils to output ' TrPage._autoSubmit()' as the onchange handler Danny On 9/24/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: Hi, I'd like to branch today for the upcoming 1.0.3-core release of Trinidad. Does one need to commit something before ? thx, Matthias -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ mail: matzew-at-apache-dot-org -- Chordiant Software Inc. www.chordiant.com -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ mail: matzew-at-apache-dot-org -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ mail: matzew-at-apache-dot-org -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ mail: matzew-at-apache-dot-org
Re: [TRINIDAD] New element in trinidad-skins.xml /SkinImpl/SkinAddition
1. Evaluate the base ValueExpression (without looking at the string or anything like that). Call this object base. Call the property propertyName. 2. Get the ELResolver from Application and the ELContext from FacesContext 3. Call elResolver.getValue(elContext, base, propertyName); You don't need to get types, or do instanceof, or anything like that! -- Adam On 9/24/07, Jeanne Waldman [EMAIL PROTECTED] wrote: I need help understanding how you are expecting I use the MapELResolver/ResourceBundleELResolver, Adam. First, let me explain what I was doing. I was creating a ValueExpression when I parsed the trinidad-skins.xml and found a value in translation-source. // could be Map or ResourceBundle, so make the type Object return LazyValueExpression.createValueExpression(translationSourceExpression, Object.class); I store this ValueExpression on the skin. Then when getTranslatedValue is called, I would look up the key in the resource cache that I lazily build. A skin can have a bundle-name or it can have a translation-source, then if the translation isn't found, it looks in all the skin additions bundle-name or translation source, and then if it still isn't found it does the same thing for the base skin, on up the chain until it finds it. As I look into a map or resource bundle, I cache the entire map/resource bundle, to make subsequent lookups faster. To get the value from the translation source, I was planning to use the ValueExpression's getValue and then figure out if it is a ResourceBundle instance or a Map instance and proceed from there by caching the Map/ResourceBundle keys/values in mylocale cache, then getting the key's value, etc. --- I don't what you mean when you say I should use a ELResolver. I'm a novice with the ValueExpression, ELResolver code. I'm guessing from reading the javadoc that you mean create an ELContext that has a MapELResolver and another one for ResourceBundleELResolver. Then I figure out what type the ValueExpression is, and then I use that ELContext, and I take the 'key' in getTranslatedValue, and append that to the ValueExpression somehow (or store the expression on the Skin as a String instead of a VE and use that as the 'base') and get the value. I suppose I can cache each key/value as I find it instead of caching the entire contents like I do for the bundle-name code. But I'd rather be consistent. Can you explain to me what you meant and iif/how that is better than the way I was planning to do it? Thanks! Jeanne Simon Lessard wrote: EL implies a small performance overhead but I guess it's acceptable for the gain here. On 9/21/07, Adam Winer [EMAIL PROTECTED] wrote: -1 to trying to turn everything into ResourceBundle. Just use EL - ELResolver in 1.2, PropertyResolver in 1.1. As of 1.2, that gives you ResourceBundle and Map support. In 1.1, only Map (and bean, of course), but then again in 1.1 how do you get unwrapped ResourceBundle instances into EL anyway? @Gary: the Shale LoadBundle class seems quite unnecessary in 1.2, right? -- Adam On 9/21/07, Gary VanMatre [EMAIL PROTECTED] wrote: From: Simon Lessard [EMAIL PROTECTED] If we accept only a map, it's quite exclusive, unless we add yet another tag, but I would be -1 on that. However, as Adam suggested, we could call it translation-source and support both Map and ResourceBundle instances. We have to a very thin adapter Map -- ResourceBundle if a Map instance is passed and the remaining code will continue to work as it's now, with a ResourceBundle. FWIW, Shale has a utility class that sounds very similar to what you have described [1]. [1] http://svn.apache.org/viewvc/shale/framework/trunk/shale-core/src/main/java/org/apache/shale/util/LoadBundle.java?view=markup ~ Simon Gary
Re: [vote] release of Trinidad plugins (1.2.3)
We should probably get serious about at least documenting the big gotchas of the faces plugin. I've started a subsection at http://wiki.apache.org/myfaces/Trinidad_Plugins so we at least have somewhere to put this sort of info. Andrew, stuff like this that you discover would be great additions. -- Adam On 9/24/07, Andrew Robinson [EMAIL PROTECTED] wrote: After investigating the code more, it is working as designed, I just expected different results. Please disregard this previous email of mine. Thanks, Andrew On 9/24/07, Andrew Robinson [EMAIL PROTECTED] wrote: Changing my vote to a possible -1 for the release. I just posted an email about the plugin not including elements from the faces-config-base.xml into the faces-config.xml. Unless I screwed up somehow, I'd like to see if this can be fixed before the release. -Andrew On 9/24/07, Adam Winer [EMAIL PROTECTED] wrote: On 9/23/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: [x] +1 for community members who have reviewed the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released, and why.. -- Adam
Re: TRINIDAD-729
I agree - in this case, you really want to add a delay with a JS window timeout that keeps getting rescheduled (e.g., on every tick of the counter, window.clearTimeout() if the timeout exists, then call window.setTimeout()). -- Adam On 9/21/07, Andrew Robinson [EMAIL PROTECTED] wrote: Is this a good idea? If the user wants to increase the counter 5 times, you would not want 5 ajax calls for every time they click the up arrow. -Andrew On 9/21/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: Hi guys, I added a patch (and a comment) to TRINIDAD-729 (see [1]). I am not sure if there is an issue with this fix/patch. Do you mind to review it ? Thanks! Matthias [1] https://issues.apache.org/jira/browse/TRINIDAD-729 -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ mail: matzew-at-apache-dot-org
Re: TRINIDAD-729
At the moment, this doesn't come up that commonly in the Trinidad components. But it could, if: - We had an autosuggest component - We supported autosubmit on any keypress in an input component, not just on tab-out There's a separate queueing question that also comes up, which is that currently, if you have nothing but autoSubmit fields, and you change A, then B, then C, but we're still processing A, you'd really like to join B+C in one submit, instead of separating them into two. For that, we really need an event queue (in addition to our request queue.) In theory, we could design the event queue to address both problems (delivering two different events together, collapsing duplicate events.) -- Adam On 9/21/07, Andrew Robinson [EMAIL PROTECTED] wrote: Yes, thought crossed my mind as well for something like that. Perhaps a common type of JS queue could be made for this, as I would not be surprised if this functionality is revisited elsewhere. Something like a non-duplicate PPR list, when a new event is added, the previous is removed and each event has a timeout associated with it (fire after x millis). On 9/21/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: true, perhaps we can include TRINIDAD-730 as well. Like, after 1000 ms start with the loop of increase / decrease and inside the loop, every 100 ms, do an update. Once the loop get's its time-out, fire the change event, for the spinbox. does that make sense ? -M On 9/21/07, Andrew Robinson [EMAIL PROTECTED] wrote: Is this a good idea? If the user wants to increase the counter 5 times, you would not want 5 ajax calls for every time they click the up arrow. -Andrew On 9/21/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: Hi guys, I added a patch (and a comment) to TRINIDAD-729 (see [1]). I am not sure if there is an issue with this fix/patch. Do you mind to review it ? Thanks! Matthias [1] https://issues.apache.org/jira/browse/TRINIDAD-729 -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ mail: matzew-at-apache-dot-org -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ mail: matzew-at-apache-dot-org
Re: [TRINIDAD] New element in trinidad-skins.xml /SkinImpl/SkinAddition
On 9/21/07, Simon Lessard [EMAIL PROTECTED] wrote:
Hello Jeanne,
I could live with that as long as the XSD should prevents the usage of both
a bundle and a map at the same time. However, I would prefer a
resource-bundle element than a translation-map. For one, it's much
easier to create a ResourceBundle from a Map than the other way around.
It's easy enough to do either, but its not really a ResourceBundle instance
unless you can get it via ResourceBundle.getBundle().
IMO, the real point here is just saying let's get it from EL, instead of
loading a ResourceBundle ourselves, so it can be anything, ResourceBundle,
Map, we don't care. So name the element translation-source perhaps?
-- Adam
Also, that would be more aligned with JSF 1.2 since its include a way to
define resource-bundle with a var name within the faces-config.xml.
~ Simon
On 9/21/07, Jeanne Waldman [EMAIL PROTECTED] wrote:
Hi,
I have a new issue I need to resolve and I wanted to run by my solution --
https://issues.apache.org/jira/browse/TRINIDAD-728
support for el to be used in a skin to bind to other translation data
sources
Currently, a SkinExtension and SkinAddition can have resource bundles
associated with them so that a person can skin text.
We have customers who want to use a Map that is EL-accessible instead of a
ResourceBundle.
I'd like to add a 'translation-map' element to the skin and
skin-addition elements in trinidad-skins.xml.
I'd add new constructors to SkinExtension and SkinAddition to accept a
translationMap ValueExpression.
Let me know what you think and if you think 'translation-map' is a good
name for the new element.
See below for an example.
Thanks,
Jeanne
from trinidad-skins.xml:
skin
id
purple.desktop
/id
family
purple
/family
render-kit-id
org.apache.myfaces.trinidad.desktop
/render-kit-id
style-sheet-name
skins/purple/purpleSkin.css
/style-sheet-name
bundle-name
org.apache.myfaces.trinidaddemo.resource.SkinBundle
/bundle-name
/skin
!-- You can extend any skin you want. Here we want the purple
skin, but with a bigger font size --
skin
id
purpleBigFont.desktop
/id
family
purpleBigFont
/family
extends
purple.desktop
/extends
render-kit-id
org.apache.myfaces.trinidad.desktop
/render-kit-id
style-sheet-name
skins/purple/purpleBigFontSkin.css
/style-sheet-name
translation-map#{skinTranslationMap.contents}/translation-map
/skin
Re: [TRINIDAD] New element in trinidad-skins.xml /SkinImpl/SkinAddition
On 9/21/07, Jeanne Waldman [EMAIL PROTECTED] wrote:
Adam Winer wrote:
On 9/21/07, Simon Lessard [EMAIL PROTECTED] wrote:
Hello Jeanne,
I could live with that as long as the XSD should prevents the usage of both
a bundle and a map at the same time. However, I would prefer a
resource-bundle element than a translation-map. For one, it's much
easier to create a ResourceBundle from a Map than the other way around.
It's easy enough to do either, but its not really a ResourceBundle instance
unless you can get it via ResourceBundle.getBundle().
IMO, the real point here is just saying let's get it from EL, instead of
loading a ResourceBundle ourselves, so it can be anything, ResourceBundle,
Map, we don't care. So name the element translation-source perhaps?
Are you saying my ValueExpression should be an Object type instead of a Map
type, and then for now I can
accept Maps, but then as another enhancement I could accept
ResourceBundles?
It seems that it can't be anything, because I need to know what I am
getting.
No, you actually can get anything. Just use ELResolver.getValue()
to resolve the property. That way, you have support for both
ResourceBundles and Maps with one element.
-- Adam
-- Adam
Also, that would be more aligned with JSF 1.2 since its include a way to
define resource-bundle with a var name within the faces-config.xml.
~ Simon
On 9/21/07, Jeanne Waldman [EMAIL PROTECTED] wrote:
Hi,
I have a new issue I need to resolve and I wanted to run by my solution --
https://issues.apache.org/jira/browse/TRINIDAD-728
support for el to be used in a skin to bind to other translation data
sources
Currently, a SkinExtension and SkinAddition can have resource bundles
associated with them so that a person can skin text.
We have customers who want to use a Map that is EL-accessible instead of a
ResourceBundle.
I'd like to add a 'translation-map' element to the skin and
skin-addition elements in trinidad-skins.xml.
I'd add new constructors to SkinExtension and SkinAddition to accept a
translationMap ValueExpression.
Let me know what you think and if you think 'translation-map' is a good
name for the new element.
See below for an example.
Thanks,
Jeanne
from trinidad-skins.xml:
skin
id
purple.desktop
/id
family
purple
/family
render-kit-id
org.apache.myfaces.trinidad.desktop
/render-kit-id
style-sheet-name
skins/purple/purpleSkin.css
/style-sheet-name
bundle-name
org.apache.myfaces.trinidaddemo.resource.SkinBundle
/bundle-name
/skin
!-- You can extend any skin you want. Here we want the purple
skin, but with a bigger font size --
skin
id
purpleBigFont.desktop
/id
family
purpleBigFont
/family
extends
purple.desktop
/extends
render-kit-id
org.apache.myfaces.trinidad.desktop
/render-kit-id
style-sheet-name
skins/purple/purpleBigFontSkin.css
/style-sheet-name
translation-map#{skinTranslationMap.contents}/translation-map
/skin
Re: [TRINIDAD] New element in trinidad-skins.xml /SkinImpl/SkinAddition
-1 to trying to turn everything into ResourceBundle. Just use EL - ELResolver in 1.2, PropertyResolver in 1.1. As of 1.2, that gives you ResourceBundle and Map support. In 1.1, only Map (and bean, of course), but then again in 1.1 how do you get unwrapped ResourceBundle instances into EL anyway? @Gary: the Shale LoadBundle class seems quite unnecessary in 1.2, right? -- Adam On 9/21/07, Gary VanMatre [EMAIL PROTECTED] wrote: From: Simon Lessard [EMAIL PROTECTED] If we accept only a map, it's quite exclusive, unless we add yet another tag, but I would be -1 on that. However, as Adam suggested, we could call it translation-source and support both Map and ResourceBundle instances. We have to a very thin adapter Map -- ResourceBundle if a Map instance is passed and the remaining code will continue to work as it's now, with a ResourceBundle. FWIW, Shale has a utility class that sounds very similar to what you have described [1]. [1] http://svn.apache.org/viewvc/shale/framework/trunk/shale-core/src/main/java/org/apache/shale/util/LoadBundle.java?view=markup ~ Simon Gary
Re: [jira] Resolved: (TRINIDAD-731) xOffset/yOffset don't get correctly processed by plugins, switch to horzOffset/vertOffset for simplicity and clarity.
Yech, why don't we just fix the plugins??? -- Adam On 9/21/07, Danny Robinson [EMAIL PROTECTED] wrote: Hard to say that they are breaking, because I'm not certain they ever worked ;-) I'll update the release notes to cover this though. D. On 9/21/07, Andrew Robinson [EMAIL PROTECTED] wrote: Is this a compatibility breaking change (meaning that the old attributes were removed)? If so, were are these items documented so that users know what happened? -Andrew On 9/21/07, Danny Robinson (JIRA) dev@myfaces.apache.org wrote: [ https://issues.apache.org/jira/browse/TRINIDAD-731?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Danny Robinson resolved TRINIDAD-731. - Resolution: Fixed Fix Version/s: 1.0.3-core Switched attribute names to horzOffset and vertOffset. xOffset/yOffset don't get correctly processed by plugins, switch to horzOffset/vertOffset for simplicity and clarity. - Key: TRINIDAD-731 URL: https://issues.apache.org/jira/browse/TRINIDAD-731 Project: MyFaces Trinidad Issue Type: Improvement Components: Components Affects Versions: 1.0.3-core Reporter: Danny Robinson Assignee: Danny Robinson Priority: Minor Fix For: 1.0.3-core -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. -- Chordiant Software Inc. www.chordiant.com
Re: [Trinidad] - [IE] funny issue with form and defaultCommand
OK, so looks like the issue is that for this submit,
we have:
var params = new Object();
params[src] = src;
params['source'] = src;
submitForm(frm,0,params);
We set params['source'] = src; to handle Trinidad buttons.
We set params[src] = src; to handle non-Trinidad buttons.
Then submitForm() has (with a lot of non-taken branches
snipped):
var hiddenField = form.elements[paramName];
if (hiddenField.type == 'submit')
// create an input type=hidden
else
hiddenField.value = paramValue;
I think we need to add a checkt to submitForm() that hiddenField is
not a button element too!
(BTW, Matthias: glancing at Core.js, I noticed
we've got double copies of all the spinbox code!)
-- Adam
On 9/19/07, Matthias Wessendorf [EMAIL PROTECTED] wrote:
reason is this
script
function changeValue(element)
{
element.value = element.id;
}
/script
button id=foo onclick=changeValue(this);bar/button
in FF, never the button-text is changed.
-M
On 9/20/07, Matthias Wessendorf [EMAIL PROTECTED] wrote:
changed subject to better reflect the issue.
-M
On 9/20/07, Matthias Wessendorf [EMAIL PROTECTED] wrote:
Hi,
by accident I noticed this funny thing with form's defaultCommand and
IE7 (true for IE 6 as well ??)
here is a demo, that has a form, containing a defaultCommand
http://www.irian.at/trinidad-demo/faces/components/form.jspx
Do the following:
-enter first value
-enter second value AND! hit enter.
= Notice that the button label changes to the ID of the button :-)
(sure, FF it works as expected ;-))
the source-code is:
tr:form defaultCommand=first binding=#{editor.component}
...
tr:inputText label=First form, First Field: shortDesc=Field 1 /
tr:inputText label=First form, Second Field: shortDesc=Field 2 /
tr:commandButton id=first text=First /
...
/tr:form
any comments ?
-Matthias
--
Matthias Wessendorf
further stuff:
blog: http://matthiaswessendorf.wordpress.com/
mail: matzew-at-apache-dot-org
--
Matthias Wessendorf
further stuff:
blog: http://matthiaswessendorf.wordpress.com/
mail: matzew-at-apache-dot-org
--
Matthias Wessendorf
further stuff:
blog: http://matthiaswessendorf.wordpress.com/
mail: matzew-at-apache-dot-org
Re: svn commit: r576576 [1/3] - in /myfaces/trinidad/trunk/trinidad: trinidad-build/src/main/resources/META-INF/maven-faces-plugin/components/trinidad/core/ trinidad-impl/src/main/java/org/apache/myfa
I'm happier if we don't add any attributes... We definitely want default behavior where, if nothing is specified, the icons get shown. -- Adam On 9/20/07, Jeanne Waldman [EMAIL PROTECTED] wrote: The other api I like is one you mentioned was not backwards compatible, and that is to have them put the icon in the facet if they want an icon. I agree that the below API is busy, but to me it is clear. No guessing what the logic is. Simon Lessard wrote: Hello Jeanne, Something alike was proposed at first, but again the most common usage kicks in. Such attributes imply, for GMail like behavior: tr:statusIndicator hideReadyIcon=true hideBusyIcon=true f:facet name=busy tr:outputText value=Loading.../ /f:facet /tr:statusIndicator It's a bit longer, but it's easily livable with I guess. On 9/20/07, Jeanne Waldman [EMAIL PROTECTED] wrote: How about hideReadyIcon = true/false hideBusyIcon = true/false. It's explicit and the user doesn't have to guess at the logic we are using -- or read the doc. - Jeanne Simon Lessard wrote: Hello Adam, On 9/18/07, Adam Winer [EMAIL PROTECTED] wrote: I think it should be as simple as for each of busy and ready, render the facet if it's present, the icon if it's not. The only issue with that behavior is most common usage. I think the most common usage with facets is going to be a busy facet and no ready (to mimic GMail behavior for example). Personally, that's the way I would use it. If that's really the most common case, then it should be as soon as a facet is specified, rendered or not, no icon will be rendered. But, if we think the most common case is going to be with both facets, then I agree with your suggestion. ~ Simon -- Adam On 9/18/07, Simon Lessard [EMAIL PROTECTED] wrote: Hmm not as simple as I though. Before pushing a patch let decide on the behavior for every use case: Both facets are specified and rendered -- Don't render any icon Both facets are specified but only one is rendered -- ? Both facets are specified but neither are rendered -- ? Only one facet is specified and rendered -- Don't render any icon or render the icon of the missing facet? Only one facet is specified but not rendered -- ? No facet is specified -- Render both icons ~ Simon On 9/18/07, Simon Lessard [EMAIL PROTECTED] wrote: Or put tr:icon in the facet. Yeah, that sound good too. On 9/18/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: that sounds like the best solution. On 9/18/07, Adam Winer [EMAIL PROTECTED] wrote: IMO, if we have a facet, we don't render the icon. No need for an attribute at all. Anyone that desperately needs both the facet and the icon can render two statusIndicators. -- Adam On 9/18/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: Hi, On 9/18/07, Simon Lessard [EMAIL PROTECTED] wrote: Speaking of which, I forgot to add skin documentation. I'll do that right away. I would also like to add a new attribute to skip the icon rendering. If it hasn't been of backward compatibility, I would have simply removed them I added a demo usage of the facet's, I was thinking, that it shouldn't render the default icon, glad you pointed it out now. since it's easily doable with a combination of facet and tr:icon, but since we had a release with the statusIndicator already, that's out of question. So, what I need now is a decent attribute name. What do you think of renderIcon or renderFacetsOnly? I tend to like renderFacetsOnly, because that what you added where facets. Perhaps, we can change that soon, that when facet's are specified, we don't render the default icon. -Matthias ~ Simon -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ mail: matzew-at-apache-dot-org -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ mail: matzew-at-apache-dot-org
Re: [TRINIDAD] PPR problem with 1.2.2 branch
PPR is totally overhauled from 1.2.1 to 1.2.2, so changes
aren't a surprise. The question is why this is happening,
and we need more information, because we did (honest)
test this code quite a bit, so there's something different about
your set up, and ideally you could play around with a lot
of variables.
First up, are you really only using the RI? No MyFaces
implementation also lying around on the classpath? I'm
guessing this is Firefox? Is this Facelets? If so, what
version? If JSP, is that really the full content of your page?
Are you using XHTML? If so, is the problem specific
to XHTML (that is, does it go away if you build an
HTML page)?
-- Adam
On 9/18/07, Tobias Freier [EMAIL PROTECTED] wrote:
Leonardo Uribe wrote:
[Invalid PPR response. The response-headers were:\nServer:
Apache-Coyote/1.1\nContent-Type: text/xml;ch...]
I'm facing a similar error on my page.
Tomcat 6.0.13 with Java 6 upd 2 and the newest version 1.2.2 of trinidad and
RI jsf 1.2.4.
trimmed jsf code:
html xmlns=http://www.w3.org/1999/xhtml;
f:view
head
/head
trh:body id=a1
tr:form id=form1
tr:table id=table1 ...
tr:column styleClass=mystyle
h:outputText value=#{table.value} styleClass=boldText /
/tr:column
/tr:table
/tr:form
/trh:body
/f:view
/html
So body, form and table have an id.
When I try to change the range of the table or trigger any other event to
update the tabele it doesn't work. The RangeChangeEvent method is executed
but the page doesn't refresh. Instead I get the js error
Invalid PPR response. The response-headers were:\nServer:
Apache-Coyote/1.1\nX-Powered-By: JSF/1.2\nContent-Type:
text/xml;charset=utf-8\nContent-Language: de\nTransfer-Encoding:
chunked\nDate: Tue, 18 Sep 2007 23:45:14 GMT\n\n The invalid response
was:\n?xml version=\1.0\ encoding=\UTF-8\
?\r\n\r\n\r\n\r\n\r\n\r\n\r\n!DOCTYPE html PUBLIC \-//W3C//DTD XHTML 1.0
Transitional//EN\
\http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd\;\r\nhtml
xmlns=\http://www.w3.org/1999/xhtml\;\r\n?xml version=\1.0\
?\n?Tr-XHR-Response-Type ?\n...
content to replace...
The same code worked under trinidad 1.2.1
Does anyone has a clue why it doesn't work with 1.2.2?
Tnx, Tobias
--
View this message in context:
http://www.nabble.com/-TRINIDAD--PPR-problem-with-1.2.2-branch-tf4275649.html#a12768364
Sent from the My Faces - Dev mailing list archive at Nabble.com.
Re: svn commit: r576576 [1/3] - in /myfaces/trinidad/trunk/trinidad: trinidad-build/src/main/resources/META-INF/maven-faces-plugin/components/trinidad/core/ trinidad-impl/src/main/java/org/apache/myfa
I see what you're saying... I think I'd be OK then with a rule where specifying either facet gets rid of both icons. Especially with a bit of doc explaining why it does that (exactly the example you give). -- Adam On 9/19/07, Simon Lessard [EMAIL PROTECTED] wrote: Hello Adam, On 9/18/07, Adam Winer [EMAIL PROTECTED] wrote: I think it should be as simple as for each of busy and ready, render the facet if it's present, the icon if it's not. The only issue with that behavior is most common usage. I think the most common usage with facets is going to be a busy facet and no ready (to mimic GMail behavior for example). Personally, that's the way I would use it. If that's really the most common case, then it should be as soon as a facet is specified, rendered or not, no icon will be rendered. But, if we think the most common case is going to be with both facets, then I agree with your suggestion. ~ Simon -- Adam On 9/18/07, Simon Lessard [EMAIL PROTECTED] wrote: Hmm not as simple as I though. Before pushing a patch let decide on the behavior for every use case: Both facets are specified and rendered -- Don't render any icon Both facets are specified but only one is rendered -- ? Both facets are specified but neither are rendered -- ? Only one facet is specified and rendered -- Don't render any icon or render the icon of the missing facet? Only one facet is specified but not rendered -- ? No facet is specified -- Render both icons ~ Simon On 9/18/07, Simon Lessard [EMAIL PROTECTED] wrote: Or put tr:icon in the facet. Yeah, that sound good too. On 9/18/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: that sounds like the best solution. On 9/18/07, Adam Winer [EMAIL PROTECTED] wrote: IMO, if we have a facet, we don't render the icon. No need for an attribute at all. Anyone that desperately needs both the facet and the icon can render two statusIndicators. -- Adam On 9/18/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: Hi, On 9/18/07, Simon Lessard [EMAIL PROTECTED] wrote: Speaking of which, I forgot to add skin documentation. I'll do that right away. I would also like to add a new attribute to skip the icon rendering. If it hasn't been of backward compatibility, I would have simply removed them I added a demo usage of the facet's, I was thinking, that it shouldn't render the default icon, glad you pointed it out now. since it's easily doable with a combination of facet and tr:icon, but since we had a release with the statusIndicator already, that's out of question. So, what I need now is a decent attribute name. What do you think of renderIcon or renderFacetsOnly? I tend to like renderFacetsOnly, because that what you added where facets. Perhaps, we can change that soon, that when facet's are specified, we don't render the default icon. -Matthias ~ Simon -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ mail: matzew-at-apache-dot-org -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ mail: matzew-at-apache-dot-org
Re: svn commit: r576576 [1/3] - in /myfaces/trinidad/trunk/trinidad: trinidad-build/src/main/resources/META-INF/maven-faces-plugin/components/trinidad/core/ trinidad-impl/src/main/java/org/apache/myfa
OK, five seconds more consideration, and now I'm torn. It's easy enough to write: tr:statusIndicator f:facet name=busyLoading.../f:facet f:facet name=readytr:outputText//f:facet /tr:statusIndicator ... which would have the same effect. So I could really go either way. -- Adam On 9/19/07, Adam Winer [EMAIL PROTECTED] wrote: I see what you're saying... I think I'd be OK then with a rule where specifying either facet gets rid of both icons. Especially with a bit of doc explaining why it does that (exactly the example you give). -- Adam On 9/19/07, Simon Lessard [EMAIL PROTECTED] wrote: Hello Adam, On 9/18/07, Adam Winer [EMAIL PROTECTED] wrote: I think it should be as simple as for each of busy and ready, render the facet if it's present, the icon if it's not. The only issue with that behavior is most common usage. I think the most common usage with facets is going to be a busy facet and no ready (to mimic GMail behavior for example). Personally, that's the way I would use it. If that's really the most common case, then it should be as soon as a facet is specified, rendered or not, no icon will be rendered. But, if we think the most common case is going to be with both facets, then I agree with your suggestion. ~ Simon -- Adam On 9/18/07, Simon Lessard [EMAIL PROTECTED] wrote: Hmm not as simple as I though. Before pushing a patch let decide on the behavior for every use case: Both facets are specified and rendered -- Don't render any icon Both facets are specified but only one is rendered -- ? Both facets are specified but neither are rendered -- ? Only one facet is specified and rendered -- Don't render any icon or render the icon of the missing facet? Only one facet is specified but not rendered -- ? No facet is specified -- Render both icons ~ Simon On 9/18/07, Simon Lessard [EMAIL PROTECTED] wrote: Or put tr:icon in the facet. Yeah, that sound good too. On 9/18/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: that sounds like the best solution. On 9/18/07, Adam Winer [EMAIL PROTECTED] wrote: IMO, if we have a facet, we don't render the icon. No need for an attribute at all. Anyone that desperately needs both the facet and the icon can render two statusIndicators. -- Adam On 9/18/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: Hi, On 9/18/07, Simon Lessard [EMAIL PROTECTED] wrote: Speaking of which, I forgot to add skin documentation. I'll do that right away. I would also like to add a new attribute to skip the icon rendering. If it hasn't been of backward compatibility, I would have simply removed them I added a demo usage of the facet's, I was thinking, that it shouldn't render the default icon, glad you pointed it out now. since it's easily doable with a combination of facet and tr:icon, but since we had a release with the statusIndicator already, that's out of question. So, what I need now is a decent attribute name. What do you think of renderIcon or renderFacetsOnly? I tend to like renderFacetsOnly, because that what you added where facets. Perhaps, we can change that soon, that when facet's are specified, we don't render the default icon. -Matthias ~ Simon -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ mail: matzew-at-apache-dot-org -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ mail: matzew-at-apache-dot-org
Re: [TRINIDAD] PPR problem with 1.2.2 branch
Ah, great, now we've got a compact description of the bug. :)
If you have an XML declaration, in the doc, we end up generating
two XML declarations on a PPR response. There's code in Trinidad (in
the XmlOutput code) to strip anything before an XML declaration,
but it gets tripped up if there are two.
My understanding, backed up by:
http://en.wikipedia.org/wiki/XHTML#XML_Declaration
is that you don't need the XML declaration to be valid XHTML.
There is a clear error in your page, though:
contentType=text/html; charset=UTF-8
is wrong. You need contentType=application/xhtml+xml; charset=UTF-8.
I'm not surprised your page wasn't rendered as XHTML.
That said, what you ideally should be doing in Trinidad is using
tr:document or trh:html/trh:head/trh:body, and not
specifying an XML declaration or DTD, but just letting Trinidad
do it for you. These do support generating XHTML DTDs,
BTW, as long as you've set the contentType correctly.
-- Adam
On 9/19/07, Tobias Freier [EMAIL PROTECTED] wrote:
Thanks for your help Adam,
It doesn't work on Firefox or IE.
I don't use Facelets. Just normal JSF with RI 1.2.04P02 and there is no
MyFaces.
No this was not the full page (too long). But thanks to your hint with the
xhtml I found the error.
The page started with:
?xml version=1.0 encoding=UTF-8 ?
%@ taglib uri=http://java.sun.com/jsf/html; prefix=h %
%@ taglib uri=http://java.sun.com/jsf/core; prefix=f %
%@ taglib uri=http://myfaces.apache.org/trinidad; prefix=tr%
%@ taglib uri=http://myfaces.apache.org/trinidad/html; prefix=trh%
%@ page language=java contentType=text/html; charset=UTF-8
pageEncoding=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;
f:view
head
...
therefore the response of the PPR was
?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;
?xml version=1.0 ?
?Tr-XHR-Response-Type ?
content action=..
Now I deleted the ?xml version=1.0 encoding=UTF-8 ? at the beginning
of my JSP page and I get the response
?xml version=1.0 ?
?Tr-XHR-Response-Type ?
content action=...
this works fine now.
The only problem is that this is no longer a well formed xhtml page.
At this point I saw that my page isn't rendered as xhtml anyway. What do I
have to use to get xhtml?
Tobias
Adam Winer wrote:
PPR is totally overhauled from 1.2.1 to 1.2.2, so changes
aren't a surprise. The question is why this is happening,
and we need more information, because we did (honest)
test this code quite a bit, so there's something different about
your set up, and ideally you could play around with a lot
of variables.
First up, are you really only using the RI? No MyFaces
implementation also lying around on the classpath? I'm
guessing this is Firefox? Is this Facelets? If so, what
version? If JSP, is that really the full content of your page?
Are you using XHTML? If so, is the problem specific
to XHTML (that is, does it go away if you build an
HTML page)?
-- Adam
On 9/18/07, Tobias Freier [EMAIL PROTECTED] wrote:
Leonardo Uribe wrote:
[Invalid PPR response. The response-headers were:\nServer:
Apache-Coyote/1.1\nContent-Type: text/xml;ch...]
I'm facing a similar error on my page.
Tomcat 6.0.13 with Java 6 upd 2 and the newest version 1.2.2 of trinidad
and
RI jsf 1.2.4.
trimmed jsf code:
html xmlns=http://www.w3.org/1999/xhtml;
f:view
head
/head
trh:body id=a1
tr:form id=form1
tr:table id=table1 ...
tr:column styleClass=mystyle
h:outputText value=#{table.value} styleClass=boldText /
/tr:column
/tr:table
/tr:form
/trh:body
/f:view
/html
So body, form and table have an id.
When I try to change the range of the table or trigger any other event to
update the tabele it doesn't work. The RangeChangeEvent method is
executed
but the page doesn't refresh. Instead I get the js error
Invalid PPR response. The response-headers were:\nServer:
Apache-Coyote/1.1\nX-Powered-By: JSF/1.2\nContent-Type:
text/xml;charset=utf-8\nContent-Language: de\nTransfer-Encoding:
chunked\nDate: Tue, 18 Sep 2007 23:45:14 GMT\n\n The invalid response
was:\n?xml version=\1.0\ encoding=\UTF-8\
?\r\n\r\n\r\n\r\n\r\n\r\n\r\n!DOCTYPE html PUBLIC \-//W3C//DTD XHTML
1.0
Transitional//EN\
\http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd\;\r\nhtml
xmlns=\http://www.w3.org/1999/xhtml\;\r\n?xml version=\1.0\
?\n?Tr-XHR-Response-Type ?\n...
content to replace...
The same code worked under trinidad 1.2.1
Does anyone has a clue why it doesn't work with 1.2.2?
Tnx, Tobias
--
View this message in context:
http://www.nabble.com/-TRINIDAD--PPR-problem-with-1.2.2-branch
Re: [Trinidad] Plugins 123 release ?
I think Andrew has some improvements for the Facelets generator that would be really worthwhile. Other than that, I don't know of anything holding up the release. -- Adam On 9/19/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: Hi, not to bug you, but what are your takes on a release of the 1.2.3 plugins. The unified one :-) -Matthias -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ mail: matzew-at-apache-dot-org
Re: svn commit: r576576 [1/3] - in /myfaces/trinidad/trunk/trinidad: trinidad-build/src/main/resources/META-INF/maven-faces-plugin/components/trinidad/core/ trinidad-impl/src/main/java/org/apache/myfa
On 9/19/07, Perkins, Nate-P63196 [EMAIL PROTECTED] wrote: Yes, but why pollute the page unnecessarily with an empty outputText? Indeed. (I'd probably use a tr:group, but same deal). The flip side is wondering how much of a pain it'd be to implement I want to change the ready icon, but not the busy icon if we go with set either facet, both icons are gone. Either design makes someone's life hard... which do we think is more common? If I approach the subject from a maintainability perspective, I think its more intuitive for the documentation to state why the icon is gone then to have to figure out why some developer stuck an empty outputText into a facet. Anyone hacking in either case does have the option of including a comment in the page, ya know! -- Adam I've been watching this thread, so I hope you don't mind my 2 cents Nate Perkins General Dynamics C4 Systems 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, September 19, 2007 9:24 AM To: MyFaces Development Subject: Re: svn commit: r576576 [1/3] - in /myfaces/trinidad/trunk/trinidad: trinidad-build/src/main/resources/META-INF/maven-faces-plugin/components /trinidad/core/ trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/renderki t/core/xhtml/ trinida OK, five seconds more consideration, and now I'm torn. It's easy enough to write: tr:statusIndicator f:facet name=busyLoading.../f:facet f:facet name=readytr:outputText//f:facet /tr:statusIndicator ... which would have the same effect. So I could really go either way. -- Adam On 9/19/07, Adam Winer [EMAIL PROTECTED] wrote: I see what you're saying... I think I'd be OK then with a rule where specifying either facet gets rid of both icons. Especially with a bit of doc explaining why it does that (exactly the example you give). -- Adam On 9/19/07, Simon Lessard [EMAIL PROTECTED] wrote: Hello Adam, On 9/18/07, Adam Winer [EMAIL PROTECTED] wrote: I think it should be as simple as for each of busy and ready, render the facet if it's present, the icon if it's not. The only issue with that behavior is most common usage. I think the most common usage with facets is going to be a busy facet and no ready (to mimic GMail behavior for example). Personally, that's the way I would use it. If that's really the most common case, then it should be as soon as a facet is specified, rendered or not, no icon will be rendered. But, if we think the most common case is going to be with both facets, then I agree with your suggestion. ~ Simon -- Adam On 9/18/07, Simon Lessard [EMAIL PROTECTED] wrote: Hmm not as simple as I though. Before pushing a patch let decide on the behavior for every use case: Both facets are specified and rendered -- Don't render any icon Both facets are specified but only one is rendered -- ? Both facets are specified but neither are rendered -- ? Only one facet is specified and rendered -- Don't render any icon or render the icon of the missing facet? Only one facet is specified but not rendered -- ? No facet is specified -- Render both icons ~ Simon On 9/18/07, Simon Lessard [EMAIL PROTECTED] wrote: Or put tr:icon in the facet. Yeah, that sound good too. On 9/18/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: that sounds like the best solution. On 9/18/07, Adam Winer [EMAIL PROTECTED] wrote: IMO, if we have a facet, we don't render the icon. No need for an attribute at all. Anyone that desperately needs both the facet and the icon can render two statusIndicators. -- Adam On 9/18/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: Hi, On 9/18/07, Simon Lessard [EMAIL PROTECTED] wrote: Speaking of which, I forgot to add skin documentation. I'll do that right away. I would also like to add a new attribute to skip the icon rendering. If it hasn't been of backward compatibility, I would have simply removed them I added a demo usage of the facet's, I was thinking, that it shouldn't render the default icon, glad you pointed it out now. since it's easily doable with a combination of facet and tr:icon, but since we had a release with the statusIndicator already, that's out
Re: [Trinidad] Plugins 123 release ?
I think the big thing to test is making sure that the 1.0.3-SNAPSHOT core build runs fine against it. We haven't been able to switch over our 1.0.3 build to the 1.2.3 plugins - the plugin snapshots aren't getting deployed, so our build would break... -- Adam On 9/19/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: cool, can you ping me, when you think it's fine ? I'd like to provide the RC over the weekend :-) .M On 9/19/07, Andrew Robinson [EMAIL PROTECTED] wrote: They are in. Barring some more testing, should be ready to go. On 9/19/07, Adam Winer [EMAIL PROTECTED] wrote: I think Andrew has some improvements for the Facelets generator that would be really worthwhile. Other than that, I don't know of anything holding up the release. -- Adam On 9/19/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: Hi, not to bug you, but what are your takes on a release of the 1.2.3 plugins. The unified one :-) -Matthias -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ mail: matzew-at-apache-dot-org -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ mail: matzew-at-apache-dot-org
Re: svn commit: r576576 [1/3] - in /myfaces/trinidad/trunk/trinidad: trinidad-build/src/main/resources/META-INF/maven-faces-plugin/components/trinidad/core/ trinidad-impl/src/main/java/org/apache/myfa
IMO, if we have a facet, we don't render the icon. No need for an attribute at all. Anyone that desperately needs both the facet and the icon can render two statusIndicators. -- Adam On 9/18/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: Hi, On 9/18/07, Simon Lessard [EMAIL PROTECTED] wrote: Speaking of which, I forgot to add skin documentation. I'll do that right away. I would also like to add a new attribute to skip the icon rendering. If it hasn't been of backward compatibility, I would have simply removed them I added a demo usage of the facet's, I was thinking, that it shouldn't render the default icon, glad you pointed it out now. since it's easily doable with a combination of facet and tr:icon, but since we had a release with the statusIndicator already, that's out of question. So, what I need now is a decent attribute name. What do you think of renderIcon or renderFacetsOnly? I tend to like renderFacetsOnly, because that what you added where facets. Perhaps, we can change that soon, that when facet's are specified, we don't render the default icon. -Matthias ~ Simon -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ mail: matzew-at-apache-dot-org
Re: Continuum
Yes, please! +1. -- Adam On 9/18/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: +1 we really need a thing like that :-) On 9/18/07, Bernd Bohmann [EMAIL PROTECTED] wrote: Hello Matthias, my current plan is to setup an continuum instance on 8080 again, for the deploy and nightly build stuff. Any objections? Regards Bernd Matthias Wessendorf wrote: Hi, there was a continuum server (port 8081) on our zone, currently down. The vmbuild, I can't deploy stuff, does only build... What is the current plan, do we want to move all our projects to Brett's vmbuild ? -Matze -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ mail: matzew-at-apache-dot-org
Re: svn commit: r576576 [1/3] - in /myfaces/trinidad/trunk/trinidad: trinidad-build/src/main/resources/META-INF/maven-faces-plugin/components/trinidad/core/ trinidad-impl/src/main/java/org/apache/myfa
I think it should be as simple as for each of busy and ready, render the facet if it's present, the icon if it's not. -- Adam On 9/18/07, Simon Lessard [EMAIL PROTECTED] wrote: Hmm not as simple as I though. Before pushing a patch let decide on the behavior for every use case: Both facets are specified and rendered -- Don't render any icon Both facets are specified but only one is rendered -- ? Both facets are specified but neither are rendered -- ? Only one facet is specified and rendered -- Don't render any icon or render the icon of the missing facet? Only one facet is specified but not rendered -- ? No facet is specified -- Render both icons ~ Simon On 9/18/07, Simon Lessard [EMAIL PROTECTED] wrote: Or put tr:icon in the facet. Yeah, that sound good too. On 9/18/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: that sounds like the best solution. On 9/18/07, Adam Winer [EMAIL PROTECTED] wrote: IMO, if we have a facet, we don't render the icon. No need for an attribute at all. Anyone that desperately needs both the facet and the icon can render two statusIndicators. -- Adam On 9/18/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: Hi, On 9/18/07, Simon Lessard [EMAIL PROTECTED] wrote: Speaking of which, I forgot to add skin documentation. I'll do that right away. I would also like to add a new attribute to skip the icon rendering. If it hasn't been of backward compatibility, I would have simply removed them I added a demo usage of the facet's, I was thinking, that it shouldn't render the default icon, glad you pointed it out now. since it's easily doable with a combination of facet and tr:icon, but since we had a release with the statusIndicator already, that's out of question. So, what I need now is a decent attribute name. What do you think of renderIcon or renderFacetsOnly? I tend to like renderFacetsOnly, because that what you added where facets. Perhaps, we can change that soon, that when facet's are specified, we don't render the default icon. -Matthias ~ Simon -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ mail: matzew-at-apache-dot-org -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ mail: matzew-at-apache-dot-org
Re: svn commit: r576576 [1/3] - in /myfaces/trinidad/trunk/trinidad: trinidad-build/src/main/resources/META-INF/maven-faces-plugin/components/trinidad/core/ trinidad-impl/src/main/java/org/apache/myfa
is busy ? -M On 9/18/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: I think no facet = icon is rendered; otherwise, no icon is rendered. -M On 9/18/07, Simon Lessard [EMAIL PROTECTED] wrote: Hmm not as simple as I though. Before pushing a patch let decide on the behavior for every use case: Both facets are specified and rendered -- Don't render any icon Both facets are specified but only one is rendered -- ? Both facets are specified but neither are rendered -- ? Only one facet is specified and rendered -- Don't render any icon or render the icon of the missing facet? Only one facet is specified but not rendered -- ? No facet is specified -- Render both icons ~ Simon On 9/18/07, Simon Lessard [EMAIL PROTECTED] wrote: Or put tr:icon in the facet. Yeah, that sound good too. On 9/18/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: that sounds like the best solution. On 9/18/07, Adam Winer [EMAIL PROTECTED] wrote: IMO, if we have a facet, we don't render the icon. No need for an attribute at all. Anyone that desperately needs both the facet and the icon can render two statusIndicators. -- Adam On 9/18/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: Hi, On 9/18/07, Simon Lessard [EMAIL PROTECTED] wrote: Speaking of which, I forgot to add skin documentation. I'll do that right away. I would also like to add a new attribute to skip the icon rendering. If it hasn't been of backward compatibility, I would have simply removed them I added a demo usage of the facet's, I was thinking, that it shouldn't render the default icon, glad you pointed it out now. since it's easily doable with a combination of facet and tr:icon, but since we had a release with the statusIndicator already, that's out of question. So, what I need now is a decent attribute name. What do you think of renderIcon or renderFacetsOnly? I tend to like renderFacetsOnly, because that what you added where facets. Perhaps, we can change that soon, that when facet's are specified, we don't render the default icon. -Matthias ~ Simon -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ mail: matzew-at-apache-dot-org -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ mail: matzew-at-apache-dot-org -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ mail: matzew-at-apache-dot-org -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ mail: matzew-at-apache-dot-org -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ mail: matzew-at-apache-dot-org
[jira] Resolved: (TRINIDAD-721) h:commandButton immediate attribute is broken
[
https://issues.apache.org/jira/browse/TRINIDAD-721?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adam Winer resolved TRINIDAD-721.
-
Resolution: Fixed
Fix Version/s: 1.0.3-core
Fixed for 1.0.3 (and 1.2.3 when we re-branch).
h:commandButton immediate attribute is broken
---
Key: TRINIDAD-721
URL: https://issues.apache.org/jira/browse/TRINIDAD-721
Project: MyFaces Trinidad
Issue Type: Bug
Components: Components
Affects Versions: 1.0.2-core, 1.2.2-core
Reporter: Mike Hanafey
Assignee: Adam Winer
Fix For: 1.0.3-core
The doc file spec-diff.html states: It is important to emphasize that there
is no requirement whatsoever that you convert from standard JSF tags to
Apache Trinidad tags. Standard JSF tags and Apache Trinidad tags can be mixed
freely within a single page.
However, if you are converting a page with standard JSF tags, and happen to
leave behind a h:commandButton tag that has immediate='true' you end up
with a button that functions, but does not conform to the dictates of the
immediate attribute. I don't know if this is a documentation problem, or a
bug in the code.
In the example below (from the trinidad-blank application), button3 results
in a validation error, but button2 works as expected:
?xml version=1.0 encoding=iso-8859-1 standalone=yes ?
jsp:root xmlns:jsp=http://java.sun.com/JSP/Page; version=2.0
xmlns:f=http://java.sun.com/jsf/core;
xmlns:h=http://java.sun.com/jsf/html;
xmlns:tr=http://myfaces.apache.org/trinidad;
jsp:directive.page contentType=text/html;charset=utf-8/
f:view
tr:document title=Apache Trinidad Blank Demo
tr:form
tr:panelPage
tr:inputText label=Your name id=input1
value=#{helloWorldBacking.name} required=true/
tr:commandButton id=button1 text=press me
action=#{helloWorldBacking.send}/
tr:commandButton id=button2 immediate=true
text=clear action=#{helloWorldBacking.clear}/
h:commandButton id=button3 immediate=true
value=clear action=#{helloWorldBacking.clear}/
/tr:panelPage
/tr:form
/tr:document
/f:view
/jsp:root
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (TRINIDAD-706) JSF 1.2: Non-EL attributes of tags are always generated as Strings
[ https://issues.apache.org/jira/browse/TRINIDAD-706?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Winer resolved TRINIDAD-706. - Resolution: Fixed Fix Version/s: 1.2.3-plugins JSF 1.2: Non-EL attributes of tags are always generated as Strings -- Key: TRINIDAD-706 URL: https://issues.apache.org/jira/browse/TRINIDAD-706 Project: MyFaces Trinidad Issue Type: Bug Components: Plugins Affects Versions: 1.2.2-plugins Reporter: Adam Winer Fix For: 1.2.3-plugins See the default attribute of UIXSubformTag. It should be of type boolean; instead, it's type String. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (TRINIDAD-714) maven-myfaces-plugin does not generate taglib.xml output for facelets-only environment
[ https://issues.apache.org/jira/browse/TRINIDAD-714?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Winer resolved TRINIDAD-714. - Resolution: Fixed Fix Version/s: 1.2.3-plugins Assignee: Adam Winer Fixed in the (now universal) 1.2.3 plugins. maven-myfaces-plugin does not generate taglib.xml output for facelets-only environment -- Key: TRINIDAD-714 URL: https://issues.apache.org/jira/browse/TRINIDAD-714 Project: MyFaces Trinidad Issue Type: Bug Components: Plugins Affects Versions: 1.0.2-plugins Reporter: Andrew Robinson Assignee: Adam Winer Fix For: 1.2.3-plugins It seems like the maven-faces-plugin is not generating any taglib.xml output for components unless JSP tag support is added. It should theoretically work for people in a facelets only environment to be able to generate taglib.xml files for their component without creating any JSP dependent functionality. Mailing list thread: http://tinyurl.com/2rau4l -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (TRINIDAD-712) Do not generate final properties with the maven-faces-plugin
[ https://issues.apache.org/jira/browse/TRINIDAD-712?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Winer resolved TRINIDAD-712. - Resolution: Invalid Assignee: Adam Winer Regarding use of final, a lot of people would strongly disagree with you. Final should be used whereever it makes sense. Here, it makes absolute sense: the true value is stored on the FacesBean. Overriding the getter or setter convenience is useless, and final is exactly correct. Do not generate final properties with the maven-faces-plugin Key: TRINIDAD-712 URL: https://issues.apache.org/jira/browse/TRINIDAD-712 Project: MyFaces Trinidad Issue Type: Wish Components: Plugins Affects Versions: 1.0.2-plugins Environment: maven-faces-plugin version 1.0.2 from the maven repository Reporter: Andrew Robinson Assignee: Adam Winer It would be extremely beneficial to not have property methods generated as final by the maven-faces-plugin. IMO, final should be reserved for constants and only on methods with rare exceptions and good reasons. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TRINIDAD-712) Do not generate final properties with the maven-faces-plugin
[ https://issues.apache.org/jira/browse/TRINIDAD-712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12527920 ] Adam Winer commented on TRINIDAD-712: - Simon, Andrew: the methods are not final for performance; there would be no significant boost. The only reason to ever make classes and methods final is for design reasons. The methods are final ENTIRELY because of the FacesBean architecture. The generated JSP tags write directly to the FacesBean, bypassing the set methods. The renderers read directly from the FacesBean, bypassing the get methods. Overriding the getters and setters would therefore be completely pointless in the current architecture. We could debate (on [EMAIL PROTECTED]) whether the JSP tags and renderers should do what they do, but it would be very bad to let people think they can override these accessors, when in fact they cannot. Do not generate final properties with the maven-faces-plugin Key: TRINIDAD-712 URL: https://issues.apache.org/jira/browse/TRINIDAD-712 Project: MyFaces Trinidad Issue Type: Wish Components: Plugins Affects Versions: 1.0.2-plugins Environment: maven-faces-plugin version 1.0.2 from the maven repository Reporter: Andrew Robinson Assignee: Adam Winer It would be extremely beneficial to not have property methods generated as final by the maven-faces-plugin. IMO, final should be reserved for constants and only on methods with rare exceptions and good reasons. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TRINIDAD-709) PPR error logging itself generates JS errors on IE
PPR error logging itself generates JS errors on IE -- Key: TRINIDAD-709 URL: https://issues.apache.org/jira/browse/TRINIDAD-709 Project: MyFaces Trinidad Issue Type: Bug Affects Versions: 1.0.2-core Reporter: Adam Winer Assignee: Adam Winer -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (TRINIDAD-709) PPR error logging itself generates JS errors on IE
[ https://issues.apache.org/jira/browse/TRINIDAD-709?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Winer resolved TRINIDAD-709. - Resolution: Fixed Fix Version/s: 1.0.3-core Fixed; the issue, BTW, was that the JS console variable was directly referenced, instead of off of the window. Works fine when there is a console, breaks when there isn't. PPR error logging itself generates JS errors on IE -- Key: TRINIDAD-709 URL: https://issues.apache.org/jira/browse/TRINIDAD-709 Project: MyFaces Trinidad Issue Type: Bug Affects Versions: 1.0.2-core Reporter: Adam Winer Assignee: Adam Winer Fix For: 1.0.3-core -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TRINIDAD-709) PPR error logging itself generates JS errors on IE
[ https://issues.apache.org/jira/browse/TRINIDAD-709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12527198 ] Adam Winer commented on TRINIDAD-709: - Better logging would be very worthwhile (there's a bunch of commented-out code - but the imperative right now is not breaking IE. Enhancing logging should be a separate issue. Both the projects you reference are Apache licensed, so both would be legally OK for use by Trinidad. PPR error logging itself generates JS errors on IE -- Key: TRINIDAD-709 URL: https://issues.apache.org/jira/browse/TRINIDAD-709 Project: MyFaces Trinidad Issue Type: Bug Affects Versions: 1.0.2-core Reporter: Adam Winer Assignee: Adam Winer Fix For: 1.0.3-core -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [TRINIDAD] Public Icon API change
I'm not sure I see the benefit, but I'm not always spot-on when it comes to wildcards in collections... Does the change mean that you're allowed to pass a MapString, String to this without casting, whereas before you couldn't? The common use-cases here all have a heterogeneous value type (because of embedded), so if I'm understanding this correctly, I don't see the benefit of this change. (BTW, I thought that in fact was possible to add elements to ? super ..., just not ? extends ) -- Adam On 9/13/07, Simon Lessard [EMAIL PROTECTED] wrote: Hello, I would like to do a public API change to Icon's renderIcon method and its dependencies. Currently the signature is abstract public void renderIcon( FacesContextcontext, RenderingContextarc, MapString, Object attrs ) throws IOException; I would like to change that to the following to make it easier to call because of non covariance of generic collections. abstract public void renderIcon( FacesContextcontext, RenderingContextarc, MapString, ? extends Object attrs ) throws IOException; I don't think it'll break anything as it's a generalization of the previous signature, meaning all old code should still be able to call the method without any change. The only implication is that renderIcon and its dependencies will no longer be able to alter the map since it's quite impossible to add an element to a collection containing a wildcard. It's not in the method contract to alter the attribute map though, so it should not be an issue. However, as it's a public API change, I preferred to ask on the mailing list in case I oversaw something. Regards, ~ Simon
Re: [TRINIDAD] Public Icon API change
On 9/13/07, Simon Lessard [EMAIL PROTECTED] wrote: Hello Adam, On 9/13/07, Adam Winer [EMAIL PROTECTED] wrote: I'm not sure I see the benefit, but I'm not always spot-on when it comes to wildcards in collections... Does the change mean that you're allowed to pass a MapString, String to this without casting, whereas before you couldn't? Yeah, that's the only benefit. More specifically, it allow the following to work: icon.renderIcon(context, rc, Collections.singletonMap(shortDesc, foo)); Ah, that's a good enough justification for me! The common use-cases here all have a heterogeneous value type (because of embedded), so if I'm understanding this correctly, I don't see the benefit of this change. (BTW, I thought that in fact was possible to add elements to ? super ..., just not ? extends ) Exactly, but it would really makes no sense at all to use super in that signature imho. Oh, absolutely - I just was self-testing my knowledge of generics since you wrote impossible to add an element to a collection containing a wildcard. I got worried that I didn't understand ? super as well as I thought I did. :) -- Adam -- Adam On 9/13/07, Simon Lessard [EMAIL PROTECTED] wrote: Hello, I would like to do a public API change to Icon's renderIcon method and its dependencies. Currently the signature is abstract public void renderIcon( FacesContextcontext, RenderingContextarc, MapString, Object attrs ) throws IOException; I would like to change that to the following to make it easier to call because of non covariance of generic collections. abstract public void renderIcon( FacesContextcontext, RenderingContextarc, MapString, ? extends Object attrs ) throws IOException; I don't think it'll break anything as it's a generalization of the previous signature, meaning all old code should still be able to call the method without any change. The only implication is that renderIcon and its dependencies will no longer be able to alter the map since it's quite impossible to add an element to a collection containing a wildcard. It's not in the method contract to alter the attribute map though, so it should not be an issue. However, as it's a public API change, I preferred to ask on the mailing list in case I oversaw something. Regards, ~ Simon
Re: [TRINIDAD] comments welcome for issue 703
Do such URLs in skins actually result in incoming URLs containing .., or does it get resolved out when we generate the .css? -- Adam On 9/12/07, Jeanne Waldman [EMAIL PROTECTED] wrote: Hi Simon, Very good point. I have seen skin's have .. in the background-image path. I forgot about that. The reason for fixing this issue is that we feel it is a security issue if the use of the .. in the path is such that the path goes outside of the 'root'. If I switch to the old code path and log a warning about the deprecated URL usage, then the security issue will still exist. It sounds like to fix the issue correctly, I'll have to make sure if the path contains .. that the path doesn't take us outside the root. e.g., foo/bar/../../zoo/../.. - takes you outside root. A side note -- I found a bug in the DirectoryResourceLoader where it was allowing paths outside the root directory, even though the comment said that it wasn't. I can fix that easily, and I will log a separate issue and fix that since it isn't controversial. Thanks again for your comments, - Jeanne Simon Lessard wrote: Hello Jeanne, Personally you won't break anything with my projects, but it's only because I fully converted the skin to use the new Trinidad URL system (well it's more Trinidad URL system than new actually). However, preventing the '..' will most likely make the passage between ADF Faces and Trinidad more difficult as '..' was often needed with ADF Faces and background-image within skins. Would it be possible to do your change but if you detect '..', switch to the old code path and log a warning about a deprecated URL usage within the skin? We could offer a grace period until one month or so after JDeveloper 11g get in production maybe? I would use that date because the amount of Trinidad user will most likely get a big boost from old ADF Faces users when JDev 11 is officially released. Also, those new users will most likely have to do the aforementioned conversion. Regards, ~ Simon On 9/11/07, Jeanne Waldman [EMAIL PROTECTED] wrote: My main concern is a. should I simply reject any path with .. in it as dangerous -or- b if the path contains .. should figure out if it resolves to a path outside the root and only reject it in that case. b is safer, but requires more processing. Thanks, - Jeanne Jeanne Waldman wrote: Hi there, I'm about to fix issue: https://issues.apache.org/jira/browse/TRINIDAD-703 snippet from issue: We register our image resource loader with a fairly loose pattern: register((/.*\\.(css|jpg|gif|png|jpeg|svg|js)), new CoreClassLoaderResourceLoader(parent)); In theory could someone get at an image on the class path outside of our own images by crafting a funky URL along the lines of ../../../../oracle/someotherpackage/foo.gif? Yes. ClassLoaderResourceLoader should prevent access outside of the rootPackage. I mention how I am fixing it (disallowing .. in the path), so please comment if you'd like. Thanks, Jeanne
Re: [TRINIDAD] Shuttle behavior is inconsistent with other selectMany
On 9/12/07, Simon Lessard [EMAIL PROTECTED] wrote: Hi all, Shuttle behavior is not the same as other selectMany components for purpose of retrieving the submitted values in two way. Firstly, shuttles submit a single parameter with values separated by ';'. That difference cannot really be changed. However, shuttles also do a first validation in that phase ... which phase, what method? -- Adam by comparing the submitted value list size with the LoV size (imply SelectItem resolution at that point). However, I think that latter validation shouldn't exist there and should be delayed until getSelectedIndices is called inside SimpleSelectManyRenderer as with all other selectMany components. Thoughts, objections? ~ Simon
Re: [TRINIDAD] StatusIndicator improvement
I like the facets a lot too, but I'm not thrilled with adding
extra JS attributes when we already have a JS hook.
Two ways of doing things only makes sense when the second
is much easier, not just marginally easier.
-- Adam
On 9/12/07, Andrew Robinson [EMAIL PROTECTED] wrote:
+1 great idea
I would also like to suggest javascript support as well:
tr:statusIndicator onbusy=alert('starting ajax');
onready=alert('ajax done'); /
This would probably be a simple hook around:
TrPage.getInstance().getRequestQueue().addStateChangeListener(func);
But it would be easier to have it on the component.
On 9/12/07, Simon Lessard [EMAIL PROTECTED] wrote:
Hi all,
I would like to add two facets to statusIndicator: busy and ready,
each
with an attached styleClass placed on a child span element. I think it
would
make the component much more customizable as it would allow something
like:
tr:statusIndicator
f:facet name=busy
tr:outputText value=Loading, please wait.../
/f:facet
/tr:statusIndicator
and in the skin:
af|statusIndicator::busy
{
border-color: black;
border-style: outset;
border-width: 2px;
display:block;
margin: auto;
position: absolute;
top:45%;
text-align: center;
vertical-align: middle;
}
af|statusIndicator::ready
{
}
The icon would still be supported and placed in the parent span, at the
same
place than now. The generated markup would thus look like:
span
span id=clientId::ready
img src=readyIcon/
span class=af_statusIndicator_ready
(ready facet content)
/span
/span
span id=clientId::busy
img src=budyIcon/
span class=af_statusIndicator_busy
(busy facet content)
/span
/span
/span
Anyone's ok with that or has a better idea?
~ Simon
Re: [TRINIDAD] Shuttle behavior is inconsistent with other selectMany
You're right, it'd be good if the Renderer did the check in getConvertedValue(), but not in getSubmittedValue(). -- Adam On 9/12/07, Simon Lessard [EMAIL PROTECTED] wrote: Oups it seems that I stripped some important information when I reread myself (one of the few times I did). The size check is done in getSubmittedValue so it's called mainly during conversion which is correct, but I don't think getSubmittedValue should do any validation, just return the String[]. ~ Simon On 9/12/07, Adam Winer [EMAIL PROTECTED] wrote: On 9/12/07, Simon Lessard [EMAIL PROTECTED] wrote: Hi all, Shuttle behavior is not the same as other selectMany components for purpose of retrieving the submitted values in two way. Firstly, shuttles submit a single parameter with values separated by ';'. That difference cannot really be changed. However, shuttles also do a first validation in that phase ... which phase, what method? -- Adam by comparing the submitted value list size with the LoV size (imply SelectItem resolution at that point). However, I think that latter validation shouldn't exist there and should be delayed until getSelectedIndices is called inside SimpleSelectManyRenderer as with all other selectMany components. Thoughts, objections? ~ Simon
[jira] Created: (TRINIDAD-706) JSF 1.2: Non-EL attributes of tags are always generated as Strings
JSF 1.2: Non-EL attributes of tags are always generated as Strings -- Key: TRINIDAD-706 URL: https://issues.apache.org/jira/browse/TRINIDAD-706 Project: MyFaces Trinidad Issue Type: Bug Components: Plugins Affects Versions: 1.2.2-plugins Reporter: Adam Winer See the default attribute of UIXSubformTag. It should be of type boolean; instead, it's type String. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (TRINIDAD-555) add public api to turn styleclass compression off for debugging
[
https://issues.apache.org/jira/browse/TRINIDAD-555?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adam Winer resolved TRINIDAD-555.
-
Resolution: Fixed
Fix Version/s: 1.0.3-core
A public config parameter was added (see the configuration chapter of the
developer's guide).
add public api to turn styleclass compression off for debugging
---
Key: TRINIDAD-555
URL: https://issues.apache.org/jira/browse/TRINIDAD-555
Project: MyFaces Trinidad
Issue Type: Improvement
Components: Skinning
Affects Versions: 1.0.1-incubating-core-SNAPSHOT
Reporter: Jeanne Waldman
Priority: Minor
Fix For: 1.0.3-core
People need to be able to debug skins. They can do this using Firebug, but
our styleclasses are compressed by default, so it is hard to figure out which
skin key they map to. When we wrote out both compressed and uncompressed
styleclasses to the generated stylesheet it was easier, but now we only
render the compressed styleclasses, so it is hard.
This is a question from a user that illustrates this problem:
Is there a way to reverse map the generated CSS (or maybe generate the
CSS files with better names). For example, I have the following css on
an html element and am trying to track down where each of these is
defined.
Not being a CSS expert it would be nice to be able even in a debug mode
to generate the CSS elements with more descriptive names so I can
quickly see what I need to change.
.xr, .xu, .x4j {MyCSS-des... (line 25)
color:#00;
font-family:Browallia New,Arial,Helvetica,Geneva,sans-serif;
font-size:10pt;
font-weight:normal;
padding:0px 8px 0px 0px;
text-align:left;
The way to disable the styleclass compression currently is by doing this in
your web.xml file:
context-param
param-nameorg.apache.myfaces.trinidadinternal.DISABLE_CONTENT_COMPRESSION/param-name
param-valuetrue/param-value
/context-param
I consider this a 'private' api and I don't like to suggest it to end users,
but I have to because there is no other way.
I think that a public api to do this when trinidad-config.xml's
debug-outputtrue/debug-output is set would be great.
We'll have to discuss whether or not this is a good idea or if there is a
better idea.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (TRINIDAD-638) trinidad-config.xml's parser should greedily trim white spaces for some properties
[
https://issues.apache.org/jira/browse/TRINIDAD-638?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adam Winer resolved TRINIDAD-638.
-
Resolution: Fixed
Fix Version/s: 1.0.3-core
Assignee: Adam Winer
Fixed.
trinidad-config.xml's parser should greedily trim white spaces for some
properties
--
Key: TRINIDAD-638
URL: https://issues.apache.org/jira/browse/TRINIDAD-638
Project: MyFaces Trinidad
Issue Type: Bug
Components: Build
Affects Versions: 1.0.2-core, 1.2.2-core
Reporter: Simon Lessard
Assignee: Adam Winer
Priority: Minor
Fix For: 1.0.3-core
Currently, the parser does not get rid of leading and trailing white spaces
greedily enough, resulting in some bad configuration setting for correct
looking XML file. Namely, the following will result in an error:
skin-family
#{view.locale.language == 'en' ? 'someEnglishSkin' : 'someOtherSkin'}
/skin-family
while the following works:
skin-family#{view.locale.language == 'en' ? 'someEnglishSkin' :
'someOtherSkin'}/skin-family
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (TRINIDAD-658) Add doctype flag to trh:html and trh:document to allow switching doctype to quirks mode
[ https://issues.apache.org/jira/browse/TRINIDAD-658?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Winer resolved TRINIDAD-658. - Resolution: Fixed Assignee: Adam Winer Added mode flag, which lets you turn on quirks or strict modes. Add doctype flag to trh:html and trh:document to allow switching doctype to quirks mode --- Key: TRINIDAD-658 URL: https://issues.apache.org/jira/browse/TRINIDAD-658 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 1.0.2-core Reporter: Nate Perkins Assignee: Adam Winer Priority: Minor Fix For: 1.0.3-core At the moment, trh:html and trh:document add the standard doctype. If a user desires to switch the doctype in a jspx, a jsp:output call is necessary which outputs a doctype to the stream and breaks the AJAX-based PPR in 1.0.2. Another side-effect of this is that the generated html has two doctypes. If DEBUG_JAVASCRIPT flag is turned on and the page is viewed in IE6 this will result in the page not being loaded with an unexpected doctype error. Currently there is a context parameter, ENABLE_QUIRKS_MODE, that can be used to put html documents into quirks mode. This does not work with xml documents. I suggest expanding this context parameter's scope to work with both xml and html. This will provide a default doctype for an application. The docType attribute for trh:html and trh:document could then be used to override the default for a particular page as needed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (TRINIDAD-678) Description Not Shown in TextArea for Select*Shuttle Components
[
https://issues.apache.org/jira/browse/TRINIDAD-678?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adam Winer resolved TRINIDAD-678.
-
Resolution: Fixed
Fix Version/s: 1.0.3-core
Assignee: Adam Winer
Applied change. Needed to also fix up SelectManyShuttleRenderer Java code for
other issues with handling shuttles that were inside a naming container.
Description Not Shown in TextArea for Select*Shuttle Components
---
Key: TRINIDAD-678
URL: https://issues.apache.org/jira/browse/TRINIDAD-678
Project: MyFaces Trinidad
Issue Type: Bug
Components: Components
Affects Versions: 1.2.1-core
Environment: [EMAIL PROTECTED]:~ uname -a
Linux aragorn 2.6.11.4-21.13-default #1 Mon Jul 17 09:21:59 UTC 2006 i686
i686 i386 GNU/Linux
Eclipse Europa 3.3 with MyEclipse 3.3 M1.
Using JSF RI 1.2:
INFO: Initializing Sun's JavaServer Faces implementation (1.2_04-b16-p02) for
context '/trinidaddemo'
Reporter: Gregg Leichtman
Assignee: Adam Winer
Fix For: 1.0.3-core
I have found a bug in the generated JavaScript for the Select*Shuttle
components. A patch follows:
TrShuttleProxy._getDescArray = function(listName) {
// var descArray = window[listName.replace(':','_') + '_desc'];
var descArray = window[listName.replace(/:/g,'_') + '_desc']; // gsl fix
return descArray;
}
where listName is content:shuttle1:leading.
The problem is that the listName is not using a global replace; therefore
only the first ':' is being replaced. This worked fine in ADF Faces before
porting to Trinidad where the listName was just shuttle1:leading. Note,
however, that Trinidad now adds an additional content prefix to the
generated inline JavaScript variables:
content_shuttle1_leading_desc=new Array('The First Item Desc',
'The Second Item Desc',
'The Third Item Desc','');
content_shuttle1_trailing_desc=new Array('');
This means that a global replace needs to be done to create the proper
variable name for matching in the JavaScript code. I will report this on Jira
for the Trinidad project.
I don't have access to the latest snapshots. The last one I see is from July
11th at:
http://people.apache.org/repo/m2-snapshot-repository/org/apache/myfaces/trinidad/trinidad-impl/1.2.1-SNAPSHOT/
If this has been fixed already, then please clear my bug report which should
have the side benefit of letting people know that the bug has been found and
fixed already.
-= Gregg =-
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [Trinidad] Components provided by issues 663 and 664 - overview and chance to vote
On 9/8/07, Andrew Robinson [EMAIL PROTECTED] wrote: If #1 was decided on, it would be good to have clear documentation on the how to initiate the submit from one of those components as well. TrPage.getInstance().sendPartialFormPost may be enough, but maybe additional standard form parameters could be supported in that method call (like, (1) is supporting the ability to skip the update phase a good idea?, (2) ability to only send the value from this component -- JavaScript initiated partial decode like the subform component does, etc.). I'd like to tackle both of these with a custom JSF 1.2 lifecycle, at which point, yes, we'd need to add some extra parameters. PS - Out of curiosity, why was it coded as TrPage.getInstance().sendPartialFormPost instead of TrPage.sendPartialFormPost (JavaScript singletons don't normally need an instance)? A good point - my brain's coded to think of Java coding styles. I don't see any reason to require the getInstance() here, which makes this call more cumbersome than it needs to be. -- Adam On 9/8/07, Adam Winer [EMAIL PROTECTED] wrote: For push triggering: what if we had a tag called pprTrigger, that worked like: someone:commandLink ... tr:pprTrigger event=action partialTargets=list of ids/ /someone:commandLink someone:inputText ... tr:pprTrigger event=valueChange partialTargets=list of ids/ /someone:inputText ... where we use a dynamic proxy to register, in the first case, an ActionListener, in the second case, a ValueChangeListener, etc. The point here is that it's not at all tied even to Trinidad (though, of course, whatever component it is must have been capable of initiating a PPR request), though it's perfectly usable and reasonable with Trinidad. It has a minor advantage over the partialTriggers attribute in that it is specific to one event type, and will not fire on just any event, which is an issue for complex components like table that can fire multiple events. Possibility #2, which is certainly simpler, is that we just add a partialTargets attribute to Trinidad components. It has the distinct disadvantage of being less fun to code up. :) -- Adam On 9/7/07, Andrew Robinson [EMAIL PROTECTED] wrote: - Trigger PPR from a parent when any child is a PPR trigger General agreement that this is valuable. - Trigger PPR when a message is queued for a component I want to rely on DHTML for this instead of PPR, at least for the Trinidad components. - Push triggering instead of pull (partialTargets instead of partialTriggers) Very interesting question, I'm toying with the idea of a tag that can be attached for any event. - Trigger PPR for a component on every request I dislike this, as you probably have surmised. :) Have I omitted an item from this list? For 663, and 664, this should be adequate, as long as DHTML is not the solution
Re: svn commit: r573765 - in /myfaces/trinidad-maven/trunk: ./ maven-faces-plugin/ maven-i18n-plugin/ maven-javacc-plugin/ maven-javascript-plugin/ maven-jdev-plugin/ maven-tagdoc-plugin/ maven-xrts-p
On this subject: I'm thinking my assumption that 1.0.3 was the right version number was off... I'll start a thread to see if this should be 1.2.3. -- Adam On 9/8/07, Wendy Smoak [EMAIL PROTECTED] wrote: On 9/7/07, Adam Winer [EMAIL PROTECTED] wrote: @Matthias, can you take care of the Continuum fix? Done. -- Wendy
[TRINIDAD] Maven Plugin version: 1.0.3 or 1.2.3
I've moved the Trinidad Maven Plugins to their own sub-repository. The codebase is really the 1.2 codeline. The question is, should the version number of the next release be: - 1.0.3 - 1.2.3 - Something else? I'd initially gone with 1.0.3, on the line of thought that we really were saying there never should have been a 1.2 line at all, since we could have always made sure there was only one line of plugins. Now I'm thinking that's bogus, and that we can't rewind history. :) So, there was a 1.2.2 release, and it's confusing to tell someone to downgrade from 1.2.2 to 1.0.3 - especially in the MyFaces 1.2 Core - so the version number should be 1.2.3. Thoughts? -- Adam
Re: [Trinidad] Components provided by issues 663 and 664
On 9/8/07, Andrew Robinson [EMAIL PROTECTED] wrote: Some quick responses inside On 9/8/07, Steven Murray [EMAIL PROTECTED] wrote: I have been watching this thread and I think this is an important topic. However I want to make the following comments. 1. Since the JSF specification has no input on AJAX and to me there are several viable AJAX frameworks, none of which really play well together, I don't buy the argument that Trinidad's AJAX implementation has to be separate from the Trinidad framework. The reason to make it separate was the idea to allow Tomahawk and its sandbox to use a common AJAX framework. It doesn't seem like the best solution to have a separate PPR for the tomahawk/sandbox project that makes tomahawk and sandbox incompatible from Trinidad. The schedule component is problem the most important Tomahawk component as no other component library has done anything remotely similar to it, and it is very robust in its feature set. Yep, totally agree. AJAX is the easiest way for two component frameworks to be incompatible; and the Trinidad architecture very intentionally is separated from the components - there's a core JS API and a fairly simple Java API as well that aren't tied to any of the components. 2. It is clear that Trinidad's approach is conceptually different than AJAX4JSF approach for JSF. Maybe this is good, both should learn from each other but keep true to their own concepts. Underlying Trinidad is an Oracle approach and underlying AJAX4JSF is a JBOSS/Exadel approach. The reality is that while both are open source each is controlled by a company with a particular vision or technology ownership. Until the JSF community decides on how AJAX and JSF *should* work together I don't see any reason for Trinidad to accomodate a different approach over the one it is using. I agree that a different approach is good, I just don't agree that the PPR functionality should be private to the inner workings of components. A few more components to expose this functionality for use in views without any coding necessary would be extremely helpful to users. 3. The argument that we are going to want to mix JSF component suites (plus maybe build a few custom ones) is desirable but at this early stage in JSF often impractical. I wonder why Andrew, who seems to be JBOSS centric, feels the need to be using Trinidad components. I am not JBoss centric, I just use the best tools for the job. JBoss-Seam has no competition in the JSF space with its functionality offerings. Trinidad components are the best components for the job. Seam has components, but it isn't a component library, Trinidad has some back-end functionality, but is a component library, they should work together. I have used A4J in the past and its AJAX based components provide a lot of required functionality that isn't provided by Trinidad, so is necessary to have to write custom components to expose these capabilities. Indeed, I would hope that JBoss users would have no reason not to use Trinidad. I suspect it is because overall Trinidad has the most comprehensive set of components available and he is sprinkling in one or two other components from various other suites for special needs. I am using other component libraries, MyFaces Tomahawk included, but the only one I am using with built-in AJAX support is Trinidad. If you feel that developers can only one component suite, you must never have built a JSF based web site for a large project. Have you? My recommendation to most JSF developers is to stick with a single suite because mixing and matching suites that have significant AJAX capabilities is difficult if not impossible. If you were tracking this thread carefully, you would have seen that that was my assessment. There are other non-AJAX component libraries out there that should work (like the JBoss-Seam components -- their AJAX is a JavaScript function invocation framework, not a PPR framework, so the two don't conflict). The best component suite is the one in which you don't need HTML supplementation or have to write custom components. There is no such thing, and never will be. That is the same as saying that Swing components provide all the functionality ever needed by all companies of the world and no one should ever have to write a Swing component again. Very true. 4. I have voiced this before but I am concerned with Trinidad being a subproject of MyFaces (not Apache) because I can never figure out if MyFaces is about a reference implementation, components (Tomahawk, Tobago, Trinidad none of which really play well together), or add-on features (Orchestra). Then we have Sun over there in java.net doing their own thing with Dynafaces etc. Trinidad should be project level. Why shouldn't Tomahawk and Trinidad play well together? I know why Tobago doesn't because if its architecture,
Re: [Trinidad] Components provided by issues 663 and 664 - overview and chance to vote
On 9/7/07, Andrew Robinson [EMAIL PROTECTED] wrote: ...I'd be vastly less concerned about seeing such a component appear in a generic MyFaces PPR/AJAX library, when we get around to that... What about a slow start? Could be a tag namespace of: xmlns:tra=http://myfaces.apache.org/trinidad/ajax; or xmlns:trp=http://myfaces.apache.org/trinidad/ppr; If the goal is to create a new PPR library, we should just start there: xmlns:ppr=http://myfaces.apache.org/ppr; ... instead of creating trinidad components, then deleting them. We could try creating a new top-level library (perhaps in SVN at something like: http://svn.apache.org/repos/asf/myfaces/sandbox/ppr ... where the initial implementation is entirely dependent on Trinidad, we get the generic APIs we want in place, then we look at refactoring Trinidad and the PPR library to reverse the dependency order, and move this ppr thing out of the generic MyFaces sandbox. A lot of those details definitely would need to be discussed with the greater MyFaces community, and we'd certainly want to make sure some committers who concentrate on Tomahawk are actively involved in its development - there's zero point in heading down this road if we don't have everyone on board with making this a core dependency of both Trinidad and Tomahawk. -- Adam then any components written that are not HTML in nature, but are simply PPR-AJAX related would be in this namespace. That way, if Trinidad's PPR functionality is extracted into its own library, these components could move with it to a new namespace? It provides a half-way point where there is functionality not specifically for Trinidad's HTML oriented components, and keeping them separate from the core components. This way there is a clear separation of functionality and goals?
Re: [Trinidad] Components provided by issues 663 and 664 - overview and chance to vote
For push triggering: what if we had a tag called pprTrigger, that worked like: someone:commandLink ... tr:pprTrigger event=action partialTargets=list of ids/ /someone:commandLink someone:inputText ... tr:pprTrigger event=valueChange partialTargets=list of ids/ /someone:inputText ... where we use a dynamic proxy to register, in the first case, an ActionListener, in the second case, a ValueChangeListener, etc. The point here is that it's not at all tied even to Trinidad (though, of course, whatever component it is must have been capable of initiating a PPR request), though it's perfectly usable and reasonable with Trinidad. It has a minor advantage over the partialTriggers attribute in that it is specific to one event type, and will not fire on just any event, which is an issue for complex components like table that can fire multiple events. Possibility #2, which is certainly simpler, is that we just add a partialTargets attribute to Trinidad components. It has the distinct disadvantage of being less fun to code up. :) -- Adam On 9/7/07, Andrew Robinson [EMAIL PROTECTED] wrote: - Trigger PPR from a parent when any child is a PPR trigger General agreement that this is valuable. - Trigger PPR when a message is queued for a component I want to rely on DHTML for this instead of PPR, at least for the Trinidad components. - Push triggering instead of pull (partialTargets instead of partialTriggers) Very interesting question, I'm toying with the idea of a tag that can be attached for any event. - Trigger PPR for a component on every request I dislike this, as you probably have surmised. :) Have I omitted an item from this list? For 663, and 664, this should be adequate, as long as DHTML is not the solution
Re: [TRINIDAD] Maven Plugin version: 1.0.3 or 1.2.3
Yeah, that thought occurred... I'm not too worried that it's the same number as JSF 2.0, but I do think it implies that we've made major changes since 1.2.2, which definitely isn't the case! I like saving major number changes for releases that break backwards compatibility. -- Adam On 9/8/07, Andrew Robinson [EMAIL PROTECTED] wrote: 2.0.0? 2.x saying that it is the 2nd major release of this tool, not that it has anything to do with JSF 2.0. If it is indeed JSF version independent, shouldn't matter that it gets away from 1.2.x. On 9/8/07, Adam Winer [EMAIL PROTECTED] wrote: I've moved the Trinidad Maven Plugins to their own sub-repository. The codebase is really the 1.2 codeline. The question is, should the version number of the next release be: - 1.0.3 - 1.2.3 - Something else? I'd initially gone with 1.0.3, on the line of thought that we really were saying there never should have been a 1.2 line at all, since we could have always made sure there was only one line of plugins. Now I'm thinking that's bogus, and that we can't rewind history. :) So, there was a 1.2.2 release, and it's confusing to tell someone to downgrade from 1.2.2 to 1.0.3 - especially in the MyFaces 1.2 Core - so the version number should be 1.2.3. Thoughts? -- Adam
[TRINIDAD] Rearranging plugins subversion structure
All, As per earlier discussion, I'm going to rearrange the Trinidad SVN structure to re-unify the 1.2 and 1.1 plugins, and run all the main Trinidad code against the 1.2 code-line of plugins. What the repos will look like when I'm done is: myfaces /trinidad /trunk pom.xml /trinidad-api /trinidad-impl (etc...) /branches ... etc ... /tags /trinidad-maven /trunk pom.xml /maven-faces-plugin (etc...) /branches I'm not in love with /trinidad-maven, and am eager for better suggestions. It was suggested that some or all of our plugins should end up in myfaces/maven, and I agree that should be the eventual end goal, but I'd like to get this rearrangement done now since it makes our release life sooo much better. While I'm at it, I'll move all of the maven-plugin-parent tags out of trinidad/tags and over to trinidad-maven/tags. @Matthias: this is going to break our nightly builds. Are you OK fixing that up? I've not yet acquired an account on the new build machine, otherwise I'd do this myself. -- Adam
Re: [Trinidad] Components provided by issues 663 and 664 - overview and chance to vote
On 9/7/07, Andrew Robinson [EMAIL PROTECTED] wrote:
seam:decorate id=decorateUsername
tr:inputText id=username required=true styleClass=#{invalid ?
'error' : ''}
value=#{ user.username}
seam:validate /
/tr:inputText
/seam:decorate
tr:partialRendered for=decorateUsername partialTriggers=saveTrigger
/
tr:partialTrigger id=saveTrigger immediate=true
tr:commandLink partialSubmit=true text=Save /
/tr:partialTrigger
The seam:decorate needs to re-render on the validation error to ensure
that the text box is now rendered with the error CSS style class.
Simply supporting updating client-side messages only would not work
here.
This isn't a great example, because you wouldn't get that styling
with client-side validation (which, I know you've turned off,
but that is a minority view). The appropriate way to tackle
that requirement is to support full CSS styling of error components
(which, is in fact exactly what the Oracle rich client code does)
beyond just attaching messages and error icons.
I have been thinking more about this, and the more I do, the more your
response really bothers me. Your are justifying denying functionality
from users because of client-side validation not supporting it.
Client-side validation is a very limiting technology, bounded by
having to write and maintain JavaScript, and the industry has
definitely not shown that it should be the mainstream for internet
applications. Look at how very few sites on the internet use it, and
you will see that. If this was the way to go, GWT would be a much
better solution than JSF, with the argument that if you are going to
push validation to the client, you may as well push rendering to the
client.
I'm not saying client-side validation is the one true way to go,.
I'm saying that DHTML that can *insert messages on the client-side*
is the right way to go. We happen to have implemented exactly this
technology as part of our client-side validation layer, but there is
no necessary requirement at all that the validation actually happen
on the client-side in order for that code to function. (Today,
we don't render the placeholders for the messages unless client-side
validation is enabled, but that's 5 minutes of work to change.)
IMO, I think it's lame that so many server-side tools are failing
to grasp the value in generating client-side validation off of
server-side validation metadata. User responsiveness is a huge
gain for web applications.
-- Adam
For most users of JBoss-Seam, client-side validation will probably not
be used (I am one user who proves this to be a valid use case). I
don't feel that just Trinidad supports some client-side validation
that users should be limited to its functionality if they decide not
to use it.
With that said, my example is a perfect one and very valid. It just
isn't applicable to the entire user base. But that has never been a
good reason in a programming platform for not supporting it. I could
go on and on about features in programming languages that many users
will never use, but that is never a good reason that they shouldn't be
provided.
My use case is also very valid in a PDA or non-JavaScript environment.
My solution would work in both a desktop-AJAX environment and would
degrade with the same level of functionality in a PDA/non-JavaScript
environment. People supporting PDA sites really don't care what
javascript validation is available.
-Andrew
Re: [Trinidad] Components provided by issues 663 and 664 - overview and chance to vote
On 9/7/07, Andrew Robinson [EMAIL PROTECTED] wrote: Adam, To put it a little more politically correct, I think it is very important to have the PPR/AJAX function of Trinidad viewed as completely separate functionality from the Trinidad components. In the same way that decisions by RichFaces developers does not limit Ajax4JSF functionality, I don't feel that Trinidad components should limit Trinidad PPR functionality. What limitation of Trinidad components are limiting Trinidad PPR functionality overall, when you've conclusively proved that you can write components on top of the Trinidad PPR functionality that address your issues? Nothing discussed here is about whether PPR/AJAX core functionality in Trinidad needs enhancements. If a user must choose RichFaces+A4J, ICEFaces or Trinidad to get PPR functionality since the libraries really are not compatible, I think it is extremely important to ensure that the AJAX functionality that Trinidad uses should be as portable and feature rich as possible to allow users to integrate more than one library at a time (facelets and seam are examples of very popular frameworks that have components). I think this is also a very good reason why I proposed, and at the time you agreed, that the PPR/AJAX functionality should be extracted from Trinidad and made part of a MyFaces AJAX commons library. I still agree this is a good goal (though, BTW, the very specific issue of *what* constitutes a triggering activity is in fact exactly a component issue, and therefore does very much belong to Trinidad components!) With this in mind, I think the PPR functionality in Trinidad should be designed for all JSF development scenarios, and not just ones that only apply to Trinidad components. So when you said that it wasn't important that seam:validation, seam:validateAll and seam:decorate functionality should not be supported by Trinidad PPR, I said no such thing, nor would I ever. I'm sorry if you misunderstood. because Trinidad components would not benefit from that functionality just because most users that use Trinidad components, use client-side validation, it is almost like you are saying that users have to choose either 100% Trinidad components, or not to use Trinidad at all as the message that is coming across is that the Trinidad developers will not support functionality that doesn't apply to most of the Trinidad component use cases. This is not my message. I've never heard anyone give this message. The tr:partialTrigger component's functionality is primarily for usage with server-side validation, not JavaScript validation. It is very important to have this functionality for users that will be using 3rd party validators, and 3rd party components, as witnessed by the Seam components I just listed. Also, I have mentioned several times a use case of requiring server side validation for validation of database uniqueness of fields (like user name), but you have never responded to that, but instead keep going back to client-side validation. How do you propose to handle database-based JSF validators with PPR? NOT client-side validation. Client-side insertion of server-side messages. Heck, I work at Oracle - do you really think I don't believe in database-generated error messages? In summary, my point is that I believe tr:partialTrigger provides required functionality for a complete AJAX library. I also would like this project to invest some time and research into providing more robust AJAX support that is similar in nature to some of the A4J functionality (like the A4J support component's attributes in particular). If we could get to more of a model of: MyFaces AJAX - used by: - Trinidad components - Oracle rich client - Tomahawk - Sandbox - Tobago? I think that a MyFaces custom component solution will become a lot more appealing to people wishing to build a new JSF project. There has been a lot of evidence that users do not feel that the PPR in Trinidad is on the same playing field as A4J. Adding the missing functionality, and making Trinidad's PPR functionality usable by all component frameworks that wish to use it would go a very long way to making Trinidad more ubiquitous. I've never said 100% no to this functionality. I've said 100% no to adding it in without discussion, and I'm pushing back on specific parts of it that just don't seem to add up, especially where they concern Trinidad components. -- Adam
Re: [Trinidad] Components provided by issues 663 and 664 - overview and chance to vote
On 9/7/07, Martin Marinschek [EMAIL PROTECTED] wrote: renderAlways: If you use renderAlways internally for the trinidad messages (even though you call it a hack now), Andrew is definitely right when he says he might want to use other message components as well and needs the same functionality there. I want to get rid of that hack on messages; we have the underlying technology to do so. ok, from your later answers to Andrew I understand now how you want to do this - je suis d'accord, sounds like a very good solution. This won't help Andrew again, if he doesn't use Trinidad messaging. Yeah, true, but it doesn't seem like adding a Trinidad component because people aren't willing to use the Trinidad tr:message component is pushing things. I'd be vastly less concerned about seeing such a component appear in a generic MyFaces PPR/AJAX library, when we get around to that, 'cause then things are eminently balanced - the base library has a lot of primitives, individual consumers (like Trinidad) can make those primitives unnecessary. This is a lot like how I imagine things will be with ICEFaces in JSF 2.0, FWIW - core AJAX primitives that ICEFaces makes unnecessary 'cause of its cool diffing approach. Couldn't Andrew queue the message region in a phase-listener using the renderContext as a partial region, bingo, he wouldn't need his custom component anymore? Yes, as long as this isn't a really common requirement that hits most developers, at which point the phase listener becomes a bit of a pain. You can't force him to use Trinidad-components only, and we all should make sure we don't do so. I'm underwhelmed by claims that this is solely Trinidad's fault; it's not as if A4J's PPR solution doesn't break Trinidad in some major ways! And Trinidad's general solutions are in fact *really, really good* at supporting third-party components - any component can be added as a partial target as long as it follows some trivial and reasonable JSF guidelines (basically appropriate use of ResponseWriter). I think my suggestion above might help. Yep. You might also be able to provide this functionality in a partial life-cycle setting, too - if you can rerender the triggered components, why can't you render a list of always triggered components as well? It might be more work to find a solution for this, though. You'd have to find such components, which would generally involve a full walk of the tree, unless you'd pre-gathered them on the prior render, which is quite a hack. and again, see above - if he manually queues it, nobody has to list the components. Yep, though it lacks the prettiness of something more automatic. By the way: it should be easy to visit the tree in JSF, then this wouldn't be so much of a hack, only costing a bit performance. I've added an issue on this to the spec issue tracker an age ago, we have to fix this for 2.0. I'd love easier APIs for tree-walking; but a full tree walk is always going to be potentially expensive, since walking into components like tables can trigger model queries. We also have some components inside Oracle called regions (little sub-applications within pages) that you'd have to walk into, and those aren't cheap. Not saying that we *don't* want these APIs, but we have to be really careful about how they designed. For instance, I suspect we'd want to make it easy to allow multiple requests for tree walking to be aggregated into a single walk. partialTriggerering by parent component id: I believe this might help users who find it overly complicated to write an action/actionListener/valueChangeListener to queue a list of regions for partial re-rendering using the render-context, as they currently would have to do as a work-around. I also think it would make the Trinidad PPR approach generally more flexible. I agree there's some value, but I'm trying to boil this all down to *exactly* the functionality required, as it's felt to me like at least 50% of what's asked for here is not the right way to go. Once we know exactly what is really, truly the right set of functionality to add, then we can design how it best belongs. the parent thing is still interesting for me - I wonder if this would require a new component, or if we could eventually use special syntax in partialTriggers=id/* or so? A special syntax would be very worth considering. The parent-of-unknown-contents is the one I'm most convinced deserves a solution. generic UIXPartialRendered/UIXPartialTrigger: the most used PPR library currently out there is AJAX4JSF - AJAX4JSF uses this paradigm. I wonder why you are so much against using a similar concept in Trinidad. Andrew is absolutely right, it would help a lot to convince people to use Trinidad PPR fully, also with other components, and wouldn't cost much, also not in maintenance. For the UIXPartialRendered, you could surely win
Re: svn commit: r573765 - in /myfaces/trinidad-maven/trunk: ./ maven-faces-plugin/ maven-i18n-plugin/ maven-javacc-plugin/ maven-javascript-plugin/ maven-jdev-plugin/ maven-tagdoc-plugin/ maven-xrts-p
@Matthias, can you take care of the Continuum fix? Wendy, the version went backwards because we used to have two forks - 1.0.x and 1.2.x. Both were at 1.y.2 - so we had 1.0.2 and 1.2.2. I realized that the 1.2 branch was actually kinda pointless, and that we only needed one branch. It made more sense to call that next release 1.0.3 than 1.2.3. But - the codeline actually was from the old 1.2 branch. So, wacky, but intentional. -- Adam On 9/7/07, Wendy Smoak [EMAIL PROTECTED] wrote: On 9/7/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Author: awiner Date: Fri Sep 7 17:47:54 2007 New Revision: 573765 URL: http://svn.apache.org/viewvc?rev=573765view=rev Log: Update version number and SCM info These need to be deleted and re-added in Continuum, it's trying to 'svn up' the old location. http://vmbuild.apache.org/continuum/groupSummary.action Why did the version number go backwards? -- Wendy
Re: [Trinidad] Components provided by issues 663 and 664 - overview and chance to vote
On 9/5/07, Andrew Robinson [EMAIL PROTECTED] wrote:
That's not a concrete example. What UI functionality are you
trying to achieve that you cannot achieve today?
Example for using immediate = true for a partial trigger (also shows
usage of the partialRendered component)
seam:decorate id=decorateUsername
tr:inputText id=username required=true styleClass=#{invalid ?
'error' : ''}
value=#{user.username}
seam:validate /
/tr:inputText
/seam:decorate
tr:partialRendered for=decorateUsername partialTriggers=saveTrigger
/
tr:partialTrigger id=saveTrigger immediate=true
tr:commandLink partialSubmit=true text=Save /
/tr:partialTrigger
The seam:decorate needs to re-render on the validation error to ensure
that the text box is now rendered with the error CSS style class.
Simply supporting updating client-side messages only would not work
here.
This isn't a great example, because you wouldn't get that styling
with client-side validation (which, I know you've turned off,
but that is a minority view). The appropriate way to tackle
that requirement is to support full CSS styling of error components
(which, is in fact exactly what the Oracle rich client code does)
beyond just attaching messages and error icons.
664: ...
I am using the alwaysRendered=true like this:
h:panelGroup id=messagesPane
tr:partialRendered alwaysRendered=true /
ts:roundedDiv
id=messagesTableContainer
borderWidth=0
radius=5
borderColor=#{roundedCornerColorLight}
rendered=#{cf:hasGlobalMessages()}
color=#{roundedCornerColorLight}
layout=table
tr:panelPopup triggerType=hover
f:facet name=trigger
tr:outputText value=#{messages.messages_present}
styleClass=messagesTitle
messagesLevel#{facesContext.maximumSeverity} /
/f:facet
tr:panelBox
id=messagesBox
background=light
tr:panelHeader
text=#{messages.messages_title} /
t:messages
styleClass=messages
globalOnly=true
infoClass=messagesLevelInfo
warnClass=messagesLevelWarn
errorClass=messagesLevelError
fatalClass=messagesLevelFatal
layout=list /
/tr:panelBox
/tr:panelPopup
/ts:roundedDiv
/h:panelGroup
Since my messages component is actually inside of a popup dialog, I
need it to be always rendered, since only re-rendering just the
messages component is not enough.
Also, I am using the Tomahawk messages component as it has more
rendering flexibility than the Trinidad one (I already submitted a
wish JIRA to get similar capabilities for style classes on each
message).
Without the alwaysRendered=true, I would have to hard code a
component or phase listener to do this programmatically, but it was
much easier to user a re-usable component that can do this for me.
I don't buy this as a sufficiently strong reason to add alwaysRendered,
given how I think that it will break when we functionality that I consider
absolutely critical for addition in JSF 1.2 - we have to stop requiring
decode()
and encodeXYZ() be called on every component on every AJAX request.
Could you move the code for these two components over
to a branch and out of trunk?
If you still don't see the need after this email sure. If so, should
it be a generic 1.0.3 sandbox for everyone, or should the branch be
more personal. Example SVN URL would be helpful, to make sure I don't
clutter up SVN in a way that isn't viewed as the most appropriate.
A sandbox would be great, but we don't have one set up.
A branch would go somewhere like:
http://svn.apache.org/repos/asf/myfaces/trinidad/branches/arobinson-ppr-components
-- Adam
Re: [Trinidad] Components provided by issues 663 and 664 - overview and chance to vote
On 9/4/07, Andrew Robinson [EMAIL PROTECTED] wrote:
663
I'd really like to hear a concrete example of where this is absolutely
necessary. This is a very abstract description that is mostly
I need functionality X because I need to do X, which is a tautology.
It's also very difficult for me to judge why this component needs
to support immediate at all (should it always be immediate=true?).
tr:partialTrigger partialTargets=myLink / In this case, the user
may not want to partially update myLink unless there phase of the
event being queued is fired.
If this were to always be immediate, the argument could be made that
all partialTriggers should applied immediately.
That's not a concrete example. What UI functionality are you
trying to achieve that you cannot achieve today?
In addition to the immediate flag, it also provides two other helpful
functions:
Are you aware that partialTriggers is recursive? So that you could
have:
af:group id=pprGroup partialTriggers=menuItem1 menuItem2
menuItem3/
af:outputText partialTriggers=pprGroup/
IMO, this makes this sub-feature unnecessary.
Yes I am aware of this feature, but with the combination of the
partialTargets and immediate functionality that is provided that the
tr:group component, and other Trinidad components lack. The usefulness
of the tr:partialTrigger component can be seen for this reason. So
yes, this sub-feature is implied by Trinidad components, but it is one
I felt worth mentioning.
It's not a specific benefit of this component is my point; the
framework already has this feature. It does point out that
we should document this (the PPR documentation doesn't
currently describe it.)
2) ...
This is an interesting use case, but couldn't you just expose
a partialTriggers attribute on the facelets template and let the
template support this?
That would be true only for very simplistic facelets applications. It
is very common to have facelets including facelets including other
facelets and so forth. This makes the ability to use a facelets
parameter unusable in all use cases. For example:
A.xhtml;
html
tr:myComponent id=updateMe partialTriggers=#{partialTriggers} /
/html
B.xhtml:
ui:composition
ui:decorate src=/A.xhtml
ui:param name=partialTriggers value=blah /
/ui:decorate
ui:include src=/C.xhtml
/ui:include
/ui:composition
C.xhtml:
ui:composition
tr:commandLink id=myLink partialSubmit=true /
/ui:composition
Now in this example, I would have to know in B that I should add
myLink to the partialTriggers argument. If I am writing more complex
code than the above example I may have to be aware of tens of
components in various include files that should all be updating the
updateMe component. It is much more maintainable to have the
myLink update the updateMe instead of having to know all the
components that should update updateMe in the including view. This
use case could easily arise from page headers, page footers, common
components on web pages, like help sections (like a
contents/index/search type of help component).
I am not saying that this would be the main use case for updating
components, I do feel that partialTriggers should be used when it
makes sense, but that doesn't mean there are not uses cases that make
partialTargets functionality better and more easily maintainable in a
large project in certain situations.
OK, so we can scope out that specific sub-issue as something
worth solving.
664: ...
BTW, looking at the code, there's also in alwaysRendered flag
that we should talk about. I'm uncomfortable with adding it to
this, and only this component, and similarly uncomfortable with
adding this to all components. In a complex application, it seems
undesirable that you'd always re-render any specific component,
since you don't know all reasons why there might be a postback
(someone adds a poll, or an autoSubmit, and now you're repainting
unnecessarily). There are workarounds for any odd scenarios where
this really is absolutely needed (e.g. f:phaseListener and binding
in JSF 1.2).
You already have alwaysRendered functionality in Trinidad, it is just
not exposed, the tr:messages is always rendered / updated. Who is to
say that users may very well have a very good reason why they may need
alwaysRendered set to true.
The rationale for adding a feature like this has to be better
than why not?! You need to argue convincingly that users
frequently have a very good reason, not ask me to prove that
no user will ever need it.
Since alwaysRendered supports EL
expressions, it doesn't have to be true/false, it can be a function or
other EL piece of code that would be smart enough to know not to
render for a poll response for example.
The tr:messages thing was a hack, basically as a half-hearted
workaround for all the issues in getting error messages displayed
One reason I *really* don't want
Re: [TRINIDAD] onchange event registration
The really important APIs here are _validateInput()
and _submitPartialChange(). The former is an interesting
one to make public; the latter's really mostly just a cover
for an already-public AdfPage API. This function itself
includes details (like the autosub parameter) that are
specific to internal Trinidad renderers.
-- Adam
On 9/5/07, Danny Robinson [EMAIL PROTECTED] wrote:
Mainly because it's not an independently callable method, it requires
validation to be correctly configured behind the scenes. We could consider
something similar as a public api though.
On 9/5/07, Andrew Robinson [EMAIL PROTECTED] wrote:
Out of curiosity, why is TrPage._autoSubmit named with an underscore,
shouldn't it be exposed as an API method? I would think people may
want to call it if they want to submit their own component using an
event other than the default one for the control.
On 9/5/07, Danny Robinson [EMAIL PROTECTED] wrote:
OK, so this seems to work for me. No scriptlet required, and less
parameters.
input id=_id22 class=af_inputText_content type=text size =5
onchange=TrPage._autoSubmit('_id22',event,1);return true;
name=_id22/
TrPage._autoSubmit = function(inputId, event, validate)
{
if (_agent.isIE)
{
// in many forms there is a hidden field named event
// Sometimes IE gets confused and sends us that instead of
// the true event, so...
if (event[type] == hidden)
event = window.event;
}
var target = event.target || event.srcElement;
if (!target)
return;
var form = _getForm(target);
if (!form)
return;
// Assume input is valid
var isValid = true;
// Validate the current input
if (validate)
isValid = _validateInput(event);
if (isValid)
{
var params = new Object();
params.event = autosub;
params.source = inputId;
_submitPartialChange(form.id, validate, params);
}
}
On 9/4/07, Adam Winer [EMAIL PROTECTED] wrote:
On 9/4/07, Danny Robinson [EMAIL PROTECTED] wrote:
I think that autoSubmit code should automatically call
_validateInput
on its own - that is, we probably need a new JS method that
will:
- run _validateInput() on the target field
- run the equivalent of the existing adfspu code
Maybe TrPage._autoSubmit()?
... and refactor the AutoSubmitUtils class to call this method
instead?
Yep.
BTW, I think we should start making a habit of putting variables
like _TrEventBasedValidation on the TrPage object - even
without a JS API, just using the JS object itself as a way to
stash variables without polluting the top-level namespace.
And I know this is a clear case of throwing stones and living in
glass houses, as it were. :)
Agreed, it wasn't permanent, just there to allow enable/disable
of the
feature while it evolves. Will move anything similar to TrPage in
future.
Cool, makes total sense.
-- Adam
-- Adam
On 9/4/07, Danny Robinson [EMAIL PROTECTED] wrote:
pinging for responses.
On 8/29/07, Danny Robinson [EMAIL PROTECTED] wrote:
Folks,
Need some pointers here. I've mainly got the event based
c/s
validation
working fine. However, this morning we uncovered an issue
that
needs
some
of your feedback. Basically, we're registering the
_validateInput(event)
method against onchange programmatically from within the
_addValidators()
method (which I think is the direction we want to take for
event
registration). Note - you can try this out by inserting
_TrEventBasedValidation=true; into a script at the top of your
page.
This works just great, until you use autoSubmit=true,
which
causes
the
SimpleInputTextRenderer (and others) to render the autoSubmit
script
via
onchange=_adfspu(...);return true;. This obviously fires
the
autoSubmit
code prior to the _validateInput and hence causes the
server-side
validators
to be used.
So, does anyone have a suggested workaround to this? Should
autoSubmit=true render the _adfspu() call differently, if so
how
could
we
ensure validators registered prior to autoSubmit event
handlers?
Thanks,
Danny
--
Chordiant Software Inc.
www.chordiant.com
--
Chordiant Software Inc.
www.chordiant.com
--
Chordiant Software Inc.
www.chordiant.com
--
Chordiant Software Inc.
www.chordiant.com
--
Chordiant Software Inc.
www.chordiant.com
[jira] Commented: (TRINIDAD-348) binding in treeTable column cause error
[
https://issues.apache.org/jira/browse/TRINIDAD-348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12525280
]
Adam Winer commented on TRINIDAD-348:
-
I'd recommend taking this to the e-mail list first to see if we really have a
bug.
binding in treeTable column cause error
---
Key: TRINIDAD-348
URL: https://issues.apache.org/jira/browse/TRINIDAD-348
Project: MyFaces Trinidad
Issue Type: Bug
Components: Components
Affects Versions: 1.0.1-incubating-core-SNAPSHOT
Environment: JBOSS 4.0.5 or Bea Weblogic 8.3 SP6
Reporter: Kamil Helman
I've got such code:
tr:document 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:tr=http://myfaces.apache.org/trinidad;
xmlns:trh=http://myfaces.apache.org/trinidad/html;
title=Facelets
tr:form
tr:treeTable value=#{fasolek.value} var=node
rowSelection=single
f:facet name=nodeStamp
tr:column
tr:outputText value=#{node.name}/
/tr:column
/f:facet
tr:column
tr:inputText value=#{node.name} binding=#{node.uiComponenet}/
/tr:column
/tr:treeTable
/tr:form
/tr:document
which gives me such error:
javax.faces.el.PropertyNotFoundException: /test.xhtml @17,72
binding=#{node.uiComponenet}: Target Unreachable, identifier 'node'
resolved to null
com.sun.facelets.el.LegacyValueBinding.setValue(LegacyValueBinding.java:72)
org.apache.myfaces.application.ApplicationImpl.createComponent(ApplicationImpl.java:449)
com.sun.facelets.tag.jsf.ComponentHandler.createComponent(ComponentHandler.java:218)
com.sun.facelets.tag.jsf.ComponentHandler.apply(ComponentHandler.java:135)
com.sun.facelets.tag.jsf.ComponentHandler.applyNextHandler(ComponentHandler.java:295)
com.sun.facelets.tag.jsf.ComponentHandler.apply(ComponentHandler.java:165)
com.sun.facelets.tag.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:47)
com.sun.facelets.tag.jsf.ComponentHandler.applyNextHandler(ComponentHandler.java:295)
com.sun.facelets.tag.jsf.ComponentHandler.apply(ComponentHandler.java:165)
com.sun.facelets.tag.jsf.ComponentHandler.applyNextHandler(ComponentHandler.java:295)
com.sun.facelets.tag.jsf.ComponentHandler.apply(ComponentHandler.java:165)
com.sun.facelets.tag.jsf.ComponentHandler.applyNextHandler(ComponentHandler.java:295)
com.sun.facelets.tag.jsf.ComponentHandler.apply(ComponentHandler.java:165)
com.sun.facelets.compiler.NamespaceHandler.apply(NamespaceHandler.java:49)
com.sun.facelets.compiler.EncodingHandler.apply(EncodingHandler.java:25)
com.sun.facelets.impl.DefaultFacelet.apply(DefaultFacelet.java:95)
com.sun.facelets.FaceletViewHandler.buildView(FaceletViewHandler.java:510)
com.sun.facelets.FaceletViewHandler.renderView(FaceletViewHandler.java:553)
org.apache.myfaces.trinidadinternal.application.ViewHandlerImpl.renderView(ViewHandlerImpl.java:178)
org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:384)
javax.faces.webapp.FacesServlet.service(FacesServlet.java:138)
org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl._invokeDoFilter(TrinidadFilterImpl.java:327)
org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl._doFilterImpl(TrinidadFilterImpl.java:291)
org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl.doFilter(TrinidadFilterImpl.java:214)
org.apache.myfaces.trinidad.webapp.TrinidadFilter.doFilter(TrinidadFilter.java:90)
org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
...
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (TRINIDAD-348) binding in treeTable column cause error
[
https://issues.apache.org/jira/browse/TRINIDAD-348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adam Winer resolved TRINIDAD-348.
-
Resolution: Invalid
This is not a bug. binding is set when components are created.
var is set when components are executed.
But what you're trying to do is more fundamentally wrong: there is only one
tr:inputText created here, not one per node. That same instance is stamped out
for every node. So binding to the var cannot possibly work.
binding in treeTable column cause error
---
Key: TRINIDAD-348
URL: https://issues.apache.org/jira/browse/TRINIDAD-348
Project: MyFaces Trinidad
Issue Type: Bug
Components: Components
Affects Versions: 1.0.1-incubating-core-SNAPSHOT
Environment: JBOSS 4.0.5 or Bea Weblogic 8.3 SP6
Reporter: Kamil Helman
I've got such code:
tr:document 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:tr=http://myfaces.apache.org/trinidad;
xmlns:trh=http://myfaces.apache.org/trinidad/html;
title=Facelets
tr:form
tr:treeTable value=#{fasolek.value} var=node
rowSelection=single
f:facet name=nodeStamp
tr:column
tr:outputText value=#{node.name}/
/tr:column
/f:facet
tr:column
tr:inputText value=#{node.name} binding=#{node.uiComponenet}/
/tr:column
/tr:treeTable
/tr:form
/tr:document
which gives me such error:
javax.faces.el.PropertyNotFoundException: /test.xhtml @17,72
binding=#{node.uiComponenet}: Target Unreachable, identifier 'node'
resolved to null
com.sun.facelets.el.LegacyValueBinding.setValue(LegacyValueBinding.java:72)
org.apache.myfaces.application.ApplicationImpl.createComponent(ApplicationImpl.java:449)
com.sun.facelets.tag.jsf.ComponentHandler.createComponent(ComponentHandler.java:218)
com.sun.facelets.tag.jsf.ComponentHandler.apply(ComponentHandler.java:135)
com.sun.facelets.tag.jsf.ComponentHandler.applyNextHandler(ComponentHandler.java:295)
com.sun.facelets.tag.jsf.ComponentHandler.apply(ComponentHandler.java:165)
com.sun.facelets.tag.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:47)
com.sun.facelets.tag.jsf.ComponentHandler.applyNextHandler(ComponentHandler.java:295)
com.sun.facelets.tag.jsf.ComponentHandler.apply(ComponentHandler.java:165)
com.sun.facelets.tag.jsf.ComponentHandler.applyNextHandler(ComponentHandler.java:295)
com.sun.facelets.tag.jsf.ComponentHandler.apply(ComponentHandler.java:165)
com.sun.facelets.tag.jsf.ComponentHandler.applyNextHandler(ComponentHandler.java:295)
com.sun.facelets.tag.jsf.ComponentHandler.apply(ComponentHandler.java:165)
com.sun.facelets.compiler.NamespaceHandler.apply(NamespaceHandler.java:49)
com.sun.facelets.compiler.EncodingHandler.apply(EncodingHandler.java:25)
com.sun.facelets.impl.DefaultFacelet.apply(DefaultFacelet.java:95)
com.sun.facelets.FaceletViewHandler.buildView(FaceletViewHandler.java:510)
com.sun.facelets.FaceletViewHandler.renderView(FaceletViewHandler.java:553)
org.apache.myfaces.trinidadinternal.application.ViewHandlerImpl.renderView(ViewHandlerImpl.java:178)
org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:384)
javax.faces.webapp.FacesServlet.service(FacesServlet.java:138)
org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl._invokeDoFilter(TrinidadFilterImpl.java:327)
org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl._doFilterImpl(TrinidadFilterImpl.java:291)
org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl.doFilter(TrinidadFilterImpl.java:214)
org.apache.myfaces.trinidad.webapp.TrinidadFilter.doFilter(TrinidadFilter.java:90)
org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
...
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [Trinidad] 2 questions (1) component generation? (2) bugs 663 and 664
On 9/3/07, Andrew Robinson [EMAIL PROTECTED] wrote: Guess I didn't leave adequate time. I took the lack of response in a days time to be no negative opinion. I can always move them back out and put them into jsf-comp as I know people will make use of them. That'd be great, thanks. Let me know of any procedures that are in place for any new component ideas. For starters, it's Labor Day weekend... For finishers, no comment is in fact a really good argument for *not* putting it in. If the idea seems good, people will pipe in with +1, sounds good. Broadly speaking, Trinidad is rather conservative w/regard to adding new components. This is a *good thing*. Saying no is one of the most important things that any open-source project can do to keep its focus. This is particularly important for a project like Trinidad where we make every possible effort to avoid any backwards-incompatible API changes going forward. That said, for component contributions we should: - Look for alternative implementations - can this be done some other way? - Review the name of the component and name of any new attributes - Make sure the community agrees it's generally useful Lack of consensus (much less lack of any comments) means don't put it in (yet). BTW, this also goes for new public APIs: adding an API to RequestContext with no public discussion isn't a great thing either. In the meantime, if you don't like them, I'd like to hear the opposition and the alternatives. I have yet to hear any suggestions for an adequate solution for supporting PPR re-rendering on command clicks that produce conversion and validation errors. As always, I am willing to hear alternatives. I've given you an alternative more than once! For starters, the idea that end users should need to add any component at all, or set a single attribute at all, just to get their server-side messages to show up is not good. The fact that they don't show up correctly today is *a bug*, and one that should get fixed. Supporting only client-side messages updates is not sufficient though to capture use cases that users will need. Message components cannot be assumed to be the only components that want to react to conversion and validation errors. That statement needs justification; and, if we fix server-side messages, then it is certainly the case that the benefit of these new components appears to be greatly reduced. -- Adam On 9/3/07, Adam Winer [EMAIL PROTECTED] wrote: I have to admit, I'm not at all convinced that either of these two new components should be added, and think there should have been more discussion before you'd checked them in. If we're going to have components added without general agreement, we need a sandbox where they can be tried out and played with. -- Adam On 8/30/07, Andrew Robinson [EMAIL PROTECTED] wrote: 2 questions for the Trinidad developers: (1) It seems like Trinidad is using some kind of generator for taglib, tld, Tag, and possibly other classes. Is this documented anywhere? I was looking around the SVN trunk and did not see any boilerplate or configuration code that would provide such information to a maven plugin. Can someone point me to the location in SVN that I can start poking around to get an understanding of how this works? (2) Are there any comments on the following enhancement bugs for new components? https://issues.apache.org/jira/browse/TRINIDAD-663 https://issues.apache.org/jira/browse/TRINIDAD-664 If not would there be any objections to me checking in the code into the Trinidad trunk (once I figure out the answer to #1 of course)? Thanks, Andrew
Re: [Trinidad] move RequestContextImpl._findRelativeComponent to public utility class
On 9/4/07, Andrew Robinson [EMAIL PROTECTED] wrote: I say that there was such a method in the RenderUtils. The method there does not support the :: syntax. It should... The function is not rendering specific, it can be used during even broadcasting, decoding and other phases as well. That is why I felt that it should be on ComponentUtils, since it is a method to help with finding components. Sure, ComponentUtils works fine. -- Adam On 9/3/07, Adam Winer [EMAIL PROTECTED] wrote: I'd add it to RenderUtils, which already has a getRelativeId() API. -- Adam On 8/30/07, Andrew Robinson [EMAIL PROTECTED] wrote: The method: static private UIComponent _findRelativeComponent( UIComponent from, String relativeId) on RequestContextImpl is a very handy method, any objections to making a JIRA issue to move this to a public class with static methods? Maybe a public static on RenderingContext? Or is there a better class? -Andrew
Re: Re: Re: [vote] release of Trinidad core (1.2.2)
On 9/4/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Hi, As soon as I get a bit of time ;) I will send you a testcase. But the setup should not be difficult to produce: Use Seam 2.0Beta and combine it with tr:table. Then do a bit of paging. Sooner or later, you get the error. That's actually a lot of setup. :) I'm very surprised that a ClassCastException here would be timing dependent or unpredictable. -- Adam Thanks, Wollfgang. Adam Winer [EMAIL PROTECTED] 04.09.2007 02:02 Bitte antworten an MyFaces Development dev@myfaces.apache.org An MyFaces Development dev@myfaces.apache.org Kopie Thema Re: Re: [vote] release of Trinidad core (1.2.2) Indeed, this is an issue (Ajax4JSF incompatibilities with Trinidad) that is present in 1.0.2, 1.0.2, and 1.2.1. It shouldn't block 1.2.2. I would really like to get a testcase for the class cast exception listed above. -- Adam On 9/3/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: Hello Wolfgang, is it possible, that the usage of Ajax4JSF is causing it ? -Matthias On 9/2/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Hi, My vote is (-1) because I replaced the 1.2.1 version in the lib of the protoype I am currently building and now apart from the attached message box I get in the log the following exceptions: 13:57:52,203 ERROR [STDERR] 02.09.2007 13:57:52 org.apache.myfaces.trinidadinternal.renderkit.core.CoreRenderKit createResponseWriter SCHWERWIEGEND: No RenderingContext has been created. 13:57:52,218 ERROR [STDERR] 02.09.2007 13:57:52 org.apache.myfaces.trinidadinternal.renderkit.core.CoreRenderKit createResponseWriter SCHWERWIEGEND: No RenderingContext has been created. 13:57:52,250 ERROR [STDERR] 02.09.2007 13:57:52 org.apache.myfaces.trinidadinternal.renderkit.core.CoreRenderKit createResponseWriter SCHWERWIEGEND: No RenderingContext has been created. 13:57:52,265 ERROR [STDERR] 02.09.2007 13:57:52 org.apache.myfaces.trinidadinternal.renderkit.core.CoreRenderKit createResponseWriter SCHWERWIEGEND: No RenderingContext has been created. 13:57:52,281 ERROR [STDERR] 02.09.2007 13:57:52 org.apache.myfaces.trinidadinternal.renderkit.core.CoreRenderKit createResponseWriter SCHWERWIEGEND: No RenderingContext has been created. 13:58:54,921 INFO [STDOUT] isQueryData() 13:59:07,265 WARN [lifecycle] org.apache.myfaces.trinidad.component.UIXCollection$Transient java.lang.ClassCastException: org.apache.myfaces.trinidad.component.UIXCollection$Transient at org.apache.myfaces.trinidad.component.StampState.restoreChildStampState(StampState.java:161) at org.apache.myfaces.trinidad.component.UIXTable.restoreStampState(UIXTable.java:359) at org.apache.myfaces.trinidad.component.UIXCollection._restoreStampState(UIXCollection.java:1264) at org.apache.myfaces.trinidad.component.UIXCollection.postRowDataChange(UIXCollection.java:743) at org.apache.myfaces.trinidad.component.UIXCollection.setRowKey(UIXCollection.java:424) at org.apache.myfaces.trinidad.component.UIXCollection.setClientRowKey(UIXCollection.java:653) at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.table.TableSelectManyRenderer._setDeltas(TableSelectManyRenderer.java:151) at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.table.TableSelectManyRenderer.decode(TableSelectManyRenderer.java:113) at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.TableRenderer.decodeSelection(TableRenderer.java:132) at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.TableRenderer.decode(TableRenderer.java:96) at org.apache.myfaces.trinidad.component.UIXComponentBase.__rendererDecode(UIXComponentBase.java:1074) at org.apache.myfaces.trinidad.component.UIXComponentBase.decode(UIXComponentBase.java:699) at org.apache.myfaces.trinidad.component.UIXCollection.processDecodes(UIXCollection.java:187) at javax.faces.component.UIForm.processDecodes(UIForm.java:203) at org.apache.myfaces.trinidad.component.UIXComponentBase.decodeChildrenImpl(UIXComponentBase.java:955) at org.apache.myfaces.trinidad.component.UIXComponentBase.decodeChildren(UIXComponentBase.java:941) at org.apache.myfaces.trinidad.component.UIXComponentBase.processDecodes(UIXComponentBase.java:797) at org.apache.myfaces.trinidad.component.UIXComponentBase.decodeChildrenImpl(UIXComponentBase.java:955) at org.apache.myfaces.trinidad.component.UIXComponentBase.decodeChildren(UIXComponentBase.java:941) at org.apache.myfaces.trinidad.component.UIXComponentBase.processDecodes
Re: [TRINIDAD] onchange event registration
I think that autoSubmit code should automatically call _validateInput on its own - that is, we probably need a new JS method that will: - run _validateInput() on the target field - run the equivalent of the existing adfspu code Maybe TrPage._autoSubmit()? BTW, I think we should start making a habit of putting variables like _TrEventBasedValidation on the TrPage object - even without a JS API, just using the JS object itself as a way to stash variables without polluting the top-level namespace. And I know this is a clear case of throwing stones and living in glass houses, as it were. :) -- Adam On 9/4/07, Danny Robinson [EMAIL PROTECTED] wrote: pinging for responses. On 8/29/07, Danny Robinson [EMAIL PROTECTED] wrote: Folks, Need some pointers here. I've mainly got the event based c/s validation working fine. However, this morning we uncovered an issue that needs some of your feedback. Basically, we're registering the _validateInput(event) method against onchange programmatically from within the _addValidators() method (which I think is the direction we want to take for event registration). Note - you can try this out by inserting _TrEventBasedValidation=true; into a script at the top of your page. This works just great, until you use autoSubmit=true, which causes the SimpleInputTextRenderer (and others) to render the autoSubmit script via onchange=_adfspu(...);return true;. This obviously fires the autoSubmit code prior to the _validateInput and hence causes the server-side validators to be used. So, does anyone have a suggested workaround to this? Should autoSubmit=true render the _adfspu() call differently, if so how could we ensure validators registered prior to autoSubmit event handlers? Thanks, Danny -- Chordiant Software Inc. www.chordiant.com -- Chordiant Software Inc. www.chordiant.com
Re: [Trinidad] Components provided by issues 663 and 664 - overview and chance to vote
Andrew, This is a bit overmuch - it isn't a thumbs-up/thumbs-down process, where we take it as is or leave it. It's a collaborative design process. We discuss, we hopefully come to consensus. Calling for a vote up front is unproductive. And there don't need to be fatal flaws, and we don't all need to have read the component's source code. We might just think that on the whole we're unhappy with the direction, or would like to be more conservative in adding functionality. Check out how Danny Robinson has been approaching his suggested component additions. More comments embedded. On 9/4/07, Andrew Robinson [EMAIL PROTECTED] wrote: Adam and the Trinidad developers, As for these two components, they are simply utility components to provide users more flexibility in the ways they wish to use the trinidad tools. Both of them do not affect the framework of Trinidad and are optional if people want to use them or not. That could be used to justify any component being added, and in itself is not a valid reason for adding it. Can you appreciate the advantage in going slow on component additions? (As requested by Adam, I'm giving all a chance to vote. Please vote below) 663: The UIXPartialTrigger component does exactly what Adam suggested in one of his responses to my email regarding the inability to partially render a component based on a trigger of a UIXCommand component, but never has a chance to broadcast that event due to a shortening of the JSF lifecycle. His suggestion was to make the FacesEvent immediate in nature so that the event will be broadcast earlier. This new component allows the component user to trigger partial rendering with immediate affect without changing the immediate property of the UIXCommand which would break code by JSF phases that are quite necessary for JSF programs to function correctly (the need for immediate on a command is a very specific use case and should not be over used). By implementing the queuing of its own event when a child component queues an event, users may choose to have parent components ignore the queuing of this event if they so desire. I'd really like to hear a concrete example of where this is absolutely necessary. This is a very abstract description that is mostly I need functionality X because I need to do X, which is a tautology. It's also very difficult for me to judge why this component needs to support immediate at all (should it always be immediate=true?). In addition to the immediate flag, it also provides two other helpful functions: 1) The ability to trigger off of one parent component. For example: I have a menu that I am building and I am using the tomahawk panelNavigation2 component. I am using this over the tr:panelNavigation because the Tomahawk one currently provides the extra functionality that I required (static children mingled with dynamic children and multiple level support). In this code, I have many t:commandNavigation2 components and some dynamic components. Now I could produce something like: tr:ouputText partialTriggers=menuItem1 menuItem2 menuItem3 ... / But this is problematic. For one, there is no way that I can designate the dynamic triggers that are rendered as I do not know their IDs, and two, I have to maintain this list in both places (every time I add a new menu item, I have to fix the partialTriggers all over every one of my pages that listen to the menu items), Are you aware that partialTriggers is recursive? So that you could have: af:group id=pprGroup partialTriggers=menuItem1 menuItem2 menuItem3/ af:outputText partialTriggers=pprGroup/ IMO, this makes this sub-feature unnecessary. This new component allows me to: tr:ouputText partialTriggers=menuItems / tr:partialTrigger id=menuItems ... any number of menu items here or other components that will fire events that should cause a partial trigger ... /tr:partialTrigger 2) The ability to specify a region to update from a component instead of having to specify listeners. Many, if not all the other AJAX libraries use this approach of a what to re-render when this is clicked type of functionality. If that isn't reason enough, I submit this use case of why it is desired as a component user: A user of facelets creates a template with a control. Since this template can be used from any other facelets page, there is no way for the author of the template to know the possible component IDs that may trigger it to be partially updated. On the other hand, the developers of the pages that use this template are in full knowledge of what components would need to force this template component to update. For this reason, this piece of functionality is required to have PPR usable in a complex view environment. This is an interesting use case, but couldn't you just expose a partialTriggers attribute on the facelets template and let the template support this? 664: The UIXPartialRendered gives people the
