Re: GWT Violates LGPL
What a farce. Who cares if it violates the LGPL (besides perhaps RMS)? GWT is release under the Apache v2.0 License. The two are completely separate from each other. About the only common heritage they share is the fact that they're OSI approved. On Apr 8, 12:18 am, Robert Hanson iamroberthan...@gmail.com wrote: There is also an about.txt[html] with the GWT distribution. Here are the notable bits: | This product includes software developed by: | - The Apache Software Foundation (http://www.apache.org/). | - Tomcat (http://tomcat.apache.org/) with modifications | - Tapestry (http://tapestry.apache.org/) | - The Eclipse Foundation (http://www.eclipse.org/). | - Java Development Tools (http://www.eclipse.org/jdt/) | - Standard Widget Toolkit (http://www.eclipse.org/swt/) with modifications | - The JFreeChart project (http://www.jfree.org/jfreechart/) | - The Mozilla Foundation (http://www.mozilla.org/). | - Mozilla 1.7.12 (http://www.mozilla.org/releases/mozilla1.7.12/) | - Rhino (http://www.mozilla.org/rhino/) with modifications | - The OpenQA Project (http://openqa.org/) | - Selenium-RC (http://selenium-rc.openqa.org/) | - The WebKit Open Source Project (http://www.webkit.org) So, there is probably some LGPL code in there. But all of this is available in svn isn't it? Wouldn't that comply with any potential make the source available rule? Enough license talk... back to some coding. Robhttp://roberthanson.org On Tue, Apr 7, 2009 at 7:54 AM, Miles T. dupont.nico...@gmail.com wrote: It says : Could not locate 'about.html' in installation directory. :-p On 7 avr, 13:10, Miguel Ping miguel.p...@gmail.com wrote: Just click the 'about' button on the hosted mode browser (the bg window) On Apr 7, 9:43 am, Miles T. dupont.nico...@gmail.com wrote: On Apr 6, 10:52 pm, Daniel Berlin daniel.ber...@gmail.com wrote: On Apr 6, 4:27 pm, allan allan1...@gmail.com wrote: The LGPL does not require source, it is only one of a myriad of options to comply with it. I think (but not sure) I've read somewhere a discussion with a FSF guy saying that the other options were not appliable to GWT. Anyway, why would GWT have to comply with LGPL. Does it use any LGPL component ? I looked athttp://code.google.com/intl/en/webtoolkit/terms.html, it talks about JFreeChart. Didn't know JFreeChart was conveyed with GWT ?! --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
Re: No source code is available for type java.io.File; did you forget to inherit a required module?
Hi Raghu, The GWT compiler complains because it doesn't support the full range of Java classes present in your run of the mill JRE. The reason for this can be found in asking the question; What does the GWT compiler produce as output?. Answering this question yields a far more pertinent question; Where does the resulting JavaScript execute?. The answer of course is the client's browser. Knowing this, it's fairly safe to assume that if we can achieve the same thing using pure JavaScript in the browser (i.e. we could port our Java code to JavaScript) then it's possible with GWT. Given that a browser has no native mechanism that supports file IO (besides perhaps the file input tag) then it makes sense that there would be no File class in GWT. The GWT developers know this and to this extent they've exposed a great deal of base Java classes (primarily the java.lang package) as native peers. This is relatively straight-forward for things like String which can easily be wrapped with a Java class that provides the expected API yet are manipulated underneath the covers using standard JS string functions. If you're ever unsure as to whether or not a native Java class is supported in GWT you can always refer back to the JRE emulation reference here: http://code.google.com/docreader/#p=google-web-toolkit-doc-1-5s=google-web-toolkit-doc-1-5t=RefJreEmulation Regards, Dave On Mar 4, 4:07 am, Lothar Kimmeringer j...@kimmeringer.de wrote: raghu prashanth k b schrieb: Hi...I am new to GWT and i'm trying to develop a small application...but here i need to open a directory and count the no.of files in it...I'm doing it as follows: File dir = new File(file); String[] pages = dir.list(); int count = pages.length; If you do that on the client-side of your application, you should ask yourself, how you would do that with Javascript. If you can come up with an answer (you can't without the use of signed applets or other tweaks), the compiler can't either. This is a question that has been answered so many times already that searching for the error-message, in this group should bring up a lot of results, including ways how to solve your problem (that is dependent if you really want to have a file-list of the files residing on the client-side or if you want ot list files residing on the server-side). Regards, Lothar --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
Re: Help with Byte Array to PDF
Hi koko, Ian is right, I encountered this exact same problem on the project I'm currently working on. In your case it sounds like you want to send some data from a textarea over to the server and put some dynamic content in the PDF, is that right? The best solution I've found is to separate what you're doing into two stages. The first stage I call the preparation stage. The preparation stage involves preparing the data create the PDF from and storing it somewhere temporarily, in my case I used the user's session. Once the data is prepared and stored away you can safely complete the RPC call. The second stage is what I call the generation or retrieval stage. This involves actually generating and retrieving the PDF using the data that was previously stored in the session. This stage is triggered in the onSuccess callback method of the previous RPC call. Really all that needs to be done inside the onSuccess method is to open a new window and point the window.location property to the URL of the servlet you're going to create. Using Ian's technique you can write a simple servlet like he said, generate the PDF using the stored data, and set the content type to application/pdf before writing the byte stream to the servlet's output stream (you can find this inside the HttpResponse object). This will tell the browser that a PDF is coming it's way and it will automatically handle it appropriately. Dave On Feb 17, 11:54 am, koko ang.ga...@gmail.com wrote: Thanks Ian, I had tried this way, but what how should I post my data in textarea to the server side? I encounter like SOP errors, for my tomcat runs on port 8080, while GWT on , I also tried to set in the same port , won't work, can you teach me how to configure or set in detail, I am doing this for my project, thanks for a lot! Regards. On 2月17日, 上午12时34分, Ian Petersen ispet...@gmail.com wrote: On Mon, Feb 16, 2009 at 4:05 PM, koko ang.ga...@gmail.com wrote: I have a problem with converting byte array to pdf file, this will be processing in the client side. in my project the PDF file was constructed by the content in the textarea which user type in, after user press PDF button it will trigger RPC call and get byte array response from server side, actually it was a PDF file, I want to shown it to the user and let them download. Now after RPC byte array was stored in variable called result, what should I do next? Can anyone help me please.. That approach won't work. To serve a PDF to the user, write a servlet that spits out the PDF, annotated with the appropriate Content-Type header. When the user presses the PDF button, either open a new window or display an iframe and, in either case, set the URL for the new window to be the address of your PDF-generating servlet. If you want to prompt the user to save the PDF to disk rather than displaying it the browser, set the Content-Disposition header appropriately. (I forget what value you need there, but you should be able to find it with a good search engine.) Ian --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
