There are a number of WikiTalk objects that emit HTML, such as the form
items, which is the model I followed when implementing the
ContainerPresentation.
I agree that there still needs to be an important distinction between
WikiTalk, HTML, WikiText, WOM, and so on, but equally, some tasks couldn't
be performed at the moment (like forms) in WikiTalk without HTML emitting
WikiTalk objects. In actual fact, I think they only emit HTML, because the
only output format the FlexWiki supports is HTML. The implement of a new
output format would require an accompanying implementation for the
presentation objects.
On 8/16/07, David Ornstein <[EMAIL PROTECTED]> wrote:
>
> It may be a fine point that doesn't help with the current issue on the
> table, but a comment about how I thought about WikiTalk and HTML when I
> implemented it originally:
>
> It's important to distinguish between whether some WikiTalk objects emit
> HTML and whether they must emit HTML. In particular, all the ones I built
> originally (including, especially, the form related ones) we designed to
> represent an abstraction that could be rendered as HTML or to any of a
> number of other UI paradigms. I believe this principle no longer holds true
> given the recent addition of the ability to put in arbitrarily-styled spans
> and divs, though.
>
> > -----Original Message-----
> > From: [EMAIL PROTECTED] [mailto:flexwiki-
> > [EMAIL PROTECTED] On Behalf Of Nathan Jones
> > Sent: Thursday, August 16, 2007 7:39 AM
> > To: FlexWiki Users Mailing List
> > Subject: Re: [Flexwiki-users] Alternate Stylesheet wrap up
> >
> > > So, the way I look at it is that stylesheets are a web app feature,
> > and
> > > really don't belong in the core. If there's a desire to add something
> > to
> > > _NormalBorders, it probably needs a layer of abstraction to allow it
> > to
> > > communicate with the web app in a way that can also work in other
> > scenarios.
> > > This generally has the benefit of making test easier, too.
> > >
> > > Indeed, nothing about HTML should really "leak" its way into the
> > core. Of
> > > course, Formatter lives there now, and it's chock full of HTMLness,
> > but
> > > that's a design flaw, IMO: it should live in the web app. With the
> > new
> > > parser (post-2.0), I imagine the Formatter will get radically
> > rewritten
> > > anyway.
> > >
> >
> > OK, so I understand your point, but I wonder what to do about it.... I
> > don't see how to separate things out so cleanly, given that WikiTalk
> > is part of the core, but WikiTalk is intimately aware of the fact that
> > it lives in HTMLland. A lot of the WikiTalk objects spew HTML
> > directly.
> >
> > So I have a ContentProvider that spews WikiTalk and is a Wiki
> > "object."WikiTalk only has access to a certain number of objects from
> > the core, and doesn't have access directly to the web app at all, even
> > though it is pretty HTML-aware. I can obviously make a WikiTalk
> > ExposedFunction that spews exactly what HTML I need it to (which is
> > what a fair number do,) but the engine still doesn't have access to
> > any configuration except what is provided from flexwiki.config via the
> > FederationConfiguration class, so that doesn't even help.
> >
> > I really don't see a way around this. The (wikitalk) content provider
> > has to do presentation work based on the configuration. The
> > configuration is in the web app because that's the only configuration
> > we have. The only link between the configuration of the web app and
> > the engine is via the FederationConfiguration. So I either use this or
> > allow the engine general access to the web app's configuration which
> > seems to really be counter to what you are worried about.
> >
> > help!
> >
> > -----------------------------------------------------------------------
> > --
> > This SF.net email is sponsored by: Splunk Inc.
> > Still grepping through log files to find problems? Stop.
> > Now Search log events and configuration files using AJAX and a browser.
> > Download your FREE copy of Splunk now >> http://get.splunk.com/
> > _______________________________________________
> > Flexwiki-users mailing list
> > [email protected]
> > https://lists.sourceforge.net/lists/listinfo/flexwiki-users
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems? Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Flexwiki-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/flexwiki-users
>
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Flexwiki-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/flexwiki-users
