You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@beehive.apache.org by Daryl Olander <do...@gmail.com> on 2006/02/25 14:22:28 UTC

Javascript Issue

I've been working on some features related to the low level support for
AJAX.  In the 1.0 release, the Tree and DivPanel are both AJAX enabled.
There are some low level features in NetUI to handle AJAX requests (.xhr)
and route the requests to objects that handle the requests.  The feature
work I'm currently working on provides plug points into these features so
more advanced handling by framework level code can be done.

The issue is that to do this, I'm going to need to change the JavaScript for
the Tree and DivPanel.  The .js file being changed is found in the webapp.
The current design is that these live in
resources/beehive/version1/javascript.  Optimally, I can do this change in a
backward compatible way, where if the current .js file is not updated, the
tree and AJAX continue to work.  I haven't yet made this work however.  I'm
a bit afraid that if I can't do this, then we would be faced with a backward
incompatible change based upon feature work.  In my mind means this is
feature work that should be targeted to a 1.1 release and not a 1.0.xrelease.

This may be the first time that updating a webapp means more than simply
replacing the .jar files.  Is it sufficient to put this into the readme
associated with the release?

Thoughts?

Re: Javascript Issue

Posted by Eddie O'Neil <ek...@gmail.com>.
  Hm; this is a good question.  It's inevitable that bugs will come up
in framework provided JavaScript files and that those bugs will be
fixed in patch releases.

  Independent of the versions involved (major, minor, patch), if an
application upgrades its runtime JARs, then other files may need to be
upgraded as well.  For example, if we shipped loose TLDs and expected
those to be in WEB-INF/, they might need to be upgraded if a tag bug
was fixed, rtexprvalue enabled / disabled, etc.  So, that would
require a change in the JARs *and* in some descriptor file.

  We could treat the JavaScript files the same way in that they need
to be kept in sync with an application's version of the framework. 
Unlike the TLDs, they just don't have a convenient packaging mechansim
(the taglib JAR file) and instead sit loose as resources in the web
application.  Documenting the steps needed to upgrade from one version
to the next seems reasonable.

  Some questions, though.  Are these internal changes to the
JavaScript API?  Or are they API incompatible changes?  Do we want to
maintain API compatibility for a patch release and deprecate the "old"
APIs for removal in the next point release?

  I don't have a strong opinion as to the version number for the next
release.  As it stands, we've got a minor security fix in trunk/ that
probably should ship soon-ish as part of some release (1.0.2?).

Eddie


On 2/25/06, Daryl Olander <do...@gmail.com> wrote:
> I've been working on some features related to the low level support for
> AJAX.  In the 1.0 release, the Tree and DivPanel are both AJAX enabled.
> There are some low level features in NetUI to handle AJAX requests (.xhr)
> and route the requests to objects that handle the requests.  The feature
> work I'm currently working on provides plug points into these features so
> more advanced handling by framework level code can be done.
>
> The issue is that to do this, I'm going to need to change the JavaScript for
> the Tree and DivPanel.  The .js file being changed is found in the webapp.
> The current design is that these live in
> resources/beehive/version1/javascript.  Optimally, I can do this change in a
> backward compatible way, where if the current .js file is not updated, the
> tree and AJAX continue to work.  I haven't yet made this work however.  I'm
> a bit afraid that if I can't do this, then we would be faced with a backward
> incompatible change based upon feature work.  In my mind means this is
> feature work that should be targeted to a 1.1 release and not a 1.0.xrelease.
>
> This may be the first time that updating a webapp means more than simply
> replacing the .jar files.  Is it sufficient to put this into the readme
> associated with the release?
>
> Thoughts?
>
>