[cgi-wiki-dev] Formatter API change proposal

[Kjetil Kjernsmo]

On mandag 24 januar 2005, 18:40, justin+earth@dicatek.com wrote:
> > > Or perhaps I'm misunderstanding, since you mention the "fragment"
> > > method. =A0But if you're going to provide a method to return a
> > > fragment, the limitations of whatever module you get to do the
> > > heavy lifting aren't relevant, surely.
> >
> > Well, it could be, if it can't return a fragment, the behaviour has
> > to be defined...
>
> I would imagine it can't be too difficult to have the formatter turn
> an HTML document into a fragment? (Am I missing something?)

Hmmm, I came to think of, the current spec is too tied to HTML. The idea=20
is to allow any format. So, yeah, you could strip some elements, and=20
get a fragment.=20

But the idea with a fragment is that you shouldn't add more than you can=20
defend. It is a minimum, and leave the rest to the calling application.=20
Then, document to fragment is not so clearly defined.

It would be nice to get a fragment anyway, that's true. But the question=20
is if it is a good idea for the Formatter to try or if it is better to=20
tell the app that "this is not clearly defined", and the app may call=20
the document instead, and do it its own way. I think I would prefer the=20
latter.=20

The alternative is to define on a per-format basis what is meant by a=20
"fragment". While it is doable, I do prefer the idea of a minimal=20
fragment. Or?

Cheers,

Kjetil
=2D-=20
Kjetil Kjernsmo
Astrophysicist/IT Consultant/Skeptic/Ski-orienteer/Orienteer/Mountaineer
kjetil@kjernsmo.net  webmaster@skepsis.no  editor@learn-orienteering.org
Homepage: http://www.kjetil.kjernsmo.net/        OpenPGP KeyID: 6A6A0BBC