>From what I can tell right now, we're probably going to only wind up with 1
"Hunk" anyway, since the inlining of the other files will wind up happening
in the cajoling process rather than in shindig itself. Not having an
implementation to base this on, it's hard to definitively say whether your
proposal or what we're doing right now is better.
~Kevin
On Jan 18, 2008 2:55 PM, <[EMAIL PROTECTED]> wrote:
> 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
>
