[webkit-dev] Fwd: Using WebKit's markup as facility of Chrome's DOM serializer

[Johnny Ding]

Hi Darin,
Thanks very much for your comments. I am glad I have chance to introduce
those features into WebKit.
MarkupClient interface is the interface for markup extensibility. Also all
those five features will be implemented inside Markup, But I think each of
them have different request.

For feature 1, the replacing logic will be implemented inside Markup. but
 user need to implement MarkupClient::getSavedLocalSubResourceURL to return
correct local URL for input subresource URL If they want to replace
all saved subresources with local URLs.
For feature 2, 3 and 4.  Since all of them are to add extra information and
correct some information inside document.  so I think the logic will be
implemented inside Markup, but they will only be active when user explicitly
declare they want them. It's because most calls for markup are just for
getting innerHTML, XMLSerializer or the clipboard code. For those purpose,
they just want to get the raw information instead of getting modificatory
information.

For feature 5,  In some of scenarios, one buffer is good enough for saving
all serialized content. Other scenarios may want to do increment saving. I
think It will be better to let users
implement MarkupClient::saveMarkupContent to choose their prefer way. (using
one buffer or using small buffer with increment process)

I totally agree we need to control the number of argument of markup. Using a
parameter class to handle those arguments is very good way. I will follow
your idea. Actually inside chrome's serialzer, we had
class:SerializeDomParam to handle all arguments we need when
doing serialization.

Now I still have a question about working process. I had contributed
several(only a few) patches to WebKit on past year for resolving some bugs
in Webkit bug management system (aka https://bugs.webkit.org/, I used
johnnyding.webkit at gmail.com as my account name.)  Now should I file a new
bug on https://bugs.webkit.org/ for improving markup, then write the patch
and send to you (plus someone else I should involve) for review? Is that a
right process?

Thanks again for your help!



2008/11/20 Darin Adler <darin at apple.com>

> On Nov 18, 2008, at 12:45 AM, Johnny Ding wrote:
>
>  For adding above features to markup. I think we can define a abstract
>> class called MarkupClient
>>
>
> I think it's fine to add a client interface to make the markup machinery
> extensible. But the five features you're talking about above seem to all be
> things that should be added to WebKit, making the markup functions more
> capable for all WebKit users rather than adding Chrome-only code for these
> things.
>
> Some features may be so unusual that they should be kept out of the core
> WebKit code, but none of the ones you list above seem that unusual.
>
> Before adding an extensibility mechanism to the markup functions, I suggest
> you instead consider how to add these additional features. As the number of
> arguments to markup becomes larger, the right thing to do would be to create
> an object to hold all of the options and pass that in, rather than having a
> long list of arguments.
>
>    -- Darin
>
>


-- 
Best Regards.
Johnny
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20081120/90c7efe5/attachment.html>