Using Microformats instead of RootPanel.get("id")

[Vladislavs Korehovs]

Hi,

i like GWT design for the most part, but some parts are ugly, like
RootPanel.get("id"). If you have many separate GWT components u want
to inject into the page.
in my Case i'm using many players with same GWT component for all of
them.
RootPanel.get("id") don't provide solution to this, because Id of
elements are not sequential and can change since i use DHTML. i also
cannot use DOM.getElementByClass() like call.

Every page could have different count of Players, and count of players
could be changed by DHTML.

My proposed solution is to use Microformat to inject GWT into the
page, instead of using Locator Antipattern GWT does.
for example:

<div class="gwtWidget" name="com.mycompany.MyWidget">
<div class="gwtProperty" name="url">http://somesite.com/song.mp3</div>
<div class="gwtProperty" name="name">Best Song</div>
</div>

During loading GWT should use microformat API (firefox 3) or Prototype
like API internally to lookup elements by class and to inject GWT root
panel widget into. Spring like DI will also be VERY nice!.

Best regards, Vladislavs Korehovs.

[Thomas Broyer]

On 23 juin, 15:48, Vladislavs Korehovs <vladislavs.koreh...@gmail.com>
wrote:

I don't know which API you're referring to but GwtQuery might be what
you're looking for.
http://www.gwtquery.com

> Spring like DI will also be VERY nice!.

!? What kind of DI would you like? XML-based? microformat-based (i.e.
runtime-based rather than at compile time?)

If you want compile-time DI, you don't need Spring or the like; a bare
Java class (with factory methods calling other factory methods, etc.)
would be enough as long as you don't have constructor-based dependency-
loops (which would involve proxies) or "InitializingBean"s (you should
really use constructor-based injection anyway... just my own opinion).

Start with this:
http://blog.springsource.com/main/2006/11/28/a-java-configuration-option-for-spring/
remove annotations and switch all methods to 'static', using static
private fields and the "lazy init" pattern if you want singletons; and
you're done, faster than using any DI framework... (for simple
things).
You'd actually have something probably closer to Guice than to Spring
(i.e. not a container, just a dependency injector); and because you
don't use any of them your resulting code is really much more
optimized.

As for AOP and GWT, I'm really not sure you should start looking at
it... it might be possible without too much bloat though, thanks to
JavaScript's monkey patching support, but generating the "right"
JavaScript from your Java/GWT code surely won't be that easy I
guess...

My 2 c€nts...

[Vladislavs Korehovs]

Well, thanks for gwtquery, i can use it to implement something similar
but not the same i proposed.
I believe, example i gave is just enough to capture the idea i want
to:

<div class="gwtWidget" name="com.mycompany.MyWidget">
<div class="gwtProperty" name="url">http://somesite.com/song.mp3</
div>
<div class="gwtProperty" name="name">Best Song</div>
</div>

I believe this should be part of GWT platforn, and nowbody should
reinvent a weel trying to write/use GwtQuery, etc.
This is TONS of not needed boilerplate code. and i believe if u can
inject GWT components into the page, by just writing:

<div class="gwtWidget" name="com.mycompany.MyWidget">
<div class="gwtProperty" name="url">http://somesite.com/song.mp3</
div>
<div class="gwtProperty" name="name">Best Song</div>
</div>

LOTS of people say thanks to you.

>!? What kind of DI would you like? XML-based? microformat-based (i.e.
>runtime-based rather than at compile time?)

microformat-based

>I don't know which API you're referring to but GwtQuery might be what
>you're looking for.

1. Native microformat queries in firefox 3
2. Prototype framework, getElementByClass()
3. Could be JQuery, but it is tooo heavy for job to be done.

>If you want compile-time DI, you don't need Spring or the like; a bare
>Java class (with factory methods calling other factory methods, etc.)

Have you ever counted how maany lines of boilerplate code you have in
your applications taking this philosophy?

>remove annotations and switch all methods to 'static', using static
>private fields and the "lazy init" pattern if you want singletons; and
>you're done, faster than using any DI framework... (for simple
>things).

Jeez i dont want singletons, what i want is to create variable count
of widgets from Microformats instead of having RootPanel crap.
Why you redirecting me to Spring documentation? i know perfectly what
spring is about, i said spring-like.
Thease lines of code, describe what i have meant:

<div class="gwtProperty" name="url">http://somesite.com/song.mp3</
div>
<div class="gwtProperty" name="name">Best Song</div>

> you're looking for.http://www.gwtquery.com

>
> > Spring like DI will also be VERY nice!.
>
> !? What kind of DI would you like? XML-based? microformat-based (i.e.
> runtime-based rather than at compile time?)
>
> If you want compile-time DI, you don't need Spring or the like; a bare
> Java class (with factory methods calling other factory methods, etc.)
> would be enough as long as you don't have constructor-based dependency-
> loops (which would involve proxies) or "InitializingBean"s (you should
> really use constructor-based injection anyway... just my own opinion).
>

> Start with this:http://blog.springsource.com/main/2006/11/28/a-java-configuration-opt...

> remove annotations and switch all methods to 'static', using static
> private fields and the "lazy init" pattern if you want singletons; and
> you're done, faster than using any DI framework... (for simple
> things).
> You'd actually have something probably closer to Guice than to Spring
> (i.e. not a container, just a dependency injector); and because you
> don't use any of them your resulting code is really much more
> optimized.
>
> As for AOP and GWT, I'm really not sure you should start looking at
> it... it might be possible without too much bloat though, thanks to
> JavaScript's monkey patching support, but generating the "right"
> JavaScript from your Java/GWT code surely won't be that easy I
> guess...
>

