jira comment formatting
Hi! What happend to the comment formatting in jira? Was it always that bad and I never noticed it, or is this a new "feature"? It purges all newlines. --- Mario
[jira] Commented: (MYFACES-856) t:aliasBean + binding + panelGrid causes exception
[ http://issues.apache.org/jira/browse/MYFACES-856?page=comments#action_12358339 ] Mario Ivankovits commented on MYFACES-856: -- You are right, these are the downsides of this solution, but as I said, it isnt a solution its a HACK. Even if you put your aliasbean directly after f:view, the aliased binding cant be resolved if you dont call "makeAlias". You might also have a look at MYFACES-334 (reported by me ;-) ) There Mathias Broekelmann pointed out another solution. Mainly to bind against a non aliased request bean which acts as an interface, though, this leads to not well maintainable code I think. Might it be possible to treat aliases static and thus, once the binding has been resolved, to rewrite the binding information directly in the component? > t:aliasBean + binding + panelGrid causes exception > -- > > Key: MYFACES-856 > URL: http://issues.apache.org/jira/browse/MYFACES-856 > Project: MyFaces > Type: Bug > Reporter: Simon Kitching > > The following use of t:aliasBean causes an exception: > including page > <%@ 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/tomahawk"; prefix="t"%> > > > > > > > > included page > <%@ 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/tomahawk"; prefix="t"%> > > > > The thrown exception is: > javax.faces.el.PropertyNotFoundException: Base is null: target > at > org.apache.myfaces.el.ValueBindingImpl.resolveToBaseAndProperty(ValueBindingImpl.java:457) > at > org.apache.myfaces.el.ValueBindingImpl.setValue(ValueBindingImpl.java:245) > at > org.apache.myfaces.application.ApplicationImpl.createComponent(ApplicationImpl.java:434) > I believe the problem is that panelGrid renders its children. This means that > the components are first created, then the panelGrid iterates over them to > render them. However the alias bean hasn't set up the alias at the time the > components are being created. And ApplicationImpl.createComponent(binding, > context, componentType) is immediately evaluating the binding expression, > resulting in the target bean for the binding not being found. -- 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: Some Ajax updates
Good work Travis! Any chance of creating some examples for these ? -- Grant Smith
[jira] Commented: (MYFACES-866) Updates to standard tag TLD documentation
[ http://issues.apache.org/jira/browse/MYFACES-866?page=comments#action_12358337 ] Steve Peterson commented on MYFACES-866: Once the tld-docs.patch is accepted and I sync up, I'll be submitting another patch to bring the changes over into the Tomahawk tld files. Can we keep this bug open to handle that patch too? > Updates to standard tag TLD documentation > - > > Key: MYFACES-866 > URL: http://issues.apache.org/jira/browse/MYFACES-866 > Project: MyFaces > Type: Improvement > Components: General > Versions: 1.1.1 > Reporter: Steve Peterson > Attachments: tld-docs.patch > > Patch coming shortly with better documented TLD files. -- 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: tld documentation for standard HTML attributes
Both tomahawk/tld/myfaces_ext.dl and tomahawk/tld/tomahawk.tld will need some additional external entities added to pick up the standard HTML stuff that I have in my patch. It looks from here (subversion newbie) like tomahawk/tld/entities and impl/tld/entities refer to the same files. If so, both tomahawk/tld/myfaces_ext.dl and tomahawk/tld/tomahawk.tld will need some additional external entities added to pick up the standard HTML stuff that I have in my patch. Is there a simple way for a noncommitter to test in that environment, or should I wait to see if my patch is accepted before I submit a patch to update the other files? That is probably simplest. SteveOn 11/23/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: I just landed a big TLD documentation change (MYFACES-866) that goes a long way toward addressing Simon's comments. It looks to me like the change will go a long way toward addressing Simon's comment. Looks like I need to edit tomahawk/tld/myfaces_ext.tld to make the changes show up there, will post a patch shortly. \ Steve On 11/23/05, Martin Marinschek < [EMAIL PROTECTED]> wrote: a) no - go ahead.b) no. nothing is autogenerated for the tld files.c) no problem with this.regards,MartinOn 11/23/05, Simon Kitching < [EMAIL PROTECTED] > wrote:> Hi,>> It's bugging me that when I look at the tomahawk TLDDOC I see lots of> "No Description" lines, most of which are for standard HTML attributes> (with the occasional JSF or Tomahawk attribute mixed in). >> I know it's trivial, but nevertheless I would like to add basic> descriptions to the tomahawk/tld/entities/* files for the html items;> just one of:>HTML event > or>HTML attribute> so that the tlddoc is easier on the eye, and attributes that *really*> aren't documented stand out properly.>> (a) > Does anyone have any objection?>> (b)> Are these files auto-generated? (obviously changing the source data and> regenerating would make more sense in that case)>> (c)> Many of the existing files have each attribute defined on a single line. > Is there a reason for that or is it just style? If I add descriptions> I'll really need to break them out to multiple lines, otherwise the> lines will get *very* long.>>> Regards, >> Simon>--http://www.irian.atYour JSF powerhouse -JSF Consulting, Development and Courses in English and GermanProfessional Support for Apache MyFaces
Re: tld documentation for standard HTML attributes
I just landed a big TLD documentation change (MYFACES-866) that goes a long way toward addressing Simon's comments. It looks to me like the change will go a long way toward addressing Simon's comment. Looks like I need to edit tomahawk/tld/myfaces_ext.tld to make the changes show up there, will post a patch shortly. \ Steve On 11/23/05, Martin Marinschek <[EMAIL PROTECTED]> wrote: a) no - go ahead.b) no. nothing is autogenerated for the tld files.c) no problem with this.regards,MartinOn 11/23/05, Simon Kitching <[EMAIL PROTECTED] > wrote:> Hi,>> It's bugging me that when I look at the tomahawk TLDDOC I see lots of> "No Description" lines, most of which are for standard HTML attributes> (with the occasional JSF or Tomahawk attribute mixed in). >> I know it's trivial, but nevertheless I would like to add basic> descriptions to the tomahawk/tld/entities/* files for the html items;> just one of:>HTML event > or>HTML attribute> so that the tlddoc is easier on the eye, and attributes that *really*> aren't documented stand out properly.>> (a) > Does anyone have any objection?>> (b)> Are these files auto-generated? (obviously changing the source data and> regenerating would make more sense in that case)>> (c)> Many of the existing files have each attribute defined on a single line. > Is there a reason for that or is it just style? If I add descriptions> I'll really need to break them out to multiple lines, otherwise the> lines will get *very* long.>>> Regards, >> Simon>--http://www.irian.atYour JSF powerhouse -JSF Consulting, Development andCourses in English and GermanProfessional Support for Apache MyFaces
[jira] Updated: (MYFACES-866) Updates to standard tag TLD documentation
[ http://issues.apache.org/jira/browse/MYFACES-866?page=all ] Steve Peterson updated MYFACES-866: --- Attachment: tld-docs.patch This patch significantly improves the TLD documentation for the basic h: and f: tag libraries. Major revisions: Every element and every attribute is documented. Deprecated HTML 4.01 tags are documented. Every attribute has its type specified, if it varies from the default of "static or value binding EL". Change UIParameter value attribute to required per spec. > Updates to standard tag TLD documentation > - > > Key: MYFACES-866 > URL: http://issues.apache.org/jira/browse/MYFACES-866 > Project: MyFaces > Type: Improvement > Components: General > Versions: 1.1.1 > Reporter: Steve Peterson > Attachments: tld-docs.patch > > Patch coming shortly with better documented TLD files. -- 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: tld documentation for standard HTML attributes
a) no - go ahead. b) no. nothing is autogenerated for the tld files. c) no problem with this. regards, Martin On 11/23/05, Simon Kitching <[EMAIL PROTECTED]> wrote: > Hi, > > It's bugging me that when I look at the tomahawk TLDDOC I see lots of > "No Description" lines, most of which are for standard HTML attributes > (with the occasional JSF or Tomahawk attribute mixed in). > > I know it's trivial, but nevertheless I would like to add basic > descriptions to the tomahawk/tld/entities/* files for the html items; > just one of: >HTML event > or >HTML attribute > so that the tlddoc is easier on the eye, and attributes that *really* > aren't documented stand out properly. > > (a) > Does anyone have any objection? > > (b) > Are these files auto-generated? (obviously changing the source data and > regenerating would make more sense in that case) > > (c) > Many of the existing files have each attribute defined on a single line. > Is there a reason for that or is it just style? If I add descriptions > I'll really need to break them out to multiple lines, otherwise the > lines will get *very* long. > > > Regards, > > Simon > -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
[jira] Created: (MYFACES-866) Updates to standard tag TLD documentation
Updates to standard tag TLD documentation - Key: MYFACES-866 URL: http://issues.apache.org/jira/browse/MYFACES-866 Project: MyFaces Type: Improvement Components: General Versions: 1.1.1 Reporter: Steve Peterson Patch coming shortly with better documented TLD files. -- 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
tld documentation for standard HTML attributes
Hi, It's bugging me that when I look at the tomahawk TLDDOC I see lots of "No Description" lines, most of which are for standard HTML attributes (with the occasional JSF or Tomahawk attribute mixed in). I know it's trivial, but nevertheless I would like to add basic descriptions to the tomahawk/tld/entities/* files for the html items; just one of: HTML event or HTML attribute so that the tlddoc is easier on the eye, and attributes that *really* aren't documented stand out properly. (a) Does anyone have any objection? (b) Are these files auto-generated? (obviously changing the source data and regenerating would make more sense in that case) (c) Many of the existing files have each attribute defined on a single line. Is there a reason for that or is it just style? If I add descriptions I'll really need to break them out to multiple lines, otherwise the lines will get *very* long. Regards, Simon
[jira] Commented: (MYFACES-856) t:aliasBean + binding + panelGrid causes exception
[
http://issues.apache.org/jira/browse/MYFACES-856?page=comments#action_12358326
]
Simon Kitching commented on MYFACES-856:
Sigh. It looks like AliasBean just won't work with component bindings. At least
I can't see any way to do it.
The issue with AliasBean when the view is being created is solvable by adding
doStartTag/doEndTag methods to AliasBeanTag.
However when restoring an existing view, the bindings are executed by
LifecycleImpl.recursivelyHandleComponentReferencesAndSetValid. And this method
doesn't delegate the operation to the actual component, but instead breaks
encapsulation by evaluating the component's binding itself. This means there is
no way to execute "before" and "after" operations around the rebinding of the
child components.
I've therefore just added a comment on AliasBean.java stating that bindings are
not supported. I will update the wiki too.
Well, there *might* be a way to do it, by having AliasBean create a dummy first
and last child, and catch calls to getValueBinding("binding") on them or some
such nasty hack. I don't think that's worth doing though.
Mario's approach above does work, but by effectively promoting all AliasBean so
that their alias is visible over the whole view tree. That's a fair solution
for specific sites but I don't think it's a good general solution. For a start,
it makes it impossible to reuse the same block of components twice in the same
page bound to different real beans. And anyway as far as I can see, it's just
equivalent to putting the aliasbean directly after the f:view and enclosing the
entire page in it. Mario, have I missed something?
I'll leave this issue open for a few days just in case someone smarter than me
comes up with a proper solution.
> t:aliasBean + binding + panelGrid causes exception
> --
>
> Key: MYFACES-856
> URL: http://issues.apache.org/jira/browse/MYFACES-856
> Project: MyFaces
> Type: Bug
> Reporter: Simon Kitching
>
> The following use of t:aliasBean causes an exception:
> including page
> <%@ 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/tomahawk"; prefix="t"%>
>
>
>
>
>
>
>
> included page
> <%@ 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/tomahawk"; prefix="t"%>
>
>
>
> The thrown exception is:
> javax.faces.el.PropertyNotFoundException: Base is null: target
> at
> org.apache.myfaces.el.ValueBindingImpl.resolveToBaseAndProperty(ValueBindingImpl.java:457)
> at
> org.apache.myfaces.el.ValueBindingImpl.setValue(ValueBindingImpl.java:245)
> at
> org.apache.myfaces.application.ApplicationImpl.createComponent(ApplicationImpl.java:434)
> I believe the problem is that panelGrid renders its children. This means that
> the components are first created, then the panelGrid iterates over them to
> render them. However the alias bean hasn't set up the alias at the time the
> components are being created. And ApplicationImpl.createComponent(binding,
> context, componentType) is immediately evaluating the binding expression,
> resulting in the target bean for the binding not being found.
--
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] Closed: (MYFACES-865) dataList not behaving inside panelGrid
[ http://issues.apache.org/jira/browse/MYFACES-865?page=all ]
Simon Kitching closed MYFACES-865:
--
Resolution: Invalid
Hi Tony,
I'd expect exactly what you are seeing.
You have a panelGrid with a single child (though its column attribute is set
dynamically).
The single child is an HtmlDataList component, which has one child per list
element.
That child happens to be a PanelGroup.
As a wild guess, perhaps you could try:
And in the css rules:
#inlineItem {
display: inline;
}
to force the thing that the t:panelGroup creates to be displayed as "inline"
rather than as "block" (which forces a linefeed).
For further discussion on this, please use the user email list rather than the
bugtracker.
> dataList not behaving inside panelGrid
> --
>
> Key: MYFACES-865
> URL: http://issues.apache.org/jira/browse/MYFACES-865
> Project: MyFaces
> Type: Bug
> Components: Tomahawk
> Versions: 1.1.1, Nightly
> Environment: Myfaces nightly from 11/22/2005
> Tomcat 5.5
> Jdk 1.5
> Linux (Fedora 4)
> Reporter: Tony Czupryna
>
> I'm trying to use a dataList to get around the lack of a loop. Here is the
> sample jsp:
> <%@ page session="true" contentType="text/html;charset=UTF-8" language="java"
> %>
> <%@ 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/tomahawk"; prefix="t" %>
>
> TonyTesterNoRadio
>
>
>
>
>
>
>
> rowIndexVar="index">
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> From this (and other code which I can provide), I expect each panel group to
> line up horizontally across the page. From the html, you can see that the
> groups are all put into the first column:
>
> 1
> helper1-descriptionLine1
> helper1-descriptionLine2
>
> 1
> helper2-descriptionLine1
> helper2-descriptionLine2
>
> 1
> helper3-descriptionLine1
> helper3-descriptionLine2
>
>
--
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
Some Ajax updates
So I've got a good set of ajax form components working now and I thought I'd give an update. - inputText (with options to show buttons for submit, default is to submit onChange) - selectManyCheckbox - selectOneRadio - selectBooleanCheckbox (with options to use on/off images instead of a checkbox) Validation and error handling works without reloading the page, all updates are done client side. The messages will also be cleared if the next request succeeds. Must use the tag for this to work correctly. I was able to short circuit most of the life cycle by completing the response before the Apply Request Values Phase (just after Restore View), only applying the lifecycle to the affected component. Travis
Re: Recent javadoc updates
Keep them coming, there is far too few comments in the code right now. I'm sure some comments would have saved me many hours. Travis On 11/22/05, Simon Kitching <[EMAIL PROTECTED]> wrote: > Hi All, > > Sorry for the flood of javadoc commits; this is some stuff I've had > sitting around for a while. > > For the changes to the api/impl classes, I've checked the JSP1.2 > javadoc, and what I've got is a bit different in flavour from the spec > so I've committed it for you to look at. If you don't like it please > tell me and I'll take it out again. However it's info that I painfully > learned by studying the code, and would have found useful myself. > > Of course any corrections are very welcome. > > Regards, > > Simon >
[jira] Created: (MYFACES-865) dataList not behaving inside panelGrid
dataList not behaving inside panelGrid -- Key: MYFACES-865 URL: http://issues.apache.org/jira/browse/MYFACES-865 Project: MyFaces Type: Bug Components: Tomahawk Versions: 1.1.1, Nightly Environment: Myfaces nightly from 11/22/2005 Tomcat 5.5 Jdk 1.5 Linux (Fedora 4) Reporter: Tony Czupryna I'm trying to use a dataList to get around the lack of a loop. Here is the sample jsp: <%@ page session="true" contentType="text/html;charset=UTF-8" language="java" %> <%@ 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/tomahawk"; prefix="t" %> TonyTesterNoRadio >From this (and other code which I can provide), I expect each panel group to >line up horizontally across the page. From the html, you can see that the >groups are all put into the first column: 1 helper1-descriptionLine1 helper1-descriptionLine2 1 helper2-descriptionLine1 helper2-descriptionLine2 1 helper3-descriptionLine1 helper3-descriptionLine2 -- 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
Recent javadoc updates
Hi All, Sorry for the flood of javadoc commits; this is some stuff I've had sitting around for a while. For the changes to the api/impl classes, I've checked the JSP1.2 javadoc, and what I've got is a bit different in flavour from the spec so I've committed it for you to look at. If you don't like it please tell me and I'll take it out again. However it's info that I painfully learned by studying the code, and would have found useful myself. Of course any corrections are very welcome. Regards, Simon
Re: Reconnecting UIComponentTag instances with the corresponding UIComponent
Hi Travis,
Thanks for your response.
Yes, it looks to me like on the first visit to the view, the ids are
generated via that getOrCreateUniqueId method (which calls
UIViewRoot.createUniqueId). That id is then stored persistently in the
component. But on the second view, how does the 3rd anonymous JSF tag in
a page know which UIComponent object to attach to? I'm guessing that it
simply calls createUniqueId, and gets back "_id3", then attaches to the
existing component with that id. But that fails horribly if something
like is used to enclose JSF tags and the if-condition changes
between consecutive render phases.
Maybe it is simply an unstated requirement that a JSP page does not add
or remove JSF components between rendering passes; I am aware that c:if
has problems with JSF. But the existence of the
UIComponentTag.removeFormerChildren method seems to imply to me that it
*is* allowed and supported for the JSP page and the view tree to not match.
Regarding re-use of JSP tag objects: this is allowed by the JSP spec.
It's a performance optimisation to reduce the number of JSP tag objects
that need to be created. Once a tag's doEndTag method has been called it
is available for reuse; see the javadoc for class
javax.servlet.jsp.tagext.Tag.
As you can see UIComponentTag.doEndTag calls internalRelease(). But
strangely, members _id, _rendered and _binding are cleared only in
release(), not internalRelease(). Maybe that's a bug?
Regards,
Simon
Travis Reeder wrote:
I believe the id's are generated at the time the component is
instantiated which seems to occur in UIComponentTag.findComponent().
The corresponding code is:
//Child
String id = getOrCreateUniqueId(context);
_componentInstance = parent.findComponent(id);
if (_componentInstance == null)
{
_componentInstance = createComponentInstance(context, id);
setProperties(_componentInstance);
..
I've just been tracing through this stuff all day to figure out how to
assign id's properly from a tag.
One very peculiar thing that may be somewhat related is that while
trying to set id's from a tag, it appears that the Tag object itself
is reused? Because initially the id on the tag is the same id as the
previous occurence of the same tag on the same page.
ex: i had a log message in HtmlMessageTag.setFor(String) and i output
getId on the tag. The second occurence of the message tag had the
previous occurences id at this point. Is it supposed to be reused?
Travis
On 11/22/05, Simon Kitching <[EMAIL PROTECTED]> wrote:
Hi,
As part of my investigations of
http://issues.apache.org/jira/browse/MYFACES-856
I have found that I need to understand how a UIComponentTag finds its
corresponding component.
When a JSP page is processed, each time a jsf tag is encountered a
UIComponentTag instance is created, initialised with the tag attributes,
and then doStartTag is invoked.
On the first visit to a view, there is no problem: each UIComponentTag
simply creates its corresponding component.
However on a re-render the UIComponentTag has to locate the appropriate
UIComponent instance in the view (see method findComponent). It's
important that it does this correctly, as this is how components with
failed validation (whose value to render is stored in the component's
_submittedValue member) render their value into the correct place in the
response.
The UIComponentTag knows its parent tag, and its parent tag knows its
component. So far so good.
Now if the tag in question has an explicit id assigned by the user then
there's no problem: a search is done in the children of the parent tag's
component for a matching id.
But what happens if the tag has an auto-generated id?
It looks to me like the "reconnection" process then depends upon
UIViewRoot generating anonymous ids in exactly the same sequence as on
the first view.
Won't this fail horribly if on re-render of a page there are more or
less JSF tags present than there were previously? UIComponentTags will
then "find" the wrong UIComponents, potentially of completely the wrong
type for that tag.
The methods UIComponentTag.removeFormerChildren/removeFormerFacets are
in this class explicitly to handle cases where re-rendering of a view
finds that JSF components have been added or removed. I had assumed that
this was to handle JSTL c:if tags enclosing JSF tags in a page, and
similar situations. Is this not the case? Perhaps this is not supported
at all, and the removeFormerChildren method is there only to handle
cases where components were programmatically added?
Is this all perhaps related to the mysterious comment in
UIComponentBase.getClientId?
if (id == null)
{
//Although this is an error prone side effect, we
// automatically create a new id
//just to be compatible to the RI
Thanks in advance for any info,
Simon
Re: Reconnecting UIComponentTag instances with the corresponding UIComponent
I believe the id's are generated at the time the component is
instantiated which seems to occur in UIComponentTag.findComponent().
The corresponding code is:
//Child
String id = getOrCreateUniqueId(context);
_componentInstance = parent.findComponent(id);
if (_componentInstance == null)
{
_componentInstance = createComponentInstance(context, id);
setProperties(_componentInstance);
..
I've just been tracing through this stuff all day to figure out how to
assign id's properly from a tag.
One very peculiar thing that may be somewhat related is that while
trying to set id's from a tag, it appears that the Tag object itself
is reused? Because initially the id on the tag is the same id as the
previous occurence of the same tag on the same page.
ex: i had a log message in HtmlMessageTag.setFor(String) and i output
getId on the tag. The second occurence of the message tag had the
previous occurences id at this point. Is it supposed to be reused?
Travis
On 11/22/05, Simon Kitching <[EMAIL PROTECTED]> wrote:
> Hi,
>
> As part of my investigations of
>http://issues.apache.org/jira/browse/MYFACES-856
> I have found that I need to understand how a UIComponentTag finds its
> corresponding component.
>
> When a JSP page is processed, each time a jsf tag is encountered a
> UIComponentTag instance is created, initialised with the tag attributes,
> and then doStartTag is invoked.
>
> On the first visit to a view, there is no problem: each UIComponentTag
> simply creates its corresponding component.
>
> However on a re-render the UIComponentTag has to locate the appropriate
> UIComponent instance in the view (see method findComponent). It's
> important that it does this correctly, as this is how components with
> failed validation (whose value to render is stored in the component's
> _submittedValue member) render their value into the correct place in the
> response.
>
> The UIComponentTag knows its parent tag, and its parent tag knows its
> component. So far so good.
>
> Now if the tag in question has an explicit id assigned by the user then
> there's no problem: a search is done in the children of the parent tag's
> component for a matching id.
>
> But what happens if the tag has an auto-generated id?
>
> It looks to me like the "reconnection" process then depends upon
> UIViewRoot generating anonymous ids in exactly the same sequence as on
> the first view.
>
> Won't this fail horribly if on re-render of a page there are more or
> less JSF tags present than there were previously? UIComponentTags will
> then "find" the wrong UIComponents, potentially of completely the wrong
> type for that tag.
>
>
> The methods UIComponentTag.removeFormerChildren/removeFormerFacets are
> in this class explicitly to handle cases where re-rendering of a view
> finds that JSF components have been added or removed. I had assumed that
> this was to handle JSTL c:if tags enclosing JSF tags in a page, and
> similar situations. Is this not the case? Perhaps this is not supported
> at all, and the removeFormerChildren method is there only to handle
> cases where components were programmatically added?
>
> Is this all perhaps related to the mysterious comment in
> UIComponentBase.getClientId?
> if (id == null)
> {
>//Although this is an error prone side effect, we
>// automatically create a new id
>//just to be compatible to the RI
>
>
> Thanks in advance for any info,
>
> Simon
>
Reconnecting UIComponentTag instances with the corresponding UIComponent
Hi,
As part of my investigations of
http://issues.apache.org/jira/browse/MYFACES-856
I have found that I need to understand how a UIComponentTag finds its
corresponding component.
When a JSP page is processed, each time a jsf tag is encountered a
UIComponentTag instance is created, initialised with the tag attributes,
and then doStartTag is invoked.
On the first visit to a view, there is no problem: each UIComponentTag
simply creates its corresponding component.
However on a re-render the UIComponentTag has to locate the appropriate
UIComponent instance in the view (see method findComponent). It's
important that it does this correctly, as this is how components with
failed validation (whose value to render is stored in the component's
_submittedValue member) render their value into the correct place in the
response.
The UIComponentTag knows its parent tag, and its parent tag knows its
component. So far so good.
Now if the tag in question has an explicit id assigned by the user then
there's no problem: a search is done in the children of the parent tag's
component for a matching id.
But what happens if the tag has an auto-generated id?
It looks to me like the "reconnection" process then depends upon
UIViewRoot generating anonymous ids in exactly the same sequence as on
the first view.
Won't this fail horribly if on re-render of a page there are more or
less JSF tags present than there were previously? UIComponentTags will
then "find" the wrong UIComponents, potentially of completely the wrong
type for that tag.
The methods UIComponentTag.removeFormerChildren/removeFormerFacets are
in this class explicitly to handle cases where re-rendering of a view
finds that JSF components have been added or removed. I had assumed that
this was to handle JSTL c:if tags enclosing JSF tags in a page, and
similar situations. Is this not the case? Perhaps this is not supported
at all, and the removeFormerChildren method is there only to handle
cases where components were programmatically added?
Is this all perhaps related to the mysterious comment in
UIComponentBase.getClientId?
if (id == null)
{
//Although this is an error prone side effect, we
// automatically create a new id
//just to be compatible to the RI
Thanks in advance for any info,
Simon
[jira] Commented: (MYFACES-864) valueChangeNotifier
[
http://issues.apache.org/jira/browse/MYFACES-864?page=comments#action_12358315
]
Mario Ivankovits commented on MYFACES-864:
--
Usage:
where you have to replace the taglib "opsj" by the name where you added the
valueChangeNotifier.
Like valueChangeListener, if you add a name with '#{...}' the returned string
of this method will be used to add the valueChange listener. And thus, you have
to strip those if you simply would like to set a bean/method-name.
Currently only the syntax myBean.myMethodName is supported, no valueChange
classes.
> valueChangeNotifier
> ---
>
> Key: MYFACES-864
> URL: http://issues.apache.org/jira/browse/MYFACES-864
> Project: MyFaces
> Type: Improvement
> Components: Tomahawk
> Reporter: Mario Ivankovits
> Attachments: ValueChangeCollector.java, ValueChangeManager.java,
> ValueChangeNotifierTag.java, ValueChangePhaseListener.java
>
> Like valueChangeListener but will fire valueChange event AFTER the
> UPDATE_MODEL phase.
> Its not correctly packaged and it didnt use the right package names yet ,
> though, functional.
> It would be great if there is a developer which will review this code so I/he
> can prepare it for addition to tomahawk.
> Maybe Simon? (as you state you do have the same needs)
> It requires a phase listener installed in your fase-config. I am sure we can
> hide this from the user after we packaged it
> faces-config
>
>
> com.ops.OPSJ.jsflib.PhaseListener
>
> TLD
>
> valueChangeNotifier
>
> com.ops.OPSJ.jsflib.valueChangeNotifier.ValueChangeNotifierTag
> JSP
>
>
> Add a value change listener which will be fired AFTER
> UPDATE_MODEL.
> Only "method" valueChange listeners are supported
> currently.
>
> e.g. myBean.myMethoListener
>
>
> name
> true
> false
>
>
--
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: (MYFACES-864) valueChangeNotifier
[ http://issues.apache.org/jira/browse/MYFACES-864?page=all ] Mario Ivankovits updated MYFACES-864: - Attachment: ValueChangeManager.java ValueChangeNotifierTag.java ValueChangePhaseListener.java > valueChangeNotifier > --- > > Key: MYFACES-864 > URL: http://issues.apache.org/jira/browse/MYFACES-864 > Project: MyFaces > Type: Improvement > Components: Tomahawk > Reporter: Mario Ivankovits > Attachments: ValueChangeCollector.java, ValueChangeManager.java, > ValueChangeNotifierTag.java, ValueChangePhaseListener.java > > Like valueChangeListener but will fire valueChange event AFTER the > UPDATE_MODEL phase. > Its not correctly packaged and it didnt use the right package names yet , > though, functional. > It would be great if there is a developer which will review this code so I/he > can prepare it for addition to tomahawk. > Maybe Simon? (as you state you do have the same needs) > It requires a phase listener installed in your fase-config. I am sure we can > hide this from the user after we packaged it > faces-config > > > com.ops.OPSJ.jsflib.PhaseListener > > TLD > > valueChangeNotifier > > com.ops.OPSJ.jsflib.valueChangeNotifier.ValueChangeNotifierTag > JSP > >> Add a value change listener which will be fired AFTER > UPDATE_MODEL. > Only "method" valueChange listeners are supported > currently. >
> e.g. myBean.myMethoListener > > > name > true > false > > -- 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: (MYFACES-864) valueChangeNotifier
[ http://issues.apache.org/jira/browse/MYFACES-864?page=all ] Mario Ivankovits updated MYFACES-864: - Attachment: ValueChangeCollector.java > valueChangeNotifier > --- > > Key: MYFACES-864 > URL: http://issues.apache.org/jira/browse/MYFACES-864 > Project: MyFaces > Type: Improvement > Components: Tomahawk > Reporter: Mario Ivankovits > Attachments: ValueChangeCollector.java, ValueChangeManager.java, > ValueChangeNotifierTag.java, ValueChangePhaseListener.java > > Like valueChangeListener but will fire valueChange event AFTER the > UPDATE_MODEL phase. > Its not correctly packaged and it didnt use the right package names yet , > though, functional. > It would be great if there is a developer which will review this code so I/he > can prepare it for addition to tomahawk. > Maybe Simon? (as you state you do have the same needs) > It requires a phase listener installed in your fase-config. I am sure we can > hide this from the user after we packaged it > faces-config > > > com.ops.OPSJ.jsflib.PhaseListener > > TLD > > valueChangeNotifier > > com.ops.OPSJ.jsflib.valueChangeNotifier.ValueChangeNotifierTag > JSP > >> Add a value change listener which will be fired AFTER > UPDATE_MODEL. > Only "method" valueChange listeners are supported > currently. >
> e.g. myBean.myMethoListener > > > name > true > false > > -- 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: (MYFACES-864) valueChangeNotifier
valueChangeNotifier --- Key: MYFACES-864 URL: http://issues.apache.org/jira/browse/MYFACES-864 Project: MyFaces Type: Improvement Components: Tomahawk Reporter: Mario Ivankovits Like valueChangeListener but will fire valueChange event AFTER the UPDATE_MODEL phase. Its not correctly packaged and it didnt use the right package names yet , though, functional. It would be great if there is a developer which will review this code so I/he can prepare it for addition to tomahawk. Maybe Simon? (as you state you do have the same needs) It requires a phase listener installed in your fase-config. I am sure we can hide this from the user after we packaged it faces-config com.ops.OPSJ.jsflib.PhaseListener TLD valueChangeNotifier com.ops.OPSJ.jsflib.valueChangeNotifier.ValueChangeNotifierTag JSPAdd a value change listener which will be fired AFTER UPDATE_MODEL. Only "method" valueChange listeners are supported currently.
e.g. myBean.myMethoListener name true false -- 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: [jira] Commented: (MYFACES-705) Overflow problem with InputSuggestAjax
Hi Volker, no, the nightly examples are not deployed. Sorry. We'll need to wait until you get to do a check-out again. In IE, the suggestion opened over the input field - halfway up. regards, Martin On 11/22/05, Volker Weber <[EMAIL PROTECTED]> wrote: > Hi Martin, > > are the nightly sandbox examples anywhere in public deployed? > > the examples at www.irian.at are without my patches. > > i can't do a fresh checkout here (@work) because my svn client can't > https :-(. > > what is the problem? i had checked with opera, ie and mozilla before > creating the patch. > > Regards > Volker > > Martin Marinschek (JIRA) wrote: > > [ > > http://issues.apache.org/jira/browse/MYFACES-705?page=comments#action_12358239 > > ] > > > > Martin Marinschek commented on MYFACES-705: > > --- > > > > Volker, > > > > obviously your fix introduced another problem - the inputSuggestAjax > > component doesn't render correctly in the IE anymore. > > > > Can you check this again? > > > > regards, > > > > Martin > > > > > >>Overflow problem with InputSuggestAjax > >>-- > >> > >> Key: MYFACES-705 > >> URL: http://issues.apache.org/jira/browse/MYFACES-705 > >> Project: MyFaces > >>Type: Bug > >> Components: Sandbox > >>Versions: 1.1.2 > >>Reporter: Volker Weber > >>Assignee: Martin Marinschek > >>Priority: Minor > >> Attachments: patches.diff, suggestAjax-length.png, suggestAjax-wrap.png > >> > >>During working on adding inputSuggestAjax functionality to tobagos in > >>component i found this problem: > >>1. maybe not realy a bug, but i dont like it: If the suggested item doesn't > >>fit into the popup div the content is wrapped (only if there are spaces). > >>see attached image suggestAjax-wrap.png. > >>2. and this is a bug: If the suggested item contains no Spaces and doesn't > >>fit into the popup div the items continue rendering out of the popupDiv. > >>see attached image suggestAjax-long.png. > >>problem 1 is easy to fix: just add "whitespace: nowrap;" to the LI style, > >>but this moves problem 1 to problem 2. > >>I'll try to fix this for tobago and provide a backport patch then. > > > > > > -- > Don't answer to From: address! > Mail to this account are droped if not recieved via mailinglist. > To contact me direct create the mail address by > concatenating my forename to my senders domain. > -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
[jira] Created: (MYFACES-863) HtmlTextareaRenderer method isDisabled generates an infinite loop
HtmlTextareaRenderer method isDisabled generates an infinite loop
-
Key: MYFACES-863
URL: http://issues.apache.org/jira/browse/MYFACES-863
Project: MyFaces
Type: Bug
Components: Tomahawk
Environment: I'm under W2k, eclipse 3.1. I've updated myfaces trunk 23/11/05
and build the jars. Tomahawk version is 347990, url
http://svn.apache.org/repos/asf/myfaces/tomahawk/trunk.
Reporter: Pablo Sosa
The HtmlTextareaRenderer isDisabled(FacesContext facesContext, UIComponent
uiComponent) contains a reference to itself. I'm not sure whether it should be
calling super.isDisabled on the impl project or something else.
protected boolean isDisabled(FacesContext facesContext, UIComponent
uiComponent)
{
if (!UserRoleUtils.isEnabledOnUserRole(uiComponent))
{
return true;
}
else
{
//This is causing the StackOverflow, entering in a infinite loop
return isDisabled(facesContext, uiComponent);
}
}
Log:
java.lang.StackOverflowError^M
at java.util.HashMap.get(HashMap.java:320)^M
at
javax.faces.component.UIComponentBase.getValueBinding(UIComponentBase.java:80)^M
at
org.apache.myfaces.component.html.ext.HtmlInputTextarea.getEnabledOnUserRole(HtmlInputTextarea.java:70)^M
at
org.apache.myfaces.component.UserRoleUtils.isEnabledOnUserRole(UserRoleUtils.java:80)^M
at
org.apache.myfaces.renderkit.html.ext.HtmlTextareaRenderer.isDisabled(HtmlTextareaRenderer.java:39)^M
:
:
-
Latest svn log entry
r166820 | manolito | 2004-05-19 02:31:40 +1200 (Wed, 19 May 2004) | 2 lines
user role support completely moved to components source tree
--
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: Defaulting to forceId=true
There are a couple reasons I went down that road, 1: at first, when trying to get things working, it was much easier to be able to directly access the component in javascript. I wanted to get this working without having to deal with unknown id's, and then come back to get it working for those cases. 2: If you reference the components in javascript by their derived id, for example: var component_form1:subview2:table3, javascript pukes, as would java or any other languages. This could be avoided I'm sure, but it was something that was occuring. 3: I have to make it work for forceId anyways so that I can access the components from javascript in a deterministic way. Travis On 11/22/05, Simon Kitching <[EMAIL PROTECTED]> wrote: > Hi Travis, > > I don't know anything about the AJAX compoents so please excuse me if > this is a silly question. But why are the AJAX components requiring > "forceId" in the first place? > > If a component's true id at the back end is "form1:subview2:table3", > then why not use that id in all the AJAX stuff rather than requiring the > table to use forceId? > > Travis Reeder wrote: > > Yes, I can use forceId=true when I want it, but my sentiments exactly > > (about altering the id), if I set an ID, it would be nice to not have > > to set forceId="true" also. Especially in this new rich client / > > ajaxing era that we seem to be rolling into. >
[jira] Updated: (MYFACES-862) focus component
[ http://issues.apache.org/jira/browse/MYFACES-862?page=all ] Rogério Pereira Araújo updated MYFACES-862: --- Attachment: myfaces_sandbox.tld.diff > focus component > --- > > Key: MYFACES-862 > URL: http://issues.apache.org/jira/browse/MYFACES-862 > Project: MyFaces > Type: Improvement > Components: Sandbox > Reporter: Rogério Pereira Araújo > Attachments: HtmlFocus.java, HtmlFocusRenderer.java, HtmlFocusTag.java, > myfaces_sandbox.tld.diff > > I created this component to make easier manage the focus on form controls > across every page reload... -- 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-817) Runtime error using Tomahawk dataTable + selectBooleanCheckboxes (MyFaces 1.1.1)
[ http://issues.apache.org/jira/browse/MYFACES-817?page=comments#action_12358304 ] Thomas A. Valletta commented on MYFACES-817: I am getting the same error. I don't know that the cause is the same, but it may be. I have created a CustomComponent that allows me to insert a component that I have programmatically defined in the java (not the jsp). The component works just like it should, until I try to add a EditableValueHolder and render it inside of a tamahawk datatable. When I do that, I get this error. I can dynamically render any other component (HtmlOutputText, HtmlCommandButton, etc.). I have tried both MyFaces 1.1.1 and the nightly with the same results. I would be glad to provide more detail if it would be helpful. SEVERE: Servlet.service() for servlet jsp threw exception java.lang.NullPointerException at org.apache.myfaces.component.html.ext.HtmlDataTableHack.restoreDescendantComponentStates(HtmlDataTableHack.java:245) at org.apache.myfaces.component.html.ext.HtmlDataTableHack.restoreDescendantComponentStates(HtmlDataTableHack.java:257) at org.apache.myfaces.component.html.ext.HtmlDataTableHack.restoreDescendantComponentStates(HtmlDataTableHack.java:257) at org.apache.myfaces.component.html.ext.HtmlDataTableHack.restoreDescendantComponentStates(HtmlDataTableHack.java:257) at org.apache.myfaces.component.html.ext.HtmlDataTableHack.restoreDescendantComponentStates(HtmlDataTableHack.java:257) at org.apache.myfaces.component.html.ext.HtmlDataTableHack.restoreDescendantComponentStates(HtmlDataTableHack.java:257) at org.apache.myfaces.component.html.ext.HtmlDataTableHack.restoreDescendantComponentStates(HtmlDataTableHack.java:257) at org.apache.myfaces.component.html.ext.HtmlDataTableHack.setRowIndex(HtmlDataTableHack.java:208) at org.apache.myfaces.component.html.ext.HtmlDataTable.setRowIndex(HtmlDataTable.java:129) at org.apache.myfaces.renderkit.html.HtmlTableRendererBase.encodeInnerHtml(HtmlTableRendererBase.java:135) at org.apache.myfaces.renderkit.html.HtmlTableRendererBase.encodeChildren(HtmlTableRendererBase.java:94) at org.apache.myfaces.renderkit.html.ext.HtmlTableRenderer.encodeChildren(HtmlTableRenderer.java:57) at javax.faces.component.UIComponentBase.encodeChildren(UIComponentBase.java:319) at org.apache.myfaces.renderkit.RendererUtils.renderChild(RendererUtils.java:444) at org.apache.myfaces.renderkit.RendererUtils.renderChildren(RendererUtils.java:427) at xxx.xxx.xxx.xxx.xxx.xxx.AjaxDragSorterRenderer.encodeEnd(AjaxDragSorterRenderer.java:80) at javax.faces.component.UIComponentBase.encodeEnd(UIComponentBase.java:331) at org.apache.myfaces.renderkit.RendererUtils.renderChild(RendererUtils.java:450) at org.apache.myfaces.renderkit.RendererUtils.renderChildren(RendererUtils.java:427) at org.apache.myfaces.renderkit.html.HtmlGroupRendererBase.encodeEnd(HtmlGroupRendererBase.java:62) at javax.faces.component.UIComponentBase.encodeEnd(UIComponentBase.java:331) at org.apache.myfaces.renderkit.RendererUtils.renderChild(RendererUtils.java:450) at org.apache.myfaces.renderkit.html.HtmlGridRendererBase.renderChildren(HtmlGridRendererBase.java:203) at org.apache.myfaces.renderkit.html.HtmlGridRendererBase.encodeEnd(HtmlGridRendererBase.java:85) at javax.faces.component.UIComponentBase.encodeEnd(UIComponentBase.java:331) at org.apache.myfaces.renderkit.RendererUtils.renderChild(RendererUtils.java:450) at org.apache.myfaces.renderkit.RendererUtils.renderChildren(RendererUtils.java:427) at org.apache.myfaces.renderkit.RendererUtils.renderChild(RendererUtils.java:448) at org.apache.myfaces.renderkit.RendererUtils.renderChildren(RendererUtils.java:427) at org.apache.myfaces.renderkit.html.HtmlGroupRendererBase.encodeEnd(HtmlGroupRendererBase.java:62) at javax.faces.component.UIComponentBase.encodeEnd(UIComponentBase.java:331) at org.apache.myfaces.renderkit.RendererUtils.renderChild(RendererUtils.java:450) at org.apache.myfaces.renderkit.html.HtmlGridRendererBase.renderChildren(HtmlGridRendererBase.java:203) at org.apache.myfaces.renderkit.html.HtmlGridRendererBase.encodeEnd(HtmlGridRendererBase.java:85) at javax.faces.component.UIComponentBase.encodeEnd(UIComponentBase.java:331) at javax.faces.webapp.UIComponentTag.encodeEnd(UIComponentTag.java:349) at javax.faces.webapp.UIComponentTag.doEndTag(UIComponentTag.java:253) at org.apache.myfaces.taglib.UIComponentBodyTagBase.doEndTag(UIComponentBodyTagBase.java:55) at org.apache.jsp.agenda.agenda_002dedit_jsp._jspx_meth_h_panelGrid_0(org.apache.jsp.agenda.agenda_002dedit_jsp:406) at org.apache.jsp.agenda.agenda_002dedit_jsp._jspx_meth_x_di
[jira] Closed: (MYFACES-861) Messages_pt_BR.properties update
[ http://issues.apache.org/jira/browse/MYFACES-861?page=all ] Grant Smith closed MYFACES-861: --- Fix Version: Nightly Resolution: Fixed Thank you (Obgrigado ??) ! > Messages_pt_BR.properties update > > > Key: MYFACES-861 > URL: http://issues.apache.org/jira/browse/MYFACES-861 > Project: MyFaces > Type: Improvement > Components: Implementation > Reporter: Rogério Pereira Araújo > Assignee: Grant Smith > Fix For: Nightly > Attachments: Messages_pt_BR.properties > > the Messages_pt_BR.properties updated, please commit -- 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: (MYFACES-775) Exception in inputDate
[ http://issues.apache.org/jira/browse/MYFACES-775?page=all ] Will Norris updated MYFACES-775: Attachment: HtmlInputDate.diff The problem is a NumberFormatException that gets thrown by Integer.parse and is never caught. HtmlInputDate$UserData.parse should be catching this and throwing a new ParseException, which the attached diff does. I'm not completely sure what the offset should be for the ParseException, since it doesn't exactly apply in this case, so I just put 0. Perhaps it should be one of the static ints in Calendar (Calendar.YEAR, Calendar.MONTH, etc) to designate which field caused the exception. However that would require a separate try/catch block for each item (total of 8 I think) -- not necessarily a bad thing if you're actually going to do something with it on the other side, but probably superfluous for the time being. > Exception in inputDate > -- > > Key: MYFACES-775 > URL: http://issues.apache.org/jira/browse/MYFACES-775 > Project: MyFaces > Type: Bug > Components: Tomahawk > Versions: 1.1.1 > Environment: myfaces-api.jar, myfaces-impl.jar, tomahawk.jar > Reporter: Kristina Feldmann > Attachments: HtmlInputDate.diff > > There is a NumberFormatException if a InputField is empty. -- 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: Use of JSF RI Javadocs in myfaces
Write a program that takes the JSF 1.1 and 1.2 docs, identifies the docs that are NOT identical to JSF 1.1 docs, and creates a patch for those that are the same. Then you should have a significant amount of the javadocs without using any JSF 1.1 docs :) Then it's just a matter of writing docs for things that have changed. I'd probably try to get as early a snapshot of the JSF 1.2 stuff as possible so the least amount of changes have occurred. On 11/22/05, Grant Smith <[EMAIL PROTECTED]> wrote: > I would say definitely copy the JSF1.2 javadocs, but perhaps wait until they > are finalized ? > If you can add javadocs that are reverse engineered, and are even more > detailed than the exisiting 1.1 stuff, then great! > > > On 11/22/05, Simon Kitching < [EMAIL PROTECTED]> wrote: > > Bruno Aranda wrote: > > > Hi devs, > > > > > > I've talked with Ed Burns in the ##jsf irc channel and he has got a > > > final answer on the question whether or not we can use the RI > > > javadocs. He has said that we CAN'T use the JSF 1.1 Javadocs because > > > it is not under the CDDL, but we CAN use the javadocs for JSF 1.2, > > > > That's good news. > > > > So the question is now: what should be done for the current release? > > > > (a) > > Write javadoc for the MyFaces API classes by copying from the JSF1.2 > > javadoc and trimming out the bits that aren't relevant to 1.1 > > > > (b) > > Go with javadoc reverse-engineered for the code for the current MyFaces > > releases, and merge in the JSF1.2 javadoc when MyFaces branches for 1.2 > > support? > > > > > > By the way, I've also asked on legal-discuss@apache.org about writing > > javadoc based on the code, and the opinions so far are that there is no > > problem with that. I'd therefore like to commit some docs as soon as > > there is a decision on A vs B above (written using approach B of course). > > > > Cheers, > > > > Simon > > > > > > -- > Grant Smith >
[jira] Updated: (MYFACES-862) focus component
[ http://issues.apache.org/jira/browse/MYFACES-862?page=all ] Rogério Pereira Araújo updated MYFACES-862: --- Attachment: HtmlFocusTag.java > focus component > --- > > Key: MYFACES-862 > URL: http://issues.apache.org/jira/browse/MYFACES-862 > Project: MyFaces > Type: Improvement > Components: Sandbox > Reporter: Rogério Pereira Araújo > Attachments: HtmlFocus.java, HtmlFocusRenderer.java, HtmlFocusTag.java > > I created this component to make easier manage the focus on form controls > across every page reload... -- 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: (MYFACES-862) focus component
[ http://issues.apache.org/jira/browse/MYFACES-862?page=all ] Rogério Pereira Araújo updated MYFACES-862: --- Attachment: HtmlFocusRenderer.java > focus component > --- > > Key: MYFACES-862 > URL: http://issues.apache.org/jira/browse/MYFACES-862 > Project: MyFaces > Type: Improvement > Components: Sandbox > Reporter: Rogério Pereira Araújo > Attachments: HtmlFocus.java, HtmlFocusRenderer.java, HtmlFocusTag.java > > I created this component to make easier manage the focus on form controls > across every page reload... -- 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: Setting states in PanelNavigation (static)
Erik, please open a jira issue for this. Thank you ThomasOn 11/22/05, Erik J <[EMAIL PROTECTED]> wrote: Hello,This posting was previously sent to the "User" list, but since nobodyanswered, I suppose it was the wrong forum. Sorry if this question doesn'tbelong here either...I would like to know if there is a way to change the behavior of how Panelnavigation sets the different states (mypage, open and selected) of theitems in the navigationlist. What I would like to do is to make any linkclicked bold, nomatter which level it is on.For example: If I first click on "Online Shop", I can make it bold since it is of state "selected". If I then click"Product Information" it gets thestate "open" (which I can make bold), but "Online shop" remains "selected"and thus still bold. Clicking items that has subitems doesn't make them "selected", only "open". What i want is simply that nomatter which of them Iclick, only that item gets the state "selected" so that only that item canbe make bold (and thereby distinguishable). Does anyone know if this is possible to achieve? I guess thatHtmlCommandNavigation.class is part of the solution, but I don't know.Thanks for your time,Erik_ Lättare att hitta drömresan med MSN Resor http://www.msn.se/resor/-- http://www.irian.at Your JSF powerhouse -JSF Consulting, Development andCourses in English and GermanProfessional Support for Apache MyFaces
[jira] Updated: (MYFACES-862) focus component
[ http://issues.apache.org/jira/browse/MYFACES-862?page=all ] Rogério Pereira Araújo updated MYFACES-862: --- Attachment: HtmlFocus.java > focus component > --- > > Key: MYFACES-862 > URL: http://issues.apache.org/jira/browse/MYFACES-862 > Project: MyFaces > Type: Improvement > Components: Sandbox > Reporter: Rogério Pereira Araújo > Attachments: HtmlFocus.java > > I created this component to make easier manage the focus on form controls > across every page reload... -- 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: (MYFACES-862) focus component
focus component --- Key: MYFACES-862 URL: http://issues.apache.org/jira/browse/MYFACES-862 Project: MyFaces Type: Improvement Components: Sandbox Reporter: Rogério Pereira Araújo Attachments: HtmlFocus.java I created this component to make easier manage the focus on form controls across every page reload... -- 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: (MYFACES-861) Messages_pt_BR.properties update
[ http://issues.apache.org/jira/browse/MYFACES-861?page=all ] Rogério Pereira Araújo updated MYFACES-861: --- Attachment: Messages_pt_BR.properties Messages_pt_BR.properties > Messages_pt_BR.properties update > > > Key: MYFACES-861 > URL: http://issues.apache.org/jira/browse/MYFACES-861 > Project: MyFaces > Type: Improvement > Components: Implementation > Reporter: Rogério Pereira Araújo > Attachments: Messages_pt_BR.properties > > the Messages_pt_BR.properties updated, please commit -- 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: (MYFACES-861) Messages_pt_BR.properties update
Messages_pt_BR.properties update Key: MYFACES-861 URL: http://issues.apache.org/jira/browse/MYFACES-861 Project: MyFaces Type: Improvement Components: Implementation Reporter: Rogério Pereira Araújo Attachments: Messages_pt_BR.properties the Messages_pt_BR.properties updated, please commit -- 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: Use of JSF RI Javadocs in myfaces
I would say definitely copy the JSF1.2 javadocs, but perhaps wait until they are finalized ? If you can add javadocs that are reverse engineered, and are even more detailed than the exisiting 1.1 stuff, then great!On 11/22/05, Simon Kitching < [EMAIL PROTECTED]> wrote:Bruno Aranda wrote: > Hi devs,>> I've talked with Ed Burns in the ##jsf irc channel and he has got a> final answer on the question whether or not we can use the RI> javadocs. He has said that we CAN'T use the JSF 1.1 Javadocs because> it is not under the CDDL, but we CAN use the javadocs for JSF 1.2,That's good news.So the question is now: what should be done for the current release?(a)Write javadoc for the MyFaces API classes by copying from the JSF1.2javadoc and trimming out the bits that aren't relevant to 1.1(b)Go with javadoc reverse-engineered for the code for the current MyFacesreleases, and merge in the JSF1.2 javadoc when MyFaces branches for 1.2support?By the way, I've also asked on legal-discuss@apache.org about writingjavadoc based on the code, and the opinions so far are that there is no problem with that. I'd therefore like to commit some docs as soon asthere is a decision on A vs B above (written using approach B of course).Cheers,Simon-- Grant Smith
Re: Use of JSF RI Javadocs in myfaces
Bruno Aranda wrote: Hi devs, I've talked with Ed Burns in the ##jsf irc channel and he has got a final answer on the question whether or not we can use the RI javadocs. He has said that we CAN'T use the JSF 1.1 Javadocs because it is not under the CDDL, but we CAN use the javadocs for JSF 1.2, That's good news. So the question is now: what should be done for the current release? (a) Write javadoc for the MyFaces API classes by copying from the JSF1.2 javadoc and trimming out the bits that aren't relevant to 1.1 (b) Go with javadoc reverse-engineered for the code for the current MyFaces releases, and merge in the JSF1.2 javadoc when MyFaces branches for 1.2 support? By the way, I've also asked on legal-discuss@apache.org about writing javadoc based on the code, and the opinions so far are that there is no problem with that. I'd therefore like to commit some docs as soon as there is a decision on A vs B above (written using approach B of course). Cheers, Simon
Re: Defaulting to forceId=true
Hi Travis, I don't know anything about the AJAX compoents so please excuse me if this is a silly question. But why are the AJAX components requiring "forceId" in the first place? If a component's true id at the back end is "form1:subview2:table3", then why not use that id in all the AJAX stuff rather than requiring the table to use forceId? Travis Reeder wrote: Yes, I can use forceId=true when I want it, but my sentiments exactly (about altering the id), if I set an ID, it would be nice to not have to set forceId="true" also. Especially in this new rich client / ajaxing era that we seem to be rolling into.
[jira] Closed: (MYFACES-860) tomahawk.tld and myfaces_ext.tld is malformed errors in weblogic log
[ http://issues.apache.org/jira/browse/MYFACES-860?page=all ] Simon Kitching closed MYFACES-860: -- Fix Version: Nightly Resolution: Fixed Fixed in SVN already > tomahawk.tld and myfaces_ext.tld is malformed errors in weblogic log > > > Key: MYFACES-860 > URL: http://issues.apache.org/jira/browse/MYFACES-860 > Project: MyFaces > Type: Bug > Versions: Nightly > Reporter: Paul Klaer > Fix For: Nightly > > Both use and html format tags for the description element and > weblogic shows this errors on the log file several times > Weblogic errors: > /META-INF/tomahawk.tld" is malformed. Check against the DTD: Element type "p" > must be declared. (line 5316, column 16).> > tomahawk.tld" is malformed. Check against the DTD: Element type "i" must be > declared. (line 5326, column 25).> > myfaces_ext.tld" is malformed. Check against the DTD: Element type "p" must > be declared. (line 5316, column 16).> > /META-INF/myfaces_ext.tld" is malformed. Check against the DTD: Element type > "i" must be declared. (line 5326, column 25).> -- 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-860) tomahawk.tld and myfaces_ext.tld is malformed errors in weblogic log
[ http://issues.apache.org/jira/browse/MYFACES-860?page=comments#action_12358295 ] Simon Kitching commented on MYFACES-860: Actually, myfaces_ext.tld was *renamed* to tomahawk.tld on 2005-08-10. There is therefore no myfaces_ext.tld in SVN. However for backwards compatibility, the tomahawk build.xml copies tomahawk.tld to myfaces_ext.tld, and tweaks the library URL to be the same as the old tld's URL. So just rebuild and the problem should go away. r231038 | schof | 2005-08-10 02:15:32 +1200 (Wed, 10 Aug 2005) | 1 line Changed paths: D /myfaces/tomahawk/trunk/tld/myfaces_ext.tld A /myfaces/tomahawk/trunk/tld/tomahawk.tld (from /myfaces/tomahawk/trunk/tld/myfaces_ext.tld:231037) Regards, Simon > tomahawk.tld and myfaces_ext.tld is malformed errors in weblogic log > > > Key: MYFACES-860 > URL: http://issues.apache.org/jira/browse/MYFACES-860 > Project: MyFaces > Type: Bug > Versions: Nightly > Reporter: Paul Klaer > Fix For: Nightly > > Both use and html format tags for the description element and > weblogic shows this errors on the log file several times > Weblogic errors: > /META-INF/tomahawk.tld" is malformed. Check against the DTD: Element type "p" > must be declared. (line 5316, column 16).> > tomahawk.tld" is malformed. Check against the DTD: Element type "i" must be > declared. (line 5326, column 25).> > myfaces_ext.tld" is malformed. Check against the DTD: Element type "p" must > be declared. (line 5316, column 16).> > /META-INF/myfaces_ext.tld" is malformed. Check against the DTD: Element type > "i" must be declared. (line 5326, column 25).> -- 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-860) tomahawk.tld and myfaces_ext.tld is malformed errors in weblogic log
[ http://issues.apache.org/jira/browse/MYFACES-860?page=comments#action_12358292 ] Paul Klaer commented on MYFACES-860: Yes you're right, its done for the tomahawk.tld file. But the myfaces_ext.tld has still and tags. Line 804 where commandSortHeader is defined. > tomahawk.tld and myfaces_ext.tld is malformed errors in weblogic log > > > Key: MYFACES-860 > URL: http://issues.apache.org/jira/browse/MYFACES-860 > Project: MyFaces > Type: Bug > Versions: Nightly > Reporter: Paul Klaer > > Both use and html format tags for the description element and > weblogic shows this errors on the log file several times > Weblogic errors: > /META-INF/tomahawk.tld" is malformed. Check against the DTD: Element type "p" > must be declared. (line 5316, column 16).> > tomahawk.tld" is malformed. Check against the DTD: Element type "i" must be > declared. (line 5326, column 25).> > myfaces_ext.tld" is malformed. Check against the DTD: Element type "p" must > be declared. (line 5316, column 16).> > /META-INF/myfaces_ext.tld" is malformed. Check against the DTD: Element type > "i" must be declared. (line 5326, column 25).> -- 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: Changes in UIComponentTag.java
This would be me as well, learning quickly that this stuff is not to be touched. ;) It'll all be changed back with my next checkin. Travis On 11/22/05, Martin Marinschek <[EMAIL PROTECTED]> wrote: > Someone changed a method in UIComponentTag.java from private to protected. > > Attention: this is no good idea. We are not allowed to change the > signature of any class of the javax.faces.* package. Especially, you > are not allowed to add public or protected methods. Whatever the > reason for this change, we need to change elsewhere, sorry. > > regards, > > Martin >
Re: Generated Code
Right. The code generator is currently not working, and needs to be urgently put back into the build process. It was lost in the reorganization. I was going to attempt to resurrect it, but ran into a major time constraint problem in my real job :) You're welcome to take a shot at it, but you'd have to get the code from the prior-to-reorg SVN.On 11/22/05, Travis Reeder <[EMAIL PROTECTED] > wrote:Hi all,In the components, there are sections that are wrapped with GENERATED CODE BEGIN and GENERATED CODE END. How are these generated? Reason Iask is that there are new fields like forceId and escape that theirstate is not being saved/restored.Thanks in advance,Travis -- Grant Smith
Generated Code
Hi all, In the components, there are sections that are wrapped with GENERATED CODE BEGIN and GENERATED CODE END. How are these generated? Reason I ask is that there are new fields like forceId and escape that their state is not being saved/restored. Thanks in advance, Travis
Re: Defaulting to forceId=true
Yes, I can use forceId=true when I want it, but my sentiments exactly (about altering the id), if I set an ID, it would be nice to not have to set forceId="true" also. Especially in this new rich client / ajaxing era that we seem to be rolling into. Thanks for the info on what's going on Adam. Travis On 11/22/05, Adam Winer <[EMAIL PROTECTED]> wrote: > Sean, > > IMO, the lamenesses are that UIForm is a NamingContainer, > and is required for includes. I argued strongly > against the former during JSF 1.0, but couldn't turn the tide. > The latter's been cleared up for JSF 1.2 (and despite what > the spec said, wasn't ever *really* required), > and prefixing can be turned of for UIForms too in JSF 1.2. > > Subtract these two issues, and "forceId" isn't especially > necessary or useful. > > Regards, > Adam > > > On 11/22/05, Sean Schofield <[EMAIL PROTECTED]> wrote: > > Is there any particular reason why you can't just use forceId=true for > > when you want it? My thinking is that its better to give the user the > > flexability to decide rather then "force" them into a particular > > choice. (Which is why I think its lame that JSF alters your id when > > generating the client id.) > > > > sean > > > > On 11/18/05, Travis Reeder <[EMAIL PROTECTED]> wrote: > > > Working on this ajax stuff, I got to wondering why we don't just have > > > id's implemented like forceId = true? Is there any reason why we > > > can't just have all id's set to the id the user specifies without > > > prepending stuff to them? > > > > > > Travis > > > > > >
Re: Defaulting to forceId=true
Sean, IMO, the lamenesses are that UIForm is a NamingContainer, and is required for includes. I argued strongly against the former during JSF 1.0, but couldn't turn the tide. The latter's been cleared up for JSF 1.2 (and despite what the spec said, wasn't ever *really* required), and prefixing can be turned of for UIForms too in JSF 1.2. Subtract these two issues, and "forceId" isn't especially necessary or useful. Regards, Adam On 11/22/05, Sean Schofield <[EMAIL PROTECTED]> wrote: > Is there any particular reason why you can't just use forceId=true for > when you want it? My thinking is that its better to give the user the > flexability to decide rather then "force" them into a particular > choice. (Which is why I think its lame that JSF alters your id when > generating the client id.) > > sean > > On 11/18/05, Travis Reeder <[EMAIL PROTECTED]> wrote: > > Working on this ajax stuff, I got to wondering why we don't just have > > id's implemented like forceId = true? Is there any reason why we > > can't just have all id's set to the id the user specifies without > > prepending stuff to them? > > > > Travis > > >
[jira] Commented: (MYFACES-860) tomahawk.tld and myfaces_ext.tld is malformed errors in weblogic log
[ http://issues.apache.org/jira/browse/MYFACES-860?page=comments#action_12358268 ] Mario Ivankovits commented on MYFACES-860: -- Duplicate of MYFACES-846 and should already be fixed. > tomahawk.tld and myfaces_ext.tld is malformed errors in weblogic log > > > Key: MYFACES-860 > URL: http://issues.apache.org/jira/browse/MYFACES-860 > Project: MyFaces > Type: Bug > Versions: Nightly > Reporter: Paul Klaer > > Both use and html format tags for the description element and > weblogic shows this errors on the log file several times > Weblogic errors: > /META-INF/tomahawk.tld" is malformed. Check against the DTD: Element type "p" > must be declared. (line 5316, column 16).> > tomahawk.tld" is malformed. Check against the DTD: Element type "i" must be > declared. (line 5326, column 25).> > myfaces_ext.tld" is malformed. Check against the DTD: Element type "p" must > be declared. (line 5316, column 16).> > /META-INF/myfaces_ext.tld" is malformed. Check against the DTD: Element type > "i" must be declared. (line 5326, column 25).> -- 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: Building MyFaces [resolved]
That was what I was missing. I needed to run clean first. Thanks for your help. -- James Mitchell Software Engineer / Open Source Evangelist Consulting / Mentoring / Freelance EdgeTech, Inc. http://www.edgetechservices.net/ 678.910.8017 AIM: jmitchtx MSN: [EMAIL PROTECTED] Skype: jmitchtx - Original Message - From: "Bruno Aranda" <[EMAIL PROTECTED]> To: "MyFaces Development" Sent: Tuesday, November 22, 2005 9:44 AM Subject: Re: Building MyFaces Sorry, when I get obsessed with an idea, my lonely neuron stops... ;-) However I've just run the build without problems. Have you tried to clean everything first? It seems to me that there is already a folder simple.war or the build creates it (I don't know why), so it says is not a file? Bruno 2005/11/22, James Mitchell <[EMAIL PROTECTED]>: --- build/build.xml --- ... ... ... --- build/build.xml --- I'm just running 'ant', so yes. Is that not what I'm suppose to do? -- James Mitchell Software Engineer / Open Source Evangelist Consulting / Mentoring / Freelance EdgeTech, Inc. http://www.edgetechservices.net/ 678.910.8017 AIM: jmitchtx MSN: [EMAIL PROTECTED] Skype: jmitchtx - Original Message - From: "Bruno Aranda" <[EMAIL PROTECTED]> To: "MyFaces Development" Sent: Tuesday, November 22, 2005 9:23 AM Subject: Re: Building MyFaces Are you running the "dist-all" target? I don't see it... > $ ant dist-all Bruno 2005/11/22, James Mitchell <[EMAIL PROTECTED]>: > Yes, that's what I did. > > > > [EMAIL PROTECTED] ~/svn/myfaces > > $ cd build/ > > > > [EMAIL PROTECTED] ~/svn/myfaces/build > > $ ant > > Did I do something wrong? > > > -- > James Mitchell > Software Engineer / Open Source Evangelist > Consulting / Mentoring / Freelance > EdgeTech, Inc. > http://www.edgetechservices.net/ > 678.910.8017 > AIM: jmitchtx > MSN: [EMAIL PROTECTED] > Skype: jmitchtx > > - Original Message - > From: "Bruno Aranda" <[EMAIL PROTECTED]> > To: "MyFaces Development" > Sent: Tuesday, November 22, 2005 8:47 AM > Subject: Re: Building MyFaces > > > You should execute 'ant dist-all' to build everything. And 'ant dist' > to build one specific subproject (inside the subproject/build folder). > All subprojects and main have the same build (one build to rule them > all), so ant dist-all is the specific target to build everything from > the main build folder... > > Regards, > > Bruno > > 2005/11/22, James Mitchell <[EMAIL PROTECTED]>: > > [EMAIL PROTECTED] ~/svn > > $ cd myfaces > > > > [EMAIL PROTECTED] ~/svn/myfaces > > $ ll > > total 0 > > drwxr-xr-x+ 5 jmitchell None 0 Nov 4 22:42 api > > drwxr-xr-x+ 7 jmitchell None 0 Nov 4 22:42 build > > drwxr-xr-x+ 11 jmitchell None 0 Nov 4 22:42 examples > > drwxr-xr-x+ 6 jmitchell None 0 Oct 26 22:51 forrest > > drwxr-xr-x+ 6 jmitchell None 0 Oct 26 22:48 impl > > drwxr-xr-x+ 2 jmitchell None 0 Oct 26 23:01 lib > > drwxr-xr-x+ 7 jmitchell None 0 Oct 26 22:49 sandbox > > drwxr-xr-x+ 4 jmitchell None 0 Oct 26 22:51 share > > drwxr-xr-x+ 7 jmitchell None 0 Oct 26 22:50 tomahawk > > > > [EMAIL PROTECTED] ~/svn/myfaces > > $ cd build/ > > > > [EMAIL PROTECTED] ~/svn/myfaces/build > > $ ant > > Buildfile: build.xml > > > > download-dependencies: > > [get] Getting: > > http://www.ibiblio.org/maven/commons-beanutils/jars/commons-beanutils-1.6.1.jar > > [get] To: > > C:\cygwin\home\jmitchell\svn\myfaces\lib\commons-beanutils.jar > > ... > > ... > > (snip) > > ... > > ... > > subproject: > > [echo] suproject : examples > > [echo] properties: examples/build.properties > > ... > > ... > > (snip) > > ... > > ... > > BUILD FAILED > > C:\cygwin\home\jmitchell\svn\myfaces\build\build.xml:790: The > > following > > error occurred while executing this line: > > C:\cygwin\home\jmitchell\svn\myfaces\build\build.xml:438: The > > following > > error occurred while executing this line: > > C:\cygwin\home\jmitchell\svn\myfaces\build\build.xml:404: The > > following > > error occurred while executing this line: > > C:\cygwin\home\jmitchell\svn\myfaces\examples\build\build.xml:859: The > > following error occurred while executing this line: > > C:\cygwin\home\jmitchell\svn\myfaces\examples\build\build.xml:904: > > C:\cygwin\home\jmitchell\svn\myfaces\examples\build\dist\simple.war is > > not > > a > > file. > > > > Total time: 23 minutes 39 seconds > > > > > > > > No compile or test errors, it just doesn' work. > > > > This worked fine for me a few days ago. Did I miss something > > recently? > > > > > > > > -- > > James Mitchell > > Software Engineer / Open Source Evangelist > > Consulting / Mentoring / Freelance > > EdgeTech, Inc. > > http://www.edgetechservices.net/ > > 678.910.8017 > > AIM: jmitchtx > > MSN: [EMAIL PROTECTED] > > Skype: jmitchtx > > > > > > > > >
Re: [jira] Commented: (MYFACES-705) Overflow problem with InputSuggestAjax
Hi Martin, are the nightly sandbox examples anywhere in public deployed? the examples at www.irian.at are without my patches. i can't do a fresh checkout here (@work) because my svn client can't https :-(. what is the problem? i had checked with opera, ie and mozilla before creating the patch. Regards Volker Martin Marinschek (JIRA) wrote: > [ > http://issues.apache.org/jira/browse/MYFACES-705?page=comments#action_12358239 > ] > > Martin Marinschek commented on MYFACES-705: > --- > > Volker, > > obviously your fix introduced another problem - the inputSuggestAjax > component doesn't render correctly in the IE anymore. > > Can you check this again? > > regards, > > Martin > > >>Overflow problem with InputSuggestAjax >>-- >> >> Key: MYFACES-705 >> URL: http://issues.apache.org/jira/browse/MYFACES-705 >> Project: MyFaces >>Type: Bug >> Components: Sandbox >>Versions: 1.1.2 >>Reporter: Volker Weber >>Assignee: Martin Marinschek >>Priority: Minor >> Attachments: patches.diff, suggestAjax-length.png, suggestAjax-wrap.png >> >>During working on adding inputSuggestAjax functionality to tobagos in >>component i found this problem: >>1. maybe not realy a bug, but i dont like it: If the suggested item doesn't >>fit into the popup div the content is wrapped (only if there are spaces). >>see attached image suggestAjax-wrap.png. >>2. and this is a bug: If the suggested item contains no Spaces and doesn't >>fit into the popup div the items continue rendering out of the popupDiv. >>see attached image suggestAjax-long.png. >>problem 1 is easy to fix: just add "whitespace: nowrap;" to the LI style, but >>this moves problem 1 to problem 2. >>I'll try to fix this for tobago and provide a backport patch then. > > -- Don't answer to From: address! Mail to this account are droped if not recieved via mailinglist. To contact me direct create the mail address by concatenating my forename to my senders domain.
[jira] Created: (MYFACES-860) tomahawk.tld and myfaces_ext.tld is malformed errors in weblogic log
tomahawk.tld and myfaces_ext.tld is malformed errors in weblogic log Key: MYFACES-860 URL: http://issues.apache.org/jira/browse/MYFACES-860 Project: MyFaces Type: Bug Versions: Nightly Reporter: Paul Klaer Both use and html format tags for the description element and weblogic shows this errors on the log file several times Weblogic errors: /META-INF/tomahawk.tld" is malformed. Check against the DTD: Element type "p" must be declared. (line 5316, column 16).> tomahawk.tld" is malformed. Check against the DTD: Element type "i" must be declared. (line 5326, column 25).> myfaces_ext.tld" is malformed. Check against the DTD: Element type "p" must be declared. (line 5316, column 16).> /META-INF/myfaces_ext.tld" is malformed. Check against the DTD: Element type "i" must be declared. (line 5326, column 25).> -- 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
Use of JSF RI Javadocs in myfaces
Hi devs, I've talked with Ed Burns in the ##jsf irc channel and he has got a final answer on the question whether or not we can use the RI javadocs. He has said that we CAN'T use the JSF 1.1 Javadocs because it is not under the CDDL, but we CAN use the javadocs for JSF 1.2, Best regards, Bruno
Re: Plan for 1.1.2?
inline--> 2005/11/22, Sean Schofield <[EMAIL PROTECTED]>: > Here is my take ... We all agree on the meaning of the "affects > version" field meaning the version reported against. So there always > needs to be a "Nightly" version to reflect problems with the lastest > and greatest source code. > > The "fix version" field has traditionally been used (by MyFaces) to > mark the version the bug was *actually* fixed in. So historically we > have been marking things fixed as nightly and then right when we > release (or at the point of a branch) we change nightly to the next > version number and add a new "nightly" version. What if someone reported with "affects [Nightly]". If we rename "Nightly" to "1.1.x" on releasing, the issue would now have the property "affects 1.1.x", which is wrong. Because the bug was actually FIXED in 1.1.x. > The release notes are also built of this scheduled version so IMO its > important to have the stuff marked as version x to be only what's > actually fixed in that version. In theory you could change the ones > you don't fix back to "nightly" if they don't get fixed but that is a > *tedious* process that generates a lot of spurious emails. (I'm > looking at setting up a custom email notification scheme for our > project btw that might cut down on some of this.) > > I think it would be good to have a free text field for "scheduled to > be fixed: " and have it be editable only by committers. We can then > create custom filters and reports in JIRA that essentially do what > Howard is trying to do here. Ultimately I think 3 fields are > required: reported, scheduled and actual. Since we are already using > the field in question for "actual" I think the new field should be > used for scheduled. Quick glance over Jira administration shows, that adding a custom field should not be too difficult. Well, the road map feature only works with the "Fix Version/s" field. So an additional "Scheduled for" field would not help us with the road map, right? Just had an offline discussions with Martin. In our opinion there is no need for a "scheduled for" field if we also take the Status and Resolution into account. This is our conclusion: There are actually two issues: 1. Correct use of "Affects Version" 2. Correct use of "Fix Version" ad 1. To actually reflect reality, there should not only be one "Nightly" version. We should better think of "Nightly - between 1.1.1 and 1.1.2" and see it as a released version rather than "unreleased". Why? If we use "Nightly" as a placeholder for the upcoming release, nobody should ever be allowed to use it as the "Affects" value, because otherwise renaming the version would have the sideeffect that I have mentioned above. Actually, in the "Affects Version" box, "Nightly" shows up under "Unreleased versions", which is confusing. We should interpret the meaning of released vs. unreleased version in Jira as "future" vs. "published" rather than "officially released" vs. "nightly". How can we solve this? Let's have more than one "Nightly" version over the time. Whenever we release a new official version, we also add a new "Nightly" version. To make it easy understandable for the reporter, we give each "Nightly" version a unique name: e.g. "Nightly - after 1.1.1" ad 2. It should be possible to add any future versions - and perhaps even give it a schedule date. Why not add a "1.2.0" version now with future schedule date, for instance? And why not have a "1.1.2" version right now? The rule of thumb for the resolving developer would be: Never use a "Nightly" version as "Fix Version". If we fix something, we select the next upcoming official release version. ie. "1.1.2" by now. This way we could even add issues for 1.2 development. "Fix version" would be "1.2". And if we are high-spirited we even give "1.2" a schedule date. ;-) Our road-map would be perfect this way and Howard will love all of us, right? Now, what would be the actions to be taken for the next release 1.1.2 ? - Filter all issues with "Fix version" 1.1.2 that are unresolved and alter them to 1.1.3 - Set version 1.1.2 to "released" - Add a new version "Nightly - after 1.1.2" and also set it to "released". Why? Because by the next day someone already might have downloaded a new nightly and wants to report something for it. - The release notes will be perfect. Athough not having double checked this, I believe that Jira only adds resolved issues to the notes for a certain release. It even does not matter because we have already postponed the open issues to 1.1.3 Can all questions be answered with this scheme? Q: "Is bug xy that I have reported for [Nightly-after 1.1.1] already fixed?" A: "Browse issue, see if it has been resolved already. If resolved, look at the date and get a suitable nightly!" Q: "When will the bug xy be fixed?" A: "Look at the road map!" Q: "Which unofficial nightly version bug xy was reported for?" A: "Browse issue. See "Affects Version" field!" - And if you are lu
Re: Building MyFaces
Sorry, when I get obsessed with an idea, my lonely neuron stops... ;-) However I've just run the build without problems. Have you tried to clean everything first? It seems to me that there is already a folder simple.war or the build creates it (I don't know why), so it says is not a file? Bruno 2005/11/22, James Mitchell <[EMAIL PROTECTED]>: > --- build/build.xml --- > ... > > > ... > ... > --- build/build.xml --- > > > > I'm just running 'ant', so yes. Is that not what I'm suppose to do? > > > > > -- > James Mitchell > Software Engineer / Open Source Evangelist > Consulting / Mentoring / Freelance > EdgeTech, Inc. > http://www.edgetechservices.net/ > 678.910.8017 > AIM: jmitchtx > MSN: [EMAIL PROTECTED] > Skype: jmitchtx > > - Original Message - > From: "Bruno Aranda" <[EMAIL PROTECTED]> > To: "MyFaces Development" > Sent: Tuesday, November 22, 2005 9:23 AM > Subject: Re: Building MyFaces > > > Are you running the "dist-all" target? I don't see it... > > > $ ant dist-all > > Bruno > > 2005/11/22, James Mitchell <[EMAIL PROTECTED]>: > > Yes, that's what I did. > > > > > > > [EMAIL PROTECTED] ~/svn/myfaces > > > $ cd build/ > > > > > > [EMAIL PROTECTED] ~/svn/myfaces/build > > > $ ant > > > > Did I do something wrong? > > > > > > -- > > James Mitchell > > Software Engineer / Open Source Evangelist > > Consulting / Mentoring / Freelance > > EdgeTech, Inc. > > http://www.edgetechservices.net/ > > 678.910.8017 > > AIM: jmitchtx > > MSN: [EMAIL PROTECTED] > > Skype: jmitchtx > > > > - Original Message - > > From: "Bruno Aranda" <[EMAIL PROTECTED]> > > To: "MyFaces Development" > > Sent: Tuesday, November 22, 2005 8:47 AM > > Subject: Re: Building MyFaces > > > > > > You should execute 'ant dist-all' to build everything. And 'ant dist' > > to build one specific subproject (inside the subproject/build folder). > > All subprojects and main have the same build (one build to rule them > > all), so ant dist-all is the specific target to build everything from > > the main build folder... > > > > Regards, > > > > Bruno > > > > 2005/11/22, James Mitchell <[EMAIL PROTECTED]>: > > > [EMAIL PROTECTED] ~/svn > > > $ cd myfaces > > > > > > [EMAIL PROTECTED] ~/svn/myfaces > > > $ ll > > > total 0 > > > drwxr-xr-x+ 5 jmitchell None 0 Nov 4 22:42 api > > > drwxr-xr-x+ 7 jmitchell None 0 Nov 4 22:42 build > > > drwxr-xr-x+ 11 jmitchell None 0 Nov 4 22:42 examples > > > drwxr-xr-x+ 6 jmitchell None 0 Oct 26 22:51 forrest > > > drwxr-xr-x+ 6 jmitchell None 0 Oct 26 22:48 impl > > > drwxr-xr-x+ 2 jmitchell None 0 Oct 26 23:01 lib > > > drwxr-xr-x+ 7 jmitchell None 0 Oct 26 22:49 sandbox > > > drwxr-xr-x+ 4 jmitchell None 0 Oct 26 22:51 share > > > drwxr-xr-x+ 7 jmitchell None 0 Oct 26 22:50 tomahawk > > > > > > [EMAIL PROTECTED] ~/svn/myfaces > > > $ cd build/ > > > > > > [EMAIL PROTECTED] ~/svn/myfaces/build > > > $ ant > > > Buildfile: build.xml > > > > > > download-dependencies: > > > [get] Getting: > > > http://www.ibiblio.org/maven/commons-beanutils/jars/commons-beanutils-1.6.1.jar > > > [get] To: > > > C:\cygwin\home\jmitchell\svn\myfaces\lib\commons-beanutils.jar > > > ... > > > ... > > > (snip) > > > ... > > > ... > > > subproject: > > > [echo] suproject : examples > > > [echo] properties: examples/build.properties > > > ... > > > ... > > > (snip) > > > ... > > > ... > > > BUILD FAILED > > > C:\cygwin\home\jmitchell\svn\myfaces\build\build.xml:790: The following > > > error occurred while executing this line: > > > C:\cygwin\home\jmitchell\svn\myfaces\build\build.xml:438: The following > > > error occurred while executing this line: > > > C:\cygwin\home\jmitchell\svn\myfaces\build\build.xml:404: The following > > > error occurred while executing this line: > > > C:\cygwin\home\jmitchell\svn\myfaces\examples\build\build.xml:859: The > > > following error occurred while executing this line: > > > C:\cygwin\home\jmitchell\svn\myfaces\examples\build\build.xml:904: > > > C:\cygwin\home\jmitchell\svn\myfaces\examples\build\dist\simple.war is > > > not > > > a > > > file. > > > > > > Total time: 23 minutes 39 seconds > > > > > > > > > > > > No compile or test errors, it just doesn' work. > > > > > > This worked fine for me a few days ago. Did I miss something recently? > > > > > > > > > > > > -- > > > James Mitchell > > > Software Engineer / Open Source Evangelist > > > Consulting / Mentoring / Freelance > > > EdgeTech, Inc. > > > http://www.edgetechservices.net/ > > > 678.910.8017 > > > AIM: jmitchtx > > > MSN: [EMAIL PROTECTED] > > > Skype: jmitchtx > > > > > > > > > > > > > > > > > >
Re: Building MyFaces
--- build/build.xml --- ... ... ... --- build/build.xml --- I'm just running 'ant', so yes. Is that not what I'm suppose to do? -- James Mitchell Software Engineer / Open Source Evangelist Consulting / Mentoring / Freelance EdgeTech, Inc. http://www.edgetechservices.net/ 678.910.8017 AIM: jmitchtx MSN: [EMAIL PROTECTED] Skype: jmitchtx - Original Message - From: "Bruno Aranda" <[EMAIL PROTECTED]> To: "MyFaces Development" Sent: Tuesday, November 22, 2005 9:23 AM Subject: Re: Building MyFaces Are you running the "dist-all" target? I don't see it... $ ant dist-all Bruno 2005/11/22, James Mitchell <[EMAIL PROTECTED]>: Yes, that's what I did. > [EMAIL PROTECTED] ~/svn/myfaces > $ cd build/ > > [EMAIL PROTECTED] ~/svn/myfaces/build > $ ant Did I do something wrong? -- James Mitchell Software Engineer / Open Source Evangelist Consulting / Mentoring / Freelance EdgeTech, Inc. http://www.edgetechservices.net/ 678.910.8017 AIM: jmitchtx MSN: [EMAIL PROTECTED] Skype: jmitchtx - Original Message - From: "Bruno Aranda" <[EMAIL PROTECTED]> To: "MyFaces Development" Sent: Tuesday, November 22, 2005 8:47 AM Subject: Re: Building MyFaces You should execute 'ant dist-all' to build everything. And 'ant dist' to build one specific subproject (inside the subproject/build folder). All subprojects and main have the same build (one build to rule them all), so ant dist-all is the specific target to build everything from the main build folder... Regards, Bruno 2005/11/22, James Mitchell <[EMAIL PROTECTED]>: > [EMAIL PROTECTED] ~/svn > $ cd myfaces > > [EMAIL PROTECTED] ~/svn/myfaces > $ ll > total 0 > drwxr-xr-x+ 5 jmitchell None 0 Nov 4 22:42 api > drwxr-xr-x+ 7 jmitchell None 0 Nov 4 22:42 build > drwxr-xr-x+ 11 jmitchell None 0 Nov 4 22:42 examples > drwxr-xr-x+ 6 jmitchell None 0 Oct 26 22:51 forrest > drwxr-xr-x+ 6 jmitchell None 0 Oct 26 22:48 impl > drwxr-xr-x+ 2 jmitchell None 0 Oct 26 23:01 lib > drwxr-xr-x+ 7 jmitchell None 0 Oct 26 22:49 sandbox > drwxr-xr-x+ 4 jmitchell None 0 Oct 26 22:51 share > drwxr-xr-x+ 7 jmitchell None 0 Oct 26 22:50 tomahawk > > [EMAIL PROTECTED] ~/svn/myfaces > $ cd build/ > > [EMAIL PROTECTED] ~/svn/myfaces/build > $ ant > Buildfile: build.xml > > download-dependencies: > [get] Getting: > http://www.ibiblio.org/maven/commons-beanutils/jars/commons-beanutils-1.6.1.jar > [get] To: > C:\cygwin\home\jmitchell\svn\myfaces\lib\commons-beanutils.jar > ... > ... > (snip) > ... > ... > subproject: > [echo] suproject : examples > [echo] properties: examples/build.properties > ... > ... > (snip) > ... > ... > BUILD FAILED > C:\cygwin\home\jmitchell\svn\myfaces\build\build.xml:790: The following > error occurred while executing this line: > C:\cygwin\home\jmitchell\svn\myfaces\build\build.xml:438: The following > error occurred while executing this line: > C:\cygwin\home\jmitchell\svn\myfaces\build\build.xml:404: The following > error occurred while executing this line: > C:\cygwin\home\jmitchell\svn\myfaces\examples\build\build.xml:859: The > following error occurred while executing this line: > C:\cygwin\home\jmitchell\svn\myfaces\examples\build\build.xml:904: > C:\cygwin\home\jmitchell\svn\myfaces\examples\build\dist\simple.war is > not > a > file. > > Total time: 23 minutes 39 seconds > > > > No compile or test errors, it just doesn' work. > > This worked fine for me a few days ago. Did I miss something recently? > > > > -- > James Mitchell > Software Engineer / Open Source Evangelist > Consulting / Mentoring / Freelance > EdgeTech, Inc. > http://www.edgetechservices.net/ > 678.910.8017 > AIM: jmitchtx > MSN: [EMAIL PROTECTED] > Skype: jmitchtx > > >
Re: Building MyFaces
Are you running the "dist-all" target? I don't see it... > $ ant dist-all Bruno 2005/11/22, James Mitchell <[EMAIL PROTECTED]>: > Yes, that's what I did. > > > > [EMAIL PROTECTED] ~/svn/myfaces > > $ cd build/ > > > > [EMAIL PROTECTED] ~/svn/myfaces/build > > $ ant > > Did I do something wrong? > > > -- > James Mitchell > Software Engineer / Open Source Evangelist > Consulting / Mentoring / Freelance > EdgeTech, Inc. > http://www.edgetechservices.net/ > 678.910.8017 > AIM: jmitchtx > MSN: [EMAIL PROTECTED] > Skype: jmitchtx > > - Original Message - > From: "Bruno Aranda" <[EMAIL PROTECTED]> > To: "MyFaces Development" > Sent: Tuesday, November 22, 2005 8:47 AM > Subject: Re: Building MyFaces > > > You should execute 'ant dist-all' to build everything. And 'ant dist' > to build one specific subproject (inside the subproject/build folder). > All subprojects and main have the same build (one build to rule them > all), so ant dist-all is the specific target to build everything from > the main build folder... > > Regards, > > Bruno > > 2005/11/22, James Mitchell <[EMAIL PROTECTED]>: > > [EMAIL PROTECTED] ~/svn > > $ cd myfaces > > > > [EMAIL PROTECTED] ~/svn/myfaces > > $ ll > > total 0 > > drwxr-xr-x+ 5 jmitchell None 0 Nov 4 22:42 api > > drwxr-xr-x+ 7 jmitchell None 0 Nov 4 22:42 build > > drwxr-xr-x+ 11 jmitchell None 0 Nov 4 22:42 examples > > drwxr-xr-x+ 6 jmitchell None 0 Oct 26 22:51 forrest > > drwxr-xr-x+ 6 jmitchell None 0 Oct 26 22:48 impl > > drwxr-xr-x+ 2 jmitchell None 0 Oct 26 23:01 lib > > drwxr-xr-x+ 7 jmitchell None 0 Oct 26 22:49 sandbox > > drwxr-xr-x+ 4 jmitchell None 0 Oct 26 22:51 share > > drwxr-xr-x+ 7 jmitchell None 0 Oct 26 22:50 tomahawk > > > > [EMAIL PROTECTED] ~/svn/myfaces > > $ cd build/ > > > > [EMAIL PROTECTED] ~/svn/myfaces/build > > $ ant > > Buildfile: build.xml > > > > download-dependencies: > > [get] Getting: > > http://www.ibiblio.org/maven/commons-beanutils/jars/commons-beanutils-1.6.1.jar > > [get] To: > > C:\cygwin\home\jmitchell\svn\myfaces\lib\commons-beanutils.jar > > ... > > ... > > (snip) > > ... > > ... > > subproject: > > [echo] suproject : examples > > [echo] properties: examples/build.properties > > ... > > ... > > (snip) > > ... > > ... > > BUILD FAILED > > C:\cygwin\home\jmitchell\svn\myfaces\build\build.xml:790: The following > > error occurred while executing this line: > > C:\cygwin\home\jmitchell\svn\myfaces\build\build.xml:438: The following > > error occurred while executing this line: > > C:\cygwin\home\jmitchell\svn\myfaces\build\build.xml:404: The following > > error occurred while executing this line: > > C:\cygwin\home\jmitchell\svn\myfaces\examples\build\build.xml:859: The > > following error occurred while executing this line: > > C:\cygwin\home\jmitchell\svn\myfaces\examples\build\build.xml:904: > > C:\cygwin\home\jmitchell\svn\myfaces\examples\build\dist\simple.war is not > > a > > file. > > > > Total time: 23 minutes 39 seconds > > > > > > > > No compile or test errors, it just doesn' work. > > > > This worked fine for me a few days ago. Did I miss something recently? > > > > > > > > -- > > James Mitchell > > Software Engineer / Open Source Evangelist > > Consulting / Mentoring / Freelance > > EdgeTech, Inc. > > http://www.edgetechservices.net/ > > 678.910.8017 > > AIM: jmitchtx > > MSN: [EMAIL PROTECTED] > > Skype: jmitchtx > > > > > > > > >
[jira] Commented: (MYFACES-854) Problem w/ InputSuggestAjax popup suggestion list
[ http://issues.apache.org/jira/browse/MYFACES-854?page=comments#action_12358240 ] Martin Marinschek commented on MYFACES-854: --- I don't see what you see obviously you are missing the styles for inputSuggestAjax, and this might be due to the fact that your extensionsFilter is not setup properly. What I do see is that obviously a recent fix to the inputSuggestAjax CSS has introduced another problem - MYFACES-705 is connected to this. I asked Volker if he would change his patch, if he doesn't, we'll need to revert the patch for this bug. Please keep me updated on this problem! regards, Martin > Problem w/ InputSuggestAjax popup suggestion list > - > > Key: MYFACES-854 > URL: http://issues.apache.org/jira/browse/MYFACES-854 > Project: MyFaces > Type: Bug > Components: Sandbox > Versions: 1.1.2 > Environment: Win2K, IE 6.0.2800, MyFaces Nightly Build > Reporter: Chris Barlow > Attachments: suggestScreenShot.png > > The InputSuggestAjax popup div that contains the list of suggestions is > misaligned, missing mouse rollovers and items are not clickable. Look at the > sandbox example. -- 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: Building MyFaces
Yes, that's what I did. [EMAIL PROTECTED] ~/svn/myfaces $ cd build/ [EMAIL PROTECTED] ~/svn/myfaces/build $ ant Did I do something wrong? -- James Mitchell Software Engineer / Open Source Evangelist Consulting / Mentoring / Freelance EdgeTech, Inc. http://www.edgetechservices.net/ 678.910.8017 AIM: jmitchtx MSN: [EMAIL PROTECTED] Skype: jmitchtx - Original Message - From: "Bruno Aranda" <[EMAIL PROTECTED]> To: "MyFaces Development" Sent: Tuesday, November 22, 2005 8:47 AM Subject: Re: Building MyFaces You should execute 'ant dist-all' to build everything. And 'ant dist' to build one specific subproject (inside the subproject/build folder). All subprojects and main have the same build (one build to rule them all), so ant dist-all is the specific target to build everything from the main build folder... Regards, Bruno 2005/11/22, James Mitchell <[EMAIL PROTECTED]>: [EMAIL PROTECTED] ~/svn $ cd myfaces [EMAIL PROTECTED] ~/svn/myfaces $ ll total 0 drwxr-xr-x+ 5 jmitchell None 0 Nov 4 22:42 api drwxr-xr-x+ 7 jmitchell None 0 Nov 4 22:42 build drwxr-xr-x+ 11 jmitchell None 0 Nov 4 22:42 examples drwxr-xr-x+ 6 jmitchell None 0 Oct 26 22:51 forrest drwxr-xr-x+ 6 jmitchell None 0 Oct 26 22:48 impl drwxr-xr-x+ 2 jmitchell None 0 Oct 26 23:01 lib drwxr-xr-x+ 7 jmitchell None 0 Oct 26 22:49 sandbox drwxr-xr-x+ 4 jmitchell None 0 Oct 26 22:51 share drwxr-xr-x+ 7 jmitchell None 0 Oct 26 22:50 tomahawk [EMAIL PROTECTED] ~/svn/myfaces $ cd build/ [EMAIL PROTECTED] ~/svn/myfaces/build $ ant Buildfile: build.xml download-dependencies: [get] Getting: http://www.ibiblio.org/maven/commons-beanutils/jars/commons-beanutils-1.6.1.jar [get] To: C:\cygwin\home\jmitchell\svn\myfaces\lib\commons-beanutils.jar ... ... (snip) ... ... subproject: [echo] suproject : examples [echo] properties: examples/build.properties ... ... (snip) ... ... BUILD FAILED C:\cygwin\home\jmitchell\svn\myfaces\build\build.xml:790: The following error occurred while executing this line: C:\cygwin\home\jmitchell\svn\myfaces\build\build.xml:438: The following error occurred while executing this line: C:\cygwin\home\jmitchell\svn\myfaces\build\build.xml:404: The following error occurred while executing this line: C:\cygwin\home\jmitchell\svn\myfaces\examples\build\build.xml:859: The following error occurred while executing this line: C:\cygwin\home\jmitchell\svn\myfaces\examples\build\build.xml:904: C:\cygwin\home\jmitchell\svn\myfaces\examples\build\dist\simple.war is not a file. Total time: 23 minutes 39 seconds No compile or test errors, it just doesn' work. This worked fine for me a few days ago. Did I miss something recently? -- James Mitchell Software Engineer / Open Source Evangelist Consulting / Mentoring / Freelance EdgeTech, Inc. http://www.edgetechservices.net/ 678.910.8017 AIM: jmitchtx MSN: [EMAIL PROTECTED] Skype: jmitchtx
[jira] Commented: (MYFACES-705) Overflow problem with InputSuggestAjax
[ http://issues.apache.org/jira/browse/MYFACES-705?page=comments#action_12358239 ] Martin Marinschek commented on MYFACES-705: --- Volker, obviously your fix introduced another problem - the inputSuggestAjax component doesn't render correctly in the IE anymore. Can you check this again? regards, Martin > Overflow problem with InputSuggestAjax > -- > > Key: MYFACES-705 > URL: http://issues.apache.org/jira/browse/MYFACES-705 > Project: MyFaces > Type: Bug > Components: Sandbox > Versions: 1.1.2 > Reporter: Volker Weber > Assignee: Martin Marinschek > Priority: Minor > Attachments: patches.diff, suggestAjax-length.png, suggestAjax-wrap.png > > During working on adding inputSuggestAjax functionality to tobagos in > component i found this problem: > 1. maybe not realy a bug, but i dont like it: If the suggested item doesn't > fit into the popup div the content is wrapped (only if there are spaces). > see attached image suggestAjax-wrap.png. > 2. and this is a bug: If the suggested item contains no Spaces and doesn't > fit into the popup div the items continue rendering out of the popupDiv. > see attached image suggestAjax-long.png. > problem 1 is easy to fix: just add "whitespace: nowrap;" to the LI style, but > this moves problem 1 to problem 2. > I'll try to fix this for tobago and provide a backport patch then. -- 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: (MYFACES-859) TreeTable doesn't work properly while updating data
[ http://issues.apache.org/jira/browse/MYFACES-859?page=all ] Pawel Czerwinski updated MYFACES-859: - Attachment: treeTableTest.zip Files for tests > TreeTable doesn't work properly while updating data > --- > > Key: MYFACES-859 > URL: http://issues.apache.org/jira/browse/MYFACES-859 > Project: MyFaces > Type: Bug > Components: Tomahawk > Reporter: Pawel Czerwinski > Priority: Blocker > Attachments: treeTableTest.zip > > The TreeTable component cannot handle updating data. If I have inputs instead > of static text fields, > and I try to modify any node's value, it doesn't work. I've noticed, that if > I change a value > of the first node in a certain column, the value goes to the last visible > node of this particular > column. This happens within treeColumn, and ordinary columns as well. > I have prepared three simple test files (packed with zip), which will show > you the problem: > - Test.java (to map in the faces-config.xml as a 'test') > - test.jsp > - TreeItem.java (stores node value) > When you run the example, please try to change following nodes' values and > click "Send request" button > to see, how the model behaves. > Thank you in advance, > Pawel -- 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: (MYFACES-859) TreeTable doesn't work properly while updating data
TreeTable doesn't work properly while updating data --- Key: MYFACES-859 URL: http://issues.apache.org/jira/browse/MYFACES-859 Project: MyFaces Type: Bug Components: Tomahawk Reporter: Pawel Czerwinski Priority: Blocker The TreeTable component cannot handle updating data. If I have inputs instead of static text fields, and I try to modify any node's value, it doesn't work. I've noticed, that if I change a value of the first node in a certain column, the value goes to the last visible node of this particular column. This happens within treeColumn, and ordinary columns as well. I have prepared three simple test files (packed with zip), which will show you the problem: - Test.java (to map in the faces-config.xml as a 'test') - test.jsp - TreeItem.java (stores node value) When you run the example, please try to change following nodes' values and click "Send request" button to see, how the model behaves. Thank you in advance, Pawel -- 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: Building MyFaces
You should execute 'ant dist-all' to build everything. And 'ant dist' to build one specific subproject (inside the subproject/build folder). All subprojects and main have the same build (one build to rule them all), so ant dist-all is the specific target to build everything from the main build folder... Regards, Bruno 2005/11/22, James Mitchell <[EMAIL PROTECTED]>: > [EMAIL PROTECTED] ~/svn > $ cd myfaces > > [EMAIL PROTECTED] ~/svn/myfaces > $ ll > total 0 > drwxr-xr-x+ 5 jmitchell None 0 Nov 4 22:42 api > drwxr-xr-x+ 7 jmitchell None 0 Nov 4 22:42 build > drwxr-xr-x+ 11 jmitchell None 0 Nov 4 22:42 examples > drwxr-xr-x+ 6 jmitchell None 0 Oct 26 22:51 forrest > drwxr-xr-x+ 6 jmitchell None 0 Oct 26 22:48 impl > drwxr-xr-x+ 2 jmitchell None 0 Oct 26 23:01 lib > drwxr-xr-x+ 7 jmitchell None 0 Oct 26 22:49 sandbox > drwxr-xr-x+ 4 jmitchell None 0 Oct 26 22:51 share > drwxr-xr-x+ 7 jmitchell None 0 Oct 26 22:50 tomahawk > > [EMAIL PROTECTED] ~/svn/myfaces > $ cd build/ > > [EMAIL PROTECTED] ~/svn/myfaces/build > $ ant > Buildfile: build.xml > > download-dependencies: > [get] Getting: > http://www.ibiblio.org/maven/commons-beanutils/jars/commons-beanutils-1.6.1.jar > [get] To: > C:\cygwin\home\jmitchell\svn\myfaces\lib\commons-beanutils.jar > ... > ... > (snip) > ... > ... > subproject: > [echo] suproject : examples > [echo] properties: examples/build.properties > ... > ... > (snip) > ... > ... > BUILD FAILED > C:\cygwin\home\jmitchell\svn\myfaces\build\build.xml:790: The following > error occurred while executing this line: > C:\cygwin\home\jmitchell\svn\myfaces\build\build.xml:438: The following > error occurred while executing this line: > C:\cygwin\home\jmitchell\svn\myfaces\build\build.xml:404: The following > error occurred while executing this line: > C:\cygwin\home\jmitchell\svn\myfaces\examples\build\build.xml:859: The > following error occurred while executing this line: > C:\cygwin\home\jmitchell\svn\myfaces\examples\build\build.xml:904: > C:\cygwin\home\jmitchell\svn\myfaces\examples\build\dist\simple.war is not a > file. > > Total time: 23 minutes 39 seconds > > > > No compile or test errors, it just doesn' work. > > This worked fine for me a few days ago. Did I miss something recently? > > > > -- > James Mitchell > Software Engineer / Open Source Evangelist > Consulting / Mentoring / Freelance > EdgeTech, Inc. > http://www.edgetechservices.net/ > 678.910.8017 > AIM: jmitchtx > MSN: [EMAIL PROTECTED] > Skype: jmitchtx > > >
Setting states in PanelNavigation (static)
Hello, This posting was previously sent to the "User" list, but since nobody answered, I suppose it was the wrong forum. Sorry if this question doesn't belong here either... I would like to know if there is a way to change the behavior of how Panelnavigation sets the different states (mypage, open and selected) of the items in the navigationlist. What I would like to do is to make any link clicked bold, nomatter which level it is on. For example: If I first click on "Online Shop", I can make it bold since it is of state "selected". If I then click"Product Information" it gets the state "open" (which I can make bold), but "Online shop" remains "selected" and thus still bold. Clicking items that has subitems doesn't make them "selected", only "open". What i want is simply that nomatter which of them I click, only that item gets the state "selected" so that only that item can be make bold (and thereby distinguishable). Does anyone know if this is possible to achieve? I guess that HtmlCommandNavigation.class is part of the solution, but I don't know. Thanks for your time, Erik _ Lättare att hitta drömresan med MSN Resor http://www.msn.se/resor/
Building MyFaces
[EMAIL PROTECTED] ~/svn $ cd myfaces [EMAIL PROTECTED] ~/svn/myfaces $ ll total 0 drwxr-xr-x+ 5 jmitchell None 0 Nov 4 22:42 api drwxr-xr-x+ 7 jmitchell None 0 Nov 4 22:42 build drwxr-xr-x+ 11 jmitchell None 0 Nov 4 22:42 examples drwxr-xr-x+ 6 jmitchell None 0 Oct 26 22:51 forrest drwxr-xr-x+ 6 jmitchell None 0 Oct 26 22:48 impl drwxr-xr-x+ 2 jmitchell None 0 Oct 26 23:01 lib drwxr-xr-x+ 7 jmitchell None 0 Oct 26 22:49 sandbox drwxr-xr-x+ 4 jmitchell None 0 Oct 26 22:51 share drwxr-xr-x+ 7 jmitchell None 0 Oct 26 22:50 tomahawk [EMAIL PROTECTED] ~/svn/myfaces $ cd build/ [EMAIL PROTECTED] ~/svn/myfaces/build $ ant Buildfile: build.xml download-dependencies: [get] Getting: http://www.ibiblio.org/maven/commons-beanutils/jars/commons-beanutils-1.6.1.jar [get] To: C:\cygwin\home\jmitchell\svn\myfaces\lib\commons-beanutils.jar ... ... (snip) ... ... subproject: [echo] suproject : examples [echo] properties: examples/build.properties ... ... (snip) ... ... BUILD FAILED C:\cygwin\home\jmitchell\svn\myfaces\build\build.xml:790: The following error occurred while executing this line: C:\cygwin\home\jmitchell\svn\myfaces\build\build.xml:438: The following error occurred while executing this line: C:\cygwin\home\jmitchell\svn\myfaces\build\build.xml:404: The following error occurred while executing this line: C:\cygwin\home\jmitchell\svn\myfaces\examples\build\build.xml:859: The following error occurred while executing this line: C:\cygwin\home\jmitchell\svn\myfaces\examples\build\build.xml:904: C:\cygwin\home\jmitchell\svn\myfaces\examples\build\dist\simple.war is not a file. Total time: 23 minutes 39 seconds No compile or test errors, it just doesn' work. This worked fine for me a few days ago. Did I miss something recently? -- James Mitchell Software Engineer / Open Source Evangelist Consulting / Mentoring / Freelance EdgeTech, Inc. http://www.edgetechservices.net/ 678.910.8017 AIM: jmitchtx MSN: [EMAIL PROTECTED] Skype: jmitchtx
Re: Defaulting to forceId=true
Is there any particular reason why you can't just use forceId=true for when you want it? My thinking is that its better to give the user the flexability to decide rather then "force" them into a particular choice. (Which is why I think its lame that JSF alters your id when generating the client id.) sean On 11/18/05, Travis Reeder <[EMAIL PROTECTED]> wrote: > Working on this ajax stuff, I got to wondering why we don't just have > id's implemented like forceId = true? Is there any reason why we > can't just have all id's set to the id the user specifies without > prepending stuff to them? > > Travis >
Re: Plan for 1.1.2?
Here is my take ... We all agree on the meaning of the "affects version" field meaning the version reported against. So there always needs to be a "Nightly" version to reflect problems with the lastest and greatest source code. The "fix version" field has traditionally been used (by MyFaces) to mark the version the bug was *actually* fixed in. So historically we have been marking things fixed as nightly and then right when we release (or at the point of a branch) we change nightly to the next version number and add a new "nightly" version. The release notes are also built of this scheduled version so IMO its important to have the stuff marked as version x to be only what's actually fixed in that version. In theory you could change the ones you don't fix back to "nightly" if they don't get fixed but that is a *tedious* process that generates a lot of spurious emails. (I'm looking at setting up a custom email notification scheme for our project btw that might cut down on some of this.) I think it would be good to have a free text field for "scheduled to be fixed: " and have it be editable only by committers. We can then create custom filters and reports in JIRA that essentially do what Howard is trying to do here. Ultimately I think 3 fields are required: reported, scheduled and actual. Since we are already using the field in question for "actual" I think the new field should be used for scheduled. I also don't think its possible to have a separate version list for the two existing fields so IMO its better to keep the non-existent version numbers out of the list of choices presented to the average user. sean On 11/22/05, Martin Marinschek <[EMAIL PROTECTED]> wrote: > Yes, it does. > > in this case, we have been using this field in the wrong way so far. > > Sean, can you confirm? > > regards, > > Martin > > On 11/22/05, Abrams, Howard A <[EMAIL PROTECTED]> wrote: > > The field I changed is called 'fix-for' as in 'we should fix it for'. > > There is a separate field to mark what version the bug was reported > > against. AFAIK, there is no 'is fixed in'; that information in implied > > by having a bug marked as 'fixed' or 'closed' and being marked 'fix-for' > > a particular version. > > > > In other words, if the bug is fixed and is in a particular version of > > the roadmap, you know what version it was "fixed in". While the issue is > > open, you know what version we are planning to fix it in. > > > > Does that make sense? > > > > > -Original Message- > > > From: Martin Marinschek [mailto:[EMAIL PROTECTED] > > > Sent: Monday, November 21, 2005 9:45 PM > > > To: MyFaces Development > > > Subject: Re: Plan for 1.1.2? > > > > > > The confusion seems to be - is this version number a: > > > > > > is fixed in - version number or a > > > is reported against - version number > > > > > > indeed, there should be two fields in jira to reflect this, right? > > > > > > regards, > > > > > > Martin > > > > > > On 11/22/05, Abrams, Howard A <[EMAIL PROTECTED]> wrote: > > > > I think there are several points of confusion here, and I'm not sure > > on > > > > whose part. > > > > > > > > The version number in JIRA is listed as 'fix-for', which to me meant > > > > that is the version we plan to fix the issue in. The 'road map' > > lists > > > > future versions and the issues that are planned for each. One > > version > > > > does not a roadmap make. :) > > > > > > > > Without listing what issues we are planning on fixing in the future > > and > > > > when, those who depend on MyFaces have no insight into what is going > > on, > > > > and no basis to express the priority of an issue or know when to > > expect > > > > a fix. My categorization of what issue was to be fixed when was > > meant > > > > only as a starting point for a conversations on prioritizing the > > issues. > > > > Those on the dev list could look at the two version and make > > reasonable > > > > informed opinions on what should be moved when. > > > > > > > > But what I'm most confused about is the state of JIRA now; There was > > a > > > > 'nightly' version which I numbered (because we aren't planning on > > fixing > > > > those in the nightly, we're planning on fixing them in the next > > > > version). Now it's been archived and the next versions (1.1.3, which > > > > isn't the upcoming version) ahs been listed as nightly. I think that > > was > > > > a mistake, no? I think if you meant to put things back, you would > > have > > > > renamed 1.1.2 to nightly, right? > > > > > > > > So, after all this, we're back to the original question: Which bugs > > are > > > > to be fixed before we can start to release 1.1.2? And how would a > > > > user/developer know unless they are listed in the "Road Map"? > > > > > > > > > > > > > -Original Message- > > > > > From: Sean Schofield [mailto:[EMAIL PROTECTED] > > > > > Sent: Monday, November 21, 2005 12:03 PM > > > > > To: MyFaces Development > > > > > Subject: Re: Plan for 1.1.2? > > > > > >
[jira] Commented: (MYFACES-858) Documentation on myFaces site has typo in code.
[ http://issues.apache.org/jira/browse/MYFACES-858?page=comments#action_12358230 ] jeff porter commented on MYFACES-858: - Also, how do you implement the backend bean? What is getItems ment to return? String[] , List, etc? > Documentation on myFaces site has typo in code. > --- > > Key: MYFACES-858 > URL: http://issues.apache.org/jira/browse/MYFACES-858 > Project: MyFaces > Type: Improvement > Components: Tomahawk > Versions: 1.1.1 > Environment: Web page. See description... > Reporter: jeff porter > Priority: Trivial > > http://myfaces.apache.org/sandbox/inputSuggestAjax.html > auggestedItemsMethod="backend bean callback > method" value="Bean"/> > Should "auggestedItemsMethod" not be "SuggestedItemsMethod" ?? > detial: First letter is wrong. -- 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-858) Documentation on myFaces site has typo in code.
[ http://issues.apache.org/jira/browse/MYFACES-858?page=comments#action_12358229 ] jeff porter commented on MYFACES-858: - Also Should... " Documentation on myFaces site has typo in code. > --- > > Key: MYFACES-858 > URL: http://issues.apache.org/jira/browse/MYFACES-858 > Project: MyFaces > Type: Improvement > Components: Tomahawk > Versions: 1.1.1 > Environment: Web page. See description... > Reporter: jeff porter > Priority: Trivial > > http://myfaces.apache.org/sandbox/inputSuggestAjax.html > auggestedItemsMethod="backend bean callback > method" value="Bean"/> > Should "auggestedItemsMethod" not be "SuggestedItemsMethod" ?? > detial: First letter is wrong. -- 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: (MYFACES-858) Documentation on myFaces site has typo in code.
Documentation on myFaces site has typo in code. --- Key: MYFACES-858 URL: http://issues.apache.org/jira/browse/MYFACES-858 Project: MyFaces Type: Improvement Components: Tomahawk Versions: 1.1.1 Environment: Web page. See description... Reporter: jeff porter Priority: Trivial http://myfaces.apache.org/sandbox/inputSuggestAjax.html Should "auggestedItemsMethod" not be "SuggestedItemsMethod" ?? detial: First letter is wrong. -- 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
Changes in UIComponentTag.java
Someone changed a method in UIComponentTag.java from private to protected. Attention: this is no good idea. We are not allowed to change the signature of any class of the javax.faces.* package. Especially, you are not allowed to add public or protected methods. Whatever the reason for this change, we need to change elsewhere, sorry. regards, Martin
[COMMUNITY] Welcome Simon!
Ladies and Gentlemen, Please welcome our new MyFaces committer Simon Kitching (skitching)! In the past Simon served many valuable patches, brought accuracy in our discussions and what is more: he seems to have unlimited time ;-) Simon, glad to have you on board and looking forward to working together. Kind regards, Manfred Geiler
