jscookMenu
Hello, I'm having two seemingly very strange problems with the jscookMenu component. The first problem relates to navigation. I embedded a jscMenu inside a dataTable to act as something comparable to a right-click menu on a rich application. The menu works sort of the way one might expect, and calls the underlying bean actions. However, row selection on the table is not set, and navigation handling seems whacked thereafter (particularly with respect to the back button). I have a hard time even describing what goes on after using this embedded menu, because it seems that the regular commandLinks all get broken in spite of the fact that they worked fine before using the embedded menu. E.g. click on a commandLink (navigation works), click back, click menu (navigation works), click back, click on the previous commandLink and nav is broken, you are taken back to the screen handled by the menu. I know this is not enough information to go on in order to debug this problem, but what sort of components have people used to perform context sensitive navigation from within a table? The other problem I'm having with jscMenu is even more baffling to me. I cannot get the menu to appear at all. This is just a little test menu, and it refuses to be processed at all. It is behaving as though the menu definition is placed within a verbatim, but clearly it is not. That is, if I view the source html on a page generated with this menu in place, I still see the jsp syntax, nothing has been translated to html/js. The test menu was copy/pasted from another page where it works fine, so there is no issue with the menu definition itself. I've tried putting the menu in it's own form, but that did nothing. The only thing different about this particular page is that the vast majority of content on the page is built in java code, not jsp. I don't know what difference that could make, because every other component specified in jsp works as expected, but the menu is hosed. Any ideas would be greatly appreciated. Thanks -- Shane
Re: [Solved] Never before seen exception (facelets.FaceletViewHandler handleRenderException) - ??
Lisa wrote: I checked everywhere, even grep'd through everything and there is no conflict. Any ideas would be appreciated. I thought I was the only one seeing misidentified 'duplicate ids' (I don't use facelets though, so this could be worthless advice). Invariably for me, 'duplicate id' has been a red herring. It seems that this can happen when there is some malformed EL squirreled away somewhere. But to be honest, I haven't really noticed enough of a pattern to be terribly certain. -- Shane
OT: Contractor
Apologies up front for the off topic post. Do any of you guys do any moonlighting? I need to write a small CRUD module but won't have any time to spend on it for some months. I was thinking that I could get the job knocked off, and get a handle on some best practices by farming it out to someone with more JSF/MyFaces experience than I have. The app itself would be tiny - move data in and out of 4 rdb tables (schema and representative data provided of course). With functionality no more complex than a simple Master-Detail screen and basic validation. I would handle all maintenance and hopefully adapt or adopt the structure of the resulting code into my own work (a big part of my problem is that I work alone, so I don't have a good handle on other people's standard practices). If you're at all interested in the work, drop me a line privately. Thanks -- Shane
Re: Convert, skip validation and update model?
Marko Asplund wrote: The system i'm working on acts as an end-user front to a back-end reporting server. Is this a product, or something 'in house'? I've got a couple of similar systems, and hate them both. If you intend to sell it as a product, it may make more sense for me to buy rather than build. Thanks. -- Shane
Re: Convert, skip validation and update model?
Mike Kienenberger wrote: Maybe there's enough of us working on this type of functionality that we could come up with a subproject/subframework for dealing with it. I haven't actually looked for available systems in a few years, so I couldn't say if this is warranted. Although it has long surprised me that it does not come standard with enterprise reporting packages themselves (a system like this should also handle deploying the report objects). I guess the question is whether we can come up with something generic enough to meet everyone's needs. Genericity shouldn't be too tough since report parameter types and cardinality have to be generic from the start. From there you really only need a generic tree structure to hold report categories. You'd need to handle pluggable report engines and that could be tougher. I've only worked with Crystal and Inetsoftware.de myself, but you'd want to cover Jasper, BIRT and iText as well (lord only knows what form of BI systems you'd want to investigate too). I couldn't say how amenable any of those systems would be to a generic front end. Ideally you'd want to also handle things like MS SQL Server's reporting services; but if I had to guess, I'd guess that it wouldn't happen soon. neither of my previous systems dealt with fields dependent on other fields. I've been putting off dealing with it in JSF so far. I've never dealt with dependent fields either (just gave people the standard 'garbage in' rule). It does add some complexity, but doesn't seem insurmountable (presumably a v1.5 feature). It doesn't really fit this list though, since we only represent a small fraction of potential customers and developers (it is a starting point). It could be worth investigating, I just don't know when I'll find the time. Shane On 4/9/07, Shane Petroff <[EMAIL PROTECTED]> wrote: Marko Asplund wrote: > > The system i'm working on acts as an end-user front to a back-end > reporting server. Is this a product, or something 'in house'? I've got a couple of similar systems, and hate them both. If you intend to sell it as a product, it may make more sense for me to buy rather than build. Thanks. -- Shane -- Shane
Re: DataTable with filtering option - presentation-wise
Gerald Müllan wrote:
have you considered to use s:filterTable from sandbox?
...
http://example.irian.at/example-sandbox-20070502/filterTable.jsf
(derailing the thread slightly)
Thanks for the reference, but I would love some help to get FilterTable
working. I've copied/pasted the example code into a page of mine, and
the java code into the backing bean. Everything renders fine, and the
table is sortable, but the function dojo.widget.byId returns null, so
the filter functions do not work. I've tried using dojo.widget.byId on
other named components, but it always seems to fail. Is there something
that needs to be configured or initialized before byId can work? I'm
using tomahawk sandbox 1.1.6 snapshot jar alongside the 1.1.5 release.
The only difference I can see in the page is that I've nested the
FilterTable inside a form. The page is attached below.
<%@ taglib uri="http://java.sun.com/jsf/core"; prefix="f"%>
<%@ taglib uri="http://java.sun.com/jsf/html"; prefix="h"%>
<%@ taglib uri="http://myfaces.apache.org/tomahawk"; prefix="t"%>
<%@ taglib uri="http://myfaces.apache.org/sandbox"; prefix="s"%>
function manufacturerFilter(name){
return (name.charAt(0) >= 'M' && name.charAt(0) <= 'Z');
}
value="#{bundle.Logout}"/>
<%-- Header --%>
action="#{pickSectionBean.onHome}" styleClass="button"/>
onclick="alert(dojo.widget.byId('filterTbl'));dojo.widget.byId('filterTbl').clearFilters()"
/>
value="#{pickSectionBean.cars}" >
--
Shane
Re: DataTable with filtering option - presentation-wise
Gerald Müllan wrote:
Which version of tomahawk are you using?
Same results with 1.1.5 and 1.1.5-SNAPSHOT. Do I need something newer
than the daily builds?
--
Shane
On 5/3/07, Shane Petroff <[EMAIL PROTECTED]> wrote:
Gerald Müllan wrote:
>
> have you considered to use s:filterTable from sandbox?
> ...
> http://example.irian.at/example-sandbox-20070502/filterTable.jsf
(derailing the thread slightly)
Thanks for the reference, but I would love some help to get FilterTable
working. I've copied/pasted the example code into a page of mine, and
the java code into the backing bean. Everything renders fine, and the
table is sortable, but the function dojo.widget.byId returns null, so
the filter functions do not work. I've tried using dojo.widget.byId on
other named components, but it always seems to fail. Is there something
that needs to be configured or initialized before byId can work? I'm
using tomahawk sandbox 1.1.6 snapshot jar alongside the 1.1.5 release.
The only difference I can see in the page is that I've nested the
FilterTable inside a form. The page is attached below.
<%@ taglib uri="http://java.sun.com/jsf/core"; prefix="f"%>
<%@ taglib uri="http://java.sun.com/jsf/html"; prefix="h"%>
<%@ taglib uri="http://myfaces.apache.org/tomahawk"; prefix="t"%>
<%@ taglib uri="http://myfaces.apache.org/sandbox"; prefix="s"%>
function manufacturerFilter(name){
return (name.charAt(0) >= 'M' && name.charAt(0) <= 'Z');
}
<%-- Header --%>
onclick="alert(dojo.widget.byId('filterTbl'));dojo.widget.byId('filterTbl').clearFilters()"
/>
--
Shane
--
Shane
Re: DataTable with filtering option - presentation-wise
Gerald Müllan wrote:
No, if you are working with the daily builds you got at least the
newest one.
The null-reference is really strange since filteringTable itself seems
to work and it already uses the dojo.widget namespace.
Can you try to have a look into firebug or some other js-debugger, if
there has any widget
been created through the dojo environment, maybe with some other
reference name? It must be located somewhere in the globally js object
pool (dojo object).
OK, this is the first time I've used FireBug, so I'm not yet sure what
I'm looking for.
Under inspect/DOM/dojo/, there are dozens of things, none of which I am
terribly familiar with... If I open the page and navigate to:
dojo/widget
I can see what appears to be a reference to the table. That is,
dojo/widget/widgetIds
has a reference "aForm:filterTbl" which one would think was the
appropriate object. ('aForm' is just an arbitrary id I assigned to the
form to see if dojo could find the form - it can't...) Similarly
dojo/widget/widgets[0]
seems like it is pointing to the correct place. Is there something more
specific which I should be looking for? Are there any issues with either
tomcat or firefox versions? Thanks for your help.
--
Shane
cheers,
Gerald
On 5/4/07, Shane Petroff <[EMAIL PROTECTED]> wrote:
Gerald Müllan wrote:
> Which version of tomahawk are you using?
Same results with 1.1.5 and 1.1.5-SNAPSHOT. Do I need something newer
than the daily builds?
--
Shane
>
> On 5/3/07, Shane Petroff <[EMAIL PROTECTED]> wrote:
>> Gerald Müllan wrote:
>> >
>> > have you considered to use s:filterTable from sandbox?
>> > ...
>> > http://example.irian.at/example-sandbox-20070502/filterTable.jsf
>> (derailing the thread slightly)
>>
>> Thanks for the reference, but I would love some help to get
FilterTable
>> working. I've copied/pasted the example code into a page of mine, and
>> the java code into the backing bean. Everything renders fine, and the
>> table is sortable, but the function dojo.widget.byId returns null, so
>> the filter functions do not work. I've tried using
dojo.widget.byId on
>> other named components, but it always seems to fail. Is there
something
>> that needs to be configured or initialized before byId can work? I'm
>> using tomahawk sandbox 1.1.6 snapshot jar alongside the 1.1.5
release.
>> The only difference I can see in the page is that I've nested the
>> FilterTable inside a form. The page is attached below.
>>
>>
>>
>>
>> <%@ taglib uri="http://java.sun.com/jsf/core"; prefix="f"%>
>> <%@ taglib uri="http://java.sun.com/jsf/html"; prefix="h"%>
>> <%@ taglib uri="http://myfaces.apache.org/tomahawk"; prefix="t"%>
>> <%@ taglib uri="http://myfaces.apache.org/sandbox"; prefix="s"%>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> function manufacturerFilter(name){
>> return (name.charAt(0) >= 'M' && name.charAt(0) <= 'Z');
>> }
>>
>>
>>
>>
>>
>>
>>
>>
>> >columns="1" cellpadding="5">
>>
>> >columns="1" cellpadding="5" align="right">
>> > value="#{bundle.Logout}"/>
>>
>>
>> <%-- Header --%>
>>
>>
>>
>>
>>
>>
>> > action="#{pickSectionBean.onHome}" styleClass="button"/>
>>
>>
>> onclick="dojo.widget.byId('filterTbl').setFilter('manufacturer',
>> manufacturerFilter);" />
>> >>
onclick="alert(dojo.widget.byId('filterTbl'));dojo.widget.byId('filterTbl').clearFilters()"
>>
>> />
>>
>> > value="#{pickSectionBean.cars}" >
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> --
>> Shane
>>
>>
>>
>>
>
>
--
Shane
--
Shane
Re: DataTable with filtering option - presentation-wise
Gerald Müllan wrote: No, if you are working with the daily builds you got at least the newest one. The null-reference is really strange since filteringTable itself seems to work and it already uses the dojo.widget namespace. The problem arises as soon as you embed the filterTable within an h:form. To duplicate simply take the example at irian and embed the filter table within a form. -- Shane
broken navigation
Hello all, I have somehow broken my application and can't figure out what I've done to cause it. Every h:commandLink in my app is currently broken and not only do I not know why, but I've spent several days working in an area of the application which is accessible by navigating via a h:commandButton, so I don't even know when I broke things. CommandLinks now generate javascript errors either trying to reference a non-existent component or a non-existent function. Some of the now broken pages have been unchanged for weeks, others completely reworked. Since navigation via button works, I can confirm that managed beans are being created and called, but I can't figure out why the javascript used for commandLinks gets hosed. Anyone else seen something like this? -- Shane
Re: broken navigation
Sorin Silaghi wrote: Can you please send us some details on this ... ? like how do the pages and action methods look like ?? have you tried to change a commandLink with a commandButton and see if you get the same errors ?(the unaffected button might work because of other reasons) There is nothing wrong with either the code or the navigation rules, the breakage appears in areas unmodified for several weeks. The mere presence of the tomahawk-sandbox-1.1.6-SNAPSHOT.jar in the application's classpath (web-inf\lib) causes the problem. If I stop tomcat, rename this jar to some other extension (and comment out the code which needs it), everything works again. If I rename it back and restart tomcat again, all the links are broken. I've tried 2 versions of the 1.1.6 sandbox and had the same problem with both. Which sucks given that I want to use some of the sandbox components... Shane thank you.. On 5/15/07, *Shane Petroff* <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote: Hello all, I have somehow broken my application and can't figure out what I've done to cause it. Every h:commandLink in my app is currently broken and not only do I not know why, but I've spent several days working in an area of the application which is accessible by navigating via a h:commandButton, so I don't even know when I broke things. CommandLinks now generate javascript errors either trying to reference a non-existent component or a non-existent function. Some of the now broken pages have been unchanged for weeks, others completely reworked. Since navigation via button works, I can confirm that managed beans are being created and called, but I can't figure out why the javascript used for commandLinks gets hosed. Anyone else seen something like this? -- Shane -- Shane
Re: broken navigation
Sorin Silaghi wrote:
I am using the the 1.1.6 sandbox but I don't have your problem ...
Presumably dozens if not hundreds of other people are too; it doesn't
make a lot of sense to me, I must be missing something. How could simply
having the sandbox jar be accessible to tomcat affect code which does
not attempt to use anything in the sandbox? (once again, the sequence
is: take a functioning app, stop tomcat, drop the sandbox jar in
web-inf/lib, restart tomcat, and commandLinks all fail because some
portion of javascript is never generated. This is tomcat 5.5.20,
tomahawk 1.1.5 and sandbox 1.1.6 snapshot)
have you tried a simple page with just one command link on it and see
if that works ...
The page I am talking about has an outputText, 4 buttons and a link. It
couldn't get much simpler, and nothing from the sandbox at all. (Various
other pages are also broken, but they are much more complex, so it seems
prudent to try to get the simplest case working first) For the sheer
hell of it, I tried commenting out everything in the jsp except the
link, form and the panel which the link sits in, and it still failed.
are command buttons also affected or just command links ? if not,
have you tried replacing a command link with a command button ?
Buttons seem to work fine although I cannot drill too far into the app
to test very many other buttons, because the majority of the site is
accessible via links. I tried swapping out the link for a button and it
worked fine, but when switched back to a link, it would no longer work.
The generated html is missing some javascript. It is not even consistent
which javascript is missing:
clear__5FidJsp0 is not defined.on one page
document.forms._idJsp3.elements['_idJsp3:_link_hidden_'] has no
propertieson another
I tried deploying to another machine to see if it was something related
to my system, but the resulting war had the same problem (I don't recall
which version of tomcat my friend was running when he tested it for me).
In the short term I'm just ditching the sandbox functionality; I have to
get some other stuff done. Longer term, I guess I will have to strip
everything out of this app to create a small test case. Thanks for
listening.
--
Shane
...
On 5/16/07, *Shane Petroff* <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>
wrote:
Sorin Silaghi wrote:
Can you please send us some details on this ... ? like how do the
pages and action methods look like ?? have you tried to change a
commandLink with a commandButton and see if you get the same
errors ?(the unaffected button might work because of other reasons)
There is nothing wrong with either the code or the navigation
rules, the breakage appears in areas unmodified for several weeks.
The mere presence of the tomahawk-sandbox-1.1.6-SNAPSHOT.jar in
the application's classpath (web-inf\lib) causes the problem. If I
stop tomcat, rename this jar to some other extension (and comment
out the code which needs it), everything works again. If I rename
it back and restart tomcat again, all the links are broken. I've
tried 2 versions of the 1.1.6 sandbox and had the same problem
with both. Which sucks given that I want to use some of the
sandbox components...
Shane
thank you..
On 5/15/07, *Shane Petroff* <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
Hello all,
I have somehow broken my application and can't figure out
what I've done
to cause it. Every h:commandLink in my app is currently
broken and not
only do I not know why, but I've spent several days working
in an area
of the application which is accessible by navigating via a
h:commandButton, so I don't even know when I broke things.
CommandLinks
now generate javascript errors either trying to reference a
non-existent
component or a non-existent function. Some of the now broken
pages have
been unchanged for weeks, others completely reworked. Since
navigation
via button works, I can confirm that managed beans are being
created and
called, but I can't figure out why the javascript used for
commandLinks
gets hosed. Anyone else seen something like this?
--
Shane
--
Shane
--
Shane
HtmlRendererUtils - There should always be a submitted value
I am having some strange navigation problems (once again...) and the only clue I have is the warning below. HtmlRendererUtils - There should always be a submitted value for an input if it is rendered, its form is submitted, and it is not disabled or read-only. In Googling the error message, it seems that the problem should be related to using Javascript to disable a control which my-faces expects to get a value from. The warning goes on to name the component in question, but there isn't any Javascript which touches these text areas, in fact there isn't any Javascript which disables anything. The components which are (in theory) causing the warning are certainly not disabled visually and for the most part they all contain text. They also happen to be created in Java code, so there is no jsp to post here. Can anyone give me a more detailed interpretation of what the warning means and when it arises? -- Shane
Re: HtmlRendererUtils - There should always be a submitted value
Mike Kienenberger wrote: I've also had it happen if the page changes and the facelets component tree (or jsp page) is still cached somewhere. I'm almost completely certain it is not a caching issue (although it would be good to know if one could configure Tomcat not to cache anything, ever...) I've hand nuked caches several times and tried executing on a different machine (Tomcat running on the localhost in both cases). Shane Same idea -- the expected submitted page elements do not match the actual submitted page elements. On 6/5/07, Shane Petroff <[EMAIL PROTECTED]> wrote: I am having some strange navigation problems (once again...) and the only clue I have is the warning below. HtmlRendererUtils - There should always be a submitted value for an input if it is rendered, its form is submitted, and it is not disabled or read-only. In Googling the error message, it seems that the problem should be related to using Javascript to disable a control which my-faces expects to get a value from. The warning goes on to name the component in question, but there isn't any Javascript which touches these text areas, in fact there isn't any Javascript which disables anything. The components which are (in theory) causing the warning are certainly not disabled visually and for the most part they all contain text. They also happen to be created in Java code, so there is no jsp to post here. Can anyone give me a more detailed interpretation of what the warning means and when it arises? -- Shane -- Shane
Re: HtmlRendererUtils - There should always be a submitted value
Thanks for the suggestions, In reviewing the potential problems you listed below, I'm still stuck. I don't use ajax, so 1) shouldn't be an issue. I don't disable anything in javascript, so 2) shouldn't affect me. I only use a single form with everything inside it, so 3) shouldn't be an issue either. And I don't tie any EL to the disabled/rendered properties (only the value is mutated via EL expression). What do you think would be the best way to diagnose what is going wrong? I guess I could attach a PhaseListener and set a breakpoint in there to try to dissect what JSF thinks is wrong. I'm at a real loss here since I can't see anything wrong and the components which are causing the problem are used to capture the most important data I deal with. Thanks for the help Shane Andrew Robinson wrote: That error occurs if there is no submitted value (I know - obvious statement). Several things can cause it though. Here are the ones that are most common IMO (P -> problem, S->Work-around/Solution) 1) (P) A4J and the ajaxSingle attribute set to true. (S) Use a4j:region around any component with ajaxSingle set to true to make sure only that component is decoded and updated 2) (P) Element is removed from the client DOM or is disabled *and* the JSF component is not disabled. (S) The client side enabled/rendered should map to the server-side enabled/rendered. Therefore, if you are disabling/removing components on the client, you need to make sure you change the value on the server *before* the apply request values phase (I think that is the correct phase of the error). 3) (P) Component is not inside of the form that was submitted. (S1) Do not use multiple forms if doing so, instead use the subForm component in the sandbox with one form or use one or multiple forms with a4j:region if using A4J. (S2) make sure all components that implement EditableValueHolder are placed inside of a UIForm component. 4) (P) The EL expression tied to the rendered or disabled property of the component is not view specific and has been changed by another view or is changed before the apply request values phase. (S) Make sure the rendered and/or disabled properties of components do not change after rendering and before the apply request values. -Andrew On 6/5/07, Shane Petroff <[EMAIL PROTECTED]> wrote: Mike Kienenberger wrote: > I've also had it happen if the page changes and the facelets component > tree (or jsp page) is still cached somewhere. I'm almost completely certain it is not a caching issue (although it would be good to know if one could configure Tomcat not to cache anything, ever...) I've hand nuked caches several times and tried executing on a different machine (Tomcat running on the localhost in both cases). Shane > Same idea -- the > expected submitted page elements do not match the actual submitted > page elements. > > On 6/5/07, Shane Petroff <[EMAIL PROTECTED]> wrote: >> >> I am having some strange navigation problems (once again...) and the >> only clue I have is the warning below. >> >> HtmlRendererUtils - There should always be a submitted value for an >> input if it is rendered, its form is submitted, and it is not disabled >> or read-only. >> >> In Googling the error message, it seems that the problem should be >> related to using Javascript to disable a control which my-faces expects >> to get a value from. The warning goes on to name the component in >> question, but there isn't any Javascript which touches these text areas, >> in fact there isn't any Javascript which disables anything. The >> components which are (in theory) causing the warning are certainly not >> disabled visually and for the most part they all contain text. They also >> happen to be created in Java code, so there is no jsp to post here. >> >> Can anyone give me a more detailed interpretation of what the warning >> means and when it arises? >> >> -- >> Shane >> >> > -- Shane -- Shane
Re: HtmlRendererUtils - There should always be a submitted value
Mike Kienenberger wrote: If there's no such element, then you need to figure out why the element wasn't rendered. I guess I wasn't clear. The components in question are in the generated html. They are enabled and rendered and I can't find anything which might potentially disable them via javascript. Certainly none of the javascript that I input will do this and I don't see any in the generated javascript which might either. If so, then you need to figure out why there's no submitted value when you submit the form -- perhaps submitting the form through some kind of proxy which logs all of the values would help. OK, can you expand on this a bit? Do you mean some 'off the shelf' proxy or something different? This is what I was getting at with the PhaseListener, if I could see what was actually making it through, I might be able to make some sense of what's going on. Shane On 6/8/07, Shane Petroff <[EMAIL PROTECTED]> wrote: Mike Kienenberger wrote: > Set a breakpoint on the line generating the error. > Your first step is to determine which component value is missing from > your form submit. According to the warning message, I can see that there are several text area components which are the problem (I assign the id's myself, so it is easy to verify which components it is complaining about). Most of the components in this page are generated in java code, and everything looks fine inside the factory method responsible for creating the text components (isDisabled()==false and isRendered()==true). Visually, immediately preceding an attempt to navigate away from this page via CommandLink, the fields in question are rendered and enabled. After that, I can see my request scoped backing bean get created once the link is clicked, but then the warnings are thrown and no navigation takes place. In terms of the generated html, it is a monsterous form with scads of disabled components, so it is not terribly easy to verify anything (my javascript skills suck as well, and that doesn't help). However, everything which gets disabled is set inside the java code which generates all of the content for the main panel so there ought not to be any issues with client side disables. > Once you know that, look at the generated html before the submit and > see if you can determine why the input for that component didn't > submit a value. OK, what do I look for? I know the component id a priori, so I can isolate the 3 times which it occurs in the generated html. Once for the component name, once for the id, and once in some javascript tied to a sepeate button which does a spell check on the component in question (fwiw, the spell check function does not alter either the rendered or disabled state of the component and this issue crops up regardless of whether or not the spell check function is actually invoked) I don't see anything in the html which suggests a problem, but I'm not altogether sure what to look for. Shane > > On 6/8/07, Shane Petroff <[EMAIL PROTECTED]> wrote: >> Thanks for the suggestions, >> >> In reviewing the potential problems you listed below, I'm still stuck. I >> don't use ajax, so 1) shouldn't be an issue. I don't disable anything in >> javascript, so 2) shouldn't affect me. I only use a single form with >> everything inside it, so 3) shouldn't be an issue either. And I don't >> tie any EL to the disabled/rendered properties (only the value is >> mutated via EL expression). >> >> What do you think would be the best way to diagnose what is going wrong? >> I guess I could attach a PhaseListener and set a breakpoint in there to >> try to dissect what JSF thinks is wrong. I'm at a real loss here since I >> can't see anything wrong and the components which are causing the >> problem are used to capture the most important data I deal with. Thanks >> for the help >> >> Shane >> >> >> Andrew Robinson wrote: >> > That error occurs if there is no submitted value (I know - obvious >> > statement). Several things can cause it though. Here are the ones that >> > are most common IMO (P -> problem, S->Work-around/Solution) >> > >> > 1) (P) A4J and the ajaxSingle attribute set to true. (S) Use >> > a4j:region around any component with ajaxSingle set to true to make >> > sure only that component is decoded and updated >> > >> > 2) (P) Element is removed from the client DOM or is disabled *and* the >> > JSF component is not disabled. (S) The client side enabled/rendered >> > should map to the server-side enabled/rendered. Therefore, if you are >> > disabling/removing components on the client, you need to make sure you
Re: HtmlRendererUtils - There should always be a submitted value
Mike Kienenberger wrote: Set a breakpoint on the line generating the error. Your first step is to determine which component value is missing from your form submit. According to the warning message, I can see that there are several text area components which are the problem (I assign the id's myself, so it is easy to verify which components it is complaining about). Most of the components in this page are generated in java code, and everything looks fine inside the factory method responsible for creating the text components (isDisabled()==false and isRendered()==true). Visually, immediately preceding an attempt to navigate away from this page via CommandLink, the fields in question are rendered and enabled. After that, I can see my request scoped backing bean get created once the link is clicked, but then the warnings are thrown and no navigation takes place. In terms of the generated html, it is a monsterous form with scads of disabled components, so it is not terribly easy to verify anything (my javascript skills suck as well, and that doesn't help). However, everything which gets disabled is set inside the java code which generates all of the content for the main panel so there ought not to be any issues with client side disables. Once you know that, look at the generated html before the submit and see if you can determine why the input for that component didn't submit a value. OK, what do I look for? I know the component id a priori, so I can isolate the 3 times which it occurs in the generated html. Once for the component name, once for the id, and once in some javascript tied to a sepeate button which does a spell check on the component in question (fwiw, the spell check function does not alter either the rendered or disabled state of the component and this issue crops up regardless of whether or not the spell check function is actually invoked) I don't see anything in the html which suggests a problem, but I'm not altogether sure what to look for. Shane On 6/8/07, Shane Petroff <[EMAIL PROTECTED]> wrote: Thanks for the suggestions, In reviewing the potential problems you listed below, I'm still stuck. I don't use ajax, so 1) shouldn't be an issue. I don't disable anything in javascript, so 2) shouldn't affect me. I only use a single form with everything inside it, so 3) shouldn't be an issue either. And I don't tie any EL to the disabled/rendered properties (only the value is mutated via EL expression). What do you think would be the best way to diagnose what is going wrong? I guess I could attach a PhaseListener and set a breakpoint in there to try to dissect what JSF thinks is wrong. I'm at a real loss here since I can't see anything wrong and the components which are causing the problem are used to capture the most important data I deal with. Thanks for the help Shane Andrew Robinson wrote: > That error occurs if there is no submitted value (I know - obvious > statement). Several things can cause it though. Here are the ones that > are most common IMO (P -> problem, S->Work-around/Solution) > > 1) (P) A4J and the ajaxSingle attribute set to true. (S) Use > a4j:region around any component with ajaxSingle set to true to make > sure only that component is decoded and updated > > 2) (P) Element is removed from the client DOM or is disabled *and* the > JSF component is not disabled. (S) The client side enabled/rendered > should map to the server-side enabled/rendered. Therefore, if you are > disabling/removing components on the client, you need to make sure you > change the value on the server *before* the apply request values phase > (I think that is the correct phase of the error). > > 3) (P) Component is not inside of the form that was submitted. (S1) Do > not use multiple forms if doing so, instead use the subForm component > in the sandbox with one form or use one or multiple forms with > a4j:region if using A4J. (S2) make sure all components that implement > EditableValueHolder are placed inside of a UIForm component. > > 4) (P) The EL expression tied to the rendered or disabled property of > the component is not view specific and has been changed by another > view or is changed before the apply request values phase. (S) Make > sure the rendered and/or disabled properties of components do not > change after rendering and before the apply request values. > > -Andrew > > On 6/5/07, Shane Petroff <[EMAIL PROTECTED]> wrote: >> Mike Kienenberger wrote: >> > I've also had it happen if the page changes and the facelets component >> > tree (or jsp page) is still cached somewhere. >> I'm almost completely certain it is not a caching issue (although it >> would be good to know if one could configure Tomcat not to cache >> anything, ever
Re: HtmlRendererUtils - There should always be a submitted value
Mike Kienenberger wrote: Another way would be to set a breakpoint somewhere and check what's in the request parameter map for the current request. OK, what I've done is to add a Servlet Filter to the mix (in looking at example code, it seems that the filter may come in handy down the line). What I figured was that the filter will get processed early, and is therefore a good place to set a breakpoint to examine request parameters. (Although as I write this I'm wondering about filter ordering and the Extensions filter) It seems as though the component id's do not correspond to the request parameters which make it through to the filter. In the generated html I have id="mainForm:_id30:_id33:editableAnecdotalComment548806536" and in the request I have param: mainForm:contentPanel_1153:contentPanel_1344:editableAnecdotalComment548806536, value: [Ljava.lang.String;@1fff293 The "editableAnecdotalComment548806536" portion is the ID that I set. All of the _idXX components get mapped to different parameter names (contentPanel happens to be the name I assigned to the main panel on the jsp page whose binding attribute I use to build up dynamic content). Since all component id's get mapped, I don't yet see a problem. I haven't tried stepping into anything outside my own code yet, but I guess that's next on the list. Shane You can save the generated html to a file and manually change the url to something else that will trap and log the values. Lots of different options, but the key is to verify that there is no value being submitted for your component, which is what the error message is claming. On 6/8/07, Shane Petroff <[EMAIL PROTECTED]> wrote: Mike Kienenberger wrote: > If there's no such element, then you need to figure out why the > element wasn't rendered. I guess I wasn't clear. The components in question are in the generated html. They are enabled and rendered and I can't find anything which might potentially disable them via javascript. Certainly none of the javascript that I input will do this and I don't see any in the generated javascript which might either. > If so, then you need to figure out why there's no submitted value when > you submit the form -- perhaps submitting the form through some kind > of proxy which logs all of the values would help. OK, can you expand on this a bit? Do you mean some 'off the shelf' proxy or something different? This is what I was getting at with the PhaseListener, if I could see what was actually making it through, I might be able to make some sense of what's going on. Shane > > On 6/8/07, Shane Petroff <[EMAIL PROTECTED]> wrote: >> Mike Kienenberger wrote: >> > Set a breakpoint on the line generating the error. >> > Your first step is to determine which component value is missing from >> > your form submit. >> According to the warning message, I can see that there are several text >> area components which are the problem (I assign the id's myself, so it >> is easy to verify which components it is complaining about). Most of the >> components in this page are generated in java code, and everything looks >> fine inside the factory method responsible for creating the text >> components (isDisabled()==false and isRendered()==true). Visually, >> immediately preceding an attempt to navigate away from this page via >> CommandLink, the fields in question are rendered and enabled. After >> that, I can see my request scoped backing bean get created once the link >> is clicked, but then the warnings are thrown and no navigation takes >> place. In terms of the generated html, it is a monsterous form with >> scads of disabled components, so it is not terribly easy to verify >> anything (my javascript skills suck as well, and that doesn't help). >> However, everything which gets disabled is set inside the java code >> which generates all of the content for the main panel so there ought not >> to be any issues with client side disables. >> >> > Once you know that, look at the generated html before the submit and >> > see if you can determine why the input for that component didn't >> > submit a value. >> OK, what do I look for? I know the component id a priori, so I can >> isolate the 3 times which it occurs in the generated html. Once for the >> component name, once for the id, and once in some javascript tied to a >> sepeate button which does a spell check on the component in question >> (fwiw, the spell check function does not alter either the rendered or >> disabled state of the component and this issue crops up regardless of >> whether or not the spell check function is ac
Re: HtmlRendererUtils - There should always be a submitted value
Andrew Robinson wrote: I would suggest debugging using an IDE at this point. Check out the request header variables and then debug through the decode phase. I'd recommend putting a break point on the warning. At the point where the warning is logged, component.getClientId(FacesContext) doesn't return a value contained in the request parameter map. While that's good for me to know, I'm guessing you guys already knew that :) What could cause the mismatch? Thanks in advance. Shane On 6/8/07, Shane Petroff <[EMAIL PROTECTED]> wrote: Thanks for the suggestions, In reviewing the potential problems you listed below, I'm still stuck. I don't use ajax, so 1) shouldn't be an issue. I don't disable anything in javascript, so 2) shouldn't affect me. I only use a single form with everything inside it, so 3) shouldn't be an issue either. And I don't tie any EL to the disabled/rendered properties (only the value is mutated via EL expression). What do you think would be the best way to diagnose what is going wrong? I guess I could attach a PhaseListener and set a breakpoint in there to try to dissect what JSF thinks is wrong. I'm at a real loss here since I can't see anything wrong and the components which are causing the problem are used to capture the most important data I deal with. Thanks for the help Shane Andrew Robinson wrote: > That error occurs if there is no submitted value (I know - obvious > statement). Several things can cause it though. Here are the ones that > are most common IMO (P -> problem, S->Work-around/Solution) > > 1) (P) A4J and the ajaxSingle attribute set to true. (S) Use > a4j:region around any component with ajaxSingle set to true to make > sure only that component is decoded and updated > > 2) (P) Element is removed from the client DOM or is disabled *and* the > JSF component is not disabled. (S) The client side enabled/rendered > should map to the server-side enabled/rendered. Therefore, if you are > disabling/removing components on the client, you need to make sure you > change the value on the server *before* the apply request values phase > (I think that is the correct phase of the error). > > 3) (P) Component is not inside of the form that was submitted. (S1) Do > not use multiple forms if doing so, instead use the subForm component > in the sandbox with one form or use one or multiple forms with > a4j:region if using A4J. (S2) make sure all components that implement > EditableValueHolder are placed inside of a UIForm component. > > 4) (P) The EL expression tied to the rendered or disabled property of > the component is not view specific and has been changed by another > view or is changed before the apply request values phase. (S) Make > sure the rendered and/or disabled properties of components do not > change after rendering and before the apply request values. > > -Andrew > > On 6/5/07, Shane Petroff <[EMAIL PROTECTED]> wrote: >> Mike Kienenberger wrote: >> > I've also had it happen if the page changes and the facelets component >> > tree (or jsp page) is still cached somewhere. >> I'm almost completely certain it is not a caching issue (although it >> would be good to know if one could configure Tomcat not to cache >> anything, ever...) I've hand nuked caches several times and tried >> executing on a different machine (Tomcat running on the localhost in >> both cases). >> >> Shane >> > Same idea -- the >> > expected submitted page elements do not match the actual submitted >> > page elements. >> > >> > On 6/5/07, Shane Petroff <[EMAIL PROTECTED]> wrote: >> >> >> >> I am having some strange navigation problems (once again...) and the >> >> only clue I have is the warning below. >> >> >> >> HtmlRendererUtils - There should always be a submitted value for an >> >> input if it is rendered, its form is submitted, and it is not >> disabled >> >> or read-only. >> >> >> >> In Googling the error message, it seems that the problem should be >> >> related to using Javascript to disable a control which my-faces >> expects >> >> to get a value from. The warning goes on to name the component in >> >> question, but there isn't any Javascript which touches these text >> areas, >> >> in fact there isn't any Javascript which disables anything. The >> >> components which are (in theory) causing the warning are certainly >> not >> >> disabled visually and for the most part they all contain text. >> They also >> >> happen to be created in Java code, so there is no jsp to post here. >> >> >> >> Can anyone give me a more detailed interpretation of what the warning >> >> means and when it arises? >> >> >> >> -- >> >> Shane >> >> >> >> >> > >> >> >> -- >> Shane >> >> > -- Shane -- Shane
Re: HtmlRendererUtils - There should always be a submitted value
Mike Kienenberger wrote: So the question is why does _id30 get translated to contentPanel_1153 and _id33 get translated to contentPanel_1344 on submit? That would be the question alright... It seems as though the problem actually happens before/during html generation. On submit, it's too late. It looks like you've went from automatically generated ids for these components to explicitly-set (plus some random number) ids for these components. The parameter map seems like it is the correct one. The text areas in question sit in tabs located on 'mainForm'. Specifically the containment looks like: mainForm (explicitly named) contentPanel (explicitly named) Tab_1 (generated id) Panel_1 (generated id) editableAnecdotalComment548806536 (explicitly named - the numbers at the end refer to a db id) Shane On 6/8/07, Shane Petroff <[EMAIL PROTECTED]> wrote: At the point where the warning is logged, component.getClientId(FacesContext) doesn't return a value contained in the request parameter map. While that's good for me to know, I'm guessing you guys already knew that :) What could cause the mismatch? Thanks in advance. On 6/8/07, Shane Petroff <[EMAIL PROTECTED]> wrote: Mike Kienenberger wrote: > Another way would be to set a breakpoint somewhere and > check what's in the request parameter map for the current request. OK, what I've done is to add a Servlet Filter to the mix (in looking at example code, it seems that the filter may come in handy down the line). What I figured was that the filter will get processed early, and is therefore a good place to set a breakpoint to examine request parameters. (Although as I write this I'm wondering about filter ordering and the Extensions filter) It seems as though the component id's do not correspond to the request parameters which make it through to the filter. In the generated html I have id="mainForm:_id30:_id33:editableAnecdotalComment548806536" and in the request I have param: mainForm:contentPanel_1153:contentPanel_1344:editableAnecdotalComment548806536, value: [Ljava.lang.String;@1fff293 The "editableAnecdotalComment548806536" portion is the ID that I set. All of the _idXX components get mapped to different parameter names (contentPanel happens to be the name I assigned to the main panel on the jsp page whose binding attribute I use to build up dynamic content). Since all component id's get mapped, I don't yet see a problem. I haven't tried stepping into anything outside my own code yet, but I guess that's next on the list. Shane > You can save the generated html to a file and manually change the url > to something else that will trap and log the values. > > Lots of different options, but the key is to verify that there is no > value being submitted for your component, which is what the error > message is claming. > > On 6/8/07, Shane Petroff <[EMAIL PROTECTED]> wrote: >> Mike Kienenberger wrote: >> >> > If there's no such element, then you need to figure out why the >> > element wasn't rendered. >> I guess I wasn't clear. The components in question are in the generated >> html. They are enabled and rendered and I can't find anything which >> might potentially disable them via javascript. Certainly none of the >> javascript that I input will do this and I don't see any in the >> generated javascript which might either. >> >> > If so, then you need to figure out why there's no submitted value when >> > you submit the form -- perhaps submitting the form through some kind >> > of proxy which logs all of the values would help. >> OK, can you expand on this a bit? Do you mean some 'off the shelf' proxy >> or something different? This is what I was getting at with the >> PhaseListener, if I could see what was actually making it through, I >> might be able to make some sense of what's going on. >> >> Shane >> >> > >> > On 6/8/07, Shane Petroff <[EMAIL PROTECTED]> wrote: >> >> Mike Kienenberger wrote: >> >> > Set a breakpoint on the line generating the error. >> >> > Your first step is to determine which component value is missing >> from >> >> > your form submit. >> >> According to the warning message, I can see that there are several >> text >> >> area components which are the problem (I assign the id's myself, >> so it >> >> is easy to verify which components it is complaining about). Most >> of the >> >> components in this page are generated in java code, and everything >> looks >> >> fine inside the f
Re: HtmlRendererUtils - There should always be a submitted value
Shane Petroff wrote: At the point where the warning is logged, component.getClientId(FacesContext) doesn't return a value contained in the request parameter map. I think the warning is a big red herring. I don't even have the capacity to change the ClientID, so the fact that there is a mismatch only indicates that something has gone wrong earlier. I've tried messing around with the page structure a little. I swapped a text field in for the text area, but had the same result. I tried removing a set of tabs to reduce the overall complexity somewhat, but that had no effect either. Something has gone wrong and failed silently long before the warning is logged, but at the moment, I don't know how to figure out what has died. The most annoying part about this is that I don't have effective UI tests, so I also have no idea when this problem was introduced... Shane On 6/8/07, Shane Petroff <[EMAIL PROTECTED]> wrote: Thanks for the suggestions, In reviewing the potential problems you listed below, I'm still stuck. I don't use ajax, so 1) shouldn't be an issue. I don't disable anything in javascript, so 2) shouldn't affect me. I only use a single form with everything inside it, so 3) shouldn't be an issue either. And I don't tie any EL to the disabled/rendered properties (only the value is mutated via EL expression). What do you think would be the best way to diagnose what is going wrong? I guess I could attach a PhaseListener and set a breakpoint in there to try to dissect what JSF thinks is wrong. I'm at a real loss here since I can't see anything wrong and the components which are causing the problem are used to capture the most important data I deal with. Thanks for the help Shane Andrew Robinson wrote: > That error occurs if there is no submitted value (I know - obvious > statement). Several things can cause it though. Here are the ones that > are most common IMO (P -> problem, S->Work-around/Solution) > > 1) (P) A4J and the ajaxSingle attribute set to true. (S) Use > a4j:region around any component with ajaxSingle set to true to make > sure only that component is decoded and updated > > 2) (P) Element is removed from the client DOM or is disabled *and* the > JSF component is not disabled. (S) The client side enabled/rendered > should map to the server-side enabled/rendered. Therefore, if you are > disabling/removing components on the client, you need to make sure you > change the value on the server *before* the apply request values phase > (I think that is the correct phase of the error). > > 3) (P) Component is not inside of the form that was submitted. (S1) Do > not use multiple forms if doing so, instead use the subForm component > in the sandbox with one form or use one or multiple forms with > a4j:region if using A4J. (S2) make sure all components that implement > EditableValueHolder are placed inside of a UIForm component. > > 4) (P) The EL expression tied to the rendered or disabled property of > the component is not view specific and has been changed by another > view or is changed before the apply request values phase. (S) Make > sure the rendered and/or disabled properties of components do not > change after rendering and before the apply request values. > > -Andrew > > On 6/5/07, Shane Petroff <[EMAIL PROTECTED]> wrote: >> Mike Kienenberger wrote: >> > I've also had it happen if the page changes and the facelets component >> > tree (or jsp page) is still cached somewhere. >> I'm almost completely certain it is not a caching issue (although it >> would be good to know if one could configure Tomcat not to cache >> anything, ever...) I've hand nuked caches several times and tried >> executing on a different machine (Tomcat running on the localhost in >> both cases). >> >> Shane >> > Same idea -- the >> > expected submitted page elements do not match the actual submitted >> > page elements. >> > >> > On 6/5/07, Shane Petroff <[EMAIL PROTECTED]> wrote: >> >> >> >> I am having some strange navigation problems (once again...) and the >> >> only clue I have is the warning below. >> >> >> >> HtmlRendererUtils - There should always be a submitted value for an >> >> input if it is rendered, its form is submitted, and it is not >> disabled >> >> or read-only. >> >> >> >> In Googling the error message, it seems that the problem should be >> >> related to using Javascript to disable a control which my-faces >> expects >> >> to get a value from. The warning goes on to name the component in >> >> qu
Re: HtmlRendererUtils - There should always be a submitted value
Mike Kienenberger wrote: I'm confused. That's good, at least I have some company! :) Clearly, something has changed from the time it was sent to the browser (generated html) and the time it was received from the browser (submitted values). That's what seems to be the case. Also, if the generated html has _id30, clearly there is no explicit name for contentPanel. This particular panel is one of the few things named in the jsp columns="1" border="1" width="100%" cellspacing="0" styleClass="panel"/> (It's name used to be 'mainPanel' to better match the binding, but it an effort to ensure that caching wasn't an issue, I renamed it) a) create a simplified example showing the problem, or If only I'd looked into Selenium earlier, I might have become aware of the time at which the problem was introduced... I only see the issue once things are large. b) post your page code, the generated html, and the form-value pairs submitted afterward. I don't know how much good the creation code would be, since execution paths through it all depend on the metadata coming out of the database (the components added to the page depend on context like the user viewing the page and the attributes of the person being represented on the page). I'll send a copy of the generated html shortly (I have reams of stuff commented out right now to try to isolate the issue). Is there any upper limit to the number of components which can reliably be rendered? One of the things that my users have requested is lots of contextual information, as a result, this page has grown huge. The reason I ask is that the discrepancy between id and request params is not the only problem. I commented out the code which creates the text areas which the warnings complain about, but my navigation issues were still not fixed. I can successively comment things out to get back to a point where navigation functions again, but I haven't yet tracked down the code which kills things (it seems to be in 2 areas). For now, I'm working under the rather baseless assumption that the 2 problems are interrelated. Thanks for your efforts so far. Shane On 6/8/07, Shane Petroff <[EMAIL PROTECTED]> wrote: Mike Kienenberger wrote: > So the question is why does _id30 get translated to contentPanel_1153 > and _id33 get translated to contentPanel_1344 on submit? > That would be the question alright... It seems as though the problem actually happens before/during html generation. On submit, it's too late. > It looks like you've went from automatically generated ids for these > components to explicitly-set (plus some random number) ids for these > components. The parameter map seems like it is the correct one. The text areas in question sit in tabs located on 'mainForm'. Specifically the containment looks like: mainForm (explicitly named) contentPanel (explicitly named) Tab_1 (generated id) Panel_1 (generated id) editableAnecdotalComment548806536 (explicitly named - the numbers at the end refer to a db id) Shane > > > On 6/8/07, Shane Petroff <[EMAIL PROTECTED]> wrote: >> At the point where the warning is logged, >> component.getClientId(FacesContext) doesn't return a value contained in >> the request parameter map. While that's good for me to know, I'm >> guessing you guys already knew that :) What could cause the mismatch? >> Thanks in advance. > > On 6/8/07, Shane Petroff <[EMAIL PROTECTED]> wrote: >> Mike Kienenberger wrote: >> > Another way would be to set a breakpoint somewhere and >> > check what's in the request parameter map for the current request. >> OK, what I've done is to add a Servlet Filter to the mix (in looking at >> example code, it seems that the filter may come in handy down the line). >> What I figured was that the filter will get processed early, and is >> therefore a good place to set a breakpoint to examine request >> parameters. (Although as I write this I'm wondering about filter >> ordering and the Extensions filter) It seems as though the component >> id's do not correspond to the request parameters which make it through >> to the filter. In the generated html I have >> >> id="mainForm:_id30:_id33:editableAnecdotalComment548806536" >> >> and in the request I have >> >> param: >> mainForm:contentPanel_1153:contentPanel_1344:editableAnecdotalComment548806536, >> >> >> value: [Ljava.lang.String;@1fff293 >> >> The "editableAnecdotalComment548806536" portion is the ID that I set. >> All of the _idXX components get ma
Re: HtmlRendererUtils - There should always be a submitted value
Mike Kienenberger wrote:
A) First request -- generated html created
B) modify form, hit submit. Form values created.
C) second request - component tree restored, form values matched with
component tree ids.
Please double and triple-check that the form values created in B are
different than the names/ids generated in A. I can think of no
reason why this would happen.
You are correct; there is no difference from A to B. Evidently I copied
the component names I sent earlier from a page which had been
re-rendered. Sorry about that. The component names in the originally
generated page source match the names logged by my filter eg:
mainForm:contentPanel_209:contentPanel_314:editableAnecdotalComment548806167
One additional thing that seems odd. When I described the containment
previously, I forgot about a couple of layers. The component path that
the warning generates doesn't seem to jive with the component name. I
don't know if this is an issue at all, but I expected there to be more
correspondence. I also didn't expect to see something with a null id in
the mix.
2007-06-11 15:41:57,140 WARN - There should always be a submitted value ...
[Class: javax.faces.component.UIViewRoot,ViewId: /pages/reportCard.jsp]
[Class: javax.faces.component.html.HtmlForm,Id: mainForm]
[Class: javax.faces.component.html.HtmlPanelGrid,Id: detailPanel]
[Class: javax.faces.component.html.HtmlPanelGrid,Id: contentPanel]
[Class: org.apache.myfaces.custom.tabbedpane.HtmlPanelTabbedPane,Id: _id0]
[Class: org.apache.myfaces.custom.tabbedpane.HtmlPanelTab,Id: _id6]
[Class: javax.faces.component.html.HtmlPanelGrid,Id: null]
[Class: org.apache.myfaces.custom.tabbedpane.HtmlPanelTabbedPane,Id: _id7]
[Class: org.apache.myfaces.custom.tabbedpane.HtmlPanelTab,Id: _id9]
[Class: javax.faces.component.html.HtmlPanelGrid,Id:
anecdotalCommentPanelGrid5488061672]
[Class: javax.faces.component.html.HtmlInputTextarea,Id:
editableAnecdotalComment548806167]
If the difference is not until C, I can think of a possibility.
binding="#{reportCardBean.mainPanel}"
What scope is reportCardBean?
Request. Since it is so easy to change, I naively tried out a session
scoped version, but it had the same problems. It's been request scoped
for it's whole life though, including versions that worked (IIRC request
scope is recommended).
If the original component is lost, and you bind it to a new component
(probably completely auto-generated, giving the _id* values that we
saw before), then this would explain why the submitted form values can
no longer be matched up to the newly-created component paths in C.
I'm not sure I follow. Despite my previous misleading mail, subsequent
versions of the page (I can't navigate away from it once it's been
opened) also have a correspondence between component names and request
parameters albeit with generated names like:
mainForm:_id6:_id9:editableAnecdotalComment548806167
The component path though seems very consistent with the previous
rendering: (only generated id's differ)
[Class: javax.faces.component.UIViewRoot,ViewId: /pages/reportCard.jsp]
[Class: javax.faces.component.html.HtmlForm,Id: mainForm]
[Class: javax.faces.component.html.HtmlPanelGrid,Id: detailPanel]
[Class: javax.faces.component.html.HtmlPanelGrid,Id: contentPanel]
[Class: org.apache.myfaces.custom.tabbedpane.HtmlPanelTabbedPane,Id: _id51]
[Class: org.apache.myfaces.custom.tabbedpane.HtmlPanelTab,Id: _id57]
[Class: javax.faces.component.html.HtmlPanelGrid,Id: null]
[Class: org.apache.myfaces.custom.tabbedpane.HtmlPanelTabbedPane,Id: _id58]
[Class: org.apache.myfaces.custom.tabbedpane.HtmlPanelTab,Id: _id60]
[Class: javax.faces.component.html.HtmlPanelGrid,Id:
anecdotalCommentPanelGrid5488061672]
[Class: javax.faces.component.html.HtmlInputTextarea,Id:
editableAnecdotalComment548806167]
Thanks for sticking with me, I owe you a case of virtual beer!
Shane
On 6/11/07, Shane Petroff <[EMAIL PROTECTED]> wrote:
Mike Kienenberger wrote:
> I'm confused.
That's good, at least I have some company! :)
> Clearly, something has changed from the time it was sent to the
> browser (generated html) and the time it was received from the browser
> (submitted values).
That's what seems to be the case.
> Also, if the generated html has _id30, clearly there is no explicit
> name for contentPanel.
This particular panel is one of the few things named in the jsp
binding="#{reportCardBean.mainPanel}"
columns="1" border="1" width="100%" cellspacing="0"
styleClass="panel"/>
(It's name used to be 'mainPanel' to better match the binding, but it an
effort to ensure that caching wasn't an issue, I renamed it)
> a) create a simplified example showing the problem, or
If only I'd looked into Selenium earlier, I might have become
Re: HtmlRendererUtils - There should always be a submitted value
Shane Petroff wrote:
Mike Kienenberger wrote:
A) First request -- generated html created
B) modify form, hit submit. Form values created.
C) second request - component tree restored, form values matched with
component tree ids.
Please double and triple-check that the form values created in B are
different than the names/ids generated in A. I can think of no
reason why this would happen.
You are correct; there is no difference from A to B. Evidently I
copied the component names I sent earlier from a page which had been
re-rendered. Sorry about that. The component names in the originally
generated page source match the names logged by my filter eg:
mainForm:contentPanel_209:contentPanel_314:editableAnecdotalComment548806167
Forgot to point out that when the warning is generated, the clientId
which cannot be found is:
mainForm:_id6:_id9:editableAnecdotalComment548806167
This value comes from a separate session, so the generated id's won't
necessarily match, but the point is that the warning is generated for
the same reason: this clientId doesn't match any request parameters.
Shane
One additional thing that seems odd. When I described the containment
previously, I forgot about a couple of layers. The component path that
the warning generates doesn't seem to jive with the component name. I
don't know if this is an issue at all, but I expected there to be more
correspondence. I also didn't expect to see something with a null id
in the mix.
2007-06-11 15:41:57,140 WARN - There should always be a submitted
value ...
[Class: javax.faces.component.UIViewRoot,ViewId: /pages/reportCard.jsp]
[Class: javax.faces.component.html.HtmlForm,Id: mainForm]
[Class: javax.faces.component.html.HtmlPanelGrid,Id: detailPanel]
[Class: javax.faces.component.html.HtmlPanelGrid,Id: contentPanel]
[Class: org.apache.myfaces.custom.tabbedpane.HtmlPanelTabbedPane,Id:
_id0]
[Class: org.apache.myfaces.custom.tabbedpane.HtmlPanelTab,Id: _id6]
[Class: javax.faces.component.html.HtmlPanelGrid,Id: null]
[Class: org.apache.myfaces.custom.tabbedpane.HtmlPanelTabbedPane,Id:
_id7]
[Class: org.apache.myfaces.custom.tabbedpane.HtmlPanelTab,Id: _id9]
[Class: javax.faces.component.html.HtmlPanelGrid,Id:
anecdotalCommentPanelGrid5488061672]
[Class: javax.faces.component.html.HtmlInputTextarea,Id:
editableAnecdotalComment548806167]
If the difference is not until C, I can think of a possibility.
binding="#{reportCardBean.mainPanel}"
What scope is reportCardBean?
Request. Since it is so easy to change, I naively tried out a session
scoped version, but it had the same problems. It's been request scoped
for it's whole life though, including versions that worked (IIRC
request scope is recommended).
If the original component is lost, and you bind it to a new component
(probably completely auto-generated, giving the _id* values that we
saw before), then this would explain why the submitted form values can
no longer be matched up to the newly-created component paths in C.
I'm not sure I follow. Despite my previous misleading mail, subsequent
versions of the page (I can't navigate away from it once it's been
opened) also have a correspondence between component names and request
parameters albeit with generated names like:
mainForm:_id6:_id9:editableAnecdotalComment548806167
The component path though seems very consistent with the previous
rendering: (only generated id's differ)
[Class: javax.faces.component.UIViewRoot,ViewId: /pages/reportCard.jsp]
[Class: javax.faces.component.html.HtmlForm,Id: mainForm]
[Class: javax.faces.component.html.HtmlPanelGrid,Id: detailPanel]
[Class: javax.faces.component.html.HtmlPanelGrid,Id: contentPanel]
[Class: org.apache.myfaces.custom.tabbedpane.HtmlPanelTabbedPane,Id:
_id51]
[Class: org.apache.myfaces.custom.tabbedpane.HtmlPanelTab,Id: _id57]
[Class: javax.faces.component.html.HtmlPanelGrid,Id: null]
[Class: org.apache.myfaces.custom.tabbedpane.HtmlPanelTabbedPane,Id:
_id58]
[Class: org.apache.myfaces.custom.tabbedpane.HtmlPanelTab,Id: _id60]
[Class: javax.faces.component.html.HtmlPanelGrid,Id:
anecdotalCommentPanelGrid5488061672]
[Class: javax.faces.component.html.HtmlInputTextarea,Id:
editableAnecdotalComment548806167]
Thanks for sticking with me, I owe you a case of virtual beer!
Shane
On 6/11/07, Shane Petroff <[EMAIL PROTECTED]> wrote:
Mike Kienenberger wrote:
> I'm confused.
That's good, at least I have some company! :)
> Clearly, something has changed from the time it was sent to the
> browser (generated html) and the time it was received from the
browser
> (submitted values).
That's what seems to be the case.
> Also, if the generated html has _id30, clearly there is no explicit
> name for contentPanel.
This particular panel is one of the few things named in the jsp
binding="#{reportCardBean.mainPanel}&qu
Re: HtmlRendererUtils - There should always be a submitted value
Mike Kienenberger wrote:
binding="#{reportCardBean.mainPanel}"
What scope is reportCardBean?
If the original component is lost, and you bind it to a new component
(probably completely auto-generated, giving the _id* values that we
saw before), then this would explain why the submitted form values can
no longer be matched up to the newly-created component paths in C.
I'm a little confused by this. I was under the impression that one was
supposed to use request scoped beans when binding to the UI, but you
seem to be suggesting that this causes the problem.
In any case, to clarify the situation (I hope), I've included a link
below which points to a zip file containing a stripped down project.
I've deleted gobs of stuff from there so hopefully the remaining
classes/files retain some cohesion to an external audience. The zip
contains java, jsp and config files. In spite of the maven style
directory structure, I haven't actually migrated yet, so dependencies
could be a problem. (I'm assuming that most of you will already have
everything, and including them in the zip would needlessly create a
larger download). I've also included my Intellij IDEA project files in
the off chance that someone else uses it. I've mocked out the data
access layer (no comments on how awful the mocked code is), so it should
be self contained. I've also included a single Selenium IDE test. It's
not really a 'test' per se, rather it is a convenient way to navigate to
the problem page without my having to describe it. Most of the paths
through this stripped down version are broken, so letting Selenium
handle the navigation seemed easiest. The test is in src\test\selenium.
I actually have 2 classes of problems I can't figure out. The first is
the one outlined in this email's subject. If you navigate to the detail
page via Selenium, then click on one of the other Student command links
at the left, MyFaces will complain about no submitted values.
Annoyingly, if you continue selecting different students, the problem
partially self-corrects in that at least it complains about fewer
cases... The other problem can be seen by editing application.properties
and changing the second entry ViewAptitudes to true, then restarting
Tomcat. This 'enables' some additional gui building code which somehow
messes with navigating through students via the same command links. With
the new UI, every *second* click of the student commandLink works.
During the submits where nothing happens, the appropriate backing bean
is created, but none of it's methods are called and the page refreshes.
Any help is greatly appreciated.
http://www.mayet.ca/downloads/
--
Shane
Re: HtmlRendererUtils - There should always be a submitted value
Shane Petroff wrote: I actually have 2 classes of problems I can't figure out. The first is the one outlined in this email's subject MyFaces will complain about no submitted values. ... With the new UI, every *second* click of the student commandLink works. During the submits where nothing happens, the appropriate backing bean is created, but none of it's methods are called and the page refreshes. FWIW, I can eliminate both problems by reverting to old myfaces versions. If I back-date to an old tomahawk-1.1.5-SNAPSHOT.jar I can eliminate the warnings. If I back-date the core to mayfaces-api-1.1.4.jar and mayfaces-impl-1.1.4.jar then the weird navigation issues go away too. I'll try to pare the example code down further before submitting the bugs. -- Shane
Re: [Trinidad] Authorisation & Authentication? (JAAS?)
Frank Nimphius wrote: Usually authorization is enforced on the business service layer and surfaces in the UI. If e.g. a user has a permission, JAAS or container managed, to update an attribute then this could/should be exposed in the UI through expression language, referencing a method on the model that performs the check permission call. What are the current best practices regarding security and JSF? Am I better off integrating with something like Acegi (since I already use Spring)? Googling the 2 suggests that Acegi integration can be painful, but now that was then... A JAAS based approach seems like it gives one lots of flexibility, but requires more work on the developers part. What are other people using to provide method level authorization checks? Shane Beside of this, security needs to be on page navigation, which is something you need to implement in the JSF engine (MyFaces or JSF RI). Have a look at http://www.orablogs.com/fnimphius/archives/001790.html http://www.orablogs.com/fnimphius/archives/001836.html where I created a sample for container managed and JAAS authorization. However, from this little development experience I can say that security in JSF is nothing you implement within an afternoon but requires a well thought through security framework that integrates not only with the UI but also the model fro a consistent security enforcement. The easiest way to get started with such an effort is to look at the security design patterns that exist and work your way back to JSF- Frank Hi all, Can anyone please point me in the right direction as regards methods to execute authorisation & authentication to a Trinidad webapp. Something along the lines of Java Authentication and Authorization Service (JAAS). We want to implement an authorisation 'front door' as an underlining layer. Has Trinidad its own implementation? I can't seem to find any information in this regards. Any info' would be appreciated! Best regards, Darren. P Please consider the environment before printing this email _ 1. The information contained in this E-mail, including any files transmitted with it, is confidential and may be legally privileged. This E-mail is intended only for the personal attention of the stated addressee(s). Any access to this E-mail, including any files transmitted with it, by any other person is unauthorised. If you are not an addressee, you must not disclose, copy, circulate or in any other way use or rely on the information contained in this E-mail or any files transmitted with it. Such unauthorised use may be unlawful. If you have received this E-mail in error, please inform the sender immediately and delete it and all copies from your system. You may not forward this E-mail without the permission of the sender. 2. The views expressed in this E-mail are those of the author, and do not necessarily represent the views of AMT-SYBEX. Internet communications are not secure and AMT-SYBEX cannot, therefore, accept legal responsibility for the contents of this message nor for any damage caused by viruses. AMT-SYBEX Limited is a UK company, registration number GB03036807 at address The Spirella Building, Bridge Road, Letchworth, SG6 4ET. AMT-SYBEX (NI) Limited is a UK company, registration number NI024104 at address Edgewater Office Park, Edgewater Rd, Belfast, BT3 9JQ. For more information on the AMT-SYBEX Group visit http://www.amt-sybex.com _ -- Frank Nimphius -- Shane
Re: [Tobago] spell checker for textarea input exmaples?
Wong, Emmanuel (Sam) wrote: Does anyone tell me where I could get spell checker for implementing Tobago textarea input field? Thanks. I'm assuming that you've Googled it already and are asking because there are so many choices... While I don't use Tobago, there are tons of paid spell check utilities which should work. After a short search for open source variants, I tried JSPSpellcheck. It is not particularly fancy, and I have not yet put it into production. However, it is pure jsp so it integrates easily and so far it has functioned reasonably (it is just a jsp front end for Jazzy). http://sourceforge.net/project/showfiles.php?group_id=131661 -- Shane
Re: does anyone use Spell Checker for JSF?
Wong, Emmanuel (Sam) wrote: Does anyone use any Spell checker for the JSF? Yes I tried to do a search and nothing much about using JSF with the spell checker. That is because there is nothing in the problem which is germane to JSF. Hell, all you have to do is use Firefox 2.x and you get inline spell checking out of the box. -- Shane
Re: Dynamic tabs in panelTabbedPane
I don't know if it is doable with the declarative syntax via jsp/facelets, but it would be easy to use a parent panel's binding, then build your tabs in java code. Shane geirgp wrote: Hi, Is it possible for the panelTabbedPane to iterate over a java.util.List and create one tab for each entry in the list? I tried enclosing the panelTabs in a dataList (see below) but then no tabs were created and all information from all objects in the list were printed on the same panel. -- Shane
Re: [Trinidad] Internet Explorer 5.5 ?
Stephen Friedrich wrote: Now I have two choices: I either fulfill this requirement or I try and pick a fight. And apparently, since everyone in your organization is equally lazy, the guidelines will stay fixed forever. :) Seriously, if the link Andrew provided doesn't motivate a change, or review at least, maybe it is time to find a new employer. At the very least, the sane approach is for all new projects to adopt a more modern set of standards. Updating legacy stuff might be cost prohibitive, but new projects shouldn't have to pay a hefty price (equate it to dollars) for compatibility with unsupported security risks. You might even try the angle that it represents a potential liability to your company because there are no further security patches. Regardless, if the suits can't provide tangible proof that the requirement is real (e.g. a major client who can't upgrade for some feasible reason, internal deployment only etc.), they have demonstrated a serious lack of foresight, and who wants to be saddled with that? And finally, it is most decidedly not "a fight". If you go into it with that mentality and get your ass kicked, you deserve it. Find out where the resistance is coming from and what kind of context is required to specify your evidence in terms that they will understand. Analyze the situation and propose a solution. If your bosses can't respond to that kind of presentation reasonably, it is time to get out. -- Shane
Re: [Trinidad] Internet Explorer 5.5 ?
Nebinger, David wrote: I think you folks are being way to hard on this guy. Thus far 'folks' can only refer to me, since Andrew's comments related to Trinidad compatibility. I'm fine with your assessment though! :) It's really just a 'hot button' of mine. 'you need to upgrade', but they could turn around and tell me they don't want my business The operative word here is "could". If you explain to them what the ramifications of their choices are and they still make bad decisions, then you must decide if their business is worth your trouble and charge them accordingly. The point is that way too many times these bad choices are more a function of poor communication than merely inane business decisions. IME, lots of 'mom-n-pop' shops will make the right choice when presented with all of the information (even some gov't departments have!). Make sure that all of the stakeholders know what the issues are before giving in to inertia. -- Shane
File download and out of memory
Hello,
I'm having a problem with a link used to download a "large" file. I say
large in quotation because by modern standards, the 5MB file I'm talking
about is tiny; I need to be able to handle at least 20MB. The same code
works for small files (<25K), but dies on larger ones. Hopefully it is a
configuration issue. On the jsp, there is a commandLink bound to the
"onDownload" action pasted below. The only config I can imagine that
might come into play is configuring the extensions filter itself. I've
specified UTF-8 encodings by default since several pages must support
extended characters. I'm currently using MyFaces core 1.1.5, Tomahawk
1.1.6 and Tomcat 5.5.23
The stack trace is:
java.lang.OutOfMemoryError: Java heap space
at java.util.Arrays.copyOf(Arrays.java:2882)
at
java.lang.AbstractStringBuilder.expandCapacity(AbstractStringBuilder.java:100)
at
java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:572)
at java.lang.StringBuffer.append(StringBuffer.java:320)
at
org.apache.myfaces.shared_tomahawk.renderkit.html.util.UnicodeEncoder.encode(UnicodeEncoder.java:54)
(full stack trace below)
Extension Filter config:
MyFacesExtensionsFilter
org.apache.myfaces.webapp.filter.ExtensionsFilter
maxFileSize
90m
uploadMaxFileSize
90m
Action code:
public String onDownload()
{
String rtn = Constants.ERROR_OUTCOME;
FileInputStream fis = null;
OutputStream os = null;
try
{
File file = buildFile(); // creates a 5MB file. If I hack
this to return a 25K file, it all works well
FacesContext fc = FacesContext.getCurrentInstance();
HttpServletResponse response = (HttpServletResponse)
fc.getExternalContext().getResponse();
response.setHeader("Content-disposition", "attachment;
filename=" + file.getName());
response.setContentType("application/xml");
fis = new FileInputStream(file);
os = new BufferedOutputStream(response.getOutputStream());
int read;
while( (read = fis.read()) != -1 )
os.write(read);
os.flush();
fc.responseComplete();
rtn = Constants.SUCCESS_OUTCOME;
}
catch ( Exception e )
{
logException( MessageConstants.LOADING_ERROR_PREFIX + "XML",
e );
}
finally
{
try
{
os.close();
fis.close();
}
catch(Exception ignored) { /* we don't care about NPE's
either */ }
}
return rtn;
}
Full Stack Trace:
java.lang.OutOfMemoryError: Java heap space
at java.util.Arrays.copyOf(Arrays.java:2882)
at
java.lang.AbstractStringBuilder.expandCapacity(AbstractStringBuilder.java:100)
at
java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:572)
at java.lang.StringBuffer.append(StringBuffer.java:320)
at
org.apache.myfaces.shared_tomahawk.renderkit.html.util.UnicodeEncoder.encode(UnicodeEncoder.java:54)
at
org.apache.myfaces.shared_tomahawk.renderkit.html.HtmlResponseWriterImpl.write(HtmlResponseWriterImpl.java:567)
at
org.apache.myfaces.renderkit.html.util.DefaultAddResource.writeResponse(DefaultAddResource.java:847)
at
org.apache.myfaces.webapp.filter.ExtensionsFilter.doFilter(ExtensionsFilter.java:162)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:215)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)
at
org.springframework.orm.hibernate3.support.OpenSessionInViewFilter.doFilterInternal(OpenSessionInViewFilter.java:173)
at
org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:77)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:215)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)
at
ca.mayet.SessionTimeoutRedirectFilter.doFilter(SessionTimeoutRedirectFilter.java:78)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:215)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:210)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:174)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:117)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:108)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:151)
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:870)
at
org.apa
Re: File download and out of memory
Anyone have any guesses even? Is there a better technique? (the code was
almost copied/pasted out of the wiki) I had wondered if the buildFile()
method was leaving some resources open. Since I don't write a lot of I/O
code (and since I wanted to convince myself of my own sanity), it is
currently stubbed out to return a handle to a pre-existing file. I've
stopped declaring a UTF-8 encoding, although UnicodeEncoder is still
invoked. There doesn't appear to be a lot I can change with this. Should
I just drop Tomahawk and the ExtensionsFilter altogether and try
Trinidad? (is there any documentation on converting over)
Shane
Shane Petroff wrote:
Hello,
I'm having a problem with a link used to download a "large" file. I
say large in quotation because by modern standards, the 5MB file I'm
talking about is tiny; I need to be able to handle at least 20MB. The
same code works for small files (<25K), but dies on larger ones.
Hopefully it is a configuration issue. On the jsp, there is a
commandLink bound to the "onDownload" action pasted below. The only
config I can imagine that might come into play is configuring the
extensions filter itself. I've specified UTF-8 encodings by default
since several pages must support extended characters. I'm currently
using MyFaces core 1.1.5, Tomahawk 1.1.6 and Tomcat 5.5.23
The stack trace is:
java.lang.OutOfMemoryError: Java heap space
at java.util.Arrays.copyOf(Arrays.java:2882)
at
java.lang.AbstractStringBuilder.expandCapacity(AbstractStringBuilder.java:100)
at
java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:572)
at java.lang.StringBuffer.append(StringBuffer.java:320)
at
org.apache.myfaces.shared_tomahawk.renderkit.html.util.UnicodeEncoder.encode(UnicodeEncoder.java:54)
(full stack trace below)
Extension Filter config:
MyFacesExtensionsFilter
org.apache.myfaces.webapp.filter.ExtensionsFilter
maxFileSize
90m
uploadMaxFileSize
90m
Action code:
public String onDownload()
{
String rtn = Constants.ERROR_OUTCOME;
FileInputStream fis = null;
OutputStream os = null;
try
{
File file = buildFile(); // creates a 5MB file. If I hack
this to return a 25K file, it all works well
FacesContext fc = FacesContext.getCurrentInstance();
HttpServletResponse response = (HttpServletResponse)
fc.getExternalContext().getResponse();
response.setHeader("Content-disposition", "attachment;
filename=" + file.getName());
response.setContentType("application/xml");
fis = new FileInputStream(file);
os = new BufferedOutputStream(response.getOutputStream());
int read;
while( (read = fis.read()) != -1 )
os.write(read);
os.flush();
fc.responseComplete();
rtn = Constants.SUCCESS_OUTCOME;
}
catch ( Exception e )
{
logException( MessageConstants.LOADING_ERROR_PREFIX +
"XML", e );
}
finally
{
try
{
os.close();
fis.close();
}
catch(Exception ignored) { /* we don't care about NPE's
either */ }
}
return rtn;
}
Full Stack Trace:
java.lang.OutOfMemoryError: Java heap space
at java.util.Arrays.copyOf(Arrays.java:2882)
at
java.lang.AbstractStringBuilder.expandCapacity(AbstractStringBuilder.java:100)
at
java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:572)
at java.lang.StringBuffer.append(StringBuffer.java:320)
at
org.apache.myfaces.shared_tomahawk.renderkit.html.util.UnicodeEncoder.encode(UnicodeEncoder.java:54)
at
org.apache.myfaces.shared_tomahawk.renderkit.html.HtmlResponseWriterImpl.write(HtmlResponseWriterImpl.java:567)
at
org.apache.myfaces.renderkit.html.util.DefaultAddResource.writeResponse(DefaultAddResource.java:847)
at
org.apache.myfaces.webapp.filter.ExtensionsFilter.doFilter(ExtensionsFilter.java:162)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:215)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)
at
org.springframework.orm.hibernate3.support.OpenSessionInViewFilter.doFilterInternal(OpenSessionInViewFilter.java:173)
at
org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:77)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:215)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)
at
ca.mayet.SessionTimeoutRedirectFilter.doFilter(SessionTimeoutRedirectFilter.java:78)
a
Re: [Trinidad] Config
Matthias Wessendorf wrote: have you set the Trinidad renderkit ? Doh!!! While it is definitely included in the example projects, it would be good if the config section of the Developers Guide at least mentioned that it is mandatory. http://myfaces.apache.org/trinidad/devguide/configuration.html Shane -M On Feb 7, 2008 6:35 PM, Shane Petroff <[EMAIL PROTECTED]> wrote: Hi, I have an existing Tomahawk based application, to which I wanted to add some new features. I wanted to start out with some basic Trinidad PPR, so I copied the configuration details from one of the Trinidad hello-world examples, but I must have messed something up. (Trinidad 1.0.5, Myfaces Core 1.1.4). Originally I thought this was a 1.1.4 problem (I can't upgrade to 1.1.5 Core because of a bug), but the problem persists even when I use the new version. With this config, the application still runs, but the tr: components don't show up, and I get 2 errors: ERROR - No component states to be saved in client response! (appears sporadically even before using a tr: component) 2008-02-07 00:14:13,753 WARN - Unsupported component-family/renderer-type: org.apache.myfaces.trinidad.Input/org.apache.myfaces.trinidad.Text Feb 7, 2008 12:14:13 AM org.apache.myfaces.trinidad.component.UIXComponentBase _getRendererImpl WARNING: Could not find renderer for CoreInputText[UIXEditableFacesBeanImpl, id=withdrawalDate] rendererType = org.apache.myfaces.trinidad.Text Feb 7, 2008 12:14:15 AM org.apache.myfaces.trinidad.component.UIXComponentBase _getRendererImpl In terms of the new configurations added, they include: s org.apache.myfaces.trinidad.CACHE_VIEW_ROOTfalse org.apache.myfaces.trinidad.USE_APPLICATION_VIEW_CACHEfalse org.apache.myfaces.trinidad.CHECK_FILE_MODIFICATIONtrue org.apache.myfaces.trinidad.CHANGE_PERSISTENCE session trinidad org.apache.myfaces.trinidad.webapp.TrinidadFilter trinidad Faces Servlet resources org.apache.myfaces.trinidad.webapp.ResourceServlet resources /adf/* (no trinidad-config.xml as of yet) Is there something in the config that I've missed? -- Shane -- Shane
[Trinidad] Config
Hi, I have an existing Tomahawk based application, to which I wanted to add some new features. I wanted to start out with some basic Trinidad PPR, so I copied the configuration details from one of the Trinidad hello-world examples, but I must have messed something up. (Trinidad 1.0.5, Myfaces Core 1.1.4). Originally I thought this was a 1.1.4 problem (I can't upgrade to 1.1.5 Core because of a bug), but the problem persists even when I use the new version. With this config, the application still runs, but the tr: components don't show up, and I get 2 errors: ERROR - No component states to be saved in client response! (appears sporadically even before using a tr: component) 2008-02-07 00:14:13,753 WARN - Unsupported component-family/renderer-type: org.apache.myfaces.trinidad.Input/org.apache.myfaces.trinidad.Text Feb 7, 2008 12:14:13 AM org.apache.myfaces.trinidad.component.UIXComponentBase _getRendererImpl WARNING: Could not find renderer for CoreInputText[UIXEditableFacesBeanImpl, id=withdrawalDate] rendererType = org.apache.myfaces.trinidad.Text Feb 7, 2008 12:14:15 AM org.apache.myfaces.trinidad.component.UIXComponentBase _getRendererImpl In terms of the new configurations added, they include: s org.apache.myfaces.trinidad.CACHE_VIEW_ROOTfalse org.apache.myfaces.trinidad.USE_APPLICATION_VIEW_CACHEfalse org.apache.myfaces.trinidad.CHECK_FILE_MODIFICATIONtrue org.apache.myfaces.trinidad.CHANGE_PERSISTENCE session trinidad org.apache.myfaces.trinidad.webapp.TrinidadFilter trinidad Faces Servlet resources org.apache.myfaces.trinidad.webapp.ResourceServlet resources /adf/* (no trinidad-config.xml as of yet) Is there something in the config that I've missed? -- Shane
[Trinidad] PPR and inputDate problems
Hi,
My first experiment with Trinidad hasn't gone too well. I wanted to test
out a very simple ppr case, but cannot get it to work. I want to 'tie'
two controls together via value change. I've pasted the entire page
below my sig (or rather a functional, but simpler version of the real
thing), but the 2 fields in question are:
styleClass="label"/>
valueChangeListener="#{classListBean.finalMarkChanged}"/>
value="#{bundle.ClassListWithdrawalDateHeader}" styleClass="label"/>
and in the backing bean
public void finalMarkChanged( ValueChangeEvent event )
{
StudentSection ss = (StudentSection) m_Table.getRowData();
ss.setWithdrawalDate(new Date());
System.out.println( "finalMarkChanged for " +
ss.getStudentName() + " " + ss.getWithdrawalDate() );
}
The autoSubmit is working, i.e. I can see that the value change event is
processed, but the partialTriggers portion has no effect and the
"withdrawalDate" field is never updated.
Also, the date picker is non-functional. The first time one attempts to
use it, the pop-up opens with the error below, and subsequent attempts
to open the pop-up are simply ignored.
HTTP Status 404 - /reportCard/__ADFv__.jsp
type Status report
message /reportCard/__ADFv__.jsp
description The requested resource (/reportCard/__ADFv__.jsp) is not
available.
Another annoyance is that default buttons no longer function throughout
the app.
--
Shane
<%@ page contentType="text/html;charset=UTF-8"%>
<%@ taglib uri="http://java.sun.com/jsf/core"; prefix="f"%>
<%@ taglib uri="http://java.sun.com/jsf/html"; prefix="h"%>
<%@ taglib uri="http://myfaces.apache.org/tomahawk"; prefix="t" %>
<%@ taglib uri="http://myfaces.apache.org/trinidad"; prefix="tr" %>
Re: [Trinidad] PPR and inputDate problems
Rafa Pérez wrote:
javax.faces.DEFAULT_SUFFIX
.jsp
in order to make inputDate and popups work properly.
Thanks, that sorts out the popup.
Any ideas why the partialTriggers aren't working?
Shane
Regards,
- - Rafa
On Feb 7, 2008 10:04 PM, Shane Petroff <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
Hi,
My first experiment with Trinidad hasn't gone too well. I wanted
to test
out a very simple ppr case, but cannot get it to work. I want to 'tie'
two controls together via value change. I've pasted the entire page
below my sig (or rather a functional, but simpler version of the real
thing), but the 2 fields in question are:
and in the backing bean
public void finalMarkChanged( ValueChangeEvent event )
{
StudentSection ss = (StudentSection) m_Table.getRowData();
ss.setWithdrawalDate(new Date());
System.out.println( "finalMarkChanged for " +
ss.getStudentName() + " " + ss.getWithdrawalDate() );
}
The autoSubmit is working, i.e. I can see that the value change
event is
processed, but the partialTriggers portion has no effect and the
"withdrawalDate" field is never updated.
Also, the date picker is non-functional. The first time one
attempts to
use it, the pop-up opens with the error below, and subsequent attempts
to open the pop-up are simply ignored.
HTTP Status 404 - /reportCard/__ADFv__.jsp
type Status report
message /reportCard/__ADFv__.jsp
description The requested resource (/reportCard/__ADFv__.jsp) is not
available.
Another annoyance is that default buttons no longer function
throughout
the app.
--
Shane
<%@ page contentType="text/html;charset=UTF-8"%>
<%@ taglib uri="http://java.sun.com/jsf/core"; prefix="f"%>
<%@ taglib uri="http://java.sun.com/jsf/html"; prefix="h"%>
<%@ taglib uri="http://myfaces.apache.org/tomahawk"; prefix="t" %>
<%@ taglib uri="http://myfaces.apache.org/trinidad"; prefix="tr" %>
valueChangeListener="#{classListBean.finalMarkChanged}"/>
--
Shane
Re: [Trinidad] PPR and inputDate problems
Matthias Wessendorf wrote:
On Feb 8, 2008 6:03 AM, Shane Petroff <[EMAIL PROTECTED]> wrote:
Any ideas why the partialTriggers aren't working?
are you using OR tags ?
They ensure all required CSS (Skinning) and JS files are sent down to the
client.
I'd go with , like
The code I attached earlier did not use tr:document, however I should
have noted that this was intentional. My original version did use the
tr:document, but the newly applied css didn't play nicely with the
existing styles, so I went back to the original. Using the Trinidad
document didn't affect the PPR behaviour though, I still had the
autoSubmit call working, but no refresh on the field specified in
partialTriggers. I hadn't really considered what else might be dependent
on the tr:document though, should I always use them (and modify my
styles to work with them)?
Shane
//only in JSP(X) required
all my content goes here
-M
Shane
Regards,
- - Rafa
On Feb 7, 2008 10:04 PM, Shane Petroff <[EMAIL PROTECTED]> wrote:
Hi,
My first experiment with Trinidad hasn't gone too well. I wanted to test
out a very simple ppr case, but cannot get it to work. I want to 'tie'
two controls together via value change. I've pasted the entire page
below my sig (or rather a functional, but simpler version of the real
thing), but the 2 fields in question are:
and in the backing bean
public void finalMarkChanged( ValueChangeEvent event )
{
StudentSection ss = (StudentSection) m_Table.getRowData();
ss.setWithdrawalDate(new Date());
System.out.println( "finalMarkChanged for " +
ss.getStudentName() + " " + ss.getWithdrawalDate() );
}
The autoSubmit is working, i.e. I can see that the value change event is
processed, but the partialTriggers portion has no effect and the
"withdrawalDate" field is never updated.
Also, the date picker is non-functional. The first time one attempts to
use it, the pop-up opens with the error below, and subsequent attempts
to open the pop-up are simply ignored.
HTTP Status 404 - /reportCard/__ADFv__.jsp
type Status report
message /reportCard/__ADFv__.jsp
description The requested resource (/reportCard/__ADFv__.jsp) is not
available.
Another annoyance is that default buttons no longer function throughout
the app.
--
Shane
<%@ page contentType="text/html;charset=UTF-8"%>
<%@ taglib uri="http://java.sun.com/jsf/core"; prefix="f"%>
<%@ taglib uri="http://java.sun.com/jsf/html"; prefix="h"%>
<%@ taglib uri="http://myfaces.apache.org/tomahawk"; prefix="t" %>
<%@ taglib uri="http://myfaces.apache.org/trinidad"; prefix="tr" %>
border="0"
headerClass="list-header"
cellspacing="0"
value="#{classListBean.studentSections}"
var="studentSec"
binding="#{classListBean.table}">
styleClass="label"/>
valueChangeListener="#{classListBean.finalMarkChanged}"/>
styleClass="label"/>
--
Shane
--
Shane
Re: [Trinidad] PPR and inputDate problems
Andrew Robinson wrote:
What trinidad build are you using?
Trinidad 1.0.5,
MyFaces Core 1.1.5
colons should not be necessary for components in the same naming
container.
Tried with and without. Using the colons clearly does not work because
it issues the warning:
WARNING: Could not find partial trigger :::finalMarkField from
CoreInputDate[UIXEditableFacesBeanImpl, id=_idJsp12]
With no preceding colons there is no warning generated, but the field is
never refreshed either. The value change method is below, as is a
stripped down jsp. I can see the value change being fired, but where
would I even set a breakpoint to tell if anything is happening on the
partialTriggers side?
public void finalMarkChanged( ValueChangeEvent event )
{
StudentSection ss = (StudentSection) m_Table.getRowData();
ss.setWithdrawalDate(new Date()); // I'm assuming that this
instance is still around to refresh the field from
System.out.println( "finalMarkChanged for " +
ss.getStudentName() + " " + ss.getWithdrawalDate() );
}
rowClasses="list-row-even,list-row-odd" cellpadding="4"
border="0"
headerClass="list-header"
cellspacing="0"
value="#{classListBean.studentSections}"
var="studentSec"
binding="#{classListBean.table}">
styleClass="label"/>
valueChangeListener="#{classListBean.finalMarkChanged}"/>
value="#{bundle.ClassListWithdrawalDateHeader}" styleClass="label"/>
timeZone="#{configBundle.TimeZone}"/>
On Feb 8, 2008 10:31 AM, Shane Petroff <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
Matthias Wessendorf wrote:
> ah,
> I just noticed, that "finalMarkField" is inside a table (naming
container).
> haven't read your code carefully, sorry.
>
> can you *try* partialTriggers=":::finalMarkField" ?
>
No joy... cleared the browser cache first, then dumped tomcat's cache,
did a full build and restarted the server. I also tried :: and
variants (3 does appear to be the correct number though based on the
generated html), but still no partial triggers refresh. Would it
be more
likely to work if I switched to a tr:table?
--
Shane
--
Shane
Re: [Trinidad] PPR and inputDate problems
Matthias Wessendorf wrote: ah, I just noticed, that "finalMarkField" is inside a table (naming container). haven't read your code carefully, sorry. can you *try* partialTriggers=":::finalMarkField" ? No joy... cleared the browser cache first, then dumped tomcat's cache, did a full build and restarted the server. I also tried :: and variants (3 does appear to be the correct number though based on the generated html), but still no partial triggers refresh. Would it be more likely to work if I switched to a tr:table? -- Shane
Re: [Trinidad] PPR and inputDate problems
Andrew Robinson wrote:
I think I know your problem. It is a phase issue
I'll take your word for it, but I guess the only thing I could do to try
and trace it through was to set a breakpoint in the decode method and
step through everything.
and why value change listeners (VCL) suck in JSF (really bad architecture)
Is there a better option? Even combos fire value changes.
The VCL architecture sucks as it is not transaction aware, and the
events fired in the validation doesn't mean that the update will ever
be done (so the new value may never become the actual value). Also,
when the VCL is invoked, the model is not updated, so you can't trust
values from the model layer (beans) since they may have pending changes.
I haven't tried it, but add a around each input. This
should only validate & update the value that has changed instead of
the entire form.
Didn't work. I'm using
One curious thing about this layout is that it can no longer find
partial triggers fields when a normal name is specified for partialTriggers.
Feb 8, 2008 5:12:16 PM
org.apache.myfaces.trinidadinternal.context.RequestContextImpl
addPartialTriggerListeners
WARNING: Could not find partial trigger finalMarkField from
CoreInputDate[UIXEditableFacesBeanImpl, id=_idJsp14]
I tried the preceding colons as well (4 of them this time because of the
additional nesting), but no luck there either.
Surely I'm not the first person to try to use PPR/ValueChange on an
editable table am I?
On Feb 8, 2008 1:14 PM, Shane Petroff <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
Andrew Robinson wrote:
What trinidad build are you using?
Trinidad 1.0.5,
MyFaces Core 1.1.5
colons should not be necessary for components in the same naming
container.
Tried with and without. Using the colons clearly does not work
because it issues the warning:
WARNING: Could not find partial trigger :::finalMarkField from
CoreInputDate[UIXEditableFacesBeanImpl, id=_idJsp12]
With no preceding colons there is no warning generated, but the
field is never refreshed either. The value change method is below,
as is a stripped down jsp. I can see the value change being fired,
but where would I even set a breakpoint to tell if anything is
happening on the partialTriggers side?
public void finalMarkChanged( ValueChangeEvent event )
{
StudentSection ss = (StudentSection) m_Table.getRowData();
ss.setWithdrawalDate(new Date()); // I'm assuming that
this instance is still around to refresh the field from
System.out.println( "finalMarkChanged for " +
ss.getStudentName() + " " + ss.getWithdrawalDate() );
}
valueChangeListener="#{classListBean.finalMarkChanged}"/>
On Feb 8, 2008 10:31 AM, Shane Petroff <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
Matthias Wessendorf wrote:
> ah,
> I just noticed, that "finalMarkField" is inside a table
(naming container).
> haven't read your code carefully, sorry.
>
> can you *try* partialTriggers=":::finalMarkField" ?
>
No joy... cleared the browser cache first, then dumped
tomcat's cache,
did a full build and restarted the server. I also tried ::
and
variants (3 does appear to be the correct number though based
on the
generated html), but still no partial triggers refresh. Would
it be more
likely to work if I switched to a tr:table?
--
Shane
--
Shane
--
Shane
Re: [Trinidad] PPR and inputDate problems
ViewFilter.doFilterInternal(OpenSessionInViewFilter.java:173)
at
org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:77)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:215)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)
at
ca.mayet.SessionTimeoutRedirectFilter.doFilter(SessionTimeoutRedirectFilter.java:78)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:215)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:210)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:174)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:117)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:108)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:151)
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:870)
at
org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:665)
at
org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:528)
at
org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:81)
at
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:685)
at java.lang.Thread.run(Thread.java:619)
How can I tell from this information which phase is being executed? I'm
assuming that the processValidators call buried in there tells me that
it is happening early (before model updates), but the info didn't mean
much to me. FWIW, there are no validators attached, unless there is
something embedded in the component itself.
otherwise, try this:
except for the names, this is what I'd tried previously. Unfortunately,
naming the subforms did not help.
In any case, thanks for all of your help Andrew.
Shane
Note that in trinidad 1.x.7 this will become
partialTriggers="::finalMarkForm:finalMarkField" (one less colon).
On Feb 8, 2008 4:26 PM, Shane Petroff <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
Andrew Robinson wrote:
I think I know your problem. It is a phase issue
I'll take your word for it, but I guess the only thing I could do
to try and trace it through was to set a breakpoint in the decode
method and step through everything.
and why value change listeners (VCL) suck in JSF (really bad
architecture)
Is there a better option? Even combos fire value changes.
The VCL architecture sucks as it is not transaction aware, and
the events fired in the validation doesn't mean that the update
will ever be done (so the new value may never become the actual
value). Also, when the VCL is invoked, the model is not updated,
so you can't trust values from the model layer (beans) since they
may have pending changes.
I haven't tried it, but add a around each input.
This should only validate & update the value that has changed
instead of the entire form.
Didn't work. I'm using
On Feb 8, 2008 1:14 PM, Shane Petroff <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
Andrew Robinson wrote:
What trinidad build are you using?
Trinidad 1.0.5,
MyFaces Core 1.1.5
colons should not be necessary for components in the same
naming container.
Tried with and without. Using the colons clearly does not
work because it issues the warning:
WARNING: Could not find partial trigger :::finalMarkField
from CoreInputDate[UIXEditableFacesBeanImpl, id=_idJsp12]
With no preceding colons there is no warning generated, but
the field is never refreshed either. The value change method
is below, as is a stripped down jsp. I can see the value
change being fired, but where would I even set a breakpoint
to tell if anything is happening on the partialTriggers side?
public void finalMarkChanged( ValueChangeEvent event )
{
StudentSection ss = (StudentSection)
m_Table.getRowData();
ss.setWithdrawalDate(new Date()); // I'm assuming
that this instance is sti
Re: [Trinidad] PPR and inputDate problems
Rafa Pérez wrote:
Could you change your h:dataTable for a tr:table?? Just to see what
happens...
Tried this days ago, but to no avail. The value change is fired, but no
partial triggers field refresh. The first time through it I used a plain
partialTriggers name. From there I tried ::finalMarkField (at first I
didn't notice that I'd lost one level of naming containers so I had 3
colons). I've also tried Andrew's subform and am using 2 inputText
components in case the inputDate is the issue. No dice on all accounts.
Shane
On Feb 11, 2008 8:30 AM, Shane Petroff <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
Andrew Robinson wrote:
Subform is a naming container, so you will have to give it an ID
and use colons to get out and back in.
OK, when I tried, I didn't explicitly name the subforms, I just
used 4 colons. Unfortunately, the subforms (named or not) made
things worse. When the subforms were introduced, the value change
listener is never called.
Replace the inputDate with an outputText of the same ID -- does
it update?
- If so this is not a PPR problem
It does not update; this was my original setup. It is not PPR per
se, because I slapped a couple of arbitrary text boxes on the form
and was able to get them linked very easily, the issue seems to be
PPR within the dataTable.
Leave it as an inputDate and use the Firebug extension in Firefox
to view the AJAX response. Does it contain the inputDate?
I've never really used Firebug before, so forgive me if I've got
it wrong, but in Inspect/Console, there appears to be POST entries
corresponding to the AJAX calls (Common1_0_5.js line 10680 to be
specific). The POST tab indicates what looks to be correct data:
_idJsp1:_idJsp4:6:finalMarkField44
_idJsp1:_idJsp4:6:withdrawalDate
_idJsp1:_idJsp4:7:finalMarkField
_idJsp1:_idJsp4:7:withdrawalDate
_idJsp1:_idJsp4:8:finalMarkField
_idJsp1:_idJsp4:8:withdrawalDate
_idJsp1:_idJsp4:9:finalMarkField
_idJsp1:_idJsp4:9:withdrawalDate
_idJsp1:xxx
_idJsp1:yyy
event autosub
org.apache.myfaces.trinidad.faces.FORM _idJsp1
org.apache.myfaces.trinidad.faces.STATE !5e7200c0
partial true
source _idJsp1:_idJsp4:6:finalMarkField
but the response tab make no mention of the date field.
<![CDATA[TrPage.getInstance()._addResetFields('_idJsp1',["source"]);]]><![CDATA
[var _idJsp1_SF={};]]>
If the above shows that it is not a PPR problem and you don't
want to bother with the subform, put a breakpoint in your set
method to see who is calling it and with what value. The stack
trace should show you the caller and you can determine the phase.
This I'd done previously, but wasn't able to decipher the results.
If I manufacture an exception, then fill in and print it's stack
trace, I get the following:
WARNING: Could not find partial trigger :::finalMarkField from
CoreInputText[UIXEditableFacesBeanImpl, id=withdrawalDate]
(The warning is generated prior to manufacturing the exception
below. This scenario is with no subforms)
java.lang.Exception
at
ca.mayet.backing.ClassListBean.finalMarkChanged(ClassListBean.java:188)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.apache.myfaces.el.MethodBindingImpl.invoke(MethodBindingImpl.java:132)
at
org.apache.myfaces.trinidad.component.UIXComponentBase.broadcastToMethodBinding(UIXComponentBase.java:1188)
at
org.apache.myfaces.trinidad.component.UIXEditableValue.broadcast(UIXEditableValue.java:213)
at javax.faces.component.UIData.broadcast(UIData.java:517)
at
javax.faces.component.UIViewRoot._broadcastForPhase(UIViewRoot.java:97)
at
javax.faces.component.UIViewRoot.processValidators(UIViewRoot.java:150)
at
org.apache.myfaces.lifecycle.ProcessValidationsExecutor.execute(ProcessValidationsExecutor.java:32)
at
org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:95)
at
org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:70)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:139)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:269)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)
at
Re: [Trinidad] new skin and new demo
Matthias Wessendorf wrote: cool, thanks! Definitely not cool... The performance at the irian site is terrible (it sucks at the best of times, but today it is atrocious). It makes both Trinidad and Irian look bad. If I didn't already know that Trinidad performance was fine, I'd be left with the impression that it was an unusable POS. Shane -M On Wed, Feb 3, 2010 at 8:23 AM, Bart Kummel wrote: Hi all, I just posted a short article about the new Cassablanca skin for Trinidad at my blog: http://www.bartkummel.net/journal/2010/2/2/new-skin-for-trinidad.html. Best regards, Bart Kummel On Sat, Jan 30, 2010 at 12:19, Matthias Wessendorf wrote: Hello, as FYI, the new skin (cassablanca) has been committed to trunk (1.2.14-SNAPSHOT). There will be a release for that in a few weeks. Thanks to our friends from Irian.at, for already hosting the new beautiful demo: http://example.irian.at/trinidad-components-showcase/ Check it out! Special thanks for the code-donation goes to Catalin and team from CodeBeat: http://www.codebeat.ro Enjoy the new skin, guys! -Matthias -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Shane
t:panelTabbed
Hello, I'm trying to upgrade an old JSF 1.1 app up to current standards. For the time being, I'd like to leave it as jsp based (upgrading pages to Facelets as changes come up). I've converted everything obvious, but Tomahawk tabs and menus are messed up. I'm currently using myfaces-core-2.1.3, tomahawk20-1.1.11, trinidad-2.0.0. Tabs in particular are annoying me, because even simple ones don't seem to work. They don't render as tabs at all (just discreet buttons) and they don't obey the serverSideTabSwitch (it's never client side, regardless of what the flag says). Any ideas? -- Shane
Re: t:panelTabbed
On 11/29/2011 11:18 PM, Leonardo Uribe wrote: Replace and tags with h:head and h:body will solve the problem. OK, another dumb question: where are h:head and h:body defined? The other h tags 'live' in myfaces-bundle-2.1.4.jar!META-INF/myfaces_html.tld, but there are no tags for head and body defined in there. The facelets tld docs mention them, but I'd like to keep as many jsp files around as I can (until I have a need to change their functionality, then they would be converted to facelets). At this point, all I'm trying to do is get the thing running under the new libs (haven't actually changed anything yet apart from ValueBindings -> ValueExpressions). -- Shane
PARTIAL_STATE_SAVING
So, I bit the bullet and converted my app over to facelets. Now I'm having problems with binding on a particular page, so I decided to try turning partial state saving off with: javax.faces.PARTIAL_STATE_SAVING false I can work with the login and start page, but anything after throws the NPE pasted below. What could I have messed up which causes full state saving to bomb? (myfaces-core-2.1.4, tomahawk20-1.1.11, trinidad-2.0.0 under JDK 1.6.0_29) Thx. Shane java.lang.NullPointerException at javax.faces.component.UIComponentBase.getRenderer(UIComponentBase.java:1201) at javax.faces.component.UIComponent$EventListenerWrapper.restoreState(UIComponent.java:1591) at javax.faces.component.UIComponentBase.restoreAttachedState(UIComponentBase.java:1776) at javax.faces.component._DeltaList.restoreState(_DeltaList.java:253) at javax.faces.component.UIComponentBase.restoreAttachedState(UIComponentBase.java:1776) at javax.faces.component.UIComponentBase.restoreFullSystemEventListenerClassMap(UIComponentBase.java:2058) at javax.faces.component.UIComponentBase.restoreState(UIComponentBase.java:1906) at javax.faces.component.UIComponentBase.processRestoreState(UIComponentBase.java:1496) at javax.faces.component.UIComponentBase.processRestoreState(UIComponentBase.java:1540) at javax.faces.component.UIComponentBase.processRestoreState(UIComponentBase.java:1540) at javax.faces.component.UIComponentBase.processRestoreState(UIComponentBase.java:1540) at javax.faces.component.UIComponentBase.processRestoreState(UIComponentBase.java:1540) at javax.faces.component.UIViewRoot.processRestoreState(UIViewRoot.java:765) at org.apache.myfaces.trinidadinternal.application.StateManagerImpl.restoreView(StateManagerImpl.java:701) at org.apache.myfaces.shared.view.ViewDeclarationLanguageBase.restoreView(ViewDeclarationLanguageBase.java:106) at org.apache.myfaces.view.facelets.FaceletViewDeclarationLanguage.restoreView(FaceletViewDeclarationLanguage.java:2037) at org.apache.myfaces.application.ViewHandlerImpl.restoreView(ViewHandlerImpl.java:300) at javax.faces.application.ViewHandlerWrapper.restoreView(ViewHandlerWrapper.java:83) at javax.faces.application.ViewHandlerWrapper.restoreView(ViewHandlerWrapper.java:83) at org.apache.myfaces.trinidadinternal.application.ViewHandlerImpl.restoreView(ViewHandlerImpl.java:242) at org.apache.myfaces.lifecycle.RestoreViewExecutor.execute(RestoreViewExecutor.java:127) at org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:170) at org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:117) at javax.faces.webapp.FacesServlet.service(FacesServlet.java:197) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:304) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) at org.apache.myfaces.webapp.filter.ExtensionsFilter.doFilter(ExtensionsFilter.java:357) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) at org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl._doFilterImpl(TrinidadFilterImpl.java:293) at org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl.doFilter(TrinidadFilterImpl.java:199) at org.apache.myfaces.trinidad.webapp.TrinidadFilter.doFilter(TrinidadFilter.java:92) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) at org.springframework.orm.hibernate3.support.OpenSessionInViewFilter.doFilterInternal(OpenSessionInViewFilter.java:198) at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:76) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:224) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:169) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:168) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:100) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:929) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:405) at org.apache.coyote.http11.AbstractHttp11Processor.process(Abs
Re: PARTIAL_STATE_SAVING
On 12/7/2011 9:50 AM, Matt Benson wrote: If you can possibly boil this down to a standalone example it would be much more likely that someone could determine what the problem is. Sure, but the process of converting from 1.1/JSP to 2.1/Facelets is large but fairly mundane: Value/MethodBinding -> Value/MethodException plus lots of syntactic changes on the UI and some config changes; it is necessarily a 'shotgun refactoring'. The pages in question currently work with partial state saving, so I'm having a hard time imagining how full state saving could be worse. I was just hoping someone else had done the same. The fact that this works for partial and fails for full suggests a config problem, because everything used to be full state saving. StateManagerImpl does not set the viewRoot on the FacesContext before calling #restoreState() on the viewRoot. The ViewRoot is set, the NPE comes from an instance of org.apache.myfaces.trinidadinternal.context.FacesContextFactoryImpl$CacheRenderKit#getRenderKit() returning null. This means that FacesContextImpl has a null renderkit at this moment too (CacheRenderKit sets: _kit = _base.getRenderKit() just before the NPE) Shane On Wed, Dec 7, 2011 at 12:30 AM, Shane Petroff wrote: So, I bit the bullet and converted my app over to facelets. Now I'm having problems with binding on a particular page, so I decided to try turning partial state saving off with: javax.faces.PARTIAL_STATE_SAVING false I can work with the login and start page, but anything after throws the NPE pasted below. What could I have messed up which causes full state saving to bomb? (myfaces-core-2.1.4, tomahawk20-1.1.11, trinidad-2.0.0 under JDK 1.6.0_29) Thx. Shane java.lang.NullPointerException at javax.faces.component.UIComponentBase.getRenderer(UIComponentBase.java:1201) at javax.faces.component.UIComponent$EventListenerWrapper.restoreState(UIComponent.java:1591) at javax.faces.component.UIComponentBase.restoreAttachedState(UIComponentBase.java:1776) at javax.faces.component._DeltaList.restoreState(_DeltaList.java:253) at javax.faces.component.UIComponentBase.restoreAttachedState(UIComponentBase.java:1776) at javax.faces.component.UIComponentBase.restoreFullSystemEventListenerClassMap(UIComponentBase.java:2058) at javax.faces.component.UIComponentBase.restoreState(UIComponentBase.java:1906) at javax.faces.component.UIComponentBase.processRestoreState(UIComponentBase.java:1496) at javax.faces.component.UIComponentBase.processRestoreState(UIComponentBase.java:1540) at javax.faces.component.UIComponentBase.processRestoreState(UIComponentBase.java:1540) at javax.faces.component.UIComponentBase.processRestoreState(UIComponentBase.java:1540) at javax.faces.component.UIComponentBase.processRestoreState(UIComponentBase.java:1540) at javax.faces.component.UIViewRoot.processRestoreState(UIViewRoot.java:765) at org.apache.myfaces.trinidadinternal.application.StateManagerImpl.restoreView(StateManagerImpl.java:701) at org.apache.myfaces.shared.view.ViewDeclarationLanguageBase.restoreView(ViewDeclarationLanguageBase.java:106) at org.apache.myfaces.view.facelets.FaceletViewDeclarationLanguage.restoreView(FaceletViewDeclarationLanguage.java:2037) at org.apache.myfaces.application.ViewHandlerImpl.restoreView(ViewHandlerImpl.java:300) at javax.faces.application.ViewHandlerWrapper.restoreView(ViewHandlerWrapper.java:83) at javax.faces.application.ViewHandlerWrapper.restoreView(ViewHandlerWrapper.java:83) at org.apache.myfaces.trinidadinternal.application.ViewHandlerImpl.restoreView(ViewHandlerImpl.java:242) at org.apache.myfaces.lifecycle.RestoreViewExecutor.execute(RestoreViewExecutor.java:127) at org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:170) at org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:117) at javax.faces.webapp.FacesServlet.service(FacesServlet.java:197) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:304) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) at org.apache.myfaces.webapp.filter.ExtensionsFilter.doFilter(ExtensionsFilter.java:357) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) at org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl._doFilterImpl(TrinidadFilterImpl.java:293) at org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl.doFilter(TrinidadFilterImpl.java:199) at org.apache.myfaces.trinidad.webapp.TrinidadFilter.doFilter(TrinidadFilter.java:92) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243) at org.apache.catalina.core.Applicat
tr:showDetail
Is there any way to make tr:showDetail components function under myfaces core 2.1 other than using: org.apache.myfaces.trinidadinternal.PPR_OVER_JSF_AJAX off ? -- Shane
[Trinidad] Server Exception during PPR
I'm trying to test out the Trinidad dialog framework (which seems quite
simple to work with from the documentation).
What does the "Server Exception during PPR" and associated js alert mean?
The stack trace below suggests that the PPR request cannot handle
calling a particular action listener. The bean is defined in request
scope with the appropriate name, the method with the correct signature
is there. Both of these values are unchanged during the port to Trinidad
so I can guarantee that there is no naming issues. but there is no
indication of what is actually going wrong. I can pretty much be sure
that it is a 'lookup' issue of sorts since the actual method which is
supposed to be called does nothing but return a string literal (it never
actually gets called though).
Feb 29, 2008 4:12:16 PM
org.apache.myfaces.trinidadinternal.config.xmlHttp.XmlHttpConfigurator
handleError
SEVERE: Server Exception during PPR, #1
javax.servlet.ServletException: Exception while invoking expression
#{reportCardBean.onOpenCommentLibrary}
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:154)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:269)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)
at
org.apache.myfaces.webapp.filter.ExtensionsFilter.doFilter(ExtensionsFilter.java:144)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:215)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)
at
org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl._invokeDoFilter(TrinidadFilterImpl.java:253)
at
org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl._doFilterImpl(TrinidadFilterImpl.java:210)
at
org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl.doFilter(TrinidadFilterImpl.java:164)
at
org.apache.myfaces.trinidad.webapp.TrinidadFilter.doFilter(TrinidadFilter.java:92)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:215)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)
at
org.springframework.orm.hibernate3.support.OpenSessionInViewFilter.doFilterInternal(OpenSessionInViewFilter.java:173)
at
org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:77)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:215)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)
at
ca.mayet.SessionTimeoutRedirectFilter.doFilter(SessionTimeoutRedirectFilter.java:78)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:215)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:210)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:174)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:117)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:108)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:151)
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:870)
at
org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:665)
at
org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:528)
at
org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:81)
at
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:685)
at java.lang.Thread.run(Thread.java:619)
--
Shane
[Trinidad] Rendering Context
Hello, I have what seems to be a configuration problem. It doesn't seem to affect much (although it isn't the only issue I have at the moment, so I'm not sure), but it is unnerving to see in the trace. Mar 4, 2008 4:52:58 PM org.apache.myfaces.trinidad.context.RenderingContext attach WARNING: Trying to attach RenderingContext to a thread that already had one. Mar 4, 2008 4:53:01 PM org.apache.myfaces.trinidadinternal.context.RequestContextImpl _createChangeManager INFO: Apache Trinidad is using HTTPSession for change persistence Mar 4, 2008 4:53:02 PM org.apache.myfaces.trinidadinternal.renderkit.core.CoreRenderKit encodeFinally WARNING: No RenderingContext available Mar 4, 2008 4:53:02 PM org.apache.myfaces.trinidad.context.RenderingContext attach WARNING: Trying to attach RenderingContext to a thread that already had one. Mar 4, 2008 4:53:02 PM org.apache.myfaces.trinidadinternal.renderkit.core.CoreRenderKit encodeFinally WARNING: No RenderingContext available The RenderingContext warnings appear in every page, regardless of whether or not I have any Trinidad components. The obvious faces-config setting is correct (I've tried trinidadinternal as well) org.apache.myfaces.trinidad.core web.xml is configured as org.apache.myfaces.trinidad.CACHE_VIEW_ROOT false org.apache.myfaces.trinidad.USE_APPLICATION_VIEW_CACHE false org.apache.myfaces.trinidad.CHECK_FILE_MODIFICATION true org.apache.myfaces.trinidad.CHANGE_PERSISTENCE session javax.faces.DEFAULT_SUFFIX .jsp org.apache.myfaces.trinidad.ENABLE_LIGHTWEIGHT_DIALOGS true Obviously, the filter, servlet and mappings are set up too. This app is being 'ported' from tomahawk to trinidad (I'm dropping tomahawk in favour of trinidad). To that end, the changes to jsp pages have been minimal apart from converting to tr:document and tr:form (which means that I do have trinidad components on every page, but I had the same warnings before converting on pages which did not yet use any trinidad components). The few trinidad components that I've tried do seem to work, I'd just like to get a handle on what the warnings mean before trying to figure out my other issues. Thanks. -- Shane
Re: [Trinidad] Rendering Context
Henry Eduardo Iguaro wrote: I also had this problem before, Ugh... IDE's can make things too easy. Apparently I hadn't done a real 'clean' since downloading the latest trinidad jars. I had both the 1.0.5 and 1.0.6 jars under my target dir. Given how easy it is to invoke an ant task from within the IDE, this is pretty embarrassing... -- Shane
Re: [Trinidad] Server Exception during PPR
OK, back to my real problem...
I can't seem to use PPR in cases where I modify the component tree at
runtime. I want to use a simple dialog. Eventually, the components which
launch and handle data 'returned' from the dialog will need to be
created via java code. My first attempt resulted in the indecipherable
results below. I figured that I ought to try to use a standard
declarative version first before moving back to the code, so I followed
the dev guide placed my fields declaratively on this dynamic jsp page
and things worked somewhat better. I was able to open the dialog, but
the PPR was still borked. The ReturnEvent was still raised/heard, but
nothing was refreshed. From there I copied/pasted the jsp code into a
more static page, and everything worked fine, the dialog opens and the
appropriate fields is refreshed. What is it about modifying the
component tree at runtime which causes PPR to fail? Firebug reports no
js errors, but the second post call seems to have failed. It is
annotated with a red X, and the response never finishes 'loading...' By
contrast, on the 'static' page, the second post completes as normal
right after the return event. After that, I'll try to figure out why
building the same thing in java code fails in a different way.
JSP Code:
value="#{reportCardBean.studentComment}"
partialTriggers="buttonId"/>
action="#{reportCardBean.onOpenCommentLibrary}"
id="buttonId"
windowWidth="500" windowHeight="500"
partialSubmit="true" useWindow="true"
returnListener="#{reportCardBean.returnedFromCommentLib}"/>
Thanks
Shane
Shane Petroff wrote:
I'm trying to test out the Trinidad dialog framework (which seems
quite simple to work with from the documentation).
What does the "Server Exception during PPR" and associated js alert mean?
The stack trace below suggests that the PPR request cannot handle
calling a particular action listener. The bean is defined in request
scope with the appropriate name, the method with the correct signature
is there. Both of these values are unchanged during the port to
Trinidad so I can guarantee that there is no naming issues. but there
is no indication of what is actually going wrong. I can pretty much be
sure that it is a 'lookup' issue of sorts since the actual method
which is supposed to be called does nothing but return a string
literal (it never actually gets called though).
Feb 29, 2008 4:12:16 PM
org.apache.myfaces.trinidadinternal.config.xmlHttp.XmlHttpConfigurator
handleError
SEVERE: Server Exception during PPR, #1
javax.servlet.ServletException: Exception while invoking expression
#{reportCardBean.onOpenCommentLibrary}
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:154)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:269)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)
at
org.apache.myfaces.webapp.filter.ExtensionsFilter.doFilter(ExtensionsFilter.java:144)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:215)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)
at
org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl._invokeDoFilter(TrinidadFilterImpl.java:253)
at
org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl._doFilterImpl(TrinidadFilterImpl.java:210)
at
org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl.doFilter(TrinidadFilterImpl.java:164)
at
org.apache.myfaces.trinidad.webapp.TrinidadFilter.doFilter(TrinidadFilter.java:92)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:215)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)
at
org.springframework.orm.hibernate3.support.OpenSessionInViewFilter.doFilterInternal(OpenSessionInViewFilter.java:173)
at
org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:77)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:215)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)
at
ca.mayet.SessionTimeoutRedirectFilter.doFilter(SessionTimeoutRedirectFilter.java:78)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:215)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)
at
org.apache.catalina.cor
[Trinidad] Difference between these 2
Can anyone tell me what the functional difference between these two
snippets is (besides the fact that the java code version doesn't work)
returnListener="#{helloWorldBacking.returnedFromPage2}"/>
and
private void addContent()
{
Application app =
FacesContext.getCurrentInstance().getApplication();
CoreInputText txt = (CoreInputText) app.createComponent(
CoreInputText.COMPONENT_TYPE );
txt.setLabel( "test dynamic" );
txt.setId( "txtID" );
txt.setValueBinding("value",
app.createValueBinding("#{helloWorldBacking.sessionText}"));
txt.setPartialTriggers( new String[] { "btnID" } );
m_MainPanel.getChildren().add(txt);
CoreCommandButton btn = (CoreCommandButton) app.createComponent(
CoreCommandButton.COMPONENT_TYPE );
btn.setText("lib");
btn.setId( "btnID" );
btn.setActionListener(app.createMethodBinding("#{helloWorldBacking.onOpenPage2}",
null )); // an empty array doesn't work either
btn.setImmediate(true);
btn.setPartialSubmit(true);
btn.setUseWindow(true);
btn.setWindowWidth(600);
btn.setWindowHeight(300);
btn.setReturnListener(app.createMethodBinding("#{helloWorldBacking.returnedFromPage2}",
new Class[] {
ReturnEvent.class }));
m_MainPanel.getChildren().add(btn);
}
The relevant backing bean methods are:
public String onOpenPage2()
{
return "dialog:openPage2";
}
public String getOnOpenPage2() // maybe this???
{
return onOpenPage2();
}
public void returnedFromPage2( ReturnEvent event)
{
if (event.getReturnValue() != null)
{
Object[] array = (Object[]) event.getReturnValue();
System.out.println( "returned value " + array[0] );
setSessionText(array[0].toString());
}
}
The jspx version works fine, but the java version throws the exception
below, which seems to suggest that onOpenPage2 should have more than the
zero arguments which it is defined with.
Mar 11, 2008 3:16:41 AM
org.apache.myfaces.trinidadinternal.config.xmlHttp.XmlHttpConfigurator
handleError
SEVERE: Server Exception during PPR, #1
javax.servlet.ServletException: Exception while invoking expression
#{helloWorldBacking.onOpenPage2}
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:154)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl._invokeDoFilter(TrinidadFilterImpl.java:250)
at
org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl._doFilterImpl(TrinidadFilterImpl.java:207)
at
org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl.doFilter(TrinidadFilterImpl.java:161)
at
org.apache.myfaces.trinidad.webapp.TrinidadFilter.doFilter(TrinidadFilter.java:92)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:263)
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:584)
at
org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
at java.lang.Thread.run(Thread.java:619)
Caused by: javax.faces.el.EvaluationException: Exception while invoking
expression #{helloWorldBacking.onOpenPage2}
at
org.apache.myfaces.el.MethodBindingImpl.invoke(MethodBindingImpl.java:168)
at
org.apache.myfaces.trinidad.component.UIXComponentBase.broadcastToMethodBinding(UIXComponentBase.java:1188)
at
org.apache.myfaces.trinidad.component.UIXCommand.broadcast(UIXCommand.java:147)
at
javax.faces.component.UIViewRoot._broadcastForPhase(UIViewRoot.java:97)
at javax.faces.component.UIViewRoot.processDecodes(UIViewRoot.java:139)
at
org.apache.myfaces.lifecycle.ApplyRequestValuesExecutor.execute(ApplyRequestValuesExecutor.java:32)
at
org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:95)
at
org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:70)
at javax.faces.webapp.FacesServlet.se
Re: [Trinidad] Difference between these 2
Abhijit Ghosh wrote:
Please try setAction()
Thanks, talk about obvious...
OK, then the real reason for this is to figure out the PPR side. The
normal declarative version works fine, but the programmatic one does
not. To get to this state, I used the maven create archetype posted here
a while back
(http://wiki.apache.org/myfaces/MyFaces_Archetypes_for_Maven) to
generate a hello world app. I dropped back the version numbers for JSF
1.1 (tr v 1.0.6), then deployed to Tomcat 6.0.14. The return events are
'heard', but the PPR refresh never succeeds. The files below contain the
respective changes to the hello world app. There are no errors either on
the server or js, but the refresh never happens. I'm trying to decipher
the posts associated with the PPR activity, but I'm not sure how to
interpret them. Any help appreciated, thanks.
Shane
HelloWorldBacking.java**
package org.apache.myfaces.trinidad.blank;
import org.apache.myfaces.trinidad.context.RequestContext;
import org.apache.myfaces.trinidad.event.ReturnEvent;
import org.apache.myfaces.trinidad.component.core.input.CoreInputText;
import org.apache.myfaces.trinidad.component.core.nav.CoreCommandButton;
import javax.faces.component.html.HtmlSelectManyListbox;
import javax.faces.component.html.HtmlPanelGrid;
import javax.faces.model.SelectItem;
import javax.faces.context.FacesContext;
import javax.faces.application.Application;
import java.util.List;
import java.util.ArrayList;
public class HelloWorldBacking
{
private HtmlSelectManyListbox m_CommentList;
public HelloWorldBacking()
{
}
public HtmlSelectManyListbox getCommentList()
{
return m_CommentList;
}
public void setCommentList(HtmlSelectManyListbox commentList )
{
m_CommentList = commentList;
}
public String cancelCommentLibrary()
{
RequestContext.getCurrentInstance().returnFromDialog(null, null);
return null;
}
public String insertFromCommentLibrary()
{
Object returnValue = m_CommentList.getSelectedValues();
RequestContext.getCurrentInstance().returnFromDialog(returnValue, null);
return null;
}
public List getComments()
{
List comments = new ArrayList();
comments.add(new SelectItem("This is a comment"));
comments.add(new SelectItem("qwerty"));
comments.add(new SelectItem("The quick brown fox jumped over the
lazy sleeping dog"));
return comments;
}
///
public String getSessionText()
{
FacesContext context = FacesContext.getCurrentInstance();
return (String)
context.getExternalContext().getSessionMap().get("testText");
}
public void setSessionText(final String s)
{
FacesContext context = FacesContext.getCurrentInstance();
context.getExternalContext().getSessionMap().put("testText", s);
}
public String onOpenPage2()
{
return "dialog:openPage2";
}
public void returnedFromPage2( ReturnEvent event)
{
if (event.getReturnValue() != null)
{
Object[] array = (Object[]) event.getReturnValue();
System.out.println( "returned value " + array[0] );
setSessionText(array[0].toString());
}
}
///
private HtmlPanelGrid m_MainPanel;
public HtmlPanelGrid getMainPanel()
{
return m_MainPanel;
}
public void setMainPanel(HtmlPanelGrid panel)
{
this.m_MainPanel = panel;
m_MainPanel.setBorder(2);
addContent();
}
private void addContent()
{
Application app =
FacesContext.getCurrentInstance().getApplication();
CoreInputText txt = (CoreInputText) app.createComponent(
CoreInputText.COMPONENT_TYPE );
txt.setLabel( "test dynamic" );
txt.setId( "txtID" );
txt.setValueBinding("value",
app.createValueBinding("#{helloWorldBacking.sessionText}"));
txt.setPartialTriggers( new String[] { "btnID" } );
m_MainPanel.getChildren().add(txt);
CoreCommandButton btn = (CoreCommandButton) app.createComponent(
CoreCommandButton.COMPONENT_TYPE );
btn.setText("this does not");
btn.setId( "btnID" );
btn.setAction(app.createMethodBinding("#{helloWorldBacking.onOpenPage2}",
null ));
btn.setImmediate(true);
btn.setPartialSubmit(true);
btn.setUseWindow(true);
btn.setWindowWidth(600);
btn.setWindowHeight(300);
btn.setReturnListener(app.createMethodBinding("#{helloWorldBacking.returnedFromPage2}",
new Class[] {
ReturnEvent.class }));
m_MainPanel.getChildren().add(btn);
}
}
index.jspx**
http://java.sun.com/JSP/Page"; version="2.0"
xmlns:f="http://java.sun.com/jsf/core";
xmlns:h="http://java.sun.com/jsf/html";
xmlns:tr=
DebugResponseWriter _logDuplicateId and HtmlPanelTab
Hello all,
I have an annoying problem with Trinidad and 'duplicate' ids. It doesn't
seem to affect functionality, but if released into production, it would
end up generating boatloads of useless log entries. Alternatively, it
seems rather self defeating to try and add custom log settings to
selectively ignore these warnings.
I'm converting an application away from Tomahawk and into Trinidad and I
get repeated warnings of the form:
Mar 28, 2008 2:54:27 PM
org.apache.myfaces.trinidadinternal.io.DebugResponseWriter _logDuplicateId
WARNING: The id "mainForm:_myt379" is used more than once.
Most of the components on this page are created programmatically, so it
was easy to dump out details allowing me to correlate the id's in
question with component types. Based on a bit of Googling, I expected to
find that they related to labels or message components, but instead
found that they all related to org.apache.myfaces.HtmlPanelTab instances.
Is there something about how HtmlPanelTab instances are created that
differs from other components? Any idea what I have to do to get rid of
all the warnings?
The code which creates these components is very simple:
public static HtmlPanelTab createTab(final String tabText)
{
HtmlPanelTab tab = (HtmlPanelTab)
createComponent(HtmlPanelTab.COMPONENT_TYPE);
tab.setStyle("width=100%;");
tab.setStyleClass("panel");
tab.setLabel(tabText);
return tab;
}
private static UIComponent createComponent(String componentType)
{
Application app =
FacesContext.getCurrentInstance().getApplication();
UIComponent comp = app.createComponent(componentType);
comp.setId( generateId() ); // ensure that every component has
some id specified
System.out.println( "created " + componentType + ". ID: " +
comp.getId() );
return comp;
}
private static int s_Id = 0;
public synchronized static String generateId()
{
if ( s_Id == (Integer.MAX_VALUE-1) )
s_Id = 0; // presumably at this point it's OK to start over
s_Id++;
StringBuffer b = new StringBuffer("_myt");
b.append(String.valueOf(s_Id));
return b.toString();
}
The resulting trace from the sysout above and the error console when
viewing the page is:
created org.apache.myfaces.HtmlPanelTab. ID: _myt379
...
Mar 28, 2008 2:54:27 PM
org.apache.myfaces.trinidadinternal.io.DebugResponseWriter _logDuplicateId
WARNING: The id "mainForm:_myt379" is used more than once.
Any ideas appreciated. Thanks
--
Shane
[Trinidad] Caret position
Hello, How can I get the current caret position from a tr:inputText component over to some server side code? I have an action which is used to open a dialog, and at that point I want to grab the current caret position for use in the dialog's return listener. Googling 'java Trinidad "caret position"' turns up virtually nothing, and searching for the erroneous label 'cursor' naturally turns up boatloads of pages related to the proper use of the word. -- Shane
[Trinidad] Scrollable TreeTable
Hello, It was relatively easy to use a tr:panelBorderLayout 'wrapper' to get a scrollable tr:treeTable, but the result is not particularly satisfying. This approach allows column headings to scroll out of view, which is something I'd rather avoid. Is it possible to have the component itself handle scrolling? Alternatively, how can I arrange a layout which can keep my own outputText components (and linework ugh...) aligned with the treeTable columns (I'm assuming that if I don't define headers for the columns that they will be unadorned). Any possibilities for resizeable columns? -- Shane
[Trinidad] tr:selectManyListbox doesn't render on IE
Hello,
I have a relatively simple page which behaves fine under Firefox, but
oddly under IE. In IE the tr:selectManyListbox is not rendered until
after the first ajax request. But the ajax request has nothing to do
with the tr:selectManyListbox. The page below is opened in a light
weight dialog, and I'm using Trinidad 1.0.7, Tomahawk 1.1.5 and MyFaces
core 1.1.5. What could be causing it to behave in this manner?
Also, how do I get rid of the hideous rollovers on tree nodes in IE?
I've defined my own skin so that I can place icons with nodes, but I
haven't changed anything else.
<%@ page contentType="text/html;charset=UTF-8"%>
<%@ page 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" %>
<%@ taglib uri="http://myfaces.apache.org/trinidad"; prefix="tr" %>
styleClass="textField"/>
binding="#{commentLibraryBean.schoolCommentList}"
contentStyle="width:100%"
styleClass="listBox">
maximum="#{commentLibraryBean.maxCommentLength}"/>
styleClass="textField"/>
inlineStyle="height:180px; overflow:auto;
position:relative;" >
actionListener="#{commentLibraryBean.selectComment}"
text="#{node.desc}"
shortDesc="#{node.commentId}"
partialSubmit="true">
maximum="#{commentLibraryBean.maxCommentLength}"/>
action="#{commentLibraryBean.insertFromCommentLibrary}"
value="#{bundle.CommentLibraryInsertButtonText}" styleClass="button"/>
action="#{commentLibraryBean.cancelCommentLibrary}"
value="#{bundle.Cancel}" immediate="true"
styleClass="button"/>
maximum="#{commentLibraryBean.maxInt}"/>
--
Shane
Re: [Trinidad] tr:selectManyListbox doesn't render on IE
Mathias Walter wrote:
it sound's related to https://issues.apache.org/jira/browse/TRINIDAD-1071.
I'll investigate the problem this week and may provide a patch.
That sounds great, thanks.
Any takers on the rollover thing?
The default skin does not seem to have any rollover effects on IE
(assuming that this is what's used for the demo at irian). Yet my custom
skin merely extends the default
simple.desktop
and only overrides node-icon properties for tree and treeTable:
af|tree::node-icon:folder-expanded{...
af|tree::node-icon:folder-collapsed{...
af|tree::node-icon:document{...
Where the heck are these properties coming from, and why only on IE?
Shane
--
Kind regards,
Mathias
-Original Message-----
From: Shane Petroff [mailto:[EMAIL PROTECTED]
Sent: Tuesday, May 13, 2008 10:47 PM
To: MyFaces Discussion
Subject: [Trinidad] tr:selectManyListbox doesn't render on IE
Hello,
I have a relatively simple page which behaves fine under Firefox, but
oddly under IE. In IE the tr:selectManyListbox is not rendered until
after the first ajax request. But the ajax request has nothing to do
with the tr:selectManyListbox. The page below is opened in a light
weight dialog, and I'm using Trinidad 1.0.7, Tomahawk 1.1.5
and MyFaces
core 1.1.5. What could be causing it to behave in this manner?
Also, how do I get rid of the hideous rollovers on tree nodes in IE?
I've defined my own skin so that I can place icons with nodes, but I
haven't changed anything else.
<%@ page contentType="text/html;charset=UTF-8"%>
<%@ page 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" %>
<%@ taglib uri="http://myfaces.apache.org/trinidad"; prefix="tr" %>
value="#{commentLibraryBean.sectionId}"/>
styleClass="textField"/>
binding="#{commentLibraryBean.schoolCommentList}"
contentStyle="width:100%"
styleClass="listBox">
value="#{commentLibraryBean.schoolComments}"/>
maximum="#{commentLibraryBean.maxCommentLength}"/>
styleClass="textField"/>
inlineStyle="height:180px;
overflow:auto;
position:relative;" >
actionListener="#{commentLibraryBean.selectComment}"
text="#{node.desc}"
shortDesc="#{node.commentId}"
partialSubmit="true">
value="#{commentLibraryBean.selectedComment.comment}"
id="commentTextField"
contentStyle="width:100%"
disabled="true"
rows="3">
maximum="#{commentLibraryBean.maxCommentLength}"/>
action="#{commentLibraryBean.insertFromCommentLibrary}"
value="#{bundle.CommentLibraryInsertButtonText}" styleClass="button"/>
action="#{commentLibraryBean.cancelCommentLibrary}"
value="#{bundle.Cancel}"
immediate="true"
styleClass="button"/>
binding="#{commentLibraryBean.hiddenCommentIdField}">
maximum="#{commentLibraryBean.maxInt}"/>
--
Shane
--
Shane
[Trinidad] CoreShowDetail
I can't seem to get a CoreShowDetail instance to work. I have an existing/functional page, which is build primarily in Java code, and I wanted to add hide/show to a particular panel. It appears as though the CoreShowDetail class is easily used CoreShowDetail detail = (CoreShowDetail) createComponent( CoreShowDetail.COMPONENT_TYPE ); detail.setDisclosed( true ); detail.getChildren().add(panel); yet the results don't work. The Component is rendered, but doesn't function. No errors (either client or server), just a dead link. It appears to be trying to do some ppr work: _submitHideShow and eventually TrPage.prototype.sendPartialFormPost are called. Any ideas on how I can tell what is going wrong? (trinidad 1.0.7) -- Shane
Re: [Trinidad] CoreShowDetail
Frank Nimphius wrote: not sure what the panel is doing, but I suggest to add a component that can take a focus (e.g. a text field) for a test OK, one of the panels didn't have any focusable components in it, so I've stuck in an HtmlTextField at the top of each panel which is a child of a CoreShowDetail (because there are conditions in which everything will be disabled), but it has had no effect. I presume that you are referring to the call to _setRequestedFocusNode, which does get called and seems to set appropriate values: a3 is set to the window; a3._TrFocusRequestDoc points to the document instance a3._TrFocusRequestID is set to the correct id, and a3._TrFocusRequestNext is set to false because a2=false. Stepping through submitPartialChange doesn't reveal anything odd either, ex.) addFormParameter => event=hide source=the_id_of_the_enclosing_span partial=true. _pprStartBlocking didn't mean much to me. submitForm returns true. To the uninitiated, everything seems fine, but nothing ever gets refreshed. Do I need to add something as a partial target? -- Shane Frank Shane Petroff wrote: I can't seem to get a CoreShowDetail instance to work. I have an existing/functional page, which is build primarily in Java code, and I wanted to add hide/show to a particular panel. It appears as though the CoreShowDetail class is easily used CoreShowDetail detail = (CoreShowDetail) createComponent( CoreShowDetail.COMPONENT_TYPE ); detail.setDisclosed( true ); detail.getChildren().add(panel); yet the results don't work. The Component is rendered, but doesn't function. No errors (either client or server), just a dead link. It appears to be trying to do some ppr work: _submitHideShow and eventually TrPage.prototype.sendPartialFormPost are called. Any ideas on how I can tell what is going wrong? (trinidad 1.0.7) -- Frank Nimphius | Principal Product Manager Oracle Application Development Tools Oracle is committed to developing practices and products that help protect the environment -- Shane
Re: [Trinidad] CoreShowDetail
Back to this issue after a small hiatus. Can someone give me an idea of what is supposed to happen? I tried registering a disclosure listener on the CoreShowDetail instance, but the event is never raised, suggesting that things are dieing earlier. I've stepped through a bunch of _javascript_, but nothing looks obviously wrong. Shane Shane Petroff wrote: Frank Nimphius wrote: not sure what the panel is doing, but I suggest to add a component that can take a focus (e.g. a text field) for a test OK, one of the panels didn't have any focusable components in it, so I've stuck in an HtmlTextField at the top of each panel which is a child of a CoreShowDetail (because there are conditions in which everything will be disabled), but it has had no effect. I presume that you are referring to the call to _setRequestedFocusNode, which does get called and seems to set appropriate values: a3 is set to the window; a3._TrFocusRequestDoc points to the document instance a3._TrFocusRequestID is set to the correct id, and a3._TrFocusRequestNext is set to false because a2=false. Stepping through submitPartialChange doesn't reveal anything odd either, ex.) addFormParameter => event=hide source=the_id_of_the_enclosing_span partial=true. _pprStartBlocking didn't mean much to me. submitForm returns true. To the uninitiated, everything seems fine, but nothing ever gets refreshed. Do I need to add something as a partial target? -- Shane Frank Shane Petroff wrote: I can't seem to get a CoreShowDetail instance to work. I have an existing/functional page, which is build primarily in Java code, and I wanted to add hide/show to a particular panel. It appears as though the CoreShowDetail class is easily used CoreShowDetail detail = (CoreShowDetail) createComponent( CoreShowDetail.COMPONENT_TYPE ); detail.setDisclosed( true ); detail.getChildren().add(panel); yet the results don't work. The Component is rendered, but doesn't function. No errors (either client or server), just a dead link. It appears to be trying to do some ppr work: _submitHideShow and eventually TrPage.prototype.sendPartialFormPost are called. Any ideas on how I can tell what is going wrong? (trinidad 1.0.7) -- Frank Nimphius | Principal Product Manager Oracle Application Development Tools Oracle is committed to developing practices and products that help protect the environment -- Shane -- Shane
Re: How to set a component value to an EL Expression in Java?
Paul Spencer wrote:
I need to dynamically add a child component inside a bean. I have
access to the component via a binding and have successfully added the
child component. What I have not been able to do is set the value of
the child component to an EL Expresion so it is resolve by JSF 1.2.
The equivalent tag for the child component is:
So far I have:
CoreInputText childComponent;
childComponent = (CoreInputText)
application.createComponent(CoreInputText.COMPONENT_TYPE);
// Set the value to an EL Expression
childComponent.setValue("#{foo.bar}"); // Does not work
ValueBinding vb = application.createValueBinding(elExpression);
vb.setValue(context, value);
Will work, but iirc, this is deprecated, and there is an alternate for
1.2, namely ValueExpression
Shane
--
Shane
