Auto Reply: Auto Reply: CDI constructor integration

I am out of office without access to email.  Please contact Michael McGrath for any urgent ADF Faces issues.

Back on Tuesday, July 6.

Andy

Auto Reply: CDI constructor integration

I am out of office without access to email.  Please contact Michael McGrath for any urgent ADF Faces issues.

Back on Tuesday, July 6.

Andy

CDI constructor integration

Are JSF xml schemes public available ?

I tried to create schemes for RichFaces faces-config and tag library
extensions, and just figured out that links
http://java.sun.com/xml/ns/javaee/web-facelettaglibary_2_0.xsd,
http://java.sun.com/xml/ns/javaee/web-facesuicomponent_2_0.xsd
http://java.sun.com/xml/ns/javaee/web-partialresponse_2_0.xsd which
supposed by schema documentation are broken. Did anyone publish them or
that is forgotten task from release procedure ?

Re: Tree visit hints [Was: ADMIN: Final list of issues for JSF 2.0 and actions for each]

Gang -

Need to bring up one of my favorite issues again. 

As described below, at the moment we have no way to suppress iteration 
(over stamped rows, eg. in UIData) while performing a tree visit.  This 
is a problem for at least one existing case: PostRestoreStateEvent 
delivery, where we only want to deliver the PostRestoreState once per 
component, rather than once for each time that the component is stamped.

Mojarra's UIData implementation implements a workaround for the 
PostRestoreStateEvent delivery case.  Mojarra's UIData.visitTree() 
implements checks the current phase and avoids iteration when the phase 
== restore view.

However, this workaround is too limited.  I need a solution for 
suppressing iteration more generally, not just for restore view.  For 
example, in ADF Faces I need to perform an tree visit just before we 
render the view.  (This is related our recent discussion on resource 
collection in the PostAddToViewEvent thread, which I am hoping we can 
solve more generally 2.1.)

The correct solution is obvious:  we need  a new SKIP_ITERATION visit hint.

However, as we have discussed repeatedly, this is going to have wait 
until 2.1.

Unfortunately, I desperately need a solution now.

Since my preferred solution (ie. a standard visit hint) doesn't seem to 
be possible at the moment, I have reached the point where I am wondering 
whether we could consider uglier, non-standard, temporary solutions.  
For example, one option might be for the JSF implementations to 
introduce a flag hanging off of the FacesContext attribute map that 
would serve the same purpose as VisitHint.SKIP_ITERATION, at least until 
we can get the standard solution in place for 2.1.

I realize that this is a terribly ugly thing to do, and I am reluctant 
to ask that we even consider this.  (Sorry!)

A fall back might be to introduce an equivalent framework-specific flag 
that we could use for Trinidad/ADF Faces, though I was hoping for 
something more generic - eg. something that would at least work with 
UIData, but ideally with other 3rd party components as well.  This would 
require some coordination between MyFaces and Mojarra.  Minimally, we 
would need to agree to a common name for the flag.

Is this something that MyFaces/Mojarra folks would be open to?

 Andy

On 4/17/09 7:51 PM, Andy Schwartz wrote:
> Gang -
>
> While reviewing this list with Ed earlier this week, Ed and I 
> discussed very small issue that is not mentioned in the list but which 
> we agreed to at least consider fixing for 2.0.  The issue is related 
> to tree visiting and state saving.  I believe that it is likely that 
> certain components may need to visit their children in a somewhat 
> different manner for state saving purposes - eg. a UIData may take 
> different steps when visiting children for state saving as opposed to 
> say, rendering an Ajax response.  However, at the moment there is no 
> way for a visitTree() implementation to know that state saving is 
> being performed.  visitTree() implementations do have access to the 
> current phase id via the FacesContext, but of course state saving does 
> not live in its own phase.  In order to provide a way to inform 
> visitTree() implementations that state saving is being performed, I 
> proposed (to Ed) that we add a new visit hint.
>
> Currently we've got the following visit hints:
>
>>   SKIP_UNRENDERED
>>   SKIP_TRANSIENT
>>   EXECUTE_LIFECYCLE
>
>
> I would like to add this new hint:
>
>>   EXECUTE_STATE_SAVING
>
> While thinking about visit hints and UIData again, I got back to 
> thinking about a use case that we had discussed in the past... 
> Currently there is no way to tell components which visit their 
> children multiple times (think UIData) not to bother performing 
> iteration - ie. to only visit each child one time.  So, for example, 
> in the UIData case, there is no way to tell the UIData component to 
> not iterate over each row when visiting children.  At one point I had 
> proposed a hint to provide control over this, but I never actually 
> added this to the API.  After discussing this with my colleagues 
> internally here, we realized that we have at least one case where we 
> need this ability.  So, while I am in the VisitHint enum, I would like 
> to also add the following new hint:
>
>>   SKIP_ITERATION
>
> I have opened up the following spec issue to track these requirements:
>
> https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=545 
>
>
> And have also uploaded a patch which adds both of these APIs (though 
> for the most part leaves the implementation alone).
>
> If anyone has comments/questions about either of these, please let me 
> know.
>
> Ed -
>
> I realize that we did not discuss the SKIP_ITERATION proposal on our 
> call.  Please let me know if you feel that it is inappropriate to add 
> this.  I can  upload a new patch.
>
> Andy
>
>