> My 2 c€nts...- Hide quoted text -
>
> - Show quoted text -

[Ray Cromwell]

On Mon, Jun 23, 2008 at 9:21 AM, Vladislavs Korehovs <vladislav...@gmail.com> wrote:

I believe this should be part of GWT platforn, and nowbody should
reinvent a weel trying to write/use GwtQuery, etc.
This is TONS of not needed boilerplate code. and i believe if u can
inject GWT components into the page, by just writing:

It appears that you are new to the contributors group. If you want something like this to eventually make it into the core platform,  the best thing to do is to implement it first, submit it to the incubator, and let others use to so that the proper design can be hammered out.  Your current proposal is too ill-defined in behavior. What triggers the processing of the microformats, can I switch it off, how are classes looked up? GWT, for example, does not have reflection or dynamic loading, so there is no Class.forName("MyWidget"), therefore, there needs to be a registration API where every one of your widgets that are eligible for Microformat injection have to pre-registered prior to scanning the DOM.

>I don't know which API you're referring to but GwtQuery might be what
>you're looking for.

1. Native microformat queries in firefox 3
2. Prototype framework, getElementByClass()
3. Could be JQuery, but it is tooo heavy  for job to be done.

GwtQuery leverages getElementsByClassName, document.evaluate, document.querySelectorAll, and does so in a lighter weight fashion than any other API. $("ul.menu > li:first-child").html("Hello") compiles to just 712 bytes when using XPath (even smaller if using Safari3), and runs faster than all other Javascript DOM libraries.

-Ray

 

p.s. GWT already has an elegant dependency injection mechanism BTW, it's called Deferred Binding. If you want more dynamic DI, something that is more Guice-like would be a better choice. Spring is the king of boilerplate.

[Vladislavs Korehovs]

Hi,

Thanks alot for your help, and providing smart reply.
I didn't included implementation on purpose.

>What triggers the processing of the
>microformats

Loading of GWT runtime Covers 90% of requirements.

>can I switch it off,

Yes, in module configuration, no overhead if u dont use it.

>how are classes looked up? GWT, for
>example, does not have reflection or dynamic loading, so there is no
>Class.forName("MyWidget"),

This is not covered by GWT i beleave, can Deferred Binding cover
thease requirement? as Google possitions this as alternative to
reflection:)

>there needs to be a registration API
>where every one of your widgets that are eligible for Microformat injection
>have to pre-registered prior to scanning the DOM.

For god sake i try to avoid any Registration mechanisms, this violates
my KISS principle.
Is it possible to create classes dynamically from inside of GWT
runtime? i.e. Private API, etc.

>GwtQuery leverages getElementsByClassName, document.evaluate,
>document.querySelectorAll, and does so in a lighter weight fashion than any
>other API. $("ul.menu > li:first-child").html("Hello") compiles to just 712
>bytes when using XPath (even smaller if using Safari3), and runs faster than
>all other Javascript DOM libraries.

This is great if not taking into account GwtQuery is 0.2 Alpha, and i
didnt understood it's code by looking at it 15 minutes.
All i need is DOM.getElementByClassName() call, i have ported it from
Prototype. Later it could be optimixed to use XPath native
microformart API, or whatever.

>the best thing to
>do is to implement it first, submit it to the incubator

How to do this?, i have implemented it already yesterday for searching
objects and injecting them. It still don't confirm to best design i
was thinking of.
Can i change GWT runtime and submit it to incubator as well?

On Jun 23, 6:07 pm, "Ray Cromwell" <cromwell...@gmail.com> wrote:
> On Mon, Jun 23, 2008 at 9:21 AM, Vladislavs Korehovs <
>

[Thomas Broyer]

On 23 juin, 18:21, Vladislavs Korehovs wrote:
> Well, thanks for gwtquery, i can use it to implement something similar
> but not the same i proposed.
> I believe, example i gave is just enough to capture the idea i want
> to:
>
> <div class="gwtWidget" name="com.mycompany.MyWidget">
> <div class="gwtProperty" name="url">http://somesite.com/song.mp3</
> div>
> <div class="gwtProperty" name="name">Best Song</div>
> </div>
>
> I believe this should be part of GWT platforn, and nowbody should
> reinvent a weel trying to write/use GwtQuery, etc.
> This is TONS of not needed boilerplate code. and i believe if u can
> inject GWT components into the page, by just writing:
>
> <div class="gwtWidget" name="com.mycompany.MyWidget">
> <div class="gwtProperty" name="url">http://somesite.com/song.mp3</
> div>
> <div class="gwtProperty" name="name">Best Song</div>
> </div>
>
> LOTS of people say thanks to you.

Not me ;-)

I believe it should NOT be part of GWT "core", but if you can make it
as a 3rd-party lib, LOTS of people will thank you ;-)

> >!? What kind of DI would you like? XML-based? microformat-based (i.e.
> >runtime-based rather than at compile time?)
>
> microformat-based
>
> >I don't know which API you're referring to but GwtQuery might be what
> >you're looking for.
>
> 1. Native microformat queries in firefox 3

I thought they were only aimed at extensions (aren't they requiring a
call to the Components object?)

> 2. Prototype framework, getElementByClass()
> 3. Could be JQuery, but it is tooo heavy for job to be done.

Yep, that's why I directed you to GwtQuery.
For some "lights" on it, go read Ray's blog, and have a look at the
video or slides of his Google I/O presentation (linked from his blog);
really impressive!
http://timepedia.blogspot.com

