Re: [ERROR] Only either css files or gss files are supported on one interface

2015-03-04 Thread Ed Bras
Ahhh, yes, you explained that before, sorry for that.
All clear now, I have to think about how to use it.

​

-- 
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.


Re: [ERROR] Only either css files or gss files are supported on one interface

2015-03-04 Thread Jens


> > Because GWT can not convert it on a file-by-file basis. 
> Why not ?
>

I have already said it before: in case of old css a constant might be used 
in one file but is defined in a different file. In case of gss you might 
use a @mixin in one file but that @mixin is defined in a different file. 

-- J.

-- 
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.


It should be registered via or entry in your .gwt.xml ?

2015-03-04 Thread Ed
I include a background image in a css file through a @sprite annotation and 
do get a warning (see subject and below) that it should be included in the 
gwt.xml gwt file.
How should this be done? The documentation still describes it like I use it 
below that results in a warning.
Details:

Css file:
@sprite .Bla {
  gwt-sprite: "quickCheck";
}

And in the ClienBundle class it's included as:
 @Source("quickCheck.jpg")
 ImageResource quickCheck();


And get the following console warning:
As a result changes in that resource will not be reflected in per-file 
recompiles. It should be registered via  or  entry in 
your .gwt.xml. In a future version of GWT, we will remove this fallback and 
your application will stop compiling 



-- 
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.


Re: [ERROR] Only either css files or gss files are supported on one interface

2015-03-04 Thread Ed Bras
Thanks @Jens.

> Because GWT can not convert it on a file-by-file basis.
Why not ?
​

-- 
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.


Re: [ERROR] Only either css files or gss files are supported on one interface

2015-03-04 Thread Jens

>
>
> If I understand you correctly, I could be able to mix css and gss files by 
> using the correct extension. In case it concerns a css file, the gss 
> mechanism will sue the css2gss converter to create the gss file before 
> passing it to to the closure compiler. But that is what I am doing, so why 
> isn't that allowed?
>

Because GWT can not convert it on a file-by-file basis. All files need to 
be merged to get complete information for parsing. So all files need to be 
of the same type.

-- J.

-- 
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.


Re: [ERROR] Only either css files or gss files are supported on one interface

2015-03-04 Thread Ed Bras
Thanks for the explanation @Jens. I think I understand why the extension is
important. So we can't  let go if that requirement.
But let's go back to the original error (subject of the topic).
If I understand you correctly, I could be able to mix css and gss files by
using the correct extension. In case it concerns a css file, the gss
mechanism will sue the css2gss converter to create the gss file before
passing it to to the closure compiler. But that is what I am doing, so why
isn't that allowed?
- Ed
​

-- 
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.


Re: (Server-side) AutoBeans and thread-safety

2015-03-04 Thread Andreas Kohn


On Tuesday, February 24, 2015 at 6:56:50 PM UTC+1, Andreas Kohn wrote:

> I understand that autobean's are actually parsed lazily, so for me this 
> looks like a concurrency issue somewhere inside the autobeans framework 
> itself. I didn't see any notes about sharing autobeans between threads in 
> the documentation, so:
> 1. Should it be possible to share them, or is additional synchronization 
> in the application code needed? 
> 2. Instead of synchronizing all accesses, would it be enough to force a 
> full parse run of the autobean before making it visible to other threads?
> 3. Is this problem only affecting server-side code, or would similar 
> issues also be possible in client-side code? (I'm suspecting: "It depends 
> on the browser's implementation of JS?")
>
> Regarding the second question: I did not manage to reproduce the issue by 
> using this additional code:
> AutoBeanUtils.getAutoBean(delegate).accept(new AutoBeanVisitor() { /* 
> Nothing */ });
>
>
>
Small update here: I was able to get my test to break again even after 
using the #accept() idea, by using a Map property in the bean, and 
iterating over its entry set. So my conclusion here: using autobeans on the 
server side without external synchronization and careful coding is 
dangerous. 

I've now worked around this issue by copying the contents of the bean into 
a separate class that implements the bean interface as well. In my case I 
do not need the ability to modify the contents, so I didn't bother working 
out how I'd get my copy serialized into JSON again.

Regards,
--
Andreas

-- 
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.


Re: [ERROR] Only either css files or gss files are supported on one interface

2015-03-04 Thread Jens
What you are asking for is simply not possible in a reliable way under the 
requirement that old css syntax needs to be converted to gss syntax to 
avoid producing compile errors when activating GSS for a project.

When I give you (which is hopefully similar to your use case):

@Source({ app-constants.gss, library-constants.css, library-mywidget.css, 
app-mywidget.gss })

Then what should GWT do to produce valid GSS code that can be handed over 
to closure stylesheets? 

- The ordering of files is important as later files can override CSS rules 
in previous files (e.g. library-mywidget could produce a red widget by 
default and app-mywidget overrides it to a blue gradient)
- Any css file might be compatible with GSS as-is but maybe it is not. If 
you can not use the file extension to decide it you need to try parsing a 
css file using a GSS parser. If it fails it is incompatible and would need 
to be converted using the css2gss in-memory converter.
- app-mywidget.gss might reuse constants provided by library-constants.css 
as well use constants from app-constants.gss.


So what would you do now?

1.) You can not try parsing each file one-by-one to figure out if it is GSS 
compatible because each file might use constants provided by other files. 
If the parser does not see the constant definition it would fail even 
though the file might be GSS compatible. The parser needs complete 
knowledge.