[806] Simplify PostRestoreStateEvent delivery requirements

Gang -

I recently logged the following spec issue:

https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=806

Short summary of the problem for those who don't want to read through 
the gory details:

The specification is currently a bit too specific about when 
PostRestoreStateEvents should be delivered.  The only requirement should 
be that these events are delivered after the view has been restored, but 
before we move out of the restore view phase.  For example, a reasonable 
implementation would be to deliver these events in the Lifecycle 
implementation, after the state manager has returned the restored view.  
However, the spec does not currently allow this - eg. the spec requires 
that UIViewRoot.processRestoreState() delivers these events.

Of course, UIViewRoot.processRestoreState isn't always called (only used 
for full state saving), which means that implementations end up having 
to duplicate this logic elsewhere, such as in whatever state manager is 
used for partial state saving.  This has further fallout for custom 
state managers - ie. custom state managers that do not call 
processRestoreState() must duplicate the event delivery logic yet again.

This is much more complicated than necessary.  My recommendation is that 
we simplify the requirements such that implementations are free to deal 
with PostRestoreStateEvent delivery in a saner way.  For example, 
implementations should be able to deliver these events once at the end 
of the restore view phase (and not be required to implement this logic 
in UIViewRoot.processRestoreState()).

I suspect that this small spec change will lead to simpler code in 
Mojarra (definitely) and MyFaces (probably, though I haven't looked at 
the code).

Does anyone have concerns about this proposal?

Martin, Leonardo -

Could you guys comment on whether this change would be acceptable to 
MyFaces?

Andy

Fwd: [Fwd: Re: Fwd: PostAddToViewEvent publishing conditions]

My comments on Andy's mail, now officially to the list.
=========================================

Hi Andy,

ok, I will answer here, and will also try to forward when I see your
mail on the list ;)

> Actually meant to say that I believe that DecorateHandler got this one
> right.  (Calling pushClient() is the way to go.)

ok

> Unless someone understands why the implementation is inconsistent across
> these two cases, I think that we should align the implementations.  Note
> that given the bug that Max logged (against Mojarra):
>
> https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=1684
>
> I believe that CompositionHandler has got this one right (ie. both
> DecorateHandler and CompositionHandler should be calling pushClient()).

ok

> If the template itself happens to depend on yet another template, I view
> that as an implementation detail of the template.  So, if we've got this
> situation:
>
> - view.xhtml, which includes:
>  - outerTemplate.xhtml, which includes:
>   - innerTemplate.xhtml
>
> In my ideal world (which, at the moment, does not match reality), view.xhtml
> should only be aware of the slots that are exposed by outerTemplate.xhtml.
>  That is, view.xhtml should not depend on the fact that outerTemplate.xhtml
> happens to include innerTemplate.xhtml, which may have its own slots.
>
> The reality is that when nesting templates, the outermost template exposes
> *all* of the slots defined by any nested templates (no matter how many
> levels deep) to the consumer.  This seems like a violation of encapsulation
> to me.   We are exposing implementation details up through the template
> hierarchy that, I think, should not necessarily be exposed.
>
> Of course, I understand that it may be useful to be able to pass content
> from view.xhtml all the way through to a slot defined by
> innerTemplate.xhtml.   If outerTemplate.xhtml wants to allow certain content
> to be passed through from view.xhtml to innerTemplate.xthml, that's fine.
>  However, this should be done by introducing a ui:insert inside of
> outerTemplate.xhtml - ie. by explicitly exposing a new slot that consumers
> of outerTemplate.xhtml can rely on.  That way, if the author of
> outerTemplate.xhtml reconsiders the implementation and decides not to
> delegate to innerTemplate.xhtml after all, users of outerTemplate.xhtml are
> not hosed.

I totally understand your notion - and I agree. However, this is not
how Facelets works now. For me, this is a little bit like a method
call where suddenly inner method calls inherit the parameters from the
outside. FWIW, also the facelets parameters for composite components
(old style) were inherited this way, at least for a long time (I am
not sure if this has been fixed at some point of time). I find this
ugly.

