I think Craig's suggestion of an Application object to expose the
configuration type information is a good one. If it wasn't for all this
pesky work stuff, I'd volunteer straight away to do it myself :o)
On 8/16/07, Craig Andera <[EMAIL PROTECTED]> wrote:
>
> > 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.
>
> Yep. Fixing it is a fair-sized job. It starts with changing WikiTalk so it
> operates on and emits a WOM rather than WikiText/HTML. Then we could
> introduce hooks into WikiTalk to let it get information from the host
> application (web app or whatever). Of course that presumes the presence of
> a
> parser to produce the WOM. Oh, and we should probably think about
> backwards
> compatibility. :)
>
> Obviously, that's way out of scope for the near term, although I think
> it's
> fairly important to keep the long-term objectives in mind. So what to do
> for
> now? Probably it makes sense to stick the configuration information into
> FederationConfiguration.
>
> A better solution that I can think of would introduce an Application (or
> Host, or whatever) object in the WikiTalk hierarchy. It could be as simple
> as a set of name-value pairs that could be set in the web app
> configuration.
> Obviously, this is more work, but maybe not an unreasonable amount. It
> would
> also be extremely general and therefore more broadly useful. I'm sure you
> can think of several things you could do if there was a generic place to
> store stuff, and then in WikiTalk you could do the equivalent of
>
> Response.Write(WikiApplication["foo"])
>
> I haven't mucked around much with the WikiTalk part of the app, though,
> and
> I'm not the one that would be doing the work, so I'd rely on your judgment
> as to the right approach here. I just wanted to raise the issue of
> separation, since it's a big problem with the code right now. I don't
> think
> it needs to prevent this feature from surfacing in the near term, but it's
> something we should keep in mind.
>
>
>
> -------------------------------------------------------------------------
> 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
> Flexwiki-users@lists.sourceforge.net
> 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
Flexwiki-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flexwiki-users
