Re: New project best practice

2017-11-05 Thread Bryan Buchanan 
Wow - thanks for the detailed reply.

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" 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 https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: GWT csrf protection

2017-11-05 Thread Maarten Daalder (ISAAC Software Solutions) 
We are currently using it in production. The code hasn't changed since at 
least 2.6.0 (and probably earlier).
The only problems we currently have are that sometimes the client doesn't 
fetch a new token on start or that the client has to refresh the browser 
after the session expired.

On Tuesday, 31 October 2017 13:36:16 UTC+1, Rencia Cloete wrote:
>
> Gwt Documentation 
> http://www.gwtproject.org/doc/latest/DevGuideSecurityRpcXsrf.html as well 
> as GWT IN action 
> https://manning-content.s3.amazonaws.com/download/d/07888ea-bada-44cc-9c55-ead15ea7fe85/GWT_sample-07.pdf
>  
> recommend extending XsrfProtectedService on client side and 
> XsrfProtectedServiceServlet on server side
>
> But both thse methods are still marked as "EXPERIMENTAL and subject to 
> change. Do not use this in production code. "
>
> What gives? is this a leftover - or are they now safe to use in production?
>
> Thanks for your help in advance!
>

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" 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 https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: The long awaited GMD 2.0 is now available

2017-11-05 Thread Grigory Shoichate 
look amazing !!!

On Sunday, November 5, 2017 at 7:28:47 AM UTC-5, mark kevin ringor wrote:
>
> 
>
>
> Showcase: http://gwtmaterialdesign.github.io/gwt-material-demo/
>
> Release Notes:
> 1. gwt-material - 
> https://github.com/GwtMaterialDesign/gwt-material/releases/tag/gwt-material-2.0
>
> 2. gwt-material-addins - 
> https://github.com/GwtMaterialDesign/gwt-material-addins/releases/tag/gwt-material-addins-2.0
>
> 3. gwt-material-themes - 
> https://github.com/GwtMaterialDesign/gwt-material-themes/releases/tag/gwt-material-themes-2.0
>
> 4. gwt-material-table - 
> https://github.com/GwtMaterialDesign/gwt-material-table/releases/tag/2.0
>
> 5. gwt-material-jquery - 
> https://github.com/GwtMaterialDesign/gwt-material-jquery/releases/tag/2.0
>
> Thanks for all your contributions and support for this Open Source 
> community.
>
> Best Regards.
> GMD Team
>
>

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" 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 https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

The long awaited GMD 2.0 is now available

2017-11-05 Thread mark kevin ringor 





Showcase: http://gwtmaterialdesign.github.io/gwt-material-demo/

Release Notes:
1. gwt-material - 
https://github.com/GwtMaterialDesign/gwt-material/releases/tag/gwt-material-2.0

2. gwt-material-addins - 
https://github.com/GwtMaterialDesign/gwt-material-addins/releases/tag/gwt-material-addins-2.0

3. gwt-material-themes - 
https://github.com/GwtMaterialDesign/gwt-material-themes/releases/tag/gwt-material-themes-2.0

4. gwt-material-table - 
https://github.com/GwtMaterialDesign/gwt-material-table/releases/tag/2.0

5. gwt-material-jquery - 
https://github.com/GwtMaterialDesign/gwt-material-jquery/releases/tag/2.0

Thanks for all your contributions and support for this Open Source 
community.

Best Regards.
GMD Team

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" 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 https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: New project best practice

2017-11-05 Thread Vassilis Virvilis 
Peter thanks for the detailed post.

I agree with most of the points. My suggestions for a new project, although
even I am not following it strictly due to existing codebase.

1) Split Client (GWT) and Server part (GWT-RPC). This wasn't possible for
me due to the interface files with GWT-RPC. It is possible however with
Resty-GWT and jaxrs in the server. I am using CXF but others option do
exist. For complex pojos there are ways to interfere with the serialization
and deserialization in order to make things digestable in both sides

