[gwt-contrib] Re: Comment on UsingOOPHM in google-web-toolkit
the tools directory is a separate checkout.
read this:
http://code.google.com/webtoolkit/makinggwtbetter.html#workingoncode
-jason
On Apr 23, 2009, at 3:51 PM, codesite-nore...@google.com wrote:
>
> Comment by tutufan:
>
> So far I'm not having much luck (64-bit Ubuntu 9.04). The file
> gwt-dev-oophm.jar does not exist in the download (gwt-linux-1.6.4),
> so I'm
> taking that to mean that the prebuilt oophm-xpcom.xpi requires that
> I build
> GWT from svn.
>
> Pulling it down and attempting a build draws the following error
> (below).
> The directory 'tools' is present in the top-level directory, but for
> some
> reason ant is looking for it one level higher, which is outside of the
> source tree. I futzed with this a bit, but it's not obvious to me
> what the
> fix is.
>
> {{{
> m...@delta:~/gwt-svn/google-web-toolkit-read-only$ ant
> Buildfile: build.xml
>
> BUILD FAILED
> /home/mkc/gwt-svn/google-web-toolkit-read-only/build.xml:4: The
> following
> error occurred while executing this line:
> /home/mkc/gwt-svn/google-web-toolkit-read-only/common.ant.xml:56:
> Cannot
> find '/home/mkc/gwt-svn/tools' tools directory; perhaps you should
> define
> the GWT_TOOLS environment variable
>
> Total time: 0 seconds
> }}}
>
>
>
> For more information:
> http://code.google.com/p/google-web-toolkit/wiki/UsingOOPHM
>
> >
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: GWT File Upload issue
agreed, that was the reason for quoting the word bug ...
This discussion really belongs on the user list.
Arun: looks like you are sending an RPC in the onSubmit() of the
form ... RPCs really have nothing to do with the form submission, and
expecting the request of the RPC to adopt the multipart encoding of
the form is unreasonable.
There are samples floating around for using a form submission with
multipart encoding (google GWT file upload), have a look at how that
is done.
-jason
On Apr 15, 2009, at 3:28 AM, Thomas Broyer wrote:
> On 14 avr, 17:03, Jason Essington wrote:
>> I fail to see how this resolves arun's "bug" with GWT form panel
>
> Arun's issue is with his code, not the FormPanel:
>
>>>> form.addFormHandler(new FormHandler() {
>>>> public void onSubmit(FormSubmitEvent event) {
>>>> service.fileUpload(new AsyncCallback(){
>>>> public void onFailure(Throwable caught) {
>>>> Window.alert("FileUpload Failure!!");
>>
>>>> }
>>
>>>> public void onSuccess(Object result) {
>>>> Window.alert("FileUpload Success!!");}});
>>
>>>> event.setCancelled(true);
>>
>>>> }
>
>
> >
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: GWT File Upload issue
I fail to see how this resolves arun's "bug" with GWT form panel
-jason
On Apr 14, 2009, at 7:00 AM, Dug wrote:
>
> Hi arun
>
> U can use GwtSwfExt lib for uploading files(gmail style file upload).
> This lib is wrapper on SWFUpload .
> http://code.google.com/p/gwtswfext/
>
> Thanks
> Dug
>
> On Apr 9, 12:58 am, "arun.r...@gmail.com"
> wrote:
>> Hi All,
>>
>> I am getting multipart false on server side even i am setting it
>> (ENCODING_MULTIPART) on client side.
>>
>> My Code
>> ---
>> -
>>
>> 1.GWTwidget: FormHandle
>>
>> RootPanel rootPanel = RootPanel.get();
>>
>> final FormPanel form = new FormPanel();
>> rootPanel.add(form);
>> form.setAction(GWT.getModuleBaseURL()+"MyFormHandler");
>> form.setEncoding(FormPanel.ENCODING_MULTIPART);
>> form.setMethod(FormPanel.METHOD_POST);
>> .
>> .
>> .
>>
>> panel.add(new Button("Submit", new ClickListener() {
>> public void onClick(Widget sender) {
>> form.submit();
>>
>> }
>> }));
>>
>> .
>> .
>> .
>>
>> form.addFormHandler(new FormHandler() {
>> public void onSubmit(FormSubmitEvent event) {
>> service.fileUpload(new AsyncCallback(){
>> public void onFailure(Throwable caught) {
>> Window.alert("FileUpload Failure!!");
>>
>> }
>>
>> public void onSuccess(Object result) {
>> Window.alert("FileUpload Success!!");}});
>>
>> event.setCancelled(true);
>>
>> }
>>
>> public void onSubmitComplete(FormSubmitCompleteEvent event) {
>> Window.alert(event.getResults());
>>
>> }
>> });
>>
>> RootPanel.get().add(form)
>>
>> 2. Servlet:: MyFormHandlerImpl
>>
>> public class MyFormHandlerImpl extends RemoteServiceServlet
>> implements
>> MyFormHandler {
>>
>> /**
>> *
>> */
>> private static final long serialVersionUID = 1L;
>>
>> @Override
>> public void fileUpload() {
>> System.out.println("0");
>> HttpServletRequest request = super.getThreadLocalRequest();
>> HttpServletResponse response = super.getThreadLocalResponse();
>>
>> boolean isMultiPart =
>> FileUpload.isMultipartContent(request);//isMultipartContent(request)
>>
>> String parentPath ="d:\\";
>>
>> if (isMultiPart) {
>> System.out.println("3");
>> DiskFileUploadupload= new DiskFileUpload();
>> try {
>> List items =upload.parseRequest(request);
>> Iterator it = items.iterator();
>> while (it.hasNext()) {
>> FileItem item = (FileItem) it.next();
>> if(!item.isFormField()){
>> File fullFile = new File(item.getName());
>> File savedFile = new File(parentPath,fullFile.getName());
>> item.write(savedFile);}
>> }
>> } catch (FileUploadException fUE) {
>>
>> System.out.println("file not found");} catch (Exception e){
>>
>> System.out.println("unknown exception");
>>
>> }
>> }
>> }
>> }
>>
>> ---
>> -
>>
>> Can anybody tell me what i am missing here?
>> what could be done to resolve this error?
>>
>> Thanks in advance for your help.
>>
>> Arun.
>
> >
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: auto-deploy GWT on maven repo ?
No? I thought that was going to be the primary focus of 1.6 ... serves me right for thinking :-( -jason On Nov 21, 2008, at 10:36 AM, Ray Ryan wrote: > Oophm is not planned for 1.6 > > On Fri, Nov 21, 2008 at 12:35 PM, nicolas.deloof <[EMAIL PROTECTED] > > wrote: > > I was not aware OOPHM was planned for 1.6, but in such case only jars > are required in maven repo. This will just require the maven plugin(s) > to upgrade and detect gwt version >= 1.6 > > Cheers, > Nicolas > > > On 21 nov, 18:19, Jason Essington <[EMAIL PROTECTED]> wrote: > > but with OOPHM in 1.6, that is no longer necessary is it? > > > > On Nov 20, 2008, at 3:20 PM, Scott Blum wrote: > > > > > Funny you should mention this.. we had a crazy plan once to embed > > > the native libs into gwt-dev.jar, and at startup install them into > > > the temp directory and then load them, with delete on exit. > > > > > On Thu, Nov 20, 2008 at 5:15 PM, Ray Cromwell > > > <[EMAIL PROTECTED]> wrote: > > > If this is done, please make sure that the conventions adhere to > the > > > gwt-maven plugin's repo layout. This allows you to use the > > > maven-dependency plugin to download the platform specific JNI > > > libraries separately and unpack them, so that one doesn't have to > > > "install" the GWT distribution and set up a GWT_HOME environment > > > variable. > > > > > I use this in my build process which allows Chronoscope to build > clean > > > on an empty computer with only Java and Maven installed and no > other > > > prerequisites or reliance on absolute file system paths. This > allows > > > us to startup a VMWare instant with an OS of our choice, and > have it > > > build and test out of the box with virtually no configuration > needed. > > > > > -Ray > > > > > --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: auto-deploy GWT on maven repo ?
but with OOPHM in 1.6, that is no longer necessary is it? On Nov 20, 2008, at 3:20 PM, Scott Blum wrote: > Funny you should mention this.. we had a crazy plan once to embed > the native libs into gwt-dev.jar, and at startup install them into > the temp directory and then load them, with delete on exit. > > On Thu, Nov 20, 2008 at 5:15 PM, Ray Cromwell > <[EMAIL PROTECTED]> wrote: > If this is done, please make sure that the conventions adhere to the > gwt-maven plugin's repo layout. This allows you to use the > maven-dependency plugin to download the platform specific JNI > libraries separately and unpack them, so that one doesn't have to > "install" the GWT distribution and set up a GWT_HOME environment > variable. > > I use this in my build process which allows Chronoscope to build clean > on an empty computer with only Java and Maven installed and no other > prerequisites or reliance on absolute file system paths. This allows > us to startup a VMWare instant with an OS of our choice, and have it > build and test out of the box with virtually no configuration needed. > > -Ray > > > > --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Proposed API Addition - PopupPanel.get/setModal() and PopupPanel.get/setAutoHide()
@Emily In my case, I needed to create a modal non-autohiding DropDown Panel. however, the problem is that DropDown calls the PopupPanel constructor that creates a non-modal auto-hiding PopupPanel. Currently the only way to flip those bits subsequent to instantiation but prior to display is to use the violator pattern to set the private field values. I suppose that toggling those bits after the panel is displayed is pretty meaningless, and as such could maybe throw IllegalStateExcpetion. -jason On Oct 6, 2008, at 10:44 AM, Emily Crutcher wrote: > +1 to > public boolean isAutoHideEnabled() > public boolean isModal() > > Why do we want to change whether auto hide/modality is enabled on an > existing popup panel? It seems like if we do this we would need to > check for edge cases that currently don't come up. > > > On Mon, Oct 6, 2008 at 12:09 PM, Alex Rudnick <[EMAIL PROTECTED]> wrote: > > +1, sounds like a good idea. > > On Mon, Oct 6, 2008 at 11:54 AM, Jason Essington > <[EMAIL PROTECTED]> wrote: > > +1 here, as I've recently had to use the violator pattern to flip > those > > bits. > > -jason > > -- > Alex Rudnick > swe, gwt, atl > > > > > > -- > "There are only 10 types of people in the world: Those who > understand binary, and those who don't" > > > --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Proposed API Addition - PopupPanel.get/setModal() and PopupPanel.get/setAutoHide()
+1 here, as I've recently had to use the violator pattern to flip those bits. -jason On Oct 6, 2008, at 9:44 AM, John LaBanca wrote: > Contributors - > > I propose adding the following accessors and getters to PopupPanel: > public boolean isAutoHideEnabled() > public boolean isModal() > public void setAutoHideEnabled(boolean autoHide) > public void setModal(boolean modal) > > Currently, autoHide and modal are private members of PopupPanel, so > subclasses cannot change these values. From a cursory glance, it > looks like PopupPanel checks these variables as needed, so > implementing these methods would not require any special handling in > case the PopupPanel is currently open. > > Here is the relevant issue: > http://code.google.com/p/google-web-toolkit/issues/detail?id=2855 > > This seems like a valuable addition to the API, but I wanted to see > if anyone has an obvious reason why we shouldn't add these methods. > > Thanks, > John LaBanca > [EMAIL PROTECTED] > > > --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: RR : Three new RPC design docs
I'll bite I guess
RPC-Auth:
No specific comments, but the design looks sound, and should be easy
enough to tie in to authentication schemes on the server side.
+1
oh, in your simple login scenario, you have svc.login("foo", "foo",
someCallback); then your variable magically changes in the next line
to svn.restrictedMethod(someCallback); (but I'm sure you just did that
to see if anyone was actually reading)
RPC-Swizzle:
This looks like a reasonable solution to the issues currently seen
with collections and lists being sent back from Hibernate and such.
+1
de-RPC:
This one actually hits home as I've just been looking at ways to
improve some existing GWT code. I was performance testing the de-
serialization of JSON and RPC payloads for an Identical object graph.
The object graph in JSON format was 180K, and in RPC format was 68K.
It turned out that the de-serialization of the larger JSON data via
eval took about 20ms while the smaller (byte wise) RPC format took
almost half again as long 35ms. This appears to show that direct
evaluation is quite a bit faster, and that RPC could gain some
performance through its implementation. Hosted mode showed a
ridiculous speed advantage for direct evaluation 22ms vs 1480ms!
With the advent of overlay types for the javascript object, RPC is
losing a bit of its advantage, so adding a little performance boost,
as well as the possibility to use it on non-java back-ends could only
help.
-jason
On Sep 4, 2008, at 3:29 PM, BobV wrote:
>
> Is anyone up for a review?
>
> --
> Bob Vawter
> Google Web Toolkit Team
>
> >
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
