[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_12442275 ] Cagatay Civici commented on MYFACES-1467: - I agree, it's a spec issue rather than a myfaces issue. 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
[jira] Created: (TOMAHAWK-738) SaveState fails with a java.util.List implementation other than ArrayList
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] Resolved: (TOMAHAWK-721) Toggle component for sandbox. This component allows the user to switch between View/Edit modes
[ http://issues.apache.org/jira/browse/TOMAHAWK-721?page=all ] Cagatay Civici resolved TOMAHAWK-721. - Fix Version/s: 1.1.5-SNAPSHOT Resolution: Fixed The component is added to the sandbox Toggle component for sandbox. This component allows the user to switch between View/Edit modes -- Key: TOMAHAWK-721 URL: http://issues.apache.org/jira/browse/TOMAHAWK-721 Project: MyFaces Tomahawk Issue Type: New Feature Environment: sandbox Reporter: Sharath Reddy Assigned To: Sharath Reddy Priority: Minor Fix For: 1.1.5-SNAPSHOT Sylvain and I discussed this. this is when we would need to use it: Toggling between View/Edit modes: We have an output text wrapped in an href, and an input text that is initially hidden. both are bound to the same backing bean property. when the user clicks on the href, javascript is executed that hides the output text and displays the input text. The problem occurs when input validation fails, and the page is re-loaded. The page needs to 'remember' to hide the output text and display the input text, since we are now still in edit mode. we want to accomplish this without using 'onload' javascript, hence the need for a JSF component. -- 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-156) Add a converter tag with the attributes converterId and binding similar in jsf 1.2
Add a converter tag with the attributes converterId and binding similar in jsf 1.2 -- Key: TOBAGO-156 URL: http://issues.apache.org/jira/browse/TOBAGO-156 Project: MyFaces Tobago Issue Type: New Feature Components: Core Reporter: Bernd Bohmann Assigned To: Bernd Bohmann Priority: Minor Fix For: 1.0.9 Most of the users using jsf 1.1 but a converter tag like in jsf 1.2 would be nice. -- 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-121) made autoreload conditional with a valuebinding
[ http://issues.apache.org/jira/browse/TOBAGO-121?page=all ] Bernd Bohmann resolved TOBAGO-121. -- Resolution: Fixed made autoreload conditional with a valuebinding --- Key: TOBAGO-121 URL: http://issues.apache.org/jira/browse/TOBAGO-121 Project: MyFaces Tobago Issue Type: Improvement Components: Core Affects Versions: 1.0.8 Reporter: Bernd Bohmann Assigned To: Bernd Bohmann 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-119) Allow custom markup - styles in tc:out
[ http://issues.apache.org/jira/browse/TOBAGO-119?page=all ]
Bernd Bohmann resolved TOBAGO-119.
--
Resolution: Fixed
Allow custom markup - styles in tc:out
Key: TOBAGO-119
URL: http://issues.apache.org/jira/browse/TOBAGO-119
Project: MyFaces Tobago
Issue Type: Improvement
Components: Core
Affects Versions: 1.0.7, 1.0.8
Environment: tobago 1.0.8 nightly jdk 1.4 retro
Reporter: Rainer Rohloff
Assigned To: Bernd Bohmann
Fix For: 1.0.9
In order to guarantee CI, we need additional layout styles within the tag
tc:out
I think an good solution is not to limit the range of values.
i.e.
tc:out value=Hello world markup=infotext1 /
with theme-definition
.tobago-out-markup-infotext1 {
...
border-bottom: 1px solid #b2b2b2;
...
}
possible patch ?
public final class HtmlRendererUtil {
if (StringUtils.isNotEmpty(markup)) {
if (markup.equals(strong) || markup.equals(deleted)) {
tobagoClass.append(prefix).append(-markup-).append(markup).append(
);
} else {
LOG.warn(Unknown markup=' + markup + ');
}
change to:
if (StringUtils.isNotEmpty(markup)) {
tobagoClass.append(prefix).append(-markup-).append(markup).append(
);
if (!markup.equals(strong) !markup.equals(deleted)) {
LOG.info(Not a standard markup=' + markup + ');
}
OutTagDeclaration:
@UIComponentTagAttribute(defaultValue = none, allowedValues = { none,
strong, deleted })
change to ???:
@UIComponentTagAttribute(defaultValue = none)
--
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-155) TagHandler for tc:loadBundle has not the same behavor as the tc:loadBundle Tag in a jsp
[ http://issues.apache.org/jira/browse/TOBAGO-155?page=all ] Bernd Bohmann resolved TOBAGO-155. -- Resolution: Fixed TagHandler for tc:loadBundle has not the same behavor as the tc:loadBundle Tag in a jsp --- Key: TOBAGO-155 URL: http://issues.apache.org/jira/browse/TOBAGO-155 Project: MyFaces Tobago Issue Type: Bug Components: Facelets Affects Versions: 1.0.7, 1.0.8 Reporter: Bernd Bohmann Assigned To: Bernd Bohmann Priority: Minor Fix For: 1.0.9 The TagHandler of loadBundle bind the var to the request instead to session as the LoadBundleTag in a jsp -- 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: TCK Tests for MYFACES-1467
On 10/13/06, Wendy Smoak [EMAIL PROTECTED] wrote: On 10/13/06, Dennis Byrne [EMAIL PROTECTED] wrote: I'm on busineess/vacation in India right now for another week. After that I have to move into a new apartment. Sorry I can't help on this soon. I would be glad to help someone else through the testing process. I have corresponded with Thomas on this recently. I'd like to learn how to run the TCK also. Okay... just having read Dennis' notes, this isn't something I have time to get into right now. -- 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_12442311 ] Matthias Weßendorf commented on MYFACES-1467: - Cagatay, it's not that much important, how the RI behaves... if there is the same bug, I am fine with that :) But... why is that bug there? Because the javadoc/spec says explicit to do it wrong, or at least partial wrong... :) David was showing me some cool stuff you are able to do w/ a man-in-the-middle tool. so the filed was required and we cut out the value from the submit request. so the value is null... but the field is still required. I like to see david open a sepc issue on that and putting the url as a ref here in. 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
SaveState Issues
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-738It 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
[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_12442354 ] David Chandler commented on MYFACES-1467: - Thanks for thinking this over, Cagatay and Matthias. The more I think about this, the less I think it's a spec issue, after all. In the case of the MITM exploit, neither MyFaces nor RI currently meet the requirement of section 3.5.4 of the spec, which states If the value of this property [required] is true and the component has no value, the component is marked invalid and a message is added... Section 3.5.5 immediately following begins with the caveat Unless otherwise specified Well, section 3.5.4 does in fact otherwise specify. Given the proximity of these sections, I find it likely that 3.5.4 is exactly what 3.5.5 has in mind, so there is no problem with the spec at all. Even if the sections were in conflict, I would think it a much more serious problem to ignore the required attribute than to call validation with a null value. One is an optimization, the other a security flaw. The code in UIInput.validateValue() method does exactly what 3.5.4 and 3.5.5 say it should do, but the patched line of code as it currently exists defeats the good code in validateValue() by not calling it for a null submitted value, even if the field is required. The patch simply ensures that the already-correct validateValue() method will run if the component is required. So, I go back to my position that the code in question is a security bug and also not compliant with the spec for this case. If we apply the patch, the only time users would ever see a difference between the RI and MyFaces is when using an MITM proxy. And of course, I'll be submitting this to RI, as well. 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
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
[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_12442359 ] Martin Marinschek commented on MYFACES-1467: Hi David, Cagatay, Matthias, this bug is indeed a problem in the sourcebase. On a sidenote - I believe that it is bad to skip validation at all if the value of a field is null. What if you want to have a field which is only required if a defined other field has a certain value? You can't just set the required-attribute (you can also not value-bind the required attribute properly, cause you don't necessarily have the converted and validated value of the other field in your backing bean model), and will need a special validator. Fact is that this special validator will never be executed, if the value is null, so effectively, you can't do the validation. I believe we should change this in the next version of the spec. regards, Martin 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
[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_12442362 ] Craig McClanahan commented on MYFACES-1467: --- On a sidenote - I believe that it is bad to skip validation at all if the value of a field is null. I haven't looked to see if this changed in 1.2, but I can tell you with certainty that this behavior is *exactly* what was intended for version 1.0. The reasoning was that, if there is no value, then there is nothing to be validated. Indeed, this is the entire reason that required exists as a property, instead of as a validator, in the first place. Craig 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
The problem is that a list is internally not just serialized, but
specially treated (wrapped, and then on restore you have a different
list 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 (on
calling save-state) which tells the component on restore-state if it
should 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,
Martin
On 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.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
Re: Tree2
Hi, did just that: http://issues.apache.org/jira/browse/TOMAHAWK-739 regards, Martin On 10/14/06, Sean Schofield [EMAIL PROTECTED] wrote: The problem was that you changed the TreeWalker interface. I've fixed my TreeWalker implementations but everyone else is going to have to do the same. I suggest at a minimum that you create a JIRA issue and mark it resolved so it makes it into the release notes. Sean On 10/10/06, Martin Marinschek [EMAIL PROTECTED] wrote: Yeah. I've already settled for a subclass. I had to copy over almost everything from the tree-sources. The only thing which rescued me from having to copy all was introducing the interface. Sean, is there a way you can get the interface working according to your needs? regards, Martin On 10/10/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: I don't want the tree to _contain_ EditableValueHolders, but the tree to be an EditableValueHolder itself - imagine a dropdown which shows a tree, and you can select values from it... maybe a subclass is needed here, since that seams not to be a common use case, right? (I think we already said that during this thread) regards, Martin On 10/10/06, Sean Schofield [EMAIL PROTECTED] wrote: Martin, What is the big deal about EditableValueHolder? Why should tree2 implement this? The idea is that Tree2 contains a tree of whatever types of JSF components you choose (just like dataTable.) You can use editable value holders right now if you want to. Just add one to your node. I am probably missing something but at the moment I fail to see the problem. Also, your tree intereface has broken some things on my end. TreeWalker now needs to take an instance of Tree instead of UITreeData. This breaks some custom tree implementations that I have done offline so I may need to revert that. Let me see if I can work with what you have. Sean On 10/5/06, Martin Marinschek [EMAIL PROTECTED] wrote: No, it's a pity that not, but I can't. I'm at a client here in Germany until end of November, can't take off a week. regards, Martin On 10/5/06, Sean Schofield [EMAIL PROTECTED] wrote: Martin: I haven't had time to read this thread yet but I will shortly. Are you going to be at Apache Con this year? If so we can discuss some of your ideas in person as well. Sean On 10/5/06, Martin Marinschek [EMAIL PROTECTED] wrote: Well, it wouldn't be a problem to have an extended version of the tree which implements EditableValueHolder, but not if the model of the tree is configured by setting the value-attribute - then extending won't work. regards, Martin On 10/5/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: hi Arash, sure your feedback is welcome :) like said before, a generic raw version + aditional tree stuff. During that task we should also take a look at tree / treeTable, IMHO. -M On 10/5/06, Arash Rajaeeyan [EMAIL PROTECTED] wrote: Hello Mattias, I am so new to this list and may be I am not allowed to say this, but I think most developers I have seen use menu related components for only displaying structured data, and most of times data is displayed to user for one of the following purposes: 1) selecting one item 2) selecting multiple item 3) displaying and editing tree structured data (like organization chart, directory services, etc) the first 2 options are currently supported features of tree2, the 3'rd is under debate. May be if we can use same parent for both menu and tree navigation related components and simple tree data structure as said by matias and zubin, for parent of all these components can have following benefits: 1) simplifying development 2) simplifying learning for users 3) making it easier to add more advanced trees later on demand Best regards Arash On 10/5/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: I think a tree should display structured data and not be an input component. What should the input be? So you are willing register also validators on the tree? maybe that is more specialized use case instead a generic tree use case you are looking at. On 10/5/06, Martin Marinschek [EMAIL PROTECTED] wrote: Hi Matthias, for the reason that every component that has changing values needs to be an editable value holder. Imagine the
[jira] Created: (TOMAHAWK-739) Introduced a Tree-Interface for tree2
Introduced a Tree-Interface for tree2 - Key: TOMAHAWK-739 URL: http://issues.apache.org/jira/browse/TOMAHAWK-739 Project: MyFaces Tomahawk Issue Type: Improvement Components: Tree2 Affects Versions: 1.1.3 Reporter: Martin Marinschek Assigned To: Martin Marinschek Fix For: 1.1.5-SNAPSHOT To be able to reuse the tree-walker of the tree2 and the tree-model itself (without having to depend on UITreeData) a tree-interface has been refactored out of the UITreeData component. This means you'll need to adopt your specialized tree-walker implementations to use this tree-interface. commit: http://svn.apache.org/viewvc?view=revrev=454391 regards, Martin -- 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: how do we handle old taglib definitions in the sandbox
+1 for a clear cut. When you upgrade your app to a new version of MyFaces, you'll surely be happy to have some of the components you used upgraded to tomahawk from the sandbox. You'll be ok with going through the code-base and doing a string-search-replace for the affected component-instances. regards, Martin On 10/13/06, Ernst Fastl [EMAIL PROTECTED] wrote: I agree ,If deprecation is not really possible ( for now I could also not think of a appropriate way to do so) then the clear cut has to be done sooner or later anyway. And as erik-berndt already pointed out, the migration for the users will be just a text-replace in their jsps or facelet-xhtml files. Before upgrading users should read the release notes anyway :-) On 10/13/06, Werner Punz [EMAIL PROTECTED] wrote: Ernst Fastl schrieb: On one hand it is right that components of the sandbox are potential subjects for change, but would it really hurt to do a slower deprecation? Like Werner pointed out, some people are already using sandbox components in their production environments although this may never have been recommended they do it. So I think a slower transition with some kind of deprecation mechanism would be appropriate wouldn't it? The problem is, there is no deprecation mechanism... I asked what the consensous is here, regarding this problem, but I think a clear cut has to do it for now... At least in my case, the dojoInitializer, this is non critical, not too many users use it, we might have to go a different route for the high level end user components, I guess. But keeping the tld codebase twice is a huge burden. -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
[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_12442363 ] Martin Marinschek commented on MYFACES-1467: Hi Craig, what do you say to my reasoning for cases where required is either true or false, depending on the value of another component? regards, Martin 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
[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_12442364 ] Craig McClanahan commented on MYFACES-1467: --- what do you say to my reasoning for cases where required is either true or false, depending on the value of another component? I say two things: * JSF validation is all about single values -- cross field validation is left to the application, or to frameworks built on top of JSF (i.e. it's reasonable to build a validation framework extending JSF that does this kind of thing, but it's out of scope for the JSF validation APIs themselves, at least for 1.0). * Firing validators on null values doesn't solve your use case anyway. You are going to need to do something application specific anyway. The current APIs are nowhere near rich enough to express all of the possible cross field scenarios that you would need to cover to be complete. In the short term (i.e. before you can convince some future JSF expert group to change this), the best advice might be to build a standalone validation framework that deals with all the possible cross-field type issues, rather than trying to coerce individual components to behave differently than the JSF standard ones do. Also, keep an eye on JSRs like #303 (annotations based validation rules), which will be playing in this same space. 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
