> 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 Flexwiki-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flexwiki-users
