Re: [VOTE] Release of MyFaces Core 2.2.5
+1 Regards, Martin Am 18.09.2014 13:10 schrieb Werner Punz werner.p...@gmail.com: +1 Am 16.09.14 20:53, schrieb Leonardo Uribe: +1 2014-09-16 13:53 GMT-05:00 Leonardo Uribe lu4...@apache.org: Hi, I was running the needed tasks to get the 2.2.5 release of Apache MyFaces core out. The artifacts passed the TCK test of Feb 2013 (jsftck-2.2_26-Feb-2013.zip). Please note that this vote concerns all of the following parts: 1. Maven artifact group org.apache.myfaces.shared v4.2.4 [1] 2. Maven artifact group org.apache.myfaces.core v2.2.5 [1] The artifacts were deployed on nexus repo [1] and to my private Apache account [3] for binary and source packages. The release notes could be found at [4]. Also the clirr test does not show binary incompatibilities with myfaces-api. Please take a look at the 2.2.5 artifacts and vote! Please note: This vote is majority approval with a minimum of three +1 votes (see [3]). [ ] +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, Leonardo Uribe [1] https://repository.apache.org/content/repositories/ orgapachemyfaces-1031/org/apache/myfaces/ [2] http://www.apache.org/foundation/voting.html#ReleaseVotes [3] http://people.apache.org/~lu4242/myfaces225binsrc [4] https://issues.apache.org/jira/secure/ReleaseNote.jspa? projectId=10600version=12327190
Re: Result (Was: [VOTE] release of MyFaces Core 2.2.2)
+1 for the release, Best regards, Martin — Sent from Mailbox for iPhone On Thu, Mar 20, 2014 at 7:51 PM, Leonardo Uribe lu4...@gmail.com wrote: Hi Ouch, I didn't noticed that Michael is committer, not PMC. I have already released the maven repo, so there is no way back. I'll appreciate if some PMC can check the artifacts, and give the extra vote. After all, this is a quick fix release, there is no extra features added, so these artifacts are pretty much the same as 2.2.1. regards, Leonardo Uribe 2014-03-20 13:45 GMT-05:00 Gerhard Petracek gpetra...@apache.org: hi leo, we don't have 3 binding votes (see [1]). regards, gerhard [1] https://www.apache.org/foundation/voting.html#ReleaseVotes 2014-03-20 19:20 GMT+01:00 Leonardo Uribe lu4...@gmail.com: Hi Thanks to all people who vote We have 4 +1 Michael Kurz Werner Punz Thomas Andraschko Leonardo Uribe so we can continue with the necessary steps to release MyFaces Core 2.2.2 regards, Leonardo Uribe
Re: Making Tomahawk Calendar more WCAG (accessibility) compliant
Hi Werner,
Now I am not sure which is better. Tag soup or attribute soup ;)
Best regards,
Martin
Am 20.12.2012 um 08:37 schrieb Werner Punz werner.p...@gmail.com:
I am not sure if it really makes sense to offload attributes into separate
tags unless they are common to more than one component.
Aka styleClass and style yes, currentDayCellClass etc... definitely not it
does not make sense to introduce a tag where an attribute suffices, otherwise
we will end up with something like the Maven syntax which is a tag soup par
excellence.
So I am not opposed to the idea (probably as Leo said, could be done
generically with a tagHandler)
But I dont see a usecase for our WCAG extensions here, which are calendar
specific.
Werner
Am 19.12.12 22:01, schrieb Leonardo Uribe:
Hi
MM I had the idea once that one could have an extra embedded style tag
which
MM goes with each one of the extended components. So you could
embed this tag,
MM and set the style attributes there, and the main component would
stay clean.
To be more specific, the idea could be move the code from this:
t:inputCalendar id=secondOne
monthYearRowClass=yearMonthHeader weekRowClass=weekHeader
popupButtonStyleClass=standard_bold
currentDayCellClass=currentDayCell
value=#{calendarBean.secondDate} renderAsPopup=true
popupTodayString=#{example_messages['popup_today_string']}
popupDateFormat=MM/dd/
popupWeekString=#{example_messages['popup_week_string']}
helpText=MM/DD//
to something like this?
t:inputCalendar id=secondOne
value=#{calendarBean.secondDate} renderAsPopup=true
popupDateFormat=MM/dd/
helpText=MM/DD/
t:styleAttributes monthYearRowClass=yearMonthHeader
weekRowClass=weekHeader
popupButtonStyleClass=standard_bold
currentDayCellClass=currentDayCell
popupTodayString=#{example_messages['popup_today_string']}
popupWeekString=#{example_messages['popup_week_string']} /
/t:inputCalendar
Or maybe this:
t:inputCalendar id=secondOne
value=#{calendarBean.secondDate} renderAsPopup=true
popupDateFormat=MM/dd/
helpText=MM/DD/
t:styleAttributes
value=#{styleAppScopeBean.calendarPropertyMap}/
/t:inputCalendar
And move the styling attribute from the markup to an application scope
bean like
the proposal in JSF 2.2 related to f:attributes tag?.
I think with just a facelet TagHandler it is possible to do it. Maybe
have a generic style tag and
a special style tag for calendar component, because calendar has a lot
of related attributes.
regards,
Leonardo Uribe
2012/12/19 Cagatay Civici cagatay.civ...@gmail.com:
Hi,
I decided to go with a javascript bundle in PF as calendar is a special
component in terms or localization and internationalization.
http://code.google.com/p/primefaces/wiki/PrimeFacesLocales
Regards,
Cagatay Civici
PrimeFaces Lead
Prime Teknoloji
www.prime.com.tr
On 19 Ara 2012, at 22:04, Martin Marinschek mmarinsc...@apache.org wrote:
Hi guys,
Wdyt?
best regards,
Martin
On Wed, Dec 19, 2012 at 4:55 PM, Grant Smith gr...@marathonpm.com wrote:
+1
The benefits outweigh the overcrowding of attributes, in my opinion.
On Wed, Dec 19, 2012 at 6:47 AM, Leonardo Uribe lu4...@gmail.com wrote:
+1
I think the proposal looks good, the names used in the properties are ok,
and
there is certainty that the changes are useful.
regards,
Leonardo
2012/12/19 Werner Punz werner.p...@gmail.com:
Ok just to be more precise, I have integrated the changes now locally,
but I
am not committing them yet, because it would mean to introduce another
set
of attributes to the Calendar yet.
I just want the opinion whether we should do it.
Just to give s small description, the attributes would add alt texts
to the popup calendar and default alt texts are set anyway, the inline
calendar does not have images hence no alt is needed and possible.
The downside of this is that we add another set of attributes:
popupLeftArrowAlt
, popupRightArrowAlt
, popupMonthArrowAlt
, popupYearArrowAlt
, popupCloseButtonAlt
, calendarIconAlt
, popupWeekOfYearTitle
, popupWeekOfDateTitle
which is a huge set of new attributes to the already attribute
overloaded
calendar.
So what is your opinion guys, shall we add it or not.
I favor for a +1 here, since accessability is a big plus
and the new attributes are optional in their usage.
Werner
Am 19.12.12 11:23, schrieb Werner Punz:
Mhh shall we integrate this?
I personally think it would make sense with some name changes.
Werner
Am 17.12.12 18:54, schrieb Jon Bionda:
Sorry
Re: [core][proposal] JSF View Pooling (going beyond JSF Stateless Mode)
Hi Leo. what are you trying to gain from this? Here the criticism from the link you provided: Criticism Some publications do not recommend using object pooling with certain languages, such as Java, especially for objects that only use memory and hold no external resources.[2]http://en.wikipedia.org/wiki/Object_pool_pattern#cite_note-2Opponents usually say that object allocation is relatively fast in modern languages with garbage collectorshttp://en.wikipedia.org/wiki/Garbage_collection_%28computer_science%29; while the operator new needs only ten instructions, the classic new - deletepair found in pooling designs requires hundreds of them as it does more complex work. Also, most garbage collectors scan live object references, and not the memory that these objects use for their content. This means that any number of dead objects without references can be discarded with little cost. In contrast, keeping a large number of live but unused objects increases the duration of garbage collection.[1]http://en.wikipedia.org/wiki/Object_pool_pattern#cite_note-urban-1In some cases, programs that use garbage collection instead of directly managing memory may run faster. what do you say about this? best regards, Martin On Mon, Dec 17, 2012 at 5:23 PM, Leonardo Uribe lu4...@gmail.com wrote: recover -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: Making Tomahawk Calendar more WCAG (accessibility) compliant
Hi guys, I had the idea once that one could have an extra embedded style tag which goes with each one of the extended components. So you could embed this tag, and set the style attributes there, and the main component would stay clean. Wdyt? best regards, Martin On Wed, Dec 19, 2012 at 4:55 PM, Grant Smith gr...@marathonpm.com wrote: +1 The benefits outweigh the overcrowding of attributes, in my opinion. On Wed, Dec 19, 2012 at 6:47 AM, Leonardo Uribe lu4...@gmail.com wrote: +1 I think the proposal looks good, the names used in the properties are ok, and there is certainty that the changes are useful. regards, Leonardo 2012/12/19 Werner Punz werner.p...@gmail.com: Ok just to be more precise, I have integrated the changes now locally, but I am not committing them yet, because it would mean to introduce another set of attributes to the Calendar yet. I just want the opinion whether we should do it. Just to give s small description, the attributes would add alt texts to the popup calendar and default alt texts are set anyway, the inline calendar does not have images hence no alt is needed and possible. The downside of this is that we add another set of attributes: popupLeftArrowAlt , popupRightArrowAlt , popupMonthArrowAlt , popupYearArrowAlt , popupCloseButtonAlt , calendarIconAlt , popupWeekOfYearTitle , popupWeekOfDateTitle which is a huge set of new attributes to the already attribute overloaded calendar. So what is your opinion guys, shall we add it or not. I favor for a +1 here, since accessability is a big plus and the new attributes are optional in their usage. Werner Am 19.12.12 11:23, schrieb Werner Punz: Mhh shall we integrate this? I personally think it would make sense with some name changes. Werner Am 17.12.12 18:54, schrieb Jon Bionda: Sorry for what is likely a breach of protocol. This is a suggestion on how to make the Tomahawk Calendar more WCAG compliant. WCAG being a standard for gauging if browser based interfaces meet accessibility requirements primarily for disabled users. I joined the list a while ago to report an error I found and it was fixed promptly so I continued to watch the list and see that you are now preparing the next Tomahawk release, so maybe the timing is right. We used an older version of Tomahawk (1.0.6) and found the HtmlInputCalendar component failed the WCAG compliancy tests with respect to missing some ‘alt’ and ‘title’ attributes on tags generated by the calendar component. Some time ago, someone who has since left the company, made it mostly compliant by adding the following 8 properties to the HtmlInputCalendar – I didn’t do the compliancy testing but understand there are different levels of compliancy and these missing attributes make it fail at a basic level, so there may be more minor compliance issues which is why I can’t say it would be fully compliant. The properties with hopefully self-describing names are: calendarIconAlt popupLeftArrowAlt popupRightArrowAlt popupMonthArrowAlt popupYearArrowAlt popupCloseButtonAlt popupWeekOfYearTitle popupWeekOfDateTitle I’ve looked into forward porting the old changes to the Tomahawk 1.1.14 code base and have provided the code for adding the changes to the (org.apache.myfaces.custom.calendar) HtmlInputCalendar and HtmlCalendarRenderer classes. However, I am having trouble unravelling the precise changes that were made to the popcalendar.js file ( they seemed to have got a newer version of the js file and made the changes on it but I can’t figure out which version get got it from, probably obvious to you guys). A related change is also included and was made because part of WCAG is supporting screen readers. The text in alt and title attributes shouldn’t be using short forms of the week days (Sun, Mon, etc.) but rather their full names (Sunday, Monday, etc.). In the HtmlCalendarRenderer.getLocalizedLanguageScript() method, I see where they created a parallel String[] to weekDays to contain the full week day names. This is also added to the initData to be accessible in the javascript. We only use the calendar in popup mode so no changes were made to renderInline() but would expect it would also have to be modified to do a complete job. I zipped up the changes to the 2 java classes mentioned above (they only contained changed methods and have “WCAG change” comments identifying the changes), plus a sample properties file for default values and our popcalendar.js file. This last one is where my knowledge is insufficient to help much, but maybe you will find it useful to see how the new properties and full week name array are used. There may
Re: [COMMUNITY] MyFaces += Michael Kurz
Hi Michael, congratulations! best regards, Martin On Fri, Sep 30, 2011 at 9:09 AM, Werner Punz werner.p...@gmail.com wrote: Am 9/30/11 8:11 AM, schrieb Gerhard Petracek: The MyFaces PMC is proud to announce a new addition to our community. Please welcome Michael Kurz as the newest MyFaces committer! Michael is an active member of the MyFaces community, especially in MyFaces Core. @Michael: Please add yourself to the Master-POM at https://svn.apache.org/repos/asf/myfaces/myfaces-master-pom/trunk/pom.xml Welcome regards, Gerhard Congratulations Michael, well deserved. werner -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: [VOTE] fix MYFACES-2552 for 2.0.x and 2.1.x branches
+1 in general, +1 to Bernd's suggestion.
best regards,
Martin
On Thu, Sep 22, 2011 at 9:59 AM, Gerhard Petracek
gerhard.petra...@gmail.com wrote:
@bernd: +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/9/22 Bernd Bohmann bernd.bohm...@atanion.com
I agree STRICT_JSF_2_COMPATIBILITY is too generic. I think the param
should contain EL, TYPE, MAP, RESOLVER, NULL. And it should enabled by
default.
Regards
Bernd
On Wed, Sep 21, 2011 at 11:50 PM, Mark Struberg strub...@yahoo.de wrote:
Shouldnt the config contain the text EL_TYPE or so?
We have far too many strict JSF spec flags already ;)
LieGrue,
strub
- Original Message -
From: Jakob Korherr jakob.korh...@gmail.com
To: MyFaces Development dev@myfaces.apache.org
Cc: gudnabr...@gmail.com
Sent: Wednesday, September 21, 2011 10:20 PM
Subject: Re: [VOTE] fix MYFACES-2552 for 2.0.x and 2.1.x branches
+1 for including the fix in 2.0.x and 2.1.x + adding
org.apache.myfaces.STRICT_JSF_2_COMPATIBILITY
Regards,
Jakob
2011/9/21 Leonardo Uribe lu4...@gmail.com:
Hi
@Matt Benson: Could you attach at least the fragment with the
solution
for MYFACES-2552 ? so I can check it, create a patch for myfaces and
write a page on:
https://cwiki.apache.org/confluence/display/MYFACES/Composite+Components
with the explanation and the solution using a custom EL resolver.
That
would be very helpful.
regards,
Leonardo Uribe
2011/9/21 Leonardo Uribe lu4...@gmail.com:
Hi
It should be a param starting with org.apache.myfaces, like
org.apache.myfaces.STRICT_JSF_2_COMPATIBILITY
The important part is that by default it should be disabled, to
prevent receive over and over the same report.
In theory, it is possible to write a custom EL resolver that check
if
the base object implements
javax.faces.el.CompositeComponentExpressionHolder and if that so, do
the required stuff only on getType(). So, if somebody is writing a
composite component that relies on this behavior, it is possible to
write the fix in a portable way to both Mojarra and MyFaces (thanks
to
CompositeComponentExpressionHolder).
Note the change does not cause any side effects, because nobody
relies
on the wrong behavior, and what user wants is components
work as
expected.
regards,
Leonardo Uribe
2011/9/21 Mark Struberg strub...@yahoo.de:
Not sure about that.
Does the param start with javax.faces? In this case we should
rather use an own internal one.
Btw, if it's not in the spec even Mojarra would not be allowed
to use a proprietary parameter with javax
LieGrue,
strub
- Original Message -
From: Matt Benson gudnabr...@gmail.com
To: MyFaces Development dev@myfaces.apache.org
Cc:
Sent: Wednesday, September 21, 2011 6:29 PM
Subject: Re: [VOTE] fix MYFACES-2552 for 2.0.x and 2.1.x
branches
+1
However, let's simplify the context parameter by giving it
a name
relating to JSF 2.2 compatibility. I submitted the final
implementation for Mojarra, so have every right to add the same
to
MyFaces.
Matt
On Wed, Sep 21, 2011 at 11:19 AM, Gerhard Petracek
gerhard.petra...@gmail.com wrote:
+1 for it in combination with the context parameter
regards,
gerhard
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
2011/9/21 Rudy De Busscher rdebussc...@gmail.com
+1
And if we create a context parameter, it should behave
by default as in
the JSF 2.2 Spec. If users want strict spec
(2.0/2.1)behaviour they
have to
set the parameter value.
regards
Rudy
On 21 September 2011 17:08, Grant Smith
work.gr...@gmail.com
wrote:
+1 if it's configurable in a
context-param. How about
org.apache.myfaces.EL_RESOLVER_GETTYPE_RETURNS_NULL ?
On Wed, Sep 21, 2011 at 5:35 AM, Michael Kurz
michi.k...@gmx.at wrote:
+1
Am 21.09.2011 um 14:20 schrieb Leonardo Uribe:
+1
2011/9/21 Leonardo Uribe
lu4...@gmail.com:
Hi
More than a year ago, it was found
that EL expressions
like
#{cc.attrs.test} does not resolve its
type correctly,
because the
composite component EL resolver is
not able to find
the right type.
Instead, MapELResolver always return
Object.class as
type, breaking
composite components that use
h:selectOneXXX into its
internals. See
https://issues.apache.org/jira/browse/MYFACES-2552
The problem with this issue is we
need to change the
way how
org.apache.myfaces.el.unified.resolver.CompositeComponentELResolver
works. JSF 2.0 spec clearly
[jira] [Commented] (MYFACES-3311) Can't resolve converter for cc attributes
[
https://issues.apache.org/jira/browse/MYFACES-3311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13109240#comment-13109240
]
Martin Marinschek commented on MYFACES-3311:
Hi Michi,
I'll say what I know about this topic:
- we can not use java.lang.Long (or any specific type) as the type for a value
expression, as the EL will try to coerce null to 0 then (that's a very strange
part of the Unified EL spec)
- however, we can of course get the value and see what the type is. Of course,
this will not work when the value is null.
- Best would probably be to go over some means independent of the EL to
determine the type, but I don't know if the API enables us to do this
I wonder if the third suggestion is used when you are outside of a composite
comp, but not used when you are inside?
best regards,
Martin
Can't resolve converter for cc attributes
-
Key: MYFACES-3311
URL: https://issues.apache.org/jira/browse/MYFACES-3311
Project: MyFaces Core
Issue Type: Bug
Components: JSR-314
Affects Versions: 2.1.3
Reporter: Michael Kurz
Attachments: MYFACES-3311-testapp.zip
I have some serious problems with composite component attributes. I have a
composite component with the attribute value. This attribute
(#{cc.attrs.value}) is mapped to the value attribute of an internal
h:inputText. When I pass a VE to the composite component, the value is not
converted in the h:inputText.
The problem is caused in _SharedRendererUtils.findUIOutputConverter(). In
this method the converter is resolved based on the type returned by a call to
getType() on the VE. Unfortunately, for the VE in the composite component
(#{cc.attrs.value}) this resolves to java.lang.Object (and not to
java.lang.Long in my case).
I quickly tried to replace the call to VE.getType() with a call to
getValue().getClass(). This works, but I guess this introduces additional
constraints I'm currently not aware of. Any ideas? Wasn't something like this
already discussed in the past?
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3199) Handling AbortProcessingException is unconsistent
[
https://issues.apache.org/jira/browse/MYFACES-3199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13058538#comment-13058538
]
Martin Marinschek commented on MYFACES-3199:
Hi Martin,
I totally agree with your point about listener isolation, however I see things
a little differently (highlighting with _ added):
1) execute one listener in try catch block and catch (Exception e)
2) if
2a) exception is instance of APE _or any of the causes of the exception are an
APE, don't_ publish ExceptionQueuedEvent and terminate processing for current
event _(is this as such in the spec that an APE has to be queued?)_
2b) for any other exception publish ExceptionQueuedEvent and continue broadcast
processing
3) handle queued exception in exception handler
3a) default exception handler : ignore AbortProcessingException
3b) custom exception handler: can handle all unexpected exception (for example
remove them from queue)
4) all unhandled exception are rethrow and error page is displayed
Handling AbortProcessingException is unconsistent
-
Key: MYFACES-3199
URL: https://issues.apache.org/jira/browse/MYFACES-3199
Project: MyFaces Core
Issue Type: Sub-task
Components: General
Environment: myface core trunk
Reporter: Martin Kočí
UIViewRoot:
try {
source.broadcast(event);
}
catch (AbortProcessingException e)
{
ExceptionQueuedEventContext exceptionContext
= new ExceptionQueuedEventContext(context, e, source,
context.getCurrentPhaseId());
context.getApplication().publishEvent(context,
ExceptionQueuedEvent.class, exceptionContext);
// Abortion
return false;
}
Problem 1:
h:inputText valueChangeListener=#{bean.processValueChange}
MethodExpressionValueChangeListener wraps all exceptions to
AbortProcessingException and therefore exception is queued
Problem 2:
h:inputText
f:valueChangeListener binding=#{bean} /
/h:inputText
ValueChangeListenerHandler does not wrap exception to
AbortProcessingException and therefore exception is not queued in this block
(but it is queued from phase executor but without component info)
Problem 3: JSF spec 2.1 :
Clarification made: throwing an AbortProcessingException tells an
implementation that no further broadcast of the
current event occurs. Does not affect future events.
But I think that code in UIViewRoot makes opposite: // Abortion return
false;
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [VOTE] how myfaces-commons-resourcehandler should work with suffix mapping enabled
Hi Leo,
how is 4 better than 2?
2 is my preferred option, 3 if someone has the time to invest in this.
I don't see the additional value of 4.
best regards,
Martin
On 6/30/11, Leonardo Uribe lu4...@gmail.com wrote:
+1 for 3.
Option 4. doesn't cause any conflict, so we can just keep that code as is.
2011/6/30 Leonardo Uribe lu4...@gmail.com:
Hi
To reference images inside a css file in JSF 2.0, users have to change
its code from this:
.someclass
{
...
background-image:url('myimage.gif');
...
}
to this:
.someclass
{
...
background-image:url(#{resource['mylib:myimage.gif']});
...
}
This means a lot of changes, including override css files and copy
images to other locations.
Some months ago, a new module was added in MyFaces commons, with the
objective of handle that problem in a gracefully way (just don't
change anything on the css file and make JSF load the images). But
there are different points of view about how to handle it on the
implementation of that module.
Things works well when prefix mapping is used for FacesServlet. But
with suffix mapping, by default all resources have an additional
suffix added on its request path. So, the resource url looks something
like this:
http://[server][port]/[webapp]/javax.faces.resource/mylib/image.gif.jsf
breaking the css file.
The intention is allow suffix mapping for jsf files, but prefix
mapping for resource links. There are the following alternatives:
1. Enforce prefix mapping for jsf applications using this module and
do not support suffix mapping at all.
2. Add a prefix mapping entry for FacesServlet and create a web config
init param to indicate that mapping will be used to handle resources.
If such param is no present, assume /faces as prefix mapping used.
3. Add a prefix mapping entry for FacesServlet and detect it
automatically, parsing web.xml file and in servlet 3.0 use
ServletRegistration. A web config init param anyway should be provided
for handle portlets case.
4. Use a special filter and detect if was setup automatically, looking
on application map if the filter was set or not and a web config init
param to know the mapping used, without parse xml files or servlet 3.0
specific code.
Please vote about which one you think is the best alternative, and
should be done in that module.
Please note: This vote is majority approval over the choice selected
(see [1]).
Thanks,
Leonardo Uribe
[1] http://www.apache.org/foundation/voting.html#ReleaseVotes
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
Re: Advanced JSF 2 ResourceHandler for MyFaces commons
Hi guys,
let me weigh in on the filter question: please, no filter!
@prefix suffix mappings: you can get the registered mappings
in previous servlet versions: parsing the web.xml
in servlet 3.0: via the API
http://download.oracle.com/javaee/6/api/javax/servlet/ServletRegistration.html
the resource url should then always be generated with the prefix
mapping - how can this lead to inconsistencies?
best regards,
Martin
On Thu, Jun 23, 2011 at 11:54 PM, Leonardo Uribe lu4...@gmail.com wrote:
Hi
In the last days this enhancements were commited:
--
Added GZIP compression to ExtendedResourceHandler and these params:
/**
* Enable or disable gzip compressions for resources served by
this extended resource handler. By default is disabled (false).
*/
@JSFWebConfigParam(defaultValue=false)
public static final String INIT_PARAM_GZIP_RESOURCES_ENABLED =
org.apache.myfaces.commons.GZIP_RESOURCES_ENABLED;
/**
* Indicate the suffix used to recognize resources that should be
compressed. By default is .css .js.
*/
@JSFWebConfigParam(defaultValue=.css, .js)
public static final String INIT_PARAM_GZIP_RESOURCES_SUFFIX =
org.apache.myfaces.commons.GZIP_RESOURCES_SUFFIX;
public static final String
INIT_PARAM_GZIP_RESOURCES_EXTENSIONS_DEFAULT = .css .js;
/**
* Indicate if gzipped files are stored on a temporal directory to
serve them later. By default is true. If this is
* disable, the files are compressed when they are served.
*/
@JSFWebConfigParam(defaultValue=true)
public static final String INIT_PARAM_CACHE_DISK_GZIP_RESOURCES =
org.apache.myfaces.commons.CACHE_DISK_GZIP_RESOURCES;
by default compression is set to false. It could be good to enable
compression only on files bigger than some specified lenght, to allow
finer tuning.
--
and these enhancements:
--
Added new scanning and parsing of myfaces-resources-config.xml files.
It was added this param:
/**
* This param allow to override the default strategy to locate
myfaces-resources-config.xml files, that will be parsed later. In this
way
* it is possible to include new source locations or handle cases
like OSGi specific setup.
*/
@JSFWebConfigParam
public static final String
INIT_PARAM_EXTENDED_RESOURCE_HANDLER_CONFIG_URL_PROVIDER =
org.apache.myfaces.commons.EXTENDED_RESOURCE_HANDLER_CONFIG_URL_PROVIDER;
I think just a param that instantiate a class implementing
MyFacesResourceHandlerUrlProvider is enough. The default algorithm
loook on classpath for META-INF/myfaces-resources-config.xml and on
servlet context for WEB-INF/myfaces-resources-config.xml files.
myfaces-resources-config.xml files can be used with these options:
?xml version=1.0 encoding=UTF-8?
myfaces-resources-config
!-- Mark this library to be handled by Extended Resource Handler --
library
library-namelibraryA/library-name
/library
!-- Indicate this library has another name, so if libraryC is used,
resources should be redirected to libraryC1 --
library
library-namelibraryC/library-name
redirect-namelibraryC1/redirect-name
/library
!-- Allow to customize the request path generated, to do things like
take library resources from a Content Delivery Network (CDN) or just
take it directly from an specified location. Note it is responsibility
of the developer to configure it properly, and the resources should
exists locally under the library name selected. --
library
library-namelibraryB/library-name
request-pathhttp://someaddress.com/alternatePath/#{resourceName}/request-path
!-- This example shows the variables that can be called
inside the expression to construct the request map
request-path#{extensionMapping ? '' :
mapping}/javax.faces.resource/$/#{localePrefix}/#{libraryName}/#{resourceName}#{extensionMapping
? mapping : ''}/request-path
--
/library
/myfaces-resources-config
All libraries referenced here will be handled by the extended
ResourceHandler. Additionally, there is an option to redirect a
library name into another, to deal with possible conflicts between
resources loaded, specially javascript libraries. And finally there is
an option to override the request-path with an EL expression, so if
you have a library with some static resources it is easy to construct
an url to load them from a Content Delivery Network (CDN) or just from
some specified path. The only thing you should note is the library
should exists locally under the library name, to detect when a
resource can be resolved or not.
--
I have not
Re: UIRepeat offset and size problem
Hi Ricard,
no, this is not a bug. findComponent is supposed to work from the
enclosing naming container. If you need to search without this, you
need to traverse the hierarchy. I do think I remember we implemented
::text for a case like this already in the standard - in any case,
the component libraries I am using imlement this already ;)
best regards,
Martin
On Tue, Jun 21, 2011 at 3:06 PM, RICARD MORE FARRES
ricard.m...@mango.com wrote:
Thanks Leonardo,
Already done, but I have another question:
Which is the reason that UIComponentBase.findComponent(String expr) looks for
the searched component, starting from the closest parent that implements
NamingContainer?
Look at this example:
h:outputText id=text value=#{bean.texto}/h:outputText
ui:repeat id=repeat value=#{bean.textos} var=texto
h:commandLink id=command value=#{texto}
f:ajax event=click listener=#{bean.actionListener} render=text/
/h:commandLink
/ui:repeat
If we try to render this view, we get:
javax.faces.FacesException: Component with id:texto not found
This exception is trown by HtmlAjaxBehaviorRenderer.mapToString when he find
every component identified in the render attribute. I think they converts the
id's in the render attribute, to the clientId of every component referenced.
The problem is that UIRepeat implements NamingContainer, so the commandLink
inside that UIRepeat is gonna search the component identified by 'text'
inside the children list of repeat tag.
But it should works, isn't it? Nothing wrong to re render an outputtext from
command link that is inside a repeat.
I have reimplemented method findComponent in my own components, in order to
find the id starting from the view root... and it works.
Is this another bug?
Regards,
Ricard
-Mensaje original-
De: Leonardo Uribe [mailto:lu4...@gmail.com]
Enviado el: lunes, 20 de junio de 2011 19:09
Para: MyFaces Development
CC: RICARD MORE FARRES
Asunto: Re: UIRepeat offset and size problem
Hi
It is a bug. Please create an issue here:
https://issues.apache.org/jira/browse/MYFACES
I have already a patch, so as soon as you create the issue I'll commit
it. Later, you can get a nightly build snapshot here:
https://repository.apache.org/content/repositories/snapshots/org/apache/myfaces/core/
regards,
Leonardo Uribe
2011/6/20 RICARD MORE FARRES ricard.m...@mango.com:
Hello,
I am testing MyFaces 2.1.1 implemantation, in order to upgrade our
aplication from version 1.2.7.
I have found a problem with parameters offset and size of ui:repeat tag.
offset sets the first index of the list to iterate over.
size is the number of element to iterate.
If I have a list of Strings like this:
private String[] textos = new String[] {B1, B2, B3, B4, B5, B6,
B7};
public String[] getTextos() {
return textos;
}
And I declare repeat tag:
ui:repeat value=#{bean.textos} var=texto offset=0 size=1
h:outputText value=#{texto}/br/
/ui:repeat
It shows elements B1 and B2 (iterate over indexes 0 and 1). If I change
offset to 1, it will show elements B2 and B3.
But if I set offset=2 in order to ietare over indexes 2 and 3 (elements B3
and B4), I get an exception:
javax.faces.FacesException: iteration offset cannot be greater than
collection size
at
org.apache.myfaces.view.facelets.component.UIRepeat._validateAttributes(UIRepeat.java:552)
at
org.apache.myfaces.view.facelets.component.UIRepeat.process(UIRepeat.java:581)
...
If I want to avoid this error, size must be allways greater tha offset, but
it should be possible to iterate over last two elements of a 102 elements
list starting from index 100, for example (offset=100,size=1).
And should not be 1 the lower value for size? Now, if you set 0 to size,
ui:repeat iterates once...
Thanks in advance,
Ricard
Para el medioambiente cada gesto cuenta: por favor, no imprimas este e-mail
si no es realmente necesario.
Este correo y sus archivos asociados son privados y confidenciales y va
dirigido exclusivamente a su destinatario. Si recibe este correo sin ser el
destinatario del mismo,le rogamos proceda a su eliminación y lo ponga en
conocimiento del emisor. La difusión por cualquier medio del contenido de
este correo podría ser sancionada conforme a lo previsto en las leyes
españolas. No se autoriza la utilización con fines comerciales o para su
incorporación a ficheros automatizados de las direcciones del emisor o del
destinatario.
Each one of us can do our bit for the environment: please, do not print this
e-mail unless it is absolutely essential.
This e-mail and its attached files are confidential and are exclusively
intented for their addressees. If you have received this e-mail and it is
not addressed to you, please notify us of the error by replying to it before
proceeding to delete it. The diffusion of the contents of this e-mail by
whatever means may be penalised in
Re: [core] performance: performance hints
+1!
best regards,
Martin
On 4/20/11, Gerhard Petracek gerhard.petra...@gmail.com wrote:
+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/4/20 Jakob Korherr jakob.korh...@gmail.com
Hi,
That's a great idea! Please do that :)
IMO there is still a lot of potential in the state saving area. I
think every idea for an improvement is appreciated here!
Regards,
Jakob
2011/4/19, Martin Koci martin.kocicak.k...@gmail.com:
Hi,
is it possible to introduce performance hints in myfaces-core? Hints
similar to javax.faces.component.visit.VisitHint but related to
performance improvements. Example:
For dataTable like:
a:dataTable
a:column
#{aExpression}
it's completely unnecessary to save per-row state. Currently there is no
elegant way how to do read-only table (state per-row is always
maintained). If user wants (fast) readOnly table, he/she must extend
UIData and re-implemenent setRowIndex method. But hint say
org.apache.myfaces.core.UIData.saveRowState=false can solve it
elegantly - if present (in component.getAttributes()) UIData skips
row-state-saving and restoring methods entirely.
Lifespan of those hints can be request (faceContext.attributes) or view
(component.attributes)
WDYT?
Regards,
Kočičák
See https://issues.apache.org/jira/browse/MYFACES-3111 too.
--
Jakob Korherr
blog: http://www.jakobk.com
twitter: http://twitter.com/jakobkorherr
work: http://www.irian.at
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
Re: [RE-VOTE] Release MyFaces Portlet Bridge 3.0.0
+1, regards, Martin On Tue, Mar 22, 2011 at 11:42 PM, Bernd Bohmann bernd.bohm...@atanion.com wrote: Here is my +1 Regards Bernd On Tue, Mar 22, 2011 at 9:53 PM, Mark Struberg strub...@yahoo.de wrote: +1 took your key from here https://svn.apache.org/repos/asf/myfaces/keys/KEYS rat, key, LICENSE, NOTICE on the source-release.zip looks fine. LieGrue, strub --- On Tue, 3/22/11, Michael Freedman michael.freed...@oracle.com wrote: From: Michael Freedman michael.freed...@oracle.com Subject: [RE-VOTE] Release MyFaces Portlet Bridge 3.0.0 To: MyFaces Development dev@myfaces.apache.org Date: Tuesday, March 22, 2011, 8:17 PM Files without necessary license statements have been updated. Rat now reports no problems. Refer to information in message below regarding this release and location of distributable components/artifacts (changes have been made to reflect current build). As this is a re-vote -- please do so asap as I will be (hopefully) closing the vote by the end of this week so we can get this release out. -Mike- Original Message Subject: [VOTE] Release MyFaces Portlet Bridge 3.0.0 Date: Wed, 09 Mar 2011 15:52:54 -0800 From: Michael Freedman michael.freed...@oracle.com Reply-To: MyFaces Development dev@myfaces.apache.org Organization: Oracle Corporation To: myfaces Development dev@myfaces.apache.org Please vote on the proposed release of MyFaces Portlet Bridge 3.0.0-alpha. This is the alpha version of the Portlet Bridge for JSF 2.0. It includes all the base function of JSR329 updated to run in a JSF 2.0 environment. Some, though not all JSF 2.0 features are expressed/utilized. Most significant is Ajax support and Composite Component suppport. Note: this version of the bridge will not work with any currently released versions of MyFaces (try Trunk) and only mostly runs on released version of Mojarra (patches available). Likewise a patched version of Trinidad is needed to run the TCK (for those tests that depend on Trinidad). Distributable components can be inspected in http://people.apache.org/~mfreedman/portlet-bridge/3.0.0-alpha Repository artifacts are at: https://repository.apache.org/content/repositories/orgapachemyfaces-022/ I have verified that the distributable jars run and pass the updated version of the JSR 329 TCK. In addition I have verified that the distributable examples run (on apache tomcat/pluto). [ ] +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, -Mike- -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: On an unrelated sidenote
Hi Werner, congrats for someone who will be in the same position very soon ;) all the best, Martin On 2/12/11, Matthias Wessendorf mat...@apache.org wrote: Congrats!! On Friday, February 11, 2011, Zubin Wadia zwa...@gmail.com wrote: Awesome! Congratulations! On Fri, Feb 11, 2011 at 5:50 PM, Bruno Aranda brunoara...@gmail.com wrote: Congrats!!! And forget sleeping... Bruno On 11 February 2011 22:36, Hazem Saleh haz...@apache.org wrote: Congratulations Werner! I bet you are a very good father. On Sat, Feb 12, 2011 at 12:26 AM, Werner Punz werner.p...@gmail.com wrote: I have become father of a nice little boy yesterday. My second child. 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 http://www.mapmysocial.com/ -- 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
Re: [VOTE] release for myfaces core 2.0.4
+1, best regards, Martin On 2/11/11, Werner Punz werner.p...@gmail.com wrote: +1 Am 11.02.11 12:54, schrieb Jakob Korherr: +1 Regards, Jakob 2011/2/9 Mark Strubergstrub...@yahoo.de: +1 LieGrue, strub --- On Wed, 2/9/11, Gerhardgerhard.petra...@gmail.com wrote: From: Gerhardgerhard.petra...@gmail.com Subject: Re: [VOTE] release for myfaces core 2.0.4 To: MyFaces Developmentdev@myfaces.apache.org Date: Wednesday, February 9, 2011, 1:52 PM +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/2/9 Martin Kocimartin.kocicak.k...@gmail.com +1 Leonardo Uribe píše v St 09. 02. 2011 v 01:07 -0500: Hi, I was running the needed tasks to get the 2.0.4 release of Apache MyFaces core out. The artifacts passed all TCK tests. Please note that this vote concerns all of the following parts: 1. Maven artifact group org.apache.myfaces.shared v4.0.5 [1] 2. Maven artifact group org.apache.myfaces.core v2.0.4 [1] The artifacts were deployed on nexus repo [1] and to my private Apache account [3] for binary and source packages. The release notes could be found at [4]. Also the clirr test does not show binary incompatibilities with myfaces-api. Please take a look at the 2.0.4 artifacts and vote! Please note: This vote is majority approval with a minimum of three +1 votes (see [3]). [ ] +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, Leonardo Uribe [1] https://repository.apache.org/content/repositories/orgapachemyfaces-044/org/apache/myfaces/ [2] http://www.apache.org/foundation/voting.html#ReleaseVotes [3] http://people.apache.org/~lu4242/myfaces204binsrc [4] https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10600version=12316153 Sucker-punch spam with award-winning protection. Try the free Yahoo! Mail Beta. http://advision.webevents.yahoo.com/mailbeta/features_spam.html -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: SKIP_ITERATION tree visit support
Hi Andy, certainly needs to be fixed on this side of the fence as well ;) best regards, Martin On 2/8/11, Andy Schwartz andy.g.schwa...@gmail.com wrote: Decided to break this up into 2 issues: MYFACES-3036 Support SKIP_ITERATION FacesContext property MYFACES-3037 Children of iterating components receive multiple PostRestoreStateEvents A solution for the first issue would make fixing the second issue very easy. Andy -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: [COMMUNITY] MyFaces += Andy Schwartz
Hi Andy, for a first commit, it is as good as it gets ;) Welcome aboard from me as well! best regards, Martin On Thu, Feb 3, 2011 at 10:34 PM, Andy Schwartz andy.g.schwa...@gmail.com wrote: Thanks again all! BTW, finally managed to get my first commit in: http://svn.apache.org/viewvc?view=revisionrevision=1066976 Looking forward to more interesting contributions in the future. :-) Andy -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
[jira] Commented: (MYFACES-3012) Allow f:param for h:inputText f:ajax
[ https://issues.apache.org/jira/browse/MYFACES-3012?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12983626#action_12983626 ] Martin Marinschek commented on MYFACES-3012: I would like this feature, but it is not foreseen by the spec so far. best regards, Martin Allow f:param for h:inputText f:ajax Key: MYFACES-3012 URL: https://issues.apache.org/jira/browse/MYFACES-3012 Project: MyFaces Core Issue Type: Improvement Components: JSR-314 Affects Versions: 2.0.4-SNAPSHOT Environment: myfaces trunk, shared svn. rev 1051469 Reporter: Martin Kočí Priority: Minor Attachments: MYFACES-3012.patch I don't know what spec says but following should work: h:inputText f:param name=paramName value=paramValue / f:ajax / /h:inputText expected result is paramName = paramValue pair in request. For h:command it works already. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [core] Improve error reporting and logging
I am always for better error reporting! best regards, Martin On 1/10/11, Jakob Korherr jakob.korh...@gmail.com wrote: Hi Kocicak, 1 Regards, Jakob 2011/1/10 Martin Koci martin.kocicak.k...@gmail.com: Hi, the most wanted feature which our coders want is more consistent and human-readable error reporting and logging. Here is a example: If user specifies f:ajax without eventName for a component without defaultEventName, myfaces throw a execption: Now (myfaces 2.0.3): eventName could not be defined for f:ajax tag with no wrap mode. Improved (example only; from my copy of myfaces): MF0345: Your ajax tag does not specify eventName and component com.foo.Bazz does not provide the default one. Please use one from available: [change, blur, focus ...]; Tag location: XYZ.xhtml line 56 column 23, f:ajax . / Component: id: componentId, class: com.foo.BazzInput, component type: org.renderkit.Input ViewId: YYZ.xhml, located in file system as: /tmp/deploy/weabpp/XYZ.xhtml PhaseId: RENDER_RESPONSE Details: ... a detailed description of this problem + suggestions, example of code. References: # Click for problem MF0345 in MYFACES knowledge database (hypertext link) # Contact your technology team : m...@to.me # If you think this a bug report it: jira.project.org What do you think about this idea? (I'll describe our requirements and what I found so far in next emails) Regards, Kočičák -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: [DISCUSS] CODI window-handler renders a page
Hi Mark, WDYT? Do we need to drop this from CODI and move it to somewhere else? no. This should reside within CODI - it cannot be part of a certain component library, as CODI doesn't know anything about component libraries. Or is this not a 'rendering' in the restricted sense? I don't see why a JSF extension framework cannot do rendering. LieGrue, strub best regards, Martin -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
[jira] Commented: (MYFACES-2968) ApplicationImpl.createMethodBinding should create expression with signature: void method(params)
[ https://issues.apache.org/jira/browse/MYFACES-2968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12933765#action_12933765 ] Martin Marinschek commented on MYFACES-2968: Hi guys, just my additional 2 cents: the EL implementations behave differently with return values. E.g.: JUEL won't find an action method which has a void return value - the reference EL implementation will find it! best regards, Martin ApplicationImpl.createMethodBinding should create expression with signature: void method(params) Key: MYFACES-2968 URL: https://issues.apache.org/jira/browse/MYFACES-2968 Project: MyFaces Core Issue Type: Bug Reporter: Martin Kočí Attachments: MYFACES-2968.patch This is probably not specified but mojarra does it: Application.createMethodBinding creates method expression with void return type. That makes sence because original purpose of MethodBinding is a reference to faces listeners and they are without return values mostly. o.a.m.ApplicationImpl creates value expression to method with Object return type. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [codi] logo proposal
+1 Regards, Martin Von meinem iPhone gesendet Am 11.11.2010 um 16:03 schrieb Alexander Bell alexander.b...@j4fry.org: +1 pretty cool 2010/11/11 Jakob Korherr jakob.korh...@gmail.com +1 It looks really great!! Regards, Jakob 2010/11/11, Matthias Wessendorf mat...@apache.org: +1 On Thu, Nov 11, 2010 at 2:36 PM, Gerhard gerhard.petra...@gmail.com wrote: +1 regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2010/11/11 Gerhard gerhard.petra...@gmail.com hi @ all, adonis made a nice codi logo [1]. regards, gerhard [1] http://people.apache.org/~gpetracek/myfaces/codi/codi_logo.png http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at -- Mit freundlichen Grüßen / Kind regards Alexander Bell J4Fry OpenSource Community Internet: http://www.j4fry.org E-Mail: alexander.b...@j4fry.org Webprofil: http://www.j4fry.org/alexanderbell.shtml
Re: [VOTE] Release of Extensions CDI (CODI) 0.9.0
+1, best regards, Martin On 11/10/10, Hazem Saleh haz...@apache.org wrote: +1. On Tue, Nov 9, 2010 at 11:12 PM, Mark Struberg strub...@yahoo.de wrote: +1 LieGrue, strub PS: we will add binary releases as next step, but they are not mandotory for an ASF release anyway (only the source-release is needed) --- On Tue, 11/9/10, Gerhard Petracek gpetra...@apache.org wrote: From: Gerhard Petracek gpetra...@apache.org Subject: [VOTE] Release of Extensions CDI (CODI) 0.9.0 To: MyFaces Development dev@myfaces.apache.org Date: Tuesday, November 9, 2010, 9:02 PM Hi, We were running the needed tasks to get the 1st release of Apache MyFaces Extensions CDI (aka MyFaces CODI) out. The artifacts are deployed to Nexus [1] (and [2]). The release contains the following modules: - CODI Core - CODI JSF Module (for 1.2 and 2.0) - CODI JPA Module - CODI BV Module - CODI I18N-Message Module - CODI Scripting Module - CODI Distribution Modules Please take a look at the 0.9.0 artifacts and vote! Please note: This vote is majority approval with a minimum of three +1 votes (see [3]). [ ] +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, Gerhard [1] https://repository.apache.org/content/repositories/orgapachemyfaces-052/ [2] https://repository.apache.org/content/repositories/orgapachemyfaces-052/org/apache/myfaces/extensions/cdi/myfaces-extcdi-parent/0.9.0/myfaces-extcdi-parent-0.9.0-source-release.zip [3] http://www.apache.org/foundation/voting.html#ReleaseVotes -- 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 Web blog: http://www.jroller.com/HazemBlog [Web 2.0] Mashups Integration with JSF: http://code.google.com/p/mashups4jsf/ -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: MYFACES-2952 - Improve Atmosphere Meteor support of MyFaces
+1 for: Or a ctx param : o.a.m.INIT_ALWAYS.
Nothing meteor-specific, I would say.
best regards,
Martin
On 10/29/10, Matthias Wessendorf mat...@apache.org wrote:
Or a ctx param : o.a.m.INIT_ALWAYS
default = false
sent from my Android phone
On Oct 29, 2010 12:41 PM, Matthias Wessendorf mat...@apache.org wrote:
Currently MyFaces stops initializing when there is no (My)FacesServlet
configured in the (present) web.xml.
I am sure this is in 99.99% of all cases right. However there is a
chance that a wrapping framework will
instantiate the (My)FacesServlet, inside a wrapping Servlet.
An example of that is the WebSocket/Comet Framework Atmosphere.
As mentioned in [1] a typical configuration looks like:
servlet
descriptionMeteorServlet/description
servlet-nameMeteorServlet/servlet-name
servlet-classorg.atmosphere.cpr.MeteorServlet/servlet-class
init-param
param-nameorg.atmosphere.servlet/param-name
param-valuejavax.faces.webapp.FacesServlet/param-value
/init-param
init-param
param-nameorg.atmosphere.useWebSocket/param-name
param-valuetrue/param-value
/init-param
init-param
param-nameorg.atmosphere.useNative/param-name
param-valuetrue/param-value
/init-param
/servlet
So in order to enable the AbstractFacesInitializer.java to see that it
can continue the initialization work, I thought about adding the
following to shared WebXml.java:
Index: src/main/java/org/apache/myfaces/shared/webapp/webxml/WebXml.java
===
--- src/main/java/org/apache/myfaces/shared/webapp/webxml/WebXml.java
(revision
1028633)
+++ src/main/java/org/apache/myfaces/shared/webapp/webxml/WebXml.java
(working
copy)
@@ -107,6 +107,11 @@
public abstract boolean isErrorPagePresent();
/**
+ * Determines, if the web.xml contains the Atmosphere Meteor Servlet
+ */
+ public abstract boolean isAtmosphereMeteorServletPresent();
+
+ /**
* Returns true if the given servlet class is a valid FacesServlet.
* This is the FacesServlet itself or any DelegatedFacesServlet.
*
The AbstractFacesInitializer would be changed to something like:
Index:
impl/src/main/java/org/apache/myfaces/webapp/AbstractFacesInitializer.java
===
---
impl/src/main/java/org/apache/myfaces/webapp/AbstractFacesInitializer.java
(revision
1028633)
+++
impl/src/main/java/org/apache/myfaces/webapp/AbstractFacesInitializer.java
(working
copy)
@@ -79,6 +79,7 @@
* application.
*/
public void initFaces(ServletContext servletContext) {
+
try {
if (log.isLoggable(Level.FINEST)) {
log.finest(Initializing MyFaces);
@@ -102,7 +103,9 @@
}
return;
- } else if (webXml.getFacesServletMappings().isEmpty()) {
+ } else if (webXml.getFacesServletMappings().isEmpty()
!webXml.isAtmosphereMeteorServletPresent()) {
+ // IF the
+
// check if the FacesServlet has been added dynamically
// in a Servlet 3.0 environment by MyFacesContainerInitializer
Boolean mappingAdded = (Boolean)
servletContext.getAttribute(FACES_SERVLET_ADDED_ATTRIBUTE);
What do you think?
Noteof course - today we have Atmoshpere, tomorrow we may have
different use cases to see if a different Servlet (and/or Filter) is
present.
Hence we could have something like instead:
WebXml_API
public abstract boolean containsServlet(String fullQualifiedClassName);
/WebXml_API
(we want String here, since (with Atmosphere) we can't compile against
it (-(L)GPL))... but we can use the String-based name
as a constant in our code)
Oh yes... a similar change would be needed for the
MyFacesContainerInitializer.java from our implee6 module.
-Matthias
[1] https://issues.apache.org/jira/browse/MYFACES-2952
--
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
Re: JBoss and MyFaces ....
Congrats to everyone involved - you did great work to make this happen! all the best, Martin On 10/14/10, Werner Punz werner.p...@gmail.com wrote: Am 14.10.10 22:32, schrieb Matthias Wessendorf: Matthias Wessendorf (@mwessendorf) has shared a Tweet with you: lincolnthree: MyFaces 2 is now included in JBoss AS 5 SNAPSHOT!! -Initialized 3 JSF configurations: [Mojarra-1.2, MyFaces-2.0, Mojarra-2.0] --http://www.twitter.com/lincolnthree/status/27372071638 sent from my Android phone Oha... this is big news... Werner -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: [VOTE] Release MyFaces Portlet Bridge 2.0.0-beta
Hi Mike, you should send out the result vote roughly 72hrs after the vote has started. When you do the release based on the vote - is your timing thingy ;) best regards, Martin On 10/12/10, Michael Freedman michael.freed...@oracle.com wrote: Actually, I had deferred sending the results message pending us actually doing/pushing the release which I thought was imminent. Alas I am still awaiting getting some free time from the developer tasked to do this but that slot never seems to open up -- so its now 2+ months since this was done and still it hasn't been published. If you would prefer I am happy to send a message concerning the vote result -- but I still don't have a time estimate for when the release/push will actually happen. Let me know whether I should wait until the push is ready to go or I should just send this message to get it off the stack. -Mike- On 10/12/2010 9:23 AM, Scott O'Bryan wrote: Mike Freedman sent out the announcement. It looks like I forgot the results email. Sorry Matthias. Sent from my iPhone On Oct 12, 2010, at 2:47 AM, Matthias Wessendorfmat...@apache.org wrote: what happened to this vote ? -Matthias On Fri, Jul 23, 2010 at 7:30 PM, Scott O'Bryandarkar...@gmail.com wrote: +1 On 07/22/2010 04:41 AM, Matthias Wessendorf wrote: +1 On Wed, Jul 21, 2010 at 10:18 PM, Michael Freedman michael.freed...@oracle.com wrote: +1 On 7/20/2010 2:09 PM, Michael Freedman wrote: Please vote on the proposed release of MyFaces Portlet Bridge 2.0.0-beta. This is the beta version of the JSR 329 RI: Portlet 2.0 Bridge for JavaServer Faces 1.2. It corresponds to that JSRs Public Review draft which is currently posted and underway. The signed bridge artifacts pass what exists of the 329 TCK (i.e. all its tests) and I have verified that the examples run. It can be inspected at http://people.apache.org/~mfreedman/portlet-bridge/2.0.0-beta/ [ ] +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, -Mike- -- 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
Re: [core] performance: disabling old technologies
Great stuff! This is certainly important... best regards, Martin On Sun, Sep 26, 2010 at 3:01 PM, Michael Concini mconc...@gmail.com wrote: +1 on Martin's proposed changes. I also concur that we should look into moving to StAX if it will help improve startup time. Regards, Mike On Sun, Sep 26, 2010 at 7:31 AM, Gerhard gerhard.petra...@gmail.com wrote: +1 regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2010/9/26 Jakob Korherr jakob.korh...@gmail.com +1 on that. Great idea! Furthermore changing to StAX is also a great idea. Regards, Jakob 2010/9/25 Ganesh gan...@j4fry.org: Great approach. Though the spec would be the right place for this I think we should have it in MyFaces asap and do our best to push it to the 2.2 spec. Am 24.09.2010 14:33, schrieb Martin Koci: Hi, since JSF 2.0 JSP support andmanaged-bean are deprecated. Since 1.2 same for javax.faces.el. For performace reasons I suggest find a way how disable following: 1) Managed Bean support (o.a.m.SUPPORT_MANAGED_BEANS=false) if this flag is false, myfaces will not install ManagedBeanResolver and will skip managed beans processing during startup (or outputs a warning if managed bean is found and this flag is false). 2) VariableResolver and PropertyResolver (o.a.m.SUPPORT_JAVAX_FACES_EL=false) myfaces will not install VariableResolverImpl and VariableResolverToELResolver and PropertyResolver implementations 3) (o.a.m.SUPPORT_JSP=false) if this flag is false myfaces will not install FacesCompositeELResolver and will skip JSP initializer during startup. FacesCompositeELResolver is related to VariableResolverImpl, maybe this can be one paramater. Those are only suggestions. I did some initial profiling and when old technogies are disabled myfaces gain significant performance boost, especially in render response phase. Another solution for ELResolvers only is use of comparator but this does not allow skip certain parts of code. WDYT? Kočičák -- There are two kinds of people in the world, those who believe there are two kinds of people and those who don't. — Robert Benchley -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: [COMMUNITY] MyFaces += Martin Kočí
Hi Martin, welcome aboard! great to have you around! best regards, Martin On 9/7/10, Martin Koci martin.k...@aura.cz wrote: Hi, it's an honour for me, thanks for inviting me to this great community. Just for curiosity I found this: https://issues.apache.org/jira/browse/MYFACES-1171 - reported by me more than four years ago - time runs so fast! That reminds me: I started with JSF 0.4 EA - do you remember h:command_button tag with underscore :) ? Over time I participated in development of more than five large systems with JSF based GUI and experiences I'll share with you here. Thanks, Martin Kočí Matthias Wessendorf píše v Út 07. 09. 2010 v 16:50 +0200: The Myfaces PMC is proud to announce a new addition to our community. Please welcome Martin Kočí as the newest MyFaces committer! Ali is an active member of the myfaces community. He started on contributing to Trinidad and was a great resource recently on MyFaces core. @Martin: Please add yourself to the Master-POM at https://svn.apache.org/repos/asf/myfaces/myfaces-master-pom/trunk/pom.xml -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: submittedValue vs. Converter.getAsObject
Hi Kocicak, So on JSF level conversion String - Object is unable to solve this problem - I simply need Object - Object conversion which is not supported yet. Yes, this is true - this is obviously a spec problem. If the submitted value is an object, it should also be allowed to convert it. A converter is more than just a string to object (and back) converter, it is an artefact which transforms information from its representation for output (and this output could be anything, and certainly doesn't have to be string based) to its representation which the business model (or also an artefact within JSF, like a validator) understands. So I agree. This hasn't come up so far cause nobody uses non string based output models for JSF. Note that my notion of a business converter (discussed on this mailing list a while ago) for converting between a business model representation and a representation in a JSF artefact like the renderer (e.g. you use joda.Date in the business model, but the JSF date picker renderer only understands the normal java date) is also hinting in the direction that such an additional converter API would be necessary. I discussed this with the EG (and also Ed privately), and there wasn't much interest for adding this. best regards, Martin best regards, Martin -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: submittedValue vs. Converter.getAsObject
I discussed this with the EG (and also Ed privately), and there wasn't much interest for adding this. P.S.: it might however be useful to have this in the MyFaces implementation somehow. @Leonardo: did you actually provide a business-converter interface - we discussed about this? best regards, Martin -- 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: submittedValue vs. Converter.getAsObject
Hi Leo, Yes, to solve the problem with t:inputCalendar and t:inputDate it was clear an interface like that was necessary but it is tied to java.util.Date in this case: We could open an issue to make this more generic - and have an infrastructure in the impl where we can register such converters. Then we could use them for such use-cases as we have, and also for Martin's use-cases. best regards, Martin -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
[jira] Commented: (MYFACES-2895) Messages component cannot be updated by ajax without wrapping it
[
https://issues.apache.org/jira/browse/MYFACES-2895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12903799#action_12903799
]
Martin Marinschek commented on MYFACES-2895:
Spec bug or not, we should try to fix it in the implementation.
best regards,
Martin
Messages component cannot be updated by ajax without wrapping it
Key: MYFACES-2895
URL: https://issues.apache.org/jira/browse/MYFACES-2895
Project: MyFaces Core
Issue Type: Bug
Components: JSR-314
Affects Versions: 2.0.2-SNAPSHOT
Reporter: Nick Belaevski
When there are no faces messages generated, h:messages component does not
render no HTML tags, so it cannot be updated by ajax.
To reproduce:
h:messages id=messages /
h:commandButton value=Invoke listener by
type action=#{bean.generateMessage}
f:ajax render=messages /
/h:commandButton
No messages will appear. As a workaround messages component can be wrapped
into h:panelGroup that's id will be specified in 'render':
h:panelGroup id=messages
h:messages /
/h:panelGroup
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: _SelectItemsUtil._ValueConverter
I didn't totally think through if it is usable in this case, but more
general, if you can prevent it, do not use EL coercion. Why?
As specified, EL coercion will coerce null to 0 or an . For the next
version of the EL, this behaviour might be configurable.
best regards,
Martin
On 8/27/10, Jakob Korherr jakob.korh...@gmail.com wrote:
Hi,
Hmm, could be. I guess this code was introduced in JSF 1.1 (no unified EL
and thus no EL coercion available) and never changed in later versions.
If you can make the scenario work using EL coercion, please file an issue in
the JIRA. Thanks!
Regards,
Jakob
2010/8/27 Martin Koci martin.k...@aura.cz
Hi,
I understand that requirement but isn't it EL coercion task ? :
https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=152
and from UISelectMany.validateValue JavaDoc:
...Before comparing each option, coerce the option value type to the
type of this component's value following the Expression Language
coercion rules ...
Regards,
Martin Kočí
Jakob Korherr píše v Pá 27. 08. 2010 v 15:31 +0200:
Hi Martin,
The purpose of this conversion is that the value of the SelectItems
may be a String, but the real (already converted) value of the
UISelectMany may be something else, e.g. Float. Imagine the following
scenario:
h:selectManyCheckbox value=#{myBean.inputFloatArray}
f:selectItem itemValue=1.1 /
f:selectItem itemValue=1.2 /
f:selectItem itemValue=1.3 /
/h:selectManyCheckbox
The itemValues of all SelectItems are Strings, but the UISelectMany
points to a property which is of type Float[]. Now because of the fact
that all Strings can be converted into Floats, this scenario must
work.
If you now take a look at _SelectItemsUtil.matchValue(), you can see
that not the component's value, but the value of the SelectItem is
converted via the _ValueConverter:
SelectItem item = selectItemsIter.next();
Object itemValue = item.getValue();
if(converter != null itemValue instanceof String)
{
itemValue = converter.getConvertedValue(context,
(String)itemValue);
}
and then matched against the real value (again which is e.g. Float):
if (value==itemValue || value.equals(itemValue))
{
return true;
}
Furthermore the converter has to be invoked with the wrapped String in
a String[], because UISelectMany.getConvertedValue() needs a
submittedValue of type String[].
Is this clear for you or should I explain it in more detail?
Regards,
Jakob
2010/8/27 Martin Koci martin.k...@aura.cz
Hi,
what is the purpose of _SelectItemsUtil._ValueConverter in
UISelectMany.validateValue(FacesContext, Object) ?
Two weird things:
1) it wraps value into new String[] { value }
2) it calls UISelectMany.this.getConvertedValue and it leads
to
Rendered.getConvertedValue call
I don't see sence in call of
UISelectMany.this.getConvertedValue
because this already done: we are in method validateValue here
and
conversion with Renderer.getConvertedValue is done already.
This causes
calls to Renderer.getConvertedValue during process validation
which is
unintented I think.
Regards,
Martin Kočí
--
Jakob Korherr
blog: http://www.jakobk.com
twitter: http://twitter.com/jakobkorherr
work: http://www.irian.at
--
Jakob Korherr
blog: http://www.jakobk.com
twitter: http://twitter.com/jakobkorherr
work: http://www.irian.at
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
Re: JSF 2.0 and jetty:run
Hi Michi, thanks, that will make it a tad easier for everyone using JSF and Jetty... best regards, Martin On Wed, Aug 18, 2010 at 9:21 PM, Matthias Wessendorf mat...@apache.org wrote: On Wed, Aug 18, 2010 at 8:07 PM, Michael Kurz michi.k...@gmx.at wrote: Patch for [2] is already committed, fast guys over there... +1 they rock and they are fast. thanks for sharing! -M Am 18.08.2010 19:48, schrieb Michael Kurz: Hi, I just saw that my patch for the maven jetty plugin ([1]) was accepted and is integrated in the latest version 7.2.0-SNAPSHOT. It is now possible to run JSF 2.0 projects with mvn jetty:run (at least in theory, there is another bug I provided a patch for [2]). Unfortunately, thre does not seem to be a snapshot repository for Jetty. So, whoever wants to try it has to build it first. cheers Michi [1]: http://jira.codehaus.org/browse/JETTY-1107 [2]: http://jira.codehaus.org/browse/JETTY-1261 -- 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
[jira] Commented: (MYFACES-2861) Remove commons-discovery dependency
[ https://issues.apache.org/jira/browse/MYFACES-2861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12896778#action_12896778 ] Martin Marinschek commented on MYFACES-2861: Hi Leonardo, are you aware that you can exclude transitive dependencies in Maven? see here: http://maven.apache.org/guides/introduction/introduction-to-optional-and-excludes-dependencies.html best regards, Martin Remove commons-discovery dependency --- Key: MYFACES-2861 URL: https://issues.apache.org/jira/browse/MYFACES-2861 Project: MyFaces Core Issue Type: Improvement Components: JSR-314 Affects Versions: 2.0.1 Reporter: Leonardo Uribe Assignee: Leonardo Uribe Fix For: 2.0.2-SNAPSHOT Commons-discovery has a dependency to commons-logging. That cause a transitive dependency to myfaces-impl. To prevent this dependency, we need to move that code into our codebase and refactor it so it uses jul instead. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: MyFaces shipping with JBoss AS6?
Hi guys, sure we would want to have this! @Leonardo: can you take care of this high priority (next to your optimization and performance improvement work)? best regards, Martin On 8/4/10, ssilv...@redhat.com ssilv...@redhat.com wrote: Hi guys, Would you like to see MyFaces Core ship with JBoss AS6? If so, read on. If you've been around MyFaces awhile, you probably remember that JBoass AS used to ship with MyFaces instead of Mojarra. It was regrettable, but at the time Mojarra was far ahead spec-wise and the powers that be decided my time would be better spent integrating Mojarra instead of improving MyFaces. However, with JBoss AS6 M4, this is no longer an either or proposition. Both MyFaces and Mojarra can live side-by-side. The application can decide which implementation to use: http://community.jboss.org/wiki/JSFonJBossAS6 What's more, changing the default JSF implementation for AS6 is just a matter of changing the defaultJSFConfig property in an XML file. I've talked internally at JBoss about adding MyFaces to the JBoss AS community distribution. Some were for it, and some were very, very for it. Nobody so far is against it. The good part is that I don't think it's a lot of work. It's probably just three or four classes that implement SPI's that I'm guessing MyFaces already has. So this is where the MyFaces Dev group comes in. MyFaces Core 2.0 will run OK on JBoss AS6 right now. However, there is some integration work that is needed for full JEE5 and JEE6 compliance. We need: * An injection provider SPI similar to Mojarra's com.sun.faces.spi.InjectionProvider. * The JBoss/MyFaces implementation of the SPI. I expect this will be very similar to org.jboss.web.jsf.integration.injection.JBossDelegatingInjectionProvider. * An AnnotationProvider SPI similar to Mojarra's com.sun.faces.spi.AnnotationProvider. * A JBoss/MyFaces implementation of the SPI similar to org.jboss.web.jsf.integration.config.JBossAnnotationProvider. * A ServletContextListener class to call for initialization. I expect this will extend from MyFacesServletContextListener and be very similar to org.jboss.web.jsf.integration.config.JBossMojarra20ConfigureListener. If MyFaces Dev decides to take this on, then the code will probably live at Apache and I'll bring it into JBoss AS using Maven. I don't have time to write and maintain the code myself but I'm happy to help out with guidance and to do some refactoring of my code to make this easier. BTW, the JBoss/Mojarra integration code lives here: http://anonsvn.jboss.org/repos/jbossas/projects/jboss-jsf-int/trunk/jboss-faces/ Lastly, let me say that I can't make hard promises right now. I don't know if someone at JBoss/RedHat will come along and nix the idea. However, even if we can't ship MyFaces you will have all the integration points ready and have an easy way to drop in MyFaces whenever you want to use it with JBoss AS. WDYT?? -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: Ann: MyFaces Ajax Fileupload and how to use it
Hi guys,
I am saying this in a broader scope - not only for the AJAX features.
But our AJAX features which do make sense out of the box (and this one
does) could also be enabled like this.
best regards,
Martin
On 8/2/10, Werner Punz werner.p...@gmail.com wrote:
Hi Martin this would make only sense if we had a bunch of features which
can be turned on via such a switch, which we don´t from my perspective
because the queue control features which we have internally
cannot be turned on switch like but have to be configured with params
like myfaces.config.delay = 300
What maybe would make sense is some kind of myfaces:ajax tag which is an
extended f:ajax tag which exposes all new features.
something along the lines of
myfaces:ajax delay=300 timeout200 execute=... render=... /
Werner
Am 01.08.10 21:42, schrieb Martin Marinschek:
Perfect.
Can we talk about having the context param STRICT_COMPATIBILITY_MODE
again, where this is disabled, and if the param is set to false, this
feature is enabled?
best regards,
Martin
On 7/30/10, Jakob Korherrjakob.korh...@gmail.com wrote:
Really great, Werner!
2010/7/30 Hazem Salehhaz...@apache.org
Wonderful!
On Fri, Jul 30, 2010 at 2:10 PM, Matthias Wessendorf
mat...@apache.orgwrote:
kick ass!
great stuff, Werner!
-Matthias
On Fri, Jul 30, 2010 at 12:58 PM, Werner Punzwerner.p...@gmail.com
wrote:
Hello, as some people might have noticed I recently integrated the
Ajax
fileupload into our trunk (2.0.2-SNAPSHOT), I also gave the code to
the
JSF
EG so that it might be part of JSF 2.1 or the base for a similar
functionality.
The code changes itself are:
a) A small patch on the myfaces side to detect the partoal fileupload
case
as ajax cycle
b) Extensions to our scripts which currently are only enabled in dev
mode
(it still is up for discussion whether we should enable it for prod or
not
since they are non standard)
Here is what you have to do:
First turn your server on into development mode via:
context-param
param-namejavax.faces.PROJECT_STAGE/param-name
param-valueDevelopment/param-value
/context-param
Then use the code like I do in my working testcase:
http://www.pastebin.org/432572
the important thing is following line:
script type=text/javascript
myfaces.config = myfaces.config || {};
myfaces.config[transportAutoSelection] = true;
/script
This enables the auto transport selection, which switches to an iframe
submit in case of a file uploading form submit.
This switch cannot be enabled by default because it would break the
spec
requirements that an xhr post has to be performed at all costs.
Also xhr level2 is out of the question for now because it is only
supported
by the newest browsers.
After that it is straight forward, you can use the fileupload
component
from
Tomahawk 2 for instance, it should work straight out of the box.
I also did a servlet 3.0 fileupload component for prototyping but the
code
is too flakey yet (mainly due to spec deficits less due to the
component
itself) and I cannot really commit it into the core. Instead I made
sure
that the standard fileupload components perform ok.
So it is ready to be used at least from my point of view, but have in
mind
all this will break compatibility to Mojarra if you use it.
So using it means you are bound to MyFaces, which is something I do
not
particularily recommend (hence also donating the prototype code to the
EG, I
want something like this in the spec)
Here again is the pastebin to all relevant files:
http://www.pastebin.org/432572
http://www.pastebin.org/432586 for the relevant bean.
If your fileupload is correctly configured this code should work out
of
the
box.
Werner
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
--
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
Web blog: http://hazems.blogetery.com/
[Web 2.0] Mashups Integration with JSF:
http://code.google.com/p/mashups4jsf/
--
Jakob Korherr
blog: http://www.jakobk.com
twitter: http://twitter.com/jakobkorherr
work: http://www.irian.at
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
Re: [GSOC] State saving status after first improvements
Hi guys, stateHelper.remove() doesn't remove the value but replaces it with null. And also, as I understand, saving the null values in the state helper can't be removed. why is this? best regards, Martin On Fri, Jul 23, 2010 at 1:27 PM, Martin Marinschek mmarinsc...@apache.orgwrote: +1! tell us how much this changes... best regards, Martin On Fri, Jul 23, 2010 at 12:23 PM, Marius Petoi marius.pe...@codebeat.ro wrote: Hello, These values are written by default in the processDecodes() and updateModel() methods. This is before the state is written. One thing that we could do is in the saveState method to check whether the values for the attributes are the default ones and remove them from the StateHelper, so that they don't get saved. Upon restore, we look if the values are in the state and if not, initialize them with the default values. Regards, Marius On Fri, Jul 23, 2010 at 11:01 AM, Martin Marinschek mmarinsc...@apache.org wrote: Hi Marius, The state of a typical input text contains the following 4 attributes (both the keys and the values): valid, value, localValueSet and submittedValue. Value and submittedValue may be null, in this case only the keys are contained in the state. Valid and localValueSet are boolean properties. I measured the state of an input text to be approximately 300 B. If this is in a table, you need to multiply it by the number of rows in that table. why are the keys contained in the state if the thing is null? null is the default value, we should probably not state save this case. Same with the default values of valid and localValueSet... best regards, Martin On Fri, Jul 23, 2010 at 6:07 AM, Martin Marinschek mmarinsc...@apache.org wrote: Hi guys, Unfortunately, try to save the state directly on the child components is not possible. The problem is the datatable is the one who know about the rows, so the right place for save this information (at least the delta information) is there. But the initial state could be saved on the children if some additional methods are provided. I don't know if it is worth to add those methods, because the only one interested to save the initial state is the datatable (things are different if the children could use that information to reset the current state, maybe a method called resetInitialState). My first solution for partial state saving used a protected variable to save the initial state on the children, but after look the latest solution I'm inclined to implement the latest one. Leonardo is right - I don´t see a way to do this either. Additionally, I don´t think changing the location will buy any major reductions. For the state of a normal input text - what exactly does it consist of, highlight the size of each of the parts. best regards, Martin On Wed, Jul 21, 2010 at 7:51 PM, Leonardo Uribe lu4...@gmail.com wrote: Hi Marius, Martin Yes, it is a bug. The problem is related to some changes done on MYFACES-2754. I think that this changes was tested against jsp but not against facelets. I reverted the changes so you can test now. regards, Leonardo Uribe 2010/7/21 Martin Marinschek mmarinsc...@apache.org Hi Marius, ok, Leonardo will hopefully take a look - for you to continue: just post the partial state values for typical pages right now (you can also take the pages of the sample as a base if you want). best regards, Martin On Wed, Jul 21, 2010 at 3:23 PM, Marius Petoi marius.pe...@codebeat.ro wrote: Hello, As I see, in JspStateManagerImpl.saveSerializedView (actually in the isWritingState() method), there is a check whether the JSP_IS_WRITING_STATE_ATTR is set in the FacesContext. But this attribute is set in ViewHandlerImpl.setWritingState() if there is no StateWriter defined (if the current view is a jsp). So, in my opinion, the verification in the JspStateManagerImpl.isWritingState() should also include the verification of the StateWriter. Otherwise, full state saving will work only for JSP-s. Regards, Marius On Wed, Jul 21, 2010 at 3:49 PM, Martin Marinschek mmarinsc...@apache.org wrote: Hi Marius -- Full state saving means setting the context parameter javax.faces.PARTIAL_STATE_SAVING to false. This is all, right? I've noticed that just by doing this, the xhtml pages don't work anymore...only the jsp-s. There is no state saved in xhtml-s. Am I missing something? Oh my. That´s a bug then. Leonardo, can you look into this (not that I
Re: Ann: MyFaces Ajax Fileupload and how to use it
Perfect.
Can we talk about having the context param STRICT_COMPATIBILITY_MODE
again, where this is disabled, and if the param is set to false, this
feature is enabled?
best regards,
Martin
On 7/30/10, Jakob Korherr jakob.korh...@gmail.com wrote:
Really great, Werner!
2010/7/30 Hazem Saleh haz...@apache.org
Wonderful!
On Fri, Jul 30, 2010 at 2:10 PM, Matthias Wessendorf
mat...@apache.orgwrote:
kick ass!
great stuff, Werner!
-Matthias
On Fri, Jul 30, 2010 at 12:58 PM, Werner Punz werner.p...@gmail.com
wrote:
Hello, as some people might have noticed I recently integrated the Ajax
fileupload into our trunk (2.0.2-SNAPSHOT), I also gave the code to the
JSF
EG so that it might be part of JSF 2.1 or the base for a similar
functionality.
The code changes itself are:
a) A small patch on the myfaces side to detect the partoal fileupload
case
as ajax cycle
b) Extensions to our scripts which currently are only enabled in dev
mode
(it still is up for discussion whether we should enable it for prod or
not
since they are non standard)
Here is what you have to do:
First turn your server on into development mode via:
context-param
param-namejavax.faces.PROJECT_STAGE/param-name
param-valueDevelopment/param-value
/context-param
Then use the code like I do in my working testcase:
http://www.pastebin.org/432572
the important thing is following line:
script type=text/javascript
myfaces.config = myfaces.config || {};
myfaces.config[transportAutoSelection] = true;
/script
This enables the auto transport selection, which switches to an iframe
submit in case of a file uploading form submit.
This switch cannot be enabled by default because it would break the
spec
requirements that an xhr post has to be performed at all costs.
Also xhr level2 is out of the question for now because it is only
supported
by the newest browsers.
After that it is straight forward, you can use the fileupload component
from
Tomahawk 2 for instance, it should work straight out of the box.
I also did a servlet 3.0 fileupload component for prototyping but the
code
is too flakey yet (mainly due to spec deficits less due to the
component
itself) and I cannot really commit it into the core. Instead I made
sure
that the standard fileupload components perform ok.
So it is ready to be used at least from my point of view, but have in
mind
all this will break compatibility to Mojarra if you use it.
So using it means you are bound to MyFaces, which is something I do not
particularily recommend (hence also donating the prototype code to the
EG, I
want something like this in the spec)
Here again is the pastebin to all relevant files:
http://www.pastebin.org/432572
http://www.pastebin.org/432586 for the relevant bean.
If your fileupload is correctly configured this code should work out of
the
box.
Werner
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
--
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
Web blog: http://hazems.blogetery.com/
[Web 2.0] Mashups Integration with JSF:
http://code.google.com/p/mashups4jsf/
--
Jakob Korherr
blog: http://www.jakobk.com
twitter: http://twitter.com/jakobkorherr
work: http://www.irian.at
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
Re: Use maven-shade-plugin to prevent duplicate code
So - without the dependencies problem - +100 for getting rid of shared. The sooner this goes, the better. But, of course: make sure the shade thing runs smoothly with the IDE integration (I want to be able to check-out the sample app and start working, highly favored best case: without having to do a full maven build after each change). And, of course, make sure there is no issues with the deployment or circular dependencies... I am sure you guys will be able to sort this out ;) best regards, Martin On Mon, Jul 26, 2010 at 11:33 PM, Jan-Kees Van Andel jankeesvanan...@gmail.com wrote: I think you're right. The only real solution is a nice and clean Shared project. Otherwise the dependencies will become very tangled. /JK Sent from my iPad Op 26 jul. 2010 om 23:10 heeft Leonardo Uribe lu4...@gmail.com het volgende geschreven: Hi 2010/7/26 Jakob Korherr jakob.korh...@gmail.com This code is just some wrappers and it is not expected this will change in the future. So the question is why bother us in this case? In this case use maven-shade-plugin is not worth. Actually and quite frankly it really is worth it. It is very easy and if you understand it, it is even easier than just copy past, because you don't have to change packages manually. Furthermore, if you look at those classes, they have been refactored a couple of times from the very beginning (myfaces 1.1). In addition, there will surely be myfaces-test versions for JSF 2.1 (and 2.2, 3.0,...) and then you will always have to copy those classes and hope nothing will change. If you use the shade-plugin, you can throw your worries away! Myfaces-test uses myfaces-builder-plugin unpack goal to share code between versions, so the wrappers will be only on myfaces-test12. I'm worried about a possible circular dependency between myfaces core and myfaces test. The wrappers are on myfaces-core, but myfaces-test requires core wrappers to be build, but we require myfaces-test on core to run some tests, so which one should be compiled first? which one should be released first?. When you execute maven release plugin, it is necessary to change versions to the release ones, so do that will cause a lot of problems on release. regards, Leonardo Regards, Jakob 2010/7/26 Mark Struberg strub...@yahoo.de I think you are both right. I can understand that copying code is really ugly, but otoh Leos argument is also pretty strong. There is a solution for this. Cut off the shared parts and move it into an own module. This sounds easy but isn't always doable. But it might be worth a try. LieGrue, strub From: Jakob Korherr jakob.korh...@gmail.com To: MyFaces Development dev@myfaces.apache.org Sent: Mon, July 26, 2010 10:32:31 PM Subject: Re: Use maven-shade-plugin to prevent duplicate code Why would you like to have any duplicate code? This should not be anyone's target in my opinion... 2010/7/26 Leonardo Uribe lu4...@gmail.com Hi Yes, it is true, that myfaces-test is used for testing myfaces core, but in theory, myfaces-test should be used to test jsf stuff without rely on a specific jsf implementation. In this case I think (and it is my personal opinion) it is better to have some duplicate code and keep things simple. Use maven-shade-plugin to deal with shared code is another different history. regards, Leonardo Uribe 2010/7/26 Jakob Korherr jakob.korh...@gmail.com Actually this already is the case: MyFaces-test is used for testing MyFaces core. Regards, Jakob 2010/7/26 Rudy De Busscher rdebussc...@gmail.com Hi Jakob, So it was never the idea that MyFaces Test (and maybe the GSOC testing effort) will be used to supply the test infrastructure for MyFaces Core? In that case : MyFaces Core can supply code. Regards Rudy. On 26 July 2010 22:01, Jakob Korherr jakob.korh...@gmail.com wrote: Hi Rudy, Yes we totally have to be careful with circular dependencies, but it should not be that big problem. Actually I think that the opposite is true. MyFaces core is the JSF implementation and MyFaces test provides the Mock classes for JSF, and for implementing these Mock classes it can reuse some functionality already present in MyFaces core (e.g. the real classes which should be mocked). IMO this is the way it should be. Regards, Jakob 2010/7/26 Rudy De Busscher rdebussc...@gmail.com Hi all, I agree, duplicated code has to be avoided and when the maven-shade-plugin can help, the better. but I think we have to define which project supplies code for which other project (so that we don't get a spaghetti (using the tomatoes ;) or get circular dependencies.). I know that MyFaces core exists much longer then MyFaces Test but I find it more logic that the MyFaces Test supplies code for the MyFaces Core project. my 2c. Regards Rudy On 26 July 2010 21:40,
Re: [GSOC] State saving status after first improvements
Hi Marius, The state of a typical input text contains the following 4 attributes (both the keys and the values): valid, value, localValueSet and submittedValue. Value and submittedValue may be null, in this case only the keys are contained in the state. Valid and localValueSet are boolean properties. I measured the state of an input text to be approximately 300 B. If this is in a table, you need to multiply it by the number of rows in that table. why are the keys contained in the state if the thing is null? null is the default value, we should probably not state save this case. Same with the default values of valid and localValueSet... best regards, Martin On Fri, Jul 23, 2010 at 6:07 AM, Martin Marinschek mmarinsc...@apache.org wrote: Hi guys, Unfortunately, try to save the state directly on the child components is not possible. The problem is the datatable is the one who know about the rows, so the right place for save this information (at least the delta information) is there. But the initial state could be saved on the children if some additional methods are provided. I don't know if it is worth to add those methods, because the only one interested to save the initial state is the datatable (things are different if the children could use that information to reset the current state, maybe a method called resetInitialState). My first solution for partial state saving used a protected variable to save the initial state on the children, but after look the latest solution I'm inclined to implement the latest one. Leonardo is right - I don´t see a way to do this either. Additionally, I don´t think changing the location will buy any major reductions. For the state of a normal input text - what exactly does it consist of, highlight the size of each of the parts. best regards, Martin On Wed, Jul 21, 2010 at 7:51 PM, Leonardo Uribe lu4...@gmail.com wrote: Hi Marius, Martin Yes, it is a bug. The problem is related to some changes done on MYFACES-2754. I think that this changes was tested against jsp but not against facelets. I reverted the changes so you can test now. regards, Leonardo Uribe 2010/7/21 Martin Marinschek mmarinsc...@apache.org Hi Marius, ok, Leonardo will hopefully take a look - for you to continue: just post the partial state values for typical pages right now (you can also take the pages of the sample as a base if you want). best regards, Martin On Wed, Jul 21, 2010 at 3:23 PM, Marius Petoi marius.pe...@codebeat.ro wrote: Hello, As I see, in JspStateManagerImpl.saveSerializedView (actually in the isWritingState() method), there is a check whether the JSP_IS_WRITING_STATE_ATTR is set in the FacesContext. But this attribute is set in ViewHandlerImpl.setWritingState() if there is no StateWriter defined (if the current view is a jsp). So, in my opinion, the verification in the JspStateManagerImpl.isWritingState() should also include the verification of the StateWriter. Otherwise, full state saving will work only for JSP-s. Regards, Marius On Wed, Jul 21, 2010 at 3:49 PM, Martin Marinschek mmarinsc...@apache.org wrote: Hi Marius -- Full state saving means setting the context parameter javax.faces.PARTIAL_STATE_SAVING to false. This is all, right? I've noticed that just by doing this, the xhtml pages don't work anymore...only the jsp-s. There is no state saved in xhtml-s. Am I missing something? Oh my. That´s a bug then. Leonardo, can you look into this (not that I desperately need full state saving, but some users might need it)? best regards, Martin On Tue, Jul 20, 2010 at 2:46 PM, Marius Petoi marius.pe...@codebeat.ro wrote: Hi Leonardo, So you are working on UIData at the moment. What about UIRepeat? I see that partial state saving is not implemented in UIRepeat components. We could improve the _childState table (which is included in the saved state) to save only the states which are different from an initial state (like in UIData components). Regards, Marius On Mon, Jul 19, 2010 at 1:46 PM, Leonardo Uribe lu4...@gmail.com wrote: Hi Marius Right now I'm working on MYFACES-2616 Fix UIData state saving model (spec issue 153). I hope to attach some new patches, a example and a better documentation in that issue soon, so we can review it and make comments. regards, Leonardo Uribe 2010/7/19 Marius Petoi marius.pe...@codebeat.ro Hi Martin, Regarding state saving in tables, here are my observations and comments: - there is no state saved in relation to the UIData objects
Re: [GSOC] State saving status after first improvements
+1! tell us how much this changes... best regards, Martin On Fri, Jul 23, 2010 at 12:23 PM, Marius Petoi marius.pe...@codebeat.ro wrote: Hello, These values are written by default in the processDecodes() and updateModel() methods. This is before the state is written. One thing that we could do is in the saveState method to check whether the values for the attributes are the default ones and remove them from the StateHelper, so that they don't get saved. Upon restore, we look if the values are in the state and if not, initialize them with the default values. Regards, Marius On Fri, Jul 23, 2010 at 11:01 AM, Martin Marinschek mmarinsc...@apache.org wrote: Hi Marius, The state of a typical input text contains the following 4 attributes (both the keys and the values): valid, value, localValueSet and submittedValue. Value and submittedValue may be null, in this case only the keys are contained in the state. Valid and localValueSet are boolean properties. I measured the state of an input text to be approximately 300 B. If this is in a table, you need to multiply it by the number of rows in that table. why are the keys contained in the state if the thing is null? null is the default value, we should probably not state save this case. Same with the default values of valid and localValueSet... best regards, Martin On Fri, Jul 23, 2010 at 6:07 AM, Martin Marinschek mmarinsc...@apache.org wrote: Hi guys, Unfortunately, try to save the state directly on the child components is not possible. The problem is the datatable is the one who know about the rows, so the right place for save this information (at least the delta information) is there. But the initial state could be saved on the children if some additional methods are provided. I don't know if it is worth to add those methods, because the only one interested to save the initial state is the datatable (things are different if the children could use that information to reset the current state, maybe a method called resetInitialState). My first solution for partial state saving used a protected variable to save the initial state on the children, but after look the latest solution I'm inclined to implement the latest one. Leonardo is right - I don´t see a way to do this either. Additionally, I don´t think changing the location will buy any major reductions. For the state of a normal input text - what exactly does it consist of, highlight the size of each of the parts. best regards, Martin On Wed, Jul 21, 2010 at 7:51 PM, Leonardo Uribe lu4...@gmail.com wrote: Hi Marius, Martin Yes, it is a bug. The problem is related to some changes done on MYFACES-2754. I think that this changes was tested against jsp but not against facelets. I reverted the changes so you can test now. regards, Leonardo Uribe 2010/7/21 Martin Marinschek mmarinsc...@apache.org Hi Marius, ok, Leonardo will hopefully take a look - for you to continue: just post the partial state values for typical pages right now (you can also take the pages of the sample as a base if you want). best regards, Martin On Wed, Jul 21, 2010 at 3:23 PM, Marius Petoi marius.pe...@codebeat.ro wrote: Hello, As I see, in JspStateManagerImpl.saveSerializedView (actually in the isWritingState() method), there is a check whether the JSP_IS_WRITING_STATE_ATTR is set in the FacesContext. But this attribute is set in ViewHandlerImpl.setWritingState() if there is no StateWriter defined (if the current view is a jsp). So, in my opinion, the verification in the JspStateManagerImpl.isWritingState() should also include the verification of the StateWriter. Otherwise, full state saving will work only for JSP-s. Regards, Marius On Wed, Jul 21, 2010 at 3:49 PM, Martin Marinschek mmarinsc...@apache.org wrote: Hi Marius -- Full state saving means setting the context parameter javax.faces.PARTIAL_STATE_SAVING to false. This is all, right? I've noticed that just by doing this, the xhtml pages don't work anymore...only the jsp-s. There is no state saved in xhtml-s. Am I missing something? Oh my. That´s a bug then. Leonardo, can you look into this (not that I desperately need full state saving, but some users might need it)? best regards, Martin On Tue, Jul 20, 2010 at 2:46 PM, Marius Petoi marius.pe...@codebeat.ro wrote: Hi Leonardo, So you are working on UIData at the moment. What about UIRepeat? I see that partial state saving is not implemented in UIRepeat components. We could improve the _childState table (which
Re: Fixing ResponseWriter.startCDATA/endCDATA
On Fri, Jul 23, 2010 at 2:40 PM, Matthias Wessendorf mat...@apache.org wrote: On Fri, Jul 23, 2010 at 2:30 PM, Bruno Aranda brunoara...@gmail.com wrote: Yeah Werner, you should take holidays seriously :) +1 ESPECIALLY this kind of holidays - a honeymoon ;) best regards, Martin On 23 July 2010 13:28, Werner Punz werner.p...@gmail.com wrote: Hi I have written a load of tests for the PPR responsewriter to have it covered, but I will do some additional testing mid next week (and will commit those tests) if the ppr responsewriter still behaves as it should after the patch. Since we are not in the middle of another release I can guess the additional testing on the ppr responsewriter can wait a little bit. If anything negative comes out I probably can fix it on the ppr writers side. Werner Am 23.07.10 13:05, schrieb Matthias Wessendorf: re-tested; works fine with your patch as well On Fri, Jul 23, 2010 at 11:37 AM, Bruno Arandabrunoara...@gmail.com wrote: Hi, But the patch had not been checked it yet? Or did you patch it before trying the tests? In any case, I have committed it just now, all myfaces tests pass. Cheers! Bruno On 23 July 2010 08:26, Matthias Wessendorfmat...@apache.org wrote: I just tested 2.0.2-SNAPSHOT with our internal version of ADF Faces, that runs on JSF2. My jetty powered environment gives me no errors with our latest trunk... -Matthias On Thu, Jul 22, 2010 at 9:36 PM, Werner Punzwerner.p...@gmail.com wrote: Btw. one issue about this, check if your fix does not break anything in the ppr case. The problem is that the ppr responseWriter simply delegates the HtmlResponseWriterImpl, but the issue is that CDATA blocks are automatically opened before any html is rendered, any valid CDATA block inside should not be swallowed but escaped in that case. So a ppr response looks like this changes update id=bla![CDATA[div id=bla /div ]]/update The problem is that per spec definition the xhr response must be xml and any html must be embedded within CDATA blocks, now if there is another CDATA block within the valid html it must be preserved at all costs because it is vital that it is properly rendered at the ppr update time (hence the complicated escaping in my code) Werner Am 22.07.10 21:31, schrieb Werner Punz: Ok point taken, yes the HTMLResponseWriterImpl definitely is html so a fix there is valid. Werner Am 22.07.10 20:11, schrieb Bruno Aranda: But we are talking about the HtmlResponseWriterImpl, which outputs HTML. The fix I have done is in that class and it only checks if there is a CDATA already started before starting one when writing the scripts. It is slightly different to the original problem (about the HtmlResponse, which is different from the one in Mojarra). The fix simply checks if there is the CDATA around the script before opening another one inside the script. I think it is OK if we just do not nest CDATAs in the HTML response, even if it was allowed. And this fixes the problems with PrimeFaces too, without having to change the ResponseWriter or the PartialResponseWriterImpl... Bruno On 22 July 2010 16:59, Werner Punzwerner.p...@gmail.com mailto:werner.p...@gmail.com wrote: Hia guys please also read up on my jira response. The entire thing is not as easy as it seems, because there are various ways a cdata block can be opened, first you can do it via startCDATA secondly you can do it via a direct write. I did some kind of double buffering in case of a cdata block was opened and then escaped the ]] as multiple cdata blocks (the jira response explains the technique exactly) And yes there is somewhat a speed hit because of this, but in case of the partial response writer I did not have a chance because: But the partial response writer is somewhat different, because it has to press html code in a valid xml response format, so nested cdata blocks can occur naturally, the normal response writer is somewhat different because nested cdata blocks are only forbidden for xmlish output dialects others might allow it. Werner Am 22.07.10 17:47, schrieb Mark Struberg: But isn't the patch of Marcus Büttner doing this by maintaining a reference counter? Another question: how is the performance of all this scanning/dynamic replacement? LieGrue, strub From: Bruno Arandabrunoara...@gmail.com mailto:brunoara...@gmail.com To: MyFaces Developmentdev@myfaces.apache.org mailto:dev@myfaces.apache.org Sent: Thu, July 22, 2010 5:26:35 PM Subject: Re: Fixing ResponseWriter.startCDATA/endCDATA Further investigation of this incompatibility problem with myfaces leads me to the fact that in the HtmlResponseWriterImpl, when we write the content of a script, we create a CDATA element without checking if is nested at all. That is a problem, because if we use the standard response writer and we write a script section inside a CDATA
Re: [COMMUNITY] MyFaces += Ali Ok
Welcome Ali! Still have to look through all of the stuff that you have already done, but I am sure I will get to it... best regards, Martin On Thu, Jul 22, 2010 at 2:01 PM, Ali Ok al...@aliok.com.tr wrote: I have to say I am very honored. Thanks again for inviting me. Let's have fun and develop great software :) Greetings, Ali On Thu, Jul 22, 2010 at 2:54 PM, Jakob Korherr jakob.korh...@gmail.com wrote: Welcome, Ali :) Regards, Jakob 2010/7/22 Hazem Saleh haz...@apache.org Congratulations and welcome! On Thu, Jul 22, 2010 at 2:38 PM, Gerhard Petracek gerhard.petra...@gmail.com wrote: welcome! regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2010/7/22 Matthias Wessendorf mat...@apache.org The Myfaces PMC is proud to announce a new addition to our community. Please welcome Ali Ok as the newest MyFaces committer! Ali is an active member of the myfaces community, especially on MyFaces core and the HTML5 (gsoc) subproject. @Ali: Please add yourself to the Master-POM at https://svn.apache.org/repos/asf/myfaces/myfaces-master-pom/trunk/pom.xml -Matthias -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- 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 Web blog: http://hazems.blogetery.com/ [Web 2.0] Mashups Integration with JSF: http://code.google.com/p/mashups4jsf/ -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at -- My Blog: http://blog.aliok.com.tr Twitter: http://twitter.com/aliok_tr -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: [GSOC] State saving status after first improvements
Hi guys, Unfortunately, try to save the state directly on the child components is not possible. The problem is the datatable is the one who know about the rows, so the right place for save this information (at least the delta information) is there. But the initial state could be saved on the children if some additional methods are provided. I don't know if it is worth to add those methods, because the only one interested to save the initial state is the datatable (things are different if the children could use that information to reset the current state, maybe a method called resetInitialState). My first solution for partial state saving used a protected variable to save the initial state on the children, but after look the latest solution I'm inclined to implement the latest one. Leonardo is right - I don´t see a way to do this either. Additionally, I don´t think changing the location will buy any major reductions. For the state of a normal input text - what exactly does it consist of, highlight the size of each of the parts. best regards, Martin On Wed, Jul 21, 2010 at 7:51 PM, Leonardo Uribe lu4...@gmail.com wrote: Hi Marius, Martin Yes, it is a bug. The problem is related to some changes done on MYFACES-2754. I think that this changes was tested against jsp but not against facelets. I reverted the changes so you can test now. regards, Leonardo Uribe 2010/7/21 Martin Marinschek mmarinsc...@apache.org Hi Marius, ok, Leonardo will hopefully take a look - for you to continue: just post the partial state values for typical pages right now (you can also take the pages of the sample as a base if you want). best regards, Martin On Wed, Jul 21, 2010 at 3:23 PM, Marius Petoi marius.pe...@codebeat.ro wrote: Hello, As I see, in JspStateManagerImpl.saveSerializedView (actually in the isWritingState() method), there is a check whether the JSP_IS_WRITING_STATE_ATTR is set in the FacesContext. But this attribute is set in ViewHandlerImpl.setWritingState() if there is no StateWriter defined (if the current view is a jsp). So, in my opinion, the verification in the JspStateManagerImpl.isWritingState() should also include the verification of the StateWriter. Otherwise, full state saving will work only for JSP-s. Regards, Marius On Wed, Jul 21, 2010 at 3:49 PM, Martin Marinschek mmarinsc...@apache.org wrote: Hi Marius -- Full state saving means setting the context parameter javax.faces.PARTIAL_STATE_SAVING to false. This is all, right? I've noticed that just by doing this, the xhtml pages don't work anymore...only the jsp-s. There is no state saved in xhtml-s. Am I missing something? Oh my. That´s a bug then. Leonardo, can you look into this (not that I desperately need full state saving, but some users might need it)? best regards, Martin On Tue, Jul 20, 2010 at 2:46 PM, Marius Petoi marius.pe...@codebeat.ro wrote: Hi Leonardo, So you are working on UIData at the moment. What about UIRepeat? I see that partial state saving is not implemented in UIRepeat components. We could improve the _childState table (which is included in the saved state) to save only the states which are different from an initial state (like in UIData components). Regards, Marius On Mon, Jul 19, 2010 at 1:46 PM, Leonardo Uribe lu4...@gmail.com wrote: Hi Marius Right now I'm working on MYFACES-2616 Fix UIData state saving model (spec issue 153). I hope to attach some new patches, a example and a better documentation in that issue soon, so we can review it and make comments. regards, Leonardo Uribe 2010/7/19 Marius Petoi marius.pe...@codebeat.ro Hi Martin, Regarding state saving in tables, here are my observations and comments: - there is no state saved in relation to the UIData objects. - the states saved for the children of the UIData objects (the components in the tables) are irrelevant. They are not used afterwards, as the components are initialized at each request with default values and the state saved corresponds to the last modifications of the component (to the row which was last set via the setRowIndex() method). - every time the setRowIndex() method is invoked with the -1 parameter, _initialDescendantComponentState is initialized. This will no longer be necessary, as the initial state will be restored from the previously saved state. - the _rowStates array of states is constructed using partial state. This means that only states for the rows which are different from the template are saved in this array. In my opinion, this is what needs to be saved for the UIData. The children component
Re: [Trinidad][api]TRINIDAD-1857 Add a Map associated with each window or tab that the user is interacting with
Hi guys, right now for this feature, I think a close integration to Trinidad does make sense, since we already have window handling, including lifecycle and an (complete) event system. Hence the proposed API is just a small addition. certainly this makes sense from your current point of view - but it does not help you with more people adopting Trinidad. Trinidad is already widely seen as a rather monolithic block of something which is just too large - splitting this up into parts which deal with clearly defined responsibilitiies would make a lot more sense. I am not saying you can add a small API more to this monolithic block, I am just saying it would make sense to at one point of time split this up into something which is reusable elsewhere in the world. And if you put your ASF hat on, Matthias, you know this ;) best regards, Martin 2010/7/19 Blake Sullivan blake.sulli...@oracle.com Thanks Gerhard. Did you want Trinidad to be configurable to delegate to Orchestra if its available, in this case? -- Blake Sullivan On Jul 19, 2010, at 12:23 AM, Gerhard Petracek wrote: hi blake, it's similar to the conversation context id of orchestra - we just have an id for every window. (in case o...@windowscoped we just add a component to the view-root (before the page gets rendered). the window id is stored as state of the component. in case of jsf 1.2 and redirects we need an url parameter for the get-request. the implementation is pluggable - so it's possible to provide a custom implementation for storing and restoring the information. in case of jsf 2.0+ and redirects you won't see an url parameter. in this case we use the flash scope to store the required information.) i'll add all the details to the wiki page [1]. i've finished the implementation of the first draft by the end of last week. so i've to cleanup some parts and i've to write further javadoc and documentation. regards, gerhard [1] http://wiki.apache.org/myfaces/Extensions/CDI/DevDoc/Conversations http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2010/7/19 Blake Sullivan blake.sulli...@oracle.com What code actually associates the scope with the browser windows? For example, in Trinidad, we have a WindowManager tasked with that job. -- Blake Sullivan On Jul 17, 2010, at 1:47 PM, Gerhard Petracek wrote: hi blake, @WindowScoped (provided by myfaces codi) is a portable extension for cdi. therefore not every project will be able to use it. anyway, imo it would be better to provide a cdi independent version of it e.g. in myfaces-orchestra and/or myfaces-commons. regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2010/7/17 Jakob Korherr jakob.korh...@gmail.com Hi Blake, Just FYI: we have also implemented a window scope for MyFaces Codi (ext-cdi). Maybe you want to take a look at it ;) Regards, Jakob 2010/7/17 Blake Sullivan blake.sulli...@oracle.com We currently have scopes for: Application Session PageFlow View I propose that we add a Map associated with each window or tab that the user is interacting with. This would slop into the scope hierarchy between the Session and PageFlow scopes. We would also expose the storage for the current window on the RequestContext. If no WindowManager was exposed and therefore there was no current Window, this Map would be the SessionMap. For high availability, each of the attributes stored in a Window's map would be stored as separate attributes in the Session. At least initially, we would not expose this map directly through its own top-level windowScope EL property. Proposed apis: RequestContext: /** * Returns a Map of objects associated with the current window if any. If there is no * current window, the Session Map is returned. * @return Map for storing objects associated with the current window. * @see org.apache.myfaces.trinidad.context.Window#getWindowMap */ public MapString, Object getWindowMap() Window /** * Returns the Map for storing data associated with this Window object. If the environment is * configured for fail-over, the contents of this Map must be Serializable. * @return The client data storage Map. */ public abstract MapString, Object getWindowMap(); Since we would provide a default implementation of getWindowMap using import org.apache.myfaces.trinidadinternal.util.SubKeyMap, we would also have to make SubKeyMap public as well. -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- http://www.irian.at
Re: [Trinidad][api]TRINIDAD-1857 Add a Map associated with each window or tab that the user is interacting with
Hi Matthias, Not everybody is using CDI and/or Spring. well, in the real world and a little while in the future, there is not many people who will not have one of these frameworks in their applications. I think, on long term we may want one clean and independent API, where all these projects offer an implementation for a window/event system: -CODI -Orchestra -Trinidad -etc However, right now, Trinidad has the base already and adding a new toolset to the belt feels kinda wrong. Again +1 on this to be inside of Trinidad. This does not mean that we could work on a better future version of a more unified API, for this. Right? yes, this is what we could and what we should. Why not take this addition as a reason to do this right now? If we don´t take such additions as a reason to do this, what else will be our reason? best regards, Martin -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: [GSOC] State saving performance improvements in MyFaces 2.0
Hi guys, I didn´t follow this in absolute detail anymore right now, but: I do not think we should think about serializing MethodExpressions or ValueExpressions - IMHO, MethodExpressions or ValueExpressions should never be part of the partial state, cause a user will never change them programmatically (well, maybe in a very obscure corner case, but not generally). Additionally, ValueExpression and MethodExpression are not implemented by us, so how can you implement StateHolder in this classes? Only in classes containing ValueExpressions, right? best regards, Martin
Re: [GSOC] State saving status after first improvements
Hi Marius -- Full state saving means setting the context parameter javax.faces.PARTIAL_STATE_SAVING to false. This is all, right? I've noticed that just by doing this, the xhtml pages don't work anymore...only the jsp-s. There is no state saved in xhtml-s. Am I missing something? Oh my. That´s a bug then. Leonardo, can you look into this (not that I desperately need full state saving, but some users might need it)? best regards, Martin On Tue, Jul 20, 2010 at 2:46 PM, Marius Petoi marius.pe...@codebeat.ro wrote: Hi Leonardo, So you are working on UIData at the moment. What about UIRepeat? I see that partial state saving is not implemented in UIRepeat components. We could improve the _childState table (which is included in the saved state) to save only the states which are different from an initial state (like in UIData components). Regards, Marius On Mon, Jul 19, 2010 at 1:46 PM, Leonardo Uribe lu4...@gmail.com wrote: Hi Marius Right now I'm working on MYFACES-2616 Fix UIData state saving model (spec issue 153). I hope to attach some new patches, a example and a better documentation in that issue soon, so we can review it and make comments. regards, Leonardo Uribe 2010/7/19 Marius Petoi marius.pe...@codebeat.ro Hi Martin, Regarding state saving in tables, here are my observations and comments: - there is no state saved in relation to the UIData objects. - the states saved for the children of the UIData objects (the components in the tables) are irrelevant. They are not used afterwards, as the components are initialized at each request with default values and the state saved corresponds to the last modifications of the component (to the row which was last set via the setRowIndex() method). - every time the setRowIndex() method is invoked with the -1 parameter, _initialDescendantComponentState is initialized. This will no longer be necessary, as the initial state will be restored from the previously saved state. - the _rowStates array of states is constructed using partial state. This means that only states for the rows which are different from the template are saved in this array. In my opinion, this is what needs to be saved for the UIData. The children component of the UIData should have no state saved (at least not in the first phase - we could think that if something appears in all the rows of _rowStates for a componentt, then we could move this down to the component state). These are just some basic observations about state saving in tables. What do you think? Regards, Marius On Wed, Jul 14, 2010 at 4:29 PM, Martin Marinschek mmarinsc...@apache.org wrote: Ok, so you actually checked it - perfect! Next step: is there any component where this is different? UIInput is ok - all the other standard components are ok as well? When we have finished this, take a look at what Leonardo has done for partial state saving in data-tables. We will need to work out a proposal for an API in JSF 2.1 - and, I guess, alsongside our implementation, also an implementation for Mojarra, cause the RI team will not be able to get this done. best regards, Martin On 7/14/10, Marius Petoi marius.pe...@codebeat.ro wrote: I placed a breakpoint in DefaultFaceletsManagementStrategy.saveStateOnMap, in the point where saveState is called for each component. That is the point where the state to be saved is retrieved. That is where I got the information on the first place. I looked at each component and at the returned value of saveState. On Wed, Jul 14, 2010 at 3:41 PM, Martin Marinschek mmarinsc...@apache.orgwrote: Hi Marius, as I see means you see it, or you think it is like this ;) ? best regards, Martin On 7/14/10, Marius Petoi marius.pe...@codebeat.ro wrote: Hi Martin, I think you mean for the attributes that I say are added before the call to markInitialState(). So, as I see, the org.apache.myfaces.view.facelets.MARK_ID, locale, uniqueIdCounter, renderKitId, rendererType are not present in the partial state at the end of the lifecycle, although they are in the StateHelper. The reason for this is that they are added there before the call to markInitialState(). So, they will never be in the partial state. Regards, Marius On Wed, Jul 14, 2010 at 3:05 PM, Martin Marinschek mmarinsc...@apache.orgwrote: Hi Marius, you are sounding a bit unsure about this - did you really check what is in the partial state at the end of the lifecycle? best regards, Martin On 7/14/10, Marius Petoi marius.pe...@codebeat.ro wrote: Hello, After the improvements we discussed in previous threads, here is what the state looks
Re: [GSOC] State saving performance improvements in MyFaces 2.0
Hi Marius, -- Take for instance MethodExpressionActionListener. This is an example where a MethodExpression is part of the state. then this should (and needs to be changed), right? Additionally, ValueExpression and MethodExpression are not implemented by us, so how can you implement StateHolder in this classes? Only in classes containing ValueExpressions, right? -- There are some implementations of MethodExpression and ValueExpression in MyFaces, such as TagMethodExpression, which implement Externalizable. These were the classes I was referring to earlier. ok, but even then, the underlying value-expression will not be touched by this changes. So your changes are only applying to a thin wrapper. So this should be negligible. best regards, Martin -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: [GSOC] State saving status after first improvements
Hi Marius, ok, Leonardo will hopefully take a look - for you to continue: just post the partial state values for typical pages right now (you can also take the pages of the sample as a base if you want). best regards, Martin On Wed, Jul 21, 2010 at 3:23 PM, Marius Petoi marius.pe...@codebeat.ro wrote: Hello, As I see, in JspStateManagerImpl.saveSerializedView (actually in the isWritingState() method), there is a check whether the JSP_IS_WRITING_STATE_ATTR is set in the FacesContext. But this attribute is set in ViewHandlerImpl.setWritingState() if there is no StateWriter defined (if the current view is a jsp). So, in my opinion, the verification in the JspStateManagerImpl.isWritingState() should also include the verification of the StateWriter. Otherwise, full state saving will work only for JSP-s. Regards, Marius On Wed, Jul 21, 2010 at 3:49 PM, Martin Marinschek mmarinsc...@apache.org wrote: Hi Marius -- Full state saving means setting the context parameter javax.faces.PARTIAL_STATE_SAVING to false. This is all, right? I've noticed that just by doing this, the xhtml pages don't work anymore...only the jsp-s. There is no state saved in xhtml-s. Am I missing something? Oh my. That´s a bug then. Leonardo, can you look into this (not that I desperately need full state saving, but some users might need it)? best regards, Martin On Tue, Jul 20, 2010 at 2:46 PM, Marius Petoi marius.pe...@codebeat.ro wrote: Hi Leonardo, So you are working on UIData at the moment. What about UIRepeat? I see that partial state saving is not implemented in UIRepeat components. We could improve the _childState table (which is included in the saved state) to save only the states which are different from an initial state (like in UIData components). Regards, Marius On Mon, Jul 19, 2010 at 1:46 PM, Leonardo Uribe lu4...@gmail.com wrote: Hi Marius Right now I'm working on MYFACES-2616 Fix UIData state saving model (spec issue 153). I hope to attach some new patches, a example and a better documentation in that issue soon, so we can review it and make comments. regards, Leonardo Uribe 2010/7/19 Marius Petoi marius.pe...@codebeat.ro Hi Martin, Regarding state saving in tables, here are my observations and comments: - there is no state saved in relation to the UIData objects. - the states saved for the children of the UIData objects (the components in the tables) are irrelevant. They are not used afterwards, as the components are initialized at each request with default values and the state saved corresponds to the last modifications of the component (to the row which was last set via the setRowIndex() method). - every time the setRowIndex() method is invoked with the -1 parameter, _initialDescendantComponentState is initialized. This will no longer be necessary, as the initial state will be restored from the previously saved state. - the _rowStates array of states is constructed using partial state. This means that only states for the rows which are different from the template are saved in this array. In my opinion, this is what needs to be saved for the UIData. The children component of the UIData should have no state saved (at least not in the first phase - we could think that if something appears in all the rows of _rowStates for a componentt, then we could move this down to the component state). These are just some basic observations about state saving in tables. What do you think? Regards, Marius On Wed, Jul 14, 2010 at 4:29 PM, Martin Marinschek mmarinsc...@apache.org wrote: Ok, so you actually checked it - perfect! Next step: is there any component where this is different? UIInput is ok - all the other standard components are ok as well? When we have finished this, take a look at what Leonardo has done for partial state saving in data-tables. We will need to work out a proposal for an API in JSF 2.1 - and, I guess, alsongside our implementation, also an implementation for Mojarra, cause the RI team will not be able to get this done. best regards, Martin On 7/14/10, Marius Petoi marius.pe...@codebeat.ro wrote: I placed a breakpoint in DefaultFaceletsManagementStrategy.saveStateOnMap, in the point where saveState is called for each component. That is the point where the state to be saved is retrieved. That is where I got the information on the first place. I looked at each component and at the returned value of saveState. On Wed, Jul 14, 2010 at 3:41 PM, Martin Marinschek mmarinsc...@apache.orgwrote: Hi Marius, as I see means you see it, or you think it is like this ;) ? best regards
Re: [VOTE] make use of new apache.snapshots repo and apache-parent-7 features
+1, best regards, Martin On Tue, Jul 20, 2010 at 10:42 AM, Gerhard Petracek gerhard.petra...@gmail.com wrote: +1 regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2010/7/20 Mark Struberg strub...@yahoo.de +1 LieGrue, strub From: Leonardo Uribe lu4...@gmail.com To: MyFaces Development dev@myfaces.apache.org Sent: Tue, July 20, 2010 4:37:09 AM Subject: [VOTE] make use of new apache.snapshots repo and apache-parent-7 features Hi Some days ago, Mark Struberg suggest some changes to use the new apache.snapshots and apache-parent-7 features. Now that myfaces core 2.0.1 has been released, we can start with this process. By upgrading to apache-parent-7 and using the features provided there, we would gain significant benefits: *) Apache wide homogenic release tasks (at least for all projects using maven) *) _real_ source distribution packages and signing (ASF projects must be rebuildable from the source packages) *) Using Nexus for staging makes the release process a lot easier *) move to the new official apache.snapshots repository. The old one really makes a lot troubles under the hood... Some work has been done on MYFACES-2790 too. We need an official vote to do this change. So please vote +1 if you want this changes be included in myfaces master pom (note this changes will affect all myfaces projects, so the following release procedures could change). regards, Leonardo Uribe -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: [GSOC] State saving status after first improvements
For me, the UIData and UIRepeat need to descend from the same component - and this is actually something which is being discussed on the EG right now. When we have this, the solution should be the same. Marius, can you go in the profiling mode again, and share with us the state sizes for a typical page - full state saving, partial state saving MyFaces, partial state saving Mojarra, with and without data tables on them? best regards, Martin On Tue, Jul 20, 2010 at 2:46 PM, Marius Petoi marius.pe...@codebeat.ro wrote: Hi Leonardo, So you are working on UIData at the moment. What about UIRepeat? I see that partial state saving is not implemented in UIRepeat components. We could improve the _childState table (which is included in the saved state) to save only the states which are different from an initial state (like in UIData components). Regards, Marius On Mon, Jul 19, 2010 at 1:46 PM, Leonardo Uribe lu4...@gmail.com wrote: Hi Marius Right now I'm working on MYFACES-2616 Fix UIData state saving model (spec issue 153). I hope to attach some new patches, a example and a better documentation in that issue soon, so we can review it and make comments. regards, Leonardo Uribe 2010/7/19 Marius Petoi marius.pe...@codebeat.ro Hi Martin, Regarding state saving in tables, here are my observations and comments: - there is no state saved in relation to the UIData objects. - the states saved for the children of the UIData objects (the components in the tables) are irrelevant. They are not used afterwards, as the components are initialized at each request with default values and the state saved corresponds to the last modifications of the component (to the row which was last set via the setRowIndex() method). - every time the setRowIndex() method is invoked with the -1 parameter, _initialDescendantComponentState is initialized. This will no longer be necessary, as the initial state will be restored from the previously saved state. - the _rowStates array of states is constructed using partial state. This means that only states for the rows which are different from the template are saved in this array. In my opinion, this is what needs to be saved for the UIData. The children component of the UIData should have no state saved (at least not in the first phase - we could think that if something appears in all the rows of _rowStates for a componentt, then we could move this down to the component state). These are just some basic observations about state saving in tables. What do you think? Regards, Marius On Wed, Jul 14, 2010 at 4:29 PM, Martin Marinschek mmarinsc...@apache.org wrote: Ok, so you actually checked it - perfect! Next step: is there any component where this is different? UIInput is ok - all the other standard components are ok as well? When we have finished this, take a look at what Leonardo has done for partial state saving in data-tables. We will need to work out a proposal for an API in JSF 2.1 - and, I guess, alsongside our implementation, also an implementation for Mojarra, cause the RI team will not be able to get this done. best regards, Martin On 7/14/10, Marius Petoi marius.pe...@codebeat.ro wrote: I placed a breakpoint in DefaultFaceletsManagementStrategy.saveStateOnMap, in the point where saveState is called for each component. That is the point where the state to be saved is retrieved. That is where I got the information on the first place. I looked at each component and at the returned value of saveState. On Wed, Jul 14, 2010 at 3:41 PM, Martin Marinschek mmarinsc...@apache.orgwrote: Hi Marius, as I see means you see it, or you think it is like this ;) ? best regards, Martin On 7/14/10, Marius Petoi marius.pe...@codebeat.ro wrote: Hi Martin, I think you mean for the attributes that I say are added before the call to markInitialState(). So, as I see, the org.apache.myfaces.view.facelets.MARK_ID, locale, uniqueIdCounter, renderKitId, rendererType are not present in the partial state at the end of the lifecycle, although they are in the StateHelper. The reason for this is that they are added there before the call to markInitialState(). So, they will never be in the partial state. Regards, Marius On Wed, Jul 14, 2010 at 3:05 PM, Martin Marinschek mmarinsc...@apache.orgwrote: Hi Marius, you are sounding a bit unsure about this - did you really check what is in the partial state at the end of the lifecycle? best regards, Martin On 7/14/10, Marius Petoi marius.pe...@codebeat.ro wrote: Hello, After the improvements we discussed in previous threads, here is what the state looks like for some of the components: - the org.apache.myfaces.view.facelets.MARK_ID (ComponentSupport.MARK_CREATED) attribute is present in almost all the components
Re: [VOTE] release for myfaces core 2.0.1
+1, best regards, Martin On 7/16/10, Werner Punz werner.p...@gmail.com wrote: +1 Am 16.07.10 01:07, schrieb Leonardo Uribe: +1 2010/7/15 Leonardo Uribe lu4...@gmail.com mailto:lu4...@gmail.com Hi, I was running the needed tasks to get the 2.0.1 release of Apache MyFaces core out. The artifacts passed all TCK tests. Please note that this vote concerns all of the following parts: 1. Maven artifact group org.apache.myfaces.shared v4.0.2 [1] 2. Maven artifact group org.apache.myfaces.core v2.0.1 [1] 3. Maven artifact group org.apache.myfaces.test v1.0.0-beta-4 [1] The artifacts are deployed to my private Apache account ([1] and [3] for binary and source packages). The release notes could be found at [4]. Also the clirr test does not show binary incompatibilities with myfaces-api. Please take a look at the 2.0.1 artifacts and vote! Please note: This vote is majority approval with a minimum of three +1 votes (see [3]). [ ] +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, Leonardo Uribe [1] http://people.apache.org/~lu4242/myfaces201 http://people.apache.org/%7Elu4242/myfaces201 [2] http://www.apache.org/foundation/voting.html#ReleaseVotes [3] http://people.apache.org/~lu4242/myfaces201binsrc http://people.apache.org/%7Elu4242/myfaces201binsrc [4] http://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10600styleName=Htmlversion=12315117 http://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10600styleName=Htmlversion=12315117 -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: [GSOC] State saving status after first improvements
Hi Marius, you are sounding a bit unsure about this - did you really check what is in the partial state at the end of the lifecycle? best regards, Martin On 7/14/10, Marius Petoi marius.pe...@codebeat.ro wrote: Hello, After the improvements we discussed in previous threads, here is what the state looks like for some of the components: - the org.apache.myfaces.view.facelets.MARK_ID (ComponentSupport.MARK_CREATED) attribute is present in almost all the components, but that is put in the attributes map before the initial state is marked, so I think it does not affect partial state saving - same goes for locale, uniqueIdCounter, renderKitId, rendererType, which are also attributes in the StateHelper, but are added before the call to markInitialState(). So they also shouldn't be included in the partial state. - for UIInput, the partial state contains the value, localValueSet, submittedValue and valid properties. This is the partial state which is stored after one submit. Do you have other suggestions about what else could be improved in partial state saving? Regards, Marius -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: [GSOC] State saving status after first improvements
Hi Marius, as I see means you see it, or you think it is like this ;) ? best regards, Martin On 7/14/10, Marius Petoi marius.pe...@codebeat.ro wrote: Hi Martin, I think you mean for the attributes that I say are added before the call to markInitialState(). So, as I see, the org.apache.myfaces.view.facelets.MARK_ID, locale, uniqueIdCounter, renderKitId, rendererType are not present in the partial state at the end of the lifecycle, although they are in the StateHelper. The reason for this is that they are added there before the call to markInitialState(). So, they will never be in the partial state. Regards, Marius On Wed, Jul 14, 2010 at 3:05 PM, Martin Marinschek mmarinsc...@apache.orgwrote: Hi Marius, you are sounding a bit unsure about this - did you really check what is in the partial state at the end of the lifecycle? best regards, Martin On 7/14/10, Marius Petoi marius.pe...@codebeat.ro wrote: Hello, After the improvements we discussed in previous threads, here is what the state looks like for some of the components: - the org.apache.myfaces.view.facelets.MARK_ID (ComponentSupport.MARK_CREATED) attribute is present in almost all the components, but that is put in the attributes map before the initial state is marked, so I think it does not affect partial state saving - same goes for locale, uniqueIdCounter, renderKitId, rendererType, which are also attributes in the StateHelper, but are added before the call to markInitialState(). So they also shouldn't be included in the partial state. - for UIInput, the partial state contains the value, localValueSet, submittedValue and valid properties. This is the partial state which is stored after one submit. Do you have other suggestions about what else could be improved in partial state saving? Regards, Marius -- 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: Pending issues before release myfaces core 2.0.1
Hi Leonardo, we actually discussed this on the EG today: I believe we should include the clientId fix immediately. This is an issue we solve in the implementation - that´s it. best regards, Martin On Wed, Jul 14, 2010 at 8:20 PM, Leonardo Uribe lu4...@gmail.com wrote: Hi Werner Ok, I'll start the release procedure tonight. I need to revert some changes done on MYFACES-2744 UIData.getClientId() should not append rowIndex, instead use UIData.getContainerClientId(), because for now the position on jsr-314-open list is include it in 2.1 (I would like this one be included in 2.0 rev A). regards, Leonardo Uribe -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
[jira] Commented: (MYFACES-2744) UIData.getClientId() should not append rowIndex, instead use UIData.getContainerClientId()
[
https://issues.apache.org/jira/browse/MYFACES-2744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12888559#action_12888559
]
Martin Marinschek commented on MYFACES-2744:
I don´t want this to be reverted. This is an issue - and even if we slightly
deviate from the spec language (which is wrong in this case), the fix is
entirely correct and it will not cause compatibility issues with Mojarra.
best regards,
Martin
UIData.getClientId() should not append rowIndex, instead use
UIData.getContainerClientId()
--
Key: MYFACES-2744
URL: https://issues.apache.org/jira/browse/MYFACES-2744
Project: MyFaces Core
Issue Type: Bug
Components: JSR-314
Affects Versions: 2.0.0
Reporter: Leonardo Uribe
Assignee: Jakob Korherr
Fix For: 2.0.1-SNAPSHOT
from: [jsr-314-open] Ajax inside a DataTable
Cagatay Civici
I've faced with an issue in our app I'd like to share when trying to update
the datatable itself from a command element located inside a column. Case is
to select a row, execute logic and update the datatable. Basic code:
h:dataTable id=cars var=car value=#{tableBean.carsSmall}
h:column
f:facet name=header
Model
/f:facet
h:outputText value=#{car.model} /
/h:column
h:column
f:facet name=header
Action
/f:facet
h:commandButton value=Some Action
actionListener=#{tableBean.handleRowAction(car)}
f:ajax render=cars /
/h:commandButton
/h:column
/h:dataTable
As datatable has a rowIndex = 0 during rendering of commandButton f:ajax
defines the component id to render as cars:{rowIndex} where I should expect
cars only. This is due to UIData.getClientId implementation as UIData
adds rowIndex for unique row ids. This causes an issue with a nested f:ajax
case.
Martin Marinschek
We should never include the row-index in the client-id of the table
itself. For this, we need to revise the client-id generation
algorithm.
Without actually having tried it, I think that it is easy to do so, as
we have a UIComponentBase.getContainerClientId() to create the
client-id of the children - when this method is called, we append the
row-index, if getClientId() itself is called, we don´t.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2753) Trivial multi-level templating does not work if ui:include is used
[ https://issues.apache.org/jira/browse/MYFACES-2753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12888162#action_12888162 ] Martin Marinschek commented on MYFACES-2753: I´d like to link this to: https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=1684 I don´t have the time to look into this more right now, but maybe you guys can start off a good discussion with Max and Andy - nobody seems to be absolutely clear about this API, so it is worthwhile spending some time on this. If you get a good understanding, why don't you document it so that everybody will be able to get it... best regards, Martin Trivial multi-level templating does not work if ui:include is used -- Key: MYFACES-2753 URL: https://issues.apache.org/jira/browse/MYFACES-2753 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.2-SNAPSHOT Environment: myfaces core trunk (2.0.2-SNAPSHOT), tomcat 6.0.26 Reporter: Martin Kočí Assignee: Jakob Korherr Attachments: MYFACES-2753-tests.patch, MYFACES-2753.patch, MYFACES-2753.tar.gz Following example does not produce any output: OuterClient.xhtml ui:decorate template=/templates/OuterTemplate.xhtml xmlns:ui=http://java.sun.com/jsf/facelets; ui:define name=content ui:include src=InnerClient.xhtml / /ui:define /ui:decorate OuterTemplate.xhtml: !DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.01 Transitional//EN http://www.w3.org/TR/html4/loose.dtd; html xmlns=http://www.w3.org/1999/xhtml; xmlns:ui=http://java.sun.com/jsf/facelets; xmlns:f=http://java.sun.com/jsf/core; xmlns:h=http://java.sun.com/jsf/html; f:view h:head titletitle/title /h:head h:body ui:insert name=content / /h:body /f:view /html InnerClient.xhtml: ui:composition template=/templates/InnerTemplate.xhtml xmlns=http://www.w3.org/1999/xhtml; xmlns:ui=http://java.sun.com/jsf/facelets; ui:define name=content Do you see me? /ui:define /ui:composition InnerTemplate.xhtml: f:subview xmlns:ui=http://java.sun.com/jsf/facelets; xmlns:f=http://java.sun.com/jsf/core; ui:insert name=content / /f:subview But if OutterClient.xhtml looks like: ui:decorate template=/templates/OuterTemplate.xhtml xmlns:ui=http://java.sun.com/jsf/facelets; ui:define name=content ui:composition template=/templates/InnerTemplate.xhtml ui:define name=content Do you see me? /ui:define /ui:composition /ui:define /ui:decorate it outputs Do you see me? which is expected result in both cases. I think first case should work too - or am I missing something? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: ValidatorHandler and wire all attributes set to the Validator instance
Hi guys,
interesting idea, Martin. If anything, it should work the same for
components and validators - I don´t see why the artifacts should be
treated differently.
best regards,
Martin
On Sat, Jul 10, 2010 at 8:37 PM, Jakob Korherr jakob.korh...@gmail.com wrote:
Hi Martin,
Unfortunately I think it means only the speced attributes are wired.
However it is not really clear, because this would only work on facelets
(because on JSP you have to specify all attributes), but f:validator is only
described in detail for JSPs in the spec pdf. Maybe you could ask the EG
about this or you could raise a spec issue for JSF 2.1.
Currently the setting of custom properties is prevented in
org.apache.myfaces.view.facelets.tag.jsf.core.ValidateDelegateHandler.createMetaRuleset(),
because this one does super.createMetaRuleset() and calls ignoreAll() on the
result. Thus it would be very easy to change ;)
Regards,
Jakob
2010/7/9 Martin Koci martin.k...@aura.cz
Hi,
javadoc for javax.faces.view.facelets.ValidatorHandler contains this
sentence:
Will wire all attributes set to the Validator instance
created/fetched. Based on that one our developer tried this:
f:validator binding=#{aValidator} property=#{expression} /
Expected result was to put a value into validator via setter
setProperty(). But all attributes set means binding, for,
disabled, ... only the specified ones, right?
Thanks,
Martin Kočí
--
Jakob Korherr
blog: http://www.jakobk.com
twitter: http://twitter.com/jakobkorherr
work: http://www.irian.at
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
[jira] Commented: (MYFACES-2780) MyFaces performance improvements for production
[ https://issues.apache.org/jira/browse/MYFACES-2780?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12888165#action_12888165 ] Martin Marinschek commented on MYFACES-2780: Hi Mike, thanks for the parameter! Do you (anyways) have an idea of how much the lazy loading influences the request processing of the first request? How much are the typical memory savings for a large component library? Just so that our users have something to chew on ;) best regards, Martin MyFaces performance improvements for production Key: MYFACES-2780 URL: https://issues.apache.org/jira/browse/MYFACES-2780 Project: MyFaces Core Issue Type: Improvement Components: General Affects Versions: 2.0.0 Reporter: Michael Concini Assignee: Michael Concini Priority: Minor Fix For: 2.0.1 Several fixes to enhance startup memory footprint and runtime performance taking advantage of ProjectStage. -lazy loading of validators, converters, behaviors,components - can have a substantial impact on startup footprint in applications with multiple or very large widget libraries. Turn off some updating of resources for ProjectStage=Production by default (can always override using javax.faces.FACELETS_REFRESH_PERIOD) -change default facelets refresh interval to -1 when projectStage is production. This by itself gains a 60% improvement in throughput. -disable reloading of web.xml and faces-config after the first load. -store a map to cache Class to listenerFor and resourceDependency annotations when in production. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2792) Redirect with include-view-params in faces-config.xml
[
https://issues.apache.org/jira/browse/MYFACES-2792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12886700#action_12886700
]
Martin Marinschek commented on MYFACES-2792:
;) s*** happens!
all the best,
Martin
Redirect with include-view-params in faces-config.xml
-
Key: MYFACES-2792
URL: https://issues.apache.org/jira/browse/MYFACES-2792
Project: MyFaces Core
Issue Type: Bug
Reporter: Gurkan Erdogdu
Assignee: Jakob Korherr
Fix For: 2.0.1-SNAPSHOT
I have a bean
@ManagedBean(name=blog)
@SessionScoped
public class Blog {
private String content;
private static AtomicInteger id = new AtomicInteger(0);
private String idm;
public String addBlog(){
this.idm = Integer.toString(id.incrementAndGet());
return view?faces-redirect=trueamp;includeViewParams=true;
}
}
This is result view
h:body
f:view
f:metadata
f:viewParam name=id
value=#{blog.idm}/f:viewParam
/f:metadata
/f:view
h:outputText value=#{blog.content}/h:outputText
/h:body
This works! Changed to following and adding faces-config.xml
public String addBlog(){
this.idm = Integer.toString(id.incrementAndGet());
return ok;
}
navigation-rule
navigation-case
from-action#{blog.addBlog}/from-action
from-outcomeok/from-outcome
to-view-id/view.xhtml/to-view-id
redirect include-view-params=true/
/navigation-case
/navigation-rule
Not working!
What can be the problem? (I think doing some wrong actions!)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2780) MyFaces performance improvements for production
[ https://issues.apache.org/jira/browse/MYFACES-2780?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12885915#action_12885915 ] Martin Marinschek commented on MYFACES-2780: Well, I am ok with lazy loading if it does not change the request times, also not the ones for the first request. How much loading do you defer - is it changing the time needed for processing a request? In any case, I guess this should be configurable. best regards, Martin MyFaces performance improvements for production Key: MYFACES-2780 URL: https://issues.apache.org/jira/browse/MYFACES-2780 Project: MyFaces Core Issue Type: Improvement Components: General Affects Versions: 2.0.0 Reporter: Michael Concini Assignee: Michael Concini Priority: Minor Fix For: 2.0.1 Several fixes to enhance startup memory footprint and runtime performance taking advantage of ProjectStage. -lazy loading of validators, converters, behaviors,components - can have a substantial impact on startup footprint in applications with multiple or very large widget libraries. Turn off some updating of resources for ProjectStage=Production by default (can always override using javax.faces.FACELETS_REFRESH_PERIOD) -change default facelets refresh interval to -1 when projectStage is production. This by itself gains a 60% improvement in throughput. -disable reloading of web.xml and faces-config after the first load. -store a map to cache Class to listenerFor and resourceDependency annotations when in production. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2780) MyFaces performance improvements for production
[ https://issues.apache.org/jira/browse/MYFACES-2780?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12885474#action_12885474 ] Martin Marinschek commented on MYFACES-2780: Hi guys, how is lazy loading good for production performance? In production, I would expect everything to be initialized on startup - so that request times are as low as possible (and certainly not the first request is taking longer than all other requests). Startup is not so much an issue in production! That's why everyone precompiles JSPs in production. best regards, Martin MyFaces performance improvements for production Key: MYFACES-2780 URL: https://issues.apache.org/jira/browse/MYFACES-2780 Project: MyFaces Core Issue Type: Improvement Components: General Affects Versions: 2.0.0 Reporter: Michael Concini Assignee: Michael Concini Priority: Minor Fix For: 2.0.1 Several fixes to enhance startup memory footprint and runtime performance taking advantage of ProjectStage. -lazy loading of validators, converters, behaviors,components - can have a substantial impact on startup footprint in applications with multiple or very large widget libraries. Turn off some updating of resources for ProjectStage=Production by default (can always override using javax.faces.FACELETS_REFRESH_PERIOD) -change default facelets refresh interval to -1 when projectStage is production. This by itself gains a 60% improvement in throughput. -disable reloading of web.xml and faces-config after the first load. -store a map to cache Class to listenerFor and resourceDependency annotations when in production. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [GSOC] State saving performance improvements in MyFaces 2.0
Hi Marius, So, I am not sure what you mean by map with the Reference of the component as the key...is it a map in which the keys are java.lang.ref.Reference objects? And if so, what kind of references should I use? I meant you just put the component itself as a key there. On the other hand, regarding serialization vs implements PartialStateHolder, I've looked for some more externalizable objects: the TagMethodExpression class is used in the MethodExpressionValueChangeListener, which implements StateHolder and PartialMethodExpressionValueChangeListener, which implements PartialStateHolder. So maybe instead of being Externalizable, TagMethodExpression should also implement PartialStateHolder. There is a similar situation with TagValueExpression. I guess - Leonardo should clarify. best regards, Martin On Tue, Jul 6, 2010 at 10:46 AM, Martin Marinschek mmarinsc...@apache.org wrote: Hi Marius, problem here is since this call occur in build time, we can't call getClientId() (it will cause problems because the parent for most components is null in this stage), so use a external map here Why not use the Reference of the component as the key? Over one request, the reference is stable enough! Yes, it is possible. Just we have to take care about ClientBehaviorRedirectEventComponentWrapper, because this class is used as a wrapper to redirect client behavior events. Note that CompositeComponentResourceTagHandler.ATTACHED_OBJECT_HADLERS_KEY list is not saved on the state, but since we use the component attribute map, the key and the null value is saved on the state. If we don't use the component attribute map, we don't have that trace on the state and it will be lower. any update on this? best regards, Martin -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: [GSOC] State saving performance improvements in MyFaces 2.0
Sent from my phone, so very short: problem here is since this call occur in build time, we can't call getClientId() (it will cause problems because the parent for most components is null in this stage), so use a external map here Why not use the Reference of the component as the key? Over one request, the reference is stable enough! Best regards, Martin
[jira] Commented: (MYFACES-2730) FacesContext not available on application startup
[ https://issues.apache.org/jira/browse/MYFACES-2730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12882072#action_12882072 ] Martin Marinschek commented on MYFACES-2730: Hi Leonardo, but this would effectively mean we cannot wrap the faces-context for the startup, instead it is only going to be our instance? best regards, Martin FacesContext not available on application startup - Key: MYFACES-2730 URL: https://issues.apache.org/jira/browse/MYFACES-2730 Project: MyFaces Core Issue Type: Bug Components: JSR-127, JSR-252, JSR-314 Affects Versions: 1.1.8, 1.2.9, 2.0.0 Reporter: Nick Belaevski Assignee: Leonardo Uribe Fix For: 2.0.2-SNAPSHOT Attachments: MYFACES-2730-1.patch, MYFACES-2730-2.patch, MYFACES-2730-3.patch, MYFACES-2730-4.patch, MYFACES-2730-revert.patch If custom ResourceHandler calls FacesContext.getCurrentInstance() in constructor to read init parameters, null value is returned. This affects latest MyFaces 2.0.0-SNAPSHOT. Mojarra 2.0 provides InitFacesContext in this case. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2730) FacesContext not available on application startup
[ https://issues.apache.org/jira/browse/MYFACES-2730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12882106#action_12882106 ] Martin Marinschek commented on MYFACES-2730: Hi guys, if Mojarra follows the same pattern (not allows to decorate the FacesContext in the startup process), then I agree to the proposed solution. best regards, Martin FacesContext not available on application startup - Key: MYFACES-2730 URL: https://issues.apache.org/jira/browse/MYFACES-2730 Project: MyFaces Core Issue Type: Bug Components: JSR-127, JSR-252, JSR-314 Affects Versions: 1.1.8, 1.2.9, 2.0.0 Reporter: Nick Belaevski Assignee: Leonardo Uribe Fix For: 2.0.2-SNAPSHOT Attachments: MYFACES-2730-1.patch, MYFACES-2730-2.patch, MYFACES-2730-3.patch, MYFACES-2730-4.patch, MYFACES-2730-revert.patch If custom ResourceHandler calls FacesContext.getCurrentInstance() in constructor to read init parameters, null value is returned. This affects latest MyFaces 2.0.0-SNAPSHOT. Mojarra 2.0 provides InitFacesContext in this case. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [GSOC] State saving performance improvements in MyFaces 2.0
Hi Leonardo, The param org.apache.myfaces.view.facelets.APPLIED is used with the web config param javax.faces.FACELETS_REFRESH_PERIOD, to detect changes on the template files. If you set this param to 0, facelets stops to add it and your state size is reduced, so that configuration must be used in production environments. so that is in all components? and it is only for reloading? wouldn't it be enough to have this once per view? In the view-root attributes map? then, if any of the files which are loaded are younger than this param, we drop the whole thing and reload? I thought the MARK_APPLIED was for something else, but I don't remember too well... I am concerned even about polluting the state while development - it makes the debugging harder. I think it is possible to do something about ComponentSupport.MARK_DELETED. The algorithm used to refresh a view by facelets uses this param to indicate when a component should be deleted, but I think we can rewrite the algorithm to do not use the component attribute map to save this information, because it is only relevant for the current request. For even less, right? It should really be valid only for one building of the view - can we keep it in some facelet-context attribute, keyed by the component instance (so that the lookup is fast)? Maybe we should change the keys for example from org.apache.myfaces.view.facelets.MARK_DELETED to something smaller like oam.facelets.MARK_DELETED to save some bytes. ah well, it should go completely. Everything else is only half the rent. best regards, Martin 2010/6/24 Marius Petoi marius.pe...@codebeat.ro Hello, As you said, Martin, the attribute org.apache.myfaces.view.facelets.APPLIED is included in the partial state. This, as well as all the other attributes of the components, as the attributeMap in the UIComponentBase is a _ComponentAttributesMap. The put method of this map calls afterwards the method in the _DeltaStateHelper. This method includes everything in the partial state (as long as the initial state is marked). This means that all the attributes of a component will be included in the partial state. I suppose that there are other attributes as facelets.APPLIED, which don't need to be included in the partial state. So my suggestion at first would be to add flags to the put methods of the _DeltaStateHelper, in which to decide whether the value added needs to be in the partial state (and therefore added in the _deltas map), or not (in which case it will be added only in the _fullstate map). Afterwards, we should revise all the attributes and decide whether they need to be in the partial state or not and call the put methods with the apropriate flag. What do you think? Regards, Marius On Wed, Jun 23, 2010 at 4:54 PM, Martin Marinschek mmarinsc...@apache.org wrote: Hi Marius, I think you will easily find out candidates for a better implementation - just take a look at the partial state of any of the components. Something that comes immediately to my mind is facelets.MARK_APPLIED - this is only relevant in request-scope, but is currently in the partial state, both in Mojarra and MyFaces (last time I looked). Stuff like this needs to be fixed. Tell us if you have more information. best regards, Martin On 6/18/10, Leonardo Uribe lu4...@gmail.com wrote: Hi I think the key classes are UIComponentBase , _DeltaStateHelper and _DeltaList. Take a look at UIComponentBase.saveState() and UIComponentBase.restoreState(). Those methods have calls to other methods that are critical to state saving. I remember UIViewRoot has other methods too. I think check those classes are a good point to start. regards, Leonardo Uribe 2010/6/18 Marius Petoi marius.pe...@codebeat.ro Hello, In order to study the current performance of state saving, I designed a small page that I included in the examples for MyFaces 2.0. Also, I wrote 2 phase listeners that determine the length of the state saved in the ExternalContext before the render response phase and before the restore view phase. Do you have any suggestions what components should I start analyzing the state for? Regards, Marius -- 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: Introduce information about saved state in the debug page
Hi Marius, are you including the component size in the information per component or centrally? I think it would be handy to have this with the component detail information. best regards, Martin On 6/23/10, Marius Petoi marius.pe...@codebeat.ro wrote: Hello, I created a JIRA ticket and attached a patch ( https://issues.apache.org/jira/browse/MYFACES-2770) that introduces some information about the saved state in the debug page. The information consists of the length of the state saved in the page, as well as the number of bytes for each component of the saved state. Please have a look over the patch and tell me if it is ok and if there is more information that I should include. Best regards, Marius -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: [PORTAL] News about the TCK
Hi Scott, great news ;) best regards, Martin On 6/23/10, Leonardo Uribe lu4...@gmail.com wrote: Hi That's cool!. Any plans for jsf 2.0 + portlets? regards, Leonardo 2010/6/22 Scott O'Bryan darkar...@gmail.com Hello everyone, For those of you unfamiliar with the portlet-bridge project, it is essentially the R.I. implementation of JSR-301 and JSR-328. For over a year some core people have been working on getting the R.I. up to par. The one piece that was missing from this was the TCK. Well, Michael Freedman will be announcing the release of Portlet Bridge 1.0, which will become the R.I. for JSR-301 pending approvals. We also got the legalities of the TCK release figured out as well and I wanted to run things by the developers before putting a release of the project to a vote. Essentially, the TCK exists, en total, here at Apache and is run using a plugable maven build script instead of Sun's Portal TCK Harness like we were planning on using initially. What this means is that the TCK will be downloadable by anyone though the TCK project's svn repository right here at MyFaces. To my knowledge I think this is a first for Apache and will hopefully pave the way for continued support of the JCP from the Apache Community. I'd like to start a vote to release the official TCK for JSR-301 tomorrow but I wanted to do one final sanity check from the community to make sure this is still in line with what people want. When we talked about the TCK earlier, there were many questions as to why this TCK could not exist completely in the open source community and, in the end, that's exactly what we did. Thanks, Scott O'Bryan -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
[jira] Commented: (MYFACES-2730) FacesContext not available on application startup
[ https://issues.apache.org/jira/browse/MYFACES-2730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12881629#action_12881629 ] Martin Marinschek commented on MYFACES-2730: Hi guys, if there is backwards compatibility issues - e.g. an existing version of Orchestra which runs on MyFaces 1.2 does not run on MyFaces 2.0 due to throwing an exception, or any libraries which don't deploy but would be deploying if we don't throw exceptions, I change my position. I also think that resolving EL expressions should also be possible on startup (just not in request and session scoped beans). However, I thought the FacesContext was not available on startup so far, so why do existing libraries rely on this behaviour? If this is necessary - I am in favor to log an error instead. best regards, Martin FacesContext not available on application startup - Key: MYFACES-2730 URL: https://issues.apache.org/jira/browse/MYFACES-2730 Project: MyFaces Core Issue Type: Bug Components: JSR-127, JSR-252, JSR-314 Affects Versions: 1.1.8, 1.2.9, 2.0.0 Reporter: Nick Belaevski Assignee: Leonardo Uribe Fix For: 2.0.2-SNAPSHOT Attachments: MYFACES-2730-1.patch, MYFACES-2730-2.patch, MYFACES-2730-3.patch, MYFACES-2730-revert.patch If custom ResourceHandler calls FacesContext.getCurrentInstance() in constructor to read init parameters, null value is returned. This affects latest MyFaces 2.0.0-SNAPSHOT. Mojarra 2.0 provides InitFacesContext in this case. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [GSOC] State saving performance improvements in MyFaces 2.0
Hi Marius, I think you will easily find out candidates for a better implementation - just take a look at the partial state of any of the components. Something that comes immediately to my mind is facelets.MARK_APPLIED - this is only relevant in request-scope, but is currently in the partial state, both in Mojarra and MyFaces (last time I looked). Stuff like this needs to be fixed. Tell us if you have more information. best regards, Martin On 6/18/10, Leonardo Uribe lu4...@gmail.com wrote: Hi I think the key classes are UIComponentBase , _DeltaStateHelper and _DeltaList. Take a look at UIComponentBase.saveState() and UIComponentBase.restoreState(). Those methods have calls to other methods that are critical to state saving. I remember UIViewRoot has other methods too. I think check those classes are a good point to start. regards, Leonardo Uribe 2010/6/18 Marius Petoi marius.pe...@codebeat.ro Hello, In order to study the current performance of state saving, I designed a small page that I included in the examples for MyFaces 2.0. Also, I wrote 2 phase listeners that determine the length of the state saved in the ExternalContext before the render response phase and before the restore view phase. Do you have any suggestions what components should I start analyzing the state for? Regards, Marius -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
[jira] Commented: (MYFACES-2758) DebugPhaseListener tries to get value from unrendered component where value is unavailable
[
https://issues.apache.org/jira/browse/MYFACES-2758?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12881697#action_12881697
]
Martin Marinschek commented on MYFACES-2758:
Hi Jakob,
we need to make sure for each and every value resolution in the debug phase
listener that we catch all exceptions and just ignore them - we don't care
about performance here, we just want to make sure that we don't mess up a page
with the debug information.
best regards,
Martin
DebugPhaseListener tries to get value from unrendered component where value
is unavailable
--
Key: MYFACES-2758
URL: https://issues.apache.org/jira/browse/MYFACES-2758
Project: MyFaces Core
Issue Type: Bug
Components: Extension Feature
Affects Versions: 2.0.2-SNAPSHOT
Environment: myfaces core trunk
Reporter: Martin Kočí
Assignee: Jakob Korherr
Fix For: 2.0.2-SNAPSHOT
When in Develepment stage DebugPhaseListener collects useful information
about component tree. But there is a problem with construction like this
(example is from a real application based on ADF API) :
h:dataTable
value=#{queryModel.currentDescriptor.conjunctionCriterion.criterionList}
var=node
h:column
h:selectOneMenu rendered=#{node.attributeCriterion and
node.removable} value=#{node.operator}
f:selectItems value=#{node.operators} /
/h:selectOneMenu
/h:column
/h:dataTable
please note that selectOneMenu is rendered only if node is AttributeCriterion
because only AttributeCriterion class has property operator. But
DebugPhaseListener tries to get value for every row in DataTable even it is
not rendered - it leads in this case to exception:
javax.el.PropertyNotFoundException: The class
'com.companyConjunctionCriterion' does not have the property 'operator'
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2730) FacesContext not available on application startup
[ https://issues.apache.org/jira/browse/MYFACES-2730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12881218#action_12881218 ] Martin Marinschek commented on MYFACES-2730: Hi Leo, Jakob, I want exceptions on methods which make no sense - much clearer to the user. Deleting files in svn is totally ok as well. Implementing this in 1.2 and 1.1 does not help. best regards, Martin FacesContext not available on application startup - Key: MYFACES-2730 URL: https://issues.apache.org/jira/browse/MYFACES-2730 Project: MyFaces Core Issue Type: Bug Components: JSR-127, JSR-252, JSR-314 Affects Versions: 1.1.8, 1.2.9, 2.0.0 Reporter: Nick Belaevski Assignee: Leonardo Uribe Fix For: 2.0.2-SNAPSHOT Attachments: MYFACES-2730-1.patch, MYFACES-2730-2.patch, MYFACES-2730-revert.patch If custom ResourceHandler calls FacesContext.getCurrentInstance() in constructor to read init parameters, null value is returned. This affects latest MyFaces 2.0.0-SNAPSHOT. Mojarra 2.0 provides InitFacesContext in this case. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (MYFACES-2730) FacesContext not available on application startup
[ https://issues.apache.org/jira/browse/MYFACES-2730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12881218#action_12881218 ] Martin Marinschek edited comment on MYFACES-2730 at 6/22/10 10:53 AM: -- Hi Leo, Jakob, I want exceptions on methods which make no sense - much clearer to the user. Deleting files in svn is totally ok as well - you can always restore them at any point of time. Implementing this in 1.2 and 1.1 does not help, it would be wasting your precious time. best regards, Martin was (Author: mmarinschek): Hi Leo, Jakob, I want exceptions on methods which make no sense - much clearer to the user. Deleting files in svn is totally ok as well. Implementing this in 1.2 and 1.1 does not help. best regards, Martin FacesContext not available on application startup - Key: MYFACES-2730 URL: https://issues.apache.org/jira/browse/MYFACES-2730 Project: MyFaces Core Issue Type: Bug Components: JSR-127, JSR-252, JSR-314 Affects Versions: 1.1.8, 1.2.9, 2.0.0 Reporter: Nick Belaevski Assignee: Leonardo Uribe Fix For: 2.0.2-SNAPSHOT Attachments: MYFACES-2730-1.patch, MYFACES-2730-2.patch, MYFACES-2730-revert.patch If custom ResourceHandler calls FacesContext.getCurrentInstance() in constructor to read init parameters, null value is returned. This affects latest MyFaces 2.0.0-SNAPSHOT. Mojarra 2.0 provides InitFacesContext in this case. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [VOTE] release for myfaces core 2.0.1
+1, best regards, Martin On Sat, Jun 12, 2010 at 12:15 AM, Leonardo Uribe lu4...@gmail.com wrote: Hi Just one small note, I regenerate all artifacts to include a small fix in MYFACES-2638. It is just move one line of code, so it does not affect anything, but I did all tests again, so we can continue the vote as is. regards, Leonardo Uribe 2010/6/11 Werner Punz werner.p...@gmail.com +1 Werner Am 11.06.10 21:07, schrieb Leonardo Uribe: +1 2010/6/11 Leonardo Uribe lu4...@gmail.com mailto:lu4...@gmail.com Hi, I was running the needed tasks to get the 2.0.1 release of Apache MyFaces core out. The artifacts passed all TCK tests. Please note that this vote concerns all of the following parts: 1. Maven artifact group org.apache.myfaces.shared v4.0.2 [1] 2. Maven artifact group org.apache.myfaces.core v2.0.1 [1] 3. Maven artifact group org.apache.myfaces.test v1.0.0-beta-4 [1] The artifacts are deployed to my private Apache account ([1] and [3] for binary and source packages). The release notes could be found at [4]. Also the clirr test does not show binary incompatibilities with myfaces-api. Please take a look at the 2.0.1 artifacts and vote! Please note: This vote is majority approval with a minimum of three +1 votes (see [3]). [ ] +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, Leonardo Uribe [1] http://people.apache.org/~lu4242/myfaces201 http://people.apache.org/%7Elu4242/myfaces201 [2] http://www.apache.org/foundation/voting.html#ReleaseVotes [3] http://people.apache.org/~lu4242/myfaces201binsrc http://people.apache.org/%7Elu4242/myfaces201binsrc [4] http://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10600styleName=Htmlversion=12315117 http://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10600styleName=Htmlversion=12315117 -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: state saving change proposal
Hi Mike, 2) do something in the form renderer to indicate that the state needs to be saved, maybe setting a request attribute that can be checked in saveView to determine whether to actually save state or just return null. I would lean towards option 2 - I don´t see how the saved state would be used at all if there is no form on the page - there cannot be a postback to it, so this memory is anyways wasted. best regards, Martin -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
[jira] Commented: (MYFACES-2739) Pass through String values in EnumConverter.getAsString()
[
https://issues.apache.org/jira/browse/MYFACES-2739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12873926#action_12873926
]
Martin Marinschek commented on MYFACES-2739:
Hi Gentlemen,
I don't think it is a good idea to wait for 2.1. As slow as things currently
run inside the big companies involved, we should rather have a
context-parameter strict-compatibility mode and we should try to fix such
issues (which are really issues hindering people using JSF properly) if this is
not set to true.
best regards,
Martin
Pass through String values in EnumConverter.getAsString()
-
Key: MYFACES-2739
URL: https://issues.apache.org/jira/browse/MYFACES-2739
Project: MyFaces Core
Issue Type: Improvement
Components: JSR-314
Affects Versions: 2.0.0
Reporter: Jakob Korherr
Assignee: Jakob Korherr
Attachments: MYFACES-2739.patch
From the related spec issue (#817 -
https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=817):
In every standard by-type converter in the JSF spec, except for the
EnumConverter, the following code is present in getAsString():
if (value instanceof String)
{
return (String) value;
}
Thus allowing String values to be used directly as the String representation
of
the type. This allows e.g. the following scenario for an Integer property in
the
managed bean to work, although 1234 beeing a String and not an Integer:
h:selectOneRadio value=#{myBean.inputInt}
f:selectItem itemValue=1234 /
/h:selectOneRadio
However the spec javadoc of the EnumConverter does not include this scenario
and
thus EnumConverter.getAsString() throws a ConverterException when providing a
String value. This means that the following scenario won't work, although it
should on my opinion (note that this currently does work with Mojarra because
of
an implementation issue - see [1] for details):
h:selectOneRadio value=#{myBean.inputEnum}
f:selectItem itemValue=EnumConstant1 /
/h:selectOneRadio
EnumConstant1 beeing a valid constant in the enum type referenced by
#{myBean.inputEnum}. The only way to make this work right now is to use a
ValueExpression that resolves to the needed enum constant, so something like
this:
h:selectOneRadio value=#{myBean.inputEnum}
f:selectItem itemValue=#{myBean.propertyThatResolvesToEnumConstant1} /
/h:selectOneRadio
This is not very straight forward IMHO, thus I think
EnumConverter.getAsString()
should pass through String-values just as every other standard by-type
converter
does.
See also the discussion on the MyFaces user mailing list about this [2].
[1] https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=1694
[2] http://www.mail-archive.com/us...@myfaces.apache.org/msg55742.html
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: javax.faces.behavior.event = undefined
Hi Radek,
yes, it definitely sounds like a bug. Please create an issue. For
evaluation purposes, I think you can assign it to Werner Punz, who has
done the javascript rewrite.
best regards,
Martin
On 6/1/10, Radek Hodain hoda...@aura.cz wrote:
Hi,
Apache MyFaces JSF-2.0 Core Impl of version 2.0.0 works correctly. The
issue appears after rewrite javascript in the 2.0.1-SNAPSHOT version.
Should I create a bug to JIRA?
Best regards
Radek Hodain
On 05/31/2010 05:22 PM, Radek Hodain wrote:
Hi,
we are using Apache MyFaces JSF-2.0 Core Impl of version
2.0.1-SNAPSHOT. We have problem to decode submit in server side code,
because the parameter javax.faces.behavior.event has still undefined
value.
We think, there is an issue when js process ajax request.
If we have xhtml like this
h:form prependId=false
h:commandButton id=buttonId
f:ajax /
/h:commandButton
/h:form
the commandButton is rendered to this html output
input type=submit
onclick=jsf.util.chain(document.getElementById('buttonId'),
event,'jsf.ajax.request(\'buttonId\',event,{\'javax.faces.behavior.event\':\'action\'})');
return false;
name=buttonId
id=buttonId.
When we submit the commandButton, js is performed and post parameters
contain undefined value for key javax.faces.behavior.event. We think
that problem is in _Runtime.js in method exists. The method has two
arguments root which is an array and subNms. In our case root contains
execute : '@this', render : '@this', javax.faces.behavior.event :
'action' and subNms is javax.faces.behavior.event. Next part of code
tries to split subNms by dots. These parts are looked up in the root
but the root contains whole key javax.faces.behavior.event. The
method returns false and the request parameter
javax.faces.behavior.event stays undefined.
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
Re: Extended Debug Tree - MYFACES-2676
After Leonardo's work on:
https://issues.apache.org/jira/browse/MYFACES-2737
we don't need to bother about that additional faces-context retrieval
at all anymore - just do a getFacesContext(), that's it.
best regards,
Martin
On 5/27/10, Martin Marinschek mmarinsc...@apache.org wrote:
Hi guys,
I am alright with this. Jakob, can you check generally if we do
anything in static settings which would also be affected by this
deployment scenario? I would certainly think it is possible that we
already do so...
best regards,
Martin
On 5/27/10, Gerhard Petracek gerhard.petra...@gmail.com wrote:
to reduce possible confusions in such very special cases - we can provide
a
meaningful default message, if the call stack is missing in dev. mode.
- +1 for keeping this feature (for now).
regards,
gerhard
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
2010/5/27 Jakob Korherr jakob.korh...@gmail.com
Hi guys,
I'd like to sum this up and get some final opinions on whether or not to
remove the code from UIInput.
Keeping the code on UIInput would provide the call stack in the extended
debug tree for submittedValue and localValue which is a very cool
feature,
but may lead to a small performance loss (even in production stage)
unless
we cache the project stage setting in UIInput. This could result in
weird
behavior when using MyFaces from a shared lib folder on a system with
many
applications with different project stage settings.
This weird behavior however only means having the call stack available
in
the debug output or not, so it is just an extra feature which will be
available or not when mixing different project stage settings and I
think
we
can deal with this by a good documentation (e.g. adding a wiki page
regarding this problem) and also I guess this will not affect many
users.
So my suggestion is to leave the code on UIInput but to cache the
Project
Stage setting in a static final attribute on UIInput to get rid of the
performance issue and furthermore add a wiki page about this.
What do you guys think?
Regards,
Jakob
2010/5/21 Jakob Korherr jakob.korh...@gmail.com
But this _could_ be a problem, or at least result in weird behavior, so
I
think it is the best solution just to remove the code from UIInput...
Regards,
Jakob
2010/5/21 Gerhard Petracek gerhard.petra...@gmail.com
yes - that's true! i also told leonardo about it.
in his e-mail he just skipped it...
regards,
gerhard
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
2010/5/21 Martin Marinschek mmarinsc...@apache.org
Hi guys,
if MyFaces is deployed with the web-app, the static var will reside
in
a class which is loaded by the context class-loader - so once per
app.
Problems might only arise if MyFaces is deployed only once for all
web-apps - which will seldom be the case, I guess.
best regards,
Martin
On 5/21/10, Jakob Korherr jakob.korh...@gmail.com wrote:
So the conclusion is to use a private static boolean on UIInput
that
tells
us if we are in Development stage or not.
Any objections to that?
Regards,
Jakob
2010/5/20 Leonardo Uribe lu4...@gmail.com
Hi
2010/5/19 Jan-Kees van Andel jankeesvanan...@gmail.com
Sounds plausible, we already do the same thing with the
ExternalContexts
class.
It's blazing fast, but the question is: Are we allowed to and do
we
want
to cache the instance?
In theory yes, because it does not change the behavior expected by
the
spec.
If the spec doesn't dictate otherwise, I'm in favor of caching
it.
Another idea is to cache it in the ServletContext. It's not as
fast
as a
static final field, but still pretty fast and can be inspected
and
modified
through appserver tooling.
The problem is from UIInput.setValue() or
UIInput.setSubmittedValue()
we
don't have access to ServletContext (the only way is through
FacesContext.getCurrentInstance().getExternalContext(), and we
want
to
avoid
the call to FacesContext.getCurrentInstance() ).
Talking with Gerhard, the conclusion was a static var could do the
job. Is
just unrealistic assume someone has a production environment with
some
applications with project stage production and others
development
(note
shared variables are shared by all applications hosted in a web
server).
In the worst case, the applications will continue working.
regards,
Leonardo
Regards,
Jan-Kees
2010/5/19 Gerhard Petracek gerhard.petra...@gmail.com
we don't have to cache the faces-context.
we can use e.g. an interface with a static final field.
usage (example):
if(Boolean.TRUE.equals(InternalProjectStage.IS_DEV_MODE))
{
//...
}
- there is just one evaluation.
regards
Re: Extended Debug Tree - MYFACES-2676
Hi guys,
I am alright with this. Jakob, can you check generally if we do
anything in static settings which would also be affected by this
deployment scenario? I would certainly think it is possible that we
already do so...
best regards,
Martin
On 5/27/10, Gerhard Petracek gerhard.petra...@gmail.com wrote:
to reduce possible confusions in such very special cases - we can provide a
meaningful default message, if the call stack is missing in dev. mode.
- +1 for keeping this feature (for now).
regards,
gerhard
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
2010/5/27 Jakob Korherr jakob.korh...@gmail.com
Hi guys,
I'd like to sum this up and get some final opinions on whether or not to
remove the code from UIInput.
Keeping the code on UIInput would provide the call stack in the extended
debug tree for submittedValue and localValue which is a very cool feature,
but may lead to a small performance loss (even in production stage) unless
we cache the project stage setting in UIInput. This could result in weird
behavior when using MyFaces from a shared lib folder on a system with many
applications with different project stage settings.
This weird behavior however only means having the call stack available in
the debug output or not, so it is just an extra feature which will be
available or not when mixing different project stage settings and I think
we
can deal with this by a good documentation (e.g. adding a wiki page
regarding this problem) and also I guess this will not affect many users.
So my suggestion is to leave the code on UIInput but to cache the Project
Stage setting in a static final attribute on UIInput to get rid of the
performance issue and furthermore add a wiki page about this.
What do you guys think?
Regards,
Jakob
2010/5/21 Jakob Korherr jakob.korh...@gmail.com
But this _could_ be a problem, or at least result in weird behavior, so I
think it is the best solution just to remove the code from UIInput...
Regards,
Jakob
2010/5/21 Gerhard Petracek gerhard.petra...@gmail.com
yes - that's true! i also told leonardo about it.
in his e-mail he just skipped it...
regards,
gerhard
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
2010/5/21 Martin Marinschek mmarinsc...@apache.org
Hi guys,
if MyFaces is deployed with the web-app, the static var will reside in
a class which is loaded by the context class-loader - so once per app.
Problems might only arise if MyFaces is deployed only once for all
web-apps - which will seldom be the case, I guess.
best regards,
Martin
On 5/21/10, Jakob Korherr jakob.korh...@gmail.com wrote:
So the conclusion is to use a private static boolean on UIInput that
tells
us if we are in Development stage or not.
Any objections to that?
Regards,
Jakob
2010/5/20 Leonardo Uribe lu4...@gmail.com
Hi
2010/5/19 Jan-Kees van Andel jankeesvanan...@gmail.com
Sounds plausible, we already do the same thing with the
ExternalContexts
class.
It's blazing fast, but the question is: Are we allowed to and do we
want
to cache the instance?
In theory yes, because it does not change the behavior expected by
the
spec.
If the spec doesn't dictate otherwise, I'm in favor of caching it.
Another idea is to cache it in the ServletContext. It's not as fast
as a
static final field, but still pretty fast and can be inspected and
modified
through appserver tooling.
The problem is from UIInput.setValue() or
UIInput.setSubmittedValue()
we
don't have access to ServletContext (the only way is through
FacesContext.getCurrentInstance().getExternalContext(), and we want
to
avoid
the call to FacesContext.getCurrentInstance() ).
Talking with Gerhard, the conclusion was a static var could do the
job. Is
just unrealistic assume someone has a production environment with
some
applications with project stage production and others
development
(note
shared variables are shared by all applications hosted in a web
server).
In the worst case, the applications will continue working.
regards,
Leonardo
Regards,
Jan-Kees
2010/5/19 Gerhard Petracek gerhard.petra...@gmail.com
we don't have to cache the faces-context.
we can use e.g. an interface with a static final field.
usage (example):
if(Boolean.TRUE.equals(InternalProjectStage.IS_DEV_MODE))
{
//...
}
- there is just one evaluation.
regards,
gerhard
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
2010/5/19 Leonardo Uribe lu4...@gmail.com
Hi
The problem in this case is the only place we can store this
information
[jira] Commented: (MYFACES-2737) Cache FacesContext on UIComponentBase instances
[
https://issues.apache.org/jira/browse/MYFACES-2737?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12872080#action_12872080
]
Martin Marinschek commented on MYFACES-2737:
Hi Leonardo,
I _definitely_ like this approach - no spec changes necessary. Way cool!
It was that simple, and I just didn't see it ;). Neither did any of the cs-JSF
team and EG members involved - just great.
best regards,
Martin
Cache FacesContext on UIComponentBase instances
---
Key: MYFACES-2737
URL: https://issues.apache.org/jira/browse/MYFACES-2737
Project: MyFaces Core
Issue Type: Improvement
Components: JSR-314
Affects Versions: 2.0.0
Reporter: Leonardo Uribe
Assignee: Leonardo Uribe
Attachments: MYFACES-2737-1.patch
Right now, the implementation of UIComponentBase.getFacesContext() is this:
@Override
protected FacesContext getFacesContext()
{
return FacesContext.getCurrentInstance();
}
I think it is possible to create a variable like this:
private transient FacesContext _facesContext;
and change the current implementation to:
void setCachedFacesContext(FacesContext facesContext)
{
_facesContext = facesContext;
}
@Override
protected FacesContext getFacesContext()
{
if (_facesContext == null)
{
return FacesContext.getCurrentInstance();
}
else
{
return _facesContext;
}
}
Then we do this on methods like processXXX, encodeXXX (not on encodeAll),
visitTree and invokeOnComponent:
@Override
public void processDecodes(FacesContext context)
{
try
{
setCachedFacesContext(context);
/*.. do what is required */
}
finally
{
popComponentFromEL(context);
setCachedFacesContext(null);
}
In few words, set and release temporally the variable while those operations
are executed. This change will reduce the amount of calls to
FacesContext.getCurrentInstance() without side effects, because we are
caching only on safe places and enclosing everything in a try finally block.
If no objections I'll commit this code soon.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [jsr-314-open] Fwd: PostAddToViewEvent publishing conditions
Hi Andy, my 2cents (isn´t worth much in this discussion if I don´t look any deeper into this ;) Given that ui:decorate is a non-trimming ui:composition, why would these behave differently with respect to interaction with the TemplateClient? I would think that both of these handlers should be calling pushClient(). I don´t see why ui:decorate should be different from ui:composition, either. Also, the multi-level search strategy seems somewhat questionable to me. A template exposes a certain number of of names into which content could be inserted. The consumer of the template leverages that contract and specifies content to be inserted into some subset of those names. When attempting to locate content to insert, why should the template look any further up the stack than the nearest consumer (ie. the most recently pushed TemplateClient)? Well, templates are certainly hierarchical - does the nearest consumer carry all information, or just the one which is defined in itself? Seems like this should have been implemented as a simple stack solution where the most recent TemplateClient is always used to resolve insertions. Of course, there may be perfectly fine reasons for why Facelets supports extendClient() and performs multi-level searches to locate content to insert. Just not clear what these reasons are. Note that for composite components, we should not follow the Facelets precedent here. If a composite component exposes a facet for insertion, we should only look to immediate consumer of the composite component for matches - ie. we should not be walking up the entire ancestor stack. 3) Why does InsertHandler call extendClient()() and why does it implement TemplateClient? Because ui:insert could expose a spot too, and it is resolved to there if no ui:define (exposed by ui:composition) with the name is exposed too. Right, so I see that InsertHandler is implemented this way, but... why? Seems silly to have ui:insert serve two entirely different purposes - ie. to both identify an insertion point as well as to define content for included templates. Why should ui:insert act both as a ui:insert *and* as a ui:define? If a template author wants to pass content through from an outer page to an inner/nested template, seems like the right way to accomplish this would be to wrap the ui:insert inside of a ui:define. Well, if you define a template, you use ui:insert to mark the spots where content can be - and then you include default content right away. Is it this which makes ui:insert a thing of both worlds? best regards, Martin -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: [cwiki] spaces
Hi Gerhard, sorry for the late reply - my username would be mmarinschek. best regards, Martin On Fri, Apr 9, 2010 at 12:52 PM, Bernd Bohmann bernd.bohm...@googlemail.com wrote: Thanks Gerhard, my username is bommel. Regards Bernd On Fri, Apr 9, 2010 at 10:54 AM, Jakob Korherr jakob.korh...@gmail.com wrote: That are really great news, Gerhard! My confluence username is jakobk. Regards, Jakob 2010/4/9 Leonardo Uribe lu4...@gmail.com Thanks! I'm tired to use the old wiki. my preferred username is lu4242 Leonardo Uribe 2010/4/9 Matthias Wessendorf mat...@apache.org Thanks Gerhard!! matzew AT apache DOT org is my username -Matthias On Fri, Apr 9, 2010 at 3:49 AM, Hazem Saleh haz...@apache.org wrote: That is a great piece of news! My preferred userName is hazems. On Thu, Apr 8, 2010 at 8:55 PM, Jan-Kees van Andel jankeesvanan...@gmail.com wrote: +1 on the whole email. My username is jankeesvanan...@apache.org. Regards, Jan-Kees 2010/4/8 Gerhard Petracek gerhard.petra...@gmail.com hi @ all, the myfaces space is available at [1]. @committers: please post your confluence user-names and i'll add them to the committers-group. if there are no objections, i'll create one space per subproject. [1] will provide some general information and news. further information would be available in the space of the concrete sub-project. for the beginning i'll create new spaces for myfaces-extval and myfaces-codi. regards, gerhard [1] http://cwiki.apache.org/confluence/display/MYFACES/Index http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- 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 Web blog: http://www.jroller.com/page/HazemBlog [Web 2.0] Google Maps Integration with JSF: http://code.google.com/p/gmaps4jsf/ http://www.ibm.com/developerworks/library/wa-aj-gmaps/ -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: Extended Debug Tree - MYFACES-2676
Hi guys,
well, yes - I fear so as well.
I wonder if that development switch is used often in other places as
well - do we have that same performance problem somewhere else?
best regards,
Martin
On Fri, May 21, 2010 at 6:17 PM, Jakob Korherr jakob.korh...@gmail.com wrote:
But this _could_ be a problem, or at least result in weird behavior, so I
think it is the best solution just to remove the code from UIInput...
Regards,
Jakob
2010/5/21 Gerhard Petracek gerhard.petra...@gmail.com
yes - that's true! i also told leonardo about it.
in his e-mail he just skipped it...
regards,
gerhard
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
2010/5/21 Martin Marinschek mmarinsc...@apache.org
Hi guys,
if MyFaces is deployed with the web-app, the static var will reside in
a class which is loaded by the context class-loader - so once per app.
Problems might only arise if MyFaces is deployed only once for all
web-apps - which will seldom be the case, I guess.
best regards,
Martin
On 5/21/10, Jakob Korherr jakob.korh...@gmail.com wrote:
So the conclusion is to use a private static boolean on UIInput that
tells
us if we are in Development stage or not.
Any objections to that?
Regards,
Jakob
2010/5/20 Leonardo Uribe lu4...@gmail.com
Hi
2010/5/19 Jan-Kees van Andel jankeesvanan...@gmail.com
Sounds plausible, we already do the same thing with the
ExternalContexts
class.
It's blazing fast, but the question is: Are we allowed to and do we
want
to cache the instance?
In theory yes, because it does not change the behavior expected by the
spec.
If the spec doesn't dictate otherwise, I'm in favor of caching it.
Another idea is to cache it in the ServletContext. It's not as fast
as a
static final field, but still pretty fast and can be inspected and
modified
through appserver tooling.
The problem is from UIInput.setValue() or UIInput.setSubmittedValue()
we
don't have access to ServletContext (the only way is through
FacesContext.getCurrentInstance().getExternalContext(), and we want to
avoid
the call to FacesContext.getCurrentInstance() ).
Talking with Gerhard, the conclusion was a static var could do the
job. Is
just unrealistic assume someone has a production environment with some
applications with project stage production and others development
(note
shared variables are shared by all applications hosted in a web
server).
In the worst case, the applications will continue working.
regards,
Leonardo
Regards,
Jan-Kees
2010/5/19 Gerhard Petracek gerhard.petra...@gmail.com
we don't have to cache the faces-context.
we can use e.g. an interface with a static final field.
usage (example):
if(Boolean.TRUE.equals(InternalProjectStage.IS_DEV_MODE))
{
//...
}
- there is just one evaluation.
regards,
gerhard
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
2010/5/19 Leonardo Uribe lu4...@gmail.com
Hi
The problem in this case is the only place we can store this
information
is the component instance itself. So, at least there is one lookup
per
component.
If we try to cache facesContext, unfortunately there is not safe
way to
clean this reference (portlet case), so there is a risk of use old
instances
of this object in this case.
regards,
Leonardo Uribe
2010/5/19 Gerhard Petracek gerhard.petra...@gmail.com
hi,
as long as we don't want to change the project stage dynamically,
we
can just store e.g. a marker as static information.
regards,
gerhard
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
2010/5/19 Jakob Korherr jakob.korh...@gmail.com
Hi Martin,
Indeed, we have to call FacesContext.getCurrentInstance()
everytime.
So I guess it will be better to remove the code from UIInput!
Regards,
Jakob
2010/5/19 Martin Marinschek mmarinsc...@apache.org
Hi Jakob,
The problem with this is that the code on UIInput checks the
ProjectStage
everytime setSubmittedValue() or setValue() are called, which
is
very often
and could make MyFaces a bit slower, I guess. If we remove
this
code on
UIInput, the debug output will stay mostly the same except for
the
call
stack, because this will be gone.
The question now is if we should leave it the way it currently
is
(with the
code on UIInput and the possibility to display the call stack)
or
if we
should remove the code from UIInput (which means no slowdown
on
setSubmittedValue() and setValue() but loosing the call
stack).
What do you
guys think? Any
[jira] Commented: (MYFACES-2730) FacesContext not available on application startup
[ https://issues.apache.org/jira/browse/MYFACES-2730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12870594#action_12870594 ] Martin Marinschek commented on MYFACES-2730: That should - by the way - be part of the Spec. If language to this extent is not included, we should file an issue. best regards, Martin FacesContext not available on application startup - Key: MYFACES-2730 URL: https://issues.apache.org/jira/browse/MYFACES-2730 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.0 Reporter: Nick Belaevski If custom ResourceHandler calls FacesContext.getCurrentInstance() in constructor to read init parameters, null value is returned. This affects latest MyFaces 2.0.0-SNAPSHOT. Mojarra 2.0 provides InitFacesContext in this case. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Extended Debug Tree - MYFACES-2676
Hi guys,
ok, in any case - let's not make the issue worse.
And - Leo - can you file a spec issue for this?
thx,
regards,
Martin
On 5/25/10, Leonardo Uribe lu4...@gmail.com wrote:
Hi Martin
I think the code that do a lot of calls to FacesContext.getCurrentInstance()
right now is on all listeners attached to system events.
One example is
DefaultFaceletsStateManagementStrategy.PostAddPreRemoveFromViewListener. It
is a listener attached to PostAddToViewEvent / PreRemoveFromViewEvent, but
it requires to get the current FacesContext to do some operations. If we
have one call here, that means this listener is being called once per each
component in a tree.
Doing some other different listeners I notice this is required over and
over.
It could be good to ask if it is possible modify the spec, so it could be
possible to pass the current facesContext instance and prevent this lookup.
regards,
Leonardo Uribe
2010/5/24 Martin Marinschek mmarinsc...@apache.org
Hi guys,
well, yes - I fear so as well.
I wonder if that development switch is used often in other places as
well - do we have that same performance problem somewhere else?
best regards,
Martin
On Fri, May 21, 2010 at 6:17 PM, Jakob Korherr jakob.korh...@gmail.com
wrote:
But this _could_ be a problem, or at least result in weird behavior, so
I
think it is the best solution just to remove the code from UIInput...
Regards,
Jakob
2010/5/21 Gerhard Petracek gerhard.petra...@gmail.com
yes - that's true! i also told leonardo about it.
in his e-mail he just skipped it...
regards,
gerhard
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
2010/5/21 Martin Marinschek mmarinsc...@apache.org
Hi guys,
if MyFaces is deployed with the web-app, the static var will reside in
a class which is loaded by the context class-loader - so once per app.
Problems might only arise if MyFaces is deployed only once for all
web-apps - which will seldom be the case, I guess.
best regards,
Martin
On 5/21/10, Jakob Korherr jakob.korh...@gmail.com wrote:
So the conclusion is to use a private static boolean on UIInput that
tells
us if we are in Development stage or not.
Any objections to that?
Regards,
Jakob
2010/5/20 Leonardo Uribe lu4...@gmail.com
Hi
2010/5/19 Jan-Kees van Andel jankeesvanan...@gmail.com
Sounds plausible, we already do the same thing with the
ExternalContexts
class.
It's blazing fast, but the question is: Are we allowed to and do
we
want
to cache the instance?
In theory yes, because it does not change the behavior expected by
the
spec.
If the spec doesn't dictate otherwise, I'm in favor of caching
it.
Another idea is to cache it in the ServletContext. It's not as
fast
as a
static final field, but still pretty fast and can be inspected and
modified
through appserver tooling.
The problem is from UIInput.setValue() or
UIInput.setSubmittedValue()
we
don't have access to ServletContext (the only way is through
FacesContext.getCurrentInstance().getExternalContext(), and we want
to
avoid
the call to FacesContext.getCurrentInstance() ).
Talking with Gerhard, the conclusion was a static var could do the
job. Is
just unrealistic assume someone has a production environment with
some
applications with project stage production and others
development
(note
shared variables are shared by all applications hosted in a web
server).
In the worst case, the applications will continue working.
regards,
Leonardo
Regards,
Jan-Kees
2010/5/19 Gerhard Petracek gerhard.petra...@gmail.com
we don't have to cache the faces-context.
we can use e.g. an interface with a static final field.
usage (example):
if(Boolean.TRUE.equals(InternalProjectStage.IS_DEV_MODE))
{
//...
}
- there is just one evaluation.
regards,
gerhard
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
2010/5/19 Leonardo Uribe lu4...@gmail.com
Hi
The problem in this case is the only place we can store this
information
is the component instance itself. So, at least there is one
lookup
per
component.
If we try to cache facesContext, unfortunately there is not safe
way to
clean this reference (portlet case), so there is a risk of use
old
instances
of this object in this case.
regards,
Leonardo Uribe
2010/5/19 Gerhard Petracek gerhard.petra...@gmail.com
hi,
as long as we don't want to change the project stage
dynamically,
we
can just store e.g. a marker as static information.
regards
Re: Extended Debug Tree - MYFACES-2676
Hi guys,
if MyFaces is deployed with the web-app, the static var will reside in
a class which is loaded by the context class-loader - so once per app.
Problems might only arise if MyFaces is deployed only once for all
web-apps - which will seldom be the case, I guess.
best regards,
Martin
On 5/21/10, Jakob Korherr jakob.korh...@gmail.com wrote:
So the conclusion is to use a private static boolean on UIInput that tells
us if we are in Development stage or not.
Any objections to that?
Regards,
Jakob
2010/5/20 Leonardo Uribe lu4...@gmail.com
Hi
2010/5/19 Jan-Kees van Andel jankeesvanan...@gmail.com
Sounds plausible, we already do the same thing with the ExternalContexts
class.
It's blazing fast, but the question is: Are we allowed to and do we want
to cache the instance?
In theory yes, because it does not change the behavior expected by the
spec.
If the spec doesn't dictate otherwise, I'm in favor of caching it.
Another idea is to cache it in the ServletContext. It's not as fast as a
static final field, but still pretty fast and can be inspected and
modified
through appserver tooling.
The problem is from UIInput.setValue() or UIInput.setSubmittedValue() we
don't have access to ServletContext (the only way is through
FacesContext.getCurrentInstance().getExternalContext(), and we want to
avoid
the call to FacesContext.getCurrentInstance() ).
Talking with Gerhard, the conclusion was a static var could do the job. Is
just unrealistic assume someone has a production environment with some
applications with project stage production and others development
(note
shared variables are shared by all applications hosted in a web server).
In the worst case, the applications will continue working.
regards,
Leonardo
Regards,
Jan-Kees
2010/5/19 Gerhard Petracek gerhard.petra...@gmail.com
we don't have to cache the faces-context.
we can use e.g. an interface with a static final field.
usage (example):
if(Boolean.TRUE.equals(InternalProjectStage.IS_DEV_MODE))
{
//...
}
- there is just one evaluation.
regards,
gerhard
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
2010/5/19 Leonardo Uribe lu4...@gmail.com
Hi
The problem in this case is the only place we can store this
information
is the component instance itself. So, at least there is one lookup per
component.
If we try to cache facesContext, unfortunately there is not safe way to
clean this reference (portlet case), so there is a risk of use old
instances
of this object in this case.
regards,
Leonardo Uribe
2010/5/19 Gerhard Petracek gerhard.petra...@gmail.com
hi,
as long as we don't want to change the project stage dynamically, we
can just store e.g. a marker as static information.
regards,
gerhard
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
2010/5/19 Jakob Korherr jakob.korh...@gmail.com
Hi Martin,
Indeed, we have to call FacesContext.getCurrentInstance() everytime.
So I guess it will be better to remove the code from UIInput!
Regards,
Jakob
2010/5/19 Martin Marinschek mmarinsc...@apache.org
Hi Jakob,
The problem with this is that the code on UIInput checks the
ProjectStage
everytime setSubmittedValue() or setValue() are called, which is
very often
and could make MyFaces a bit slower, I guess. If we remove this
code on
UIInput, the debug output will stay mostly the same except for the
call
stack, because this will be gone.
The question now is if we should leave it the way it currently is
(with the
code on UIInput and the possibility to display the call stack) or
if we
should remove the code from UIInput (which means no slowdown on
setSubmittedValue() and setValue() but loosing the call stack).
What do you
guys think? Any opinions/objections?
for me it is a question how fast this getProjectStage() derivation
is.
If that means to call FacesContext.getCurrentInstance() all the
time,
the impact is considerable (thread-local resolution). In this case
it
might be better to not have this information...
Martin
Regards,
Jakob
--
Jakob Korherr
blog: http://www.jakobk.com
twitter: http://twitter.com/jakobkorherr
work: http://www.irian.at
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
--
Jakob Korherr
blog: http://www.jakobk.com
twitter: http://twitter.com/jakobkorherr
work: http://www.irian.at
--
Jakob Korherr
blog: http://www.jakobk.com
twitter: http://twitter.com/jakobkorherr
work: http://www.irian.at
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
Re: Extended Debug Tree - MYFACES-2676
Hi Jakob, The problem with this is that the code on UIInput checks the ProjectStage everytime setSubmittedValue() or setValue() are called, which is very often and could make MyFaces a bit slower, I guess. If we remove this code on UIInput, the debug output will stay mostly the same except for the call stack, because this will be gone. The question now is if we should leave it the way it currently is (with the code on UIInput and the possibility to display the call stack) or if we should remove the code from UIInput (which means no slowdown on setSubmittedValue() and setValue() but loosing the call stack). What do you guys think? Any opinions/objections? for me it is a question how fast this getProjectStage() derivation is. If that means to call FacesContext.getCurrentInstance() all the time, the impact is considerable (thread-local resolution). In this case it might be better to not have this information... Martin Regards, Jakob -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: [VOTE] release for myfaces builder plugin 1.0.6
+1 regards, Martin On Tue, May 18, 2010 at 1:40 PM, Jakob Korherr jakob.korh...@gmail.com wrote: +1 Regards, Jakob 2010/5/18 Leonardo Uribe lu4...@gmail.com +1 2010/5/17 Leonardo Uribe lu4...@gmail.com Hi, I was running the needed tasks to get the 1.0.6 release of Apache MyFaces Builder Plugin out. This release includes some changes necessary to build myfaces core 2.0 branch, and other enhancements like the new @JSFBehavior annotation and the addition of javascript compressor code into our codebase. Testing instructions are available at [3]. Please note that this vote concerns all of the following parts: 1. Maven artifact group org.apache.myfaces.buildtools artifact myfaces-builder-plugin v1.0.6 [1] 2. Maven artifact group org.apache.myfaces.buildtools artifact myfaces-builder-annotations v1.0.5 [1] 3. Maven artifact group org.apache.myfaces.buildtools artifact myfaces-javacc-plugin v1.0.1 [1] 3. Maven artifact group org.apache.myfaces.buildtools artifact myfaces-javascript-plugin v1.0.1 [1] The artifacts are deployed to my private Apache account ([1]). Please take a look at the 1.0.6 artifacts and vote! Please note: This vote is majority approval with a minimum of three +1 votes (see [3]). [ ] +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, Leonardo Uribe [1] http://people.apache.org/~lu4242/m2-plugins-106 [2] http://www.apache.org/foundation/voting.html#ReleaseVotes [3] http://wiki.apache.org/myfaces/BuilderPluginRelease106 -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
[jira] Commented: (TOMAHAWK-1504) Update autoscroll feature to JSF 2
[ https://issues.apache.org/jira/browse/TOMAHAWK-1504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12868070#action_12868070 ] Martin Marinschek commented on TOMAHAWK-1504: - Hi Leonardo, ok, well - with my comment I meant if it wouldn´t be practical to (instead of having one tag per component) have one component per page which enables this behaviour for all command components? Just like we do it in the view-handler of MyFaces? Does that sound reasonable? best regards, Martin Update autoscroll feature to JSF 2 -- Key: TOMAHAWK-1504 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1504 Project: MyFaces Tomahawk Issue Type: Improvement Components: JSF2 Affects Versions: 1.1.9 Reporter: Leonardo Uribe Assignee: Leonardo Uribe Fix For: 1.1.10-SNAPSHOT Attachments: TOMAHAWK-1504-1.patch In jsf 1.1. and 1.2, autoscroll behavior had the following problems: - It is myfaces specific feature, because requires add some code on renderers. In ri it will not work - It only works for h:commandXXX and t:commandXXX components, so if you use trinidad (override h:commandXXX renderers) it will not work. - Since it requires render some javascript at the end of body tag, it requires use DefaultAddResource or t:documentBody With jsf 2.0 we have the chance to get rid all this problems and make this feature work with other libraries. First a short review about this feature. To make it work, it requires the following points: - Render an input type=hidden name=autoScroll / that will contain the position on the page (x,y) - Render a function called getScrolling() ant the end of the page that calculate the value and optionally render the command that scroll. - Render the script on each link to call getScrolling() function and assign its value to the hidden field (using oamSetHiddenInput). The idea include add the following code: - Create a new client behavior tag called t:autoscroll that adds the script required on each command component. - Create a new component that just render the hidden field. It will be added as a component resource. - Create a new component that render autoScroll script. It will be added as a component resource. - Add some code on ResourceViewHandler, to add the two previous components to the component tree as transient each time the view is rendered, but only if org.apache.myfaces.AUTO_SCROLL web param is true or t:autoscroll is used on the current page. Now, the proposal will work in following scenarios like this: - org.apache.myfaces.AUTO_SCROLL is enabled, myfaces core is used, so all h:commandXXX and t:commandXXX works like in jsf 1.1 and jsf 1.2. - org.apache.myfaces.AUTO_SCROLL is disabled and myfaces core is used, hidden field and script will be added only if t:autoscroll is used. By default, h:commandXXX and t:commandXXX will not have autoscroll script, so t:autoscroll is required to add this script. - RI (Mojarra) is used, hidden field and script will be added only if t:autoscroll is used. By default, h:commandXXX and t:commandXXX will not have autoscroll script, so t:autoscroll is required to add this script. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2616) Fix UIData state saving model (spec issue 153)
[
https://issues.apache.org/jira/browse/MYFACES-2616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12867478#action_12867478
]
Martin Marinschek commented on MYFACES-2616:
Hi Leonardo,
while I see that your approach would be good, I see one problem with this - and
that is performance due to the additional tree visit (and the EG has already
said that it is not happy about adding more tree-visits).
Can we find a solution so that your requirements are fulfilled, and no
additional tree-visit is necessary?
best regards,
Martin
Fix UIData state saving model (spec issue 153)
--
Key: MYFACES-2616
URL: https://issues.apache.org/jira/browse/MYFACES-2616
Project: MyFaces Core
Issue Type: Task
Components: JSR-314
Affects Versions: 2.0.0-beta-2
Reporter: Leonardo Uribe
Assignee: Leonardo Uribe
Attachments: fixUIDataPSS-6.patch, fixUIDataPSS-7.patch
In short, this topic is an attempt to add full state to components inside
UIData. I'll do a brief resume, so people can understand this one easily.
UIData uses the same component instances to render multiple rows. Suppose
this example:
h:dataTable id=cities var=city value=#{country.cities}
h:column
h:outputText value=#{city} /
/h:column
/h:dataTable
In the component tree it is created this hierarchy:
HtmlDatatable
UIColumn
HtmlOutputText
If we have 10 cities, the same component is used over and over to render all
10 cities. The reason to do that in this way is keep state as small as
possible.
Now let's suppose something like this:
h:dataTable id=cities var=city value=#{country.cities}
h:column
h:inputText value=#{city} /
/h:column
/h:dataTable
It was changed the output component for an input one. If this table is in a
form and the values are submitted, the same component is used to apply
request values, validate and apply them to the model (update process). To
make this possible, UIData class has some code to preserve this values
between phases (using EditableValueHolder interface), so when each phase is
processed, all rows are traversed and you get the expected behavior.
Now suppose something more complex: We have a code that use invokeOnComponent
to change the style of my inputText. In theory, only one row should change.
But in fact, all rows are rendered with the same color. Why? because we use
the same component to render all rows, and we don't preserve the children
component state between rows.
There is a lot of issues, questions, and side effects related to this issue,
but just to put some of them here:
TOMAHAWK-1062 InputTextArea doesn't work properly inside facet DetailStamp
TOMAHAWK-96 Data table Scroller not working the dataTable which was actually
contained in other DataTable
https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=153
Problems with UIData state saving
Also, it is well know that one reason why people uses c:forEach in facelets,
is because this one create full components per each row. It is very easy to
find articles on internet.
Now, with jsf 2.0 we have partial state saving, so we have a chance to fix
this one once and for all. I tried fix this one per months (maybe years!),
but talking with Martin Marinschek on JSFDays, some ideas came out and
finally it was found a possibility to fix this one using the existing api and
with little changes on the spec.
The proposal is this:
1. Do not call UIComponent.markInitialState() on ComponentTagHandlerDelegate,
as ComponentHandler javadoc says, instead call it after PostAddToViewEvent
are published on vdl.buildView(). We need to call it from root to nodes, so
the parent component is marked first. I know the place where this call comes
is from trinidad tag handler, but this call needs to be fixed in a more
predictable way.
2. Use an attribute on facesContext to identify when the VDL is marking the
initial state (in myfaces there is already an attribute called
org.apache.myfaces.MARK_INITIAL_STATE). This is necessary to indicate
UIData instances that it is time to save the full state of all component
children,
3. Allow UIData to hold a map where the key are client ids and the value are
the deltas of all components per row. This map should be saved and restored.
4. Change UIData.setRowIndex() to restore and save the component state.
I'll attach a patch on this issue with the algorithm proposed (because it is
based on myfaces codebase). It was tested and it works. But note it is
necessary to fix the javadoc for UIData.markInitialState(), ComponentHandler
and maybe vdl.buildView(), so the intention is propose this change for jsf
2.0 rev A. Note this works only with PSS enabled because without
[jira] Commented: (TRINIDAD-1809) CPU impact for repeated calls to isRenderer on UIXComponentBase
[ https://issues.apache.org/jira/browse/TRINIDAD-1809?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12867479#action_12867479 ] Martin Marinschek commented on TRINIDAD-1809: - Hi Stefan, yes, you are right - it would be safe to do this. In cs-JSF we do exactly this - we also cache the rendered attribute from the begin of processDecodes until the end of invoke application. However: if you cache this in a transient attributes, you need to treat stuff in data-tables differently. Transient attributes are not saved/restored per row while a data-table is processed, a long standing issue we have with the spec. best regards, Martin CPU impact for repeated calls to isRenderer on UIXComponentBase --- Key: TRINIDAD-1809 URL: https://issues.apache.org/jira/browse/TRINIDAD-1809 Project: MyFaces Trinidad Issue Type: Bug Components: Components Reporter: Stevan Malesevic While using Trinidad framework we noticed that even with very complex app having complex bus logic we still spend some 2-3% of time doing checks on isRenderer() on UIXComponentBase. In general the problem is that number of these are EL expression on some EL expressions are not very cheap to evaluate. Now, the fact that there are number of duplicate checks makes the cost higher. The big chunk of calls comes from 3 areas 1. encodeBegin, encodeChild and encodeEnd all do the check 2. __encodeRecursive does a check and then invokes methods from 1. 3. CoreRenderer.encodeChild also does a check and then calls group 1. Generally it should be possible to mark renderer as local property at the begging of comp rendering and use it . This should save a 1/3 of cpu cycles -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TOMAHAWK-1504) Update autoscroll feature to JSF 2
[ https://issues.apache.org/jira/browse/TOMAHAWK-1504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12867481#action_12867481 ] Martin Marinschek commented on TOMAHAWK-1504: - Hi Leonardo, cool stuff - like your suggestion. Question: t:autoScroll is a client-behaviour, and a normal tag, right? So I will just have to add it once to a page if I use Mojarra, right? nice! best regards, Martin Update autoscroll feature to JSF 2 -- Key: TOMAHAWK-1504 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1504 Project: MyFaces Tomahawk Issue Type: Improvement Components: JSF2 Affects Versions: 1.1.9 Reporter: Leonardo Uribe Assignee: Leonardo Uribe Attachments: TOMAHAWK-1504-1.patch In jsf 1.1. and 1.2, autoscroll behavior had the following problems: - It is myfaces specific feature, because requires add some code on renderers. In ri it will not work - It only works for h:commandXXX and t:commandXXX components, so if you use trinidad (override h:commandXXX renderers) it will not work. - Since it requires render some javascript at the end of body tag, it requires use DefaultAddResource or t:documentBody With jsf 2.0 we have the chance to get rid all this problems and make this feature work with other libraries. First a short review about this feature. To make it work, it requires the following points: - Render an input type=hidden name=autoScroll / that will contain the position on the page (x,y) - Render a function called getScrolling() ant the end of the page that calculate the value and optionally render the command that scroll. - Render the script on each link to call getScrolling() function and assign its value to the hidden field (using oamSetHiddenInput). The idea include add the following code: - Create a new client behavior tag called t:autoscroll that adds the script required on each command component. - Create a new component that just render the hidden field. It will be added as a component resource. - Create a new component that render autoScroll script. It will be added as a component resource. - Add some code on ResourceViewHandler, to add the two previous components to the component tree as transient each time the view is rendered, but only if org.apache.myfaces.AUTO_SCROLL web param is true or t:autoscroll is used on the current page. Now, the proposal will work in following scenarios like this: - org.apache.myfaces.AUTO_SCROLL is enabled, myfaces core is used, so all h:commandXXX and t:commandXXX works like in jsf 1.1 and jsf 1.2. - org.apache.myfaces.AUTO_SCROLL is disabled and myfaces core is used, hidden field and script will be added only if t:autoscroll is used. By default, h:commandXXX and t:commandXXX will not have autoscroll script, so t:autoscroll is required to add this script. - RI (Mojarra) is used, hidden field and script will be added only if t:autoscroll is used. By default, h:commandXXX and t:commandXXX will not have autoscroll script, so t:autoscroll is required to add this script. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [GSOC] New Form Elements
On Thu, May 6, 2010 at 5:43 PM, Mike Kienenberger mkien...@gmail.com wrote: Sounds a lot like the tomahawk sandbox subform and tomahawk UICommand components. You can specify an actionFor attribute on the UICommand components to point at a specific subform. I wonder if some of the design from subform can be reused. Yes, I agree - you definitely need to take a look at the subform - if for nothing else to find out if the code will be superfluous with HTML 5 ;) best regards, Martin
[jira] Commented: (TOMAHAWK-1425) Support to java.sql.Date using inputCalendar tag.
[ https://issues.apache.org/jira/browse/TOMAHAWK-1425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12866342#action_12866342 ] Martin Marinschek commented on TOMAHAWK-1425: - Hi Leonardo, I have always thought that JSF should add a business-converter for such issues. So we should have a way to convert between the model type that we need for the renderer, and the model-type that the backing-beans use. You could register such a converter on the input-component like the normal converter, businessConverter= We could also cover stuff like the joda-date with this. Eventually, we could even add a central registry for this in MyFaces where you can register business-converters centrally and hence let the renderer automatically retrieve such a a converter for the backing-bean datatype and the datatype it needs. best regards, Martin Support to java.sql.Date using inputCalendar tag. - Key: TOMAHAWK-1425 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1425 Project: MyFaces Tomahawk Issue Type: New Feature Components: Calendar Affects Versions: 1.1.8 Reporter: Paulo Henrique Couto de Lima Assignee: Leonardo Uribe Priority: Minor Fix For: 1.1.10-SNAPSHOT Attachments: HtmlCalendarRenderer.java.patch Original Estimate: 1h Remaining Estimate: 1h Trying to use a java.sql.Date value for inputCalendar results in IllegalArgumentException, thrown by the deprecated method getHour of java.sql.Date. java.util.Date does not throw any exceptions when getHour is invoked. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2667) var values cause problems with ui:debug when creating the debug component tree
[
https://issues.apache.org/jira/browse/MYFACES-2667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12862527#action_12862527
]
Martin Marinschek commented on MYFACES-2667:
Hi Jakob,
yes, the location in the XHTML. Actually, from our discussion on the EG, we
have stated that this location should be part of the information each component
has (it comes from the tag field of a TagHandler in Facelets I think). I hope
this has made it into the spec, if not, you will need to file a spec issue ;)
Emitting this information would be very valuable on the debug page.
best regards,
Martin
var values cause problems with ui:debug when creating the debug component tree
--
Key: MYFACES-2667
URL: https://issues.apache.org/jira/browse/MYFACES-2667
Project: MyFaces Core
Issue Type: Bug
Affects Versions: 2.0.1-SNAPSHOT
Reporter: Jakob Korherr
Assignee: Jakob Korherr
Fix For: 2.0.1-SNAPSHOT
When using ui:debug / on a page, it creates a String version of the current
component tree to show it in the debug output window (opens by hitting ctrl +
shift + D in the browser).
While creating this component tree, ui:debug wants to display every property
of every component in the tree using the class' PropertyDescriptors. However
there are some problems with this solution related to components that publish
values in the RequestMap while the real tree is processed (rendered) like
e.g. ui:repeat or h:dataTable (mostly those with a var attribute). Every
child component of such a component, which refers to this value, will cause
EL operations with invalid parameters (null or empty String) when its getters
are called. See the related thread on the mailing list to this problem:
http://www.mail-archive.com/us...@myfaces.apache.org/msg55485.html
In addition, properties with values of Collection, Map or Iterator are not
included in the debug output, only those with real values (like true,
false, 1234) are included. Also I don't think that it makes much sence to
include all real values in the debug component tree, because what should we
display for components that render their children a couple of times like
h:dataTable? ...and depend on values of their parent which are published
somewhere else?
To visualize the problem a bit more, see the following facelet page:
ui:repeat var=master value=#{myBean.masterList}
h:dataTable var=detail value=#{myBean.getDetailList(master)}
h:column
h:outputText value=#{detail} /
/h:column
/h:dataTable
/ui:repeat
The debug output for this one looks something like this:
UIRepeat id=j_id2114509110_7e08d943 inView=true offset=0
rendered=true size=-1 step=1 transient=false var=master
HtmlDataTable border=-2147483648 first=0
id=j_id2114509110_7e08d9b9 inView=true rendered=true rowIndex=-1
rows=0 transient=false var=detail
UIColumn id=j_id2114509110_7e08d99f inView=true
rendered=true transient=false
HtmlOutputText escape=true id=j_id2114509110_7e08d9f5
inView=true rendered=true transient=false/
/UIColumn
/HtmlDataTable
/UIRepeat
I personally think that it would be much better not to evaluate the
ValueExpressions, but to include the properties with the expression String in
the component tree, like you see here:
UIRepeat id=j_id2114509110_7e08d943 inView=true offset=0
rendered=true size=-1 step=1 transient=false
value=#{myBean.masterList} var=master
HtmlDataTable border=-2147483648 first=0
id=j_id2114509110_7e08d9b9 inView=true rendered=true rowIndex=-1
rows=0 transient=false value=#{myBean.getDetailList(master)}
var=detail
UIColumn id=j_id2114509110_7e08d99f inView=true
rendered=true transient=false
HtmlOutputText escape=true id=j_id2114509110_7e08d9f5
inView=true rendered=true transient=false value=#{detail}/
/UIColumn
/HtmlDataTable
/UIRepeat
This will solve the problem the user has experienced and will also create a
much better debug output.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2667) var values cause problems with ui:debug when creating the debug component tree
[
https://issues.apache.org/jira/browse/MYFACES-2667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12861782#action_12861782
]
Martin Marinschek commented on MYFACES-2667:
Hi Jakob,
sure, that is a good idea!
A feature which I would have wanted for a long time already would be the
ability to concentrate on one component (like click on it on the debug page)
and then being able to see how that component values changed over the
lifecycle. That would help me a lot with debugging in cs-JSF. The location of
the component (coming from the Facelet Tag Handler) is hopefully already
included in the information shown?
best regards,
Martin
var values cause problems with ui:debug when creating the debug component tree
--
Key: MYFACES-2667
URL: https://issues.apache.org/jira/browse/MYFACES-2667
Project: MyFaces Core
Issue Type: Bug
Affects Versions: 2.0.1-SNAPSHOT
Reporter: Jakob Korherr
Assignee: Jakob Korherr
Fix For: 2.0.1-SNAPSHOT
When using ui:debug / on a page, it creates a String version of the current
component tree to show it in the debug output window (opens by hitting ctrl +
shift + D in the browser).
While creating this component tree, ui:debug wants to display every property
of every component in the tree using the class' PropertyDescriptors. However
there are some problems with this solution related to components that publish
values in the RequestMap while the real tree is processed (rendered) like
e.g. ui:repeat or h:dataTable (mostly those with a var attribute). Every
child component of such a component, which refers to this value, will cause
EL operations with invalid parameters (null or empty String) when its getters
are called. See the related thread on the mailing list to this problem:
http://www.mail-archive.com/us...@myfaces.apache.org/msg55485.html
In addition, properties with values of Collection, Map or Iterator are not
included in the debug output, only those with real values (like true,
false, 1234) are included. Also I don't think that it makes much sence to
include all real values in the debug component tree, because what should we
display for components that render their children a couple of times like
h:dataTable? ...and depend on values of their parent which are published
somewhere else?
To visualize the problem a bit more, see the following facelet page:
ui:repeat var=master value=#{myBean.masterList}
h:dataTable var=detail value=#{myBean.getDetailList(master)}
h:column
h:outputText value=#{detail} /
/h:column
/h:dataTable
/ui:repeat
The debug output for this one looks something like this:
UIRepeat id=j_id2114509110_7e08d943 inView=true offset=0
rendered=true size=-1 step=1 transient=false var=master
HtmlDataTable border=-2147483648 first=0
id=j_id2114509110_7e08d9b9 inView=true rendered=true rowIndex=-1
rows=0 transient=false var=detail
UIColumn id=j_id2114509110_7e08d99f inView=true
rendered=true transient=false
HtmlOutputText escape=true id=j_id2114509110_7e08d9f5
inView=true rendered=true transient=false/
/UIColumn
/HtmlDataTable
/UIRepeat
I personally think that it would be much better not to evaluate the
ValueExpressions, but to include the properties with the expression String in
the component tree, like you see here:
UIRepeat id=j_id2114509110_7e08d943 inView=true offset=0
rendered=true size=-1 step=1 transient=false
value=#{myBean.masterList} var=master
HtmlDataTable border=-2147483648 first=0
id=j_id2114509110_7e08d9b9 inView=true rendered=true rowIndex=-1
rows=0 transient=false value=#{myBean.getDetailList(master)}
var=detail
UIColumn id=j_id2114509110_7e08d99f inView=true
rendered=true transient=false
HtmlOutputText escape=true id=j_id2114509110_7e08d9f5
inView=true rendered=true transient=false value=#{detail}/
/UIColumn
/HtmlDataTable
/UIRepeat
This will solve the problem the user has experienced and will also create a
much better debug output.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
