> I am currently of the mind that the way to handle the "Change Style" > option is to have it be automagically injected into _NormalBorders > using the BuiltinTopicsProvider if the admin has configured the site > to have alternates. This, however, means that the configuration needs > to be in the Federation section of the flexwiki.config file since that > is all that the engine can see at runtime. This wouldn't be that big > of an issue except for the OverrideStylesheet element is at the root > level. It seems to me that these two are too similar to have in > different configuration sections.
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. > So to sum up the configuration issues, I'm planning on moving > OverrideStylesheet to the Federation section and adding the new > alternate config there as well so that it can be exposed to the engine > and to the Flexwiki.Web classes. I'm also planning on altering the > BuiltinTopics to include the element if the admin has configured > alternates. (This, of course, means that if they alter _NormalBorders > before adding the alternates that they won't magically see the > feature, but there's nothing to be done about that.) Yeah, that's a constant problem. I haven't thought of a good solution. > Another config question is do we want to turn this on in the default > flexwiki.config that is delivered by specifying the "Lemon" stylesheet > as an alternate. I can see going either way on this one, so unless > there are comments, I'll just leave it out and require that admins add > alternates to see the feature. > > Finally, I guess that the UI passes muster as the only comments I got > earlier were positive, so I'll just leave it as it is for now. > > Please comment if any of this is unnacceptable or if you see some > alternatives that I'm missing. > > I plan on committing later today. > > -nathan > > ----------------------------------------------------------------------- > -- > 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
