You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Don Brown <mr...@twdata.org> on 2006/04/13 00:19:26 UTC
[action2] Switching to Dojo widgets
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.
Don
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [action2] Switching to Dojo widgets
Posted by Ian Roughley <ia...@fdar.com>.
Thanks for the clarification. That makes sense now :)
/Ian
Martin Cooper wrote:
>On 4/13/06, Ian Roughley <ia...@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 includes
>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 <mr...@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.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: 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
>>
>>
>>
>>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [action2] Switching to Dojo widgets
Posted by Laurie Harper <la...@holoweb.net>.
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 <mr...@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.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: 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
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [action2] Switching to Dojo widgets
Posted by Martin Cooper <ma...@apache.org>.
On 4/13/06, Ian Roughley <ia...@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 includes
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 <mr...@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.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: 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
>
>
Re: [action2] Switching to Dojo widgets
Posted by Don Brown <mr...@twdata.org>.
Ian Roughley 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?
Since we are using Dojo now for tooltips, we are importing a minimal dojo profile on every page (simple/head.ftl).
Therefore, I think it is important to keep this minimal, leaving components to require other parts of dojo as they need.
The power user will override simple/head.ftl and import the exact parts of dojo it needs so the later requires won't
have a performance impact.
Don
>
> 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 <mr...@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.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: 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [action2] Switching to Dojo widgets
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
netsql wrote:
> ps: very exciting to have Ajax built in!!!!!!!!
:) Could have had that a year ago :)
(Sorry, couldn't resist)
Frank
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [action2] Switching to Dojo widgets
Posted by Ian Roughley <ia...@fdar.com>.
Don Brown wrote:
> Ian Roughley wrote:
>
>> Ok, I'll be more specific :) The tags that you use in JSP are
>> directly available to other view technologies (freemarker and
>> velocity) due to a common underlying component model. To make this
>> possible they have their own MVC design - using a freemarker template
>> as the view.
>>
>> So you can use any ajax library that you want. But if you create a
>> new UI theme via templates, I think you are better encapsulating the
>> logic. SAF/WW is by no means dojo specific, but dojo was the first
>> ajax theme implemented, and it looks like the default out of the box.
>
>
> Ok, that's the theory, but in practice, different toolkits have
> widgets that support different parameters. Currently, we have a
> Component class, which has getters/setters for its parameters. Should
> this class have accessors for every possible parameter?
>
> Take, for example, the date picker widget. I just switched Action 2
> to Dojo's Date picker. Unfortunately, it has very few parameters and
> supports no localization, however, the component class has a bunch of
> parameters, all supported by the old jscalendar Javascript library.
> Do I remove all the unsupported component class parameters and someone
> let users know they won't work, or do I replace them with parameters
> supported by the new date picker?
>
> Don
This as come up a couple of times. One option that was suggested is
nesting the ww:param for the advanced parameters.
>
>>
>> /Ian
>>
>>
>>
>> netsql wrote:
>>
>>> Struts 1.x was "view independent".
>>>
>>> Is SAF2 (pronounced "SafeTy"? ;-) ) be dojo specific? Like I could
>>> not use Tibet w/out fighting the "tags"?
>>> (or JDNC once they figure that out.)
>>>
>>> .V
>>>
>>> ps: very exciting to have Ajax built in!!!!!!!!
>>>
>>>
>>> Ian Roughley wrote:
>>>
>>>> This is where my knowledge of dojo falls short, perhaps Martin can
>>>> assist.
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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
Re: [action2] Switching to Dojo widgets
Posted by Don Brown <mr...@twdata.org>.
Ian Roughley wrote:
> Ok, I'll be more specific :) The tags that you use in JSP are directly
> available to other view technologies (freemarker and velocity) due to a
> common underlying component model. To make this possible they have
> their own MVC design - using a freemarker template as the view.
>
> So you can use any ajax library that you want. But if you create a new
> UI theme via templates, I think you are better encapsulating the logic.
> SAF/WW is by no means dojo specific, but dojo was the first ajax theme
> implemented, and it looks like the default out of the box.
Ok, that's the theory, but in practice, different toolkits have widgets that support different parameters. Currently,
we have a Component class, which has getters/setters for its parameters. Should this class have accessors for every
possible parameter?
Take, for example, the date picker widget. I just switched Action 2 to Dojo's Date picker. Unfortunately, it has very
few parameters and supports no localization, however, the component class has a bunch of parameters, all supported by
the old jscalendar Javascript library. Do I remove all the unsupported component class parameters and someone let users
know they won't work, or do I replace them with parameters supported by the new date picker?
Don
>
> /Ian
>
>
>
> netsql wrote:
>
>> Struts 1.x was "view independent".
>>
>> Is SAF2 (pronounced "SafeTy"? ;-) ) be dojo specific? Like I could not
>> use Tibet w/out fighting the "tags"?
>> (or JDNC once they figure that out.)
>>
>> .V
>>
>> ps: very exciting to have Ajax built in!!!!!!!!
>>
>>
>> Ian Roughley wrote:
>>
>>> This is where my knowledge of dojo falls short, perhaps Martin can
>>> assist.
>>>
>>
>>
>> ---------------------------------------------------------------------
>> 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
Re: [action2] Switching to Dojo widgets
Posted by Ian Roughley <ia...@fdar.com>.
Ok, I'll be more specific :) The tags that you use in JSP are directly
available to other view technologies (freemarker and velocity) due to a
common underlying component model. To make this possible they have
their own MVC design - using a freemarker template as the view.
So you can use any ajax library that you want. But if you create a new
UI theme via templates, I think you are better encapsulating the logic.
SAF/WW is by no means dojo specific, but dojo was the first ajax theme
implemented, and it looks like the default out of the box.
/Ian
netsql wrote:
> Struts 1.x was "view independent".
>
> Is SAF2 (pronounced "SafeTy"? ;-) ) be dojo specific? Like I could not
> use Tibet w/out fighting the "tags"?
> (or JDNC once they figure that out.)
>
> .V
>
> ps: very exciting to have Ajax built in!!!!!!!!
>
>
> Ian Roughley wrote:
>
>> This is where my knowledge of dojo falls short, perhaps Martin can
>> assist.
>>
>
>
> ---------------------------------------------------------------------
> 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
Re: [action2] Switching to Dojo widgets
Posted by netsql <ne...@roomity.com>.
Struts 1.x was "view independent".
Is SAF2 (pronounced "SafeTy"? ;-) ) be dojo specific? Like I could not
use Tibet w/out fighting the "tags"?
(or JDNC once they figure that out.)
.V
ps: very exciting to have Ajax built in!!!!!!!!
Ian Roughley wrote:
> This is where my knowledge of dojo falls short, perhaps Martin can assist.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [action2] Switching to Dojo widgets
Posted by Ian Roughley <ia...@fdar.com>.
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?
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 <mr...@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.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: 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
Re: [action2] Switching to Dojo widgets
Posted by Don Brown <mr...@twdata.org>.
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 <mr...@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.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: 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
Re: [action2] Switching to Dojo widgets
Posted by Ian Roughley <ia...@fdar.com>.
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 <mr...@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.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: 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
Strecks 1.0-alpha-1 released
Posted by Phil Zoio <ph...@realsolve.co.uk>.
I'm pleased to announce the first public release of Strecks, a set of
open source extensions to the Struts framework aimed at Java 5 users.
Strecks (which stands for "Struts Extensions") is built on the existing
Struts 1.2 code base.
Strecks contains a range of features aimed to streamline the Struts
programming model. Some key features include:
- pure POJO action beans with zero framework dependencies
- action vs controller separation. Request processing logic is
encapsulated into Action controllers, simplifying action implementations
- annotation-based dependency injection (typed request parameters,
session attributes, Spring beans, and many others)
- annotation-based form validators (XML and code-free)
- annotation-based data binding from form properties to domain model
- annotations for additional per-field control over type conversion
- simplified mechanisms to support navigation and redirecting after posts
- pluggable navigation using annotations
- pre and post action interceptors
For a more complete list, see http://strecks.sourceforge.net/features.php
The main design goals of Strecks are to:
- introduce no compatibility issues apart from Java 5
- simplify the action/form programming model in line with recent
software development best practices
- offer or even improve on advanced features offered by competitive
frameworks
- keep easy to learn for existing Struts users
Strecks 1.0-alpha-1 is available for download from
http://strecks.sourceforge.net/.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [action2] Switching to Dojo widgets
Posted by Martin Cooper <ma...@apache.org>.
On 4/12/06, Don Brown <mr...@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.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: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>