2.) Because of the previous you need to merge all files before parsing so 
you have all information available. Parsing the merged data might work if 
the css files are GSS compatible in which case you would hand over the 
merge result to closure stylesheet to parse it again and produce the final 
css output. However if the merged data fails to parse then you know that 
some files are incompatible but not wich ones. So you don't know if its 
because of a GSS syntax error in one of the gss files (in which case you 
would fail the compile) or if its because one of the css files contain 
legacy syntax that needs to be converted using the in-memory converter.
To figure that out you would need to assume that css files are 
incompatible, merge just the css files (because of 1. and because the 
converter does not want gss input)), run them through the css2gss converter 
and finally merge the conversion result with the remaining gss files. 
However when doing so you might have changed the ordering of css rules that 
needs to be avoided as it changes rendering behavior.

So the only way to make it fool proof for GWT is to assume that *.css files 
must always be converted and that *.gss files can be used as-is and that 
you can never mix them for a given CssResource. And that is exactly what 
GWT does.



So in your case you need to provide gss and css files for your widgets. You 
can generate the gss files from the css files by using the css2gss tool 
provided in gwt-user.jar. GWT itself does the same for its widgets.



-- J.

-- 
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.


Provide implementations for List/Set/Map proxy properties

2015-03-04 Thread Gordan Krešić
I have server-side bean:

public class Author {
public Map getAttributes() { /* ... */ }
public void setAttributes(Map attributes) { /* ... */ }
}

and its RF proxy type:

@ProxyFor(value=Author.class, locator=AuthorLocator.class)
public interface AuthorProxy extends EntityProxy {
Map getAttributes();
void setAttributes(Map attributes);
}

Is there a way to provide custom instances of Map that will 
be used when constructing proxy autobean?

According to docs, it seems that AutoBeanFactory.Category may provide 
implementation for additional methods in proxy interface that could do 
converting to/from MyMapClass but I wonder if it is possible to construct 
proper instances imediatelly upon autobean deserialization? I'm aware that 
it will still require casting return values to my class, but that is 
acceptable compromise).

-- 
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.


Re: Development Mode will not be supported in Firefox 27+

2015-03-04 Thread jonl
https://sdbg.github.io

Allows you to debug javascript in Eclipse when running your application in 
Chrome.  Has its limitations and is a work in progress, but it works.

On Tuesday, March 3, 2015 at 1:49:47 AM UTC-7, Liam Stewart wrote:
>
> Debugging javascript is a king size pain in the arse if you live and 
> breath Java, super dev mode is still nowhere near good enough to *really* use 
> when you have a lot going on and you need to step through and evaluate line 
> by line the state of the application at runtime, this becomes particularly 
> important if you are delving deeply into hibernate and hazelcast 
> environment like we do.
>
> I was tasked with evaluating IntelliJ as a viable alternative after we 
> went to GWT.create this year, I used it for a morning and wasn't impressed 
> with what I saw... it is painfully obvious you are debugging javascript as 
> the values you want are hidden down inside elements and the debugger simply 
> won't play ball at times, having to put in a debugger API call if you 
> actually do really want it to stop is ridiculous...
>
> I've attached an image of how I feel google has responded to the issue of 
> dev mode - if they really cared about the developers they would have just 
> released a dev version of chrome or something for us, not dropped us in it 
> with a super dev mode that 'will definitely be good, honest, promise... at 
> some time in the infinite future'.
>
> Grumble.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.


Add plugins to mgwt-phonegape

2015-03-04 Thread Abdessamad GET
Hi Everyone,
   I'm using m-gwt and mgwt-phongegap to create an app that run on an 
