Of course the answer to many programming questions is yes it can be
done and that sounds cool, but there is a big but. Given the necessary
compiler support - eg: to stop inlining of methods you may wish to
intercept - the question remains is this the best way to solve this
problem.
On the
Volatile has a long history of disabling compiler optimizations, in
both Java, and C/C++, so it is not quite inappropriate to use it for
this purpose. GWT already uses volatile for this purpose, for example,
volatile fields are not subject to type-tightening or being promoted
to final, and in some
Maybe the simpler answer is to have a read resolve / write object
equivalent.
I personally think coupling these value objects all the way from your
database tier to the browser smells.
The detached object problem seems like a symptom of the smell.
On 23/04/2009, at 12:22 PM, Ray Cromwell w
What about support for true aop alliance like interfaces where the one
can modify parameters, change return values etc. Just adding a list of
interested interceptors adds some bloat to every enhanced and I use
the word loosely costs.
There's no need for this anyway, just like there's no nee
Too much extra nonsense adding annotations everywhere. You could have
written a more efficient decorator fir less keystrokes and the
decorator will always be faster at runtime and save the compiler from
overheating with extra passes and complexity.
It's never a good thing to chest and reuse
If there was a low cost way to disable inlining and conversion to
static methods of certain functions, you might be able handle the
interception dynamically, e.g.
for(method in myClass.prototype) {
if(shouldIntercept(myClass.prototype[method])) {
myClass.prototype[method] = function() {
To implement Interceptors in gwt one does just needs to follow the
same general patterns that exist in real java and aop.
I have already done interceptors / aop for gwt as part of my own di
module in gwt. One does not need interceptors in gwt a lot of extra
behind the scenes classes are nee
IMHO, The interesting case is not AOP of outgoing objects, but AOP of
incoming objects (return values from RPC). This might even help some
of the GWT/GAE/JDO issues, where you could AOP enhance an incoming
model object to track dirty modification of fields. This is not
unlike the JRE serializatio
> Now, MyBean does not implement interface X, but a generator/AOP
> interceptor could make a subclass of MyBean that has interface X
> implement. IIRC, GWT RPC just invokes the default constructor, so
> there's no way to intercept this and substitute a replacement.
Yeah, that is an interesting qu
On Tue, Apr 21, 2009 at 7:11 PM, Arthur Kalmenson wrote:
>
> Hmm, but don't you normally send some kind of Model or domain object
> over the wire and not something that would need to be injected with
> dependencies by Gin?
I think what he's saying is that he might have an RPC method like this:
Gin actually falls back on calling GWT.create() if it can't find a
binding for an injected dependency. This means that, using Bruce's
example, you could have something like this:
public class SomeWidget() {
@Inject
public SomeWidget(PersonBeanWithMethodCallLogger personBean) {
person.get
Interesting question. Gin auto-creates RPC interfaces as well, for
example, if you have:
public interface MyFoo extends Ginjector {
MyServiceAsync getService();
}
then Gin implicitly looks for MyService.class and invokes
GWT.create(MyService.class) when calling getService(). Since Gin is
hand
Sounds a good solution.How would this solve the use case "data returned by
RPC call" ?
2009/4/21 Ray Cromwell
>
> I really think Guice-style dependency injection is the way to go to
> solve this problem, rather than trying to emulate Java
> Proxies/Classloader in the compiler. If you use Guice/G
I really think Guice-style dependency injection is the way to go to
solve this problem, rather than trying to emulate Java
Proxies/Classloader in the compiler. If you use Guice/Gin, then in Gin
you can inject GWT.create-d versions, and in JUnit-mode, you can use
regular Guice injection. The code u
A simple example : databinding
Lets consider I want to bind some Label text to some model Bean value. Gwt
Label widget "text" can be accessed as a javaBean property, so this sound a
typical java.beans.binding use-case
This requires my model bean to support PropertyChangeListeners. As I'm lazy
I'd
On Tue, Apr 21, 2009 at 12:38 PM, nicolas de loof
wrote:
> The only critism I'd have is the requirement to use GWT.create() to get
> code from a generator. This is a requirement when the generated code doesn't
> extend the source type (for example for Async interfaces) but not when the
> genrator
That's a really valueable consideration. AOP based coding is in many time
difficult to understand and debug, even beeing very powerfull.
The only critism I'd have is the requirement to use GWT.create() to get code
from a generator. This is a requirement when the generated code doesn't
extend the so
A sort of philosophical meta-point that may or may not be of interest...
When we started GWT, we were worried about managing the complexity of
compile-time code generation, so we tried to find the simplest, most
easy-to-debug approach we could think of. GWT's model of never changing
existing code[
On 20 avr, 08:43, nicolas de loof wrote:
> > > I wonder if there is any way to also "pre-process" Java sources, for
> > example
> > > this would enable support for Aspect Oriented Programming or maybe some
> > > DataBinding framework.
>
> > Depends what you mean by "pre-process"... Generally, g
I'll definitly take a look at GIN. I'm not used with Guice (as I'm a Spring
user) but concept is familiar. Any chance to see Google Guice contribute to
JSR 299 ?
Data binding will be a killer feature when available compared to
hand-written PropertyChangeListeners and related boilerplate code.
Is th
With regards to AOP, as Ray mentioned, you might want to check out
Google GIN. They haven't yet implemented Interceptors (AFAIK), so you
might want to combine efforts with them to get this to work.
With regards to data binding, bobv is, AFAIK, working on that feature.
If you hold off until it's d
What I'm looking for is both some AOP capability and a way to port javaFx
"bind" keyword to Java / GWT.
gwt-beans-binding is doing databinding using marker interface in model and
"wrappers" for widgets. This makes impossible to use advanced widgets from
3rd tier librairy without some more code to w
Hi,
I think it should be perfectly possible to use the generator for adding
aspects.
You can replace one class with a different implementation, that is what is
done to emulate the JVM classes and that is used all over the place to
implement browser specific code.
But if you are programming again
GWT generators cannot access the source AST of the original class,
only the class metadata (fields/method names, parameters, signatures),
no method body stuff. If you're looking to do AOP/Method Interception,
I suggest you take a look at Google Gin which is a Guice
implementation for Git. It's a d
>
>
> > I wonder if there is any way to also "pre-process" Java sources, for
> example
> > this would enable support for Aspect Oriented Programming or maybe some
> > DataBinding framework.
>
> Depends what you mean by "pre-process"... Generally, generators
> analyze the class they're called for (f
On 19 avr, 16:34, nicolas de loof wrote:
> Hi
> If I understand well the GWTCompiler process, The generator are used to
> create complementary Java files to be added in the project sources and
> compiled to JavaScript.
Among other things: GALGWT uses a generator to produce the offline
manifest
26 matches
Mail list logo
