[jira] Commented: (MYFACES-1467) Validation doesn't run for required fields if submitted value is null
[ http://issues.apache.org/jira/browse/MYFACES-1467?page=comments#action_12442373 ] Matthias Weßendorf commented on MYFACES-1467: - I pretty much think that the single value validation is a good thing. JSF is a spec not a product. so myfaces or ri can (not must) handle this different. At least it (single v. valid.) protcets you from bad bad hooks of the frameworks itself. at least you need to write a *framework* on top of faces for that yourself. (which only you (or a community) is in charge of it) Validation doesn't run for required fields if submitted value is null - Key: MYFACES-1467 URL: http://issues.apache.org/jira/browse/MYFACES-1467 Project: MyFaces Core Issue Type: Bug Components: General Affects Versions: 1.2.0-SNAPSHOT, 1.1.5-SNAPSHOT Reporter: David Chandler Assigned To: Matthias Weßendorf Attachments: patch.txt A component with a required value will not fail validation as expected if the submitted value is null. This issue is not seen normally because browsers send the value for an empty text field as an empty string. That is, the POST data for an empty field1 will contain the field name but no value, like field1=field2=something. However, if you use a man-in-the-middle proxy such as Paros to remove fieldname= from the POST data, the submitted value will be null. UIInput.validate() skips validation for null submitted values, but since requiredness is also part of validation, the requiredness check gets skipped, too. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: SaveState Issues
Yes Marting that's exactly the problem. After digging more, I've realized that we dont need to change anything in restoreState of the component because calling restoreAttachedState will simply return the value if it's not a special wrapped type.
public Object saveState(FacesContext context) { Object values[] = new Object[2]; values[0] = super.saveState(context); values[1] = getValue() instanceof StateHolder ? saveAttachedState(context, getValue()) : getValue();
return values; } public void restoreState(FacesContext context, Object state) { Object values[] = (Object[])state; super.restoreState(context, values[0]); Object value = restoreAttachedState(context,values[1]);
ValueBinding vb = getValueBinding(value); if (vb != null) { vb.setValue(context, value); } }This works good both with stateholders and lists, also the ugly part is removed since we dont need to tell the component to take special care during restoreState.
CagatayOn 10/15/06, Martin Marinschek [EMAIL PROTECTED] wrote:
The problem is that a list is internally not just serialized, butspecially treated (wrapped, and then on restore you have a differentlist than you had before - no good).And that's something that Cagatay understandably doesn't want
Cagatay, how about adding an additional parameter to the component (oncalling save-state) which tells the component on restore-state if itshould restore the value normally or via restoreAttachedState?
public Object saveState(FacesContext context){Object values[] = new Object[3];values[0] = super.saveState(context);boolean stateHolder = getValue() instanceof StateHolder;values[1] =stateHolder ? saveAttachedState(context,
getValue()) : getValue();values[2] =Boolean.valueOf(stateHolder);return values;}regards,MartinOn 10/15/06, Matthias Wessendorf
[EMAIL PROTECTED] wrote: Hi catagay, javax.faces.component._AttachedStateWrapper is pretty much myfaces_api isn't it? so shouldn't be used inside the savastate custom comp.
can you explain why it is failing? Thanks! On 10/14/06, Cagatay Civici [EMAIL PROTECTED] wrote: Hi,
I'd like to discuss the latest issues about the savestate component. In order to use the component with a value of type StateHolder, restoreAttachedState-saveAttachedState is used. But using
them fails with list implementations other than arraylists. See this one; See this one;
http://issues.apache.org/jira/browse/TOMAHAWK-738 It seems restoreAttachedState-saveAttachedState should only be used when the value is a stateholder, I've found an ugly solution to the
problem as; public Object saveState(FacesContext context) { Object values[] = new Object[2]; values[0] = super.saveState(context);
values[1] = getValue() instanceof StateHolder ? saveAttachedState(context, getValue()) : getValue(); return values; } public void restoreState(FacesContext context, Object state)
{ Object values[] = (Object[])state; super.restoreState(context, values[0]); Object value = values[1].getClass().getName().equals(
javax.faces.component._AttachedStateWrapper) ? restoreAttachedState(context,values[1]) : values[1]; ValueBinding vb = getValueBinding(value);
if (vb != null) { vb.setValue(context, value); } } Since _AttachedStateWrapper is private, I cant use instanceof, using class
name is the ugly part. Other than that it works fine with all cases. Any ideas about this? Cagatay
-- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf
mail: mwessendorf-at-gmail-dot-com--http://www.irian.atYour JSF powerhouse -JSF Consulting, Development andCourses in English and German
Professional Support for Apache MyFaces
[jira] Resolved: (TOMAHAWK-738) SaveState fails with a java.util.List implementation other than ArrayList
[ http://issues.apache.org/jira/browse/TOMAHAWK-738?page=all ]
Cagatay Civici resolved TOMAHAWK-738.
-
Resolution: Fixed
Now saveAttachedState is not used for non state holders
SaveState fails with a java.util.List implementation other than ArrayList
-
Key: TOMAHAWK-738
URL: http://issues.apache.org/jira/browse/TOMAHAWK-738
Project: MyFaces Tomahawk
Issue Type: Bug
Components: UISaveState
Affects Versions: 1.1.5-SNAPSHOT
Reporter: Cagatay Civici
Assigned To: Cagatay Civici
Fix For: 1.1.5-SNAPSHOT
restoreAttachedState of UIComponentBase wraps the lists as an ArrayList so
restoring values fails when a list implementation other than an arraylist is
used.
An example;
private LinkedList list;
private String name;
private String surname;
public LinkedList getList() {
list = new LinkedList();
list.add(name);
list.add(surname);
return list;
}
public void setList(LinkedList list) {
name = (String)list.get(0);
surname = (String)list.get(1);
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (TOBAGO-157) Resizing of browser window should result in recalculation of layout, even if the same view is rerendered
Resizing of browser window should result in recalculation of layout, even if the same view is rerendered Key: TOBAGO-157 URL: http://issues.apache.org/jira/browse/TOBAGO-157 Project: MyFaces Tobago Issue Type: Bug Components: Core Reporter: Volker Weber Assigned To: Volker Weber Priority: Minor Fix For: 1.0.9 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (TOBAGO-157) Resizing of browser window should result in recalculation of layout, even if the same view is rerendered
[ http://issues.apache.org/jira/browse/TOBAGO-157?page=all ] Volker Weber resolved TOBAGO-157. - Resolution: Fixed Resizing of browser window should result in recalculation of layout, even if the same view is rerendered Key: TOBAGO-157 URL: http://issues.apache.org/jira/browse/TOBAGO-157 Project: MyFaces Tobago Issue Type: Bug Components: Core Reporter: Volker Weber Assigned To: Volker Weber Priority: Minor Fix For: 1.0.9 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (TOMAHAWK-730) create a component which will submit a form on a specific event
[ http://issues.apache.org/jira/browse/TOMAHAWK-730?page=all ] Mario Ivankovits resolved TOMAHAWK-730. --- Fix Version/s: 1.1.5-SNAPSHOT Resolution: Fixed added to sandbox create a component which will submit a form on a specific event --- Key: TOMAHAWK-730 URL: http://issues.apache.org/jira/browse/TOMAHAWK-730 Project: MyFaces Tomahawk Issue Type: New Feature Reporter: Mario Ivankovits Assigned To: Mario Ivankovits Priority: Minor Fix For: 1.1.5-SNAPSHOT Proposal for this new component: A new component which aims to do whats described here [1] Component name: submitOnEvent It should operate in three modes: 1) as a child of an input* component (direct child) In this mode submitOnEvent will add a event handler to the input component and fires the button/link pointed to with for 2) standalone somewhere on the page In this mode submitOnEvent will intercept *all* events it is configured for and fires the button/link pointed to with for 3) as a child of a command* component (link or button) In this mode submitOnEvent will intercept *all* events it is configured for and fires the button/link it is embedded. It should handle buttons and links - links as described on [2] The proposed syntax is: s:submitOnEvent for=myButton event=keypress|focus|blur|change callback=any_user_js_function / event and callback should be optional. The default event should be keypress and for callback the default should be a method which will trigger on Enter. for should be optional if the component is embedded in a command* component. h:commandLink s:submitOnEvent/ /h:commandLink The component should *not* use dojo. [1] http://wiki.apache.org/myfaces/SubmitPageOnValueChange [2] http://wiki.apache.org/myfaces/JavascriptWithJavaServerFaces -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (TOMAHAWK-740) create a component which creates the JSF tree based on beans and its annotations
create a component which creates the JSF tree based on beans and its annotations Key: TOMAHAWK-740 URL: http://issues.apache.org/jira/browse/TOMAHAWK-740 Project: MyFaces Tomahawk Issue Type: New Feature Components: New Component Reporter: Mario Ivankovits Assigned To: Mario Ivankovits Priority: Minor The component I'll going to add to the sandbox is the GUI Builder stuff I developed for FacesFreeway. The component name is dynaForm and I'll add it to the sandbox15 area as it requires annotations and thus java 5.0 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (TOMAHAWK-741) create a component which creates the JSF tree based on beans and its annotations
create a component which creates the JSF tree based on beans and its annotations Key: TOMAHAWK-741 URL: http://issues.apache.org/jira/browse/TOMAHAWK-741 Project: MyFaces Tomahawk Issue Type: New Feature Components: New Component Reporter: Mario Ivankovits Assigned To: Mario Ivankovits Priority: Minor The component I'll going to add to the sandbox is the GUI Builder stuff I developed for FacesFreeway. The component name is dynaForm and I'll add it to the sandbox15 area as it requires annotations and thus java 5.0 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
sandbox15 - nightly build, continuum, examples
Hi! I've finished setting up the sandbox15 stuff. We now have working pom.xml things in there so that anyone who would like to check out the stuff is able to do a simple mvn install in there, though, I didn't add it to our main pom.xml file in tomahawk as then it is a requirement to use Java 5.0 for the whole build, which shouldn't be, should it? Now I would like to ask if someone is able to: *) add the sandbox15 to our nightly build *) add it to the continuum build *) create a link to the sandbox15 examples webapp (which has to happen at Irian, no?) I've already setup a simple demonstration of the dynaForm component - more to come (including a wiki based documentation) Thanks! Ciao, Mario
Re: [jira] Created: (TOMAHAWK-741) create a component which creates the JSF tree based on beans and its annotations
hey Mario, these gui builder components are great I think they may gain lots of attentionis there any way I can read more about them?On 10/15/06, Mario Ivankovits (JIRA) dev@myfaces.apache.org wrote: create a component which creates the JSF tree based on beans and its annotations Key: TOMAHAWK-741 URL: http://issues.apache.org/jira/browse/TOMAHAWK-741 Project: MyFaces TomahawkIssue Type: New FeatureComponents: New Component Reporter: Mario Ivankovits Assigned To: Mario IvankovitsPriority: MinorThe component I'll going to add to the sandbox is the GUI Builder stuff I developed for FacesFreeway. The component name is dynaForm and I'll add it to the sandbox15 area as it requires annotations and thus java 5.0--This message is automatically generated by JIRA.-If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa-For more information on JIRA, see: http://www.atlassian.com/software/jira -- Arash Rajaeeyan
Re: sandbox15 - nightly build, continuum, examples
On 10/15/06, Mario Ivankovits [EMAIL PROTECTED] wrote: I've finished setting up the sandbox15 stuff. We now have working pom.xml things in there so that anyone who would like to check out the stuff is able to do a simple mvn install in there, though, I didn't add it to our main pom.xml file in tomahawk as then it is a requirement to use Java 5.0 for the whole build, which shouldn't be, should it? Profiles can be activated by JDK version. For example, from the Shale Apps pom: http://svn.apache.org/repos/asf/shale/framework/trunk/shale-apps/pom.xml !-- Sample applications that depend on JDK 1.5 -- profile activation jdk1.5/jdk /activation modules modulemailreader-jpa/module moduleshale-mailreader-jpa/module moduleshale-sql-browser/module moduleshale-test-tiger/module /modules /profile Now I would like to ask if someone is able to: *) add the sandbox15 to our nightly build *) add it to the continuum build I'm not certain about the nightly build, but I can probably get it into Continuum if you provide the url for the pom.xml file in svn and what 'mvn' command you want executed. Example: http://svn.apache.org/repos/asf/myfaces/core/trunk/impl/pom.xml mvn clean deploy Thanks, Wendy
Re: sandbox15 - nightly build, continuum, examples
Hi Wendy! I didn't add it to our main pom.xml file in tomahawk as then it is a requirement to use Java 5.0 for the whole build, which shouldn't be, should it? Profiles can be activated by JDK version. For example, from the Shale Apps pom: Ah yes, great idea! Works like a charm. Now I would like to ask if someone is able to: *) add the sandbox15 to our nightly build *) add it to the continuum build I'm not certain about the nightly build, but I can probably get it into Continuum if you provide the url for the pom.xml file in svn and what 'mvn' command you want executed. Now with the profile settings I guess there is no additional work to do to make them work (sandbox15 is a module of tomahawk which already works at continuum), though, I don't know. So here is the data: http://svn.apache.org/repos/asf/myfaces/tomahawk/trunk/sandbox15 mvn clean deploy (;-) if this is the command the other projects use too) Thanks, I have to thank you! Ciao, Mario
Re: svn commit: r464151 - /myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/custom/savestate/UISaveState.java
On 10/15/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Author: cagatay Date: Sun Oct 15 03:36:01 2006 New Revision: 464151 URL: http://svn.apache.org/viewvc?view=revrev=464151 Log: Fix for TOMAHAWK-738 Does this need to be applied to the branch for 1.1.4? Also... can you please include a short description of the change in addition to the JIRA issue number? It really helps when people who aren't familiar with the code are reviewing commits. And as great as JIRA is, the commit logs will probably outlive it. :) Thanks! -- Wendy
Re: [jira] Created: (TOMAHAWK-741) create a component which creates the JSF tree based on beans and its annotations
Hi Arash! hey Mario, these gui builder components are great I think they may gain lots of attention is there any way I can read more about them? Nope, there is only the source and a simple example yet. If you checkout myfaces using the url [1] you'll get the sandbox15 module of tomahawk too. Though, to checkout the sandbox15 module only use [2] I try to add more examples and a Wiki documentation as we speak, so hold on for a while :-) Ciao, Mario [1] https://svn.apache.org/repos/asf/myfaces/current [2] http://svn.apache.org/repos/asf/myfaces/tomahawk/trunk/sandbox15
Re: [jira] Created: (TOMAHAWK-741) create a component which creates the JSF tree based on beans and its annotations
sorry for being impatient, I had an argument with a rubby developer about how java can be as easy as ruby and I saw your component at same day! I find it very useful for that argument. On 10/15/06, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi Arash! hey Mario, these gui builder components are great I think they may gain lots of attention is there any way I can read more about them?Nope, there is only the source and a simple example yet. If you checkout myfaces using the url [1] you'll get the sandbox15module of tomahawk too.Though, to checkout the sandbox15 module only use [2]I try to add more examples and a Wiki documentation as we speak, so hold on for a while :-)Ciao,Mario[1] https://svn.apache.org/repos/asf/myfaces/current[2] http://svn.apache.org/repos/asf/myfaces/tomahawk/trunk/sandbox15-- Arash Rajaeeyan
Re: [jira] Created: (TOMAHAWK-741) create a component which creates the JSF tree based on beans and its annotations
Hi Arash! sorry for being impatient hehe :-) I had an argument with a rubby developer about how java can be as easy as ruby and I saw your component at same day! I find it very useful for that argument. Let's see how far we can go. For now I removed the persistence stuff, the master plan is to rework the persistence using our conversationTag, but it should work with Seam too. Yea, and at the end there is still a mvn createApplication (or something like this) missing, it depends on the community what the future will bring us ... lets beat ruby - hehe - just kidding ;-) Ciao, Mario
Extend HtmlInputCalendar with time input
Hi! Someone willing to extend our HtmlInputCalendar to allow to input a time? Additional attributes like: inputTime=true|false timePrecision=hours|minutes|seconds would be great! timePrecision will define the pattern: hours: HH minutes: HH:MM seconds: HH:MM:SS The missing part should be initialized with zero then. Ciao, Mario
Re: [jira] Created: (TOMAHAWK-741) create a component which creates the JSF tree based on beans and its annotations
future will bring us ... lets beat ruby - hehe - just kidding ;-)hey why not? when the JSR 276 finished we can bring ease of use of Java Studio Creator to All java IDE's then users can just drag and drop their database tables or java bean or EJB intro JSF pages and have the application ready! as I understood your GUI builder components are an small step for you and myfaces but a giant step for JSF community for this target! ;-)On 10/15/06, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi Arash! sorry for being impatienthehe :-) I had an argument with a rubby developer about how java can be as easy as ruby and I saw your component at same day! I find it very useful for that argument. Let's see how far we can go. For now I removed the persistence stuff,the master plan is to rework the persistence using ourconversationTag, but it should work with Seam too.Yea, and at the end there is still a mvn createApplication (or something like this) missing, it depends on the community what thefuture will bring us ... lets beat ruby - hehe - just kidding ;-)Ciao,Mario-- Arash Rajaeeyan
Question from project owners about 1.1 and 1.2 distribution numbering
Hi I am writing a guide for beginners on how to use MyFacesI have two questionsI want to know what will be package name for implementation of JSF 1.2 api on download siteis it going to be: myfaces-core-1.2.x ?if so will tomahawk branched to to two different versions one for running on JSF 1.1 and another for running on JSF 1.2 ?if answer is positive is tomahawk numbering going to be like this: tomahawk-1.1.x. (run on JSF 1.1) tomahawk-1.2.x. (run on JSF 1.2)Regards Arash Rajaeeyan
[jira] Created: (MYFACES-1468) myfaces-core-src is missing some files available in the bin
myfaces-core-src is missing some files available in the bin --- Key: MYFACES-1468 URL: http://issues.apache.org/jira/browse/MYFACES-1468 Project: MyFaces Core Issue Type: Bug Components: General Affects Versions: 1.1.4 Reporter: Federico Fissore I'm tuning the building of myfaces package on Gentoo Linux Archive myfaces-core-1.1.4-src is missing some files that are present in the bin distribution. In archive myfaces-core-1.1.4-bin, the jar myfaces-impl-1.1.4.jar contains the following files /META-INF/myfaces_core.tld /META-INF/myfaces_html.tld /javax/faces/Messages*.properties /licenses/sundtd-LICENSE.txt /org/apache/myfaces/resource/standard-faces-config.xml /org/apache/myfaces/resource/web-facesconfig_1_0.dtd /org/apache/myfaces/resource/web-facesconfig_1_1.dtd These files are missing in the src, so currently the user have to download both src and bin in order to build and package it correctly Please, include these files even in the src distribution. Thank you -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [continuum] BUILD FAILURE: Impl
On 10/15/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Online report : http://myfaces.zones.apache.org:8080/continuum/servlet/continuum/target/ProjectBuild.vm/view/ProjectBuild/id/64/buildId/5275 Build statistics: State: Failed Previous State: Failed This is the only failed build in Continuum right now. Bruno, can you take a look? http://myfaces.zones.apache.org:8080/continuum/servlet/continuum/target/View.vm/fid/maven2Project/id/64 Thanks, -- Wendy
RE: Use of Sun's XSD schema in MyFaces codebase
Bruno, You might want to have this raised on the internal legal list if you want an official answer. --- Noel -Original Message- From: Bruno Aranda [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 04, 2006 4:36 To: legal-discuss@apache.org Cc: MyFaces Development Subject: Use of Sun's XSD schema in MyFaces codebase Hi, In the Apache Myfaces Project [1] we are implementing the scpecification for JSR-252 (JSF 1.2). One of the new issues includes the implementation of a XSD Schema [2] to validate some configuration XML files. This schema has been already implemented by Sun for the JSF Reference Implementation. In the previous implementation (1.1) we did include the DTDs for those files also implemented by Sun in our codebase, keeping the Sun headers and including a note in the LICENSE. It is possible the same or a similar thing to include the schema in our codebase, or do we have to implement it from scratch? Cheers, Bruno [1] http://myfaces.apache.org [2] http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd
Re: Question from project owners about 1.1 and 1.2 distribution numbering
Yes, IMO that should be the numbering for MyFaces. I don't know when there will be tomahawk component working only with version 1.2, but then, the numbering will be tomahawk-1.2 (or maybe a different component library for 1.2 components? there is not a decision on that point yet). A possible tomahawk-1.2 will only work with JSF 1.2, whereas tomahawk-1.1 will run both in 1.1 and 1.2. Cheers, Bruno On 10/15/06, Arash Rajaeeyan [EMAIL PROTECTED] wrote: Hi I am writing a guide for beginners on how to use MyFaces I have two questions I want to know what will be package name for implementation of JSF 1.2 api on download site is it going to be: myfaces-core-1.2.x ? if so will tomahawk branched to to two different versions one for running on JSF 1.1 and another for running on JSF 1.2 ? if answer is positive is tomahawk numbering going to be like this: tomahawk-1.1.x. (run on JSF 1.1) tomahawk-1.2.x. (run on JSF 1.2) Regards Arash Rajaeeyan
Re: [continuum] BUILD FAILURE: Impl
Continuum is failing right now I cannot check. If you check in the code and compile it, everything runs fine. I guess that continuum is trying to compile Impl with a wrong version of shared for the 1.2 build, but I cannot check that right now. Later this week I will have a look at it. Cheers, Bruno On 10/15/06, Wendy Smoak [EMAIL PROTECTED] wrote: On 10/15/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Online report : http://myfaces.zones.apache.org:8080/continuum/servlet/continuum/target/ProjectBuild.vm/view/ProjectBuild/id/64/buildId/5275 Build statistics: State: Failed Previous State: Failed This is the only failed build in Continuum right now. Bruno, can you take a look? http://myfaces.zones.apache.org:8080/continuum/servlet/continuum/target/View.vm/fid/maven2Project/id/64 Thanks, -- Wendy
[jira] Resolved: (TOBAGO-139) Apt Plugin should support fork mode
[ http://issues.apache.org/jira/browse/TOBAGO-139?page=all ] Bernd Bohmann resolved TOBAGO-139. -- Resolution: Fixed Apt Plugin should support fork mode --- Key: TOBAGO-139 URL: http://issues.apache.org/jira/browse/TOBAGO-139 Project: MyFaces Tobago Issue Type: Improvement Components: Maven Apt Plugin Affects Versions: 1.0.8 Reporter: Bernd Bohmann Assigned To: Bernd Bohmann Priority: Minor Fix For: 1.0.9 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: svn commit: r464151 - /myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/custom/savestate/UISaveState.java
Yes sure, I'll apply the same to 1.1.4.CagatayOn 10/15/06, Wendy Smoak [EMAIL PROTECTED] wrote: On 10/15/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Author: cagatay Date: Sun Oct 15 03:36:01 2006 New Revision: 464151 URL: http://svn.apache.org/viewvc?view=revrev=464151 Log: Fix for TOMAHAWK-738Does this need to be applied to the branch for 1.1.4?Also... can you please include a short description of the change inaddition to the JIRA issue number?It really helps when people who aren't familiar with the code are reviewing commits.And as great asJIRA is, the commit logs will probably outlive it. :)Thanks!--Wendy
[jira] Commented: (TOMAHAWK-491) t:columns generates wrong name in children input fields
[
http://issues.apache.org/jira/browse/TOMAHAWK-491?page=comments#action_12442440
]
sean schofield commented on TOMAHAWK-491:
-
m having a problemn passing a commandButton parameter inside of a t:column. I
wonder if this is due to the same problem? The JSF 1.2
setPropertyActionListener is also not working as expected with t:columns.
Instead of passing the one component that was clicked, all of the components in
the row are passed.
t:columns generates wrong name in children input fields
---
Key: TOMAHAWK-491
URL: http://issues.apache.org/jira/browse/TOMAHAWK-491
Project: MyFaces Tomahawk
Issue Type: Bug
Components: Columns
Affects Versions: 1.1.3
Environment: JSF 1.1 reference implementation
Reporter: Daniele Bernardini
Attachments: UIColumns.java
following jsf:
t:columns value=#{beanType.attributes} var=column
t:inputText value=#{bean.attributeValues[column]} id=stringInput/
/t:columns
generates:
tr class=row
tdinput id=_id0:_id1:0:_id2:stringInput
name=_id0:_id1:0:_id2:stringInput type=text value=drgsadsadf
15324//td
tdinput id=_id0:_id1:0:_id2:stringInput
name=_id0:_id1:0:_id2:stringInput type=text value=sdfsadf //td
/tr
tr class=row
tdinput id=_id0:_id1:1:_id2:stringInput
name=_id0:_id1:1:_id2:stringInput type=text value=dsdfasdf//td
tdinput id=_id0:_id1:1:_id2:stringInput
name=_id0:_id1:1:_id2:stringInput type=text value=sdsdfasdgsdgadf
//td
/tr
t:columns contributes always _id2 independently of the column being rendered,
this makes saving data from the input fields impossible.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: svn commit: r464151 - /myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/custom/savestate/UISaveState.java
Catagay this breaks my code. Serializable should also be supported. I have a bunch of Hibernate domain objects that are serializable that I use in a multi page table where I need save state. I'm going to reopen the JIRA issue. Sean On 10/15/06, Cagatay Civici [EMAIL PROTECTED] wrote: Yes sure, I'll apply the same to 1.1.4. Cagatay On 10/15/06, Wendy Smoak [EMAIL PROTECTED] wrote: On 10/15/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Author: cagatay Date: Sun Oct 15 03:36:01 2006 New Revision: 464151 URL: http://svn.apache.org/viewvc?view=revrev=464151 Log: Fix for TOMAHAWK-738 Does this need to be applied to the branch for 1.1.4? Also... can you please include a short description of the change in addition to the JIRA issue number? It really helps when people who aren't familiar with the code are reviewing commits. And as great as JIRA is, the commit logs will probably outlive it. :) Thanks! -- Wendy
[jira] Reopened: (TOMAHAWK-738) SaveState fails with a java.util.List implementation other than ArrayList
[ http://issues.apache.org/jira/browse/TOMAHAWK-738?page=all ]
sean schofield reopened TOMAHAWK-738:
-
Catagay this breaks my code. Serializable should also be supported. I have a
bunch of Hibernate domain objects that are serializable that I use in a multi
page table where I need save state.
SaveState fails with a java.util.List implementation other than ArrayList
-
Key: TOMAHAWK-738
URL: http://issues.apache.org/jira/browse/TOMAHAWK-738
Project: MyFaces Tomahawk
Issue Type: Bug
Components: UISaveState
Affects Versions: 1.1.5-SNAPSHOT
Reporter: Cagatay Civici
Assigned To: Cagatay Civici
Fix For: 1.1.5-SNAPSHOT
restoreAttachedState of UIComponentBase wraps the lists as an ArrayList so
restoring values fails when a list implementation other than an arraylist is
used.
An example;
private LinkedList list;
private String name;
private String surname;
public LinkedList getList() {
list = new LinkedList();
list.add(name);
list.add(surname);
return list;
}
public void setList(LinkedList list) {
name = (String)list.get(0);
surname = (String)list.get(1);
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (TOMAHAWK-491) t:columns generates wrong name in children input fields
[ http://issues.apache.org/jira/browse/TOMAHAWK-491?page=all ]
sean schofield updated TOMAHAWK-491:
Status: Resolved (was: Patch Available)
Fix Version/s: 1.1.5-SNAPSHOT
Resolution: Fixed
I tested the fix and it works great! It also fixed my
f:setPropertyActionListener issue. This was actually a pretty serious bug
because as near as I could tell, all events would be applied to every column
value instead of only the correct column value. Thanks for contributing the
patch.
t:columns generates wrong name in children input fields
---
Key: TOMAHAWK-491
URL: http://issues.apache.org/jira/browse/TOMAHAWK-491
Project: MyFaces Tomahawk
Issue Type: Bug
Components: Columns
Affects Versions: 1.1.3
Environment: JSF 1.1 reference implementation
Reporter: Daniele Bernardini
Assigned To: sean schofield
Fix For: 1.1.5-SNAPSHOT
Attachments: UIColumns.java
following jsf:
t:columns value=#{beanType.attributes} var=column
t:inputText value=#{bean.attributeValues[column]} id=stringInput/
/t:columns
generates:
tr class=row
tdinput id=_id0:_id1:0:_id2:stringInput
name=_id0:_id1:0:_id2:stringInput type=text value=drgsadsadf
15324//td
tdinput id=_id0:_id1:0:_id2:stringInput
name=_id0:_id1:0:_id2:stringInput type=text value=sdfsadf //td
/tr
tr class=row
tdinput id=_id0:_id1:1:_id2:stringInput
name=_id0:_id1:1:_id2:stringInput type=text value=dsdfasdf//td
tdinput id=_id0:_id1:1:_id2:stringInput
name=_id0:_id1:1:_id2:stringInput type=text value=sdsdfasdgsdgadf
//td
/tr
t:columns contributes always _id2 independently of the column being rendered,
this makes saving data from the input fields impossible.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
Tomahawk JIRA issues
I just did two bulk changes to issues in Tomahawk. Any issue that was marked 'Affects' 1.1.5-SNAPSHOT is now 1.1.4-SNAPSHOT. Any issue that was marked 'Fix For' 1.1.5-SNAPSHOT is now 1.1.4-SNAPSHOT. This was necessary because the 1.1.4 release branch was re-copied last Wednesday, so things discovered and fixed on the 1.1.5-SNAPSHOT trunk up until then will be in the release. If you marked any issues on Wednesday or after that really don't belong to 1.1.4, please change them back individually. -- Wendy
Re: svn commit: r464151 - /myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/custom/savestate/UISaveState.java
I mean if an object(not List) is serializable saveAttachedState simply returns it so;values[1] = getValue() instanceof StateHolder ? saveAttachedState(context, getValue()) : getValue();doesn't matter because saveAttachedState(context, getValue()) and getValue() are same for Serializable. Still I couldn't see why it breaks, an example should help.On 10/16/06, Cagatay Civici [EMAIL PROTECTED] wrote:Sean, I see that Serializable is already supported in saveAttachedState. I couldn't get why it's failing in your case, can you give more details?CagatayOn 10/16/06, Sean Schofield [EMAIL PROTECTED] wrote: Catagay this breaks my code.Serializable should also be supported.I have a bunch of Hibernate domain objects that are serializable thatI use in a multi page table where I need save state.I'm going toreopen the JIRA issue. SeanOn 10/15/06, Cagatay Civici [EMAIL PROTECTED] wrote: Yes sure, I'll apply the same to 1.1.4. Cagatay On 10/15/06, Wendy Smoak [EMAIL PROTECTED] wrote: On 10/15/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Author: cagatay Date: Sun Oct 15 03:36:01 2006 New Revision: 464151 URL: http://svn.apache.org/viewvc?view=revrev=464151 Log: Fix for TOMAHAWK-738 Does this need to be applied to the branch for 1.1.4? Also... can you please include a short description of the change in addition to the JIRA issue number?It really helps when people who aren't familiar with the code are reviewing commits.And as great as JIRA is, the commit logs will probably outlive it. :) Thanks! -- Wendy
[jira] Commented: (MYFACES-1467) Validation doesn't run for required fields if submitted value is null
[ http://issues.apache.org/jira/browse/MYFACES-1467?page=comments#action_12442459 ] Adam Winer commented on MYFACES-1467: - With regards to the original issue: the bug is *not* in UIInput, but is in fact in the decode() implementation for the h:inputText Renderer. If the field is expected to be submitted, a request parameter of null should get changed to the empty string, because a submitted value of null is special. W/regards to all Craig said, yes, the current behavior in the component space is exactly as intended. Validation doesn't run for required fields if submitted value is null - Key: MYFACES-1467 URL: http://issues.apache.org/jira/browse/MYFACES-1467 Project: MyFaces Core Issue Type: Bug Components: General Affects Versions: 1.2.0-SNAPSHOT, 1.1.5-SNAPSHOT Reporter: David Chandler Assigned To: Matthias Weßendorf Attachments: patch.txt A component with a required value will not fail validation as expected if the submitted value is null. This issue is not seen normally because browsers send the value for an empty text field as an empty string. That is, the POST data for an empty field1 will contain the field name but no value, like field1=field2=something. However, if you use a man-in-the-middle proxy such as Paros to remove fieldname= from the POST data, the submitted value will be null. UIInput.validate() skips validation for null submitted values, but since requiredness is also part of validation, the requiredness check gets skipped, too. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
