portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Sean Taylor <d.tay...@onehippo.com>
Subject Re: Other toolkits
Date Fri, 27 Nov 2009 17:14:02 GMT

On Nov 27, 2009, at 5:14 AM, Gonzalo Aguilar Delgado wrote:

> First of all... I know that this proposition doubles work...
>

Double work, double bugs, and then when you decide to go off and do  
something else when you get bored with this project, double  
maintenance for me. And not only a zero feature gain, but a negative  
feature gain since the work you could be doing on features (developed  
in collaboration between all developers) is instead "wasted" (I say  
wasted from the team POV) on duplicating everything. We are a small  
team.

Sorry, thats just my POV, and maybe some fear from getting burnt in  
the past by people who are gung-ho one day, and disappear the next. I  
try to put the project quality first.

> But can at least leave door open for other AJAX toolkits?
>
Point taken. What I will do is investigate introducing a Jetspeed  
Javascript API layer, so all high level Javascript operations are  
programmed against a higher level Javascript API, minimizing  
dependencies on one Javascript library. If we are going to put in this  
layer, we need to closely consider the costs/benefits. The costs to  
consider are flexibility, bugs introduced by layering and delegating  
everything, introducing yet another programming api, and feature work  
not being implemented due to time spent writing layer and delegate  
code -- all against the benefits, which you should talk more about...

> I mean, it would be nice if ajax implementation doesn't rely on only  
> one
> toolkit or implementation. So others can implement their own.
>

I should point out that the AJAX Customizations API is callable from  
any Javascript library. So you are free to implement your own client  
side code from that POV

> Maybe I can propone patches to leave door open to other toolkits and
> make
> jetspeed interface generic...
>
Lets discuss it more. Now that I am beginning to learn about your what  
you want to do, there are a few coordination improvements we need to  
make:

1. I have an in-progress issue I am actively working on.  https://issues.apache.org/jira/browse/JS2-1084)

. I would like the opportunity to contribute too, with your approval  
of course...

2. Your patches are going to be out of date. I am working and  
committing as I go on a documented JIRA issue. If you want to work on  
any part of this issue, you need to work closer with me and we can  
decide who works on what so we don't have conflicts and so that we can  
coordinate and collaborate on the work. I would very much like to  
collaborate with you on this work, please do not misinterpret my  
caution to jump on the 'layering API approach' before analyzing the  
costs/benefits as something else.




---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org


Mime
View raw message