> >remove annotations and switch all methods to 'static', using static
> >private fields and the "lazy init" pattern if you want singletons; and
> >you're done, faster than using any DI framework... (for simple
> >things).
>
> Jeez i dont want singletons, what i want is to create variable count
> of widgets from Microformats instead of having RootPanel crap.
> Why you redirecting me to Spring documentation? i know perfectly what
> spring is about, i said spring-like.
> Thease lines of code, describe what i have meant:
> <div class="gwtProperty" name="url">http://somesite.com/song.mp3</
> div>
> <div class="gwtProperty" name="name">Best Song</div>

Ah, OK, seems like we don't have the same definition for "dependency"
injection... This snippet I would call "configuration", not DI.

Given that, I'd say that coding this as a library wouldn't be that
hard. You'd probably have to make a base class for those widgets that
can be injected that way, so that you can use a generator for getting/
setting bean-properties by name (similar to ConstantsWithLookup); and
solve the "lack of reflection" problem with some kind of registry
(again, could be generated using deferred binding)

[Vladislavs Korehovs]

Hi,

Im not sure if i can use deferred binding for this, as Deferred
binding provides compile time injection. not runtime injection.
Is there any similar support for doing this in runtime?

Can i skip compiler mangling for specific properties and Classes?
So i can use annotations to say this property is injectable and dont
mangle it?
Something similar to gwt-exporter. it is real shame GWT still dont
have native possibility for this.

And i missed point why microformats should not be part of GWT core?
And why to use RootPanel.get("") for everything?

> really impressive!http://timepedia.blogspot.com

[Ray Cromwell]

On Tue, Jun 24, 2008 at 10:42 AM, Vladislavs Korehovs <vladislav...@gmail.com> wrote:

Hi,

Im not sure if i can use deferred binding for this, as Deferred
binding provides compile time injection. not runtime injection.
Is there any similar support for doing this in runtime?

No, not be default. Doing so would hamper compiler optimization and bloat the generated code tremendously. 

 

Can i skip compiler mangling for specific properties and Classes?
So i can use annotations to say this property is injectable and dont
mangle it?
Something similar to gwt-exporter. it is real shame GWT still dont
have native possibility for this.

 I think there is a difference between exportability and runtime introspection. Exportability buys you non-mangled publically addressable identifiers, but it doesn't neccessarily get you the same information as Java Reflection. There are a few GWT introspection projects out there. See gwittir for example, at http://code.google.com/p/gwittir/wiki/Introspection

 

Think about the repercussions however of every widget in your source path being available at runtime for dynamic injection: 

1) If you expect, you lose alot of the ability to obfuscate identifiers

2) Every possible-to-inject widget MUST be included in the compiled output and cannot be pruned. Try this with something like GWT-Ext and you'll have about 500mb of Javascript even before your application code is considered

3) You are losing the benefits of compilation by making every choice happen at runtime. If you just want something like Dojo, I would suggest using Dojo itself.

 

And i missed point why microformats should not be part of GWT core?
And why to use RootPanel.get("") for everything?

I hope I have explained the downsides of microformat IoC with respect to GWT. It is possible to mitigate some of these issues by having the GWT compiler read the HTML microformats at *compile time* and instantiate widgets, but then we're back to doing things at compile time.

The GWT philosophy is to do as much as possible work at compile time to maximize user benefit, that means small and fast code. Runtime dependency injection essentially breaks the GWT value proposition.

-Ray

[Peter Blazejewicz]

hi,
On Jun 24, 7:42 pm, Vladislavs Korehovs
<vladislavs.koreh...@gmail.com> wrote:
> Hi,

> And i missed point why microformats should not be part of GWT core?

please start new issue:
http://code.google.com/p/google-web-toolkit/issues/list
and then we will likely see how many people think the same way as you.
Write ticket summary and give it clear advertisement so people would
buy it and star ticket,

> And why to use RootPanel.get("") for everything?

that's pretty much simple: to let properly manage events in
application and avoid memory leaks GWT.
# you don't have to post a topic on contrib section to ask such
questions, just read available docs #
regards,
Peter

[Vladislavs Korehovs]

Hi,

Jeez Ray, looks like your mind was taken over completely by bits
compilers and low level stuff. I feel sorry for you, hope you can
recover from this desease, Since some of your comments shown good
perspective and ability to see Big picture. I happy i didn't choise
Google as my employer otherwise something similar could happen to me:(

We are talking about replacing RootPanel with dynamiccally loaded
widget class. We are not talking about replacing Everything with
microformats based injection. How many RootPanel are there in a
typicall application? 5-10 instances? and lets say they have 5-10
properties being injected.
It could make initialization of GWT 5ms slower, i know it is a lot for
quantum physics but for human eye it is nothing:)

Good design is always a compromise.

On Jun 24, 8:21 pm, "Ray Cromwell" <cromwell...@gmail.com> wrote:
> On Tue, Jun 24, 2008 at 10:42 AM, Vladislavs Korehovs <
>

> vladislavs.koreh...@gmail.com> wrote:
>
> > Hi,
>
> > Im not sure if i can use deferred binding for this, as Deferred
> > binding provides compile time injection. not runtime injection.
> > Is there any similar support for doing this in runtime?
>
> No, not be default. Doing so would hamper compiler optimization and bloat
> the generated code tremendously.
>
>
>
> > Can i skip compiler mangling for specific properties and Classes?
> > So i can use annotations to say this property is injectable and dont
> > mangle it?
> > Something similar to gwt-exporter. it is real shame GWT still dont
> > have native possibility for this.
>
>  I think there is a difference between exportability and runtime
> introspection. Exportability buys you non-mangled publically addressable
> identifiers, but it doesn't neccessarily get you the same information
> as Java Reflection. There are a few GWT introspection projects out there.