android POS (point of sales --> it has more features (Icc 
reader,Printer...) then a mobile phone the question is : how can I use this 
Android POS libs in gwt project ?? I know if i'm just working with phonegap 
i have to add some plugins to call android native code in phonegap 
javascript.

thank you

-- 
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.


Update GWT 2.7

2015-03-04 Thread ELkeke
Hi,

I updated my application GWT with the new version 2.7. I have problems with 
generators, generated class, but before with the version GWT 
2.6.1;everything was Ok, I don't change my code, only update the version of 
GWT 2.6.1 -> 2.7.

This is the error message :
[ERROR] Could not find fr.core.generator.MyClassLoader in types compiled 
from source. Is the source glob too strict?
...
[ERROR] Compiler returned false

I don't understand this message because the MyClassLoader is a class 
generated by a class(=MyClassLoaderGenerator) which extend 
com.google.gwt.core.ext.Generator.
When I survey the target created by maven 3, I have found this class :
target\.generated\fr\core\generator\MyClassLoader.

When I do : mvn clean install : no problem !
If I deploy my application in a Tomcat : no problem !
The problem happens when I do : mvn gwt:run (run the SuperDevMode).

Help me, thank you.

-- 
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.


ListBox change event

2015-03-04 Thread Bryan Buchanan
Could some one please tell me why this doesn't generate any change events:



 





 

public class Invoices extends Composite {

private static InvoicesUiBinder uiBinder = 
GWT.create(InvoicesUiBinder.class);

 interface InvoicesUiBinder extends UiBinder {
}

@UiField
ListBox category;

 public Invoices() {
initWidget(uiBinder.createAndBindUi(this));
 category.setVisibleItemCount(1);
category.addItem("--- Select ---");
category.addItem("H");
category.addItem("T");
category.addItem("S");

}

@UiHandler("category")
void categoryChange(ChangeEvent event) {

Window.alert("changed");
}


}


-- 
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.


Superdevmode throws error if Project dependency exists

2015-03-04 Thread Bhumika Thaker
Hi,

A main project which has multiple gwt project is set in build path 
(common(gwt project), dao, facade).

The module entry point is defined in main project. It compiles successfully 
in dev mode.

I am trying to run project using superdev mode. It throws error i.e. Line 
66: No source code is available for ..

The error is related classes of other projects which are in build path.


I did below configuration in eclipse:


Set main class:

com.google.gwt.dev.codeserver.CodeServer


Arugment:

-src src/ com.org.project1 


I have tried through multiple argument of src as SO answer says but it's 
not work as it's for module not different project:


http://stackoverflow.com/questions/20333242/multiple-source-folders-for-super-dev-mode



Is superdevmode support multiple project? If yes,  what is missing in this?



Thanks & Regards,

Bhumika Thaker

-- 
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.


Re: [ERROR] Only either css files or gss files are supported on one interface

2015-03-04 Thread Ed Bras
Thanks @Jens, I understand what you mean.
However, I still not see a could reason to force the gss file extension. I
think we can assume that the developer knows what he is doing and it's his
responsibility to feed the gss engine with the correct files, giving him
the freedom to use any extension he wants.

I understand that it's a nice separation, and it's how other css generation
tools work.
But Gwt is a bit different and does more then just css generation, so in
this case it has some blocking disadvantages.
Advantages of allowing the css extension: shared code use, merging to gss
step by step.

Let me explain it through my use case:
I have a gwt code base that exists of many widget having their own resource
bundle and css files (empty mostly, following to the adapter pattern).
New projects want to use css3 features, as such need the gss mechanism.
However, these shared resource bundles can't be changed, as it results in
breaking other projects using them. Neither do I want to change them as
mostly they concern empty css files that aren't gss dependent, which they
would look like it if they have the gss extension.

To solve this I see 2 options: duplicating the shared css files and giving
them the gss extension -> a lot of work, messy maintainable code.
Patching the gwt gss engine to allow for css files with the css extension.
I think I go for the last option as it seems an easy one looking at the gss
code.

I would suggest to allow for the css extension. Optional with a console
warning that can be suppressed (like done in other parts of the gwt code).

I understand that the css files might contain some gwt syntax like @def
that might result in unwanted results when processed by gss. But isn't that
the same as letting Spring eat some hibernate syntax that it understands
and results in strange outcome It's the responsibility of the developer
to overcome that So give him that freedom

What do you think?
Just my 50 cents.


​

-- 
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.