Mailing-List: contact dev-help@struts.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Struts Developers List" <dev@struts.apache.org>
Received-SPF: pass (asf.osuosl.org: domain of mfncooper@gmail.com designates
 64.233.166.179 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:references;
        b=HPQPanjkthebrj6egnXPH3r0kjJoNRONvewDaCIfSbesdl5mzB9Vf8o7PeTRzq+/2e8oojg0UPimxgbB+TgpEJPVYj2GMpSsCYn/2lZyMqJ2aupOLvMnU5xpGIthrgY56EqiV206hcbnzi/VHWtiDkgxyaZ1mFRusUhel6u9DU4=
Message-ID: <16d6c6200604132034w18889b45ke6b74090e82480d8@mail.gmail.com>
Date: Thu, 13 Apr 2006 20:34:30 -0700
From: "Martin Cooper" <martinc@apache.org>
Sender: mfncooper@gmail.com
To: "Struts Developers List" <dev@struts.apache.org>
Subject: Re: [action2] Switching to Dojo widgets
In-Reply-To: <443E968C.4060706@fdar.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_7775_10220645.1144985670250"
References: <443D7CEE.9070706@twdata.org>
	 <16d6c6200604122128h60802cb6vfcd2f1b6f9362f3a@mail.gmail.com>
	 <443E51EB.1020604@fdar.com> <443E72D7.8090304@twdata.org>
	 <443E968C.4060706@fdar.com>

------=_Part_7775_10220645.1144985670250
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On 4/13/06, Ian Roughley <ian@fdar.com> wrote:
>
> This is where my knowledge of dojo falls short, perhaps Martin can assist=
.
>
> What I was planning on doing was using a compressed JS profile of dojo,
> and removing the individual files from the saf src.  If we are pulling
> in individual files via dojo.require() do we need to keep the dojo src
> in the saf src?


I think what Don has done is fine. We can always fine-tune it later if we
need / want to.

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 include=
s
everything.

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.

--
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 <mrdon@twdata.org> 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.htm=
l
> >>>>  - 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: dev-unsubscribe@struts.apache.org
> >>>> For additional commands, e-mail: dev-help@struts.apache.org
> >>>>
> >>>>
> >>>>
> >>>
> >>>
> >>>
> >>>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> >> For additional commands, e-mail: dev-help@struts.apache.org
> >>
> >>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> > For additional commands, e-mail: dev-help@struts.apache.org
> >
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>

------=_Part_7775_10220645.1144985670250--