Re: [VOTE] Release of Trinidad 1.2.10
+1 On Thu, Nov 13, 2008 at 7:06 PM, Grant Smith [EMAIL PROTECTED] wrote: +1 On Thu, Nov 13, 2008 at 6:28 AM, Gerhard Petracek [EMAIL PROTECTED] wrote: hello paul, the jira link is [1] e.g. [2] regards, gerhard [1] http://issues.apache.org/jira/secure/ConfigureReleaseNote.jspa?projectId=12310661 [2] http://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12313342styleName=HtmlprojectId=12310661Create=Create 2008/11/13 Matthias Wessendorf [EMAIL PROTECTED] On Thu, Nov 13, 2008 at 3:12 PM, Paul Spencer [EMAIL PROTECTED] wrote: Where can I find the proposed release notes? usually all these myfaces projects provide that after a release. You can do a jira search on your own -M BTW: I will not be able to look at the artifacts until this evening, Eastern Standard Time, at the earliest. Paul Spencer Matthias Wessendorf wrote: Hi, I was running the needed tasks to get the 1.2.10 release of the Apache MyFaces Trinidad CORE out. The artifacts are deployed to my private Apache account ([1]). Please take a look at the 1.2.10 artifacts and vote [ ] +1 for community members who have reviewed the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released, and why.. Thanks, Matthias [1] http://people.apache.org/~matzew/trinidad1210/ -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- Grant Smith
Re: tomahawk examples design proposal
On Fri, Oct 10, 2008 at 12:52 PM, Cristi Toth [EMAIL PROTECTED] wrote: Hi Thomas, Actually the colors seem a bit washed-out... Wasn't the plan to have Tomahawk examples use MyFaces theme? In my opinion, the examples design and the myfaces theme fit together very well. From what I remember, Adonis provided logos for all MyFaces sub-projects, which were voted, but never made it (why !?!?) in the actual sites... ok, adonis can you send the logo template to Enrico? Cristi Toth - Codebeat www.codebeat.ro On Fri, Oct 10, 2008 at 12:43 PM, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi! +1 to number one. Ciao, Mario
[jira] Created: (MYFACES-1958) Implement AfterAddToParentEvent
Implement AfterAddToParentEvent --- Key: MYFACES-1958 URL: https://issues.apache.org/jira/browse/MYFACES-1958 Project: MyFaces Core Issue Type: Task Components: JSR-314 Affects Versions: 2.0.0-alpha Reporter: Thomas Spiegl -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-1959) Add missing javax.faces.event Classes Interfaces
Add missing javax.faces.event Classes Interfaces -- Key: MYFACES-1959 URL: https://issues.apache.org/jira/browse/MYFACES-1959 Project: MyFaces Core Issue Type: Task Components: JSR-314 Affects Versions: 2.0.0-alpha Reporter: Thomas Spiegl Assignee: Thomas Spiegl -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [jira] Updated: (TRINIDAD-873) JavaScriptError in Core.js _formatErrorString
no objections here.
Regards,
Thomas
On Tue, Apr 8, 2008 at 10:44 PM, Gabrielle Crawford
[EMAIL PROTECTED] wrote:
Hi people,
I will be committing this patch tomorrow unless there are objections.
Thanks,
Gabrielle
Yee-wah Lee wrote:
Hi all,
I would like to modify the code slightly from this patch. Basically, move
the check for typeof down, so that it only affects the code which does
String.replace(). For details, see TRINIDAD-1036.
I didn't see a test scenario for TRINIDAD-873, so if anyone familiar with
the above can i) email me their test case or ii) verify the proposed
changes, please let me know.
Thanks,
Yee-Wah
Original:
function _formatErrorString()
{
..
for (var currToken in tokens)
{
var currValue = tokens[currToken];
// if the token has no value, replace it with the empty string
if (!currValue)
{
currValue = ;
}
// TRINIDAD-829:
// we replace '{' and '}' to ensure, that tokens containing values
// like {3} aren't parsed more than once...
currValue = currValue.replace({,{');
currValue = currValue.replace(},'});
}
-
With TRINIDAD-873 patch:
function _formatErrorString( )
{
..
for (var currToken in tokens)
{
var currValue = tokens[currToken];
+// if the token has no value
+// or !typeof string, replace it with the empty string (see
TRINIDAD-873)
+if (!currValue || !(typeof currValue == string))
{
currValue = ;
}
// TRINIDAD-829:
// we replace '{' and '}' to ensure, that tokens containing values
// like {3} aren't parsed more than once...
currValue = currValue.replace({,{');
currValue = currValue.replace(},'});
}
-
With TRINIDAD-1036 patch:
function _formatErrorString( )
{
..
for (var currToken in tokens)
{
var currValue = tokens[currToken];
// if the token has no value
+if (!currValue)
{
currValue = ;
}
// TRINIDAD-829:
// we replace '{' and '}' to ensure, that tokens containing values
// like {3} aren't parsed more than once...
+// Only do this if it is typeof string (see TRINIDAD-873)
+if (typeof currValue == string)
+{
currValue = currValue.replace({,{');
currValue = currValue.replace(},'});
+}
Matthias Weßendorf (JIRA) wrote:
[
https://issues.apache.org/jira/browse/TRINIDAD-873?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matthias Weßendorf updated TRINIDAD-873:
Resolution: Fixed
Fix Version/s: 1.2.5-core
1.0.5-core
Status: Resolved (was: Patch Available)
applied the patch to both trunks;
JavaScriptError in Core.js _formatErrorString
-
Key: TRINIDAD-873
URL: https://issues.apache.org/jira/browse/TRINIDAD-873
Project: MyFaces Trinidad
Issue Type: Bug
Affects Versions: 1.0.5-core
Reporter: Thomas Spiegl
Assignee: Matthias Weßendorf
Fix For: 1.0.5-core, 1.2.5-core
Attachments: Core.js.patch
currValue in defined in function _formatErrorString line 2807 may be a
function (eg. removeDuplicates)
currValue.replace will then cause a JavaScript error
adding a typeof fixes the problem
// if the token has no value or !typeof string, replace it with the
empty string
if (!currValue || !(typeof currValue == string))
{
currValue = ;
}
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
Re: [proposal] jsf validation with annotations
I think it's a good idea to add sev-en as an orchestra subproject. Would be nice to have a common place for documentation, common release plans release numbers. regards, Thomas On Wed, Apr 9, 2008 at 11:14 AM, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi! my position on this is we could make sev-en part of orchestra, if the orchestra crew really, really wants it. If not, this should just be a separate sub-module in MyFaces. It is interesting enough to stand on its own. First, Orchestra is part of the MyFaces community, so it really, really should be a decision the MyFaces community felt, and not a Orchestra Team only one. Anyway, I think this is a question on how we position Orchestra. If it is a strong position against JBoss Seam, then it probably might make sense to include everything which makes life easier for the developer into Orchestra - just as Seam tries to do. However, then we loose one of the strongest arguments pro Orchestra: Being a lightweight Conversation-Centric Library. If, we could add it as sub-module to Orchestra, but I think the best place for sev-en (would like to see a new name anyway) is to be a submodule of MyFaces. But first I'd like to see the technical details of how the sev-en core works. e.g. in the examples I've seen a lot of converter wrapper stuff ... Building an official MyFaces Maven Artifact which bootup a development environment (MyFaces Fullstack) with what we think on need for development of any-range-sized applications would be more approriate then. Such a project could include sev-en too. Ciao, Mario -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: partial model update on ppr request
The pprSubmit is something like a generic autoSubmit feature for command components (see also autoSubmit attribute in trinidad). Adding this feature to pprSubmit would somehow break the existing ppr behavior, where the triggered components register themselves for updates. Thomas On Thu, Mar 27, 2008 at 12:00 PM, Gerald Müllan [EMAIL PROTECTED] wrote: Hi Mario, i think this usecase is already covered by the component. Have a look at the current nightly build page http://example.irian.at/example-sandbox-20080327/pprPanelGroupOnChange.jsf Especially the input component in combination with the outputText element. You may have to play with immediate=true and a valueChangeListener, but it should be possible!? Apart from this, your solution sounds quite good, the user would expect it exactly this way not the other one. cheers, Gerald On Thu, Mar 27, 2008 at 11:44 AM, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi! I have the need to do a partial model update for given components on ppr submit. (subform won't work here) I have a form with a couple of input fields, lets say FIELD_A, FIELD_B, FIELD_C, FIELD_D - all in one form. FIELD_A is required now, after something has been entered in FIELD_B, FIELD_C should be updated from the server using the data of FIELD_B. For this to work, I thought extending the new pprSubmit component with something like updateComponentIds=. You then will be able to have a commandLink (probably hidden) with s:pprSubmit updateComponentIds=FIELD_B / (comma separated list). The PprPhaseListener then has to do some magic to only update/validate those fields and skip the normal JSF phases. I'll going to add that stuff if no one objects. Ciao, Mario -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: partial model update on ppr request
ok, now I got it - nice approach +1
On Thu, Mar 27, 2008 at 2:54 PM, Mario Ivankovits [EMAIL PROTECTED] wrote:
Hi!
The pprSubmit is something like a generic autoSubmit feature for
command components (see also autoSubmit attribute in trinidad).
? pprSubmit does nothing else than rendering the javascript to hook on
the new components too, no?
I do not understand what you mean with autoSubmit here.
Adding this feature to pprSubmit would somehow break the existing ppr
behavior, where the triggered components register themselves for
updates.
I do not change the existing ppr behavior, just how the data sent by it
will be processed on the server. If this will break the ppr philosophy
then I think the ppr is broken at all, isn't it?
Just to be sure everyone understand what I would like to have.
The interesting part of this view is:
* a single form
* a required customer name
* a country/zip pair which needs to be available in the model during ppr
* a city which will be computed out of the country/zip data during ppr
The problem is, that due to the required customer the ppr will not work
due to the validation error which will happen.
h:form
s:pprPanelGroup partialTrigger=lookupCity
t:panelGrid columns=2
h:outputText value=Customer Name /
h:inputText id=name value=#{bean.name} required=true /
h:outputText value=Country /
h:selectOneMenu id=country value=#{bean.country} /
h:outputText value=Zip /
h:inputText id=zip value=#{bean.zip} required=true
s:submitOnEvent event=change for=lookupCity /
/h:inputText
h:outputText value=City /
h:panelGroup
h:outputText id=cityAuto value=#{bean.cityAuto}
renderer=#{bean.cityAuto}/
h:commandButton action=#{bean.overrideCity}
renderer=#{bean.cityAuto}/
h:inputText id=cityMan value=#{bean.cityMan}
renderer=#{!bean.cityAuto} required=true /
h:commandButton action=#{bean.resetCityToAutomatic}
renderer=#{!bean.cityAuto}/
/h:panelGroup
/t:panelGrid
/s:pprPanelGroup
h:commandButton id=lookupCity action=#{bean.lookupCity} style=hidden
s:pprSubmit processComponentIds=country,zip /
/h:commandButton
h:commandButton action=#{bean.save} /
/h:form
The complicated thing is, that the pprSubmit enhancement would require a
custom LifeCycle for PPR requests (why is it a PhaseListener by now?)
Another possibility to fix that would be to enhance subForm to nicely
work in a nested mode so that you can have a subForm with multiple
subForms within and a logical name (new attribute) to group the subForms
together.
Then ppr as it is today might work then, the resulting view wouldn't
look nice though.
Or, using RichFaces with its ajax implementation which might allow this
already ... adding this library for just one function seems weird to me
though :-(
Ciao,
Mario
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
[jira] Resolved: (MYFACES-1827) MessageUtils don't handle MessageFormat substitution correctly with different Locale
[
https://issues.apache.org/jira/browse/MYFACES-1827?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Spiegl resolved MYFACES-1827.
Resolution: Fixed
now it's also fixed in 1.2.3-SNAPSHOT
MessageUtils don't handle MessageFormat substitution correctly with different
Locale
Key: MYFACES-1827
URL: https://issues.apache.org/jira/browse/MYFACES-1827
Project: MyFaces Core
Issue Type: Bug
Affects Versions: 1.1.5
Environment: Java 6+5, Myfaces 1.1.5
Reporter: Veit Guna
Assignee: Thomas Spiegl
Fix For: 1.1.6-SNAPSHOT, 1.2.3-SNAPSHOT
Attachments: MessageUtils.patch
Using MessageUtils to generate FacesMessages from ResourceBundle like:
my.message.key=Your current balance is {0,number,currency}
Doesn't work out for other locales than the default one. Internally
MessageUtils uses MessageFormat to do substitution. Due to wrong handling
the given Locale won't be used correctly leading to wrong currency symbols
and formatting in for example t:messages.
The provided patch includes the fix, as well as two testcases to reproduce
the problem.
BTW: is there any JSF-API way to have resource bundle entries read via
MessageFormat?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Reopened: (MYFACES-1827) MessageUtils don't handle MessageFormat substitution correctly with different Locale
[
https://issues.apache.org/jira/browse/MYFACES-1827?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Spiegl reopened MYFACES-1827:
fix also in 1.2.3-SNAPSHOT
MessageUtils don't handle MessageFormat substitution correctly with different
Locale
Key: MYFACES-1827
URL: https://issues.apache.org/jira/browse/MYFACES-1827
Project: MyFaces Core
Issue Type: Bug
Affects Versions: 1.1.5
Environment: Java 6+5, Myfaces 1.1.5
Reporter: Veit Guna
Assignee: Thomas Spiegl
Fix For: 1.1.6
Attachments: MessageUtils.patch
Using MessageUtils to generate FacesMessages from ResourceBundle like:
my.message.key=Your current balance is {0,number,currency}
Doesn't work out for other locales than the default one. Internally
MessageUtils uses MessageFormat to do substitution. Due to wrong handling
the given Locale won't be used correctly leading to wrong currency symbols
and formatting in for example t:messages.
The provided patch includes the fix, as well as two testcases to reproduce
the problem.
BTW: is there any JSF-API way to have resource bundle entries read via
MessageFormat?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [vote] [orchestra] release Core 1.1
+1 On Mon, Mar 10, 2008 at 9:10 AM, Matthias Wessendorf [EMAIL PROTECTED] wrote: +1 -M On Mon, Mar 10, 2008 at 1:17 AM, Martin Marinschek [EMAIL PROTECTED] wrote: +1, regards, Martin On Sat, Mar 8, 2008 at 4:38 PM, simon [EMAIL PROTECTED] wrote: Hi All, As has been discussed recently, it is time to get a core-1.1 release out. This requires releasing the orchestra parent pom too. The maven artifacts have been deployed to the staging repo: * Apache MyFaces Orchestra Maven [1] * Apache MyFaces Orchestra Core [2] The tar.gz and zip archives are deployed at [3] The code to be released is currently in svn under http://svn.apache.org/repos/asf/myfaces/orchestra/branches/ and will be moved to the tags dir when the vote passes. The release notes can be found at [4] Please have a look at these artifacts and vote: [ ] +1 for community members who have reviewed the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released, and why.. The vote will be open for 72 hours (tuesday evening european time). I'll start the voting with +1 (non-binding) :-) Regards, Simon [1] http://people.apache.org/builds/myfaces/m2-staging-repository/org/apache/myfaces/orchestra/myfaces-orchestra-maven/1.1/ [2] http://people.apache.org/builds/myfaces/m2-staging-repository/org/apache/myfaces/orchestra/myfaces-orchestra-core/1.1/ [3] http://people.apache.org/~skitching/orchestra/ [4] http://svn.apache.org/repos/asf/myfaces/orchestra/branches/core-1_1/RELEASE-NOTES.txt -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: MessageFormat
Hi, I'll have a look at it. -Thomas On Mon, Mar 10, 2008 at 11:17 PM, Veit Guna [EMAIL PROTECTED] wrote: Hi. Is there any chance that this patch will be included in the 1.1.6 release or even in the 1.1.5 version in a fix-release? https://issues.apache.org/jira/browse/MYFACES-1827 -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: MessageFormat
fixed, thanks for your patch! Thomas On Mon, Mar 10, 2008 at 11:22 PM, Thomas Spiegl [EMAIL PROTECTED] wrote: Hi, I'll have a look at it. -Thomas On Mon, Mar 10, 2008 at 11:17 PM, Veit Guna [EMAIL PROTECTED] wrote: Hi. Is there any chance that this patch will be included in the 1.1.6 release or even in the 1.1.5 version in a fix-release? https://issues.apache.org/jira/browse/MYFACES-1827 -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
[jira] Created: (MYFACES-1833) UIComponentBase catches all Exceptions on broadcast
UIComponentBase catches all Exceptions on broadcast --- Key: MYFACES-1833 URL: https://issues.apache.org/jira/browse/MYFACES-1833 Project: MyFaces Core Issue Type: Bug Components: JSR-127, JSR-252 Affects Versions: 1.1.6-SNAPSHOT, 1.2.3-SNAPSHOT Reporter: Thomas Spiegl Priority: Critical In UIComponentBase.broadcast(FacesEvent event) catches all Exceptions rethrows a FacesException -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-1833) UIComponentBase catches all Exceptions on broadcast
[
https://issues.apache.org/jira/browse/MYFACES-1833?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12576753#action_12576753
]
Thomas Spiegl commented on MYFACES-1833:
catch(Exception ex) {
throw new FacesException(Exception while calling broadcast on
component : +getPathToComponent(this), ex);
}
the api docs say ...
Throws:
AbortProcessingException - Signal the JavaServer Faces implementation that
no further processing on the current event should be performed
java.lang.IllegalStateException
java.lang.NullPointerException - if event is null
UIComponentBase catches all Exceptions on broadcast
---
Key: MYFACES-1833
URL: https://issues.apache.org/jira/browse/MYFACES-1833
Project: MyFaces Core
Issue Type: Bug
Components: JSR-127, JSR-252
Affects Versions: 1.1.6-SNAPSHOT, 1.2.3-SNAPSHOT
Reporter: Thomas Spiegl
Priority: Critical
In UIComponentBase.broadcast(FacesEvent event) catches all Exceptions
rethrows a FacesException
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [orchestra] plans
On Sat, Mar 8, 2008 at 7:34 AM, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi! +1 very good idea! Are those +1 due to the fact that you think that Orchestra is not the best place where such a component is located (which I understood), or is it that this component is still missunderstood ( :-( ) ? +1 was for moving unstable code to orchestra sandbox and then release core15 Fact is, that this component is a great timesaver when it comes to build master-data edit/view/list paged - typical CRUD stuff. Together with facelets templating and a little bit of base code creating new pages is just a matter of minutes and the best - these pages automatically follow the changes of the beans it creates (at runtime) the view for. Ciao, Mario -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: [orchestra] plans
+1 very good idea! On Wed, Mar 5, 2008 at 10:18 AM, Manfred Geiler [EMAIL PROTECTED] wrote: yes, +1 on moving dynaform to sandbox. the annotation stuff seems stable and there are many people out there who would like it to see this dings in the official maven repo. --Manfred On Wed, Mar 5, 2008 at 8:59 AM, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi! 2) release of orchestra-core15-1.0 We're working on it, but there's quite a lot of effort still needed. It all works (and is being used in production) but needs a lot of polishing before a stable API can be declared. Probably a couple of months away.. Really months? What do you plan to change/polish? As it is now, probably yes. The dynaForm stuff is really a hughe code-base needing some thoughts to being sure having a stable api. What we can think of moving the dynaForm stuff into the Orchestra sandbox. Then core15 should be a no-brainer for a release. This might make sense as thoughts are to merge the dynaForm stuff with another project. I'll kick off a discussion about it soon. Ciao, Mario -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
[orchestra] plans
Hi orchestra team, just used orchestra in one of my projects, works really great - thanks for your effort! Are there any plans to release orchestra-core-1.1? When looking through the project I was missing ... 1) download link for orchestra-core-1.0 on http://myfaces.apache.org/download.html 2) release of orchestra-core15-1.0 3) release of orchestra-core-1.1 documentation is really good up to date, but already refers to orchestra-core-1.1-SNAPSHOT. It isn't fully compliant to release 1.0 and therefore confusing for someone using release 1.0 4) an example for @ConversationRequire? -Thomas
Re: [orchestra] plans
On Tue, Mar 4, 2008 at 10:24 PM, simon [EMAIL PROTECTED] wrote: On Tue, 2008-03-04 at 20:38 +0100, Thomas Spiegl wrote: Hi orchestra team, just used orchestra in one of my projects, works really great - thanks for your effort! Great - thanks for the feedback. Did you use the persistence stuff, or just the plain conversation-scoping? I used both, extendes persistence context orchestra scopes. Worked both fine for me. Are there any plans to release orchestra-core-1.1? Yes. Hopefully either Mario or I will post an RC tomorrow or the day after, and start the vote. http://wiki.apache.org/myfaces/ReleasePlanForCore1%2e1 great to hear. I'll test it as soon as it's available When looking through the project I was missing ... 1) download link for orchestra-core-1.0 on http://myfaces.apache.org/download.html Yep. The last release was just to the maven repo. It's rather tempting to do the same again, actually. Is a download bundle actually useful to anyone? yes, not everyone is using maven out there. Some people are missing the download links. 2) release of orchestra-core15-1.0 We're working on it, but there's quite a lot of effort still needed. It all works (and is being used in production) but needs a lot of polishing before a stable API can be declared. Probably a couple of months away.. Really months? What do you plan to change/polish? 3) release of orchestra-core-1.1 documentation is really good up to date, but already refers to orchestra-core-1.1-SNAPSHOT. It isn't fully compliant to release 1.0 and therefore confusing for someone using release 1.0 Agreed. But there isn't enough manpower ATM to write both 1.0 and 1.1 docs. I have *tried* to indicate where 1.0 and 1.1 differ. If there are any bits that are misleading please let me know. I did not write down the differences. A new release would help to be up to date. Ideally there would be different websites for different releases. The Maven project has just moved to this approach for plugin docs, but are still ironing out the problems; I don't know of any other project that has yet managed to do this. And unfortunately I don't have time to be a leader in this area - but am happy to be a follower if someone can show how it can be done. 4) an example for @ConversationRequire? I'll update the docs in the next few days to improve that. Another user also pointed out that we need to better document the spring conversationName attribute. The Orchestra Examples project does use this annotation, so you can look there for information but it does need to also be on the website docs. thanks, managed to get it working - the feature is just likely to be missed reading the docs. Cheers, Simon ciao, Thomas -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
[jira] Created: (TOMAHAWK-1204) PPRPanelGroup encodeChildren does not render
PPRPanelGroup encodeChildren does not render Key: TOMAHAWK-1204 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1204 Project: MyFaces Tomahawk Issue Type: Bug Components: PPRPanelGroup Reporter: Thomas Spiegl Fix For: 1.1.7-SNAPSHOT PPRPanelGroup encodeChildren does not render using facelets (1.1.14) facelets.BUILD_BEFORE_RESTORE=true Reason: the DISABLE_RENDER_CHILDREN is not getting restored if acelets.BUILD_BEFORE_RESTORE set true fix: render, even if DISABLE_RENDER_CHILDREN = null -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TOMAHAWK-1205) PPR does not work commandLinks nested inside a dataTable
PPR does not work commandLinks nested inside a dataTable
Key: TOMAHAWK-1205
URL: https://issues.apache.org/jira/browse/TOMAHAWK-1205
Project: MyFaces Tomahawk
Issue Type: Improvement
Components: PPRPanelGroup
Reporter: Thomas Spiegl
Assignee: Thomas Spiegl
Fix For: 1.1.7-SNAPSHOT
the following ppr example does not work.
s:pprPanelGroup id=group partialTriggers=edit
t:dataTable var=entity value=#{backingBean.entities}
t:column
h:commandLink id=edit value=#{project.name} /
/h:commandLink
/t:dataTable
s:pprPanelGroup
problem: the pprPanelGroupRenderer renderer looks for it's triggers and renders
the necessary PPR javascript. Therefore the renderer has to know the trigger's
client id, which of course does not work in the example above.
solution: let the trigger components (UICommand components) render the
necessecary PPR javascript itself. To enable UIComponents to be a PPR trigger,
I suggest to add a s:pprSubmit / to a trigger component, like ...
s:pprPanelGroup id=group partialTriggers=edit
t:dataTable var=entity value=#{backingBean.entities}
t:column
h:commandLink id=edit value=#{project.name}
s:pprSubmit /
/h:commandLink
/h:commandLink
/t:dataTable
s:pprPanelGroup
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: svn commit: r615200 - /myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/custom/datascroller/HtmlDataScrollerRenderer.java
The scroller implementation assumes that a commandLink renders it's
children nested between the link tag. Trinidad's commandLink for
example deviates from this behaviour renders the a start tag
within encodeEnd of the renderer. Any other component library might do
the same.
Indeed it's not nice to create the commandLink without using the
factory. A better solution might be to check the commandLink
implementation to render the link's children correctly.
Regards,
Thomas
On Jan 26, 2008 9:51 AM, simon [EMAIL PROTECTED] wrote:
I haven't analysed this in depth, but this patch doesn't look like a
good idea to me.
Everywhere else in renderers we create components via the normal
factories.
I'm concerned that this will fix one particular user's issue, and break
many other situations.
Regards,
Simon
On Fri, 2008-01-25 at 12:20 +, [EMAIL PROTECTED] wrote:
Author: tomsp
Date: Fri Jan 25 04:20:00 2008
New Revision: 615200
URL: http://svn.apache.org/viewvc?rev=615200view=rev
Log:
TOMAHAWK-117 resolved, applied patch from Martin Haimberger
Modified:
myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/custom/datascroller/HtmlDataScrollerRenderer.java
Modified:
myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/custom/datascroller/HtmlDataScrollerRenderer.java
URL:
http://svn.apache.org/viewvc/myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/custom/datascroller/HtmlDataScrollerRenderer.java?rev=615200r1=615199r2=615200view=diff
==
---
myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/custom/datascroller/HtmlDataScrollerRenderer.java
(original)
+++
myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/custom/datascroller/HtmlDataScrollerRenderer.java
Fri Jan 25 04:20:00 2008
@@ -344,7 +344,7 @@
if(ondblclick != null){
link.setOndblclick(ondblclick);
}
-
+
link.encodeBegin(facesContext);
facetComp.encodeBegin(facesContext);
if (!facetComp.getRendersChildren())
@@ -412,7 +412,7 @@
String onclick = scroller.getOnclick();
String ondblclick = scroller.getOndblclick();
-
+
for (int i = start, size = start + pages; i size; i++)
{
int idx = i + 1;
@@ -495,10 +495,13 @@
String text, int pageIndex)
{
String id = HtmlDataScrollerRenderer.PAGE_NAVIGATION +
Integer.toString(pageIndex);
+
Application application = facesContext.getApplication();
-HtmlCommandLink link = (HtmlCommandLink) application
-.createComponent(HtmlCommandLink.COMPONENT_TYPE);
+ // See Jira Issue TOMAHAWK-117
http://issues.apache.org/jira/browse/TOMAHAWK-117
+// and http://issues.apache.org/jira/browse/MYFACES-1809
+HtmlCommandLink link = new
org.apache.myfaces.component.html.ext.HtmlCommandLink();
+
link.setId(scroller.getId() + id);
link.setTransient(true);
UIParameter parameter = (UIParameter) application
@@ -526,8 +529,10 @@
{
Application application = facesContext.getApplication();
-HtmlCommandLink link = (HtmlCommandLink) application
-.createComponent(HtmlCommandLink.COMPONENT_TYPE);
+ // See Jira Issue TOMAHAWK-117
http://issues.apache.org/jira/browse/TOMAHAWK-117
+// and http://issues.apache.org/jira/browse/MYFACES-1809
+HtmlCommandLink link = new
org.apache.myfaces.component.html.ext.HtmlCommandLink();
+
link.setId(scroller.getId() + facetName);
link.setTransient(true);
UIParameter parameter = (UIParameter) application
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
[jira] Created: (TRINIDAD-889) inputDate day light saving bug
inputDate day light saving bug -- Key: TRINIDAD-889 URL: https://issues.apache.org/jira/browse/TRINIDAD-889 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 1.0.5-core Reporter: Thomas Spiegl JavaScript for inputDate component (DateField.js) adds the day light offset to the selected date value. This does not work when selecting a date that has a different day light offset then the actual date. day light offset is calculated in function _getDayLightSavOffset var currDate = new Date(); var dstDate = new Date(newValue); var dlsOffset = dstDate.getTimezoneOffset() - currDate.getTimezoneOffset(); here's an example what happens: currDate = 9.1.2008 (GMT+1 vienna wintertime) dstDate = 7.8.2007 (GMT+2 vienna summertime) dlsOffset = -120- (-60) = -60 == bug: instead of 7.8.2007, 6.8.2007 will show up in inputDate field, because 1 hour is subtracted from the selected date value Is there any reason for adding the day light offset to the selected date value? Wehn skipping day light saving adjustment, the component works fine. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (ORCHESTRA-14) ConversationManagerSessionListener leak IllegalStateException
[ https://issues.apache.org/jira/browse/ORCHESTRA-14?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Spiegl resolved ORCHESTRA-14. Resolution: Fixed Fix Version/s: 1.1 resolved ConversationManagerSessionListener leak IllegalStateException --- Key: ORCHESTRA-14 URL: https://issues.apache.org/jira/browse/ORCHESTRA-14 Project: MyFaces Orchestra Issue Type: Bug Components: Conversation Affects Versions: 1.1 Environment: tomcat 5 Reporter: Thomas Spiegl Assignee: Thomas Spiegl Fix For: 1.1 ConversationManagerSessionListener has serveral issues: 1) attributeReplaced sets the old instance of conversationManager in conversationWiperThread instead of the new one 2) on session expire ConversationManagerSessionListener.attributeRemoved is getting called and session.getId() throws IllegalStateException 3) ConversationManagerSessionListener.sessionDestroyed will throw a IllegalStateException as well - method is useless Solution: 1) use a unique id for conversationManager instead of session.getId() as a key in conversationWiperThread 2) remove HttpSessionListener interface from ConversationManagerSessionListener -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (ORCHESTRA-14) ConversationManagerSessionListener leak IllegalStateException
ConversationManagerSessionListener leak IllegalStateException --- Key: ORCHESTRA-14 URL: https://issues.apache.org/jira/browse/ORCHESTRA-14 Project: MyFaces Orchestra Issue Type: Bug Components: Conversation Affects Versions: 1.1 Environment: tomcat 5 Reporter: Thomas Spiegl Assignee: Thomas Spiegl ConversationManagerSessionListener has serveral issues: 1) attributeReplaced sets the old instance of conversationManager in conversationWiperThread instead of the new one 2) on session expire ConversationManagerSessionListener.attributeRemoved is getting called and session.getId() throws IllegalStateException 3) ConversationManagerSessionListener.sessionDestroyed will throw a IllegalStateException as well - method is useless Solution: 1) use a unique id for conversationManager instead of session.getId() as a key in conversationWiperThread 2) remove HttpSessionListener interface from ConversationManagerSessionListener -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Server state saving and multiple frames
Nicu's solution works fine for MyFaces commandLinks using the MyFaces JspStateManager. Someone using MyFaces Tomahawk can take advantage out of this new view pool approach. The big problem here: It does not work using a component library that decorates the statemanager (eg. trinidad). So far I did not take a look to trinidad's statesaving mechanism. It'll be worth to think about a more common solution for having a state view pool. -Thomas On Dec 20, 2007 9:41 AM, Simon Kitching [EMAIL PROTECTED] wrote: Orchestra provides a tag that can be explicitly wrapped around links (eg h:outputLink). It then encodes a window id into the url params. So it also partially addresses the second part of the problem (identifying windows/frames). It covers more cases than Nicu's suggestion, but it does require modifications to pages. Orchestra then uses this window-id to provide a new set of conversation-scoped beans per window. But nothing in orchestra addresses the problem of the view-state pool, so unless I misunderstand something this Orchestra feature is not really usable; the backing beans will work right but when the viewstate gets screwed up after 4 page-views that is no consolation. I think myfaces core needs to provide a per-window viewstate cache. It can then just allow something else to figure out how to identify the windows, allowing the Orchestra approach or Nicu's approach, or whatever people come up with. Yes, it would be interesting to hear how Trinidad dialogs handle this.. Regards, Simon Martin Marinschek [EMAIL PROTECTED] schrieb: Hi Nicu, we should include Mario in this discussion - he implemented a solution for this in Orchestra. Also, how about Trinidad, in Trinidad there is dialog handling as well, how is this done? regards, Martin On 12/19/07, simon [EMAIL PROTECTED] wrote: Hi Nicu, I haven't got time to look at this closely, but IMO siomething like this is definitely needed in MyFaces. A user with multiple windows is certainly going to have trouble at the moment. I think a modification to the view pool to include a window id (or frame id) is definitely a good idea. The second part of the problem still remains: how to associate a different id with each window/frame. Checking CommandLink components for a target attribute is clever; it doesn't solve all the cases but does solve some. Regards, Simon On Tue, 2007-12-18 at 19:07 +0200, Nicu Mercioiu wrote: Hi, There is a problem in JSF when more than one window are opened in an application. There are only a maximum number of NUMBER_OF_VIEWS_IN_SESSION view states saved at one moment (when server side state saving is enabled). If you have 2 windows opened and you navigate on one of them for NUMBER_OF_VIEWS_IN_SESSION times, you will lose the other window's state. I've been facing this problem while developing a project so I've implemented a solution for it. The solution is having a number of view states saved for each opened window at one moment. For determining when a new window (frame) is opened, the target of the submitting component (or its enclosing form) is used. This is obtained in the HtmlLinkRendererBase's and HtmlButtonRendererBase's decode methods and it is set in the RequestMap. Using the submitted target, the JspStateManagerImpl figures out whether a new frame was opened. If so, a new frame id is generated. In the renderResponse phase, the frameId is encoded in the javax.faces.ViewState field and is used along with the viewId to save the state in a SerializedViewCollection. In the restore view phase the frameId is decoded from the javax.faces.ViewState field and is used along with the viewId to restore the corresponding state from the SerializedViewCollection. In SerializedViewCollection instead of a list of recently used views, now a list is kept for each frameId. The following context params are defined for configuring this. NUMBER_OF_FRAMES_IN_SESSION (max frames stored) NUMBER_OF_VIEWS_IN_FRAME (max views stored per frame) These replace the old: NUMBER_OF_VIEWS_IN_SESSION context-param. What is your opinion on this solution? Of course this solution only works with MyFaces Tomahawk's commandLink and commandButton. Ohter component sets that do not use a custom stateManager might use this feature if they will just modify the renderers of command components to set the target attribute in the requestMap. An extra feature would be to enable this for outputLinks (plain old links) and for JS (openWindow). The solution for this is quite simple, just add a GET parameter named 'target' and set the value the same as the target attribute. In the JspStateManagerImpl this value is obtained
[jira] Updated: (TRINIDAD-873) JavaScriptError in Core.js _formatErrorString
[
https://issues.apache.org/jira/browse/TRINIDAD-873?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Spiegl updated TRINIDAD-873:
---
Status: Patch Available (was: Open)
JavaScriptError in Core.js _formatErrorString
-
Key: TRINIDAD-873
URL: https://issues.apache.org/jira/browse/TRINIDAD-873
Project: MyFaces Trinidad
Issue Type: Bug
Affects Versions: 1.0.5-core
Reporter: Thomas Spiegl
Assignee: Matthias Weßendorf
currValue in defined in function _formatErrorString line 2807 may be a
function (eg. removeDuplicates)
currValue.replace will then cause a JavaScript error
adding a typeof fixes the problem
// if the token has no value or !typeof string, replace it with the empty
string
if (!currValue || !(typeof currValue == string))
{
currValue = ;
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (TRINIDAD-873) JavaScriptError in Core.js _formatErrorString
JavaScriptError in Core.js _formatErrorString
-
Key: TRINIDAD-873
URL: https://issues.apache.org/jira/browse/TRINIDAD-873
Project: MyFaces Trinidad
Issue Type: Bug
Affects Versions: 1.0.5-core
Reporter: Thomas Spiegl
Assignee: Matthias Weßendorf
currValue in defined in function _formatErrorString line 2807 may be a function
(eg. removeDuplicates)
currValue.replace will then cause a JavaScript error
adding a typeof fixes the problem
// if the token has no value or !typeof string, replace it with the empty
string
if (!currValue || !(typeof currValue == string))
{
currValue = ;
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (TRINIDAD-874) RequestQueue.js breaks tomahawk components
RequestQueue.js breaks tomahawk components -- Key: TRINIDAD-874 URL: https://issues.apache.org/jira/browse/TRINIDAD-874 Project: MyFaces Trinidad Issue Type: Bug Affects Versions: 1.0.5-core Reporter: Thomas Spiegl Assignee: Matthias Weßendorf Trinidad ppr breaks tomahawk components by sending all input type=submit fields in the subsequent xhr request. t:panelTabbedPane for example will always queue a TabChangeEvent and therefore navigate directly to RenderResponsePhase when processing the Event in the ApplyRequestValuesPhase UpdateModelPhase therefore never takes place and ppr seems not to work. Looks like the error is in RequestQueue.js 187 TrRequestQueue.prototype._getPostbackContent ... 199 // todo: do not post values for non-triggering submit buttons 200 if (input.name !input.disabled) adding a check for submit buttons in line 200 fixes the problem 200 if (input.name !input.disabled !(input.tagName==INPUT input.type==submit) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TRINIDAD-874) RequestQueue.js breaks tomahawk components
[ https://issues.apache.org/jira/browse/TRINIDAD-874?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Spiegl updated TRINIDAD-874: --- Status: Patch Available (was: Open) RequestQueue.js breaks tomahawk components -- Key: TRINIDAD-874 URL: https://issues.apache.org/jira/browse/TRINIDAD-874 Project: MyFaces Trinidad Issue Type: Bug Affects Versions: 1.0.5-core Reporter: Thomas Spiegl Assignee: Matthias Weßendorf Trinidad ppr breaks tomahawk components by sending all input type=submit fields in the subsequent xhr request. t:panelTabbedPane for example will always queue a TabChangeEvent and therefore navigate directly to RenderResponsePhase when processing the Event in the ApplyRequestValuesPhase UpdateModelPhase therefore never takes place and ppr seems not to work. Looks like the error is in RequestQueue.js 187 TrRequestQueue.prototype._getPostbackContent ... 199 // todo: do not post values for non-triggering submit buttons 200 if (input.name !input.disabled) adding a check for submit buttons in line 200 fixes the problem 200 if (input.name !input.disabled !(input.tagName==INPUT input.type==submit) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [VOTE] Portlet Bridge Specification for JSF (JSR-301) code donation
+1 On 10/15/07, Paul McMahan [EMAIL PROTECTED] wrote: +1 (non-binding) Best wishes, Paul On Oct 15, 2007, at 7:03 AM, Manfred Geiler wrote: This is the official vote for the acceptance of Oracle's donation of the JSR-301 [1] reference implementation code as a new MyFaces sub module. Please note that - since the codebase is small enough and there are no new committers - the intellectual property issues are handled by IP clearance [2] rather than incubation. You can find the current IP clearance status at [3]. Upon positive vote result the codebase will be imported into SVN at: http://svn.apache.org/repos/asf/myfaces/portlet-bridge/trunk Please note: This vote is for the latest code drop at [4] with the following checksum. MD5: 861076b6accc3728a3e36d4c240cf28f Regards, Manfred Geiler [1] http://jcp.org/en/jsr/detail?id=301 [2] http://incubator.apache.org/ip-clearance/index.html [3] http://incubator.apache.org/ip-clearance/jsr-301-ri.html [4] https://issues.apache.org/jira/browse/MYFACES-1664 -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: [VOTE] release of Apache MyFaces Orchestra 1.0 (II)
+1 passed my tests On 10/10/07, Werner Punz [EMAIL PROTECTED] wrote: Mario Ivankovits schrieb: Hi! Next try to get Orchestra into the wild ... I was running the needed tasks to get the following artifacts released: (All artifacts are deployed to the MyFaces staging repository) * Apache MyFaces Orchestra Maven [1] * Apache MyFaces Orchestra Core [2] I have been using it for a while without problems +1 from me. Cheers Werner -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: Trinidad Core - 1.2.1 release
+1 change temporary to JSF-RI's API, On 6/28/07, Bruno Aranda [EMAIL PROTECTED] wrote: Yes, you can change it, it is just a build dependency on the API, so no problems with that and it shows that the core API 1.2 is fine, at least for building trinidad! :-) Bruno On 28/06/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: nobody complained, so I started. Trinidad depends on MyFAces-1.2.-0-API SNAPSHOT. Not out yet, so no Trinidad 1.2.1 release. We can change temporary to JSF-RI's API, which is already released (it is only a build dependency, since in Java EE 5, which is the scope of Trinidad 1.2.1 JSF-API/IMPL are provided) I am +1 on changing it *temporary* on the release branch. (not on trunk!) -M On 6/27/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: just a heads up. Tomorrow morning German time, I'll create the branch for the CORE 1.2.1 release. -M -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ mail: matzew-at-apache-dot-org -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ mail: matzew-at-apache-dot-org -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: [vote] release of Trinidad core (1.0.1)
+1 On 6/21/07, Bernd Bohmann [EMAIL PROTECTED] wrote: +1 Martin Marinschek wrote: +1 regards, Martin On 6/21/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: Must be, these files are created by the same assembly, just the *format* is different. -M On 6/20/07, Adam Winer [EMAIL PROTECTED] wrote: Hrm, nevermind, I think I was grabbing a cached version. -- Adam On 6/20/07, Adam Winer [EMAIL PROTECTED] wrote: The dist .tar.gz still contains commons-beanutils/collections/logging -- Adam On 6/20/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: thanks for pointing these issues out. I fixed them and replaced the old files, with new ones. Thanks! Matthias On 6/20/07, Adam Winer [EMAIL PROTECTED] wrote: -1, with two problems: - The dist zip contains Javadoc for trinidadinternal. That's both a lot of wasted space and documenting code that we explicitly don't want people touching. - We dist zip includes commons-beanutils/collections/logging JARs even though our runtime code has no dependencies on any of them. -- Adam On 6/19/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: Hi, I was running the needed tasks to get the 101 release of the Trinidad MyFaces CORE out. This is the first release of the JSF components (targeted for JSF 1.1) since leaving the Apache Incubator. The artifacts are deployed to my private Apache account ([1] and [2]). Please take a look at the 1.0.1 artifacts and vote [ ] +1 for community members who have reviewed the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released, and why.. Thanks, Matthias [1] http://people.apache.org/~matzew/trinidad_core_101/ [2] http://people.apache.org/~matzew/trinidad_core_101_dist/ -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ mail: matzew-at-apache-dot-org -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ mail: matzew-at-apache-dot-org -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ mail: matzew-at-apache-dot-org -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
[jira] Created: (TOMAHAWK-1026) Panelnavigation does not close items
Panelnavigation does not close items Key: TOMAHAWK-1026 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1026 Project: MyFaces Tomahawk Issue Type: Bug Components: Panel Navigation2 Reporter: Thomas Spiegl Some Items are not getting closed, if another subtree's item is clicked. Subtree A Item A.1 (open) Subtree B Item B.1 click in B.1 does not close Subtree A -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (TOMAHAWK-1026) Panelnavigation does not close items
[ https://issues.apache.org/jira/browse/TOMAHAWK-1026?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Spiegl resolved TOMAHAWK-1026. - Resolution: Fixed Fix Version/s: 1.1.7-SNAPSHOT Panelnavigation does not close items Key: TOMAHAWK-1026 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1026 Project: MyFaces Tomahawk Issue Type: Bug Components: Panel Navigation2 Affects Versions: 1.1.7-SNAPSHOT Reporter: Thomas Spiegl Fix For: 1.1.7-SNAPSHOT Some Items are not getting closed, if another subtree's item is clicked. Subtree A Item A.1 (open) Subtree B Item B.1 click in B.1 does not close Subtree A -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [COMMUNITY] Peter Mahoney - Committer
Welcome! On 6/14/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: Welcome Peter! On 6/14/07, Paul Spencer [EMAIL PROTECTED] wrote: Welcome aboard Peter. Paul Spencer Grant Smith wrote: The Myfaces PMC is proud to announce a new addition to our community. Please welcome Peter Mahoney as the newest MyFaces committer. Peter has been exceedingly helpful in providing patches in JIRA and is a great value to this project ! Thanks Peter! -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ mail: matzew-at-apache-dot-org -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
[jira] Created: (TRINIDAD-50) ClassCastException in ExternalContextUtils
ClassCastException in ExternalContextUtils -- Key: TRINIDAD-50 URL: https://issues.apache.org/jira/browse/TRINIDAD-50 Project: MyFaces Trinidad Issue Type: Bug Components: Portlet Affects Versions: 1.0.1-core Reporter: Thomas Spiegl Situation: At the beginning of an ActionResponse org.apache.myfaces.trinidadinternal.contextFacesContextFactoryImpl.getFacesContext() is getting called. Bug: In the following ExternalContextUtils ._getPortletContentType causes a ClassCastException environment: jsf-portlet bridge 1.0.2-RC (patched).+ myfaces 1.1.5 + myfaces trinidad 1.0.1-SNAPSHOT + pluto 1.1.3 + tomcat 5.5.17 adding this patch the above configuration seems to work. Thomas -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TRINIDAD-50) ClassCastException in ExternalContextUtils
[ https://issues.apache.org/jira/browse/TRINIDAD-50?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12503765 ] Thomas Spiegl commented on TRINIDAD-50: --- the above description is inaccurate - please substitute ActionResponse by RenderReqest ClassCastException in ExternalContextUtils -- Key: TRINIDAD-50 URL: https://issues.apache.org/jira/browse/TRINIDAD-50 Project: MyFaces Trinidad Issue Type: Bug Components: Portlet Affects Versions: 1.0.1-core Reporter: Thomas Spiegl Attachments: ExternalContextUtils.patch Situation: At the beginning of an ActionResponse org.apache.myfaces.trinidadinternal.contextFacesContextFactoryImpl.getFacesContext() is getting called. Bug: In the following ExternalContextUtils ._getPortletContentType causes a ClassCastException environment: jsf-portlet bridge 1.0.2-RC (patched).+ myfaces 1.1.5 + myfaces trinidad 1.0.1-SNAPSHOT + pluto 1.1.3 + tomcat 5.5.17 adding this patch the above configuration seems to work. Thomas -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Trinidad and Portlets
What about trinidad skinning in a portlet environment? Is there a solution for adding the necessary link element to the html header? Thomas On 6/11/07, Scott O'Bryan [EMAIL PROTECTED] wrote: Hey Martin, One thing we could look at if 286 won't be released for a while is an extension to Trinidad to support a plugable ppr system. This would be a lot of work but we could have plugins for various portals that would allow us to enable PPR. If a plugin was not available for a particular portal then we fall back to no ppr. Still, we really need a functioning bridge before we can test this effectively so I totally agree with your comment about getting the bridge done first. Who knows, maybe 286 will be released by the time we get everything put together. Scott Scott O'Bryan wrote: Moving this to Dev list since it belongs there... :) Martin Marinschek wrote: Hi Scott, interesting, thanks for the further clarification. I see the problems very clearly now. Well then - let's start off this portlet bridge, and see where it brings us to! regards, Martin On 6/11/07, Scott O'Bryan [EMAIL PROTECTED] wrote: Martin, PPR in Portlets CAN be implemented using certain portlet implementations. But it cannot be done with generic JSR-168. Here are a number of problems although I'm sure there are more: 1. Action Requests have portal artifacts. This means that a portal can append content to a response (and typically will) making it insufficient to use in an XMLHttpRequest and/or an iframe with ppr data and JS. 2. Resource Requests are not in-protocol. This means that if we decide to retrieve the PPR segment as a resource, we are not guaranteed to have the same session.. Especially in remote WSRP type environments. Even if we could, portlet-scoped properties on the session are prefixed with javax.portlet.[PORTLET_ID] and there is no way in JSR-168 to obtain the portlet id for the portlet instance. In MANY implementations this is the same as the namespace, but this is in no way guaranteed by JSR-168. This makes it impossible for all JSR-168 containers to support a servlet type fallback. That being said, I have successfully used the servlet technique on Pluto and WebSphere (when not running through WSRP) by using the namespace as the portlet id, but I would rather wait for JSR-286 to come out (which is looking like it will support BOTH an in-protocol resource requests AND a special XMLHttpRequest handler) in order to enable AJAX in a container agnostic fashion. Do you agree? Scott Martin Marinschek wrote: Hi Scott, sorry for the late response - I've been on vacation the last week. Yeah, your proposal seems definitely interesting. The bridge could certainly be a sub-project of MyFaces. I was thinking about why PPR wouldn't be supported in a portlet environment - is that due to the fact that the portlet server itself would need to know about PPR, and so it is entirely impossible to do this in portlet servers? I envision it might be possible to have the client-side AJAX library post back to a servlet instead of the portlet - would that be possible or not, wdyt? regards, Martin -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
[jira] Created: (MYFACES-1660) memory leak in JspStateManagerImpl
memory leak in JspStateManagerImpl -- Key: MYFACES-1660 URL: https://issues.apache.org/jira/browse/MYFACES-1660 Project: MyFaces Core Issue Type: Bug Affects Versions: 1.1.6-SNAPSHOT, 1.2.0-SNAPSHOT Reporter: Thomas Spiegl Priority: Blocker André Næss reported a memory leak in JspStateManagerImpl: http://www.mail-archive.com/dev@myfaces.apache.org/msg22905.html _oldSerializedViews = new ReferenceMap(); needs to be substituted by _oldSerializedViews = new ReferenceMap(AbstractReferenceMap.WEAK, AbstractReferenceMap.WEAK, true); -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Possible memory leak in JspStateManagerImpl
interesting. Actually it's using a soft reference. What if you substitute
_oldSerializedViews = new ReferenceMap();
by
_oldSerializedViews = new ReferenceMap(AbstractReferenceMap.WEAK,
AbstractReferenceMap.WEAK, true);
?
I'm curious if the behaviour is still the same.
Thomas
On 6/4/07, André Næss [EMAIL PROTECTED] wrote:
Hi
We are working on a JSF project and recently started stress testing the
system. This stress-testing caused the JVM to run out of memory and
spend most of it time doing Full GC. Analyzing the heap revealed that
most of the memory was being retained by SerializedViewCollection
instances. We also noticed that the value of NUMBER_OF_VIEWS_IN_SESSION
didn't seem to affect the memory usage.
I then decided to have a look at the code, and found something very
interesting at line 614 in JspStateManagerImpl. When views are taken out
of the main collection they are stuffed into the _oldSerializedViews
collection which is supposed to be a weak hashmap. The idea here, I
suppose, is to use this as a kind of cache which trades some extra
memory for performance, but only if the memory is available.
Unfortunately it doesn't seem like this works as the author expected
when he wrote this:
// old views will be hold as soft references which will be
removed by
// the garbage collector if free memory is low
The problem we saw when profiling was the the OldGen would grow and grow
and reach a plateau, at which point the GC wasn't able to clean anything
out if it. I removed the usage of the _oldSerializedViews and this
immediately improved the situation. When the OldGen maxes out, a full GC
is executed which reclaims most of the data. I've successfully tested
this using JMeter, with up to 2000 threads running at a constant load of
30 requests per second, and it seems fine.
Unless the _oldSerializedViews object can be made to work properly, I
think it should be removed. After all, the developers can control the
memory in a more predictable manner using the NUMBER_OF_VIEWS_IN_SESSION
parameter. However, it is not entirely clear to me what the purpose of
storing the views in the SerializedViewsCollections really is? Is it
purely a performance trick (providing better rendering times), or does
it provide some other kind of advantage to the end user?
André Næss
Here's the svn diff output:
~/code/myfaces-1.1.5/impl/src/main/java/org/apache/myfaces/application/jsp$
svn diff
Index: JspStateManagerImpl.java
===
--- JspStateManagerImpl.java(revision 543859)
+++ JspStateManagerImpl.java(working copy)
@@ -41,6 +41,7 @@
import javax.faces.render.ResponseStateManager;
import java.io.*;
import java.util.*;
+import java.util.logging.Logger;
import java.util.zip.GZIPInputStream;
import java.util.zip.GZIPOutputStream;
@@ -611,7 +612,7 @@
// old views will be hold as soft references which will be
removed by
// the garbage collector if free memory is low
-private transient Map _oldSerializedViews = null;
+//private transient Map _oldSerializedViews = null;
public synchronized void add(FacesContext context, Object state) {
Object key = new SerializedViewKey(context);
@@ -623,10 +624,10 @@
int views = getNumberOfViewsInSession(context);
while (_keys.size() views) {
key = _keys.remove(0);
-Object oldView = _serializedViews.remove(key);
-if (oldView != null) {
-getOldSerializedViewsMap().put(key, oldView);
-}
+_serializedViews.remove(key);
+//if (oldView != null) {
+//getOldSerializedViewsMap().put(key, oldView);
+//}
}
}
@@ -663,19 +664,19 @@
/**
* @return old serialized views map
*/
-protected Map getOldSerializedViewsMap() {
-if (_oldSerializedViews == null) {
-_oldSerializedViews = new ReferenceMap();
-}
-return _oldSerializedViews;
-}
+//protected Map getOldSerializedViewsMap() {
+//if (_oldSerializedViews == null) {
+//_oldSerializedViews = new ReferenceMap();
+//}
+//return _oldSerializedViews;
+//}
public Object get(Integer sequence, String viewId) {
Object key = new SerializedViewKey(viewId, sequence);
Object value = _serializedViews.get(key);
-if (value == null) {
-value = getOldSerializedViewsMap().get(key);
-}
+//if (value == null) {
+//value = getOldSerializedViewsMap().get(key);
+//}
return value;
}
}
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
Re: [Vote] Sponsoring Entity of RCF (was Re: [Proposal] RCF, a rich component library for JSF)
+1 On 3/19/07, Cagatay Civici [EMAIL PROTECTED] wrote: +1 (non-binding) Cagatay On 3/19/07, Mario Ivankovits [EMAIL PROTECTED] wrote: Matthias Wessendorf schrieb: +1 for MyFaces being the sponsoring entity for RCF +1 Ciao, Mario -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
[jira] Commented: (MYFACES-1546) Find a new name for Apache MyFaces Fusion
[ https://issues.apache.org/jira/browse/MYFACES-1546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12476707 ] Thomas Spiegl commented on MYFACES-1546: Apache MyFaces Cement Apache MyFaces Plaster Find a new name for Apache MyFaces Fusion - Key: MYFACES-1546 URL: https://issues.apache.org/jira/browse/MYFACES-1546 Project: MyFaces Core Issue Type: Task Components: General Reporter: Mario Ivankovits This jira is to collect new names for Apache MyFaces Fusion so far: Apache MyFaces Connections Apache MyFaces Vista Apache MyFaces Salida Apache MyFaces Defender Apache MyFaces Seamless Apache MyFaces Mergence Apache MyFaces Accretion Apache MyFaces Collective Apache MyFaces Aurora Apache MyFaces Concerto Apache MyFaces Orchestra -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: MyFaces Fusion Naming
2 more ... Apache MyFaces Cement Apache MyFaces Plaster On 2/28/07, Grant Smith [EMAIL PROTECTED] wrote: OK, nix my previous vote. I just added the following to the JIRA: The United States of MyFaces (joke) Apache MyFaces States Apache MyFaces StateConverse Apache MyFaces Converse Apache MyFaces Talk Apache MyFaces StateOrchestra Apache MyFaces Music Apache MyFaces Debate Apache MyFaces Fellowship --- I Like this one -- Grant Smith -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: MyFaces Fusion Naming
another one ... Apache MyFaces Edge On 2/28/07, Jeff Bischoff [EMAIL PROTECTED] wrote: Glad you liked it. Yeah I figured it would be pretty common name, but at least not as bad as Spyder! (taken by both SP ETF fund and major winter sports gear company) Anyway it's a cool name, but probably too common Mario Ivankovits wrote: Hi Jeff! Apache Myfaces Spider I like it, though the first hit in google with software spider results in http://www.spider-software.de/ Ciao, Mario -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: Tomahawk 1.1.5 release plans?
+1 for release number tomahawk 1.1.5 On 2/23/07, Paul Spencer [EMAIL PROTECTED] wrote: I suggest releasing from the head with a version of 1.1.5. Releasing the head as 1.1.4 to me is more confusing for the following reasons: o It is currently called 1.1..5-SNAPSHOT o Issues are linked to 1.1.5-SNAPSHOT o Mailing list post refer to 1.1.5-SNAPSHOT o 1.1.4 has already gone through, although partially, a release process. o 1.1.4.1 has already gone through, although partially, a release process. o User searching the mailing list for 1.1.5 issues will have to determine if the post is for the first or second 1.1.5 I do not have a problem with a missing 1.1.4 release, Tomcat does this all the time. The following statement is a concerning statement: 1.1.5 that is 100% compatible to the current core 1.1.5 What does it mean? Are their related Jira issues? Paul Spencer Manfred Geiler wrote: The new tomahawk release number is a trade-off. We must decide between - releasing tomahawk 1.1.4 which is not compatible to core 1.1.4 and therefore might confuse users - skipping tomahawk 1.1.4, stay in sync with core and have a tomahawk 1.1.5 that is 100% compatible to the current core 1.1.5 WDYT? --Manfred On 2/23/07, Scheper, Erik-Berndt [EMAIL PROTECTED] wrote: I agree. The old 1.1.4 RC is getting really aged now. However, it seems strange to just throw it away and follow-up 1.1.3 by 1.1.5 Regards, Erik-Berndt Van: Cagatay Civici [mailto:[EMAIL PROTECTED] Verzonden: vr 23-2-2007 9:27 Aan: MyFaces Development Onderwerp: Re: Tomahawk 1.1.5 release plans? Hi, +1 for throwing away 1.1.4, creating a new branch using current trunk and releasing 1.1.4. Cagatay On 2/23/07, Manfred Geiler [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Ok folks, I will try to start the release process for tomahawk next week. Well, regarding the branch there are various possibilities: - use the already existing 1.1.4 branch from Nov. 2006 and release 1.1.4 - throw away existing 1.1.4 branch, create new branch and release 1.1.4 - (optionally) throw away existing 1.1.4 branch, create new 1.1.5 branch, skip version number 1.1.4 and release 1.1.5 If we use one of the two create new branch strategies, which revision is stable enough. Current head? Thanks, Manfred On 2/22/07, Jeff Bischoff [EMAIL PROTECTED] wrote: +1 on this idea. Tomahawk has settled down since the Dojo move and has been running relatively stable. Best to ensure the next release is branched sometime before any more big changes. (Tomahawk 1.1.4 RC is very good too) :) Paul Spencer wrote: We just completed a MyFaces 1.1.5 release, which resolved blockers related to Tomahawk. Can we get a Tomahawk release done before we start changing things for Fusion? Paul Spencer Disclaimer: This message contains information that may be privileged or confidential and is the property of Sogeti Nederland B.V. or its Group members. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message. -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: [VOTE] MyFaces Core 1.1.5
+1 binding On 2/14/07, Manfred Geiler [EMAIL PROTECTED] wrote: Sorry, one important thing I forgot: The release artifacts already passed the TCK! (Thanks Thomas) --Manfred On 2/14/07, Manfred Geiler [EMAIL PROTECTED] wrote: Hi all, This is the official vote for MyFaces Core 1.1.5. Please note that this vote concerns all of the following parts: 1. Maven artifact group org.apache.myfaces.maven v1.0.5 [1] 2. Maven artifact group org.apache.myfaces.shared v2.0.5 [1] 3. Maven artifact group org.apache.myfaces.core v1.1.5 [1] 4. MyFaces Core Assembly [2] 5. Proposed Release Announcement [3] [1] http://people.apache.org/builds/myfaces/m2-staging-repository/ [2] http://people.apache.org/builds/myfaces/core-1.1.5/ [3] http://wiki.apache.org/myfaces/CoreRelease115#releasenotes --Manfred -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: MyFaces Core 1.1.5 is ready for TCK
Great to hear, that we have a new core release ready. I will run TCK tests within today. -Thomas On 2/8/07, Manfred Geiler [EMAIL PROTECTED] wrote: Dennis, This is a sad story. I'm sorry for your PC. May it rest in peace... FYI, I just had a call with Thomas. He is on vacation right now and was just sitting on a ski lift... Poor Thomas ;-) Thomas is going to do the TCK tests on sunday. Since he already has everything set up on his PC and is able to run the TCK with Tomcat I think it is worth waiting until sunday. Dennis, take care of your new mother board and always wear a grounded wrist band! :) Regards, Manfred On 2/6/07, Dennis Byrne [EMAIL PROTECTED] wrote: Thomas, can you get it this time? Here is my story ... It reached below zero temperature in Chicago this weekend, Lower temperatures make it drier, Dryness allows static electricity, I shocked my computer with static electricity, I smelled burning plastic and the computer shut down, I just ordered a new mother board from Dell. Dennis Byrne On 2/6/07, Manfred Geiler [EMAIL PROTECTED] wrote: Thomas, Dennis, Can one of you please run the TCK tests for core release candidate 1.1.5? You can find the artifacts here: http://people.apache.org/builds/myfaces/m2-staging-repository/org/apache/myfaces/core/ If you have to change/fix something please do so on the 1.1.5 branch at https://svn.apache.org/repos/asf/myfaces/core/branches/1_1_5/ Please note that this core version depends on maven-project 1.0.5 and shared 2.0.5 which you can also find in people.apache.org/builds/myfaces/m2-staging-repository and the corresponding svn branches. This is the last step before the vote. A new MyFaces release is near. Yippee! Thanks, Manfred -- Dennis Byrne -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: MyFaces Core 1.1.5 is ready for TCK
MyFaces Core 1.1.5 passes all TCK tests! We are ready for the next step Manfred. Regards, Thomas On 2/12/07, Thomas Spiegl [EMAIL PROTECTED] wrote: Great to hear, that we have a new core release ready. I will run TCK tests within today. -Thomas On 2/8/07, Manfred Geiler [EMAIL PROTECTED] wrote: Dennis, This is a sad story. I'm sorry for your PC. May it rest in peace... FYI, I just had a call with Thomas. He is on vacation right now and was just sitting on a ski lift... Poor Thomas ;-) Thomas is going to do the TCK tests on sunday. Since he already has everything set up on his PC and is able to run the TCK with Tomcat I think it is worth waiting until sunday. Dennis, take care of your new mother board and always wear a grounded wrist band! :) Regards, Manfred On 2/6/07, Dennis Byrne [EMAIL PROTECTED] wrote: Thomas, can you get it this time? Here is my story ... It reached below zero temperature in Chicago this weekend, Lower temperatures make it drier, Dryness allows static electricity, I shocked my computer with static electricity, I smelled burning plastic and the computer shut down, I just ordered a new mother board from Dell. Dennis Byrne On 2/6/07, Manfred Geiler [EMAIL PROTECTED] wrote: Thomas, Dennis, Can one of you please run the TCK tests for core release candidate 1.1.5? You can find the artifacts here: http://people.apache.org/builds/myfaces/m2-staging-repository/org/apache/myfaces/core/ If you have to change/fix something please do so on the 1.1.5 branch at https://svn.apache.org/repos/asf/myfaces/core/branches/1_1_5/ Please note that this core version depends on maven-project 1.0.5 and shared 2.0.5 which you can also find in people.apache.org/builds/myfaces/m2-staging-repository and the corresponding svn branches. This is the last step before the vote. A new MyFaces release is near. Yippee! Thanks, Manfred -- Dennis Byrne -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: IDEA: client-side state manager that restores majority of saved state from initial tree state
Maybe you can take a look at the Trinidad approach. I think Trinidad solves state-saving more effective than tomahawk or myfaces does. On 12/20/06, Mike Kienenberger [EMAIL PROTECTED] wrote: I'm a fan of client-side state saving. It solves a lot of issues for me. However, there's no doubt that it requires more bandwidth due to saving the entire component tree state in a hidden input field. I wonder how much of this is really necessary. I'm guessing 90% of the state saved is simply constant for a given page.The two examples I can think of where this wouldn't be true would be the localValue for a UIInput or java code that directly manipulates a component. It seems like the state manager could preserve (or recreate) the original state of the component from the page code, compare that state with the current state of the component, and then mark it with a boolean value (didStateChange). For most components, this would result in a save state size of one boolean (no more than a char, and could probably even been put into a bit array if one needed to. For components whose state did differ from the original state, it would require one additional boolean value. This should work for any JSF implementation. A clever implementation could go a step further and separate the state saved into state that rarely differs and state that always differs (UIInput localValue, for instance) so as to reduce even the 10% remaining. So we'd be trading off network (and html size) bandwidth for server-side processing (or perhaps memory if you were willing to cache original page states in the application). Anyone else have any thoughts on this idea? -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: [vote] release tobago 1.0.9
+1 On 12/19/06, Grant Smith [EMAIL PROTECTED] wrote: +1 On 12/18/06, Bernd Bohmann [EMAIL PROTECTED] wrote: Here is my +1 Regards Bernd Bernd Bohmann wrote: Hello, I would like to release tobago 1.0.9, This release contains over 70 changes. For a detail list please consult the release notes: http://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310273styleName=Htmlversion=12312042 The latest 1.0.9-SNAPSHOT is available in the nightly build dir and revision number of the release is 487980 and tagged as tobago-1.0.9. http://people.apache.org/builds/myfaces/nightly/ The Vote is open for 72h. Regards Bernd -- Grant Smith -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
[jira] Created: (TOMAHAWK-815) FilterTable
FilterTable --- Key: TOMAHAWK-815 URL: http://issues.apache.org/jira/browse/TOMAHAWK-815 Project: MyFaces Tomahawk Issue Type: New Feature Reporter: Thomas Spiegl add new component sortable filter table, which is based on dojo's filterTable http://archive.dojotoolkit.org/nightly/tests/widget/test_FilteringTable.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
New component FilterTable
Checkout MyFaces new filterTable component http://www.irian.at/myfaces-sandbox/filterTable.jsf which is based on dojo's filterTable widget. The 2 core features are: - Sorting of multiple columns - Filter to show/hide records based on a criteria -Thomas -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
[jira] Updated: (MYFACES-1467) Validation doesn't run for required fields if submitted value is null
[ http://issues.apache.org/jira/browse/MYFACES-1467?page=all ] Thomas Spiegl updated MYFACES-1467: --- Status: Resolved (was: Patch Available) Resolution: Fixed I applied the original patch to UIInput. In my oppinion the patch does not break the spec which says in 3.5.5 (Standard Validator Implementations): Unless otherwise specified, components with a null local value cause the validation checking by this validator to be skipped. The current behavior can be described as follows: If the submitted value is null and the components required attribute is set true, then the javax.faces.component.UIInput.REQUIRED message is registered and UIInput.valid is set to false. No further validation takes place, so that all posibly registered validators are being skipped. The patch passed all TCK tests. Validation doesn't run for required fields if submitted value is null - Key: MYFACES-1467 URL: http://issues.apache.org/jira/browse/MYFACES-1467 Project: MyFaces Core Issue Type: Bug Components: General Affects Versions: 1.2.0-SNAPSHOT, 1.1.5-SNAPSHOT Reporter: David Chandler Assigned To: Matthias Weßendorf Attachments: patch.txt A component with a required value will not fail validation as expected if the submitted value is null. This issue is not seen normally because browsers send the value for an empty text field as an empty string. That is, the POST data for an empty field1 will contain the field name but no value, like field1=field2=something. However, if you use a man-in-the-middle proxy such as Paros to remove fieldname= from the POST data, the submitted value will be null. UIInput.validate() skips validation for null submitted values, but since requiredness is also part of validation, the requiredness check gets skipped, too. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: I need MyFaces 1.1.5 and Tomahawk 1.1.4 released and I am willing to help!
I will run the tests again. -Thomas On 11/20/06, Martin Marinschek [EMAIL PROTECTED] wrote: I really don't know. Thomas, please comment! regards, Martin On 11/19/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: that wasn't related to the security test, right ? we should apply that patch, because it is saver in a man-in-the-middle-tool case. (does that effect is readonly as well?) On 11/19/06, Martin Marinschek [EMAIL PROTECTED] wrote: Thomas has run the TCK tests - they run through now again. regards, Martin On 11/18/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: From what I know there was an issue on the TCK test... I asked Thomas three weeks ago to run the TCK. Thomas, can you comment here? -M On 11/17/06, Paul Spencer [EMAIL PROTECTED] wrote: I have several projects that are moving from demoware to production. The demoware versions use a snapshot of Tomahawk 1.1.4, so I need for Tomahawk 1.1.4 to be released for the production versions. To this end, I have submitted patches for MyFaces and Tomahawk, and will continue to submit patches. Base on the wiki [1][2] the following are on task need to be completed: 1) Release MyFaces 1.1.5 - Their is one blocker, http://issues.apache.org/jira/browse/MYFACES-1488. Grant Smith has done some work on this, but he has an open question on how to proceed. If the answer involves adding the Apache license to ALL files, I can help with this. 2) TOMAHAWK-767 (http://issues.apache.org/jira/browse/TOMAHAWK-767) - i have submitted a patch on this one, which has not been applied or commented on. As with #1, I am offering to help with this issue. Paul Spencer [1]http://wiki.apache.org/myfaces/TomahawkRelease114?highlight=%28release%29 [2]http://wiki.apache.org/myfaces/CoreRelease115?highlight=%28release%29 -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: I need MyFaces 1.1.5 and Tomahawk 1.1.4 released and I am willing to help!
Just ran the TCK tests. All tests passed! I'm also fine releasing core 1.1.5 and shared 2.0.5. On 11/21/06, Thomas Spiegl [EMAIL PROTECTED] wrote: I will run the tests again. -Thomas On 11/20/06, Martin Marinschek [EMAIL PROTECTED] wrote: I really don't know. Thomas, please comment! regards, Martin On 11/19/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: that wasn't related to the security test, right ? we should apply that patch, because it is saver in a man-in-the-middle-tool case. (does that effect is readonly as well?) On 11/19/06, Martin Marinschek [EMAIL PROTECTED] wrote: Thomas has run the TCK tests - they run through now again. regards, Martin On 11/18/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: From what I know there was an issue on the TCK test... I asked Thomas three weeks ago to run the TCK. Thomas, can you comment here? -M On 11/17/06, Paul Spencer [EMAIL PROTECTED] wrote: I have several projects that are moving from demoware to production. The demoware versions use a snapshot of Tomahawk 1.1.4, so I need for Tomahawk 1.1.4 to be released for the production versions. To this end, I have submitted patches for MyFaces and Tomahawk, and will continue to submit patches. Base on the wiki [1][2] the following are on task need to be completed: 1) Release MyFaces 1.1.5 - Their is one blocker, http://issues.apache.org/jira/browse/MYFACES-1488. Grant Smith has done some work on this, but he has an open question on how to proceed. If the answer involves adding the Apache license to ALL files, I can help with this. 2) TOMAHAWK-767 (http://issues.apache.org/jira/browse/TOMAHAWK-767) - i have submitted a patch on this one, which has not been applied or commented on. As with #1, I am offering to help with this issue. Paul Spencer [1]http://wiki.apache.org/myfaces/TomahawkRelease114?highlight=%28release%29 [2]http://wiki.apache.org/myfaces/CoreRelease115?highlight=%28release%29 -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
[jira] Created: (MYFACES-1500) Default values in standard-faces-config.xml
Default values in standard-faces-config.xml --- Key: MYFACES-1500 URL: http://issues.apache.org/jira/browse/MYFACES-1500 Project: MyFaces Core Issue Type: Bug Affects Versions: 1.1.5-SNAPSHOT Reporter: Thomas Spiegl Assigned To: Thomas Spiegl Fix For: 1.1.5-SNAPSHOT Default values for view-handler and factories are missing in standard-faces-config.xml. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: svn commit: r472050 - /myfaces/core/trunk/impl/pom.xml
Do you remember the class name? On 11/10/06, Martin Marinschek [EMAIL PROTECTED] wrote: Thomas, could you take this over? regards, Martin On 11/9/06, Wendy Smoak [EMAIL PROTECTED] wrote: On 11/9/06, Martin Marinschek [EMAIL PROTECTED] wrote: well, yes - I'm working on both 1.1.5 snapshot of tomahawk and impl, and the startup didn't work anymore. A class that has recently been added by Thomas wasn't found. I'd suggest porting Thomas' change to the 2.0.4 branch of shared, and using that for both MyFaces 1.1.5 and Tomahawk 1.1.4. If we're going to keep shared 2.0.5, the assembly/pom.xml file also needs to be updated. (Right now, core is compiling against Shared 2.0.5, but if you build the release assembly it will include the source for 2.0.4.) -- Wendy -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Core Release 1.1.5
We should release Core 1.1.5 soon, as it's needed for the next tomahawk release. Therefore I tested the current trunk against Sun's TCK and fixed all issues. MyFaces core is new 100 % compatible. I have some time to prepare the release, but will need help from some of you (eg. Wendy). First of all I will create a branch for core 1.1.5 and shared 2.0.5 and start the release process. -Thomas -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
[jira] Resolved: (MYFACES-1479) SerialFactory breaks Portlet bridge
[ http://issues.apache.org/jira/browse/MYFACES-1479?page=all ] Thomas Spiegl resolved MYFACES-1479. Fix Version/s: (was: 1.2.0-SNAPSHOT) Resolution: Fixed moved handleSerialFactory from StartupServletContextListener to FacesConfigurator SerialFactory breaks Portlet bridge --- Key: MYFACES-1479 URL: http://issues.apache.org/jira/browse/MYFACES-1479 Project: MyFaces Core Issue Type: Bug Affects Versions: 1.1.4 Reporter: Stan Silvert Assigned To: Stan Silvert Priority: Blocker Fix For: 1.1.5-SNAPSHOT There is code in StartupServletContextListener that initializes the SerialFactory. Since portlets don't use the StartupServletContextListener, this never gets initialized and results in a NullPointerException. See: http://www.jboss.com/index.html?module=bbop=viewtopict=93223 http://wiki.apache.org/myfaces/PortletSerialFactoryWorkaround The handleSerialFactory() method should be in the FacesConfigurator instead of StartupServletContextListener. You can get the init params via ExternalContext.getInitParameter() instead of ServletContext.getInitParameter(). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Core Release 1.1.5
Yes, I will run the tests again. On 11/9/06, Wendy Smoak [EMAIL PROTECTED] wrote: On 11/8/06, Mario Ivankovits [EMAIL PROTECTED] wrote: Hmmm ... but shared will be copied into the core (or tomahawk) distribution - there is no shared.jar, so I see no advantage of *not* upgrading to the latest shared. This should not introduce a incompatibility with any other release. At least this was the idea. IMHO every release of tomahawk or core should always use the actual shared, in the worst case, shared should be released at the same time as core or tomahawk respectively. Up until yesterday, Core 1.1.5 was using Shared 2.0.4, and it was fine. Thomas, did you run the TCK before or after Martin's change? You might need to re-do it against Core 1.1.5 + Shared 2.0.5 if that's what we're going with. I'm vaguely concerned that there is code in Shared 2.0.5 that goes with the new Tomahawk code and possibly doesn't belong with Core 1.1.5. But I haven't been paying that much attention to commits, and it may not even be an issue. It's slightly less work all around if Core 1.1.5 and Tomahawk 1.1.4 can use the same branch of Shared. It doesn't matter to me either way, I was just surprised to see the dependency version change with an explanation of fixed, since as far as I know it wasn't a problem. Once it's decided, please update the Core 1.1.5 release plan and the project status document. -- Wendy -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
[jira] Resolved: (MYFACES-1430) selectOneMenu looses values after clicking immediate link (since 1.1.4)
[ http://issues.apache.org/jira/browse/MYFACES-1430?page=all ]
Thomas Spiegl resolved MYFACES-1430.
Resolution: Fixed
Thanks for the testcase Michael!!
Patch for MyFaces-1301 broke createComponent in class ApplicationImpl.
selectOneMenu looses values after clicking immediate link (since 1.1.4)
---
Key: MYFACES-1430
URL: http://issues.apache.org/jira/browse/MYFACES-1430
Project: MyFaces Core
Issue Type: Bug
Components: General
Affects Versions: 1.1.4
Environment: myFacesCore 1.1.4
tomahawk 1.1.3
Tomcat 5.5.17
jdk 1.5.0.7
Reporter: Michael Heinen
Priority: Critical
Fix For: 1.1.5-SNAPSHOT
Attachments: ddTest.war
After updating myFacesCore to 1.1.4 a selectOneMenu with a binding is not
working anymore.
The used version of tomahawk is 1.1.3.
The entries of the select one menu are cleared after clicking an immediate
link.
The BackingBean BBController has session scope.
When I go back to myFacesCore 1.1.3 everything works fine!!!
I attached a small demo webApp that everybody can reconstruct this behaviour.
JSP snippet:
f:view
h:form id=myform
h:panelGroup
h:outputText value=MyDropdown style=padding-right:10px;/
h:selectOneMenu id=lastSearch
binding=#{BBController.savedSearchesMenu}/
/h:panelGroup
h:outputText value=br/br/ escape=false/
h:commandLink actionListener=#{BBController.doImmediate}
value=doImmediate immediate=true/h:commandLink
h:outputText value=br/br/ escape=false/
h:commandLink actionListener=#{BBController.doNormal}
value=doNormal/h:commandLink
/h:form
/f:view
BBController snippet:
public class BackingBean implements Serializable {
private static final long serialVersionUID = 1L;
private transient UISelectOne savedSearchesMenu;
public BackingBean() {}
public UISelectOne getSavedSearchesMenu() {
System.out.println (getSavedSearchesMenu called);
if (this.savedSearchesMenu==null){
this.populateSavedSearchesMenu();
}
return this.savedSearchesMenu;
}
public void setSavedSearchesMenu(UISelectOne savedSearchesMenu) {
System.out.println (*** setSavedSearchesMenu called);
this.savedSearchesMenu = savedSearchesMenu;
}
private SelectItem[] populateSavedSearchesMenu(){
SelectItem[] selectItems = new SelectItem[5];
for (int i=0; i5; i++) {
selectItems[i] = new SelectItem(i+ testItem);
}
this.savedSearchesMenu = new HtmlSelectOneMenu();
//add an emtpy Select Item
UISelectItem uiItem = new UISelectItem();
uiItem.setValue( new SelectItem());
this.savedSearchesMenu.getChildren().add(0, uiItem);
//add the saved searches
UISelectItems uiItems = new UISelectItems();
uiItems.setValue(selectItems);
this.savedSearchesMenu.getChildren().add(uiItems);
return selectItems;
}
/**
* Action Listener to show detailed document profile data.
*
* @param ae The ActionEvent
*/
public void doImmediate(ActionEvent ea) {
System.out.println (doImmediate called);
// This causes the current View tree to be discarded and a
fresh one created.
// The new components of course then have no submitted values,
// and so fetch their displayed values via their value-bindings.
FacesContext context = FacesContext.getCurrentInstance();
ViewHandler viewHandler = context.getApplication().getViewHandler();
UIViewRoot viewRoot = viewHandler.createView(context,
context.getViewRoot().getViewId());
context.setViewRoot(viewRoot);
context.renderResponse();
}
/**
* Action Listener to show detailed document profile data.
*
* @param ae The ActionEvent
*/
public void doNormal(ActionEvent ea) {
System.out.println (do normal called);
}
}
Output after clicking the immedaite link
with 1.1.3:
*** setSavedSearchesMenu called
doImmediate called
getSavedSearchesMenu called
with 1.1.4:
*** setSavedSearchesMenu called
doImmediate called
getSavedSearchesMenu called
*** setSavedSearchesMenu called
The obvious difference is the 2.nd call of the setter.
The parameter savedSearchesMenu (of type HtmlSelectOneMenu) is not
initialized anymore.
All attributes are null or false except _valid which is true.
URL of the discussion:
http://marc.theaimsgroup.com/?l=myfaces-userm=115953578324128w=2
--
This message is automatically generated by JIRA
[jira] Reopened: (MYFACES-1301) Check for stale components is effectively broken as implemented in myfaces-impl 1.1.2
[ http://issues.apache.org/jira/browse/MYFACES-1301?page=all ] Thomas Spiegl reopened MYFACES-1301: do not apply this patch again. It breaks ApplicationImpl.createComponent (see MYFACES-1430) the problem must be somewhere else Check for stale components is effectively broken as implemented in myfaces-impl 1.1.2 -- Key: MYFACES-1301 URL: http://issues.apache.org/jira/browse/MYFACES-1301 Project: MyFaces Core Issue Type: Bug Reporter: Christian Kesselheim Assigned To: Grant Smith Fix For: 1.1.4 Attachments: patch.ckesselh_20060509 This causes an IllegalStateException about duplicate ids to pop-up when navigating from one to another instance of the same view, while using component binding at the same time. If you look at the code in ApplicationImpl, starting line 430, you see that it actually fails to archive anything, apart from a fancy log message per stale component it finds. Patch is attached. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MYFACES-1489) ExternalContext Maps
ExternalContext Maps Key: MYFACES-1489 URL: http://issues.apache.org/jira/browse/MYFACES-1489 Project: MyFaces Core Issue Type: Bug Components: JSR-127 Affects Versions: 1.1.5-SNAPSHOT Reporter: Thomas Spiegl Context Maps (SessionMap, RequestHeaderMap, InitParameterMap, ...) return different values each time the map is called -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MYFACES-1490) DateTimeConverter exception on parsing time
DateTimeConverter exception on parsing time --- Key: MYFACES-1490 URL: http://issues.apache.org/jira/browse/MYFACES-1490 Project: MyFaces Core Issue Type: Bug Components: JSR-127 Affects Versions: 1.1.5-SNAPSHOT Reporter: Thomas Spiegl Assigned To: Thomas Spiegl DateTimeConverter throws ParseException on parsing time. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Reopened: (MYFACES-1418) javax.faces.validator - DoubleRangeValidator, LengthValidator, LongRangeValidator are very similar, refactor common behaviour
[ http://issues.apache.org/jira/browse/MYFACES-1418?page=all ] Thomas Spiegl reopened MYFACES-1418: validators in javax.faces.validator package must extend from Object (JSF 1.1) javax.faces.validator - DoubleRangeValidator, LengthValidator, LongRangeValidator are very similar, refactor common behaviour - Key: MYFACES-1418 URL: http://issues.apache.org/jira/browse/MYFACES-1418 Project: MyFaces Core Issue Type: Improvement Components: JSR-127 Affects Versions: 1.1.4 Reporter: Nikolay Petrov Assigned To: Martin Marinschek Fix For: 1.1.5-SNAPSHOT Attachments: validator.patch The 3 classes are very similar to each other except the type of minimum and maximum (and value of course). Therefore I'll suggest extracting the common behaviour in common parent class. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Reopened: (MYFACES-1486) Error Handling in Property-Resolver-Impl
[ http://issues.apache.org/jira/browse/MYFACES-1486?page=all ] Thomas Spiegl reopened MYFACES-1486: This behaviour (PropertyResolverImpl.getValue throws PropertyNotFoundException in case of base == NULL) breaks JSF 1.1 compatibility. Error Handling in Property-Resolver-Impl Key: MYFACES-1486 URL: http://issues.apache.org/jira/browse/MYFACES-1486 Project: MyFaces Core Issue Type: Bug Components: General Reporter: Martin Marinschek Assigned To: Martin Marinschek Fix For: 1.1.5-SNAPSHOT MyFaces currently doesn't handle the case of null-values for the base parameter in the calls to methods of PropertyResolverImpl. This is bad for user-feedback - they never know that a bean that they supplied was spelled wrongly or is null. It's ok for the VariableResolverImpl to return null if the resolved bean is null, and ok for the PropertyResolverImpl to return null if the supplied property-name resolves to null, but not if the supplied base is null! regards, Martin -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Tomahawk 1.1.4 - STATUS
Hi Wendy, I can assist you. Just tell me what you need. -Thomas On 10/17/06, Wendy Smoak [EMAIL PROTECTED] wrote: First, I could really use a co-release manager for this one. Is anyone interested? I've uploaded snapshots of the release assemblies, built from the Tomahawk 1.1.4 and Shared 2.0.4 branches: http://people.apache.org/builds/myfaces/tomahawk-1.1.x/ (Both the build script and the build log can be found in the tomahawk-1.1.x/logs directory.) Please see the release plan for more information, including how to configure the snapshot repository so you can try these jars with your Maven project: http://wiki.apache.org/myfaces/TomahawkRelease114 Note that Tomahawk 1.1.4-SNAPSHOT should be used with MyFaces Core 1.1.5-SNAPSHOT. Feedback welcome-- I'd like to hear from a few people on the dev list before we ask users to test it. (And I have not looked at it myself.) -- Wendy
Re: Tomahawk 1.1.4 - STATUS
Just moved 21 unresolved issues from fixed version 1.1.4-SNAPSHOT to 1.1.5-SNAPSHOT. On 10/17/06, Wendy Smoak [EMAIL PROTECTED] wrote: On 10/16/06, Wendy Smoak [EMAIL PROTECTED] wrote: I've uploaded snapshots of the release assemblies, built from the Tomahawk 1.1.4 and Shared 2.0.4 branches: http://people.apache.org/builds/myfaces/tomahawk-1.1.x/ (Both the build script and the build log can be found in the tomahawk-1.1.x/logs directory.) ... and in the build log I can see that I introduced a typo to one of the dependency elements and broke the build. JEdit 4.3pre6 is doing something strange with alt-File, Open, I keep inadvertently adding an 'o' all over the place. -- Wendy -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: TCK Tests for MYFACES-1467
I ran the TCK tests. 3 test cases failed. I will send the report within the next hour. On 10/14/06, Wendy Smoak [EMAIL PROTECTED] wrote: On 10/13/06, Wendy Smoak [EMAIL PROTECTED] wrote: On 10/13/06, Dennis Byrne [EMAIL PROTECTED] wrote: I'm on busineess/vacation in India right now for another week. After that I have to move into a new apartment. Sorry I can't help on this soon. I would be glad to help someone else through the testing process. I have corresponded with Thomas on this recently. I'd like to learn how to run the TCK also. Okay... just having read Dennis' notes, this isn't something I have time to get into right now. -- Wendy -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
[jira] Created: (TOMAHAWK-743) Fisheye component based on a DataModel
Fisheye component based on a DataModel -- Key: TOMAHAWK-743 URL: http://issues.apache.org/jira/browse/TOMAHAWK-743 Project: MyFaces Tomahawk Issue Type: Improvement Components: FishEyeNavigationMenu Reporter: Thomas Spiegl Fisheye component should be changed to DataModel. The menu can then be rendered based on a Model instead of a component tree which is more effective and menu items can be added dynamically. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Unable to compile -- Re: svn commit: r464453
Thanks Sean, just fixed it.
On 10/16/06, Sean Schofield [EMAIL PROTECTED] wrote:
Maven is complaining about a facelets plugin. Its not available in a
public repo and it doesn't seem to be in the myfaces/maven project.
Sean
On 10/16/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Author: tomsp
Date: Mon Oct 16 04:55:58 2006
New Revision: 464453
URL: http://svn.apache.org/viewvc?view=revrev=464453
Log:
TOMAHAWK-743 implemented
Added:
myfaces/tomahawk/trunk/sandbox/core/src/main/java/org/apache/myfaces/custom/fisheye/FishEyeCommandLink.java
myfaces/tomahawk/trunk/sandbox/core/src/main/java/org/apache/myfaces/custom/fisheye/FishEyeCommandLinkTag.java
myfaces/tomahawk/trunk/sandbox/core/src/main/java/org/apache/myfaces/custom/fisheye/FishEyeItem.java
myfaces/tomahawk/trunk/sandbox/core/src/main/tld/entities/html_fishey_commandlink_attributes.xml
myfaces/tomahawk/trunk/sandbox/examples/src/main/java/org/apache/myfaces/examples/fisheye/labels.properties
Modified:
myfaces/tomahawk/trunk/core/pom.xml
myfaces/tomahawk/trunk/sandbox/core/src/main/java/org/apache/myfaces/custom/fisheye/HtmlFishEyeNavigationMenu.java
myfaces/tomahawk/trunk/sandbox/core/src/main/java/org/apache/myfaces/custom/fisheye/HtmlFishEyeNavigationMenuRenderer.java
myfaces/tomahawk/trunk/sandbox/core/src/main/java/org/apache/myfaces/custom/fisheye/HtmlFishEyeNavigationMenuTag.java
myfaces/tomahawk/trunk/sandbox/core/src/main/resources-facesconfig/META-INF/faces-config.xml
myfaces/tomahawk/trunk/sandbox/core/src/main/tld/entities/html_fisheyelist_attributes.xml
myfaces/tomahawk/trunk/sandbox/core/src/main/tld/myfaces_sandbox.tld
myfaces/tomahawk/trunk/sandbox/examples/src/main/java/org/apache/myfaces/examples/fisheye/FishEyeHandler.java
myfaces/tomahawk/trunk/sandbox/examples/src/main/webapp/fisheye.jsp
Modified: myfaces/tomahawk/trunk/core/pom.xml
URL:
http://svn.apache.org/viewvc/myfaces/tomahawk/trunk/core/pom.xml?view=diffrev=464453r1=464452r2=464453
==
--- myfaces/tomahawk/trunk/core/pom.xml (original)
+++ myfaces/tomahawk/trunk/core/pom.xml Mon Oct 16 04:55:58 2006
@@ -230,6 +230,18 @@
plugins
plugin
+groupIdorg.apache.myfaces.maven/groupId
+artifactIdfacelets-plugin/artifactId
+version1.0.5-SNAPSHOT/version
+executions
+ execution
+phasecompile/phase
+goalsgoalgenerate-taglibs/goal/goals
+ /execution
+/executions
+ /plugin
+
+ plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-surefire-plugin/artifactId
configuration
Added:
myfaces/tomahawk/trunk/sandbox/core/src/main/java/org/apache/myfaces/custom/fisheye/FishEyeCommandLink.java
URL:
http://svn.apache.org/viewvc/myfaces/tomahawk/trunk/sandbox/core/src/main/java/org/apache/myfaces/custom/fisheye/FishEyeCommandLink.java?view=autorev=464453
==
---
myfaces/tomahawk/trunk/sandbox/core/src/main/java/org/apache/myfaces/custom/fisheye/FishEyeCommandLink.java
(added)
+++
myfaces/tomahawk/trunk/sandbox/core/src/main/java/org/apache/myfaces/custom/fisheye/FishEyeCommandLink.java
Mon Oct 16 04:55:58 2006
@@ -0,0 +1,66 @@
+package org.apache.myfaces.custom.fisheye;
+
+import org.apache.myfaces.shared_tomahawk.util._ComponentUtils;
+
+import javax.faces.component.UICommand;
+import javax.faces.el.ValueBinding;
+import javax.faces.context.FacesContext;
+
+/**
+ * @author Thomas Spiegl
+ */
+public class FishEyeCommandLink extends UICommand {
+private String _caption;
+private String _iconSrc;
+private String _target;
+
+public static final String COMPONENT_TYPE =
org.apache.myfaces.FishEyeCommandLink;
+public static final String RENDERER_TYPE =
org.apache.myfaces.FishEyeCommandLink;
+
+public String getCaption() {
+if (_caption != null) return _caption;
+ValueBinding vb = getValueBinding(caption);
+return vb != null ?
_ComponentUtils.getStringValue(getFacesContext(), vb) : null;
+}
+
+public void setCaption(String caption) {
+_caption = caption;
+}
+
+public String getIconSrc() {
+if (_iconSrc != null) return _iconSrc;
+ValueBinding vb = getValueBinding(iconSrc);
+return vb != null ?
_ComponentUtils.getStringValue(getFacesContext(), vb) : null;
+}
+
+public void setIconSrc(String iconSrc) {
+_iconSrc = iconSrc;
+}
+
+public String getTarget() {
+if (_target != null) return _target;
+ValueBinding vb = getValueBinding(target);
+return vb != null ?
_ComponentUtils.getStringValue(getFacesContext(), vb) : null;
+}
+
+public void setTarget(String target) {
+_target = target
[jira] Reopened: (MYFACES-1419) javax.faces.convert - refactor common behaviour + DateTimeConverter changes
[ http://issues.apache.org/jira/browse/MYFACES-1419?page=all ] Thomas Spiegl reopened MYFACES-1419: This patch needs to be reverted. Relevant converters are API classes and must extend from Object. javax.faces.convert - refactor common behaviour + DateTimeConverter changes --- Key: MYFACES-1419 URL: http://issues.apache.org/jira/browse/MYFACES-1419 Project: MyFaces Core Issue Type: Improvement Components: JSR-127 Affects Versions: 1.1.4 Reporter: Nikolay Petrov Assigned To: Martin Marinschek Priority: Minor Fix For: 1.1.5-SNAPSHOT Attachments: converter.patch All available converters look very similar. Extract the common behavior in base class. Also DateTimeConverter can be migrated to work with type safe enums for style and type properties. There are comments in source like //TODO: validate timeStyle. According to java doc of DateTimeConverter on sun there should not have validation. The validation of these will be performed when asString/asObject methods are called. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Tomahawk status?
Please note: We need to release MyFaces Core 1.1.5 before MyFaces Tomahawk 1.1.5. The jsf_sequence is now rendered by the HtmlResponseStateManager when using server side state saving. Before the tomahawk HtmlForm rendered this parameter, which was incompatible to Sun RI and Trinidad. -Thomas On 10/8/06, Wendy Smoak [EMAIL PROTECTED] wrote: On 9/26/06, Martin Marinschek [EMAIL PROTECTED] wrote: I just wanted to fix one final little thing in JavaScript generation - I'll hurry up, I promise. Martin, can we get an update? If it's not a huge change, it might make sense to go ahead and branch so that Werner can proceed with his changes on the trunk. We can always merge changes to the release branch. -- Wendy -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: Tomahawk status?
The order is important. We will need to release core before tomahawk. On 10/9/06, Wendy Smoak [EMAIL PROTECTED] wrote: On 10/9/06, Thomas Spiegl [EMAIL PROTECTED] wrote: Please note: We need to release MyFaces Core 1.1.5 before MyFaces Tomahawk 1.1.5. I was actually talking about Tomahawk 1.1.4. In any case, both core and tomahawk will need to be released again and I don't think the order matters too much. The jsf_sequence is now rendered by the HtmlResponseStateManager when using server side state saving. Before the tomahawk HtmlForm rendered this parameter, which was incompatible to Sun RI and Trinidad. Any comments on this one? http://www.nabble.com/Javascript-changes-and-Core-Tomahawk-compatibility-t2396176.html It sounds like the Tomahawk trunk is incompatible with MyFaces 1.1.4. It's not a problem either way, we just need to document what versions work together. -- Wendy -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
[jira] Created: (MYFACES-1427) Error restoring view
Error restoring view Key: MYFACES-1427 URL: http://issues.apache.org/jira/browse/MYFACES-1427 Project: MyFaces Core Issue Type: Bug Reporter: Thomas Spiegl sharath reddy wrote: There seems to be a problem restoring the view, I get the following error: java.lang.NumberFormatException: For input string: VUPIfby1ciIiAGQV/wIyHg== java.lang.NumberFormatException.forInputString(NumberFormatException.java:48) java.lang.Integer.parseInt(Integer.java:447) java.lang.Integer.init(Integer.java:620) org.apache.myfaces.application.jsp.JspStateManagerImpl.getSerializedViewFromServletSession(JspStateManagerImpl.java:472) org.apache.myfaces.application.jsp.JspStateManagerImpl.restoreTreeStructure(JspStateManagerImpl.java:229) org.apache.myfaces.application.jsp.JspStateManagerImpl.restoreView(JspStateManagerImpl.java:264) org.apache.myfaces.application.jsp.JspViewHandlerImpl.restoreView(JspViewHandlerImpl.java:231) org.apache.myfaces.custom.conversation.ConversationViewHandler.restoreView(ConversationViewHandler.java:116) org.apache.myfaces.lifecycle.RestoreViewExecutor.execute(RestoreViewExecutor.java:78) org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:92) org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:67) javax.faces.webapp.FacesServlet.service(FacesServlet.java:137) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MYFACES-1427) Error restoring view
[ http://issues.apache.org/jira/browse/MYFACES-1427?page=comments#action_12438824 ] Thomas Spiegl commented on MYFACES-1427: cause: if context parameter org.apache.myfaces.SECRET != null, then the jsf_sequence is getting encrypted in HtmlResponseStateManager.getTreeStructureToRestore line 189 Error restoring view Key: MYFACES-1427 URL: http://issues.apache.org/jira/browse/MYFACES-1427 Project: MyFaces Core Issue Type: Bug Affects Versions: 1.1.5-SNAPSHOT Reporter: Thomas Spiegl Assigned To: Thomas Spiegl sharath reddy wrote: There seems to be a problem restoring the view, I get the following error: java.lang.NumberFormatException: For input string: VUPIfby1ciIiAGQV/wIyHg== java.lang.NumberFormatException.forInputString(NumberFormatException.java:48) java.lang.Integer.parseInt(Integer.java:447) java.lang.Integer.init(Integer.java:620) org.apache.myfaces.application.jsp.JspStateManagerImpl.getSerializedViewFromServletSession(JspStateManagerImpl.java:472) org.apache.myfaces.application.jsp.JspStateManagerImpl.restoreTreeStructure(JspStateManagerImpl.java:229) org.apache.myfaces.application.jsp.JspStateManagerImpl.restoreView(JspStateManagerImpl.java:264) org.apache.myfaces.application.jsp.JspViewHandlerImpl.restoreView(JspViewHandlerImpl.java:231) org.apache.myfaces.custom.conversation.ConversationViewHandler.restoreView(ConversationViewHandler.java:116) org.apache.myfaces.lifecycle.RestoreViewExecutor.execute(RestoreViewExecutor.java:78) org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:92) org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:67) javax.faces.webapp.FacesServlet.service(FacesServlet.java:137) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: latest sandbox is broken, error restoring view
fixed this issue, see https://issues.apache.org/jira/browse/MYFACES-1427 On 9/29/06, L Frohman [EMAIL PROTECTED] wrote: I am getting the exact same error. Quick fix - change param-namejavax.faces.STATE_SAVING_METHOD/param-name to param-valueclient/param-value until the problem is corrected. -Original Message- From: sharath reddy [mailto:[EMAIL PROTECTED] Sent: Friday, September 29, 2006 4:26 AM To: dev@myfaces.apache.org Subject: latest sandbox is broken, error restoring view Hello, I also checked with Werner Punz, he has the same problem. There seems to be a problem restoring the view, I get the following error: java.lang.NumberFormatException: For input string: VUPIfby1ciIiAGQV/wIyHg== java.lang.NumberFormatException.forInputString(NumberFormatException.java:48 ) java.lang.Integer.parseInt(Integer.java:447) java.lang.Integer.init(Integer.java:620) org.apache.myfaces.application.jsp.JspStateManagerImpl.getSerializedViewFrom ServletSession(JspStateManagerImpl.java:472) org.apache.myfaces.application.jsp.JspStateManagerImpl.restoreTreeStructure( JspStateManagerImpl.java:229) org.apache.myfaces.application.jsp.JspStateManagerImpl.restoreView(JspStateM anagerImpl.java:264) org.apache.myfaces.application.jsp.JspViewHandlerImpl.restoreView(JspViewHan dlerImpl.java:231) org.apache.myfaces.custom.conversation.ConversationViewHandler.restoreView(C onversationViewHandler.java:116) org.apache.myfaces.lifecycle.RestoreViewExecutor.execute(RestoreViewExecutor .java:78) org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:9 2) org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:67) javax.faces.webapp.FacesServlet.service(FacesServlet.java:137) org.apache.myfaces.custom.conversation.ConversationServletFilter.doFilter(Co nversationServletFilter.java:59) org.apache.myfaces.custom.requestParameterProvider.RequestParameterServletFi lter.doFilter(RequestParameterServletFilter.java:47) org.apache.myfaces.webapp.filter.ExtensionsFilter.doFilter(ExtensionsFilter. java:144) __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
[jira] Resolved: (MYFACES-1427) Error restoring view
[ http://issues.apache.org/jira/browse/MYFACES-1427?page=all ] Thomas Spiegl resolved MYFACES-1427. Fix Version/s: 1.1.5-SNAPSHOT Resolution: Fixed fixed Error restoring view Key: MYFACES-1427 URL: http://issues.apache.org/jira/browse/MYFACES-1427 Project: MyFaces Core Issue Type: Bug Affects Versions: 1.1.5-SNAPSHOT Reporter: Thomas Spiegl Assigned To: Thomas Spiegl Fix For: 1.1.5-SNAPSHOT sharath reddy wrote: There seems to be a problem restoring the view, I get the following error: java.lang.NumberFormatException: For input string: VUPIfby1ciIiAGQV/wIyHg== java.lang.NumberFormatException.forInputString(NumberFormatException.java:48) java.lang.Integer.parseInt(Integer.java:447) java.lang.Integer.init(Integer.java:620) org.apache.myfaces.application.jsp.JspStateManagerImpl.getSerializedViewFromServletSession(JspStateManagerImpl.java:472) org.apache.myfaces.application.jsp.JspStateManagerImpl.restoreTreeStructure(JspStateManagerImpl.java:229) org.apache.myfaces.application.jsp.JspStateManagerImpl.restoreView(JspStateManagerImpl.java:264) org.apache.myfaces.application.jsp.JspViewHandlerImpl.restoreView(JspViewHandlerImpl.java:231) org.apache.myfaces.custom.conversation.ConversationViewHandler.restoreView(ConversationViewHandler.java:116) org.apache.myfaces.lifecycle.RestoreViewExecutor.execute(RestoreViewExecutor.java:78) org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:92) org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:67) javax.faces.webapp.FacesServlet.service(FacesServlet.java:137) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: activePanelTabVar change needs JIRA issue [Was: svn commit: r448171 - in /myfaces/tomahawk/trunk/core/src/main: java/org/apache/myfaces/custom/tabbedpane/ resources/org/apache/myfaces/custom/tabbe
Hi Mike,
no need to feel bad. I thought we open jira issues for important
changes, like new components or changes to MyFaces core. I did not
knew that we have to open a jira issue for new component attributes. I
will consider this in the future.
-Thomas
On 9/20/06, Mike Kienenberger [EMAIL PROTECTED] wrote:
Thomas,
I hate to keep picking on you, but where's the JIRA issue for this?
We'll also want to update the commit log message to point to that
issue (Martin and Wendy talked about how to do that in the last couple
of weeks when Martin forgot to add a JIRA issue).
On 9/20/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Author: tomsp
Date: Wed Sep 20 04:50:22 2006
New Revision: 448171
URL: http://svn.apache.org/viewvc?view=revrev=448171
Log:
new attribute activePanelTabVar for HtmlPanelTabbedPane
Modified:
myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/custom/tabbedpane/HtmlPanelTabbedPane.java
myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/custom/tabbedpane/HtmlPanelTabbedPaneTag.java
myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/custom/tabbedpane/HtmlTabbedPaneRenderer.java
myfaces/tomahawk/trunk/core/src/main/resources/org/apache/myfaces/custom/tabbedpane/HtmlPanelTabbedPane.xml
myfaces/tomahawk/trunk/core/src/main/tld/tomahawk-entities/tomahawk_panel_tabbed_pane_attributes.xml
Modified:
myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/custom/tabbedpane/HtmlPanelTabbedPane.java
URL:
http://svn.apache.org/viewvc/myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/custom/tabbedpane/HtmlPanelTabbedPane.java?view=diffrev=448171r1=448170r2=448171
==
---
myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/custom/tabbedpane/HtmlPanelTabbedPane.java
(original)
+++
myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/custom/tabbedpane/HtmlPanelTabbedPane.java
Wed Sep 20 04:50:22 2006
@@ -161,6 +161,7 @@
private String _inactiveSubStyleClass = null;
private String _tabContentStyleClass = null;
private Boolean _serverSideTabSwitch = null;
+private String _activePanelTabVar;
public HtmlPanelTabbedPane()
{
@@ -172,6 +173,17 @@
return COMPONENT_FAMILY;
}
+public String getActiveTabVar() {
+if (_activePanelTabVar != null) return _activePanelTabVar;
+ValueBinding vb = getValueBinding(activeTabVar);
+return vb != null ?
_ComponentUtils.getStringValue(getFacesContext(), vb) : null;
+}
+
+public void setActiveTabVar(String activeTabVar) {
+_activePanelTabVar = activeTabVar;
+}
+
+
public void setSelectedIndex(int selectedIndex)
{
_selectedIndex = new Integer(selectedIndex);
@@ -284,7 +296,7 @@
public Object saveState(FacesContext context)
{
-Object values[] = new Object[11];
+Object values[] = new Object[12];
values[0] = super.saveState(context);
values[1] = _selectedIndex;
values[2] = _bgcolor;
@@ -296,6 +308,7 @@
values[8] = _tabContentStyleClass;
values[9] = _disabledTabStyleClass;
values[10] = _serverSideTabSwitch;
+values[11] = _activePanelTabVar;
return ((Object) (values));
}
@@ -313,6 +326,7 @@
_tabContentStyleClass = (String)values[8];
_disabledTabStyleClass = (String)values[9];
_serverSideTabSwitch = (Boolean) values[10];
+_activePanelTabVar = (String) values[11];
}
//-- GENERATED CODE END
---
}
Modified:
myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/custom/tabbedpane/HtmlPanelTabbedPaneTag.java
URL:
http://svn.apache.org/viewvc/myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/custom/tabbedpane/HtmlPanelTabbedPaneTag.java?view=diffrev=448171r1=448170r2=448171
==
---
myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/custom/tabbedpane/HtmlPanelTabbedPaneTag.java
(original)
+++
myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/custom/tabbedpane/HtmlPanelTabbedPaneTag.java
Wed Sep 20 04:50:22 2006
@@ -63,6 +63,7 @@
private String _inactiveSubStyleClass;
private String _tabContentStyleClass;
private String _serverSideTabSwitch;
+private String _activePanelTabVar;
// User Role support -- already handled by HtmlPanelGroupTag
@@ -91,6 +92,7 @@
setStringProperty(component, inactiveSubStyleClass,
_inactiveSubStyleClass);
setStringProperty(component, tabContentStyleClass,
_tabContentStyleClass);
setBooleanProperty(component, serverSideTabSwitch,
_serverSideTabSwitch);
+setStringProperty(component, activePanelTabVar,
_activePanelTabVar);
}
Re: activePanelTabVar change needs JIRA issue [Was: svn commit: r448171 - in /myfaces/tomahawk/trunk/core/src/main: java/org/apache/myfaces/custom/tabbedpane/ resources/org/apache/myfaces/custom/tabbe
Is an additional attribute always a non-trivial change? In the
specific case it was a trivial change from my point of view. How
should we handle this in the future?
On 9/22/06, Mike Kienenberger [EMAIL PROTECTED] wrote:
Hey Thomas,
We're now opening jira issues for any non-trivial change change to
Core or Tomahawk (Sandbox is still optional although recommended).
This is how we're generating change-logs, release notes for new releases.
On 9/22/06, Thomas Spiegl [EMAIL PROTECTED] wrote:
Hi Mike,
no need to feel bad. I thought we open jira issues for important
changes, like new components or changes to MyFaces core. I did not
knew that we have to open a jira issue for new component attributes. I
will consider this in the future.
-Thomas
On 9/20/06, Mike Kienenberger [EMAIL PROTECTED] wrote:
Thomas,
I hate to keep picking on you, but where's the JIRA issue for this?
We'll also want to update the commit log message to point to that
issue (Martin and Wendy talked about how to do that in the last couple
of weeks when Martin forgot to add a JIRA issue).
On 9/20/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Author: tomsp
Date: Wed Sep 20 04:50:22 2006
New Revision: 448171
URL: http://svn.apache.org/viewvc?view=revrev=448171
Log:
new attribute activePanelTabVar for HtmlPanelTabbedPane
Modified:
myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/custom/tabbedpane/HtmlPanelTabbedPane.java
myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/custom/tabbedpane/HtmlPanelTabbedPaneTag.java
myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/custom/tabbedpane/HtmlTabbedPaneRenderer.java
myfaces/tomahawk/trunk/core/src/main/resources/org/apache/myfaces/custom/tabbedpane/HtmlPanelTabbedPane.xml
myfaces/tomahawk/trunk/core/src/main/tld/tomahawk-entities/tomahawk_panel_tabbed_pane_attributes.xml
Modified:
myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/custom/tabbedpane/HtmlPanelTabbedPane.java
URL:
http://svn.apache.org/viewvc/myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/custom/tabbedpane/HtmlPanelTabbedPane.java?view=diffrev=448171r1=448170r2=448171
==
---
myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/custom/tabbedpane/HtmlPanelTabbedPane.java
(original)
+++
myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/custom/tabbedpane/HtmlPanelTabbedPane.java
Wed Sep 20 04:50:22 2006
@@ -161,6 +161,7 @@
private String _inactiveSubStyleClass = null;
private String _tabContentStyleClass = null;
private Boolean _serverSideTabSwitch = null;
+private String _activePanelTabVar;
public HtmlPanelTabbedPane()
{
@@ -172,6 +173,17 @@
return COMPONENT_FAMILY;
}
+public String getActiveTabVar() {
+if (_activePanelTabVar != null) return _activePanelTabVar;
+ValueBinding vb = getValueBinding(activeTabVar);
+return vb != null ?
_ComponentUtils.getStringValue(getFacesContext(), vb) : null;
+}
+
+public void setActiveTabVar(String activeTabVar) {
+_activePanelTabVar = activeTabVar;
+}
+
+
public void setSelectedIndex(int selectedIndex)
{
_selectedIndex = new Integer(selectedIndex);
@@ -284,7 +296,7 @@
public Object saveState(FacesContext context)
{
-Object values[] = new Object[11];
+Object values[] = new Object[12];
values[0] = super.saveState(context);
values[1] = _selectedIndex;
values[2] = _bgcolor;
@@ -296,6 +308,7 @@
values[8] = _tabContentStyleClass;
values[9] = _disabledTabStyleClass;
values[10] = _serverSideTabSwitch;
+values[11] = _activePanelTabVar;
return ((Object) (values));
}
@@ -313,6 +326,7 @@
_tabContentStyleClass = (String)values[8];
_disabledTabStyleClass = (String)values[9];
_serverSideTabSwitch = (Boolean) values[10];
+_activePanelTabVar = (String) values[11];
}
//-- GENERATED CODE END
---
}
Modified:
myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/custom/tabbedpane/HtmlPanelTabbedPaneTag.java
URL:
http://svn.apache.org/viewvc/myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/custom/tabbedpane/HtmlPanelTabbedPaneTag.java?view=diffrev=448171r1=448170r2=448171
==
---
myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/custom/tabbedpane/HtmlPanelTabbedPaneTag.java
(original)
+++
myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/custom/tabbedpane
Re: activePanelTabVar change needs JIRA issue [Was: svn commit: r448171 - in /myfaces/tomahawk/trunk/core/src/main: java/org/apache/myfaces/custom/tabbedpane/ resources/org/apache/myfaces/custom/tabbe
We'd still like to get a jira issue opened up for this change as well
so it'll be picked up in the next release.
that definitely makes sense. I'll open an issue.
On 9/22/06, Martin Marinschek [EMAIL PROTECTED] wrote:
I think we should let the developer decide if he wants a trivial
change (and adding an attribute might be trivial) to show up in the
release notes.
As the tabbed-pane is a major component, I'd love to have an
additional attribute in the relase-notes, though.
If the developer decides for no, it can still be the community which
opens a jira-issue and attaches the commit log there.
regards,
Martin
On 9/22/06, Thomas Spiegl [EMAIL PROTECTED] wrote:
Is an additional attribute always a non-trivial change? In the
specific case it was a trivial change from my point of view. How
should we handle this in the future?
On 9/22/06, Mike Kienenberger [EMAIL PROTECTED] wrote:
Hey Thomas,
We're now opening jira issues for any non-trivial change change to
Core or Tomahawk (Sandbox is still optional although recommended).
This is how we're generating change-logs, release notes for new releases.
On 9/22/06, Thomas Spiegl [EMAIL PROTECTED] wrote:
Hi Mike,
no need to feel bad. I thought we open jira issues for important
changes, like new components or changes to MyFaces core. I did not
knew that we have to open a jira issue for new component attributes. I
will consider this in the future.
-Thomas
On 9/20/06, Mike Kienenberger [EMAIL PROTECTED] wrote:
Thomas,
I hate to keep picking on you, but where's the JIRA issue for this?
We'll also want to update the commit log message to point to that
issue (Martin and Wendy talked about how to do that in the last couple
of weeks when Martin forgot to add a JIRA issue).
On 9/20/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Author: tomsp
Date: Wed Sep 20 04:50:22 2006
New Revision: 448171
URL: http://svn.apache.org/viewvc?view=revrev=448171
Log:
new attribute activePanelTabVar for HtmlPanelTabbedPane
Modified:
myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/custom/tabbedpane/HtmlPanelTabbedPane.java
myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/custom/tabbedpane/HtmlPanelTabbedPaneTag.java
myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/custom/tabbedpane/HtmlTabbedPaneRenderer.java
myfaces/tomahawk/trunk/core/src/main/resources/org/apache/myfaces/custom/tabbedpane/HtmlPanelTabbedPane.xml
myfaces/tomahawk/trunk/core/src/main/tld/tomahawk-entities/tomahawk_panel_tabbed_pane_attributes.xml
Modified:
myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/custom/tabbedpane/HtmlPanelTabbedPane.java
URL:
http://svn.apache.org/viewvc/myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/custom/tabbedpane/HtmlPanelTabbedPane.java?view=diffrev=448171r1=448170r2=448171
==
---
myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/custom/tabbedpane/HtmlPanelTabbedPane.java
(original)
+++
myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/custom/tabbedpane/HtmlPanelTabbedPane.java
Wed Sep 20 04:50:22 2006
@@ -161,6 +161,7 @@
private String _inactiveSubStyleClass = null;
private String _tabContentStyleClass = null;
private Boolean _serverSideTabSwitch = null;
+private String _activePanelTabVar;
public HtmlPanelTabbedPane()
{
@@ -172,6 +173,17 @@
return COMPONENT_FAMILY;
}
+public String getActiveTabVar() {
+if (_activePanelTabVar != null) return _activePanelTabVar;
+ValueBinding vb = getValueBinding(activeTabVar);
+return vb != null ?
_ComponentUtils.getStringValue(getFacesContext(), vb) : null;
+}
+
+public void setActiveTabVar(String activeTabVar) {
+_activePanelTabVar = activeTabVar;
+}
+
+
public void setSelectedIndex(int selectedIndex)
{
_selectedIndex = new Integer(selectedIndex);
@@ -284,7 +296,7 @@
public Object saveState(FacesContext context)
{
-Object values[] = new Object[11];
+Object values[] = new Object[12];
values[0] = super.saveState(context);
values[1] = _selectedIndex;
values[2] = _bgcolor;
@@ -296,6 +308,7 @@
values[8] = _tabContentStyleClass;
values[9] = _disabledTabStyleClass;
values[10] = _serverSideTabSwitch;
+values[11] = _activePanelTabVar;
return ((Object) (values));
}
@@ -313,6 +326,7 @@
_tabContentStyleClass = (String)values[8
[jira] Created: (TOMAHAWK-684) New attribute activePanelTabVar for HtmlPanelTabbedPane
New attribute activePanelTabVar for HtmlPanelTabbedPane --- Key: TOMAHAWK-684 URL: http://issues.apache.org/jira/browse/TOMAHAWK-684 Project: MyFaces Tomahawk Issue Type: New Feature Affects Versions: 1.1.5-SNAPSHOT Reporter: Thomas Spiegl Assigned To: Thomas Spiegl Priority: Minor HtmlPanelTabbedPane has a new attribute activePanelTabVar. When rendering a panelTab a Boolean variable is set in request scope. True means that the currently rendered panelTab is active. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: activePanelTabVar change needs JIRA issue [Was: svn commit: r448171 - in /myfaces/tomahawk/trunk/core/src/main: java/org/apache/myfaces/custom/tabbedpane/ resources/org/apache/myfaces/custom/tabbe
you are right Mike, that's the point.
On 9/22/06, Mike Kienenberger [EMAIL PROTECTED] wrote:
The problem with this approach is that the developer doesn't care if
it's in the release notes, but end users do, as do other developers.
When someone upgrades, any change that might affect them should be in
the notes. There shouldn't be any need to go to the wiki, search the
mailing lists, or even search the issue tracker.
Non-trivial changes should have Jira issues. Almost all changes are
non-trivial. Adding a new attribute is definitely non-trivial.
I've worked with projects that went both ways -- the ones that do a
good job with releases document every change in Jira :-)
On 9/22/06, Martin Marinschek [EMAIL PROTECTED] wrote:
I think we should let the developer decide if he wants a trivial
change (and adding an attribute might be trivial) to show up in the
release notes.
As the tabbed-pane is a major component, I'd love to have an
additional attribute in the relase-notes, though.
If the developer decides for no, it can still be the community which
opens a jira-issue and attaches the commit log there.
regards,
Martin
On 9/22/06, Thomas Spiegl [EMAIL PROTECTED] wrote:
Is an additional attribute always a non-trivial change? In the
specific case it was a trivial change from my point of view. How
should we handle this in the future?
On 9/22/06, Mike Kienenberger [EMAIL PROTECTED] wrote:
Hey Thomas,
We're now opening jira issues for any non-trivial change change to
Core or Tomahawk (Sandbox is still optional although recommended).
This is how we're generating change-logs, release notes for new releases.
On 9/22/06, Thomas Spiegl [EMAIL PROTECTED] wrote:
Hi Mike,
no need to feel bad. I thought we open jira issues for important
changes, like new components or changes to MyFaces core. I did not
knew that we have to open a jira issue for new component attributes. I
will consider this in the future.
-Thomas
On 9/20/06, Mike Kienenberger [EMAIL PROTECTED] wrote:
Thomas,
I hate to keep picking on you, but where's the JIRA issue for this?
We'll also want to update the commit log message to point to that
issue (Martin and Wendy talked about how to do that in the last couple
of weeks when Martin forgot to add a JIRA issue).
On 9/20/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Author: tomsp
Date: Wed Sep 20 04:50:22 2006
New Revision: 448171
URL: http://svn.apache.org/viewvc?view=revrev=448171
Log:
new attribute activePanelTabVar for HtmlPanelTabbedPane
Modified:
myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/custom/tabbedpane/HtmlPanelTabbedPane.java
myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/custom/tabbedpane/HtmlPanelTabbedPaneTag.java
myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/custom/tabbedpane/HtmlTabbedPaneRenderer.java
myfaces/tomahawk/trunk/core/src/main/resources/org/apache/myfaces/custom/tabbedpane/HtmlPanelTabbedPane.xml
myfaces/tomahawk/trunk/core/src/main/tld/tomahawk-entities/tomahawk_panel_tabbed_pane_attributes.xml
Modified:
myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/custom/tabbedpane/HtmlPanelTabbedPane.java
URL:
http://svn.apache.org/viewvc/myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/custom/tabbedpane/HtmlPanelTabbedPane.java?view=diffrev=448171r1=448170r2=448171
==
---
myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/custom/tabbedpane/HtmlPanelTabbedPane.java
(original)
+++
myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/custom/tabbedpane/HtmlPanelTabbedPane.java
Wed Sep 20 04:50:22 2006
@@ -161,6 +161,7 @@
private String _inactiveSubStyleClass = null;
private String _tabContentStyleClass = null;
private Boolean _serverSideTabSwitch = null;
+private String _activePanelTabVar;
public HtmlPanelTabbedPane()
{
@@ -172,6 +173,17 @@
return COMPONENT_FAMILY;
}
+public String getActiveTabVar() {
+if (_activePanelTabVar != null) return _activePanelTabVar;
+ValueBinding vb = getValueBinding(activeTabVar);
+return vb != null ?
_ComponentUtils.getStringValue(getFacesContext(), vb) : null;
+}
+
+public void setActiveTabVar(String activeTabVar) {
+_activePanelTabVar = activeTabVar;
+}
+
+
public void setSelectedIndex(int selectedIndex)
{
_selectedIndex = new Integer(selectedIndex);
@@ -284,7 +296,7 @@
public Object saveState(FacesContext context
[jira] Commented: (TOMAHAWK-684) New attribute activePanelTabVar for HtmlPanelTabbedPane
[ http://issues.apache.org/jira/browse/TOMAHAWK-684?page=comments#action_12436844 ] Thomas Spiegl commented on TOMAHAWK-684: Manfred the jokey chest :) New attribute activePanelTabVar for HtmlPanelTabbedPane --- Key: TOMAHAWK-684 URL: http://issues.apache.org/jira/browse/TOMAHAWK-684 Project: MyFaces Tomahawk Issue Type: New Feature Affects Versions: 1.1.5-SNAPSHOT Reporter: Thomas Spiegl Assigned To: Thomas Spiegl Priority: Minor Fix For: 1.1.5-SNAPSHOT HtmlPanelTabbedPane has a new attribute activePanelTabVar. When rendering a panelTab a Boolean variable is set in request scope. True means that the currently rendered panelTab is active. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: JScookMenu is not rendered with Facelets
So now we got it. The rederer-type is missing in your /WEB-INF/tomahawk.taglib.xml tag tag-namejscookMenu/tag-name component component-typeorg.apache.myfaces.JSCookMenu/component-type renderer-typeorg.apache.myfaces.JSCookMenu/renderer-type /component /tag -Thomas On 9/21/06, alexeinov [EMAIL PROTECTED] wrote: Tom Innes wrote: There is a bug however if you try to override the Stylesheet. Thanks for reply, Tom. My problem is that the menu is not rendered at all. The following line of HTML is all that I get in the rendered page: !-- Start: javax.faces.Command[_id0] --input id=_id0 name=_id0 type=submit value= I never come to the point where the stylesheet could be a problem. Anyway, I applied the fix suggested in https://issues.apache.org/jira/browse/TOMAHAWK-575 but it does not change anything. I tried MyFaces and Tomahawk both 1.1.3 and 1.1.5 snapshot - same result. There must be something special about Facelets and JSCookMenu that I'm missing. The tag is described in /WEB-INF/tomahawk.taglib.xml as tag tag-namejscookMenu/tag-name component component-typeorg.apache.myfaces.JSCookMenu/component-type /component /tag faces-config definse JSCookMenu as component component-typeorg.apache.myfaces.JSCookMenu/component-type component-classorg.apache.myfaces.custom.navmenu.jscookmenu.HtmlCommandJSCookMenu/component-class /component Still something is wrong -- View this message in context: http://www.nabble.com/JScookMenu-is-not-rendered-with-Facelets-tf2303975.html#a6423955 Sent from the My Faces - Dev mailing list archive at Nabble.com. -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
[jira] Reopened: (MYFACES-1405) Interoperability with Facelets
[ http://issues.apache.org/jira/browse/MYFACES-1405?page=all ] Thomas Spiegl reopened MYFACES-1405: jsf_sequence may not be rendered by HtmlResponseStateManger cause this breaks Trinidad. Trinidad and other component libraries may have there own ResponseStateManager implementation. There is no guarantee that MyFaces HtmlResponseStateManger is called. Interoperability with Facelets -- Key: MYFACES-1405 URL: http://issues.apache.org/jira/browse/MYFACES-1405 Project: MyFaces Core Issue Type: Improvement Components: General Affects Versions: 1.1.5-SNAPSHOT Reporter: Martin Marinschek Assigned To: Martin Marinschek Priority: Critical Fix For: 1.1.5-SNAPSHOT The current version of 1.1.5-SNAPSHOT had state saving code built into the view-handler. Facelets replaces the view-handler; so this was an attempt that didn't work. Resolution: - moving all the state saving code (especially: view-sequence-id) into the state-manager - letting the HtmlResponseStateManager write code not only in the client-side state saving case, but also in the server-side state saving case how to see that it still doesn't work: watch for issues with the back-button. If you click on the back-button, does a click on a link move you to the next page? If the first one doesn't, but the second one does, this problem has reoccurred and we need to reopen this bug. Can anyone check that this really works with Facelets? regards, Martin -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: naming of dojo components
what about modalDialog? On 9/8/06, Gerald Müllan [EMAIL PROTECTED] wrote: Hi Mario, You know, I dont wanted to point to a special person, just a general discussion. Sorry, that it was your committed component I used as sample ;-) No problem, my strong ego withstands it :) If it sufficiently describes it, sure, though, it was just a wild guess from my side ;-) Let`s take dynamicDialog, sounds good to me. If there is at the end of the day still consent about the renaming, do you have time to rename them too? Or should we ask Werner ;-) No problem, i can do the job. Werner, what are your thoughts about renaming your stuff? regards, Gerald On 9/8/06, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi Gerald! I just accepted the stuff from Thomas. You know, I dont wanted to point to a special person, just a general discussion. Sorry, that it was your committed component I used as sample ;-) So, let`s change the name to dynamicDialog? If it sufficiently describes it, sure, though, it was just a wild guess from my side ;-) There is also * dojoContentPane * dojoSplitPane I think this is where the prefix dynamic really fits well. * dynamicContentPane * dynamicSplitPane If there is at the end of the day still consent about the renaming, do you have time to rename them too? Or should we ask Werner ;-) Ciao, Mario -- Gerald Müllan Schelleingasse 2/11 1040 Vienna, Austria 0043 699 11772506 [EMAIL PROTECTED] -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: MyFaces Core 1.1.4 - STATUS
Do we have to test 1.1.4 against TCK again, as r422749 and r428204 where merged back? 2006-08-05 - [WWW] r428968 merged r422749 and r428204 to branch and new snapshots published What else do we need to do? Can I help? Regards Thomas On 9/5/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: Wendy, I move to a new appartment so, my spare time / weekend is reserved for that. -Matthias On 9/5/06, Wendy Smoak [EMAIL PROTECTED] wrote: I've updated the Core parent pom on the 1.1.4 branch to add Implementation entries to the jar file manifests. The latest release of maven-jar-plugin defaults to a minimal manifest. Apparently scp does not work on the zone, though ssh does. So if you want to deploy to the repository on the zone, you will have to build it from there. (Unless someone knows how to make scp work.) Then I went looking for snapshot dependencies, and (re) discovered that the 'Maven' project has to be released in advance of a Core release. Or at least the myfaces-master pom does, though the way the branch is done it looks like it should be the whole thing. It contains some things for the site, a 'wagon' plugin, and the master pom. Sean, do you know how much of the 'Maven' project is required for a Core release? It's too late tonight for me to get into this, and next weekend does not look good. Matthias, what does it look like for you? -- Wendy -- Matthias Wessendorf further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
Re: svn commit: r434574 [1/2] - in /myfaces: shared/trunk/core/src/main/java/org/apache/myfaces/shared/renderkit/ shared/trunk/core/src/main/java/org/apache/myfaces/shared/renderkit/html/ tomahawk/tru
Sure, I was looking for a jira issue dealing with this problem before my commit last night, but I could not find one. Next time I will open a new one ;) On 8/25/06, Mike Kienenberger [EMAIL PROTECTED] wrote: Also, and I know this isn't always possible, could you commit your code cleanup separately from your code changes? It makes it really hard to see what you've actually done if every line changes due to formatting reasons :-) On 8/24/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Author: tomsp Date: Thu Aug 24 16:52:09 2006 New Revision: 434574 URL: http://svn.apache.org/viewvc?rev=434574view=rev Log: fix for Trinidad / Tomahawk commandlink problem -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
[jira] Created: (MYFACES-1393) MyFaces state information is rendered by MyFaces Form
MyFaces state information is rendered by MyFaces Form - Key: MYFACES-1393 URL: http://issues.apache.org/jira/browse/MYFACES-1393 Project: MyFaces Core Issue Type: Bug Affects Versions: 1.1.3, 1.1.5-SNAPSHOT Reporter: Thomas Spiegl Assigned To: Thomas Spiegl Problem#2 Environment: MyFaces implementation ADF Faces Tomahawk 1.1.5 The hidden parameter jsf-sequence will not be rendered when using an ADF form. Possible solution: A new tomahawk component (myfacesParams), renders all hidden input fields needed by the MyFaces implementation, eg the jsf-sequence param. This artificial component must then be added to every ADF form. This approach will work, but it's fault-prone. Any ideas? Comment by Adam Winer: Problem #2 should not be happening if the MyFaces state management code is properly factored; the FormRenderer - anyone's form renderer - should be calling the ResponseStateManager, which should be rendering the sequence. Last time I looked, the MyFaces FormRenderer was directly encoding the sequence ID, which isn't the right approach. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Issues using Trinidad, ADF tomahawk
Thanks for the hint Adam. Moved the rendering of the jsf_sequence field from HtmlFormRendererBase.encodeEnd to JspViewHandlerImpl.writeState(...). Now the hidden input is rendered when using an ADF form. Thomas On 8/25/06, Werner Punz [EMAIL PROTECTED] wrote: Thomas Spiegl schrieb: Problem #2 (needs to be solved) Environment: MyFaces implementation ADF Faces Tomahawk 1.1.5 The hidden parameter jsf-sequence will not be rendered when using an ADF form. Possible solution: A new tomahawk component (myfacesParams), renders all hidden input fields needed by the MyFaces implementation, eg the jsf-sequence param. This artificial component must then be added to every ADF form. This approach will work, but it's fault-prone. Any ideas? Problem #3... Thomas and I were investigating that one, I am just posting it and will open a Wiki and Jira entry for that later. Once ADF is enabled something in the ADF CSS or scripting disables the Dojo tag and attribute parsing. Now since this is a bad coding practice anyway (at least for html 4.01) I can recommend, switch to the programmatic generation of components, I will add a factory method to the Dojo utils later today (already have written it) Currently affected by this problem seems to be the Fisheye which uses this technique which will be fixed by me later today and some of my unit test pages. Anyway for the guys working on the ADF side please investigate into the problem, this could trigger a lot of other problems in the future which might be non Dojo related. -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Good News:Trinidad Tomahawk
Good news: MyFaces Trinidad and Tomahawk components can now be used together. Major issues regarding tomahawk links have now been fixed. You wil be able to mix Trinidad and Tomahawk components in the same page, putting them into an ADF form. Version note: Get the current MyFaces version from SVN, or use a nightly build = 8/26/2006 http://people.apache.org/builds/myfaces/nightly/ Thomas -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: Issues using Trinidad, ADF tomahawk
Nor wouId I merge it back to 1.1.4 either. Let's test this feature in 1.1.5. Thomas On 8/25/06, Mike Kienenberger [EMAIL PROTECTED] wrote: On 8/25/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: can you move that to the 114 branch ? Yikes! Let's not do anything that might delay the 1.1.4 branch further unless it's a blocker. If it's not a regression, let's leave it for 1.1.5. -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Issues using Trinidad, ADF tomahawk
I started to work on Trinidad and tomahawk incompatibilities. Problem #1 (fixed partly) When using the ADF form, tomahawk links won't work. The reason for this: Tomahawk links are bound to the MyFaces form component. This problem I could partly solve. I started off using an environment, which is typical for users creating an ADF project with JDeveloper. Sun RI 1.1_02 ADF Faces Tomahawk 1.1.5 Tomahawk links can now be used in conjunction with anADF form. In this case the ADF form will be detected, and the links onclick method will be rendered the ADF way. The name of the hidden input will be different than the one MyFaces uses. This fact is considered when extracting the request parameter in the link renderers decode method. Restriction (not solved by now) Tomahawk links are not working using h:form, because the Sun RI Form is not compatible with the MyFaces form. I have in mind that Martin recently resolved this issue, but it did not seem to work for me. Some components using links may still have problems (JSCookMenu was one of this candidates). Problem #2 (needs to be solved) Environment: MyFaces implementation ADF Faces Tomahawk 1.1.5 The hidden parameter jsf-sequence will not be rendered when using an ADF form. Possible solution: A new tomahawk component (myfacesParams), renders all hidden input fields needed by the MyFaces implementation, eg the jsf-sequence param. This artificial component must then be added to every ADF form. This approach will work, but it's fault-prone. Any ideas? Thomas -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: Facelets Tomahawk
I have written an autogenerator for the facelets-taglib. Maybe we can use this one. What about adding new MyFaces examples using facelets? We will need it to test tomahawk facelet support. On 8/3/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: Yes, I know... there is also the Trinidad maven-faces-plugin. On 8/2/06, Mike Kienenberger [EMAIL PROTECTED] wrote: On 8/2/06, Mike Kienenberger [EMAIL PROTECTED] wrote: I think I remember seeing that Manfred had resurrected the code generator before I left on vacation. Just stumbled across the JIRA issue while looking at another. http://issues.apache.org/jira/browse/MYFACES-1284 -- Matthias Wessendorf further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: [WELCOME] MyFaces += (Cagatay, Lance)
Hi Çagatay Lance, welcome to the Apache MyFaces team! Thomas On 8/2/06, Manfred Geiler [EMAIL PROTECTED] wrote: Hi MyFaces community, Please welcome our new MyFaces committers Çagatay Çivici (cagatay) and Lance Frohman (lfrohman)! They both have been very active contributors during the last weeks, so the PMC decided to invite them as new committers. Çagatay and Lance, nice to have you aboard! Regards, Manfred -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Facelets Tomahawk
I will add facelets support to MyFaces tomahawk. Here my suggestions: Tomahawk Facelets classes (TagHandlers, etc.) go to folder: tomahawk/core/src/main/java package: org.apache.myfaces.custom.facelets Tomahawk Facelets Taglib resides in folder: tomahawk/core/src/main/resources-facelets Tomahwak will have a compile time dependency on facelets. Regards Thomas
Re: preserveDataModel does not make selected row available
That's a question for the user list, not dev. Tip: Use the updateActionListener to set the actual rowData in your backingBean. Thomas On 7/28/06, Gregory D Dennis [EMAIL PROTECTED] wrote: Can anyone explain why setting the preserveDataModel attribute to true in a dataTable does not make the selected row (via getRowIndex or getRowData) available on the subsequent request? That seems to be what one would logically expect. Currently, preserving the selected row requires saving the state of the data model's wrapped data. It would be nice if using t:saveState on the wrapped data and setting the preserveDataModel attribute to true had the same effect. -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
