On 13/05/2013 14:35, Thomas Andraschko wrote:
Hi Christian,
i don't understand your solution exactly.
Whats the difference?
It would still store the #{cc.attrs.xxx} expression and #{cc} cant be
evaluated without #pushComponentToEL(cc).
Also #createView should be avoided for such a request IMO be
I'm sure, i checked the code base :)
We generate a report on the fly for the user. It just depends on the
session data but not on view data, therefore streamedContent is actually a
nice solution.
2013/5/13 Christian Beikov
> I am not sure if that is independent. I think catagy fixed something
I am not sure if that is independent. I think catagy fixed something like
this in a newer release.
Well I fixed the graphicImage thing by using the previously provided
implementation. It's costly because it has to restore the view but in the
end it works for us. We are using the graphicImage in co
I believe it would be possible to solve it with ->
1) check if current component (media etc.) is inside a CC
2) get the CC
3) check if expressionString contains ".attrs." and extract the attribute
name
4) get the expression via the CC#getAttributes(attributeName)
But don't know if it works in all
3.5.4 but thats indepenent :)
2013/5/13 Christian Beikov
> What PF version are you using?
>
>
> 2013/5/13 Thomas Andraschko
>
> > It's really view independent and my Controller is RequestScoped.
> > The only problem is that currently graphicImage/media/filedownload are
> > unusable in a CC,
What PF version are you using?
2013/5/13 Thomas Andraschko
> It's really view independent and my Controller is RequestScoped.
> The only problem is that currently graphicImage/media/filedownload are
> unusable in a CC, if you need to pass the EL into the CC.
>
>
> 2013/5/13 Christian Beikov
>
It's really view independent and my Controller is RequestScoped.
The only problem is that currently graphicImage/media/filedownload are
unusable in a CC, if you need to pass the EL into the CC.
2013/5/13 Christian Beikov
> The difference is that it can handle the view based scopes where the
>
The difference is that it can handle the view based scopes where the
primefaces impl can't. But as I just realize this won't help you at all.
Sorry but for now I can't think of a reliable general purpose way to
retrieve the contents without rebuilding the view, I have to think about it.
Do you need
Hi Christian,
i don't understand your solution exactly.
Whats the difference?
It would still store the #{cc.attrs.xxx} expression and #{cc} cant be
evaluated without #pushComponentToEL(cc).
Also #createView should be avoided for such a request IMO because of
performance.
Regards,
Thomas
2013/
I'd rather say this should be fixed by restoring the view before accessing
the expression. I have done something like that for
DynamicContentResourceHandler which probably is used in this case here too.
Basically you need to save the viewId and the expression together in the
session so you are able
Hi Kito,
CC:
View:
-
Hello Thomas,
I think this is doable. Can you send us your composite component code?
___
Kito D. Mann | @kito99 | Author, JSF in Action
Virtua, Inc. | http://www.virtua.com | JSF/Java EE training and consulting
http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info |
@jsfcentral
+1 203
Hi,
is it possible unwrap a CC ValueExpresion?
i found a bug with PrimeFaces p:media inside a composite component and i
would like to fix it.
If you pass the EL via a CC attr (e.g. #{myController.content}) and attach
it to p:media (e.g. #{cc.attrs.content}),
p:media gets the ValueExpression and s
13 matches
Mail list logo