Cool. Thanks.
On Thu, Jun 17, 2010 at 18:41, Greg Brown wrote:
> OK, it didn't look too bad so I went ahead and checked it in. I didn't end up
> doing it exactly as you suggested, but the end result should be the same (I
> pass the internal processing namespace prefix and the annotation class t
OK, it didn't look too bad so I went ahead and checked it in. I didn't end up
doing it exactly as you suggested, but the end result should be the same (I
pass the internal processing namespace prefix and the annotation class to the
BeanSerializer constructor, so BeanSerializer doesn't need to kn
It is feasible, but then developers would need to know that they need to add
this JAR to their classpath. I was thinking we'd just deprecate WTKXSerializer
and @WTKX - that way you'll know as soon as you compile that you should
upgrade, but at least your app will run.
On Jun 17, 2010, at 10:42
Would it be feasible to release a pivot-compat.jar that could include
support for older wtkx files while still making it pretty clear this
is not standard?
On Thu, Jun 17, 2010 at 10:35 AM, Greg Brown wrote:
> Yeah, OK. The main problem is that many developers aren't going to read the
> release
Yeah, OK. The main problem is that many developers aren't going to read the
release notes, and they won't know why their app suddenly doesn't compile.
There's an easy fix, but it would be good to avoid that initial frustration if
possible.
Let me prototype it and see how it looks.
On Jun 17,
Hi
It's the difference between
(a) having to do a big-bang conversion when switching to Pivot2.0
and
(b) being able to get things running quickly, and then make the updates
piece-meal.
Personally, I have no real problem either way, because I don't have any
WTKX files to convert of my own.
I just
I understand the desire to provide a more "backwards-compatible" solution.
However, I see two main issues with it:
1) As you noted, it is still a bit of a hack, even if we do something along the
lines of what you suggest.
2) It provides an incentive for developers to not update their code to us
Hi
I had an idea while out cycling yesterday.
How about we add code that looks something like this:
for (java.lang.annotation.Annotation ann :
field.getAnnotations()) {
if
(ann.annotationType().getName().equals("org.apache.pivot.wtkx.WTKX")) {
p
Hi to all,
from me no objections to put this change in 2.0 (2.0 will be a major change
in many things, so drop the backward compatibility also on this part
shouldn't be a problem).
And to avoid unwanted complicated code, I'd suggest to NOT add
transition/translation annotation or code that could
:10 AM
To: dev@pivot.apache.org
Subject: Re: Pivot 1.6->2.0
> a) Create a new serializer resource naming approach that does not use file
> extensions and they are automatically appended when the user specifies a
> string for a resource location.
Sounds a bit complicated, and may see
> a) Create a new serializer resource naming approach that does not use file
> extensions and they are automatically appended when the user specifies a
> string for a resource location.
Sounds a bit complicated, and may seem foreign to many developers (myself
included). Also may have hidden negat
ncing* changes that can make it easier once 2.0 hits and perhaps this
should be the target now.
-Original Message-
From: Greg Brown [mailto:gkbr...@mac.com]
Sent: Tuesday, June 15, 2010 8:12 AM
To: dev@pivot.apache.org
Subject: Re: Pivot 1.6->2.0
That's the problem - we can
That's the problem - we can't easily support backwards compatibility. I had
originally hoped to have WTKXSerializer extend BeanSerializer in Pivot 1.6, and
then drop WTKXSerializer in 2.0. However, we can't do that with @WTKX/@BXML,
because annotations can't inherit. So, we're kind of stuck with
Sure, but surely we can provide aliases for those things internally so
existing files continue to work?
Maybe with a runtime warning to System.out so people know that they need
to upgrade at some point.
It just seems a little harsh to dump that amount of work on people when
we can reasonably easi
Files with a .wtkx extension will still work fine. However, the "wtkx"
namespace prefix will change to "bxml", the annotation will change to @BXML,
and the serializer will change to BeanSerializer, so for consistency I think
we'd want to recommend changing the file extension as well.
Greg
On J
Hi
I don't have a problem with the version numbering, but is there any
reason why you can't continue to support the WTKX extension for
backwards compatibility?
-- Noel
On Mon, Jun 14, 2010 at 02:13, Greg Brown wrote:
> Hi all,
>
> I'd really like to refactor WTKXSerializer to BeanSerializer and
Hi all,
I'd really like to refactor WTKXSerializer to BeanSerializer and move it to
Pivot Core for the next release. However, I think this change is too disruptive
for the 1.x line. As a developer, I don't think I would be too pleased to
discover that I need to update all of my WTKX files to BX
17 matches
Mail list logo
