Unsubscribe
Re: [VOTE] Release Tobago 1.0.38
Here is my +1 Regards Bernd On Mon, Oct 17, 2011 at 7:44 PM, Grant Smith work.gr...@gmail.com wrote: +1 On Mon, Oct 17, 2011 at 10:07 AM, Volker Weber v.we...@inexso.de wrote: Hi, +1 Regards, Volker 2011/10/16 Bernd Bohmann bernd.bohm...@atanion.com: Hello, I would like to release Tobago 1.0.38. Changes: Bug [TOBAGO-1020] - The iframe from tc:object should not render a frame in IE [TOBAGO-1023] - Exception if using orderBy attribute of UIMessage in a JDK 1.4 environment [TOBAGO-1031] - Missing ValueExpression support for contentType in tc:validateFileItem Improvement [TOBAGO-1015] - Impossible to select a node in tc:tree by keyboard [TOBAGO-1017] - Sandbox simpleSheet: Impossible to select a row in tc:sheet by keyboard [TOBAGO-1025] - Reduce number of PhaseEvent instances created [TOBAGO-1034] - Activate popup if decode fails [TOBAGO-1035] - Unified access to partialComponentsId in AjaxUtils for 1.0.x and 1.5.x For a detail list please consult the release notes: http://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310273styleName=Htmlversion=12317350 The version is available at the nexus staging repository. Staging repository: https://repository.apache.org/content/repositories/orgapachemyfaces-071/ The Vote is open for 72h. [ ] +1 [ ] +0 [ ] -1 Regards Bernd -- inexso - information exchange solutions GmbH Ofener Str. 30 | 26121 Oldenburg Tel.: +49 441 219 730 56 | FAX: +49 441 219 730 66 | eMail: volker.we...@inexso.de Firmensitz: Oldenburg | Amtsgericht Oldenburg HRB 205251 Geschäftsführer: Stefan Schulte, Michael Terschüren -- Grant Smith - V.P. Information Technology Marathon Computer Systems, LLC.
[RESULT] [VOTE] Release Tobago 1.0.38
The vote has passed with the following results: +1 lofwyr (binding)struberg (binding) weber(binding) grantsmith(binding) bommel (binding) I will proceed with the next steps. Regards Bernd On Sat, Oct 22, 2011 at 8:37 AM, Bernd Bohmann bernd.bohm...@atanion.com wrote: Here is my +1 Regards Bernd On Mon, Oct 17, 2011 at 7:44 PM, Grant Smith work.gr...@gmail.com wrote: +1 On Mon, Oct 17, 2011 at 10:07 AM, Volker Weber v.we...@inexso.de wrote: Hi, +1 Regards, Volker 2011/10/16 Bernd Bohmann bernd.bohm...@atanion.com: Hello, I would like to release Tobago 1.0.38. Changes: Bug [TOBAGO-1020] - The iframe from tc:object should not render a frame in IE [TOBAGO-1023] - Exception if using orderBy attribute of UIMessage in a JDK 1.4 environment [TOBAGO-1031] - Missing ValueExpression support for contentType in tc:validateFileItem Improvement [TOBAGO-1015] - Impossible to select a node in tc:tree by keyboard [TOBAGO-1017] - Sandbox simpleSheet: Impossible to select a row in tc:sheet by keyboard [TOBAGO-1025] - Reduce number of PhaseEvent instances created [TOBAGO-1034] - Activate popup if decode fails [TOBAGO-1035] - Unified access to partialComponentsId in AjaxUtils for 1.0.x and 1.5.x For a detail list please consult the release notes: http://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310273styleName=Htmlversion=12317350 The version is available at the nexus staging repository. Staging repository: https://repository.apache.org/content/repositories/orgapachemyfaces-071/ The Vote is open for 72h. [ ] +1 [ ] +0 [ ] -1 Regards Bernd -- inexso - information exchange solutions GmbH Ofener Str. 30 | 26121 Oldenburg Tel.: +49 441 219 730 56 | FAX: +49 441 219 730 66 | eMail: volker.we...@inexso.de Firmensitz: Oldenburg | Amtsgericht Oldenburg HRB 205251 Geschäftsführer: Stefan Schulte, Michael Terschüren -- Grant Smith - V.P. Information Technology Marathon Computer Systems, LLC.
Time for a Tobago 1.5.0-beta2?
Hello, I think most of the stuff in Tobago 1.5.0 is stable now. It's time for an other beta release. If no objections i will start with the release soon. Regards Bernd
Re: [html5] alpha release for myfaces html5
+1 for moving it to tomahawk.
One big open question for me is our html5 strategy at all.
Will the html5 components provide legacy html support themselfs?
Thus a calendar component will use jQuery (or whatever) calendar when a
non-html5 browser is detected,
or is this in the responsibility of the developer?
if (html5){
} else{
//fallback
}
?
Afaik our current html5 components 'only' support pure html5 rendering, isn't?
LieGrue,
strub
From: Gerhard Petracek gerhard.petra...@gmail.com
To: MyFaces Development dev@myfaces.apache.org
Sent: Friday, October 21, 2011 10:22 PM
Subject: Re: [html5] alpha release for myfaces html5
@grant: +1
regards,
gerhard
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
2011/10/21 Grant Smith work.gr...@gmail.com
I must agree with Gerhard. The whole point of the sandbox is for this very
purpose. However, perhaps we should look at the sandbox more often and vote on
components that are ready to graduate.
On Fri, Oct 21, 2011 at 1:12 PM, Gerhard Petracek
gerhard.petra...@gmail.com wrote:
hi leo,
imo such an argument doesn't justify an own sub-project. i don't say -1.
my point is that we should discuss it (esp. because the situation changed).
regards,
gerhard
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
2011/10/21 Leonardo Uribe lu4...@gmail.com
Hi
The problem with move to tomahawk sandbox is those artifact can't
never be released. Do an alpha release give us the chance to know if
the bits are good enough, get more feedback, and later decide what to
do. The truth is some people only test some artifacts after a
release. Do it as an alpha release means ... software that has just
been compiled and ready for its initial test inhouse. I think
that is enough clear.
regards,
Leonardo Uribe
2011/10/21 Gerhard Petracek gerhard.petra...@gmail.com:
hi ali,
most commits happened directly after the initial import. that didn't
look
very promising.
it's great to hear that you plan to continue.
however, since we haven't seen a lot of activity, we should re-visit the
option to move the components to tomahawk (btw. tomahawk-sandbox).
regards,
gerhard
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
2011/10/21 Ali Ok al...@aliok.com.tr
Hi,
Thank you Leonardo for volunteering in the release.
Yes, it would be good discussing the future.
I am still working on the project. Leonardo and I am the only ones at the
moment.
I am trying to work on the project 1 night a week, so the progress is
slow. I think it will be like this for a while.
We have a few issues to fix / features to implement already in the issue
tracker, and I am going to add more. There isn't enough feedback, since I
guess Html5 stuff is still not supported by every browser and not
everyone
can use them. So the user profile is more like enthusiasts who are
experimenting with Html5.
What we could do is providing fallback for old browsers out of the box,
but it is really hard to implement.
About the future: there is a lot to do in this area and I am willing to
work, but I can say I can spare limited time.
That's the intention of this mail. I think we should do an alpha
release. I don't see reasons to block a release.
I agree.
I am pretty sure a release is good for the project, more people will hear
about it; and hopefully we can get some feedback.
Cheers,
Ali
On Fri, Oct 21, 2011 at 8:50 PM, Werner Punz werner.p...@gmail.com
wrote:
+1
Am 10/21/11 7:56 PM, schrieb Leonardo Uribe:
Hi
That's the intention of this mail. I think we should do an alpha
release. I don't see reasons to block a release.
regards,
Leonardo Uribe
2011/10/21 Gerhard Petracekgerhard.petra...@gmail.com:
before we release it, we should (imo) discuss the future of this
module.
regards,
gerhard
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
2011/10/21 Leonardo Uribelu4...@gmail.com
Hi
It could be good to do an alpha release of myfaces html5 next week.
The site for this project is:
http://myfaces.apache.org/html5/
If no objections I'll do the necessary steps.
regards,
Leonardo Uribe
--
My Blog: http://blog.aliok.com.tr
Twitter: http://twitter.com/aliok_tr
--
Grant Smith - V.P. Information Technology
Marathon Computer Systems, LLC.
[jira] [Created] (MYFACES-3366) FacesContext should use FacesContext.getCurrentInstance() instead of 'this'
FacesContext should use FacesContext.getCurrentInstance() instead of 'this' --- Key: MYFACES-3366 URL: https://issues.apache.org/jira/browse/MYFACES-3366 Project: MyFaces Core Issue Type: Bug Affects Versions: 2.1.3, 2.0.9 Reporter: Bernd Bohmann Assignee: Bernd Bohmann Priority: Minor To support overriding FacesContext should call other methods of FacesContext with FacesContext.getCurrentInstance() -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
Fw: [ANNOUNCE] Apache OpenWebBeans 1.1.2 release
FYI! And thanks to all the contributors, testers and supporters! LieGrue, strub - Forwarded Message - From: Mark Struberg strub...@apache.org To: annou...@apache.org Cc: Sent: Friday, October 21, 2011 9:18 PM Subject: [ANNOUNCE] Apache OpenWebBeans 1.1.2 release T he Apache OpenWebBeans Team is proud to announce the release of Apache OpenWebBeans 1.1.2 Apache OpenWebBeans is an Apache License v2 licensed implementation of the JSR-299 Context and Dependency Injection for Java EE and JSR-330 atinject specifications. OpenWebBeans has a modular structure and provides Dependency Injection scaling from Java SE environments up to EE6 server clusters with complicated ClassLoader hierarchies or OSGi environments. openwebbeans-1.1.2 implements the CDI-1.0 API, passes the JSR-330 TCK and the JSR-299 standalone TCK. Distribution packages can be downloaded from http://www.apache.org/dyn/closer.cgi/openwebbeans/1.1.2/ The release is also available in maven.central http://repo1.maven.org/maven2/org/apache/openwebbeans/ More info can be found at http://openwebbeans.apache.org The Apache OpenWebBeans Team - To unsubscribe, e-mail: announce-unsubscr...@apache.org For additional commands, e-mail: announce-h...@apache.org
[jira] [Resolved] (MYFACES-3366) FacesContext should use FacesContext.getCurrentInstance() instead of 'this'
[ https://issues.apache.org/jira/browse/MYFACES-3366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bernd Bohmann resolved MYFACES-3366. Resolution: Fixed Fix Version/s: 2.1.4 2.0.10 FacesContext should use FacesContext.getCurrentInstance() instead of 'this' --- Key: MYFACES-3366 URL: https://issues.apache.org/jira/browse/MYFACES-3366 Project: MyFaces Core Issue Type: Bug Affects Versions: 2.0.9, 2.1.3 Reporter: Bernd Bohmann Assignee: Bernd Bohmann Priority: Minor Fix For: 2.0.10, 2.1.4 To support overriding FacesContext should call other methods of FacesContext with FacesContext.getCurrentInstance() -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [html5] alpha release for myfaces html5
it's planned that jsf2.2 will get some sort of html5 support.
imo we should work together with the jsf-eg to ensure that we won't promote
incompatible components.
regards,
gerhard
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
2011/10/22 Mark Struberg strub...@yahoo.de
+1 for moving it to tomahawk.
One big open question for me is our html5 strategy at all.
Will the html5 components provide legacy html support themselfs?
Thus a calendar component will use jQuery (or whatever) calendar when a
non-html5 browser is detected,
or is this in the responsibility of the developer?
if (html5){
} else{
//fallback
}
?
Afaik our current html5 components 'only' support pure html5 rendering,
isn't?
LieGrue,
strub
From: Gerhard Petracek gerhard.petra...@gmail.com
To: MyFaces Development dev@myfaces.apache.org
Sent: Friday, October 21, 2011 10:22 PM
Subject: Re: [html5] alpha release for myfaces html5
@grant: +1
regards,
gerhard
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
2011/10/21 Grant Smith work.gr...@gmail.com
I must agree with Gerhard. The whole point of the sandbox is for this very
purpose. However, perhaps we should look at the sandbox more often and vote
on components that are ready to graduate.
On Fri, Oct 21, 2011 at 1:12 PM, Gerhard Petracek
gerhard.petra...@gmail.com wrote:
hi leo,
imo such an argument doesn't justify an own sub-project. i don't say
-1. my point is that we should discuss it (esp. because the situation
changed).
regards,
gerhard
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
2011/10/21 Leonardo Uribe lu4...@gmail.com
Hi
The problem with move to tomahawk sandbox is those artifact can't
never be released. Do an alpha release give us the chance to know if
the bits are good enough, get more feedback, and later decide what to
do. The truth is some people only test some artifacts after a
release. Do it as an alpha release means ... software that has just
been compiled and ready for its initial test inhouse. I think
that is enough clear.
regards,
Leonardo Uribe
2011/10/21 Gerhard Petracek gerhard.petra...@gmail.com:
hi ali,
most commits happened directly after the initial import. that
didn't look
very promising.
it's great to hear that you plan to continue.
however, since we haven't seen a lot of activity, we should re-visit
the
option to move the components to tomahawk (btw. tomahawk-sandbox).
regards,
gerhard
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
2011/10/21 Ali Ok al...@aliok.com.tr
Hi,
Thank you Leonardo for volunteering in the release.
Yes, it would be good discussing the future.
I am still working on the project. Leonardo and I am the only ones
at the
moment.
I am trying to work on the project 1 night a week, so the progress
is
slow. I think it will be like this for a while.
We have a few issues to fix / features to implement already in the
issue
tracker, and I am going to add more. There isn't enough feedback,
since I
guess Html5 stuff is still not supported by every browser and not
everyone
can use them. So the user profile is more like enthusiasts who are
experimenting with Html5.
What we could do is providing fallback for old browsers out of the
box,
but it is really hard to implement.
About the future: there is a lot to do in this area and I am willing
to
work, but I can say I can spare limited time.
That's the intention of this mail. I think we should do an alpha
release. I don't see reasons to block a release.
I agree.
I am pretty sure a release is good for the project, more people will
hear
about it; and hopefully we can get some feedback.
Cheers,
Ali
On Fri, Oct 21, 2011 at 8:50 PM, Werner Punz werner.p...@gmail.com
wrote:
+1
Am 10/21/11 7:56 PM, schrieb Leonardo Uribe:
Hi
That's the intention of this mail. I think we should do an alpha
release. I don't see reasons to block a release.
regards,
Leonardo Uribe
2011/10/21 Gerhard Petracekgerhard.petra...@gmail.com:
before we release it, we should (imo) discuss the future of this
module.
regards,
gerhard
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
2011/10/21 Leonardo Uribelu4...@gmail.com
Hi
It could be good to do an alpha release of myfaces html5 next
week.
The site for this
Re: [html5] alpha release for myfaces html5
Ha, I don't think we should wait for the jsf-eg.
Hey guys they are asking for a alpha release.
In my opinion as long this lib is html5 only it should not be part of
the tomahawk project.
I don't see any problems in releasing an alpha release. But before a
beta we should decide own extension or tomahawk.
Regards
Bernd
On Sat, Oct 22, 2011 at 9:31 AM, Gerhard Petracek
gerhard.petra...@gmail.com wrote:
it's planned that jsf2.2 will get some sort of html5 support.
imo we should work together with the jsf-eg to ensure that we won't promote
incompatible components.
regards,
gerhard
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
2011/10/22 Mark Struberg strub...@yahoo.de
+1 for moving it to tomahawk.
One big open question for me is our html5 strategy at all.
Will the html5 components provide legacy html support themselfs?
Thus a calendar component will use jQuery (or whatever) calendar when a
non-html5 browser is detected,
or is this in the responsibility of the developer?
if (html5){
} else{
//fallback
}
?
Afaik our current html5 components 'only' support pure html5 rendering,
isn't?
LieGrue,
strub
From: Gerhard Petracek gerhard.petra...@gmail.com
To: MyFaces Development dev@myfaces.apache.org
Sent: Friday, October 21, 2011 10:22 PM
Subject: Re: [html5] alpha release for myfaces html5
@grant: +1
regards,
gerhard
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
2011/10/21 Grant Smith work.gr...@gmail.com
I must agree with Gerhard. The whole point of the sandbox is for this
very purpose. However, perhaps we should look at the sandbox more often and
vote on components that are ready to graduate.
On Fri, Oct 21, 2011 at 1:12 PM, Gerhard Petracek
gerhard.petra...@gmail.com wrote:
hi leo,
imo such an argument doesn't justify an own sub-project. i don't say
-1. my point is that we should discuss it (esp. because the situation
changed).
regards,
gerhard
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
2011/10/21 Leonardo Uribe lu4...@gmail.com
Hi
The problem with move to tomahawk sandbox is those artifact can't
never be released. Do an alpha release give us the chance to know if
the bits are good enough, get more feedback, and later decide what to
do. The truth is some people only test some artifacts after a
release. Do it as an alpha release means ... software that has just
been compiled and ready for its initial test inhouse. I think
that is enough clear.
regards,
Leonardo Uribe
2011/10/21 Gerhard Petracek gerhard.petra...@gmail.com:
hi ali,
most commits happened directly after the initial import. that
didn't look
very promising.
it's great to hear that you plan to continue.
however, since we haven't seen a lot of activity, we should re-visit
the
option to move the components to tomahawk (btw. tomahawk-sandbox).
regards,
gerhard
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
2011/10/21 Ali Ok al...@aliok.com.tr
Hi,
Thank you Leonardo for volunteering in the release.
Yes, it would be good discussing the future.
I am still working on the project. Leonardo and I am the only ones
at the
moment.
I am trying to work on the project 1 night a week, so the progress
is
slow. I think it will be like this for a while.
We have a few issues to fix / features to implement already in the
issue
tracker, and I am going to add more. There isn't enough feedback,
since I
guess Html5 stuff is still not supported by every browser and not
everyone
can use them. So the user profile is more like enthusiasts who are
experimenting with Html5.
What we could do is providing fallback for old browsers out of the
box,
but it is really hard to implement.
About the future: there is a lot to do in this area and I am
willing to
work, but I can say I can spare limited time.
That's the intention of this mail. I think we should do an alpha
release. I don't see reasons to block a release.
I agree.
I am pretty sure a release is good for the project, more people
will hear
about it; and hopefully we can get some feedback.
Cheers,
Ali
On Fri, Oct 21, 2011 at 8:50 PM, Werner Punz
werner.p...@gmail.com
wrote:
+1
Am 10/21/11 7:56 PM, schrieb Leonardo Uribe:
Hi
That's the intention of this mail. I think we should do an alpha
release. I don't see reasons to block a release.
regards,
Leonardo Uribe
2011/10/21 Gerhard
[jira] [Commented] (MYFACES-3168) Bound attribute values resolve to NULL during PreRenderViewEvent for nested composite components
[
https://issues.apache.org/jira/browse/MYFACES-3168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13133311#comment-13133311
]
Kennard Consulting commented on MYFACES-3168:
-
Leonardo,
The equivalent issue under Mojarra is
http://java.net/jira/browse/JAVASERVERFACES-2089. Ed Burns has recently started
work on it. Would you care to comment on Ed's patch, given your understanding
of this issue?
Regards,
Richard.
Bound attribute values resolve to NULL during PreRenderViewEvent for nested
composite components
Key: MYFACES-3168
URL: https://issues.apache.org/jira/browse/MYFACES-3168
Project: MyFaces Core
Issue Type: Bug
Components: General
Affects Versions: 2.0.6, 2.1.0
Environment: Windows 7 x64 Enterprise.
JDK 1.6.0_25.
Eclipse Version: Helios Service Release 2
Build id: 20110218-0911
Reporter: MAtthew Sweeney
Assignee: Leonardo Uribe
Attachments: jsf-testing-2.zip, jsf-testing-myfaces.zip,
screenshot-1.jpg
When nesting custom composite components, any data bound attributes (eg
#{someValueExpression} ) will resolve to null during the PreRenderViewEvent.
This only occurs on the second level or deeper nested component (the
top-level component in the page works fine).
This same issue occurs on JSF RI 2.0.4, 2.1.x, 2.2.x
I have an eclipse project for upload that reproduces the problem.
I have no cause for the issue at this time.
Cheers,
Matt
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [html5] alpha release for myfaces html5
a different idea would be a small myfaces-incubator for new project-ideas
(esp. for gsoc projects).
we can release parts easily and drop them if we see that something doesn't
work for our community. if an idea works for the community, we can discuss
the correct place for it.
we might see new gsoc projects (related to myfaces) every year. imo it's the
wrong approach to just add them as new sub-project and we don't have the
resources/community to maintain them.
regards,
gerhard
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
2011/10/22 Bernd Bohmann bernd.bohm...@atanion.com
Ha, I don't think we should wait for the jsf-eg.
Hey guys they are asking for a alpha release.
In my opinion as long this lib is html5 only it should not be part of
the tomahawk project.
I don't see any problems in releasing an alpha release. But before a
beta we should decide own extension or tomahawk.
Regards
Bernd
On Sat, Oct 22, 2011 at 9:31 AM, Gerhard Petracek
gerhard.petra...@gmail.com wrote:
it's planned that jsf2.2 will get some sort of html5 support.
imo we should work together with the jsf-eg to ensure that we won't
promote
incompatible components.
regards,
gerhard
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
2011/10/22 Mark Struberg strub...@yahoo.de
+1 for moving it to tomahawk.
One big open question for me is our html5 strategy at all.
Will the html5 components provide legacy html support themselfs?
Thus a calendar component will use jQuery (or whatever) calendar when a
non-html5 browser is detected,
or is this in the responsibility of the developer?
if (html5){
} else{
//fallback
}
?
Afaik our current html5 components 'only' support pure html5 rendering,
isn't?
LieGrue,
strub
From: Gerhard Petracek gerhard.petra...@gmail.com
To: MyFaces Development dev@myfaces.apache.org
Sent: Friday, October 21, 2011 10:22 PM
Subject: Re: [html5] alpha release for myfaces html5
@grant: +1
regards,
gerhard
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
2011/10/21 Grant Smith work.gr...@gmail.com
I must agree with Gerhard. The whole point of the sandbox is for this
very purpose. However, perhaps we should look at the sandbox more
often and
vote on components that are ready to graduate.
On Fri, Oct 21, 2011 at 1:12 PM, Gerhard Petracek
gerhard.petra...@gmail.com wrote:
hi leo,
imo such an argument doesn't justify an own sub-project. i don't
say
-1. my point is that we should discuss it (esp. because the
situation
changed).
regards,
gerhard
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
2011/10/21 Leonardo Uribe lu4...@gmail.com
Hi
The problem with move to tomahawk sandbox is those artifact can't
never be released. Do an alpha release give us the chance to know if
the bits are good enough, get more feedback, and later decide what
to
do. The truth is some people only test some artifacts after a
release. Do it as an alpha release means ... software that has just
been compiled and ready for its initial test inhouse. I think
that is enough clear.
regards,
Leonardo Uribe
2011/10/21 Gerhard Petracek gerhard.petra...@gmail.com:
hi ali,
most commits happened directly after the initial import. that
didn't look
very promising.
it's great to hear that you plan to continue.
however, since we haven't seen a lot of activity, we should
re-visit
the
option to move the components to tomahawk (btw. tomahawk-sandbox).
regards,
gerhard
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
2011/10/21 Ali Ok al...@aliok.com.tr
Hi,
Thank you Leonardo for volunteering in the release.
Yes, it would be good discussing the future.
I am still working on the project. Leonardo and I am the only
ones
at the
moment.
I am trying to work on the project 1 night a week, so the
progress
is
slow. I think it will be like this for a while.
We have a few issues to fix / features to implement already in
the
issue
tracker, and I am going to add more. There isn't enough feedback,
since I
guess Html5 stuff is still not supported by every browser and not
everyone
can use them. So the user profile is more like enthusiasts who
are
Re: [html5] alpha release for myfaces html5
including our very own little 'attic' :)
Actually the big difference between the incubator and a mf subproject would be
the IP clearance. We really need to do this upfront before importing.
But actually I like this much more than having projects developed outside and
only later brought into our SVN - because this causes lots of paperwork (gas
grants and a IP clearance review is mandatory).
Thus a +1
LieGrue,
strub
From: Gerhard Petracek gerhard.petra...@gmail.com
To: MyFaces Development dev@myfaces.apache.org
Sent: Saturday, October 22, 2011 10:58 AM
Subject: Re: [html5] alpha release for myfaces html5
a different idea would be a small myfaces-incubator for new project-ideas
(esp. for gsoc projects).
we can release parts easily and drop them if we see that something doesn't
work for our community. if an idea works for the community, we can discuss the
correct place for it.
we might see new gsoc projects (related to myfaces) every year. imo it's the
wrong approach to just add them as new sub-project and we don't have the
resources/community to maintain them.
regards,
gerhard
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
2011/10/22 Bernd Bohmann bernd.bohm...@atanion.com
Ha, I don't think we should wait for the jsf-eg.
Hey guys they are asking for a alpha release.
In my opinion as long this lib is html5 only it should not be part of
the tomahawk project.
I don't see any problems in releasing an alpha release. But before a
beta we should decide own extension or tomahawk.
Regards
Bernd
On Sat, Oct 22, 2011 at 9:31 AM, Gerhard Petracek
gerhard.petra...@gmail.com wrote:
it's planned that jsf2.2 will get some sort of html5 support.
imo we should work together with the jsf-eg to ensure that we won't promote
incompatible components.
regards,
gerhard
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
2011/10/22 Mark Struberg strub...@yahoo.de
+1 for moving it to tomahawk.
One big open question for me is our html5 strategy at all.
Will the html5 components provide legacy html support themselfs?
Thus a calendar component will use jQuery (or whatever) calendar when a
non-html5 browser is detected,
or is this in the responsibility of the developer?
if (html5){
} else{
//fallback
}
?
Afaik our current html5 components 'only' support pure html5 rendering,
isn't?
LieGrue,
strub
From: Gerhard Petracek gerhard.petra...@gmail.com
To: MyFaces Development dev@myfaces.apache.org
Sent: Friday, October 21, 2011 10:22 PM
Subject: Re: [html5] alpha release for myfaces html5
@grant: +1
regards,
gerhard
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
2011/10/21 Grant Smith work.gr...@gmail.com
I must agree with Gerhard. The whole point of the sandbox is for this
very purpose. However, perhaps we should look at the sandbox more often
and
vote on components that are ready to graduate.
On Fri, Oct 21, 2011 at 1:12 PM, Gerhard Petracek
gerhard.petra...@gmail.com wrote:
hi leo,
imo such an argument doesn't justify an own sub-project. i don't say
-1. my point is that we should discuss it (esp. because the situation
changed).
regards,
gerhard
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
2011/10/21 Leonardo Uribe lu4...@gmail.com
Hi
The problem with move to tomahawk sandbox is those artifact can't
never be released. Do an alpha release give us the chance to know if
the bits are good enough, get more feedback, and later decide what to
do. The truth is some people only test some artifacts after a
release. Do it as an alpha release means ... software that has just
been compiled and ready for its initial test inhouse. I think
that is enough clear.
regards,
Leonardo Uribe
2011/10/21 Gerhard Petracek gerhard.petra...@gmail.com:
hi ali,
most commits happened directly after the initial import. that
didn't look
very promising.
it's great to hear that you plan to continue.
however, since we haven't seen a lot of activity, we should re-visit
the
option to move the components to tomahawk (btw. tomahawk-sandbox).
regards,
gerhard
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
2011/10/21 Ali Ok al...@aliok.com.tr
Hi,
Thank you Leonardo for volunteering in the release.
Yes, it would be good discussing the future.
I am still working on the project.
Re: [html5] alpha release for myfaces html5
Hi,
In my opinion as long this lib is html5 only it should not be part of
the tomahawk project
I agree, no relation with Tomahawk.
a different idea would be a small myfaces-incubator for new project-ideas
(esp. for gsoc projects).
Makes more sense to me than Tomahawk.
I think (almost) everyone is in favor of moving the project to somewhere
else, I am also ok with it.
Important thing for the project is having the ability for releases and the
jars are deployed to maven repo.
Cheers,
Ali
On Sat, Oct 22, 2011 at 11:05 AM, Mark Struberg strub...@yahoo.de wrote:
including our very own little 'attic' :)
Actually the big difference between the incubator and a mf subproject would
be the IP clearance. We really need to do this upfront before importing.
But actually I like this much more than having projects developed outside
and only later brought into our SVN - because this causes lots of paperwork
(gas grants and a IP clearance review is mandatory).
Thus a +1
LieGrue,
strub
From: Gerhard Petracek gerhard.petra...@gmail.com
To: MyFaces Development dev@myfaces.apache.org
Sent: Saturday, October 22, 2011 10:58 AM
Subject: Re: [html5] alpha release for myfaces html5
a different idea would be a small myfaces-incubator for new project-ideas
(esp. for gsoc projects).
we can release parts easily and drop them if we see that something doesn't
work for our community. if an idea works for the community, we can discuss
the correct place for it.
we might see new gsoc projects (related to myfaces) every year. imo it's
the wrong approach to just add them as new sub-project and we don't have the
resources/community to maintain them.
regards,
gerhard
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
2011/10/22 Bernd Bohmann bernd.bohm...@atanion.com
Ha, I don't think we should wait for the jsf-eg.
Hey guys they are asking for a alpha release.
In my opinion as long this lib is html5 only it should not be part of
the tomahawk project.
I don't see any problems in releasing an alpha release. But before a
beta we should decide own extension or tomahawk.
Regards
Bernd
On Sat, Oct 22, 2011 at 9:31 AM, Gerhard Petracek
gerhard.petra...@gmail.com wrote:
it's planned that jsf2.2 will get some sort of html5 support.
imo we should work together with the jsf-eg to ensure that we won't
promote
incompatible components.
regards,
gerhard
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
2011/10/22 Mark Struberg strub...@yahoo.de
+1 for moving it to tomahawk.
One big open question for me is our html5 strategy at all.
Will the html5 components provide legacy html support themselfs?
Thus a calendar component will use jQuery (or whatever) calendar when
a
non-html5 browser is detected,
or is this in the responsibility of the developer?
if (html5){
} else{
//fallback
}
?
Afaik our current html5 components 'only' support pure html5
rendering,
isn't?
LieGrue,
strub
From: Gerhard Petracek gerhard.petra...@gmail.com
To: MyFaces Development dev@myfaces.apache.org
Sent: Friday, October 21, 2011 10:22 PM
Subject: Re: [html5] alpha release for myfaces html5
@grant: +1
regards,
gerhard
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
2011/10/21 Grant Smith work.gr...@gmail.com
I must agree with Gerhard. The whole point of the sandbox is for this
very purpose. However, perhaps we should look at the sandbox more
often and
vote on components that are ready to graduate.
On Fri, Oct 21, 2011 at 1:12 PM, Gerhard Petracek
gerhard.petra...@gmail.com wrote:
hi leo,
imo such an argument doesn't justify an own sub-project. i don't
say
-1. my point is that we should discuss it (esp. because the
situation
changed).
regards,
gerhard
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
2011/10/21 Leonardo Uribe lu4...@gmail.com
Hi
The problem with move to tomahawk sandbox is those artifact can't
never be released. Do an alpha release give us the chance to know
if
the bits are good enough, get more feedback, and later decide what
to
do. The truth is some people only test some artifacts after a
release. Do it as an alpha release means ... software that has
just
been compiled and ready for its initial test inhouse. I
think
that is enough clear.
regards,
[jira] [Resolved] (MYFACES-3356) MyFaces assumes that the WAR is exploded and XHTML pages are accessible in filesystem
[ https://issues.apache.org/jira/browse/MYFACES-3356?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leonardo Uribe resolved MYFACES-3356. - Resolution: Fixed Fix Version/s: 2.1.4 2.0.10 Assignee: Leonardo Uribe Applied in 2.0.x and 2.1.x only. Thanks for the report. MyFaces assumes that the WAR is exploded and XHTML pages are accessible in filesystem - Key: MYFACES-3356 URL: https://issues.apache.org/jira/browse/MYFACES-3356 Project: MyFaces Core Issue Type: Bug Components: General Affects Versions: 1.1.9, 1.2.10, 2.0.9, 2.1.3 Reporter: Raul Kripalani Assignee: Leonardo Uribe Fix For: 2.0.10, 2.1.4 During initialization, MyFaces assumes that the Web Application has been exploded in some location in the filesystem. This assumption is caused by heavily using [ServletContext.getRealPath|http://download.oracle.com/javaee/6/api/javax/servlet/ServletContext.html#getRealPath(java.lang.String)] during initialization, as well as File objects to access xhtml pages. This makes MyFaces behave badly in containers which do not need to explode WARs, e.g. Apache Karaf with PAX Web. It also hinders OSGi-friendliness. I have pinpointed the following locations, at least: * org.apache.myfaces.config.FacesConfigValidator (line 102 in v2.1.3): when validating the from-id and to-id in the navigation rules. * org.apache.myfaces.webapp.AbstractFacesInitializer (line 320 in v2.1.3): when setting the context path for validations * org.apache.myfaces.webapp.AbstractFacesInitializer (line 133 in v2.1.3): logging It would be a good idea to refactor this code to use ServletContext.getResource, as naturally XHTML files are bound to be WAR resources anyway. This will also make MyFaces more implementation-agnostic. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3356) MyFaces assumes that the WAR is exploded and XHTML pages are accessible in filesystem
[ https://issues.apache.org/jira/browse/MYFACES-3356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13133438#comment-13133438 ] Raul Kripalani commented on MYFACES-3356: - Hi Leonardo, Thanks for the quick fix. Did this issue only impact the validation of navigation rules? Or did it also prevent the rules from actually being parsed, loaded and applied to requests? Thanks, Raúl. MyFaces assumes that the WAR is exploded and XHTML pages are accessible in filesystem - Key: MYFACES-3356 URL: https://issues.apache.org/jira/browse/MYFACES-3356 Project: MyFaces Core Issue Type: Bug Components: General Affects Versions: 1.1.9, 1.2.10, 2.0.9, 2.1.3 Reporter: Raul Kripalani Assignee: Leonardo Uribe Fix For: 2.0.10, 2.1.4 During initialization, MyFaces assumes that the Web Application has been exploded in some location in the filesystem. This assumption is caused by heavily using [ServletContext.getRealPath|http://download.oracle.com/javaee/6/api/javax/servlet/ServletContext.html#getRealPath(java.lang.String)] during initialization, as well as File objects to access xhtml pages. This makes MyFaces behave badly in containers which do not need to explode WARs, e.g. Apache Karaf with PAX Web. It also hinders OSGi-friendliness. I have pinpointed the following locations, at least: * org.apache.myfaces.config.FacesConfigValidator (line 102 in v2.1.3): when validating the from-id and to-id in the navigation rules. * org.apache.myfaces.webapp.AbstractFacesInitializer (line 320 in v2.1.3): when setting the context path for validations * org.apache.myfaces.webapp.AbstractFacesInitializer (line 133 in v2.1.3): logging It would be a good idea to refactor this code to use ServletContext.getResource, as naturally XHTML files are bound to be WAR resources anyway. This will also make MyFaces more implementation-agnostic. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (MYFACES-3354) NullPointerException on jetty 6.1.5 with faces-redirect=true action result
[
https://issues.apache.org/jira/browse/MYFACES-3354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leonardo Uribe resolved MYFACES-3354.
-
Resolution: Fixed
Fix Version/s: 2.1.4
2.0.10
Assignee: Leonardo Uribe
I checked it and it sounds reasonable do not call setValue(null).
NullPointerException on jetty 6.1.5 with faces-redirect=true action result
--
Key: MYFACES-3354
URL: https://issues.apache.org/jira/browse/MYFACES-3354
Project: MyFaces Core
Issue Type: Bug
Components: General
Affects Versions: 2.0.9
Environment: Ubuntu 11, jetty 6.1.5, MyFaces Core 2.0.9, Primefaces
3.0M3
Reporter: Joe Rossi
Assignee: Leonardo Uribe
Priority: Minor
Fix For: 2.0.10, 2.1.4
XHTML file:
p:commandButton id=saveAndGo
value=Save and Go
action=#{launchBean.saveAction}
ajax=false
/p:commandButton
Backing Bean method:
public String saveAction()
throws Exception
{
ProcessInstance process = _createProcessInstance();
return
/home/assistants/assistant?faces-redirect=trueprocessInstanceId=
+ process.getId();
}
Invoking the command button produces the following stack trace, causing part
of the next page to terminate rendering:
java.lang.NullPointerException
at java.io.Writer.write(Writer.java:140)
at org.mortbay.jetty.NCSARequestLog.log(NCSARequestLog.java:319)
at
org.mortbay.jetty.handler.RequestLogHandler.handle(RequestLogHandler.java:51)
at
org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:712)
at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:405)
at
org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:211)
at
org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114)
at
org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139)
at org.mortbay.jetty.Server.handle(Server.java:313)
at
org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:506)
at
org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:830)
at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:514)
at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:211)
at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:381)
at
org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:396)
at
org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:442)
The section of jetty code that throws the NullPointerException is as follows
(offending line highlighted):
if (_logCookies)
{
Cookie[] cookies = request.getCookies();
if (cookies == null || cookies.length == 0)
_writer.write( -);
else
{
_writer.write( \);
for (int i = 0; i cookies.length; i++)
{
if (i != 0)
_writer.write(';');
_writer.write(cookies[i].getName());
_writer.write('=');
_writer.write(cookies[i].getValue()); // --
NullPointerException
}
_writer.write(\);
}
}
Caused because the cookie oam.Flash.REDIRECT has a null value.
Looking at the source code for Myfaces Core -
org.apache.myfaces.shared.context.flash.FlashImpl, the function
_restoreRedirectValue has the following code which is used to remove the
cookie:
if (cookie != null)
{
// the cookie exists means there was a redirect, regardless
of the value
externalContext.getRequestMap().put(
FLASH_PREVIOUS_REQUEST_REDIRECT, Boolean.TRUE);
// A redirect happened, so it is safe to remove the cookie,
setting
// the maxAge to 0 seconds. The effect is we passed
FLASH_REDIRECT param
// to this request object
cookie.setMaxAge(0);
cookie.setPath(_getCookiePath(externalContext));
cookie.setValue(null);
httpResponse.addCookie(cookie);
}
My understanding is that a cookie can be removed by setMaxAge(0). Hence the
setValue(null) is redundant. Removing this should fix the issue.
--
This message is automatically generated by JIRA.
If
[jira] [Created] (MYFACES-3367) Detect when to wpdate head or body target when content has been updated dynamically
Detect when to wpdate head or body target when content has been updated
dynamically
---
Key: MYFACES-3367
URL: https://issues.apache.org/jira/browse/MYFACES-3367
Project: MyFaces Core
Issue Type: Improvement
Components: JSR-314
Reporter: Leonardo Uribe
Assignee: Leonardo Uribe
Related to topic sent on jsr344-experts list:
[jsr344-experts] Facelet page with dynamic content and update ajax content does
not work as user expects
Now take a look at this example:
include.xhtml
h:commandLink ...
f:ajax render=content/
/h:commandLink
...
f:subview id=content
ui:include src=#{testManagedBean.page}/
/f:subview
page1.xhtml
ui:composition
xmlns:h=http://java.sun.com/jsf/html;
xmlns:f=http://java.sun.com/jsf/core;
xmlns:ui=http://java.sun.com/jsf/facelets;
h:outputText id=component1 value=Page 1/
!-- ... more components ... --
/ui:composition
page2.xhtml
ui:composition
xmlns:h=http://java.sun.com/jsf/html;
xmlns:f=http://java.sun.com/jsf/core;
xmlns:ui=http://java.sun.com/jsf/facelets;
h:outputStylesheet ... /
h:outputText id=component2 value=Page 2/
!-- ... more components ... --
/ui:composition
Here the problem is if the dynamic content changes and add a resource under
head target (h:outputStylesheet does that), shouldn't be added a section
on the ajax payload to update the head section? In theory yes, because
this breaks encapsulation principle. If the user says render all inside
content if the head section changes it is responsability of the framework
(in this case PartialViewContext) to detect that an send the correct
payload, right?. Here we have two options:
a. Keep track of the resources rendered and save that on the state, then use
that information to check if the head should be rendered.
b. Use PostAddToViewEvent to check when a change on the component tree has
triggered a change on the head.
Option b. save some bytes on the state but it could cause render head
section more than necessary (for example a dynamic change but the head
has already rendered the resource, so it is not necessary). Option a.
impose that you need a way to check if the head was changed, and
require changes on the spec.
I'll solve this problem adding a web config param:
org.apache.myfaces.STRICT_JSF_2_REFRESH_TARGET_AJAX
on MyFaces and doing some
changes on the algorithm, adding a flag to indicate if a view is being built
by first time.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (MYFACES-3367) Detect when to wpdate head or body target when content has been updated dynamically
[
https://issues.apache.org/jira/browse/MYFACES-3367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leonardo Uribe updated MYFACES-3367:
Status: Patch Available (was: Open)
Detect when to wpdate head or body target when content has been updated
dynamically
---
Key: MYFACES-3367
URL: https://issues.apache.org/jira/browse/MYFACES-3367
Project: MyFaces Core
Issue Type: Improvement
Components: JSR-314
Reporter: Leonardo Uribe
Assignee: Leonardo Uribe
Attachments: MYFACES-3367-1.patch
Related to topic sent on jsr344-experts list:
[jsr344-experts] Facelet page with dynamic content and update ajax content
does not work as user expects
Now take a look at this example:
include.xhtml
h:commandLink ...
f:ajax render=content/
/h:commandLink
...
f:subview id=content
ui:include src=#{testManagedBean.page}/
/f:subview
page1.xhtml
ui:composition
xmlns:h=http://java.sun.com/jsf/html;
xmlns:f=http://java.sun.com/jsf/core;
xmlns:ui=http://java.sun.com/jsf/facelets;
h:outputText id=component1 value=Page 1/
!-- ... more components ... --
/ui:composition
page2.xhtml
ui:composition
xmlns:h=http://java.sun.com/jsf/html;
xmlns:f=http://java.sun.com/jsf/core;
xmlns:ui=http://java.sun.com/jsf/facelets;
h:outputStylesheet ... /
h:outputText id=component2 value=Page 2/
!-- ... more components ... --
/ui:composition
Here the problem is if the dynamic content changes and add a resource under
head target (h:outputStylesheet does that), shouldn't be added a section
on the ajax payload to update the head section? In theory yes, because
this breaks encapsulation principle. If the user says render all inside
content if the head section changes it is responsability of the framework
(in this case PartialViewContext) to detect that an send the correct
payload, right?. Here we have two options:
a. Keep track of the resources rendered and save that on the state, then use
that information to check if the head should be rendered.
b. Use PostAddToViewEvent to check when a change on the component tree has
triggered a change on the head.
Option b. save some bytes on the state but it could cause render head
section more than necessary (for example a dynamic change but the head
has already rendered the resource, so it is not necessary). Option a.
impose that you need a way to check if the head was changed, and
require changes on the spec.
I'll solve this problem adding a web config param:
org.apache.myfaces.STRICT_JSF_2_REFRESH_TARGET_AJAX
on MyFaces and doing some
changes on the algorithm, adding a flag to indicate if a view is being built
by first time.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3367) Detect when to wpdate head or body target when content has been updated dynamically
[
https://issues.apache.org/jira/browse/MYFACES-3367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13133442#comment-13133442
]
Leonardo Uribe commented on MYFACES-3367:
-
If no objection I'll commit this code soon.
Detect when to wpdate head or body target when content has been updated
dynamically
---
Key: MYFACES-3367
URL: https://issues.apache.org/jira/browse/MYFACES-3367
Project: MyFaces Core
Issue Type: Improvement
Components: JSR-314
Reporter: Leonardo Uribe
Assignee: Leonardo Uribe
Attachments: MYFACES-3367-1.patch
Related to topic sent on jsr344-experts list:
[jsr344-experts] Facelet page with dynamic content and update ajax content
does not work as user expects
Now take a look at this example:
include.xhtml
h:commandLink ...
f:ajax render=content/
/h:commandLink
...
f:subview id=content
ui:include src=#{testManagedBean.page}/
/f:subview
page1.xhtml
ui:composition
xmlns:h=http://java.sun.com/jsf/html;
xmlns:f=http://java.sun.com/jsf/core;
xmlns:ui=http://java.sun.com/jsf/facelets;
h:outputText id=component1 value=Page 1/
!-- ... more components ... --
/ui:composition
page2.xhtml
ui:composition
xmlns:h=http://java.sun.com/jsf/html;
xmlns:f=http://java.sun.com/jsf/core;
xmlns:ui=http://java.sun.com/jsf/facelets;
h:outputStylesheet ... /
h:outputText id=component2 value=Page 2/
!-- ... more components ... --
/ui:composition
Here the problem is if the dynamic content changes and add a resource under
head target (h:outputStylesheet does that), shouldn't be added a section
on the ajax payload to update the head section? In theory yes, because
this breaks encapsulation principle. If the user says render all inside
content if the head section changes it is responsability of the framework
(in this case PartialViewContext) to detect that an send the correct
payload, right?. Here we have two options:
a. Keep track of the resources rendered and save that on the state, then use
that information to check if the head should be rendered.
b. Use PostAddToViewEvent to check when a change on the component tree has
triggered a change on the head.
Option b. save some bytes on the state but it could cause render head
section more than necessary (for example a dynamic change but the head
has already rendered the resource, so it is not necessary). Option a.
impose that you need a way to check if the head was changed, and
require changes on the spec.
I'll solve this problem adding a web config param:
org.apache.myfaces.STRICT_JSF_2_REFRESH_TARGET_AJAX
on MyFaces and doing some
changes on the algorithm, adding a flag to indicate if a view is being built
by first time.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Time for a Tobago 1.5.0-beta2?
Hi, Yes, I think it's time for a New release Gruß Udo Am 22.10.2011 um 08:50 schrieb Bernd Bohmann bernd.bohm...@atanion.com: Hello, I think most of the stuff in Tobago 1.5.0 is stable now. It's time for an other beta release. If no objections i will start with the release soon. Regards Bernd
[DISCUSS] how to get rid of tons of duplicated code
Hi! While working on the mafyces-commons cleanup I figured that we have tons of duplicated code spread over MyFaces. As an example I like to mention myfaces-commons-resourcehandler. There are 43 classes in total, and 35 of them are just 1:1 copied from other projects to provide resource management, zip, etc. For me this is an absolute no-go. Those classes have neither tests nor any documentation where they got forked from. Nor will any bug which gets fixed in another module make it's way over to all the other projects containing that very forked code. That's just ... unbelievable unmaintainable. There are 2 different ways to solve this (depending on the problem): A.) drop the functionality and provide a generalized solution. The GZIP of myfaces-commons-resourcehandleris an obvious example: We now copy this code over the 4th time or even more. Instead of doing this, we should rather do it in the classic unix fashion: do one thing, but do it well. Which means I'd rather see all the GZIP stuff factored out into an own mf-commons module as a Servlet Filter. This can then get applied to what ever other mechanism you like. This could also (commonly) cover cases like detecting http UserAgents which are not able to handle zipped resources, etc. That way we could provide this logic ONCE and have complete freedom over the configuration. B.) code reusable components once and use them in other projects (ev via shading it in). ClassLoaderResourceLoader would be a perfect candidate! I grepped through only the few pits which I have checked out locally and found this class 7 SEVEN times! I just can't believe that we can't move this stuff to a shared modul... Same for FacesServletMapping. 6 times copied around, WebConfigProviderFactory 5 times, ... There are whole packages with 10++ classes which got copied 1:1! I really could cry seeing this :( What can we do to solve this? Theoretically myfaces-shared should contain this stuff. This is exactly what it is for! Historically there have been some hand forged tweeks and ugly hacks, but nowadays we have the maven-shade-plugin to make our live easier. So the suggestion is: 1.) cleanup myfaces-shared. mf-shared has almost no checkstyle rules applied. 2.) add unit tests for myfaces-shared. Currently there are not many... 3.) move the shared code parts back to myfaces-shared and add unit tests. 4.) import myfaces-shared via maven dependency and use minimizeJar and relocations to package the stuff [+1] fine go ahead (ideally: yes, what parts can I help with?) [0] dont care [-1] wont work because ... I've attached a file which contains all Classes which name exists multiple times in MyFaces. The number is the cound how often they exist in MyFaces. I excluded current20. Please note that classes with the same name do not necessarily have the same content - but quite a lot actually do have! (scroll to the bottom of the file ...) LieGrue, strub 2 AbstractAnnotationsViewControllerManager.java 2 AbstractBuffer.java 2 AbstractClientBehaviorTestCase.java 2 AbstractCompactScheduleRenderer.java 2 AbstractComponentDemo.java 2 AbstractComponentVariantDemo.java 2 AbstractCreditCardValidator.java 2 AbstractDiv.java 2 AbstractDocument.java 2 AbstractDocumentBody.java 2 AbstractDocumentRenderer.java 2 AbstractEntity.java 2 AbstractEqualValidator.java 2 AbstractHtmlAccordionPanel.java 2 AbstractHtmlCollapsiblePanel.java 2 AbstractHtmlColumns.java 2 AbstractHtmlCommandJSCookMenu.java 2 AbstractHtmlDataScroller.java 2 AbstractHtmlFocus.java 2 AbstractHtmlInputCalendar.java 2 AbstractHtmlInputCalendarTag.java 2 AbstractHtmlInputDateTag.java 2 AbstractHtmlInputFileUpload.java 2 AbstractHtmlInputTextHelp.java 2 AbstractHtmlMessage.java 2 AbstractHtmlMessages.java 2 AbstractHtmlPanelGroup.java 2 AbstractHtmlPanelLayout.java 2 AbstractHtmlPanelNavigationMenu.java 2 AbstractHtmlPanelTab.java 2 AbstractHtmlPanelTabbedPane.java 2 AbstractHtmlPopup.java 2 AbstractHtmlSelectManyCheckbox.java 2 AbstractHtmlSelectManyListbox.java 2 AbstractHtmlSelectManyMenu.java 2 AbstractHtmlSelectManyPicklist.java 2 AbstractHtmlSimpleColumn.java 2 AbstractHtmlSwapImage.java 2 AbstractHtmlTag.java 2 AbstractHtmlTree.java 2 AbstractHtmlUnitTestCase.java 2 AbstractInputSuggestAjax.java 2 AbstractJmockJsfTestCase.java 2 AbstractJsfConfigurableMockTestCase.java 2 AbstractOddNumberValidator.java 2 AbstractPasswordStrengthComponent.java 2 AbstractRegExprValidator.java 2 AbstractRepository.java 2 AbstractSayHello.java 2 AbstractScheduleRenderer.java 2 AbstractSelectOneRow.java 2 AbstractStateUtilsTest.java 2 AbstractSuggestAjax.java 2 AbstractSuggestAjaxTag.java 2 AbstractTagBean.java 2 AbstractToggleGroup.java 2 AbstractTogglePanel.java 2 AbstractTreeTag.java 2 AbstractUINavigationMenuItem.java 2
