You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Martin Cooper <ma...@apache.org> on 2006/04/13 06:47:40 UTC

Re: JS Libraries (was Re: [WebWork2] TODO)

(Yeah, I'm very late catching up...)

On 3/28/06, Joe Germuska <Jo...@germuska.com> wrote:
>
> >I had very bad experiences with Dojo so far, and I brought this into
> >discussion on ww forums. I wouldn't encourage moving to Dojo, because the
> >browser support is still lacking, and from the feeling we got from their
> ml
> >some of the old browsers, that are still used (f.e. IE 5.5) will
> be  missing
> >in the next versions.
>
> If you believe http://thecounter.com/stats/2006/March/browser.php, IE
> 5.5 only has 2% market share.  I wouldn't blame a project for not
> spending a large amount of resources supporting that.


It's not just lack of market share. IE 5.5 has some serious deficiencies
when it comes to DHTML and DOM manipulation. So the question becomes one of
how much effort do you want to put in to support a minimally used browser,
and negatively impact performance on more modern browsers at the same time.
IMHO, the Dojo folks made the right decision.

That said, I think we should try to keep the JS libraries as
> pluggable as possible.  But maybe it's impossible to bundle valuable
> features and still do that -- I was really surprised at how many
> dependencies Webwork accepted, and I'm still trying to work out for
> myself whether that's better in the long run.  I think the Struts
> community philosophy was very conservative about that, but it may do
> us well to challenge that philosophy.
>
> Still, having roots in that philosophy, again my inclination is to
> try to be more library agnostic.  Can that work?


Well, in theory, yes. In practice, in the general case, I seriously doubt
it. To really accomplish that, we'd end up building yet another custom
abstraction. That would (a) negatively impact performance, and (b) eliminate
the option of using certain toolkits (e.g. Dojo) the way they were designed
to be used, viz _without_ an abstraction layer on top of the browser.

--
Martin Cooper


Joe
>
> --
> Joe Germuska
> Joe@Germuska.com * http://blog.germuska.com
>
> "You really can't burn anything out by trying something new, and
> even if you can burn it out, it can be fixed.  Try something new."
>         -- Robert Moog
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>

Re: JS Libraries (was Re: [WebWork2] TODO)

Posted by Martin Cooper <ma...@apache.org>.
On 4/12/06, Martin Cooper <ma...@apache.org> wrote:
>
> (Yeah, I'm very late catching up...)
>
> On 3/28/06, Joe Germuska <Jo...@germuska.com> wrote:
>
> > >I had very bad experiences with Dojo so far, and I brought this into
> > >discussion on ww forums. I wouldn't encourage moving to Dojo, because
> > the
> > >browser support is still lacking, and from the feeling we got from
> > their ml
> > >some of the old browsers, that are still used (f.e. IE 5.5) will
> > be  missing
> > >in the next versions.
> >
> > If you believe http://thecounter.com/stats/2006/March/browser.php , IE
> > 5.5 only has 2% market share.  I wouldn't blame a project for not
> > spending a large amount of resources supporting that.
>
>
> It's not just lack of market share. IE 5.5 has some serious deficiencies
> when it comes to DHTML and DOM manipulation. So the question becomes one of
> how much effort do you want to put in to support a minimally used browser,
> and negatively impact performance on more modern browsers at the same time.
> IMHO, the Dojo folks made the right decision.
>

Important Correction: I mis-spoke here. It's not IE 5.5 that has the
problems, it's IE 5.0. And even more importantly, Dojo *does* support IE 5.5,
but does not support IE 5.0. So if anyone has been having issues with Dojo
and IE 5.5, be sure to submit bug reports via Trac, and they'll be
addressed.

--
Martin Cooper


That said, I think we should try to keep the JS libraries as
> > pluggable as possible.  But maybe it's impossible to bundle valuable
> > features and still do that -- I was really surprised at how many
> > dependencies Webwork accepted, and I'm still trying to work out for
> > myself whether that's better in the long run.  I think the Struts
> > community philosophy was very conservative about that, but it may do
> > us well to challenge that philosophy.
> >
> > Still, having roots in that philosophy, again my inclination is to
> > try to be more library agnostic.  Can that work?
>
>
> Well, in theory, yes. In practice, in the general case, I seriously doubt
> it. To really accomplish that, we'd end up building yet another custom
> abstraction. That would (a) negatively impact performance, and (b) eliminate
> the option of using certain toolkits ( e.g. Dojo) the way they were
> designed to be used, viz _without_ an abstraction layer on top of the
> browser.
>
> --
> Martin Cooper
>
>
> Joe
> >
> > --
> > Joe Germuska
> > Joe@Germuska.com * http://blog.germuska.com
> >
> > "You really can't burn anything out by trying something new, and
> > even if you can burn it out, it can be fixed.  Try something new."
> >         -- Robert Moog
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> > For additional commands, e-mail: dev-help@struts.apache.org
> >
> >
>

Re: JS Libraries (was Re: [WebWork2] TODO)

Posted by Ian Roughley <ia...@fdar.com>.
I have some other things going on over the next few weeks that will mesh 
nicely with documenting how to do this.

/Ian


Don Brown wrote:

> I think the answer to all this is the built-in themes.  Right now, I'm 
> proposing that the current themes use Dojo where an advanced widget is 
> needed, however there could very well be a "prototype" theme, or the 
> user could replace the default head.ftl (that loads dojo) with their 
> own.  Component themes, and the ease of overriding a given template, 
> is a very powerful concept.  This is definitely something we'll need 
> to document more.
>
> Don
>
> Martin Cooper wrote:
>
>> (Yeah, I'm very late catching up...)
>>
>> On 3/28/06, Joe Germuska <Jo...@germuska.com> wrote:
>>  
>>
>>>> I had very bad experiences with Dojo so far, and I brought this into
>>>> discussion on ww forums. I wouldn't encourage moving to Dojo, 
>>>> because the
>>>> browser support is still lacking, and from the feeling we got from 
>>>> their
>>>>       
>>>
>>> ml
>>>    
>>>
>>>> some of the old browsers, that are still used (f.e. IE 5.5) will
>>>>       
>>>
>>> be  missing
>>>    
>>>
>>>> in the next versions.
>>>>       
>>>
>>> If you believe http://thecounter.com/stats/2006/March/browser.php, IE
>>> 5.5 only has 2% market share.  I wouldn't blame a project for not
>>> spending a large amount of resources supporting that.
>>>     
>>
>>
>>
>> It's not just lack of market share. IE 5.5 has some serious deficiencies
>> when it comes to DHTML and DOM manipulation. So the question becomes 
>> one of
>> how much effort do you want to put in to support a minimally used 
>> browser,
>> and negatively impact performance on more modern browsers at the same 
>> time.
>> IMHO, the Dojo folks made the right decision.
>>
>> That said, I think we should try to keep the JS libraries as
>>  
>>
>>> pluggable as possible.  But maybe it's impossible to bundle valuable
>>> features and still do that -- I was really surprised at how many
>>> dependencies Webwork accepted, and I'm still trying to work out for
>>> myself whether that's better in the long run.  I think the Struts
>>> community philosophy was very conservative about that, but it may do
>>> us well to challenge that philosophy.
>>>
>>> Still, having roots in that philosophy, again my inclination is to
>>> try to be more library agnostic.  Can that work?
>>>     
>>
>>
>>
>> Well, in theory, yes. In practice, in the general case, I seriously 
>> doubt
>> it. To really accomplish that, we'd end up building yet another custom
>> abstraction. That would (a) negatively impact performance, and (b) 
>> eliminate
>> the option of using certain toolkits (e.g. Dojo) the way they were 
>> designed
>> to be used, viz _without_ an abstraction layer on top of the browser.
>>
>> -- 
>> Martin Cooper
>>
>>
>> Joe
>>  
>>
>>> -- 
>>> Joe Germuska
>>> Joe@Germuska.com * http://blog.germuska.com
>>>
>>> "You really can't burn anything out by trying something new, and
>>> even if you can burn it out, it can be fixed.  Try something new."
>>>         -- Robert Moog
>>>
>>> ---------------------------------------------------------------------
>>> 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: JS Libraries (was Re: [WebWork2] TODO)

Posted by Don Brown <mr...@twdata.org>.
I think the answer to all this is the built-in themes.  Right now, I'm 
proposing that the current themes use Dojo where an advanced widget is 
needed, however there could very well be a "prototype" theme, or the 
user could replace the default head.ftl (that loads dojo) with their 
own.  Component themes, and the ease of overriding a given template, is 
a very powerful concept.  This is definitely something we'll need to 
document more.

Don

Martin Cooper wrote:
> (Yeah, I'm very late catching up...)
>
> On 3/28/06, Joe Germuska <Jo...@germuska.com> wrote:
>   
>>> I had very bad experiences with Dojo so far, and I brought this into
>>> discussion on ww forums. I wouldn't encourage moving to Dojo, because the
>>> browser support is still lacking, and from the feeling we got from their
>>>       
>> ml
>>     
>>> some of the old browsers, that are still used (f.e. IE 5.5) will
>>>       
>> be  missing
>>     
>>> in the next versions.
>>>       
>> If you believe http://thecounter.com/stats/2006/March/browser.php, IE
>> 5.5 only has 2% market share.  I wouldn't blame a project for not
>> spending a large amount of resources supporting that.
>>     
>
>
> It's not just lack of market share. IE 5.5 has some serious deficiencies
> when it comes to DHTML and DOM manipulation. So the question becomes one of
> how much effort do you want to put in to support a minimally used browser,
> and negatively impact performance on more modern browsers at the same time.
> IMHO, the Dojo folks made the right decision.
>
> That said, I think we should try to keep the JS libraries as
>   
>> pluggable as possible.  But maybe it's impossible to bundle valuable
>> features and still do that -- I was really surprised at how many
>> dependencies Webwork accepted, and I'm still trying to work out for
>> myself whether that's better in the long run.  I think the Struts
>> community philosophy was very conservative about that, but it may do
>> us well to challenge that philosophy.
>>
>> Still, having roots in that philosophy, again my inclination is to
>> try to be more library agnostic.  Can that work?
>>     
>
>
> Well, in theory, yes. In practice, in the general case, I seriously doubt
> it. To really accomplish that, we'd end up building yet another custom
> abstraction. That would (a) negatively impact performance, and (b) eliminate
> the option of using certain toolkits (e.g. Dojo) the way they were designed
> to be used, viz _without_ an abstraction layer on top of the browser.
>
> --
> Martin Cooper
>
>
> Joe
>   
>> --
>> Joe Germuska
>> Joe@Germuska.com * http://blog.germuska.com
>>
>> "You really can't burn anything out by trying something new, and
>> even if you can burn it out, it can be fixed.  Try something new."
>>         -- Robert Moog
>>
>> ---------------------------------------------------------------------
>> 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