Hi Thomas, I decided to put the library as you suggested in a separate project, and to make it evolve to a state where it can be presented as an alternative to UiBinder. Here's the link, all unit tests pass. If any body wants to contribute, you're welcome
https://code.google.com/p/ui-binder-factory-proxy/ Le vendredi 23 mai 2014 14:59:35 UTC+1, Zied Hamdi OneView a écrit : > > Hi, > > I want to talk about GWT authorizations to brainstorm an architecture that > supports it natively. > > It's somehow surprising a framework that is in advance (adopted the Fog > computing more than 5 years ago) doesn't provide a native support for > security routines. Workarounds are naturally possible, but no real core > solution is available, to specify how it should be done according to best > practices and have developers immediately knowing what they do when they > want to implement security in GWT. > > There are some open sources that already propose solutions for this > subject, they or developers who used them are naturally welcome to discuss > the even ad odd points from their feedback. > > Before I started this discussion I made a tour on the available solutions > and I found all what I discovered either too intrusive (imposes its own > architecture that might not be compatible with existing projects), or too > superficial (means there is no central way of doing things). > > With the evolution of IT, many thinkers brought new ways of solving > problems. All problems can't be solved with one only pattern and overusing > a pattern can lead to bad architectures (hardly maintainable code). > > AOP is an example of these best practice ideas that couldn't be overused. > It decomposes a layer (in a n layer architecture) into different logically > splitted layers. In AOP the interceptor knows about his host but the host > doesn't event know the AOP exists. This is a good approach to separate > concerns. The logger, the security some visual adjustments etc... can > intercept the program without this latter knowing about them. > > Another best practice pattern is the single access point: it is somehow > related to the proxying because when all your program flow passes through a > single object/method/facade, it is easy to intercept events and add logic. > > The event oriented programming is a direct iteration on these two > patterns, it states that a shared event bus can make the entire application > connected and make it possible to plug itself on the program without > impacting it. > > I proposed a solution based on this approach to solve the security feature > lack in GWT: an interception entry point to the creation of widgets to > permit plugging into it and doing other interesting things GWT isn't > obliged to be responsible of. > > My proposal is > here<https://code.google.com/p/google-web-toolkit/issues/detail?can=2&start=0&num=100&q=&colspec=ID%20Type%20Status%20Owner%20Milestone%20Summary%20Stars&groupby=&sort=&id=8727> > > https://code.google.com/p/google-web-toolkit/issues/detail?can=2&start=0&num=100&q=&colspec=ID%20Type%20Status%20Owner%20Milestone%20Summary%20Stars&groupby=&sort=&id=8727 > > A > discussion<https://groups.google.com/forum/#!topic/google-web-toolkit/wk9a3mCRliY>already > happened in the user forum too about the subject. > > Your ideas and comments are welcome :) > > -- You received this message because you are subscribed to the Google Groups "GWT Contributors" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/95ae19ac-c132-4938-87ba-dab37d5c1796%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
