[jira] [Commented] (MYFACES-3099) Update archetype versions
[ https://issues.apache.org/jira/browse/MYFACES-3099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13017826#comment-13017826 ] Jakob Korherr commented on MYFACES-3099: since MyFaces core 2.0.5 is already synct to maven central, we can now even update to 2.0.5! Update archetype versions - Key: MYFACES-3099 URL: https://issues.apache.org/jira/browse/MYFACES-3099 Project: MyFaces Core Issue Type: Task Components: Archetype Reporter: Jakob Korherr Assignee: Jakob Korherr After EXTCDI-90 is fixed, we can do another archetypes release. However, we should update them to the newest versions first. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (EXTCDI-162) re-visit implementation of custom project stages.
[
https://issues.apache.org/jira/browse/EXTCDI-162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13017829#comment-13017829
]
Jakob Korherr commented on EXTCDI-162:
--
+1 on automatically vetoing custom project stages!
extends ProjectStage means no CDI bean. should be easy to understand for
everyone!
re-visit implementation of custom project stages.
-
Key: EXTCDI-162
URL: https://issues.apache.org/jira/browse/EXTCDI-162
Project: MyFaces CODI
Issue Type: Task
Components: Core
Affects Versions: 0.9.4
Reporter: Gerhard Petracek
if users forget @Typed(), they would see an AmbiguousResolutionException.
cdi-qualifiers aren't supported (in case of project-stages). so @Typed() is
required all the time.
currently valid example:
public class CustomProjectStage implements ProjectStageHolder
{
@Typed()
public static final class Debugging extends ProjectStage
{
private static final long serialVersionUID = -8626602281649294170L;
}
public static final Debugging Debugging = new Debugging();
}
since there is no support for cdi-qualifiers, we could veto those classes.
that would allow to skip the @Typed() but the rest would be the same (because
codi will still find them).
pro: users don't have to use @Typed() explicitly (and they won't see the
AmbiguousResolutionException, if they forget using @Typed())
con: it isn't std. cdi - but adding @Typed() even though it isn't needed
wouldn't harm.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (EXTCDI-162) re-visit implementation of custom project stages.
[
https://issues.apache.org/jira/browse/EXTCDI-162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13012158#comment-13012158
]
Gerhard Petracek edited comment on EXTCDI-162 at 4/9/11 10:24 AM:
--
imo users don't directly think - i create a custom project-stage - ah right
everything is a bean and codi has a producer for the project stage - i've to
use @Typed - ask 100 users - and maybe 1 will think that way. the problem is
- as soon as you create a custom implementation and you forget it - you get the
exception (just because we have an internal producer which already uses the
default qualifier).
@a: it is - because it's easier for users and you need @Typed() in all cases -
you never have the choice to do something different
@b: we already have an observer in an extension - the overhead would be only
one method call (and not a whole extension)
@c: no - because they can use @Typed() if they are aware of it (without
breaking something)
@Veto or @NoBean or maybe even better @Ignored would be fine for me as well -
esp. @Ignored would be more expressive than @Typed()
imo @Ignored would be a nice feature anyway. we already had this topic in an
irc discussion
was (Author: gpetracek):
imo users don't directly think - i create a custom project-stage - ah right
everything is a bean and codi has a producer for the project stage - i've to
use @Typed - ask 100 users - and maybe 1 will think that way. the problem is
- as soon as you create a custom implementation and you forget it - you get the
exception (just because we have an internal producer which already uses the
default qualifier).
@a: it is - because it's easier for users and you need @Typed() in all cases -
you never have the choice to do something different
@b: we already have an observer in an extension - the overhead would be only
one method call (and not a whole extension)
@c: no - because they can use @Typed() if they are aware of it (without
breaking something)
@Veto or @NoBean or maybe even better @Ignored would be find for me as well -
esp. @Ignored would be more expressive than @Typed()
imo @Ignored would be a nice feature anyway. we already had this topic in an
irc discussion
re-visit implementation of custom project stages.
-
Key: EXTCDI-162
URL: https://issues.apache.org/jira/browse/EXTCDI-162
Project: MyFaces CODI
Issue Type: Task
Components: Core
Affects Versions: 0.9.4
Reporter: Gerhard Petracek
if users forget @Typed(), they would see an AmbiguousResolutionException.
cdi-qualifiers aren't supported (in case of project-stages). so @Typed() is
required all the time.
currently valid example:
public class CustomProjectStage implements ProjectStageHolder
{
@Typed()
public static final class Debugging extends ProjectStage
{
private static final long serialVersionUID = -8626602281649294170L;
}
public static final Debugging Debugging = new Debugging();
}
since there is no support for cdi-qualifiers, we could veto those classes.
that would allow to skip the @Typed() but the rest would be the same (because
codi will still find them).
pro: users don't have to use @Typed() explicitly (and they won't see the
AmbiguousResolutionException, if they forget using @Typed())
con: it isn't std. cdi - but adding @Typed() even though it isn't needed
wouldn't harm.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (EXTCDI-162) re-visit implementation of custom project stages.
[
https://issues.apache.org/jira/browse/EXTCDI-162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13017830#comment-13017830
]
Gerhard Petracek commented on EXTCDI-162:
-
currently we have
4 +1 for an autom. veto (+ logging)
1 +1 for a new explicit annotation as alternative to @Typed() btw. keep it as
it is
i'll commit the fix (preferred by the majority) by the end of next week.
if someone feels that this result isn't representative, please feel free to
start a discussion on the dev-list.
re-visit implementation of custom project stages.
-
Key: EXTCDI-162
URL: https://issues.apache.org/jira/browse/EXTCDI-162
Project: MyFaces CODI
Issue Type: Task
Components: Core
Affects Versions: 0.9.4
Reporter: Gerhard Petracek
if users forget @Typed(), they would see an AmbiguousResolutionException.
cdi-qualifiers aren't supported (in case of project-stages). so @Typed() is
required all the time.
currently valid example:
public class CustomProjectStage implements ProjectStageHolder
{
@Typed()
public static final class Debugging extends ProjectStage
{
private static final long serialVersionUID = -8626602281649294170L;
}
public static final Debugging Debugging = new Debugging();
}
since there is no support for cdi-qualifiers, we could veto those classes.
that would allow to skip the @Typed() but the rest would be the same (because
codi will still find them).
pro: users don't have to use @Typed() explicitly (and they won't see the
AmbiguousResolutionException, if they forget using @Typed())
con: it isn't std. cdi - but adding @Typed() even though it isn't needed
wouldn't harm.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
Who is next week in Vienna (CONFESS)?
Hello, I'm next week in Vienna from Monday afternoon till Friday. Regards Bernd
Re: Who is next week in Vienna (CONFESS)?
Hi, Me too. See you there! Regards, Jakob 2011/4/9 Bernd Bohmann bernd.bohm...@atanion.com: Hello, I'm next week in Vienna from Monday afternoon till Friday. Regards Bernd -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at
Re: Who is next week in Vienna (CONFESS)?
yes - see you there! regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2011/4/9 Jakob Korherr jakob.korh...@gmail.com Hi, Me too. See you there! Regards, Jakob 2011/4/9 Bernd Bohmann bernd.bohm...@atanion.com: Hello, I'm next week in Vienna from Monday afternoon till Friday. Regards Bernd -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at
Re: Who is next week in Vienna (CONFESS)?
I'll be there the same days: Monday through Friday. Sent from my iPhone http://www.jsfcentral.com http://www.Virtua.com On Apr 9, 2011, at 7:30 AM, Bernd Bohmann bernd.bohm...@atanion.com wrote: Hello, I'm next week in Vienna from Monday afternoon till Friday. Regards Bernd
Re: Who is next week in Vienna (CONFESS)?
I'll be there too. Also talked with Aslak, he will arrive Monday afternoon. LieGrue, strub --- On Sat, 4/9/11, Kito Mann kito.m...@virtua.com wrote: From: Kito Mann kito.m...@virtua.com Subject: Re: Who is next week in Vienna (CONFESS)? To: MyFaces Development dev@myfaces.apache.org Date: Saturday, April 9, 2011, 11:58 AM I'll be there the same days: Monday through Friday. Sent from my iPhone http://www.jsfcentral.com http://www.Virtua.com On Apr 9, 2011, at 7:30 AM, Bernd Bohmann bernd.bohm...@atanion.com wrote: Hello, I'm next week in Vienna from Monday afternoon till Friday. Regards Bernd
Re: Who is next week in Vienna (CONFESS)?
Am 09.04.11 13:30, schrieb Bernd Bohmann: Hello, I'm next week in Vienna from Monday afternoon till Friday. Regards Bernd I will be there from tuesday til thursday. Werner
[jira] [Created] (TOMAHAWK-1577) t:inputCalendar disabled status is not working with f:ajax
t:inputCalendar disabled status is not working with f:ajax
--
Key: TOMAHAWK-1577
URL: https://issues.apache.org/jira/browse/TOMAHAWK-1577
Project: MyFaces Tomahawk
Issue Type: Bug
Components: AJAX Form Components, Calendar
Affects Versions: 1.1.11-SNAPSHOT
Environment: Win XP, JDK 1.6.0.20, Tomcat 6.0.29, MyFaces 2.0.6 -
Snapshots (built from trunk of 09-04-2011), Tomahawk20-1.1.11 Snapshot (built
from trunk of 09-04-2011)
Reporter: Oliver Bayer
I'm using a t:selectBooleanCheckbox with ajax functionality and the
t:inputCalendar component. The calendar should be enabled if the checkbox is
checked and vice versa. By default the checkbox is unchecked and the calendar
disabled. The disabled calendar does not show the (disabled) button for the
popup at all. If the checkbox is checked the calendar stays disabled.
See demo source code below:
t:selectBooleanCheckbox id=aCheckbox value=#{mybean.aCheckbox}
f:ajax event=valueChange render=aDate /
/t:selectBooleanCheckbox
t:inputCalendar id=aDate
monthYearRowClass=yearMonthHeader
weekRowClass=weekHeader
popupButtonStyleClass=standard_bold
currentDayCellClass=currentDayCell
value=#{mybean.aDate}
renderAsPopup=true
popupTodayString=today
popupDateFormat=dd.MM.
popupWeekString=week
forceId=true
disabled=#{mybean.aCheckbox == false} /
Maybe this ajax issue is related to this ticket: TOMAHAWK-1574
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (MYFACES-3106) Resources not loaded when using a dynamic ui:inlclude and rendered via ajax
Resources not loaded when using a dynamic ui:inlclude and rendered via ajax
---
Key: MYFACES-3106
URL: https://issues.apache.org/jira/browse/MYFACES-3106
Project: MyFaces Core
Issue Type: Bug
Affects Versions: 2.0.4
Environment: Windows 7, JBoss AS 6, Richfaces 4.0.0 Final, JSF2
Reporter: Luciano Deriu
I'm migrating my project from JSF 1.2 to JSF2 and I was using a ui:include
src=#{guiMB.viewID} / tag wrapped in a a4j:outputPanel tag (from
RichFaces) and rendering the a4j:outputPanel via ajax. However in JSF2 this
doesn't load the resources for the page i'm including.
So anything i include dynamically like this doesn't have any of the styling or
javascript that should be loaded with it.
I have created a test project which demonstrates the issue so i'll attach for
you to replicate the issue.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Who is next week in Vienna (CONFESS)?
Hi I'll be happy to see you all guys! I'll be there. Leonardo 2011/4/9 Werner Punz werner.p...@gmail.com Am 09.04.11 13:30, schrieb Bernd Bohmann: Hello, I'm next week in Vienna from Monday afternoon till Friday. Regards Bernd I will be there from tuesday til thursday. Werner
Re: Who is next week in Vienna (CONFESS)?
***Unfortunately, I could not get EU visa in time. On Sat, Apr 9, 2011 at 1:20 PM, Hazem Saleh haz...@apache.org wrote: I have no luck as I will not be able to see you guys this year. Unfortunately, I could get EU visa in time. Wish to see you all next year in Vienna. On Sat, Apr 9, 2011 at 1:17 PM, Leonardo Uribe lu4...@gmail.com wrote: Hi I'll be happy to see you all guys! I'll be there. Leonardo 2011/4/9 Werner Punz werner.p...@gmail.com Am 09.04.11 13:30, schrieb Bernd Bohmann: Hello, I'm next week in Vienna from Monday afternoon till Friday. Regards Bernd I will be there from tuesday til thursday. Werner -- Hazem Ahmed Saleh Ahmed Author of (The Definitive Guide to Apache MyFaces and Facelets): http://www.amazon.com/Definitive-Guide-Apache-MyFaces-Facelets/dp/1590597370 http://www.amazon.com/-/e/B002M052KY Visualize and share your social networks 2D and 3D: http://www.mapmysocial.com -- Hazem Ahmed Saleh Ahmed Author of (The Definitive Guide to Apache MyFaces and Facelets): http://www.amazon.com/Definitive-Guide-Apache-MyFaces-Facelets/dp/1590597370 http://www.amazon.com/-/e/B002M052KY Visualize and share your social networks 2D and 3D: http://www.mapmysocial.com
