Martin Cooper wrote:
When you build (or download) a specific profile, the dojo.js file contains
only what is defined for that profile. However, everything else is still
available. Any code that is "dojo.require"d that is not part of the profile
will be dynamically fetched by Dojo when that 'require' is evaled. That's
why you need the source directory. The only situation in which this is not
true is if you use the kitchen sink profile, since by definition it includes
everything.
Just to avoid future confusion: that's not quite true. Kitchen sink
still doesn't include the code for the individual widgets, on the
assumption that very few apps/pages would need many of them at once, so
even with Kitchen Sink you still want the src/ folder around.
Additionally, there are other files you need under src/, such as HTML
widget templates, CSS and image files.
The trade-off is between having a larger download on startup versus having
multiple requests for individual pieces. Right now, I think it's fine to
have a minimal profile and then have each component fetch any additional
pieces it needs, which is what Don has done.
+1, it's really easy to create a custom profile with Dojo, and most
browsers will cache the dynamically loaded Javascript anyway so, as with
regularly included static resources, the download hit is one-time. If
there's anything (tooltips?) that's likely to be used by every page, it
may still be worth baking it into the profile, but otherwise, keep it
minimal.
L.
--
Martin Cooper
If you like I can assist, but I won't have time till late next week at
the earliest.
/Ian
Don Brown wrote:
Ian, what about using the minimal profile, but each component that
needs something more can do a dojo.require() to pull it in? A user's
application, that knows they need more, can overwrite head.ftl to
change the profile. This is the change I plan to do today.
Don
Ian Roughley wrote:
Martin - which profile do you suggest? I had a quick look over the
profiles awhile back, and the only ones from the kitchen sick that I
thought could be removed were "flash" and "storage" - especially with
the incorporation of more widgets.
The other option would be to have different profiles to download
which are dependent on which widgets you are using, but this seems
like it would be much more trouble as well as more custom
configuration (which we have been trying to avoid). What are your
thoughts?
My other plan (to which I owe Jason an apology as I ran out of time)
was to upgrade to 0.2.2 and use the compressed version rather than
the exploded version.
BTW - the dojo editor is already incorporated as an ajax themed
textarea, however as for 0.2.1 it is still seems a little buggy.
/Ian
Martin Cooper wrote:
On 4/12/06, Don Brown <[EMAIL PROTECTED]> wrote:
I'm starting to look into replacing the LGPL Javascript components
with
ones provided by Dojo, a toolkit we are already
using. Dojo already has the following widgets:
- date picker -
http://archive.dojotoolkit.org/nightly/tests/widget/test_DatePicker.html
- tooltip -
http://archive.dojotoolkit.org/nightly/tests/widget/test_Tooltip.html
- rich text editor -
http://archive.dojotoolkit.org/nightly/tests/widget/test_Editor.html
My question is how should we handle the Dojo imports? Currently
Dojo is
only imported in the header of the ajax theme.
I propose we import dojo.js in the header of the simple theme
(which is
imported by the other themes), leaving each
component to do the dojo.require() call to ensure their widget is
available.
This makes sense to me.
However, I think we should change the current strategy on the Dojo
profile
that's bundled by default. It looks like the kitchen sink profile is
what's
bundled today. It would make more sense, IMHO, to bundle the minimal
profile
(or at least somewhat more minimal than kitchen sink) by default,
and to
provide the kitchen sink as an option and / or provide instructions
on how
to construct a custom profile (which is really easy). I'm certainly
willing
to help out here.
--
Martin Cooper
Don
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
