Hello,
Sorry for that.
I did the test for Firefox, and it worked well.
Before the upgrade, all the pages with a dojo component looked blank :
I use linux and have no IE, but I asked Cagatay to test it under
windows, and he didn't report me any problem.
Can you give me the link to the bug crashing
Versions: 1.1.5-SNAPSHOT
Environment: Linux / Firefox 2. Don't know about other OS at this stage
Reporter: Sylvain Vieujot
Any page that has a component that uses the Dojo toolkit (inputSuggest, ...)
displays as blank under firefox.
For example in the myfaces-example-s
[ http://issues.apache.org/jira/browse/TOMAHAWK-738?page=all ]
Sylvain Vieujot updated TOMAHAWK-738:
-
Status: Resolved (was: Patch Available)
Resolution: Fixed
Assignee: Sylvain Vieujot (was: Cagatay Civici)
xed in rev 465098 by
[ http://issues.apache.org/jira/browse/TOMAHAWK-738?page=all ]
Sylvain Vieujot updated TOMAHAWK-738:
-
Status: Patch Available (was: Reopened)
> SaveState fails with a java.util.List implementation other than ArrayL
[
http://issues.apache.org/jira/browse/TOMAHAWK-738?page=comments#action_12443067
]
Sylvain Vieujot commented on TOMAHAWK-738:
--
I agree with Cagatay here.
In our applications we heavily rely on the savestate tag so save objects.
When
f you are interested, please send me your resume and your price at [EMAIL PROTECTED]
Thank you,
Sylvain Vieujot
CEO / CIO Freelance.com
You could do :
if( request.getAttribute(org.apache.myfaces.webapp.filter.ExtensionsFilter.DOFILTER_CALLED)!=null )
But the DOFILTER_CALLED variable is private.
Maybe hack it with a copy of the String.
If you find it useful, maybe the clean way would be to add an hasBeenCalled public static met
+1
On Thu, 2006-03-30 at 23:06 +0200, Martin Marinschek wrote:
I believe code quality, documentation, examples and support for the
schedule component is good enough for it to be moved over to tomahawk.
my +1 for this.
regards,
Martin
safety over xdoclet. It's also much faster than the xdoclet plugin.
So my suggestion would be to start from this, and then to enhance it for those that would need more out this plugin.
On Wed, 2006-03-29 at 19:26 +0200, Werner Punz wrote:
Sylvain Vieujot schrieb:
> I don't thi
Good idea.
Maybe just before doing that we could check if we couldn't move some components from the sandbox to tomahawk.
For example : convertboolean, fieldset, focus, ... ?
At least those three seems simple enough and havent been modified since months, so they might be good candidates.
Sylva
I don't think we should rule out the use of annotations for navigation rules.
Even if navigation rules are tied to the presentation layer, so are bean names.
I also see good user cases for navigation rules defined as annotations.
Here is just an example :
In my projects there is a "management
[
http://issues.apache.org/jira/browse/TOMAHAWK-65?page=comments#action_12372092
]
Sylvain Vieujot commented on TOMAHAWK-65:
-
I just upgraded the kupu code to version 1.3.5.
I don't have any IE browser though, so could someone please confi
I agree, it would be very nice and avoid double validation code for the hibernate users.
It would also prevent meaning less errors for the users and show the exact problem.
Great idea !
Sylvain.
On Sat, 2006-03-11 at 17:45 +0100, Jurgen Lust wrote:
How about this approach?
Hello Martin,
I'm on the plane today, but I'll check that over the week-end.
Best regards,
Sylvain.
On Fri, 2006-02-17 at 04:15 +0100, Martin Marinschek wrote:
Hi Sylvain,
how hard would it be for you to loose the moving circle you have built
in in the current inputSuggestAjax component?
[
http://issues.apache.org/jira/browse/MYFACES-1118?page=comments#action_12366416
]
Sylvain Vieujot commented on MYFACES-1118:
--
I didn't really follow the last modifications with the resourceLoaders, but the
parsed lastModified is us
Cactus tests not run by "mvn test"
--
Key: MYFACES-1120
URL: http://issues.apache.org/jira/browse/MYFACES-1120
Project: MyFaces
Type: Test
Reporter: Sylvain Vieujot
The cactus tests aren't run by maven :
mvn
[ http://issues.apache.org/jira/browse/MYFACES-1119?page=all ]
Sylvain Vieujot closed MYFACES-1119:
Resolution: Fixed
r377535.
> EL evaluating undefined variable trhows exception instead of returning n
: Implementation
Reporter: Sylvain Vieujot
Assigned to: Sylvain Vieujot
Expressions like #{empty undefinedVariable} now throw exception because of
LastVariableResolverInChain.resolveVariable throwing an exception if the
variable could not be resolved.
--
This message is automatically
: Nightly
Reporter: Sylvain Vieujot
Since the build is done by Maven, the ant code that was parsing the
commons/src/main/resources/org/apache/myfaces/renderkit/html/util/AddResource.properties
by replacing the @lastModified@ tag with the build date is gone.
So the file in the jar now contains
ion filter, could you explain
me how it works or how it should work?.
Any Idea or tip?.
al.
On 11/14/05, Sylvain Vieujot <[EMAIL PROTECTED]> wrote:
> I don't like this external config file.
> I think the proper way of doing this is to overload the Kupu method that
> confi
I don't like this external config file.
I think the proper way of doing this is to overload the Kupu method that configures the images library box.
So, we could pass to the inputHtml tag a Map containing images URLs as Key, and Images descriptions as held Objects.
What do you think ?
Sylvain
[
http://issues.apache.org/jira/browse/MYFACES-736?page=comments#action_12357512
]
Sylvain Vieujot commented on MYFACES-736:
-
I didn't find how to fix this yet, but here is a workaround.
As NumberFormat.parse returns either a Long or a Double
Yes, it would be very nice.
It's on my todo list since quite some times now.
Kupu already has some provision to do this.
It needs to be enabled and made compatible with JSF.
I would be happy to review and commit your patch on this.
Thanks,
Sylvain.
On Wed, 2005-11-09 at 19:41 +0100, Alberto
I think we should investigate on this bug (h:inputText with f:convertNumber) doesn't work.
http://issues.apache.org/jira/browse/MYFACES-736
It doesn't work on trunk and Keijo Nurmes reported that it doesn't work on RC3 either.
As I have absolutely no time to investigate on this, I won't vote
[
http://issues.apache.org/jira/browse/MYFACES-736?page=comments#action_12332702
]
Sylvain Vieujot commented on MYFACES-736:
-
In fact, it's not working with primitive int either.
BUT it's working fine with primitive float.
> Number
Number converter not working with Number
Key: MYFACES-736
URL: http://issues.apache.org/jira/browse/MYFACES-736
Project: MyFaces
Type: Bug
Components: Implementation
Versions: Nightly
Reporter: Sylvain Vieujot
s actually subject to the Kupu licence.
___
kupu-dev mailing list
[EMAIL PROTECTED]
http://codespeak.net/mailman/listinfo/kupu-dev
On Mon, 2005-10-10 at 10:50 +0200, Werner Punz wrote:
Sylvain Vieujot wrote:
> Downloading Sarissa it at build would be fine, for those that build fr
r those that build from source.
But wouldn't it prevent us from distributing the compiled version ?
regards,
Martin
On 10/9/05, Sylvain Vieujot <[EMAIL PROTECTED]> wrote:
Indeed, this is bad.
I checked the Kupu licence, but not the one of a
Indeed, this is bad.
I checked the Kupu licence, but not the one of all included libraries
Plus, Kupu is the only decent HTML Editor I found with a compatible licence.
A quick fix would be to add a sarissa path, or to ask the developers to include the lib on the page.
A better fix would be t
I just tried to code a compact tree serialization.
It's not very successful now, as I still have bugs while generating the tree (I get a duplicate id error).
If someone fluent in dynamic tree generation could look at it, it would help
Once fixed, we might have to change it to make it work in
od binding attributes
> directly into the url seems best :)
>
> Maybe we can cryptologically sign the URL somehow -- hash the strings
> against the jsf state tree or something and also pass that as an argument :)
>
>
>
>
> On 9/29/05, Sylvain Vieujot <[EMAIL PROTECTED]&
Rename done.
On Thu, 2005-09-29 at 16:05 +0200, Mathias Brökelmann wrote:
graphicImageDynamic sounds good to me.
works for me :)
On 9/29/05, Sylvain Vieujot <[EMAIL PROTECTED]> wrote:
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.
the method binding attributes directly into the url seems best :)
Maybe we can cryptologically sign the URL somehow -- hash the strings against the jsf state tree or something and also pass that as an argument :)
On 9/29/05, Sylvain Vieujot <[EMAIL PROTECTED]> wrote:
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
e has a lot of images. If the state has a
considerable size it would be posted for every image and slows down
the rendering of the page in the browser.
The patch for the action event isn´t the problem. But we should
discuss whats the best solution before changing everything.
2005/9/28, Sylvain
't it
> sufficient to render a response after the restoreView phase?
>
>
> On 9/28/05, Sylvain Vieujot <[EMAIL PROTECTED]> wrote:
> > Yes, probably.
> > I tested it with Tomcat, and it works fine, but I didn't try on a big page
> > though.
> > A fix to th
also noticed that this error (414 Url too large) is a
standard http protocol error, so it's reasonable to think that other
servers are going to throw it.
On 9/28/05, Sylvain Vieujot <[EMAIL PROTECTED]> wrote:
> Except if you serialize the image, the size of the image shouldn't b
ith a small (13,342 byte) image. Well, relatively small :)
On 9/28/05, Sylvain Vieujot <[EMAIL PROTECTED]> wrote:
> 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
s
> event which is queued through UIComponent.queueEvent(...).
>
>
> 2005/9/28, Sylvain Vieujot <[EMAIL PROTECTED]>:
> > I just committed a first working version of a graphicImage component that
> > displays the images from bytes, and that doesn't need an additional servlet.
>
the phase listener which will not work if the
component is used in a uidata component. Try using a custom faces
event which is queued through UIComponent.queueEvent(...).
2005/9/28, Sylvain Vieujot <[EMAIL PROTECTED]>:
> I just committed a first working version of a graphicImage compon
a component that can display an image
from bytes as well, if you want any assistance.
"-- need a dynamic image servlet" is the next item on my todo list :)
On 9/26/05, Sylvain Vieujot <[EMAIL PROTECTED]> wrote:
> Yes, you're right, but I was looking for a way to use the same
t for head - or body
tags, I don't like having to parse the whole output for these strings
- there are just too many possibilities. With a clearly defined call
to startElement, we know the position!
regards,
Martin
On 9/27/05, Sylvain Vieujot <[EMAIL PROTECTED]> wrote:
> I think i
tion.
>
> Not having a separate filter would be good, but I don't know how this can
> be done, as any HTML rendered before the JSF components would be lost.
>
>
> Wait a minute - we could set the insert position by setting request
> parameters which the filter reads, right?
ow how this can be done, as any HTML rendered before the JSF components would be lost.
Wait a minute - we could set the insert position by setting request
parameters which the filter reads, right?
Sure !
regards,
Martin
On 9/27/05, Sylvain Vieujot <[EMAIL PROTECTED]> wrote:
>
!
We are doing this today for the rendering of the _javascript_ for commandLinks...
If we don't find a way to fix this problem, we won't be able to use
the ADF components with MyFaces apps, nor will facelets be properly
working.
regards,
Martin
On 9/27/05, Sylvain Vieujot <[EMAIL
won't get the functionality if he doesn't use
t:head or t:body. It will still work, he just won't have the extras.
regards,
Martin
On 9/27/05, Sylvain Vieujot <[EMAIL PROTECTED]> wrote:
> Hello Martin,
>
> I'm not sure I understand this.
> Would you requir
Hello Martin,
I'm not sure I understand this.
Would you require every page having a t:component to have t:head & t:body components as well ?
If this is the case, it would be a lead to a lot ot other problems I think.
For example, it would break old pages. Also, you could not include just a t:
you posted is just about remembering the state of the
application client side - it doesn't have to do anything with dynamic
loading of images...
Or do I get you completely wrong?
regards,
Martin
On 9/26/05, Sylvain Vieujot <[EMAIL PROTECTED]> wrote:
> You're right, Ajax isn&#x
y to load an image is, as you say, using the src property of the image object, and that will always do a GET. I don't see how you get AJAX to work into this scenario, unless you plan to use it to generate the URL for the image object to load.
Or am I just missing somethin
> -1 for the special target.
>>
>> Its a lot of extra maintenance and the only reason I am hearing for
>> this is convenience (you don't have to change your JSP when a
>> component is promoted.)
>>
>> sean
>>
>> On 9/26/05, Sylvain Vieujot <[EMA
is what I am proposing now. I am prepared to compromise by
> > including sandbox stuff in the distro but my position is that
> > it should not be part of all and that we shouldn't sandbox
> > stuff in with the TLD or faces-config.xml for tomahawk.
> >
>
now. I am prepared to compromise by including sandbox
> > stuff in the distro but my position is that it should not be part of
> > all and that we shouldn't sandbox stuff in with the TLD or
> > faces-config.xml for tomahawk.
> >
> > sean
> >
> > On 9/
Hello,
I'm trying to make a new component that would display an image, but without the need to have a dedicated servlet.
It would make applications that use images from a lot of different sources (i.e. servlets) much simpler.
Basically, it would be a component like :
As the only way I found
ts in each component's directory, and to generate each tld in the build process.
Any thoughts about this ?
Sylvain.
On Mon, 2005-09-26 at 14:57 -0400, Sylvain Vieujot wrote:
I too think it makes sens to release the sandbox into the myfaces-all.jar.
But if we do that, then this ja
I too think it makes sens to release the sandbox into the myfaces-all.jar.
But if we do that, then this jar needs to contain a faces-config.xml that merges the ones from tomahawk & from the sandbox (build file, merge-sandbox target).
The process for merging the faces-config.xml files & the tld
files. I'd imagine that
the sandbox components are often dependent on a specific tomahawk
version.
On 9/26/05, Sylvain Vieujot <[EMAIL PROTECTED]> wrote:
> Hello Sean,
>
> It's not a question of laziness.
> As said before, having one common jar is very useful when
, and not in tweaking the build process!
>
> ... and I'd like to hear John Fallow's opinion here - the Oracle guys
> are putting a lot of effort in their deployment and building process,
> let's see what his opinion on this would be.
>
> regards,
>
> Martin
>
&
box
component to tomahawk once is mature, so people can use it in their
applications. IMO, people will begin to miss the difference between
the sandbox and tomahawk...
My two cents,
Bruno
2005/9/24, Sylvain Vieujot <[EMAIL PROTECTED]>:
> With a separate sandbox, you can
clude the sandbox by default. Other
than that, I disagree. I don't see any real advantage of mixing the
sandbox stuff into the other jars. I think it should be kept separate
and for those who want to use sandbox stuff before its released, just
add the extra sandbox.jar. What would be so hard a
As for the relases, you're right.
But I also see great value still having a single jar with everything.
I allows seamless migration from the sandbox to tomahawk.
As such, it allows us to really test the sandbox.
Otherwise, I'm afraid the components in the sandbox will be really less used and te
[ http://issues.apache.org/jira/browse/MYFACES-380?page=all ]
Sylvain Vieujot closed MYFACES-380:
---
Fix Version: Nightly Build
Resolution: Fixed
Implemented in the sandbox.
> New component
> --
>
>
Yes, this is it.
I just close the bug.
Thanks for the notice.
Sylvain.
On Wed, 2005-09-21 at 17:49 -0400, Sean Schofield wrote:
Cool. There is an old JIRA issue on this (MYFACES-380.) Does this
basically implement that?
sean
On 9/20/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Aut
[
http://issues.apache.org/jira/browse/MYFACES-565?page=comments#action_12329428
]
Sylvain Vieujot commented on MYFACES-565:
-
Yes, it work now.
Thanks Bruno.
> t:dataList doesn't work with Sets
[
http://issues.apache.org/jira/browse/MYFACES-565?page=comments#action_12329346
]
Sylvain Vieujot commented on MYFACES-565:
-
No, still the same problem :-(
The row variable (row="...") is still assigned to the Set, not to the Set
[
http://issues.apache.org/jira/browse/MYFACES-376?page=comments#action_12329342
]
Sylvain Vieujot commented on MYFACES-376:
-
I had the bug in one of my applications.
The reason is : ContentTypeList does not contain a supported content type:
text
t:dataList doesn't work with Sets anymore
-
Key: MYFACES-565
URL: http://issues.apache.org/jira/browse/MYFACES-565
Project: MyFaces
Type: Bug
Components: Tomahawk
Versions: Nightly Build
Reporter: Sy
issue b/c it doesn't need (nor should it have)
the sandbox stuff. As long as the build is good we can leave you
changes and worry about this the next time we need to release.
sean
On 9/13/05, Sylvain Vieujot <[EMAIL PROTECTED]> wrote:
> Hello Sean,
>
> I just re-fixed
[ http://issues.apache.org/jira/browse/MYFACES-557?page=all ]
Sylvain Vieujot closed MYFACES-557:
---
Resolution: Invalid
Sorry, the bug was in my application.
> f:convertNumber always sets the backing bean value t
Hello Sean,
I just re-fixed the path because with this commit, the files go in subdirectories of META-INF.
For example,
temp/myfaces_all.tld" unless="skip.sandbox"/>
Should be :
" prefix="META-INF/">
Thanks,
Sylvain.
On Tue, 2005-09-13 at 22:06 +, [EMAIL PROTECTED] wrote:
A
f:convertNumber always sets the backing bean value to 0
---
Key: MYFACES-557
URL: http://issues.apache.org/jira/browse/MYFACES-557
Project: MyFaces
Type: Bug
Reporter: Sylvain Vieujot
An inputText with a
[
http://issues.apache.org/jira/browse/MYFACES-553?page=comments#action_12323298
]
Sylvain Vieujot commented on MYFACES-553:
-
Thanks.
> NullPointerException in WebXml.getFacesServletMappi
[
http://issues.apache.org/jira/browse/MYFACES-554?page=comments#action_12323277
]
Sylvain Vieujot commented on MYFACES-554:
-
Thanks.
> UISelectMany crashes on submit
> --
>
> Key: MYFACES-554
&g
[
http://issues.apache.org/jira/browse/MYFACES-553?page=comments#action_12323244
]
Sylvain Vieujot commented on MYFACES-553:
-
I just committed a fix (r280367), but as I'm not 100% sure it is correct, I
leave this bug open.
Oliver, could you
UISelectMany crashes on submit
--
Key: MYFACES-554
URL: http://issues.apache.org/jira/browse/MYFACES-554
Project: MyFaces
Type: Bug
Versions: Nightly Build
Reporter: Sylvain Vieujot
When submitting a page with a UISelectMany
Reporter: Sylvain Vieujot
Assigned to: Oliver Rossmueller
Priority: Blocker
Oliver, I assigned this to you because I have this bug only since your last
changes.
Here is that bug report with the Stack Trace.
You will see the NPE at WebXml.java:90
Error Report
HTTP Status : 500
Date
[ http://issues.apache.org/jira/browse/MYFACES-544?page=all ]
Sylvain Vieujot closed MYFACES-544:
---
Fix Version: Nightly Build
Resolution: Fixed
This has been fixed a few hours ago.
Thanks anyway,
Sylvain.
> HtmlTableRendererBase thr
[
http://issues.apache.org/jira/browse/MYFACES-286?page=comments#action_12322820
]
Sylvain Vieujot commented on MYFACES-286:
-
I agree with you for h:dataTable, but for x:dataTable, I think it would be a
plus to support all collections.
Couldn'
[
http://issues.apache.org/jira/browse/MYFACES-509?page=comments#action_12322789
]
Sylvain Vieujot commented on MYFACES-509:
-
Revision r279101 is causing this problem.
the clientId was unique, but the id isn't because of the subviews.
I rev
[ http://issues.apache.org/jira/browse/MYFACES-509?page=all ]
Sylvain Vieujot reopened MYFACES-509:
-
I think there is a problem with this fix :
If 2 subviews have components with the same id, an exception is thrown
or myfaces! ;-)
2005/9/7, Sylvain Vieujot <[EMAIL PROTECTED]>:
> I didn't mean to include it in the sandbox and hope to refactor it later.
> I meant to add it to the sandbox, and to move it to tomahawk only when we
> accept JSE5 code in tomahawk (which is required for JSF 1.2 if I&#
t that we will not have much drive towards moving components from sandbox to tomahawk then, but that's something we should be able to cope with, I'd say.
>
> regards,
>
> Martin
>
>
>
> On 9/6/05, Sylvain Vieujot <[EMAIL PROTECTED]> wrote:
> &g
x27;t think we should add stuff and hope to refactor
it later.
sean
On 9/6/05, Sylvain Vieujot <[EMAIL PROTECTED]> wrote:
> Hello,
>
> I was about to commit the few Maps util classes I have when I realized it's
> all Java 5 code (with many generics and a few annotatio
t it there, and go on from this!
regards,
Martin
On 9/6/05, Sylvain Vieujot <[EMAIL PROTECTED]> wrote:
> Hello Martin,
>
> No, I never committed it.
> I think a new package would be great, but where do you want to put it ?
> The logic would be to have it first in the sandb
Hello,
As we have a myfaces-all.jar, it would be nice to also add a corresponding tld with http://myfaces.apache.org/all to this jar.
This tld would roughly concatenate the ones from tomahawk & from sandbox.
That way, we could recycle the old x: prefix, and avoid changing the applicatio
omahawk jsfutils
We could also have the user contributions like the message-remembering
facilities and the newly added remember request-bean over redirect
facilities there...
regards,
Martin
On 5/11/05, Sylvain Vieujot <[EMAIL PROTECTED]> wrote:
> I'm fine with that and find
[ http://issues.apache.org/jira/browse/MYFACES-508?page=all ]
Sylvain Vieujot closed MYFACES-508:
---
Fix Version: Nightly Build
Resolution: Fixed
Indeed this was a bug.
It should be fixed now.
Thanks for reporting this.
Sylvain
[ http://issues.apache.org/jira/browse/MYFACES-492?page=all ]
Sylvain Vieujot closed MYFACES-492:
---
Fix Version: Nightly Build
Resolution: Fixed
> UISelectMany doesn't validate
> -
>
>
UISelectMany doesn't validate
-
Key: MYFACES-492
URL: http://issues.apache.org/jira/browse/MYFACES-492
Project: MyFaces
Type: Bug
Components: Implementation
Reporter: Sylvain Vieujot
Fix For: Nightly Build
--
[ http://issues.apache.org/jira/browse/MYFACES-491?page=all ]
Sylvain Vieujot closed MYFACES-491:
---
Fix Version: Nightly Build
Resolution: Fixed
> SelectOneCountry & SelectOneLanguage don
SelectOneCountry & SelectOneLanguage don't validate
---
Key: MYFACES-491
URL: http://issues.apache.org/jira/browse/MYFACES-491
Project: MyFaces
Type: Bug
Components: Tomahawk
Reporter: Sylvain Vieujo
[ http://issues.apache.org/jira/browse/MYFACES-490?page=all ]
Sylvain Vieujot closed MYFACES-490:
---
Resolution: Fixed
> Messages for UISelectOne & UISelectMany don't include the component's name
> like for
browse/MYFACES-490
Project: MyFaces
Type: Improvement
Components: Implementation
Versions: Nightly Build
Reporter: Sylvain Vieujot
Priority: Minor
Fix For: Nightly Build
--
This message is automatically generated by JIRA.
-
If you think it was sent incor
absolutely right. The only solution would be to rewrite
current web browsers, which might be diffcult :-)
I think we could close this issue.
-Manfred
2005/8/31, Sylvain Vieujot <[EMAIL PROTECTED]>:
> No, there is no that I know of t
[ http://issues.apache.org/jira/browse/MYFACES-474?page=all ]
Sylvain Vieujot closed MYFACES-474:
---
Resolution: Invalid
I think you forgot to configure the extensions filter.
The doc isn't visible on the website though, but it'll be res
Hello Sean,
As I'm not the king of forrest, I prefer to ask this to you.
In the reorg, I think the link to the extensions filter doc has been lost.
The page is still in forest/content/xdoc/docs but there is no link to it.
Could you try to make it visible from the tomcat page ?
Thanks,
Sylvai
No, there is no that I know of to do this, as it would be a security problem for the browsers (it would allow you get any file from a user, without him knowing it).
On Wed, 2005-08-31 at 10:52 -0500, [EMAIL PROTECTED] wrote:
Hello All,
I'm using the FileUpload component of
[
http://issues.apache.org/jira/browse/MYFACES-473?page=comments#action_12320684
]
Sylvain Vieujot commented on MYFACES-473:
-
The reason for this security check is that without it, you could use the filter
with a crafted class name to access any
[
http://issues.apache.org/jira/browse/MYFACES-271?page=comments#action_12320028
]
Sylvain Vieujot commented on MYFACES-271:
-
Now, all the inputDate tags are enclosed in a span which has the expected id
for the labels, ...
So the validation should
For really new components, I agree with you, but this one as really nothing new or experimental.
So I prefer to postpone it because adding it to the sandbox means I'll have to change all the prefixes if I use it.
... for a convenient tag, this isn't very convenient.
P.S. As for the doc, it's
1 - 100 of 334 matches
Mail list logo