> See gwittir for example, athttp://code.google.com/p/gwittir/wiki/Introspection

> > > (again, could be generated using deferred binding)- Hide quoted text -

[Ray Cromwell]

On Wed, Jun 25, 2008 at 2:37 AM, Vladislavs Korehovs <vladislav...@gmail.com> wrote:

Hi,

Jeez Ray, looks like your mind was taken over completely by bits
compilers and low level stuff. I feel sorry for you, hope you can
recover from this desease, Since some of your comments shown good
perspective and ability to see Big picture. I happy i didn't choise
Google as my employer otherwise something similar could happen to me:(

I don't work for Google, I just happen to be a heavy GWT user.

 

We are talking about replacing RootPanel with dynamiccally loaded
widget class. We are not talking about replacing Everything with
microformats based injection. How many RootPanel are there in a
typicall application? 5-10 instances? and lets say they have 5-10
properties being injected.

It's not how many RootPanel's you are replacing, it's the fact that to support runtime injection, the GWT compiler has no idea which widget classes will be used and which won't, so it would have to include all of them. That is, suppose you write:

<div class="gwtWidget" name="com.google.gwt.user.client.ui.TabPanel">

Since by the time this has been encountered (at runtime), your application has already been compiled, the TabPanel must have been compiled in. But since the name attribute could conceivably be ANY subclass of Widget, the compiler would therefore have to include every single subclass of Widget in the compiled output in order to allow runtime selection. And not only would it be unable to prune unused widgets, it would be unable to obfuscate things like class names, and stuff like type-tightening optimizations would be hampered in some circumstances. 

A registration based API works by only compiling in those Widgets which are "registered" and hence, eligible for injection. If you go with an introspection-reflection based approach, you end up with the sum total of the widget hierarchy added to the output. A lazy-load implementation (load compiled Widgets on-demand) would keep the output smaller, but massively increase startup time.

GWT is a fundamentally different system of authoring AJAX than Javascript models, the compilation step is very important. The whole library is designed around the compiler. Doing everything at runtime defeats much of the advantages of using GWT.

It could make initialization of GWT 5ms slower, i know it is a lot for
quantum physics but for human eye it is nothing:)

The difference between loading up 50kb of JS, and loading up 250kb of JS and walking the DOM to find microformats is not 5ms, especially not on a browser like IE6. Even at DSL speeds, you're talking 500-1000ms, not to mention more memory consumption, and an extra 25-50ms to evaluate getElementsByClassName() on older browsers like FF2/Saf3/IE6.

I encourage you to compare the startup time of Dojo's Mail example, and compare it to a functionally identical version of the GWT Mail sample, in terms of startup performance over the network. Dojo takes the microformat approach at runtime, GWT uses the compile time approach. On my system, GWT 's Mail App starts up 500% faster. 5 seconds vs less than 1 second.

 

Good design is always a compromise.

Compilation is not bad design. Nothing precludes using microformats to instantiate widgets in GWT, you just have to let the GWT compiler parse the HTML at compile time.  It's deferring the decisions until runtime that is the issue. Yes, there are applications where you might wish to defer widget layout decisions until runtime, but the majority of applications do not require this.

[Vladislavs Korehovs]

Hi,

I dont see your point at all.
RootPanel is something optimization cannot drop, because it is core of
your applications.
As i say there should be at most 5-10 root panels in most
applications. And thease are VERY coarse grained components.
If compiler will build dependency graph to determine which peaces of
Code are unused, it wont be RootPanels Since RootPanels are Entry
points of your applications. Not everything should be driven by
compiler, something as coarse as RootPanels could be driven by
configuration or convention.

What you are trying to persuade is common pitfall of bad designs, it
is generalizing some particular thing(conpilation driven) what is
benefitial for something across whole things, and at the end you endup
with too many quirks for humans, because Compiler is different from
Human

Microformats inject only simple types, like Strings and Integers so
there is no Way how injection can make 200kb bigger code.
All your figures are completely based on imagination and not taking
into accout facts and typical ussage scenarios.

On Jun 25, 11:14 am, "Ray Cromwell" <cromwell...@gmail.com> wrote:
> On Wed, Jun 25, 2008 at 2:37 AM, Vladislavs Korehovs <
>

> > > - Show quoted text -- Hide quoted text -

[Vladislavs Korehovs]

Off Topic:

Java Programmers are praying to Type Safety and Static typing,
Python programmers are praying to Duck Typing and Dynamic typing.
Google Programmers are praying to Compilers and Compilation driven
designs:)


On Jun 25, 12:37 pm, Vladislavs Korehovs

> ...
>
> read more »- Hide quoted text -

[Thomas Broyer]

On 25 juin, 13:37, Vladislavs Korehovs <vladislavs.koreh...@gmail.com>
wrote:
> Hi,
>

> I dont see your point at all.
> RootPanel is something optimization cannot drop, because it is core of
> your applications.
> As i say there should be at most 5-10 root panels in most
> applications. And thease are VERY coarse grained components.
> If compiler will build dependency graph to determine which peaces of
> Code are unused, it wont be RootPanels Since RootPanels are Entry
> points of your applications.

RootPanels are *one* way to "inject" widgets into the page at
identified locations. You can also use the newly introduced .wrap()
methods of some widgets: http://code.google.com/p/google-web-toolkit/source/detail?r=3085

