You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@shindig.apache.org by Mike Samuel <mi...@gmail.com> on 2008/01/16 22:51:06 UTC
Caja error messages in Shindig
Some Shindigers demoed shindig with caja support at the hackathon
today. It doesn't currently display Caja error messages or warnings
(from com.google.caja.reporting.MessageQueue).
Cassie (CCed) and I bandied about a couple ideas:
(1) Since GadgetRewriter takes a gadget spec and returns a gadget
spec, put the messages after or in place of the <Content>:
<Error level="WARNING" location="foo.js:42"
>is_not_assigned is used before first assignment</Error>
(2) Have shindig grab the message queue and use it.
I'm leaning towards (1) because:
* having one output (content | content with warnings | errors) will
make it easier on many clients
* it would make it easy for us to provide more structured error
messages in the future without having to update clients
Any other options or arguments for or against either option?
cheers,
mike
Re: Caja error messages in Shindig
Posted by ih...@gmail.com.
On Jan 16, 2008 7:20 PM, John Hjelmstad <fa...@google.com> wrote:
> Fwiw, I've just submitted code to at least output the message ...
Thanks John!
> > Once we have that licked, the next step will be to ... work out
> > the file position skew issues caused by the fact that the container
> > is, in the general case, parsing and, in some cases, rewriting the
> > content before it hands it to Caja.
For the Shindig case at least, would it make sense to use Mike
Samuel's parse tree implementation to operate on the XML gadget
"envelope", since that can be made to preserve file positions across
mutation and is in general pretty full-featured?
Breaking things out this way would be a good way to preserve position
information but also allow both Caja and Shindig to independently make
the transformations that are important to us.
So, maybe, the parse tree core of Caja could be an independent utility
that both Shindig and Caja relies on?
And hey, we even have quasiliterals! We've never met a problem that
can't be solved with those. ;->
Ihab
--
Ihab A.B. Awad, Palo Alto, CA
Re: Caja error messages in Shindig
Posted by John Hjelmstad <fa...@google.com>.
Fwiw, I've just submitted code to at least output the message in addition to
the code of errors that occur during Shindig rendering requests, which
should help significantly when Caja processing errors occur. The rest of
these comments still apply though :)
John
On Wed, Jan 16, 2008 at 5:44 PM, <ih...@gmail.com> wrote:
> On Jan 16, 2008 2:31 PM, Mike Samuel <mi...@gmail.com> wrote:
>
> > Please explain what you mean by (error "code")?
> >
>
> This is all much easier to discuss when we're all looking at the code, but
> I'll try.
>
> The thing in Shindig that does the Cajoling is allowed to throw a
> GadgetException. This exception has a code (one of an enumeration,
> including
> MALFORMED_FOR_SAFE_INLINING) and a message.
>
> Right now, when Shindig catches one of these exceptions, it returns to the
> client only the code, which is why you see <pre>MALFORMED...</pre> and
> nothing else. The embedding we have right now formats the Caja
> MessageQueue
> into the message of this exception, but it's not getting returned to the
> client.
>
> Once we have that licked, the next step will be to format the Caja
> MessageQueue messages in a *pretty* way so a developer sees "real compiler
> error messages", and work out the file position skew issues caused by the
> fact that the container is, in the general case, parsing and, in some
> cases,
> rewriting the content before it hands it to Caja.
>
> Ihab
>
> --
> Ihab A.B. Awad, Palo Alto, CA
>
Re: Caja error messages in Shindig
Posted by ih...@gmail.com.
On Jan 16, 2008 2:31 PM, Mike Samuel <mi...@gmail.com> wrote:
> Please explain what you mean by (error "code")?
>
This is all much easier to discuss when we're all looking at the code, but
I'll try.
The thing in Shindig that does the Cajoling is allowed to throw a
GadgetException. This exception has a code (one of an enumeration, including
MALFORMED_FOR_SAFE_INLINING) and a message.
Right now, when Shindig catches one of these exceptions, it returns to the
client only the code, which is why you see <pre>MALFORMED...</pre> and
nothing else. The embedding we have right now formats the Caja MessageQueue
into the message of this exception, but it's not getting returned to the
client.
Once we have that licked, the next step will be to format the Caja
MessageQueue messages in a *pretty* way so a developer sees "real compiler
error messages", and work out the file position skew issues caused by the
fact that the container is, in the general case, parsing and, in some cases,
rewriting the content before it hands it to Caja.
Ihab
--
Ihab A.B. Awad, Palo Alto, CA
Re: Caja error messages in Shindig
Posted by Mike Samuel <mi...@gmail.com>.
Please explain what you mean by (error "code")?
mike
On 16/01/2008, ihab.awad@gmail.com <ih...@gmail.com> wrote:
>
>
> On Jan 16, 2008 1:51 PM, Mike Samuel <mi...@gmail.com> wrote:
>
> > (2) Have shindig grab the message queue and use it.
> >
>
> It's currently implemented this way -- it's just that the error "code"
> (and not the message) is being rendered. -- Ihab
>
> --
> Ihab A.B. Awad, Palo Alto, CA
Re: Caja error messages in Shindig
Posted by ih...@gmail.com.
On Jan 16, 2008 1:51 PM, Mike Samuel <mi...@gmail.com> wrote:
> (2) Have shindig grab the message queue and use it.
>
It's currently implemented this way -- it's just that the error "code" (and
not the message) is being rendered. -- Ihab
--
Ihab A.B. Awad, Palo Alto, CA
Re: [Caja] Caja error messages in Shindig
Posted by Mike Stay <me...@gmail.com>.
Sorry for responding late--didn't see this message. I put
instructions on how to enable error messages in the "readme" message I
sent to Mark and Eric. It's a 2-line patch to
GadgetRenderingServlet.java on line 273
for (GadgetException error : errs.getComponents()) {
markup.append(error.getCode().toString());
+ markup.append(" ");
+ markup.append(error.getMessage().toString());
markup.append("\n");
}
So if you're running a shinding server for everyone, make that change.
Otherwise they can make the change on their own servers per the doc I
sent.
--
Mike Stay - metaweta@gmail.com
http://math.ucr.edu/~mike
http://reperiendi.wordpress.com