Mailing-List: contact dev-help@beehive.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Beehive Developers" <dev@beehive.apache.org>
Received-SPF: pass (asf.osuosl.org: domain of ekoneil@gmail.com designates
 66.249.82.198 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=F5pO7t8StoZsJbNxuC6LfTZpIU6Q5551wkzd5Ep5t2g21PzFxVD15552nMxtDA6CF7f+WfJfnB3gXKxhLhJzzAdHl9/pg4bNqhaXiUSczkWtox8pNBZ8AGcj7enCTM75Q433oYm064D10IvgsYAIYKjuuSSR+tL3ESukoYWYiI8=
Message-ID: <e9ac83540602260920p402c7800ja9c36d20eef806b7@mail.gmail.com>
Date: Sun, 26 Feb 2006 10:20:48 -0700
From: "Eddie O'Neil" <ekoneil@gmail.com>
To: "Beehive Developers" <dev@beehive.apache.org>
Subject: Re: Javascript Issue
In-Reply-To: <40f026540602250522w892a346g85f39e7f10ec5497@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
References: <40f026540602250522w892a346g85f39e7f10ec5497@mail.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.=20
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 <dolander@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 i=
n a
> backward compatible way, where if the current .js file is not updated, th=
e
> 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 backw=
ard
> 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.xrele=
ase.
>
> 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?
>
>