And you're not forced to use widgets with GWT (you can use bare DOM
access for instance; and/or GwtQuery ;) ), nor are you obliged to use
widgets as they're done in com.google.gwt.user.*

EntryPoints are something different as far as GWT is concerned, and
there can only be one per module.

> Not everything should be driven by
> compiler, something as coarse as RootPanels could be driven by
> configuration or convention.

So you're proposing that "injectable" widgets derive from some base
class? If so, say it clearly.

Or are you using the term "widget" to actually mean "module
EntryPoint"?
so <div class="gwtWidget" name="com.mycompany.MyApplication"> would
then be caught by a GWT app that'll in turn load the
com.mycompany.MyApplication module.
Are your injected "widgets" intended to communicate with each others?
or are they meant to be "standalone" "applications"?

> What you are trying to persuade is common pitfall of bad designs, it
> is generalizing some particular thing(conpilation driven) what is
> benefitial for something across whole things, and at the end you endup
> with too many quirks for humans, because Compiler is different from
> Human
>
> Microformats inject only simple types, like Strings and Integers so
> there is no Way how injection can make 200kb bigger code.
> All your figures are completely based on imagination and not taking
> into accout facts and typical ussage scenarios.

My main problem is to identify those "typical usage scenarios". I
believe most GWT applications have only one "instance" injected into a
page, so using a predefined id and RootPanel.get(id) isn't a problem.

In the issue report, you say one use case is to communicate from
server to client without involving RPC. GWT already has such a thing,
without involving microformats: the Dictionary class.

If what you'd like is to communicate some element ids to the app so
that RootPanel is parameterized at runtime by the calling page; you
could use such a Dictionary. Only that Dictionary would have to have a
predefined name (eventually being the module's name).

I believe what you'd like to achieve is doable as a 3rd-party lib
(i.e. don't require any change to the compiler or any GWT client
class). So go ahead, code it, and if it works eventually propose it
for inclusion into the incubator (with a chance that it'll be merged
into "core" at some time).

What I wonder is how to do dynamic injection (while "placeholders" are
added/removed), and moreover without memory leak.

(off topic: I have a gripe about so-called microformats, which
actually doesn't have any more meaning than "Web 2.0", are sometimes
abusing HTML, etc. Not that the idea is borked, but it has evolved in
a bad bad way... e.g. using HTML to convey machine-oriented data while
originally it was about annotating user-oriented data with machine-
readable metadata... see http://www.bbc.co.uk/blogs/radiolabs/2008/06/removing_microformats_from_bbc.shtml
)

[Ray Cromwell]

On Wed, Jun 25, 2008 at 4:37 AM, Vladislavs Korehovs <vladislav...@gmail.com> wrote:

Hi,

I dont see your point at all.
RootPanel is something optimization cannot drop, because it is core of
your applications.

  Try harder. :) If I write an application that does RootPanel.get().add(new Label()), the compiler includes the code for Label() in the output, but none of the other subclasses of Widget in user.jar are included in the output.

  If you don't believe what I'm saying, why don't try implementing it? I tell you what, write the following method in GWT:

public Widget createWidgetToInject(String className) { ... }

 for your runtime microformat injection. That is, given a String that has been fetched from your <div class="gwtWidget" name="widgetClass">, write a method that will take the value of element.getAttribute("name") and construct the appropriate Widget. After you have figured out how to implement this method, that will work at runtime and allow you to inject any widget that is in the claspath, explain to me how the compiler will deal with it.

 

Microformats inject only simple types, like Strings and Integers so
there is no Way how injection can make 200kb bigger code.
All your figures are completely based on imagination and not taking
into accout facts and typical ussage scenarios.

Clearly, you don't understand what's neccessary to implement your proposal, that's why I encouraged you to try and implement it first, because it is half-baked at the moment. Once you spend a little time thinking through the implementation of how it would work, you'll realize the repercussions it has on code size.

 

The "bad design" discussion is off topic for this list. GWT is a framework that includes a compilation step to build apps. If you want to build an app only by manipulating HTML, I would encourage other frameworks like Dojo.

-Ray

[Vladislavs Korehovs]

>So you're proposing that "injectable" widgets derive from some base
>class? If so, say it clearly.

>Or are you using the term "widget" to actually mean "module
>EntryPoint"?

class MyWidget extends Widget implements EntryPoint {
String name;
String url;

void onModuleLoad() {

}

void onModuleUnload() {

}
}

>What I wonder is how to do dynamic injection (while "placeholders" are
>added/removed), and moreover without memory leak.

since Everything comes thru DOM class, you can see what part of page
were overwritten by DHTML, and call onModuleUnload() which will notify
component it is unloaded.
What im doing now in order to support DHTML with GWT is Dependency
Graph of Widgets. So if Root Widget (EntryPoint) is unloaded it
unloads all dependent nodes.
There is no way of having DHTML with GWT without leaks if not doing
something like dependency graph yourself. This is another thing what
should be included in GWT in my oppinion, and lifecycle of Components
should be clearly defined.

> readable metadata... seehttp://www.bbc.co.uk/blogs/radiolabs/2008/06/removing_microformats_fr...
> )

[Vladislavs Korehovs]

> for your runtime microformat injection. That is, given a String that has
>been fetched from your <div class="gwtWidget" name="widgetClass">, write a
>method that will take the value of element.getAttribute("name") and
>construct the appropriate Widget. After you have figured out how to
>implement this method, that will work at runtime and allow you to inject any
>widget that is in the claspath, explain to me how the compiler will deal
>with it.

