Craig raises a good point about not "polluting" the core (even more) with
Web app stuff, so I'm not sure what to suggest moving forwards. Just leave
the config options where they are (not in the Federation stuff) perhaps?
Maybe we can tackle the issue of the Web app and it's configuration and how
it interacts with the core (_NormalBorders) in the next release.
Personally, I'd rather not see the Change Styles link under it's current UI
in the RightBorder because the graphic on the left would "imbalance" the
appearance. I'm wondering if a drop-down of styles can be generated with a
button on the right (like the search UI in the LeftBorder), which would then
look suitably balanced in the RightBorder.
Yes, I think a new style would be appropriate. Something like "Popup", which
we could apply to other elements in the future if necessary.
Yes, I think it should be applied by default.
On 8/16/07, Craig Andera <[EMAIL PROTECTED]> wrote:
>
> > 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
>
-------------------------------------------------------------------------
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
