You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Ted Husted <te...@gmail.com> on 2006/03/27 02:24:48 UTC
[WebWork2] TODO
The big item on the Incubator TODO list is verifying distribution
rights. The items here are
(1) Verify that the files that have been donated have been updated to
reflect the new ASF copyright.
(2) Verify that for all code included with the distribution that is
not under the Apache license, we have the right to combine with
Apache-licensed code and redistribute.
(3) Verify that all source code distributed by the project is covered
by one or more of the following approved licenses: Apache, BSD,
Artistic, MIT/X, MIT/W3C, MPL 1.1, or something with essentially the
same terms.
----
As to (3), in another thread Rainer cited at least four components
that we need to be address
* JSCalendar for the DatePicker tag
* FCKEditor for the Richtexteditor tag
* Walter Zorns tooltip library for all UI Tags
* tabbedpane.vm Archived UI template
Martin suggested that there may be DOJO equivalents for all four of
these. (Unless tabbed pane is server-side.)
Is anyone planning on checking on these yet?
----
As to (2), if we resolve (3), will there be any other *code* that
would not be under the ASF.
As to (1), I scanned the Java source for copright statements. We seem
to be in pretty good shape. Most of those that have copyright
statements run to "Open Symphony Group". But, there are a few
exceptions.
* Copyright (c) 2005 ePlus Corporation (SessionContextAutowiringInterceptor)
* Copyright (C) NanoContainer Organization (org.apache.struts.action2.pico)
* Copyright (c) 2005 Your Corporation.
Well, the last one, I think we can safely ignore :)
I believe the first one is Jason's employer. If possible, it would be
great if we could get a software grant or CCLA to cover this class.
Meanwhile, has the software grant for "Open Symphony Group" gone on
file yet? I looked but I didn't see it.
-----
As to the package naming, did anyone want to change their vote to
followup on Gabe's suggestion? Otherwise, it looks like the
conventions suggested by Rainer have the most support.
I don't know if we want to bring XWork into the ASF now, later, or
never. Of course, it's a great package and I'm sure we'd love to have
it, if the XWork developers would like to donate and support it.
There would also be the question of whether XWork is something that we
would maintain here, or whether we might want to propose it to the
Jakarta Commons, where it might find a broader audience.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [WebWork2] TODO
Posted by Ian Roughley <ia...@fdar.com>.
I thought there was some talk of depreciating the tabbedpane (as
opposed to the
tabbedpannel - ajax component). Pat - do you remember anything about this?
/Ian
Quoting Ted Husted <te...@gmail.com>:
> STATUS update
> ----
>
> DISTRIBUTION RIGHTS - LICENSING
>
> JSCalendar for the DatePicker tag
> * Rene will contact author about license change
> * There may also be a Dojo equivalent
>
> FCKEditor for the Richtexteditor tag
> * Is there a Dojo equivalent?
>
> Walter Zorns tooltip library for all UI Tags
> * Is there a Dojo equivalent?
>
> tabbedpane.vm Archived UI template
> * Is this a server-side compoonent, or is there a Dojo equivalent?
>
> ----
>
> DISTRIBUTION RIGHTS - COPYRIGHT HOLDERS
>
> Has "Open Symphony Group" filed a software grant?
>
> Has "ePlus Corporation" filed a software grant or CCLA for Jason?
>
> ----
>
> NAMING CONVENTIONS
>
> Option 1:
>
> - com.opensymphony.webwork package -> org.apache.struts.ti
> - WebWork* classes -> Struts*
> - WebWork in comments, documentation -> Struts Action 2
> - webwork. as the configuration properties prefix -> struts.
> - ww: tag prefix -> a:
>
> +1 Martin Cooper (binding)
> +0 Don Brown (binding)
> +1 Frank Zammetti (non-binding)
>
> Option 2:
> - com.opensymphony.webwork package -> org.apache.struts.action2
> - WebWork* classes -> Struts*
> - WebWork in comments, documentation -> Struts Action 2
> - webwork. as the configuration properties prefix -> struts.
> - ww: tag prefix -> a:/saf:
>
> +1 Rainer Hermanns, Ted Husted, Alexandru Popescu, Rene Gielen, Don
> Brown (binding)
> +0 Toby Jee, Hubert Rabago, Craig McClanahan (binding)
> +1 Paul Benedict, Michael Jouravlev (non-binding)
>
> Option 3:
> - com.opensymphony.webwork package -> org.apache.web or .webwork
> - WebWork in comments, documentation -> Struts Action 2
> - webwork. as the configuration properties prefix -> web or webwork
> - else, remains the same
>
> +0 Joe Germuska, Ted Husted (binding)
> +1 Gabe (non-binding)
>
> ----
>
> MIGRATE XWORK NOW (see "[Struts Tt] Xwork?")
>
> +1 Gabe
>
> ----
>
> At this point, I'll move the STATUS notes to a file in the repository,
> where it will be easier to track and maintain as a group.
>
> -Ted.
>
> ---------------------------------------------------------------------
> 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 Ian Roughley <ia...@fdar.com>.
Martin Cooper wrote:
>On 3/28/06, Ian Roughley <ia...@fdar.com> wrote:
>
>
>>Alex - I definately agree with you, somewhat ;) - if this is a simple
>>calendar,
>>or other lightweight widget there is no need to involve an ajax library
>>download. *Any* ajax library download. But I do think there is a need
>>for an
>>ajax theme when the user is ready to use one. So how do we deferentiate
>>between these?
>>
>>Joe - I think the UI tags are very library agnostic. It was reasonably
>>simple
>>to add in the dojo support once we had the <ww:a .../>, <ww:div .../>
>>etc. tags
>>in place. Dojo just happened to be the initial implementation. We could
>>definately outline what the core components are (JS widget and ajax
>>widget) and
>>the attributes and functionality that is expected from a tag API
>>standpoint, and
>>then have different implementations of the tag themes for
>>implementation.
>>
>>
>
>
>The question here is whether the developer should pick one toolkit and run
>with it, or should be able to pick different widgets that come from
>different toolkits. Most people seem to want to do the latter, but that is
>highly problematic. For one thing, few random combinations of DHTML toolkits
>will work together properly. For another, the browser will end up
>downloading and evaluating much more code than is really necessary,
>impacting performance.
>
>
I would definitely agree with you - try to keep within UI theme
boundaries whenever possible, especially when using ajax themes.
>Additionally, when talking about this last month (or
>
>
>>was it longer now?) we
>>(Ranier, Rene, Alex and Mike) were all thinking in the same vein. One
>>thing
>>that we wanted to add was an action/inteface that returned JSON so that
>>any
>>ajax implementation could use the same server implementation to provide
>>list
>>data.
>>
>>
>
>
>Yes, a JSON serialiser would be A Good Thing (tm) to have. The hard part,
>though, is getting people to agree on what you encode in JSON and how. ;-)
>Without that, you don't have interoperability.
>
>
Perhaps I should have explained a little better. The action / interface
that was proposed was something like:
List getData();
So, the information in the list would be highly dependent on the feature
being developed. Thus, we could use the attribute names and values (and
possibly walking into more complex values in a similar nature). As the
data is dependent on the feature, and the developer will most likely be
working on the action and the view, I think we would be ok.
>--
>Martin Cooper
>
>
>The question really is do we bundle the libaries and the implementations
>
>
>>with
>>the SAF 2.0 release or should there be a seperate project where the
>>different
>>library integrations live? Althought we could extract them into a
>>optional
>>project, I think there is benifit in provide a basic implementation.
>>
>>/Ian
>>
>>
>>Quoting Alexandru Popescu <th...@gmail.com>:
>>
>>
>>
>>>Joe, I mostly agree with you. What I've been trying to say is that most
>>>
>>>
>>of
>>
>>
>>>the user will not like to have a big dependency on Dojo for simple
>>>functionality like a calendar component. And I agree, this is my case
>>>
>>>
>>too. I
>>
>>
>>>would prefere something small and working almost everywhere. We have
>>>
>>>
>>even
>>
>>
>>>been thinking to add a new AJAX theme based on lighter solutions (a la
>>>prototype). And if this will work, I would almost sure vote for removing
>>>
>>>
>>the
>>
>>
>>>dependency on Dojo. But this is way to personal :-).
>>>
>>>./alex
>>>--
>>>.w( the_mindstorm )p.
>>>
>>>
>>>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.
>>>>
>>>>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?
>>>>
>>>>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 Martin Cooper <ma...@apache.org>.
On 3/28/06, Ian Roughley <ia...@fdar.com> wrote:
>
> Alex - I definately agree with you, somewhat ;) - if this is a simple
> calendar,
> or other lightweight widget there is no need to involve an ajax library
> download. *Any* ajax library download. But I do think there is a need
> for an
> ajax theme when the user is ready to use one. So how do we deferentiate
> between these?
>
> Joe - I think the UI tags are very library agnostic. It was reasonably
> simple
> to add in the dojo support once we had the <ww:a .../>, <ww:div .../>
> etc. tags
> in place. Dojo just happened to be the initial implementation. We could
> definately outline what the core components are (JS widget and ajax
> widget) and
> the attributes and functionality that is expected from a tag API
> standpoint, and
> then have different implementations of the tag themes for
> implementation.
The question here is whether the developer should pick one toolkit and run
with it, or should be able to pick different widgets that come from
different toolkits. Most people seem to want to do the latter, but that is
highly problematic. For one thing, few random combinations of DHTML toolkits
will work together properly. For another, the browser will end up
downloading and evaluating much more code than is really necessary,
impacting performance.
Additionally, when talking about this last month (or
> was it longer now?) we
> (Ranier, Rene, Alex and Mike) were all thinking in the same vein. One
> thing
> that we wanted to add was an action/inteface that returned JSON so that
> any
> ajax implementation could use the same server implementation to provide
> list
> data.
Yes, a JSON serialiser would be A Good Thing (tm) to have. The hard part,
though, is getting people to agree on what you encode in JSON and how. ;-)
Without that, you don't have interoperability.
--
Martin Cooper
The question really is do we bundle the libaries and the implementations
> with
> the SAF 2.0 release or should there be a seperate project where the
> different
> library integrations live? Althought we could extract them into a
> optional
> project, I think there is benifit in provide a basic implementation.
>
> /Ian
>
>
> Quoting Alexandru Popescu <th...@gmail.com>:
>
> > Joe, I mostly agree with you. What I've been trying to say is that most
> of
> > the user will not like to have a big dependency on Dojo for simple
> > functionality like a calendar component. And I agree, this is my case
> too. I
> > would prefere something small and working almost everywhere. We have
> even
> > been thinking to add a new AJAX theme based on lighter solutions (a la
> > prototype). And if this will work, I would almost sure vote for removing
> the
> > dependency on Dojo. But this is way to personal :-).
> >
> > ./alex
> > --
> > .w( the_mindstorm )p.
> >
> >
> > 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.
> >>
> >> 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?
> >>
> >> 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
>
>
Re: JS Libraries (was Re: [WebWork2] TODO)
Posted by Ian Roughley <ia...@fdar.com>.
Alex - I definately agree with you, somewhat ;) - if this is a simple
calendar,
or other lightweight widget there is no need to involve an ajax library
download. *Any* ajax library download. But I do think there is a need for an
ajax theme when the user is ready to use one. So how do we deferentiate
between these?
Joe - I think the UI tags are very library agnostic. It was reasonably simple
to add in the dojo support once we had the <ww:a .../>, <ww:div .../>
etc. tags
in place. Dojo just happened to be the initial implementation. We could
definately outline what the core components are (JS widget and ajax
widget) and
the attributes and functionality that is expected from a tag API
standpoint, and
then have different implementations of the tag themes for
implementation. Additionally, when talking about this last month (or
was it longer now?) we
(Ranier, Rene, Alex and Mike) were all thinking in the same vein. One thing
that we wanted to add was an action/inteface that returned JSON so that any
ajax implementation could use the same server implementation to provide list
data.
The question really is do we bundle the libaries and the implementations with
the SAF 2.0 release or should there be a seperate project where the different
library integrations live? Althought we could extract them into a optional
project, I think there is benifit in provide a basic implementation.
/Ian
Quoting Alexandru Popescu <th...@gmail.com>:
> Joe, I mostly agree with you. What I've been trying to say is that most of
> the user will not like to have a big dependency on Dojo for simple
> functionality like a calendar component. And I agree, this is my case too. I
> would prefere something small and working almost everywhere. We have even
> been thinking to add a new AJAX theme based on lighter solutions (a la
> prototype). And if this will work, I would almost sure vote for removing the
> dependency on Dojo. But this is way to personal :-).
>
> ./alex
> --
> .w( the_mindstorm )p.
>
>
> 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.
>>
>> 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?
>>
>> 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
Re: JS Libraries (was Re: [WebWork2] TODO)
Posted by Martin Cooper <ma...@apache.org>.
On 3/28/06, Michael Jouravlev <jm...@gmail.com> wrote:
>
> On 3/28/06, Alexandru Popescu <th...@gmail.com> wrote:
> > I would prefere something small and working almost everywhere. We have
> even
> > been thinking to add a new AJAX theme based on lighter solutions (a la
> > prototype).
>
> Heh, and I considered Prototype too heavy (around 50K) to adopt for my
> project...
Prototype's heaviness is in its feet - it will quite happily stomp all over
any other JavaScript code you have on the page. It's really a very badly
behaved chunk of code.
--
Martin Cooper
Michael.
>
> ---------------------------------------------------------------------
> 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 Michael Jouravlev <jm...@gmail.com>.
On 3/28/06, Alexandru Popescu <th...@gmail.com> wrote:
> I would prefere something small and working almost everywhere. We have even
> been thinking to add a new AJAX theme based on lighter solutions (a la
> prototype).
Heh, and I considered Prototype too heavy (around 50K) to adopt for my
project...
Michael.
---------------------------------------------------------------------
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 3/28/06, Alexandru Popescu <th...@gmail.com> wrote:
>
> Joe, I mostly agree with you. What I've been trying to say is that most of
> the user will not like to have a big dependency on Dojo for simple
> functionality like a calendar component.
The "size" of the dependency on Dojo is _completely_ up to you. Unlike the
other DHTML toolkits out there, you can very easily build a custom profile
that includes only what you need, and almost none of the code you don't
need.
The minimal profile of Dojo is very small. Right now, it looks like WW uses
the kitchen sink profile, which is pretty much everything Dojo has. I can
understand why you would not want to load all of that for just a calendar.
But you don't have to. That is the beauty of the Dojo profile system.
--
Martin Cooper
And I agree, this is my case too. I
> would prefere something small and working almost everywhere. We have even
> been thinking to add a new AJAX theme based on lighter solutions (a la
> prototype). And if this will work, I would almost sure vote for removing
> the
> dependency on Dojo. But this is way to personal :-).
>
> ./alex
> --
> .w( the_mindstorm )p.
>
>
> 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.
> >
> > 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?
> >
> > 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 Alexandru Popescu <th...@gmail.com>.
Joe, I mostly agree with you. What I've been trying to say is that most of
the user will not like to have a big dependency on Dojo for simple
functionality like a calendar component. And I agree, this is my case too. I
would prefere something small and working almost everywhere. We have even
been thinking to add a new AJAX theme based on lighter solutions (a la
prototype). And if this will work, I would almost sure vote for removing the
dependency on Dojo. But this is way to personal :-).
./alex
--
.w( the_mindstorm )p.
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.
>
> 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?
>
> 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
Re: JS Libraries (was Re: [WebWork2] TODO)
Posted by Martin Cooper <ma...@apache.org>.
(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
>
>
JS Libraries (was Re: [WebWork2] TODO)
Posted by Joe Germuska <Jo...@Germuska.com>.
>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.
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?
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: [WebWork2] TODO
Posted by Rainer Hermanns <he...@aixcept.de>.
Hey there,
I share Alex' opinion on DOJO. We should not add to many dependencies for
"core" components into the themes for now.
DOJO is still quite unstable and we should wait until their basis gets a
bit more stable.
Regarding the other AJAX themes, there were plans already to rename the
current "ajax" theme to "dojo" and provide a new theme "prototype" based
on prototype and script.aculo.us.
A third ajax enabled theme was discussed to include the Yahoo components.
But these developments are still in progress or on hold til now, cause
of the webwork 2.2.2 release.
cheers,
Rainer
> pls see inlined....
>
> On 3/27/06, Ted Husted <te...@gmail.com> wrote:
>>
>> STATUS update
>> ----
>>
>> DISTRIBUTION RIGHTS - LICENSING
>>
>> JSCalendar for the DatePicker tag
>> * Rene will contact author about license change
>> * There may also be a Dojo equivalent
>>
>> FCKEditor for the Richtexteditor tag
>> * Is there a Dojo equivalent?
>>
>> Walter Zorns tooltip library for all UI Tags
>> * Is there a Dojo equivalent?
>
>
> 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.
>
> hth,
>
> ./alex
> --
> .w( the_mindstorm )p.
>
> [trimmed rest of original mail]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [WebWork2] TODO
Posted by Alexandru Popescu <th...@gmail.com>.
pls see inlined....
On 3/27/06, Ted Husted <te...@gmail.com> wrote:
>
> STATUS update
> ----
>
> DISTRIBUTION RIGHTS - LICENSING
>
> JSCalendar for the DatePicker tag
> * Rene will contact author about license change
> * There may also be a Dojo equivalent
>
> FCKEditor for the Richtexteditor tag
> * Is there a Dojo equivalent?
>
> Walter Zorns tooltip library for all UI Tags
> * Is there a Dojo equivalent?
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.
hth,
./alex
--
.w( the_mindstorm )p.
[trimmed rest of original mail]
Re: [WebWork2] TODO
Posted by Laurie Harper <la...@holoweb.net>.
Joe Germuska wrote:
> At 7:39 AM -0500 3/27/06, Ted Husted wrote:
>> Walter Zorns tooltip library for all UI Tags
>> * Is there a Dojo equivalent?
>
> I'm pretty sure there is not.
I haven't looked at the Walter Zorn tooltips, but Dojo does have a
tooltip widget:
http://dojotoolkit.org/~dylan/dojo/tests/widget/test_Tooltip.html
Is that what would be needed?
L.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [WebWork2] TODO
Posted by Ian Roughley <ia...@fdar.com>.
This is a good followup to what Craig is saying. I accidentally sent
it to Joe
instead of this list - hopefully got it right this time :)
It's not a JS API, but WW does have something similar in the theme's for the
tags.
At the moment we have a dojo theme, but Ranier was going to introduce a
prototype/scripactulous theme. Some on the users list didn't like to
introduce
dojo into pages that only needed a date picker/WYSIWYG editor - and hence the
current implementation (I did add a dojo implementation, but at the current
version of dojo this is a little flaky).
We had a discussion a few months back, and agreed on certain standard
components
that each theme should implement. What we need to be carefull of, is ensuring
that each theme implementation covers this same functionality. One case of
this is that the prototype currently does not offer events similar to
dojo - so
it would need to be clearly documentated that you cannot easy move
between these
themes.
Quoting Craig McClanahan <cr...@apache.org>:
> On 3/27/06, Frank W. Zammetti <fz...@omnytex.com> wrote:
>>
>> On Mon, March 27, 2006 9:22 am, Joe Germuska said:
>> > I wonder if there's a way to generalize an "API" out of these so that
>> > we are less bound to an implementation. Certainly, a date picker or
>> > rich text field which ultimately just ends up setting a value of a
>> > single form field should be not too hard to generalize, although I
>> > haven't looked at all the models for integrating JS widgets into a
>> > page neatly. I guess there are also issues of triggering the
>> > widgets, etc.
>>
>> Generalize an API out of GUI widgets?
>>
>> Where's Craig with the JSF plug when you need him?!? :-) LOL
>
>
> Ask and ye shall receive :-) [1]
>
> Seriously, wrapping DOJO widgets (using whatever technology you like on the
> server side) is a heck of a lot more fun than writing all that javascript
> yourself, as long as the underlying widget does what you need. I'm
> currently playing with a JSF component wrapper for DOJO's rich text editing
> capability. Took about an hour to do the wrapping -- the only issues I've
> got relate to the widget implementation itself (doesn't support scrollbars,
> and problems hooking in to the Save and Cancel events where I want to).
>
> I've also seen people try to generalize *all* DOJO widgets with a single JSP
> tag API. This is a lot more practical in JSP 2.0, where you can declare a
> tag that takes arbitrary parameters. But I worry about usability issues of
> a single tag like this, because you effectively have a "mode" of operation
> for every widget (which would each only recognize only a subset of the
> overall set of attributes). We have small examples of this sort of thing
> all over the Struts tag library ... just for an example, try to explain to a
> newbie what combination of attributes to use on an <html:frame> tag[2] when
> you want to pass parameters in.
>
> Wrapping is good, but I've come to believe in "one tag (or equivalent for
> your favorite technology) per use case" is better than "one size fits all".
>
> Frank
>
>
> Craig
>
> [1]
> http://blogs.sun.com/roller/page/edwingo?entry=component_authoring_for_creator
> [2] http://struts.apache.org/struts-taglib/tlddoc/html/frame.html
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [WebWork2] TODO
Posted by Craig McClanahan <cr...@apache.org>.
On 3/27/06, Frank W. Zammetti <fz...@omnytex.com> wrote:
>
> On Mon, March 27, 2006 9:22 am, Joe Germuska said:
> > I wonder if there's a way to generalize an "API" out of these so that
> > we are less bound to an implementation. Certainly, a date picker or
> > rich text field which ultimately just ends up setting a value of a
> > single form field should be not too hard to generalize, although I
> > haven't looked at all the models for integrating JS widgets into a
> > page neatly. I guess there are also issues of triggering the
> > widgets, etc.
>
> Generalize an API out of GUI widgets?
>
> Where's Craig with the JSF plug when you need him?!? :-) LOL
Ask and ye shall receive :-) [1]
Seriously, wrapping DOJO widgets (using whatever technology you like on the
server side) is a heck of a lot more fun than writing all that javascript
yourself, as long as the underlying widget does what you need. I'm
currently playing with a JSF component wrapper for DOJO's rich text editing
capability. Took about an hour to do the wrapping -- the only issues I've
got relate to the widget implementation itself (doesn't support scrollbars,
and problems hooking in to the Save and Cancel events where I want to).
I've also seen people try to generalize *all* DOJO widgets with a single JSP
tag API. This is a lot more practical in JSP 2.0, where you can declare a
tag that takes arbitrary parameters. But I worry about usability issues of
a single tag like this, because you effectively have a "mode" of operation
for every widget (which would each only recognize only a subset of the
overall set of attributes). We have small examples of this sort of thing
all over the Struts tag library ... just for an example, try to explain to a
newbie what combination of attributes to use on an <html:frame> tag[2] when
you want to pass parameters in.
Wrapping is good, but I've come to believe in "one tag (or equivalent for
your favorite technology) per use case" is better than "one size fits all".
Frank
Craig
[1]
http://blogs.sun.com/roller/page/edwingo?entry=component_authoring_for_creator
[2] http://struts.apache.org/struts-taglib/tlddoc/html/frame.html
Re: [WebWork2] TODO
Posted by Joe Germuska <Jo...@Germuska.com>.
At 9:59 AM -0500 3/27/06, Frank W. Zammetti wrote:
>On Mon, March 27, 2006 9:22 am, Joe Germuska said:
>> I wonder if there's a way to generalize an "API" out of these so that
>> we are less bound to an implementation. Certainly, a date picker or
>> rich text field which ultimately just ends up setting a value of a
>> single form field should be not too hard to generalize, although I
>> haven't looked at all the models for integrating JS widgets into a
>> page neatly. I guess there are also issues of triggering the
>> widgets, etc.
>
>Generalize an API out of GUI widgets?
>
>Where's Craig with the JSF plug when you need him?!? :-) LOL
:)
But what I'm talking about here is a JavaScript API -- basically
something that manages the discovery process for a widget
implementation, like JAXP does for XML parsing and transformation.
maybe i'll float this question on the Dojo list...
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: [WebWork2] TODO
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
On Mon, March 27, 2006 9:22 am, Joe Germuska said:
> I wonder if there's a way to generalize an "API" out of these so that
> we are less bound to an implementation. Certainly, a date picker or
> rich text field which ultimately just ends up setting a value of a
> single form field should be not too hard to generalize, although I
> haven't looked at all the models for integrating JS widgets into a
> page neatly. I guess there are also issues of triggering the
> widgets, etc.
Generalize an API out of GUI widgets?
Where's Craig with the JSF plug when you need him?!? :-) LOL
Frank
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [WebWork2] TODO
Posted by Craig McClanahan <cr...@apache.org>.
On 3/27/06, Ted Husted <te...@gmail.com> wrote:
>
> On 3/27/06, Michael Jouravlev <jm...@gmail.com> wrote:
> > On 3/27/06, Gabe <gj...@yahoo.com> wrote:
> > > for the tag prefix, I am actually thinking "html" might be best.
> > > While Struts Action 2 is supposed to be a "revolution" in order
> > > for us to keep the community behind it, we ought to make it
> > > seem as much of an "evolution" as possible. (Otherwise, why
> > > wouldn't a struts developer look at this as the opportunity to try
> > > something completely different?) Therefore, I think using html
> > > for the ww form tags etc would be ideal.
> >
> > I like "html" prefix especially if the taglib could be portable to,
> > say, SAF 1.3 or even to plain JSP environment.
>
> Noted.
As we all know, the prefix that is actually used is up to the individual
developer, but most of them tend to copy our examples :-).
If I were a Struts 1.x user, and saw the "html" prefix on SAF 2.x tags, I
would expect the functionality to be fundamentally similar. If that's what
ends up happening, then this is a pretty good suggestion. But I fear it
would be confusing if the tags are radically different (i.e. improved :-).
ISTR there was also an idea floating around some of the early discussions
that SAF 2.x might want to support the Struts 1.x tags as a "legacy"
library, similar in spirit to creating a compatibility layer to talk to
Struts 1.x action classes. If that path was followed, it would make more
sense to keep "html" for this library and use something else for the new
one.
> I suggest to analyze all tags and to deprecate everything that is
> > already supported in JSTL 1.0. WW features that duplicate features of
> > JSTL 1.1 should be considered "half-deprecated" since a lot of people
> > still use Tomcat4 (my provider quoted me $50 for upgrade to Tomcat5,
> > nah). JSP 2.0 has new features like resource messages support, SAF2
> > should promote using these more generic J2EE features instead of
> > proprietary tags and property files.
>
> The tags are listed here, Michael, if you'd lke to run through them.
>
> * http://wiki.opensymphony.com/display/WW/Tags
>
> The UI tags are quite a bit different that the Action 1 taglibs. Aside
> from generating markup, many also observe a stylesheet, giving them
> capabilities beyond what is offered with JSTL alone. The UI tags are
> also value-stack aware, allowing expressions that are not supported by
> standard JSTL. Though, I understand that the UI tags are JSTL aware
> and be mixed-and-matched with JSTL tags, as needed.
>
>
> > SAF2 should also make clear what platform it targets. Stripes, for
> > example, uses Java5 specifically for annotations and other internal
> > niceties like typed collections. Should SAF2 target JDK1.4 or Java5?
> > Should it target JSP1.2+JSTL1.0 or JSP2.0? I think that JSP2.0 is a
> > better target and JSP pages are much cleaner, but there should be
> > compatibility package for JSP1.2, kind of like Tomcat5 has for JDK1.4.
>
> Webwork 2.2 targetrs JDK 1.4, and I would suggest we stay that course,
> since I believe it it what most of the committers, including myself,
> are using in production. The UI tags look and feel like ordinary JSP
> tags, under the covers, the markups is being created with FreeMarker
> templates. (See same reference.)
>
> Meanwhlie, some work is being done on Java 5 extensions. I believe
> Shale is doing the same.
>
> * http://wiki.opensymphony.com/display/WW/J2SE+5+Support
Shale's current annotations are described here[1] -- see subpackages
"managed", "register", and "view". However, most of them are pretty
specific to JSF at the moment.
One thing I'd also like to look at is integrating XWork interceptor stacks
directly into Shale, at both the local (calling a particular action method)
and global (in the application controller filter, where you can currently
customize the "all requests" processing with Commons Chain) locations. If
that works out, then it should be possible to use any XWork-based
annotations directly.
In another thread, there was talk about using a consistent approach to
> annotations between Shale, Action 2, and Stecks (Action 1 -
> http://www.realsolve.co.uk/site/strecks/).
>
> Though, I think ideas for new developmen tmight better be discussed
> once the codebase clears the Incubator.
>
> -Ted
Craig
[1]
http://struts.apache.org/struts-shale/shale-tiger/apidocs/overview-summary.html
Re: [WebWork2] TODO
Posted by Michael Jouravlev <jm...@gmail.com>.
On 3/27/06, Ted Husted <te...@gmail.com> wrote:
> On 3/27/06, Michael Jouravlev <jm...@gmail.com> wrote:
> > I suggest to analyze all tags and to deprecate everything that is
> > already supported in JSTL 1.0.
>
> The tags are listed here, Michael, if you'd lke to run through them.
>
> * http://wiki.opensymphony.com/display/WW/Tags
>
> The UI tags are quite a bit different that the Action 1 taglibs. Aside
> from generating markup, many also observe a stylesheet, giving them
> capabilities beyond what is offered with JSTL alone.
I did not quite get that. Do you mean CSS stylesheet? I started
reading the WebWork book, but then put it aside, shame on me. So I am
not versed in WebWork yet. Anyway, CSS support is not a problem in
SAF1 tags either.
> The UI tags are
> also value-stack aware, allowing expressions that are not supported by
> standard JSTL.
I see. Considering that ValueStack is just a tree-like object
containing beans, I would prefer a very small set of tags to
put/remove ValueStack to a certain scope, and then access its
properties using standard JSTL expressions, if this is possible. I
thought that OGNL expressions are evaluated on a whole page like
JSP2.0 expressions, not within specific tags only. I guess I was
wrong. Would be great if OGNL expressions could be used anywhere on a
page, so I had to use as few WW-specific tags as possible.
> The UI tags look and feel like ordinary JSP
> tags, under the covers, the markups is being created with FreeMarker
> templates. (See same reference.)
I hope that plain JSP is still an option. I will try to find time to
finish the book ;-) Thanks for the heads up.
Michael.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [WebWork2] TODO
Posted by Ted Husted <te...@gmail.com>.
On 3/27/06, Michael Jouravlev <jm...@gmail.com> wrote:
> On 3/27/06, Gabe <gj...@yahoo.com> wrote:
> > for the tag prefix, I am actually thinking "html" might be best.
> > While Struts Action 2 is supposed to be a "revolution" in order
> > for us to keep the community behind it, we ought to make it
> > seem as much of an "evolution" as possible. (Otherwise, why
> > wouldn't a struts developer look at this as the opportunity to try
> > something completely different?) Therefore, I think using html
> > for the ww form tags etc would be ideal.
>
> I like "html" prefix especially if the taglib could be portable to,
> say, SAF 1.3 or even to plain JSP environment.
Noted.
> I suggest to analyze all tags and to deprecate everything that is
> already supported in JSTL 1.0. WW features that duplicate features of
> JSTL 1.1 should be considered "half-deprecated" since a lot of people
> still use Tomcat4 (my provider quoted me $50 for upgrade to Tomcat5,
> nah). JSP 2.0 has new features like resource messages support, SAF2
> should promote using these more generic J2EE features instead of
> proprietary tags and property files.
The tags are listed here, Michael, if you'd lke to run through them.
* http://wiki.opensymphony.com/display/WW/Tags
The UI tags are quite a bit different that the Action 1 taglibs. Aside
from generating markup, many also observe a stylesheet, giving them
capabilities beyond what is offered with JSTL alone. The UI tags are
also value-stack aware, allowing expressions that are not supported by
standard JSTL. Though, I understand that the UI tags are JSTL aware
and be mixed-and-matched with JSTL tags, as needed.
> SAF2 should also make clear what platform it targets. Stripes, for
> example, uses Java5 specifically for annotations and other internal
> niceties like typed collections. Should SAF2 target JDK1.4 or Java5?
> Should it target JSP1.2+JSTL1.0 or JSP2.0? I think that JSP2.0 is a
> better target and JSP pages are much cleaner, but there should be
> compatibility package for JSP1.2, kind of like Tomcat5 has for JDK1.4.
Webwork 2.2 targetrs JDK 1.4, and I would suggest we stay that course,
since I believe it it what most of the committers, including myself,
are using in production. The UI tags look and feel like ordinary JSP
tags, under the covers, the markups is being created with FreeMarker
templates. (See same reference.)
Meanwhlie, some work is being done on Java 5 extensions. I believe
Shale is doing the same.
* http://wiki.opensymphony.com/display/WW/J2SE+5+Support
In another thread, there was talk about using a consistent approach to
annotations between Shale, Action 2, and Stecks (Action 1 -
http://www.realsolve.co.uk/site/strecks/).
Though, I think ideas for new developmen tmight better be discussed
once the codebase clears the Incubator.
-Ted
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [WebWork2] TODO
Posted by Michael Jouravlev <jm...@gmail.com>.
On 3/27/06, Gabe <gj...@yahoo.com> wrote:
> for the tag prefix, I am actually thinking "html" might be best.
> While Struts Action 2 is supposed to be a "revolution" in order
> for us to keep the community behind it, we ought to make it
> seem as much of an "evolution" as possible. (Otherwise, why
> wouldn't a struts developer look at this as the opportunity to try
> something completely different?) Therefore, I think using html
> for the ww form tags etc would be ideal.
I like "html" prefix especially if the taglib could be portable to,
say, SAF 1.3 or even to plain JSP environment.
I suggest to analyze all tags and to deprecate everything that is
already supported in JSTL 1.0. WW features that duplicate features of
JSTL 1.1 should be considered "half-deprecated" since a lot of people
still use Tomcat4 (my provider quoted me $50 for upgrade to Tomcat5,
nah). JSP 2.0 has new features like resource messages support, SAF2
should promote using these more generic J2EE features instead of
proprietary tags and property files.
SAF2 should also make clear what platform it targets. Stripes, for
example, uses Java5 specifically for annotations and other internal
niceties like typed collections. Should SAF2 target JDK1.4 or Java5?
Should it target JSP1.2+JSTL1.0 or JSP2.0? I think that JSP2.0 is a
better target and JSP pages are much cleaner, but there should be
compatibility package for JSP1.2, kind of like Tomcat5 has for JDK1.4.
On 3/27/06, Joe Germuska <Jo...@germuska.com> wrote:
> At 7:39 AM -0500 3/27/06, Ted Husted wrote:
> >tabbedpane.vm Archived UI template
> >* Is this a server-side compoonent, or is there a Dojo equivalent?
>
> I'm not sure what this is -- is it this?
> http://archive.dojotoolkit.org/nightly/tests/widget/test_TabPane.html
>
> I've used Dojo tabs in an application satisfactorily. A
> rearchitecture of the implementation introduced some problems, so I
> forked the original implementation into my own widget package and
> soldiered on. I'm not enough of a JS/DHTML whiz to understand why my
> page looked wrong in the new tab implementation, but it was an
> awfully complicated page.
Would be great to see an example of how tabbed panes work with forms
and buttons inside the panels.
Michael.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [WebWork2] TODO
Posted by Joe Germuska <Jo...@Germuska.com>.
At 7:39 AM -0500 3/27/06, Ted Husted wrote:
>STATUS update
>----
>
>DISTRIBUTION RIGHTS - LICENSING
>
>JSCalendar for the DatePicker tag
>* Rene will contact author about license change
>* There may also be a Dojo equivalent
Dojo has a date picker:
http://archive.dojotoolkit.org/nightly/tests/widget/test_DatePicker.html
it is somewhat less fully featured than JSCalendar. I haven't used
it in an app. JSCalendar has worked well for me in other apps, but I
haven't gotten very deeply into how it works nor have I investigated
integrating it with JSP tags.
>FCKEditor for the Richtexteditor tag
>* Is there a Dojo equivalent?
Dojo does have a rich text editor:
http://dojotoolkit.org/docs/rich_text.html
http://blog.dojotoolkit.org/2005/11/07/new-editor-widget-explained
http://archive.dojotoolkit.org/nightly/tests/widget/test_Editor.html
I've actually not yet had cause to apply a RTE in an application.
>Walter Zorns tooltip library for all UI Tags
>* Is there a Dojo equivalent?
I'm pretty sure there is not.
>tabbedpane.vm Archived UI template
>* Is this a server-side compoonent, or is there a Dojo equivalent?
I'm not sure what this is -- is it this?
http://archive.dojotoolkit.org/nightly/tests/widget/test_TabPane.html
I've used Dojo tabs in an application satisfactorily. A
rearchitecture of the implementation introduced some problems, so I
forked the original implementation into my own widget package and
soldiered on. I'm not enough of a JS/DHTML whiz to understand why my
page looked wrong in the new tab implementation, but it was an
awfully complicated page.
I wonder if there's a way to generalize an "API" out of these so that
we are less bound to an implementation. Certainly, a date picker or
rich text field which ultimately just ends up setting a value of a
single form field should be not too hard to generalize, although I
haven't looked at all the models for integrating JS widgets into a
page neatly. I guess there are also issues of triggering the
widgets, etc.
Hope this helps.
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: [WebWork2] TODO
Posted by tm jee <tm...@yahoo.co.uk>.
Hi Ted & Friends,
I could contact the author of FCKEditor and Walter Zorns tooltip library about a license change or possible dual licensing. Will post back when I got any information.
rgds
Ted Husted <te...@gmail.com> wrote: STATUS update
----
DISTRIBUTION RIGHTS - LICENSING
JSCalendar for the DatePicker tag
* Rene will contact author about license change
* There may also be a Dojo equivalent
FCKEditor for the Richtexteditor tag
* Is there a Dojo equivalent?
Walter Zorns tooltip library for all UI Tags
* Is there a Dojo equivalent?
tabbedpane.vm Archived UI template
* Is this a server-side compoonent, or is there a Dojo equivalent?
----
DISTRIBUTION RIGHTS - COPYRIGHT HOLDERS
Has "Open Symphony Group" filed a software grant?
Has "ePlus Corporation" filed a software grant or CCLA for Jason?
----
NAMING CONVENTIONS
Option 1:
- com.opensymphony.webwork package -> org.apache.struts.ti
- WebWork* classes -> Struts*
- WebWork in comments, documentation -> Struts Action 2
- webwork. as the configuration properties prefix -> struts.
- ww: tag prefix -> a:
+1 Martin Cooper (binding)
+0 Don Brown (binding)
+1 Frank Zammetti (non-binding)
Option 2:
- com.opensymphony.webwork package -> org.apache.struts.action2
- WebWork* classes -> Struts*
- WebWork in comments, documentation -> Struts Action 2
- webwork. as the configuration properties prefix -> struts.
- ww: tag prefix -> a:/saf:
+1 Rainer Hermanns, Ted Husted, Alexandru Popescu, Rene Gielen, Don
Brown (binding)
+0 Toby Jee, Hubert Rabago, Craig McClanahan (binding)
+1 Paul Benedict, Michael Jouravlev (non-binding)
Option 3:
- com.opensymphony.webwork package -> org.apache.web or .webwork
- WebWork in comments, documentation -> Struts Action 2
- webwork. as the configuration properties prefix -> web or webwork
- else, remains the same
+0 Joe Germuska, Ted Husted (binding)
+1 Gabe (non-binding)
----
MIGRATE XWORK NOW (see "[Struts Tt] Xwork?")
+1 Gabe
----
At this point, I'll move the STATUS notes to a file in the repository,
where it will be easier to track and maintain as a group.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
---------------------------------
Yahoo! Photos NEW, now offering a quality print service from just 8p a photo.
Re: [WebWork2] TODO
Posted by Gabe <gj...@yahoo.com>.
Ted,
What you have written below is not what I have suggested. I suggested:
- com.opensymphony.webwork package -> org.apache.struts.web
- WebWork* classes -> Web*
- WebWork in comments, documentation -> Struts Action 2
- webwork. as the configuration properties prefix -> struts.
- ww: tag prefix -> web
However, personally for the tag prefix, I am actually thinking "html" might be best. While Struts Action 2 is supposed to be a "revolution" in order for us to keep the community behind it, we ought to make it seem as much of an "evolution" as possible. (Otherwise, why wouldn't a struts developer look at this as the opportunity to try something completely different?) Therefore, I think using html for the ww form tags etc would be ideal.
I am not for naming that would keep webwork in any of the class names / file names.
Thanks,
Gabe
----- Original Message ----
From: Ted Husted <te...@gmail.com>
To: Struts Developers List <de...@struts.apache.org>
Sent: Monday, March 27, 2006 7:39:15 AM
Subject: Re: [WebWork2] TODO
STATUS update
----
DISTRIBUTION RIGHTS - LICENSING
JSCalendar for the DatePicker tag
* Rene will contact author about license change
* There may also be a Dojo equivalent
FCKEditor for the Richtexteditor tag
* Is there a Dojo equivalent?
Walter Zorns tooltip library for all UI Tags
* Is there a Dojo equivalent?
tabbedpane.vm Archived UI template
* Is this a server-side compoonent, or is there a Dojo equivalent?
----
DISTRIBUTION RIGHTS - COPYRIGHT HOLDERS
Has "Open Symphony Group" filed a software grant?
Has "ePlus Corporation" filed a software grant or CCLA for Jason?
----
NAMING CONVENTIONS
Option 1:
- com.opensymphony.webwork package -> org.apache.struts.ti
- WebWork* classes -> Struts*
- WebWork in comments, documentation -> Struts Action 2
- webwork. as the configuration properties prefix -> struts.
- ww: tag prefix -> a:
+1 Martin Cooper (binding)
+0 Don Brown (binding)
+1 Frank Zammetti (non-binding)
Option 2:
- com.opensymphony.webwork package -> org.apache.struts.action2
- WebWork* classes -> Struts*
- WebWork in comments, documentation -> Struts Action 2
- webwork. as the configuration properties prefix -> struts.
- ww: tag prefix -> a:/saf:
+1 Rainer Hermanns, Ted Husted, Alexandru Popescu, Rene Gielen, Don
Brown (binding)
+0 Toby Jee, Hubert Rabago, Craig McClanahan (binding)
+1 Paul Benedict, Michael Jouravlev (non-binding)
Option 3:
- com.opensymphony.webwork package -> org.apache.web or .webwork
- WebWork in comments, documentation -> Struts Action 2
- webwork. as the configuration properties prefix -> web or webwork
- else, remains the same
+0 Joe Germuska, Ted Husted (binding)
+1 Gabe (non-binding)
----
MIGRATE XWORK NOW (see "[Struts Tt] Xwork?")
+1 Gabe
----
At this point, I'll move the STATUS notes to a file in the repository,
where it will be easier to track and maintain as a group.
-Ted.
---------------------------------------------------------------------
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: [WebWork2] TODO
Posted by Ted Husted <te...@gmail.com>.
STATUS update
----
DISTRIBUTION RIGHTS - LICENSING
JSCalendar for the DatePicker tag
* Rene will contact author about license change
* There may also be a Dojo equivalent
FCKEditor for the Richtexteditor tag
* Is there a Dojo equivalent?
Walter Zorns tooltip library for all UI Tags
* Is there a Dojo equivalent?
tabbedpane.vm Archived UI template
* Is this a server-side compoonent, or is there a Dojo equivalent?
----
DISTRIBUTION RIGHTS - COPYRIGHT HOLDERS
Has "Open Symphony Group" filed a software grant?
Has "ePlus Corporation" filed a software grant or CCLA for Jason?
----
NAMING CONVENTIONS
Option 1:
- com.opensymphony.webwork package -> org.apache.struts.ti
- WebWork* classes -> Struts*
- WebWork in comments, documentation -> Struts Action 2
- webwork. as the configuration properties prefix -> struts.
- ww: tag prefix -> a:
+1 Martin Cooper (binding)
+0 Don Brown (binding)
+1 Frank Zammetti (non-binding)
Option 2:
- com.opensymphony.webwork package -> org.apache.struts.action2
- WebWork* classes -> Struts*
- WebWork in comments, documentation -> Struts Action 2
- webwork. as the configuration properties prefix -> struts.
- ww: tag prefix -> a:/saf:
+1 Rainer Hermanns, Ted Husted, Alexandru Popescu, Rene Gielen, Don
Brown (binding)
+0 Toby Jee, Hubert Rabago, Craig McClanahan (binding)
+1 Paul Benedict, Michael Jouravlev (non-binding)
Option 3:
- com.opensymphony.webwork package -> org.apache.web or .webwork
- WebWork in comments, documentation -> Struts Action 2
- webwork. as the configuration properties prefix -> web or webwork
- else, remains the same
+0 Joe Germuska, Ted Husted (binding)
+1 Gabe (non-binding)
----
MIGRATE XWORK NOW (see "[Struts Tt] Xwork?")
+1 Gabe
----
At this point, I'll move the STATUS notes to a file in the repository,
where it will be easier to track and maintain as a group.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [WebWork2] TODO
Posted by Rene Gielen <gi...@it-neering.net>.
Ted, others,
I would volunteer to ask for license changes at least for jscalendar,
but I can do the others as well - if there is no one around who has
existing links to the said projects and / or their representatives
making it easier to "get through" (which I do not have explicitely).
Regards,
Rene
Ted Husted schrieb:
>The big item on the Incubator TODO list is verifying distribution
>rights. The items here are
>
>(1) Verify that the files that have been donated have been updated to
>reflect the new ASF copyright.
>
>(2) Verify that for all code included with the distribution that is
>not under the Apache license, we have the right to combine with
>Apache-licensed code and redistribute.
>
>(3) Verify that all source code distributed by the project is covered
>by one or more of the following approved licenses: Apache, BSD,
>Artistic, MIT/X, MIT/W3C, MPL 1.1, or something with essentially the
>same terms.
>
>----
>
>As to (3), in another thread Rainer cited at least four components
>that we need to be address
>
>* JSCalendar for the DatePicker tag
>
>* FCKEditor for the Richtexteditor tag
>
>* Walter Zorns tooltip library for all UI Tags
>
>* tabbedpane.vm Archived UI template
>
>Martin suggested that there may be DOJO equivalents for all four of
>these. (Unless tabbed pane is server-side.)
>
>Is anyone planning on checking on these yet?
>
>----
>
>As to (2), if we resolve (3), will there be any other *code* that
>would not be under the ASF.
>
>As to (1), I scanned the Java source for copright statements. We seem
>to be in pretty good shape. Most of those that have copyright
>statements run to "Open Symphony Group". But, there are a few
>exceptions.
>
>* Copyright (c) 2005 ePlus Corporation (SessionContextAutowiringInterceptor)
>* Copyright (C) NanoContainer Organization (org.apache.struts.action2.pico)
>* Copyright (c) 2005 Your Corporation.
>
>Well, the last one, I think we can safely ignore :)
>
>I believe the first one is Jason's employer. If possible, it would be
>great if we could get a software grant or CCLA to cover this class.
>
>Meanwhile, has the software grant for "Open Symphony Group" gone on
>file yet? I looked but I didn't see it.
>
>-----
>
>As to the package naming, did anyone want to change their vote to
>followup on Gabe's suggestion? Otherwise, it looks like the
>conventions suggested by Rainer have the most support.
>
>I don't know if we want to bring XWork into the ASF now, later, or
>never. Of course, it's a great package and I'm sure we'd love to have
>it, if the XWork developers would like to donate and support it.
>
>There would also be the question of whether XWork is something that we
>would maintain here, or whether we might want to propose it to the
>Jakarta Commons, where it might find a broader audience.
>
>-Ted.
>
>---------------------------------------------------------------------
>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