In compilation, compiler checks which Widgets implement EntryPoint or
similar LABEL interface which supports loading/unloading
notifications.
It builds registry(class names) which are candidates for injection. It
also builds list of properties which could be injected. It stores a
map pointing to obfuscated names of those.
#
At runtime while page is loaded it scans page and searches
microformats. For each gwtWidget it do a lookup a registry and creates
instances of Classes after this, injects properties and then calls
Lifecycle Callbacks (onModuleLoad or similar).

If page is updated Dynamically, GWT should have a dependency graph or
similar structure to determine which components need to be unloaded.
But even if unload will not be supported at the beginning this is not
a problem. Making microformat injection for static Web Pages could be
VERY usefull and required for MOST of users.

[Bruce Johnson]

I reiterate everything Ray has said, but to make sure we understand your actual use case (something we care a lot about around here) before we start giving you a hard time...

Why do you want to do this in the way you describe? And, more precisely, why would *prefer* (if it's the case) to do this work at runtime rather than compile-time? Also, how is it different and better than the current design doc for Declarative UI?

We're happy to discuss in detail practical ideas that are properly motivated. It's too big a list of people do discuss things, just because it seems subjectively "more elegent" to you. Explain how it benefits the end user or how it makes developers more productive or code more correct, and you'll spark useful discussion.

[Ray Cromwell]

On Wed, Jun 25, 2008 at 8:22 AM, Vladislavs Korehovs <vladislav...@gmail.com> wrote:

In compilation, compiler checks which Widgets implement EntryPoint or
similar LABEL interface which supports loading/unloading
notifications.
It builds registry(class names) which are candidates for injection. It
also builds list of properties which could be injected. It stores a

You're proposing that the compiler produce separate JS files for each widget. The compiler does not have this capability yet, there is no ability dynamically load/unload anything. Rather, you'd be forced to create a separate GWT module and entrypoint for each widget, and compile them separately, otherwise the selection script would load them all at once. This is significantly more headache and hassle than using compile time microformat parsing.

 

map pointing to obfuscated names of those.

 

#
At runtime while page is loaded it scans page and searches
microformats. For each gwtWidget it do a lookup a registry and creates
instances of Classes after this, injects properties and then calls
Lifecycle Callbacks (onModuleLoad or similar).

This requires every widget to have its api exported so that the runtime can inject properties (you are aware that no two compiles will produce identical obfuscations). Exporting the API bloats size and prevents method pruning.

 

If page is updated Dynamically, GWT should have a dependency graph or
similar structure to determine which components need to be unloaded.
But even if unload will not be supported at the beginning this is not
a problem. Making microformat injection for static Web Pages could be
VERY usefull and required for MOST of users.

This would turn every widget class into a separate HTTP request to load it, significantly slowing startup speed.  No production JS library, not even Dojo or jQuery or ExtJS force users to load each widget as a separate JS file, rather, than concatenate all of the widget implementations together (leading to bloat)

I don't think you're going to convince very many GWT users to use such a system, except for those building Portal-like apps.  There is a proposal to allow deferred loading/module splitting, without the need to export non-obfuscated methods, it's called GWT.createAsync(), look it up  in the archives. However, it is still a compile time mechanism.

I can only encourage you to first go prototype the system you are proposing, and bring back some measurements of the resulting file sizes and load times. This is how every other GWT widget proposal eventually makes it in, by going through the incubator process. 

-Ray

 

[Vladislavs Korehovs]

Hello Ray,

Why you base all your point on assumption we will have separate JS
files?
Then you conclude my point is wrong because your point is wrong.
Try to re-read what i was saying:

There should be no compilator decision of Including or not Injected
widgets into the page.
And this of cause imply those will not be compiled into separate JS
files, there is no need for that.

If you stuck with EntryPoint class because you know too much of
existing design, then it could be InjectionPoint class or anything
else, which have nothing to do with current design of compilation.

You don't think in positive direction, so how can i explain you
something you reject to see?

On Jun 25, 11:57 pm, "Ray Cromwell" <cromwell...@gmail.com> wrote:
> On Wed, Jun 25, 2008 at 8:22 AM, Vladislavs Korehovs <
>

[Vladislavs Korehovs]

Hello Bruce,

Runtime is better:
0) It allows you to plug GWT easily into existing designs and pages,
instead of forcing redeveloping application from scratch!
1) It allows yo use it with any rendering technology: JSP, FreeMarker,
Velocity, JSF, PHP, etc
2) it allows you to pass any dynamic data from server side to your
widget without writing any code.
3) Runs on any sort of HTML, HTML 4/5 XHTML1.0 XHTML1.1, etc
4) Modularity: you can reuse your components easily without re-
compiling them. Sell or publish on the web without openning source
code.

To see more points, refer to Spring framework to understand design
benefits.

I had a quick look on Declarative UI design, and looks like it is
something JSF like, tons of XML etc.

