Hi Bruno & all,
Thanks for the reply. Will work on all these issues but I thought I'd
ask specifically about this one --
On Jan 18, 2008 12:15 AM, Bruno Bowden <[EMAIL PROTECTED]> wrote:
> For the line comments, it looks like it can't be parsed. Can you just
> mention the 'comment' prefix, e.g. "//" that will be used depending on where
> it's shown.
Parsing is indeed an issue -- see below.
> Also, with styles being separated out, does this mean out of
> sequence line numbers to group together styles that might have been
> scattered throughout the original gadget spec.
That would be the (desirable) effect, yes: the line numbers would
ensure that errors referred to the original gadget spec even though
the styles are lumped into one section at the top.
* * * * *
I'd like to propose a different API for the GadgetContentRewriter [*]
that does not depend on parsing. Right now, the client specifies a
Readable (essentially, a character stream). What would you folks think
if, instead, the client gave us a more structured data type? Something
like --
class FilePosition {
int lineNo, charNo;
URI source;
}
class Hunk {
FilePosition start;
String content;
}
GadgetContentRewriter.rewriteContent(..., List<Hunk> content, ...);
This would allow you to maintain progeny, down to the character level
if you want, of where each piece of content came from. For
compilation, we would concatenate all the Strings in order, but we
would be able to maintain the progeny through our parsing.
It seems like this is easy enough to do even if you are substituting
hangman variables (_UP_*) via something so simple as a regex. It
requires no deep parsing, no commenting and no escaping.
Shinding ** and ** Caja people -- what are your thoughts?
Ihab
[*]
http://google-caja.googlecode.com/svn/trunk/src/java/com/google/caja/opensocial/GadgetContentRewriter.java
--
Ihab A.B. Awad, Palo Alto, CA
