7:46 p.m.
The onevent attribute of <f:ajax> can be used to specify a JS function to
monitor Ajax calls, which is all well and good. However, the data payload
(I'm not sure why we have to refer to it as a payload), seems strange
because:
1. data.type is always "event". What's the point of that?!?
2. data.name is really the status of the Ajax request. Using "name" for the
property seems meaningless. Name of what?
3. does it make sense to give the page author access to the actual
XMLHttpRequest object via the data payload? data.xhr, for example?
Thanks,
david
5:52 a.m.
On 5/23/09 10:46 AM, David Geary wrote:
The onevent attribute of <f:ajax> can be used to specify a JS
function
to monitor Ajax calls, which is all well and good. However, the data
payload (I'm not sure why we have to refer to it as a payload), seems
strange because:
1. data.type is always "event". What's the point of that?!?
Sometimes, it's error. See the jsf-demo/ajax-queue demo for an example
that uses this interchangeably.
2. data.name <http://data.name> is really the status of the
Ajax
request. Using "name" for the property seems meaningless. Name of what?
The name of the event. Or, the name of the error. The spec lists them
- there are only a few to choose from. I'm afraid I don't understand
your objection.
3. does it make sense to give the page author acdcess to the actual
XMLHttpRequest object via the data payload? data.xhr, for example?
Is your objection that they could modify the object? Since this is
JavaScript, they can already modify darn near everything anyway. We
could always deliver them a copy of the object, I suppose...
Jim
7:58 p.m.
On Sat, May 23, 2009 at 11:52 PM, Jim Driscoll <Jim.Driscoll(a)sun.com> wrote:
On 5/23/09 10:46 AM, David Geary wrote:
> The onevent attribute of <f:ajax> can be used to specify a JS function
> to monitor Ajax calls, which is all well and good. However, the data
> payload (I'm not sure why we have to refer to it as a payload), seems
> strange because:
>
> 1. data.type is always "event". What's the point of that?!?
>
Sometimes, it's error. See the jsf-demo/ajax-queue demo for an example
that uses this interchangeably.
2. data.name <http://data.name> is really the status of the Ajax
> request. Using "name" for the property seems meaningless. Name of what?
>
Honestly, in looking at the demo you cited, I can't possibly resolve why you
would want to use a property called "name". To me, the word "status"
wants
to come to mind. I really think you could get away with a single property,
status.
status could be: begin, complete, success, error
Then you have errorCode instead of overloading name. Just get rid of type
and name and use status instead.
>
The name of the event. Or, the name of the error. The spec lists them -
there are only a few to choose from. I'm afraid I don't understand your
objection.
3. does it make sense to give the page author acdcess to the actual
> XMLHttpRequest object via the data payload? data.xhr, for example?
>
Is your objection that they could modify the object? Since this is
JavaScript, they can already modify darn near everything anyway. We could
always deliver them a copy of the object, I suppose...
I think David is asking whether it is possible to access the object. It
appears that data is a copy of the properties from the XHR object, not the
object itself. David, do you want the native object?
-Dan
--
Dan Allen
Senior Software Engineer, Red Hat | Author of Seam in Action
http://mojavelinux.com
http://mojavelinux.com/seaminaction
http://in.relation.to/Bloggers/Dan
NOTE: While I make a strong effort to keep up with my email on a daily
basis, personal or other work matters can sometimes keep me away
from my email. If you contact me, but don't hear back for more than a week,
it is very likely that I am excessively backlogged or the message was
caught in the spam filters. Please don't hesitate to resend a message if
you feel that it did not reach my attention.
8:38 p.m.
2009/5/24 Dan Allen <dan.j.allen(a)gmail.com>
On Sat, May 23, 2009 at 11:52 PM, Jim Driscoll
<Jim.Driscoll(a)sun.com>wrote:
> On 5/23/09 10:46 AM, David Geary wrote:
>
>> The onevent attribute of <f:ajax> can be used to specify a JS function
>> to monitor Ajax calls, which is all well and good. However, the data
>> payload (I'm not sure why we have to refer to it as a payload), seems
>> strange because:
>>
>> 1. data.type is always "event". What's the point of that?!?
>>
>
> Sometimes, it's error. See the jsf-demo/ajax-queue demo for an example
> that uses this interchangeably.
Okay, that makes sense, I suppose. But the spec, in table 14-4 describes the
value of the type parameter as simply "event". That description should be
updated.
>
> 2. data.name <http://data.name> is really the status of the Ajax
>> request. Using "name" for the property seems meaningless. Name of
what?
>>
>
Honestly, in looking at the demo you cited, I can't possibly resolve why
you would want to use a property called "name". To me, the word
"status"
wants to come to mind. I really think you could get away with a single
property, status.
status could be: begin, complete, success, error
Then you have errorCode instead of overloading name. Just get rid of type
and name and use status instead.
Agreed. That was my original objection. "name" implies nothing. Name of
what?
3. does it make sense to give the page author acdcess to the actual
>> XMLHttpRequest object via the data payload? data.xhr, for example?
>>
>
> Is your objection that they could modify the object? Since this is
> JavaScript, they can already modify darn near everything anyway. We could
> always deliver them a copy of the object, I suppose...
I think David is asking whether it is possible to access the object. It
appears that data is a copy of the properties from the XHR object, not the
object itself. David, do you want the native object?
Yes, I think it'd be useful to provide access to the actual xhr object.
david
-Dan
--
Dan Allen
Senior Software Engineer, Red Hat | Author of Seam in Action
http://mojavelinux.com
http://mojavelinux.com/seaminaction
http://in.relation.to/Bloggers/Dan
NOTE: While I make a strong effort to keep up with my email on a daily
basis, personal or other work matters can sometimes keep me away
from my email. If you contact me, but don't hear back for more than a week,
it is very likely that I am excessively backlogged or the message was
caught in the spam filters. Please don't hesitate to resend a message if
you feel that it did not reach my attention.
2:01 a.m.
On 5/24/09 11:38 AM, David Geary wrote:
Okay, that makes sense, I suppose. But the spec, in table 14-4
describes
the value of the type parameter as simply "event". That description
should be updated.
You need to also see table 14-6.
2. data.name <http://data.name>
<http://data.name> is really
the status of the Ajax
request. Using "name" for the property seems meaningless.
Name of what?
Honestly, in looking at the demo you cited, I can't possibly resolve
why you would want to use a property called "name". To me, the word
"status" wants to come to mind. I really think you could get away
with a single property, status.
status could be: begin, complete, success, error
Then you have errorCode instead of overloading name. Just get rid of
type and name and use status instead.
Agreed. That was my original objection. "name" implies nothing. Name of
what?
The name of the event. Or, the name of the error.
3. does it make sense to give the page author acdcess to
the
actual
XMLHttpRequest object via the data payload? data.xhr, for
example?
Is your objection that they could modify the object? Since this
is JavaScript, they can already modify darn near everything
anyway. We could always deliver them a copy of the object, I
suppose...
I think David is asking whether it is possible to access the object.
It appears that data is a copy of the properties from the XHR
object, not the object itself. David, do you want the native object?
Yes, I think it'd be useful to provide access to the actual xhr object.
That would require a spec change. The motivation for leaving that out
(I'd originally had it in the payload) was mostly just that folks in
general didn't think that people would want to use that. I also got
some resistance (as I recall) to the response text - but at least one
use case (improved error reporting) was envisioned for it, so it stayed in.
Again, I really wish this had come up when the spec went up for review,
instead of now that it's final, but at least this change (adding a new
property to an object) isn't a break with current compatibility.
Jim
1:50 a.m.
On 5/24/09 10:58 AM, Dan Allen wrote:
Honestly, in looking at the demo you cited, I can't possibly resolve why
you would want to use a property called "name". To me, the word
"status"
wants to come to mind. I really think you could get away with a single
property, status.
status could be: begin, complete, success, error
Then you have errorCode instead of overloading name. Just get rid of
type and name and use status instead.
That was one iteration of the proposal I made, IIRC (the second
iteration, after my massively overcomplicated first try). So it's not
as though I disagree with you. As I recall, I was the only person who
advocated that position, though, so there may be folks who disagree with
you on that... IIRC, the motivation behind the final form was splitting
out errors and events somewhat more than making error just a kind of event.
It's a shame that this discussion is coming up after the spec is final
though. If only there had been some group of people responsible for
reviewing the spec before it went final to catch this sort of thing,
some sort of Group of Experts....
But now that the spec is final, that seems like a rather large change to
make in an errata. The kind that could really mess folks up if they
were relying on the current behavior.
Jim
4:18 a.m.
It's a shame that this discussion is coming up after the spec is final
though. If only there had been some group of people responsible for
reviewing the spec before it went final to catch this sort of thing, some
sort of Group of Experts....
It's just amazing what happens once discussions are released out into the
open, isn't it? You actually get participation. So it's really too bad that
collaboration started so late. But at the same time, exciting that it's
finally happening. Frankly, I don't really care what "state" JSF is in. To
me, JSF 2.0 is but a snapshot in the long evolution that JSF has and will
continue to have. If we can't change something in 2.0, then we will change
it in 2.1. The point is, we need the changes and the discussions that lead
up to them to happen and continue to happen. Otherwise, as David so
gracefully said in his IBM series, we are just a bunch of eggheads in an
ivory tower.
-Dan
--
Dan Allen
Senior Software Engineer, Red Hat | Author of Seam in Action
http://mojavelinux.com
http://mojavelinux.com/seaminaction
http://in.relation.to/Bloggers/Dan
NOTE: While I make a strong effort to keep up with my email on a daily
basis, personal or other work matters can sometimes keep me away
from my email. If you contact me, but don't hear back for more than a week,
it is very likely that I am excessively backlogged or the message was
caught in the spam filters. Please don't hesitate to resend a message if
you feel that it did not reach my attention.
8:50 a.m.
On 5/24/09 7:18 PM, Dan Allen wrote:
It's a shame that this discussion is coming up after the spec is
final though. If only there had been some group of people
responsible for reviewing the spec before it went final to catch
this sort of thing, some sort of Group of Experts....
It's just amazing what happens once discussions are released out into
the open, isn't it? You actually get participation.
So it's really too
bad that collaboration started so late. But at the same time, exciting
that it's finally happening. Frankly, I don't really care what "state"
JSF is in. To me, JSF 2.0 is but a snapshot in the long evolution that
JSF has and will continue to have. If we can't change something in 2.0,
then we will change it in 2.1.
Actually, that's not entirely true, and it's a point that has to be
made, so everyone understands why it's such a big deal that the spec is
final.
As a rule, Java does not ever, ever, make changes that break backward
compatibility.
Even when I really wish we would. (Java security policies spring to
mind, for instance.)
The examples where backward compatibility was violated are small in
number, and usually involve things that are horribly broken by design,
with no way to fix it (like Thread.stop).
So, the changes you're proposing, moving the data fields around in the
payload, will break compatibility, and will thus probably not happen.
Because we missed our window to change it before the spec went final.
Now, that policy respecting backward compatibility may change, but
please keep in mind why it's there: because enterprises expect that out
of their APIs. The backward incompatible changes that Microsoft makes
every few years, though necessitated by bad design choices, has hurt
their enterprise adoption noticeably. ASP.net, anyone?
The point is, we need the changes and the
discussions that lead up to them to happen and continue to happen.
Yes, but the ability to make those changes become more constrained once
the spec goes final. So it's a big deal that we didn't catch this
before it did.
This is why reviewing the spec when it goes through it's drafts is such
a big deal.
Otherwise, as David so gracefully said in his IBM series, we are just
a
bunch of eggheads in an ivory tower.
API stability isn't for eggheads. In fact, in my experience, it's the
suits who want API stability. Eggheads and gearheads (academics and
geeks) tend to like fiddling with APIs. That fiddling makes the suits,
for whom every API change means expense costs, more than a little crazy.
Or has your experience been different?
Jim
4:18 p.m.
On Mon, May 25, 2009 at 2:50 AM, Jim Driscoll <Jim.Driscoll(a)sun.com> wrote:
On 5/24/09 7:18 PM, Dan Allen wrote:
>
>
> It's a shame that this discussion is coming up after the spec is
> final though. If only there had been some group of people
> responsible for reviewing the spec before it went final to catch
> this sort of thing, some sort of Group of Experts....
>
>
> It's just amazing what happens once discussions are released out into
> the open, isn't it? You actually get participation.
>
So it's really too
> bad that collaboration started so late. But at the same time, exciting
> that it's finally happening. Frankly, I don't really care what
"state"
> JSF is in. To me, JSF 2.0 is but a snapshot in the long evolution that
> JSF has and will continue to have. If we can't change something in 2.0,
> then we will change it in 2.1.
>
Actually, that's not entirely true, and it's a point that has to be made,
so everyone understands why it's such a big deal that the spec is final.
As a rule, Java does not ever, ever, make changes that break backward
compatibility.
Even when I really wish we would. (Java security policies spring to mind,
for instance.)
The examples where backward compatibility was violated are small in number,
and usually involve things that are horribly broken by design, with no way
to fix it (like Thread.stop).
So, the changes you're proposing, moving the data fields around in the
payload, will break compatibility, and will thus probably not happen.
I understand the policy. And I can also say that many, many people think
that it is a naive stance because the world changes and thus APIs need to
adapt. Of course there are people that never want it to change. But that
ignores all those pleas from people who do want it to change. So, it should
change when it makes sense (i.e., strong use cases, etc)
Because we missed our window to change it before the spec went
final.
Now, that policy respecting backward compatibility may change, but please
keep in mind why it's there: because enterprises expect that out of their
APIs. The backward incompatible changes that Microsoft makes every few
years, though necessitated by bad design choices, has hurt their enterprise
adoption noticeably. ASP.net, anyone?
Um, .NET is killing us. So obviously it doesn't hurt adoption that badly. By
no means am I saying to follow MS, I'm just pointing out that it somehow
doesn't phase the adoption.
The point is, we need the changes and the
> discussions that lead up to them to happen and continue to happen.
>
Yes, but the ability to make those changes become more constrained once the
spec goes final. So it's a big deal that we didn't catch this before it
did.
This is why reviewing the spec when it goes through it's drafts is such a
big deal.
Otherwise, as David so gracefully said in his IBM series, we are just a
> bunch of eggheads in an ivory tower.
>
API stability isn't for eggheads. In fact, in my experience, it's the
suits who want API stability. Eggheads and gearheads (academics and geeks)
tend to like fiddling with APIs. That fiddling makes the suits, for whom
every API change means expense costs, more than a little crazy. Or has your
experience been different?
The reality is, and the reality coming out of my experience, is that this
argument completely ignores that fact that there are defacto standards.
Facelets is a defacto standard and we are most definitely breaking that
standard as we move into JSF 2.0. If people think that APIs will never ever
change, they are just not being reasonable. I think that APIs should never
change without good reason. People that refactor just to try something new
are hurting a lot of people. People that refactor because others are begging
them to reduce pain or want to grow and mature the library are following
sound judgement.
But if the rule is that it can never change, so be it. It doesn't
necessarily mean it makes good sense.
-Dan
--
Dan Allen
Senior Software Engineer, Red Hat | Author of Seam in Action
http://mojavelinux.com
http://mojavelinux.com/seaminaction
http://in.relation.to/Bloggers/Dan
NOTE: While I make a strong effort to keep up with my email on a daily
basis, personal or other work matters can sometimes keep me away
from my email. If you contact me, but don't hear back for more than a week,
it is very likely that I am excessively backlogged or the message was
caught in the spam filters. Please don't hesitate to resend a message if
you feel that it did not reach my attention.
6:36 p.m.
First, my apologies for bringing this up after the spec went final, but as
Roger correctly intuited, I had not dived deeply enough until I started
preparing for J1.
As far as breaking bw compatibility, I must side with Dan here. It's also
worth pointing out that breaking bw compatibility for Java the language is
much more far-reaching than breaking it for a framework like JSF. It's my
opinion, btw, that refusal to break bw compatibility was toxic for Struts in
the long run. And RoR does not hesitate to break bw compatibility, and it
doesn't seem to have hurt them much.
david
2009/5/25 Dan Allen <dan.j.allen(a)gmail.com>
On Mon, May 25, 2009 at 2:50 AM, Jim Driscoll
<Jim.Driscoll(a)sun.com>wrote:
> On 5/24/09 7:18 PM, Dan Allen wrote:
>
>>
>>
>> It's a shame that this discussion is coming up after the spec is
>> final though. If only there had been some group of people
>> responsible for reviewing the spec before it went final to catch
>> this sort of thing, some sort of Group of Experts....
>>
>>
>> It's just amazing what happens once discussions are released out into
>> the open, isn't it? You actually get participation.
>>
>
> So it's really too
>> bad that collaboration started so late. But at the same time, exciting
>> that it's finally happening. Frankly, I don't really care what
"state"
>> JSF is in. To me, JSF 2.0 is but a snapshot in the long evolution that
>> JSF has and will continue to have. If we can't change something in 2.0,
>> then we will change it in 2.1.
>>
>
> Actually, that's not entirely true, and it's a point that has to be made,
> so everyone understands why it's such a big deal that the spec is final.
>
> As a rule, Java does not ever, ever, make changes that break backward
> compatibility.
>
> Even when I really wish we would. (Java security policies spring to
> mind, for instance.)
>
> The examples where backward compatibility was violated are small in
> number, and usually involve things that are horribly broken by design, with
> no way to fix it (like Thread.stop).
>
> So, the changes you're proposing, moving the data fields around in the
> payload, will break compatibility, and will thus probably not happen.
I understand the policy. And I can also say that many, many people think
that it is a naive stance because the world changes and thus APIs need to
adapt. Of course there are people that never want it to change. But that
ignores all those pleas from people who do want it to change. So, it should
change when it makes sense (i.e., strong use cases, etc)
> Because we missed our window to change it before the spec went final.
>
> Now, that policy respecting backward compatibility may change, but please
> keep in mind why it's there: because enterprises expect that out of their
> APIs. The backward incompatible changes that Microsoft makes every few
> years, though necessitated by bad design choices, has hurt their enterprise
> adoption noticeably. ASP.net, anyone?
Um, .NET is killing us. So obviously it doesn't hurt adoption that badly.
By no means am I saying to follow MS, I'm just pointing out that it somehow
doesn't phase the adoption.
>
>
> The point is, we need the changes and the
>
>> discussions that lead up to them to happen and continue to happen.
>>
>
> Yes, but the ability to make those changes become more constrained once
> the spec goes final. So it's a big deal that we didn't catch this before it
> did.
>
> This is why reviewing the spec when it goes through it's drafts is such a
> big deal.
>
>
> Otherwise, as David so gracefully said in his IBM series, we are just a
>> bunch of eggheads in an ivory tower.
>>
>
> API stability isn't for eggheads. In fact, in my experience, it's the
> suits who want API stability. Eggheads and gearheads (academics and geeks)
> tend to like fiddling with APIs. That fiddling makes the suits, for whom
> every API change means expense costs, more than a little crazy. Or has your
> experience been different?
The reality is, and the reality coming out of my experience, is that this
argument completely ignores that fact that there are defacto standards.
Facelets is a defacto standard and we are most definitely breaking that
standard as we move into JSF 2.0. If people think that APIs will never ever
change, they are just not being reasonable. I think that APIs should never
change without good reason. People that refactor just to try something new
are hurting a lot of people. People that refactor because others are begging
them to reduce pain or want to grow and mature the library are following
sound judgement.
But if the rule is that it can never change, so be it. It doesn't
necessarily mean it makes good sense.
-Dan
--
Dan Allen
Senior Software Engineer, Red Hat | Author of Seam in Action
http://mojavelinux.com
http://mojavelinux.com/seaminaction
http://in.relation.to/Bloggers/Dan
NOTE: While I make a strong effort to keep up with my email on a daily
basis, personal or other work matters can sometimes keep me away
from my email. If you contact me, but don't hear back for more than a week,
it is very likely that I am excessively backlogged or the message was
caught in the spam filters. Please don't hesitate to resend a message if
you feel that it did not reach my attention.
1:23 a.m.
On Mon, May 25, 2009 at 12:36 PM, David Geary <clarity.training(a)gmail.com>wrote:
First, my apologies for bringing this up after the spec went final,
but as
Roger correctly intuited, I had not dived deeply enough until I started
preparing for J1.
And I think this timing is perfectly reasonable. We can't all write sample
applications in a couple of weeks (which is how long we had to review the
final draft) and Mojarra really wasn't really ready until just a couple
weeks ago to try all of this out. So I think we are discovering/uncovering
about as soon as we could anyway.
-Dan
--
Dan Allen
Senior Software Engineer, Red Hat | Author of Seam in Action
http://mojavelinux.com
http://mojavelinux.com/seaminaction
http://in.relation.to/Bloggers/Dan
NOTE: While I make a strong effort to keep up with my email on a daily
basis, personal or other work matters can sometimes keep me away
from my email. If you contact me, but don't hear back for more than a week,
it is very likely that I am excessively backlogged or the message was
caught in the spam filters. Please don't hesitate to resend a message if
you feel that it did not reach my attention.
1:49 a.m.
In all fairness, most of the JSF 2.0 Ajax stuff (at least the stuff that
has been discussed here) has been out
since EDR2 and especially Public Review Draft (Jan 09). Regardless, I
do appreciate the good feedback,
which in most cases can be found when trying to use the APIs as David is
doing - thanks David!
Also, thanks Andy for taking the time to do some debugging and
clarification on some of the existing demos.
I'm going to collect these issues and add what I can to the MR list.
Thanks, Roger.
Dan Allen wrote:
On Mon, May 25, 2009 at 12:36 PM, David Geary
<clarity.training(a)gmail.com <mailto:clarity.training@gmail.com>> wrote:
First, my apologies for bringing this up after the spec went
final, but as Roger correctly intuited, I had not dived deeply
enough until I started preparing for J1.
And I think this timing is perfectly reasonable. We can't all write
sample applications in a couple of weeks (which is how long we had to
review the final draft) and Mojarra really wasn't really ready until
just a couple weeks ago to try all of this out. So I think we are
discovering/uncovering about as soon as we could anyway.
-Dan
--
Dan Allen
Senior Software Engineer, Red Hat | Author of Seam in Action
http://mojavelinux.com
http://mojavelinux.com/seaminaction
http://in.relation.to/Bloggers/Dan
NOTE: While I make a strong effort to keep up with my email on a daily
basis, personal or other work matters can sometimes keep me away
from my email. If you contact me, but don't hear back for more than a
week,
it is very likely that I am excessively backlogged or the message was
caught in the spam filters. Please don't hesitate to resend a message if
you feel that it did not reach my attention.
2:12 a.m.
On Mon, May 25, 2009 at 7:49 PM, Roger Kitain <Roger.Kitain(a)sun.com> wrote:
In all fairness, most of the JSF 2.0 Ajax stuff (at least the stuff
that
has been discussed here) has been out
since EDR2 and especially Public Review Draft (Jan 09). Regardless, I do
appreciate the good feedback,
which in most cases can be found when trying to use the APIs as David is
doing - thanks David!
Also, thanks Andy for taking the time to do some debugging and
clarification on some of the existing demos.
I'm going to collect these issues and add what I can to the MR list.
Good news. Thanks for aggregating this feedback.
-Dan
--
Dan Allen
Senior Software Engineer, Red Hat | Author of Seam in Action
http://mojavelinux.com
http://mojavelinux.com/seaminaction
http://in.relation.to/Bloggers/Dan
NOTE: While I make a strong effort to keep up with my email on a daily
basis, personal or other work matters can sometimes keep me away
from my email. If you contact me, but don't hear back for more than a week,
it is very likely that I am excessively backlogged or the message was
caught in the spam filters. Please don't hesitate to resend a message if
you feel that it did not reach my attention.
8:53 a.m.
On 5/25/09 7:18 AM, Dan Allen wrote:
The reality is, and the reality coming out of my experience, is that
this argument completely ignores that fact that there are defacto
standards. Facelets is a defacto standard and we are most definitely
breaking that standard as we move into JSF 2.0. If people think that
APIs will never ever change, they are just not being reasonable. I think
that APIs should never change without good reason. People that refactor
just to try something new are hurting a lot of people. People that
refactor because others are begging them to reduce pain or want to grow
and mature the library are following sound judgement.
But if the rule is that it can never change, so be it. It doesn't
necessarily mean it makes good sense.
Nothing you said is false. I even agree with most of it. That doesn't
change the fact that nothing you said refutes what I said, either. As
unfortunate as that may be.
What I'm trying to say is two things: if you care about the spec, it's
important to review it before it goes final. There are large portions
of the spec that I didn't review either, but it's an important point to
bring up. That's the point of the one month review period between
Final Draft and the commencement of the vote. And secondly, when
looking to make changes, try to figure out how to make them in a way
that doesn't break backward compatibility. Because if you don't or
won't, then history suggests that you are probably wasting your time.
Whether I agree with you or not. It's not my call.
As for this change - changing the name of a returned object's property
from "name" to "status" hardly seems like sufficient reason to break
backward compatibility. The only thing arguing in it's favor is that it
would seem that less that a dozen people worldwide have used the API
thus far - so it's probably now or never, at the least.
If we're going to break backward compatibility, I suspect a more
compelling rationale would be required.
Jim
3:34 p.m.
As for this change - changing the name of a returned object's property from
"name" to "status" hardly seems like sufficient reason to break
backward
compatibility. The only thing arguing in it's favor is that it would seem
that less that a dozen people worldwide have used the API thus far - so it's
probably now or never, at the least.
If we're going to break backward compatibility, I suspect a more compelling
rationale would be required.
Getting back on topic after the entertaining and obviously futile discussion
of backwards compatibility, I think in this case the property name "name" on
the data object of an Ajax callback is one that few people will understand.
Meaning at first look (or a look after a period of rest) they will think,
"name of what". I believe strongly that the payload API will be more well
received if the property name is "status".
-Dan
--
Dan Allen
Senior Software Engineer, Red Hat | Author of Seam in Action
http://mojavelinux.com
http://mojavelinux.com/seaminaction
http://in.relation.to/Bloggers/Dan
NOTE: While I make a strong effort to keep up with my email on a daily
basis, personal or other work matters can sometimes keep me away
from my email. If you contact me, but don't hear back for more than a week,
it is very likely that I am excessively backlogged or the message was
caught in the spam filters. Please don't hesitate to resend a message if
you feel that it did not reach my attention.
5455
days inactive
5458
days old
jsr-314-open-mirror@lists.jboss.org
14 comments
4 participants
participants (4)
-
Dan Allen -
David Geary -
Jim Driscoll -
Roger Kitain