On Jun 25, 9:16 pm, "Bruce Johnson" <br...@google.com> wrote:
> I reiterate everything Ray has said, but to make sure we understand your
> actual use case (something we care a lot about around here) before we start
> giving you a hard time...
> Why do you want to do this in the way you describe? And, more precisely, why
> would *prefer* (if it's the case) to do this work at runtime rather than
> compile-time? Also, how is it different and better than the current design

> doc<http://code.google.com/p/google-web-toolkit-incubator/wiki/DeclarativeUi>for

> > VERY usefull and required for MOST of users.- Hide quoted text -

[Cameron Braid]

On Thu, Jun 26, 2008 at 8:03 PM, Vladislavs Korehovs <vladislav...@gmail.com> wrote:

Hello Bruce,

Runtime is better:

Its not a question of runtime is beter... GWT uses a compiler to produce the javascript, there is no escaping that, that is how it was designed and built.

So, if you want a set of widgets to be available at runtime you need to force the compiler to include them all.  You can do this by writing a method like this :

public Widget createWidget(String className, Map<String, String> parameters) {
  if ("package.Button".equals(className)) {
     package.Button widget = new package.Button();
     // set parameters onto widget
     return widget;
  }
  else if ("package.TabPanel".equals(className)) {
     package.TabPanel widget = new package.TabPanel();
     // set parameters onto widget
     return widget;
  }
  etc.. for all of the widgets that you want to be available at runtime.

}

Then, your microformat parser system will call this method to instantiate the widgets it wishes to place into the DOM.
 

0) It allows you to plug GWT easily into existing designs and pages,
instead of forcing redeveloping application from scratch!

I plug GWT into existing designs and pages at the moment, without this.  I use GwtQuery to find the Elements in the page's DOM, then add widgets to them as I see fit.
 

1) It allows yo use it with any rendering technology: JSP, FreeMarker,
Velocity, JSF, PHP, etc

I use freemarker to generate my pages, and insert GWT widgets into them.
 

2) it allows you to pass any dynamic data from server side to your
widget without writing any code.

Huh ? 

I use GWT RPC, and have very neat server Java code <-> client Java code RPC . can't beat this.
 

3) Runs on any sort of HTML, HTML 4/5 XHTML1.0 XHTML1.1, etc

I use a mixture of HTML 4 transitional (for older pages) and strict (for new pages)
 

4) Modularity: you can reuse your components easily without re-
compiling them. Sell or publish on the web without openning source
code.

I reuse lots of components by packaging them into JAR files. This is fantastic.  THe fact that they get re-compiled for each app is a bonus, because I get really samll, optimized code for each project / app.
 

To see more points, refer to Spring framework to understand design
benefits.

I use the spring framework on the server - it really shines there.. though it has nothing to do with GWT, and I don't see it offering me any beenefit to my GWT modules.
 

I had a quick look on Declarative UI design, and looks like it is
something JSF like, tons of XML etc.

Its an optional component that you can use, if you wish to.
 

Regards

Cameron

[Folke]

Do you want something like this:

package com.example;
public interface Injectable {
Widget inject();
}

package com.example;
public MyPanel extends Panel implements Injectable {
private String xyz;

public String getXyz() { return xyz; }
public void setXyz(String value) { this.xyz = value; }

public Widget inject() {
return new Label(xyz);
}
}

HTML input (at compile time):
...
<div class="gwtInjectable" name="com.example.MyPanel">
<div class="gwtProperty" name="xyz">Hello, World!</div>
</div>
...

HTML output (at runtime):
...
<div class="gwt-Label">Hello, World!</div>
...

This would require the GWT compiler to render a list of Injectables
and their properties and map them to their names. Then they are
resolvable at runtime by their full name. When the GWT module is
loaded the HTML document is scanned for class "gwtInjectable". For
each instance the contained properties are set, then the method
inject() is called that produces a widget that is then injected at
that point.

This is doable, I guess. He doesn't want to mark each core Widget and
Panel with Injectable.

On 26 Jun., 12:14, "Cameron Braid" <came...@braid.com.au> wrote:
> On Thu, Jun 26, 2008 at 8:03 PM, Vladislavs Korehovs <
>

[Folke]

On 26 Jun., 16:17, Folke <mess...@gmail.com> wrote:
> package com.example;
> public interface Injectable {

Injectable should, of course, be somewhere inside
com.google.gwt.user.client.

[Vladislavs Korehovs]

Your comment have not sense.
You don't see things, and you are not designer, you are develper.
So don't bother.!

On Jun 26, 11:14 am, "Cameron Braid" <came...@braid.com.au> wrote:
> On Thu, Jun 26, 2008 at 8:03 PM, Vladislavs Korehovs <
>

[Toby Reyelts]

Vladislavs,

We appreciate your desire to contribute to and improve GWT, but it isn't acceptable for you to speak to others this way. If you haven't already read through Making GWT Better, it's essentially a pre-requisite to participating in this group. You should pay particular attention to Be Friendly.

Thanks,
-Toby

[Peter Blazejewicz]

hi Vlad,

no offence - but do you own a blog? there are couple of free services
you could pick from to start one if you don't.
Then express yourself and stop object to other people posts on "just
because" rule. That's not probably what communities are for unless I'm
missing common sense meanings. People - actually - had lost their time
trying to discuss topic (I hope they will stop). Let see how search
engines and community will rank your ideas expressed in well written,
formal proposal derived from many other succesful ones, take example
one:
http://domscripting.com/blog/display/41
I think people will enjoy reading good posts expressed by number of
comments,
regards,
Peter

On Jun 26, 4:25 pm, Vladislavs Korehovs

[Peter Blazejewicz]

ops,
I actaully missed Toby's post, sorry for spamming group and bumping
topic up,
Peter

[Vladislavs Korehovs]

Hi Folke,

Finally, somebody could understand what i mean, thanks good there are
not just Compiler oriented developers in this group.
Because i've already started loosing hope.

Best Regards, Vladislavs

> > Cameron- Hide quoted text -

[Bruce Johnson]

We are performance-oriented developers in this group.

[Vladislavs Korehovs]

Premature optimization oriented, to be more precise:)

