5:30 p.m.
I'd like to propose that we add a freeform text description field to the
JavaScript event and error payload.
This would allow for user readable descriptions to go along with errors
like the infamous "MalformedXML" error.
I think this could fit into an errata, since:
1) It's got no backward incompatibility impact.
2) It's a single line in the spec.
3) It's (almost) trivial to implement.
and most importantly:
4) We really should have had this in there in the first place, and it's
omission was really more of an oversight than a deliberate choice.
Thoughts?
I've opened up spec issue 570 to track this:
https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=570
And yes, I made it a P1.
Jim
8:56 p.m.
I think this is really important. This came up during my demo at
JavaOne, and given the fact that we finally have good error reporting
with Facelets, we should strive for that level of detail across the
client as well.
On Wednesday, June 10, 2009, Jim Driscoll <Jim.Driscoll(a)sun.com> wrote:
I'd like to propose that we add a freeform text description field
to the JavaScript event and error payload.
This would allow for user readable descriptions to go along with errors like the infamous
"MalformedXML" error.
I think this could fit into an errata, since:
1) It's got no backward incompatibility impact.
2) It's a single line in the spec.
3) It's (almost) trivial to implement.
and most importantly:
4) We really should have had this in there in the first place, and it's omission was
really more of an oversight than a deliberate choice.
Thoughts?
I've opened up spec issue 570 to track this:
https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=570
And yes, I made it a P1.
Jim
--
---
Kito D. Mann -- Author, JavaServer Faces in Action
http://twitter.com/kito99 http://twitter.com/jsfcentral
http://www.virtua.com - JSF/Java EE consulting, training, and mentoring
http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info
+1 203-404-4848 x3
10:44 p.m.
On Wed, Jun 10, 2009 at 9:56 PM, Kito Mann <kito.mann(a)virtua.com> wrote:
I think this is really important. This came up during my demo at
JavaOne, and given the fact that we finally have good error reporting
with Facelets, we should strive for that level of detail across the
client as well.
+1. I was there to witness a view into what developers will experience. The
shifting in the room was evidence of the fact that we should never pause at
having better error reporting. So I'm for the information.
-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:34 p.m.
+1. Something to "improve" (or better yet - "fix" ;-) ) usability
issues is a must.
-roger
Jim Driscoll wrote:
I'd like to propose that we add a freeform text description field
to
the JavaScript event and error payload.
This would allow for user readable descriptions to go along with
errors like the infamous "MalformedXML" error.
I think this could fit into an errata, since:
1) It's got no backward incompatibility impact.
2) It's a single line in the spec.
3) It's (almost) trivial to implement.
and most importantly:
4) We really should have had this in there in the first place, and
it's omission was really more of an oversight than a deliberate choice.
Thoughts?
I've opened up spec issue 570 to track this:
https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=570
And yes, I made it a P1.
Jim
1:37 p.m.
Yep, agree with Kito and Dan that we need to do whatever we can to
reduce confusion when problems like this arise, so happy to see a more
detailed error description made available. (Not sure that we need a
description field for "events" - but definitely for errors.)
On a related note... So have we started to identify common problems that
might lead to client-side errors such as the "MalformedXML" error? Are
there certain issues/approaches that application developers should be
aware of in order to avoid running into such errors? Are there some
best practices that we should recommending to reduce the chance that
such errors will be seen? If so, it would be good to collect this
knowledge and make it available to our users.
Or are we seeing MalformedXML errors in cases where the application
developer has done everything right, but something is going wrong at the
framework/implementation/browser level?
Kito -
Were you able to track down the source of the MalformedXML error that
hit during your demo?
Andy
Jim Driscoll wrote:
I'd like to propose that we add a freeform text description field
to
the JavaScript event and error payload.
This would allow for user readable descriptions to go along with
errors like the infamous "MalformedXML" error.
I think this could fit into an errata, since:
1) It's got no backward incompatibility impact.
2) It's a single line in the spec.
3) It's (almost) trivial to implement.
and most importantly:
4) We really should have had this in there in the first place, and
it's omission was really more of an oversight than a deliberate choice.
Thoughts?
I've opened up spec issue 570 to track this:
https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=570
And yes, I made it a P1.
Jim
5:51 p.m.
On 6/11/09 11:37 AM, Andy Schwartz wrote:
Yep, agree with Kito and Dan that we need to do whatever we can to
reduce confusion when problems like this arise, so happy to see a more
detailed error description made available. (Not sure that we need a
description field for "events" - but definitely for errors.)
I agree that a description field may be overkill for an event.
On a related note... So have we started to identify common problems
that
might lead to client-side errors such as the "MalformedXML" error? Are
there certain issues/approaches that application developers should be
aware of in order to avoid running into such errors? Are there some best
practices that we should recommending to reduce the chance that such
errors will be seen? If so, it would be good to collect this knowledge
and make it available to our users.
The "render=false" error seems to be the major (user error) reason to
see the error at this point. All other occurances of that error that
I've seen have been RI errors.
That doesn't mean that there aren't a lot of other ways that the user
can make XML errors. Once they start writing XML from the server back
to the client, it's bound to happen sooner or later.
Since we have writers that enforce well formed XML, the majority of
errors you'll see will then be updating or deleting fields that don't
exist, or improperly CDATA escaping payload text.
But I think that for the standard components, we've found most of the
common code path bugs. *crosses fingers*
Or are we seeing MalformedXML errors in cases where the application
developer has done everything right, but something is going wrong at the
framework/implementation/browser level?
Up until a month ago, bugs in the RI made me see that error frequently.
I think I've squashed all the common path errors in the RI that
generated that error at this point.
Kito -
Were you able to track down the source of the MalformedXML error that
hit during your demo?
I'd also be interested in hearing about that. The RI errors seem to be
mostly easy to fix, it's just a matter of finding them.
Jim
5466
days inactive
5467
days old
jsr-314-open-mirror@lists.jboss.org
5 comments
5 participants
participants (5)
-
Andy Schwartz -
Dan Allen -
Jim Driscoll -
Kito Mann -
Roger Kitain