What about the possibility of manually constructing a minimal
component tree and using that instead? Perhaps just a UIViewRoot and
a copy of the graphicImageAjax? The jsf state should be small enough
in that case.
Also, why do you wait until after phase invokeApplication? Isn't it
sufficient
Ok. Now that I have graphicImageAjax working under facelets
(providing the component tree is small enough), I've gone ahead and
switched it from INVOKE_APPLICATION to RESTORE_VIEW (which was already
in the source commented out). It seems to work, but maybe you changed
it because you ran into
We have created a similar component for our application which depends
on a servlet. We use an interface for the value which must be
implemented to return the binary data and the content type. The value
is stored into the session by using an unique key. That key is used in
a param for the url. When
I just commited some changes, (as the RESTORE_VIEW phase), but didn't before.
Constructing a minimal component tree would be the best solution I guess. Do you know how to do that ?
In the current code, you'll find an attempt to provide initializationParameters, but it doesn't work right now,
Sure, using the extension filter would be a solution, but right now, this filter is in Tomahawk, and I wouldn't like to start modifying it for the sole purpose of a sandbox component.
Also, I don't think storing anything in the session is the solution because then you have to manage a lot of
I just would like to settle on this, as the earlier we do the rename, the easiest it'll be.
Any opinion on those graphicImageBytes downloadBytes names ?
Any better proposal ?
Thanks,
Sylvain.
On Wed, 2005-09-28 at 13:09 -0400, Sylvain Vieujot wrote:
I like the fact that it starts
graphicImageDynamic sounds good to me.
2005/9/29, Sylvain Vieujot [EMAIL PROTECTED]:
Don't you think graphicImageDynamic in better then, as when you use auto
completion in your IDE, you clearly have the choice between the 2 ?
The download tag could then be downloadDynamic ?
On Thu,
Of the names presented, I also like graphicImageDynamic the best (and
had already named my facelets tag handler graphicImageDynamicTagHandler)
I've been thinking more about the minimal tree construction, and it
occurs to me that we don't really care what tree exists -- we just want
the method
I agree with this except that using the minimal jsf tree would be an answer for the security problem.
About the initializationParameters, I think that in either cases you'll need it.
Usually just the method binding strings aren't enough.
For example, if you want to display an image for a
a minimal tree or passing the valuebindings through the url won´t work
if someone uses it in a uidata component with a row dependent value.
Writing the binary stream into a tempfile during the render phase will
not work in clustered environments but we could make it an option for
the user. It
About the security issue, you're absolutely right, but at least it's not so straightforward to do, and as it's supposed to be solved in JSF 1.2, we might soon get a fix is the same allover JSF.
On Thu, 2005-09-29 at 11:31 -0400, Mike Kienenberger wrote:
Actually, I wonder if the security
Rename done.
On Thu, 2005-09-29 at 16:05 +0200, Mathias Brkelmann wrote:
graphicImageDynamic sounds good to me.
You're right about the UIData stuff
We'll have to find a workaround for this.
The easiest solution would be to use the initializeParameters and let the burden on the back end bean, but I would prefer to have something transparent to the user.
This temp file solution can't work in a clustered
We can get the encoding behavior as seen in jsf state by calling the
encoding methods. There seem to be enough versions of them
:)
org.apache.myfaces.renderkit.html.HtmlResponseStateManager -- impl
org.apache.myfaces.util.zip.ZipUtils -- impl
org.apache.myfaces.util.StateUtils -- share
Isn't
Has anyone else tried this under Internet Explorer?
It's working fine from Firefox 1.07, but IE 6.0.2800 only displays a broken image.
Ironically, the Jenia4Faces PopupFrame I'm trying to display it in works for IE 6, but doesn't work for Firefox 1.07 :)
Just tried the sandbox example and
Great! We definitely need a component to render dynamic images.
I took a view into the code and saw that the state is appended to the
image url. IMO it will not work in every case since the state could be
very large and as far as I know there is a limitation around 1024
chars in a request url.
How about something like dynaImage?
sean
On 9/28/05, Mathias Brökelmann [EMAIL PROTECTED] wrote:
Great! We definitely need a component to render dynamic images.
I took a view into the code and saw that the state is appended to the
image url. IMO it will not work in every case since the state
As for the URL limitation, this can indeed be a problem, but not @ 1024 chars.
There is no spec limiting the number of chars in the URL, but browsers can have problems :
http://www.aspfaq.com/show.asp?id=
But, as I didn't find any way to use a post request to load an image, I see no
I like the fact that it starts like the standard graphicImage component, but the Dynamic part is good to.
What about graphicImageDynamic?
A bite long though
Or maybe graphicImageBytes, which would be consistent with a downloadBytes tag ?
On Wed, 2005-09-28 at 08:49 -0400, Sean Schofield
Well, the url is also a problem with some containers.
Jetty 5.1.3 is generating this error:
15:28:58.609 WARN!! [SocketListener0-1]
org.mortbay.http.HttpConnection.exception(HttpConnection.java:762)
06 null /faces/pages/announcement/EditAnnouncements.xhtml HTTP/1.1
HttpException(414,Request URI
Except if you serialize the image, the size of the image shouldn't be a factor.
Did you try this with the sandbox application ?
Do you know the URL size limit in Jetty ?
Thanks,
Sylvain.
On Wed, 2005-09-28 at 15:30 -0400, Mike Kienenberger wrote:
Well, the url is also a problem with some
Yes, I think you're right in that the size of the image doesn't matter.
However, the size of my page's jsf_state_64 attribute does matter.
The page I'm looking at right this second has a jsf_state_64 of 3,768
bytes.
No, I didn't try this with the sandbox since it seemed easy enough to
just dump
Yes, probably.
I tested it with Tomcat, and it works fine, but I didn't try on a big page though.
A fix to this problem could be to have an optional initializationParameters, and omit the jsf state.
It wouldn't be as transparent, but it still would remove the need to do a special purpose
One other issue I hit (I hit it earlier but thought it was the URL
size problem by mistake).
You currently have to include this tag inside an h:form, otherwise
there's no jsf_state_64 to reference.
Now that I figured that out, I'm back to trying it in a popup window.
I think there's some
24 matches
Mail list logo
