[dojo-contributors] Re: Figuring out what Dojo needs to become. A few questions.

[Dylan Schiemann]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

One idea I had been floating around was in essence a widget state
precompiler.  Basically the idea was something like this:

- - widgets that are slow tend to be those with lots of nested nodes
(lists, trees, grids, etc.)

- - a huge benefit of widgets is attachPoints and event attachment in the
scope of a widget instance

So the idea went something like this:

- - a widget could be delivered in page with markup that already has a
number of subwidgets in the current state

- - a json description file could be delivered as well that would
initialize the widget into the same state that the markup or template is
already in

The main benefit of this would be along the lines of being able to use
the same widget code for create/read/update/delete operations on
subwidgets... basically the widget in this mythical setup would work the
same whether it was instantiated as a new widget, or prepopulated  with
market and some json description file.

This concept is almost completely unbaked, but the idea is that widgets
could optionally be delivered in a state that is more efficient than
having to initialize them "from scratch."  In many ways this could be
done with a template-less widget, though we'd still need a way to
generate the json description file for each server side language.

Thoughts?  At all coherent?

- -Dylan

Jesse Kuhnert wrote:
> Of course, all of these solutions suppose that a template is needed to
> build a DatePicker.
> 
> The very popular dhtml calendar (or even the DatePicker tapestry has)
> look/work great without templates.
> 
> Not saying it's what Dojo needs to do, just hoping the seed is planted
> in fertile enough soil for more people to think different ways.
> 
> On 12/28/06, Bill Keese <bill at dojotoolkit.org> wrote:
>> Eugene Lazutkin wrote:
>> > For example the calendar (DatePicker) widget has pretty elaborate
>> visual
>> > implementation, which is initialized dynamically (when the page has
>> > loaded). Why? It would be much better to generate all necessary HTML
>> for
>> > it on the server in a proper state showing an exact date: 12/28/2006.
>>
>> Uh oh, I opened a can of worms.  :-)
>>
>> Of course, the main reason we don't do that is that it requires a
>> back-end to be written in ever server language (PHP, Java, ASP, etc).
>>
>> But also, it's because creating widgets programatically would require an
>> XHR to the server to get the HTML.  In the DatePicker case it would be
>> worse; wouldn't you have to XHR w/the server every time you hit the
>> next-month or previous-month button?
>>
>>
>>  > It
>>  > will cut down on initialization time,
>>  > user will see the result much
>>  > earlier
>>
>> Hmm, I'm not sure if that's true.  (Assuming Dojo's javascript is
>> cached) doing templates on the server means that you are downloading
>> more data to the client each time, and you aren't reducing the amount of
>> code that gets run.  You are just changing the language, and the machine.
>>
>> I bet we could speed up initial instantiation time though, if (for
>> DropdownDatePicker), we didn't create the DatePicker widget until you
>> pressed the drop-down button.   Deferred instantiation is something to
>> think about for Tooltip too.
>>
>>  > and it will prevent flickering.
>>
>> Flickering is definitely something to think about.  Of course, if you
>> declare the widget like <dojo:DatePicker> then it will be hidden until
>> rendered, so at least you wouldn't see something that disappeared later.
>>
>>
>>
>> _______________________________________________
>> dojo-contributors mailing list
>> dojo-contributors at dojotoolkit.org
>> http://dojotoolkit.org/mailman/listinfo/dojo-contributors
>>
> 
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFlMBe8nLgh/JJsxERAiK3AJ42H07tj+jrICRS3NSmqnd87eT+agCfcQPM
lHWJ13osNLY7GXafBQFprpM=
=4ZHN
-----END PGP SIGNATURE-----