2) Use elemental2 and jsinteropify your js dependencies. I agree with Peter
that there is a cultural between java and js and some things do not map
intuitively. I have jsinteropify

   - jquery
   - datatables
   - d3
   - daterangepicker
   - bootstrap modals

and only datatables is seriously not properly mapped to java mappings.

3) Avoid gwt widgets. God I will miss HeaderPanel -- welcome FlexBox. Gwt
widgets are not so nice compared to native javascript libraries and they
are slowly deprecating...

My two cents



On Sun, Nov 5, 2017 at 4:32 AM, Peter Donald  wrote:

> Hi,
>
> On Fri, Nov 3, 2017 at 1:45 PM, Bryan Buchanan 
> wrote:
>>
>> If I was to start a new GWT project today, what is the recommended way to
>> generate the UI (Elements, UIBinder, ??) and exchange data with a back end
>> (RCP, ??)
>>
>
> There are as many different answers to this as there are people is my
> guess and a lot of the answers are contingent on j2cl/gwt3 not being
> vapourware.
>
> However this is our experience. We have several largish apps that are all
> built around a subset of GWT (Events, UIBinder, Widgets and GWT-RPC) that
> have been in active development since 2011 or so. Up until a few months ago
> we had planned to continue to use Events, UIBinder, Widgets into GWT3/j2cl
> and convert to jsinterop as required. (GWT-RPC was to be replaced but we
> had an abstraction layer that would make that relatively easy). However
> something forced us to look at the javascript ecosystem in earnest and we
> have since switched our strategy and are absolutely loving the change.
>
> Roughly we looked at all the popular javascript framework ecosystems and
> came to the conclusion that we really wanted to use either VueJS or React
> for the view and Mobx for state management. There was a whole suite of
> other libraries that we wanted to use from javascript as well. We were sort
> of limited in what we could select as we needed a stable base that likely
> to survive the next 10ish years and we still wanted to use Java for the
> application logic, network stack, dependency injection etc. Ideally, we
> also wanted to be able to use Closure Compiler to compile both java and
> javascript into a single bundle.
>
> We found that some of the libraries were very difficult to wrap and call
> from java or that the constructs were clumsy and confusing. i.e. We often
> found that to wrap library X required that the user had deep knowledge of
> both the library, how javascript works and how gwt works which was too
> much. Some libraries just did not make sense in a GWT/java world.
>
> So what we have essentially done is whittled it down to a small number of
> essential libraries and we are creating java-ish abstractions on top of
> them. The developers then just treat it like a normal GWT library. The
> advantage is that they do not need to have a deep understanding or
> javascript, jsinterop etc but get all the advantages of using a
> well-thought out abstraction.
>
> About the only thing we have no good solution for is assets (i.e. CSS,
> images, etc) and the plan was to continue to use GWT 2.x abstractions for
> that until j2cl came out or we became desperate for something more. This is
> no where as good as the css-in-js solutions or webpack loaders available in
> native javascript ecosystem but hopefully we can remedy it in the future.
>
> Anyhoo we use the following libraries without reservation:
>
> * Dagger 2 for dependency injection (https://google.github.io/dagger/)
> * Elemental2 for Browser Integration (https://github.com/google/elemental2
> )
>
> Elemental2 does not see frequent releases, is beta, and missing lots and
> is a PITA to build. However it is built by Google and presumably used
> internally quite heavily and based of closure which is even wider usage so
> we expect this to improve over time. It also covers all/most of our use
> cases so we have been happy with it. When we hit something that not yet
> covered it is simple to write your own jsinterop abstraction.
>
> An interesting library that we are watching but have yet to use is VueGWT (
> https://github.com/Axellience/vue-gwt). It looks like it could be very
> nice and developers seem active and
>
> We also have our own library that does state management which is a
> reimplementation of principles of Mobx in java with a few other libraries
> blended into it. It is probably one of the best things about our new
> architecture but it is st