> > > - Show quoted text -- Hide quoted text -

[Ray Cromwell]

  Vladislavs, it might help if you watch this video: http://www.youtube.com/watch?v=ZSFDm3UYkeE, "How Open Source Projects Survive Poisonous People". Whether it is a language barrier or not, you are coming off as an intensely arrogant and uninformed person. It seems that you did not take the time to get a sense of the purpose of this community, or the philosophy behind GWT, and are even acting in an insulting manner to people here. 

  You agreed with Cameron's proposal, but did not understand that it worked by using the GWT compiler to read HTML files at compile time and compile only the widgets used into the output, which is exactly what I told you needed to be done a few messages ago. You make assertions about premature optimization (do you really believe that no one here is familar with that old Knuth chestnut?), but don't seem to understand that we have long been benchmarking AJAX app performance here, and the optimizations we do are dramatic, and not premature. A 500% reduction in startup latency is not the result of premature optimization.

 Third, your proposal is not fully worked out, and you have not contributed an implementation, yet you expect to insult people here and then have them do the implementation for you, or accept your patches?

  This group is about improving the GWT platform. GWT is a compile time platform, fundamentally, there is no doubt. This is not going to change anytime soon. Your proposal may have merit, but it is probably not something for GWT core. There are numerous JSF/GWT integration projects, as well as jMaki, that use a more Web 1.0 + GWT runtime approach, so you might want to look at those.

 Arrogance is never a way to win support and work with a community, even if you think it is well deserved.

-Ray

[Vladislavs Korehovs]

I agreed with Folke proposal not Cameron.
Is it possible to minimise noise in this discussion?
Parsing HTML output before compilation is ridiculos idea to say the
least.
Thanks Roy for contribution to discussion, but it was not
constructive, and backed by not constructive people either,
you created noise without understanding proposal, so why do you just
skip reading and replying to something you dont understand?
Or ask questions if you don't understand since everybody have
different backgroud.
But please don't say something is not possible without understanding
proposal fully.

And stop blaming that i didnt' contributed code. and dont have to
contribute anything, this is my free will.
I feel that contributing this idea is enough, if you say i should
implement this as a module, i will, but without sharing it.
The hole point was to make GWT simplier, since i fedup writing
boilerplate code, but if you like boilerplate, then i can do nothign
about this.
I also wanted people to follow the idea and develop more things in
that direction that was a reason i contributed the idea.
If this is no part of GWT, nobody will develop this idea, and this
makes this not reasonable for me.

[Vladislavs Korehovs]

PS.

And i don't watch youtube...

On Jun 27, 7:30 pm, "Ray Cromwell" <cromwell...@gmail.com> wrote:

[Ray Cromwell]

On Mon, Jun 30, 2008 at 1:08 AM, Vladislavs Korehovs <vladislav...@gmail.com> wrote:

I agreed with Folke proposal not Cameron.

Is it possible to minimise noise in this discussion?
Parsing HTML output before compilation is ridiculos idea to say the
least.

Folke's proposal was for compile time HTML parsing to build a map of injectables. Go back and re-read Folke's message. I've said all I'm going to say in this discussion, except to advise you to go back and work through your ideas more thoroughly. Most of the people on this list are very busy, and are not likely to commit labor to anything that isn't fully specified. The burden of proof is on the one making the proposal, to show how it can be implemented, and implemented efficiently. Working code is most welcome.

[Vladislavs Korehovs]

> Folke's proposal was for compile time HTML parsing to build a map of
> injectables. Go back and re-read Folke's message. I've said all I'm going to

Some people see only what they want to see.
I will skip commenting imperative tone of your message.

I never contribudet anything to open Source. Could you help me with ?
Where is incubator what to do, etc.?

I can provide implementation for HTMLPanel, compilers are not my area.

On Jun 30, 9:49 am, "Ray Cromwell" <cromwell...@gmail.com> wrote:
> On Mon, Jun 30, 2008 at 1:08 AM, Vladislavs Korehovs <
>

[Andrés Testi]

Wow! GWTC is now troll friendly XD

On 30 jun, 05:09, Vladislavs Korehovs <vladislavs.koreh...@gmail.com>
wrote:

[Eric Ayers]

Many points of the Poisonous People talk (and other insightful things about running an Open Source project) are found in the book "Producing Open Source Software" by Karl Fogel, who cut his teeth on the Subversion project - no You Tube required.

http://www.amazon.com/Producing-Open-Source-Software-Successful/dp/0596007590

The GWT development guidelines which are informed by this book are found here (I think Ray already posted this once in the course of this discussion - thanks Ray)

http://code.google.com/webtoolkit/makinggwtbetter.html


-Eric.

--
Eric Z. Ayers - GWT Team - Atlanta, GA USA
http://code.google.com/webtoolkit/

[Vladislavs Korehovs]

NO need to write such books,
Google can make their brainwashing directly from Karl Marx's
or any other Communism studies:)
Google implement many ideas of those...

On Jun 30, 2:00 pm, "Eric Ayers" <zun...@google.com> wrote:
> Many points of the Poisonous People talk (and other insightful things about
> running an Open Source project) are found in the book "Producing Open Source
> Software" by Karl Fogel, who cut his teeth on the Subversion project - no
> You Tube required.
>

> http://www.amazon.com/Producing-Open-Source-Software-Successful/dp/05...

> Eric Z. Ayers - GWT Team - Atlanta, GA USAhttp://code.google.com/webtoolkit/- Hide quoted text -