PotentialElement seems to be one of those ghost features that was never
finished, or at least never correctly documented, so might as well be half
done:
EXPERIMENTAL and subject to change. Do not use this in production code.
>
We've never used it, and I've only encouraged people to stay away from it,
since, well, we aren't supposed to use it in production code.
There are only a handful of places that use PotentialElement - a Composite
has a 'resolve' step, DOM does some resolution as well, UiObject just has a
ton of asserts, and then of course RenderablePanel, "EXPERIMENTAL and
subject to change. Do not use this in production code.". Then we get this
tidbit:
This class is a stepping in our transition to the Renderable strategy.
> Eventually this functionality should be merged into {@link HTMLPanel}.
>
Related classes seem to include IsRenderable:
This interface is very experimental and in active development, so the
> exact API is likely to change. Very likely. In fact, it will definitely
> change. You've been warned.
>
Hard to argue with that. The snark is kinda fun, but we should know better
for production code.
/**
> * @see #render(RendearbleStamper, SafeHtmlBuilder)
> * TODO(rdcastro): Remove this once UiBinder doesn't rely on it anymore.
> */
> SafeHtml render(RenderableStamper stamper);
>
I'm assuming UiBinder still relies on it.
> // TODO(rdcastro): use the render() call that receives the
> SafeHtmlBuilder
> String elementHtml =
> fieldManager.convertFieldToGetter(childFieldWriter.getName()) + ".render("
> + fieldManager.convertFieldToGetter(stamper) + ")";
>
Yep. Also looks like Composite and RenderablePanel use it too.
>From an outsider's perspective, this is not only unfinished code, but
probably abandoned since it has been left unfinished for so long. If it
isn't going to be finished/maintained, it should be deprecated, wait a
version and remove it, otherwise it should be 'completed'. Another option
would be to factor it out to its own jar so that it doesn't appear to be an
integral part of User... but the hooks in DOM.java will make that hard, and
the 'only com.google.gwt code can write uibinder parsers' make this even
tougher.
On Sun, Jul 6, 2014 at 10:25 PM, 'Goktug Gokdogan' via GWT Contributors <
google-web-toolkit-contributors@googlegroups.com> wrote:
>
>
>
> On Sun, Jul 6, 2014 at 8:05 PM, Stephen Haberman <
> stephen.haber...@gmail.com> wrote:
>
>>
>> > Even Orkut closing the doors, it doesn't mean their code is going away
>> > anytime soon :)
>>
>> You're killing me, Goktug. The backwards compatibility knife had
>> already pierced my heart, and this just shimmied it around a bit. :-)
>>
>>
> The point was more about Orkut announcement doesn't change anything and
> cannot effect the decision from our perspective; as long as the system is
> running we need to take care of it.
>
>
>
>> I had to refresh on memory on PotentialElement, but it looks virtual
>> DOM-ish; making fake elements that are really pure JS objects, and then
>> later converting them into real DOM objects only as-needed. I believe
>> it sped up the first page load of Orkut by ...15%? or so.
>>
>> I also vaguely recall that, AFAIU, the pipe dream was to have the
>> entire initial DOM render be one huge .innerHTML=<blah>, since IE
>> really liked that. But making strings that big hurts the GC such that
>> (AFAIK) it's a wash in modern browsers to just making DOM elements
>> directly anyway.
>>
>> Speaking of PotentialElement, looking at commits from around that time
>> frame, there is also a change from Ray Ryan that turned
>> useLazyWidgetBuilders = true, with a commit message of "in prep for
>> deleting the old code".
>>
>> Looks like that deleting never happened...can we do that now?
>>
>> As with PotentialElement, I don't think useLazyWidgetBuilders had any
>> external design docs, discussion, etc., so I don't really know the
>> whole story on it. Or even little bits, other than I enjoy deleting old
>> code and will volunteer to do that if we can.
>>
>> - Stephen
>>
>> --
>> 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 google-web-toolkit-contributors+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/google-web-toolkit-contributors/20140706220525.6ccc4472%40sh9
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
> --
> 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 google-web-toolkit-contributors+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAN%3DyUA2itF_dBO%3D8GpRmRgs0%3D2NfeBY1r%3Dhr2may347Hb9BQHg%40mail.gmail.com
> <https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAN%3DyUA2itF_dBO%3D8GpRmRgs0%3D2NfeBY1r%3Dhr2may347Hb9BQHg%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
> For more options, visit https://groups.google.com/d/optout.
>
--
218.248.6165
niloc...@gmail.com
--
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 google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/google-web-toolkit-contributors/CADcXZMyLEaz9i2UhqsLqZ1yhe80t2jMQ6g4Pn91RqEaQofz5fg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