> Oh well, this looks like another cases where I am many years too late.  That
> seems to be my fate these days.
>
> Even if we cannot change this behavior for ui:insert now, I do think it is
> important that we avoid this behavior for composite components.  Since we
> are tinkering with the composite:inertFacet/composite:insertChildren
> implementations now to be more Facelets/TemplateClient-like, let's just be
> careful to avoid introducing the Facelets nested insert behavior into
> composite components.

agreed

>>> 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?
>>
>
>
> Let's take a step back and look at the role of the TemplateClient contract.
>  TemplateClient allows consumers of templates (eg. ui:composition) to
> provide access to content that should be inserted into the template - ie.
> content defined by ui:define, inserted into ui:insert.  So, for example,
> both CompositionHandler and DecorateHandler are TemplateClients.
>
> ui:insert is clearly a user of the TemplateClient interface.  InsertHandler
> (via a call to FaceletContext.includeDefinition()) pulls in content provided
> by outer TemplateClients (eg. an ancestor ui:composition).
>
> This is all well and good.
>
> Where things get strange is that InsertHandler also implements
> TemplateClient.  This means that, in addition to being a consumer of
> TemplateClient content, ui:insert also exposes its own content for
> consumption by other consumers of TemplateClients.
>
> So, if you've got:
>
>  <ui:insert name="foo">
>   body content
>  </ui:insert>
>
> The "body content" serves two roles:
>
> 1.  It provides default content in the event that no matching ui:define for
> "foo" can be found.
> 2.  It is exposed as content for consumption while performing the definition
> inclusion (during the call to FaceletContext.includeDefinition()).
>
> Case #1 is expected/documented.

that is the case I meant - wasn´t sure if the existing implementation
tried to reach there.

> Case #2 is where ui:insert seems to acting as a ui:define.  This is
> non-obvious, and, as far as I can tell, not documented.

brrr, ugly. Has to go.

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

[2.0RevA-C071] none scoped beans and <at> PostConstruct

This is in the Change Log, and in issue 1683 [1].

Section 5.4.1 of the JSF 1.2 spec states:

  Methods on managed beans declared to be in request, session, or
  application scope, annotated with  <at> PostConstruct, must be called by the
  JSF implementation after resource injection is performed (if any) but
  before the bean is placed into scope.

Mojarra currently *does* cause these methods to be called,

What's right?  Call it or not call it?  I think not call it.  Thoughts?

Ed

[1] https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=1683
--

-- 
| edburns@... | 
| homepage:          | http://ridingthecrest.com/

Re: f:selectItems value="#{myMap}" underspecified

Hi Leo,

>> I never understood why the labels should be the key here - it should
>> really be the other way round, and the value should be the key. I
>> thought that was sorted for 1.2 - it is not?
>>
>>
> No, this was not solved because the documentation of f:selectItems does
> not have the properties mentioned (var, itemValue, itemLabel....). In fact
> it was f:selectItem the component that has them in jsf 1.2

Well, so this is really two issues - first, it is not documented,
second, I still think if we build the items from a map, it should go
the other way round.

Can you open issues?

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: Fix UIData state saving model (issue 153)

Hi Leonardo,

ok

> If we have some code on UIData.markInitialState() we have to call
> clearInitialState
> on all children, save the component initial state and call again
> markInitialState. The
> idea behind do not call UIComponent.markInitialState() on
> ComponentTagHandlerDelegate,
> is in avoid do that in reverse order and just do it in one step.

well, you need to have all children constructed, when
markInitialState() is called on the table, right? Is that what it
boils down to?

> on the state. The code proposed additionally save and restore the delta, and
> the
> delta per row is saved on UIData state.

ok

>
>> By the way - I don´t like Alexander´s idea of having a
>> restoreRowState/saveRowState (this additional API would only be useful
>> inside repeater-components). Instead, I would propagate a
>> getTransientAttributesMap() API, and the repeating-component would
>> just take care of saving/restoring this as well. I believe this API
>> could be used for a lot of other stuff. It would essentially a
>> component-request scope, which we don´t have yet, and for which we had
>> quite a few usages in cs-JSF already.
>>
>> We could also embed this state in the stateMap with a transient=true
>> attribute, that´s the other option - then it won´t be a public API
>> however.
>>
>>
> The important here is provide methods to save and restore that map/variable
> set.
> As long as we have some way to do that, we could call it from
> UIData.setRowIndex. I like the idea to extend StateHelper with accesors
> and save/restore methods for transient components.

I agree.

Can we add this to our JSF 2.1 roadmap?

best regards,

Martin

Repetitive calls to FacesContext.getCurrentInstance() from listeners of system events