Awesome, can't wait to see what you come up with. Sent from my iPhone
On Apr 27, 2009, at 7:33 PM, Arthus Erea <[email protected]> wrote: > > Overall, I think everyone has some good points. Thanks for the > feedback. > > Pending any objections, I'm going to start working on an > implementation (as described). > > On Apr 27, 2009, at 2:00 AM, Andrew Rickmann wrote: >> >> This is a solid gold idea. > > Thanks. > >> >> I think it should be possible to include any FormUI type, i.e. radio >> buttons, check boxes, and dropdowns. > > If you take a look at the wiki proposal, we'll be generating the form > using FormUI. Therefore, all current FormUI types will be accessible, > in addition to some new ones I'll add (color, etc.). > > This also has the added benefit of allowing plugins and themes to > provide their own custom controls, if need be. > > On Apr 27, 2009, at 2:33 AM, Andrew Rickmann wrote: >> >> A few other thoughts that occur to me: >> >> 1) Should the configuration options be saved in a theme specific way, >> i.e. the option is the theme name and all the actual values are >> stored >> within that array, so that even if you remove the theme and then want >> it back the options won't be overritten by the options of the next >> theme. > > Actually, I prefer the idea of keeping them all in the main options > field. Themes will probably start to standardize on certain fields > (such as a "blurb" field) which I wouldn't want to have to port every > time I change my theme. > > Plus, storing serialized arrays should be avoided if possible. > >> If so this would need a cleanup option as well. > > There will be a reset button, which will reset all options to the > current theme defaults. > >> 2) Is there any value in being able to wrap the options in a page in >> case there are a lot of options >> >> <config> >> <page> >> <title>Options page 1</title> >> <field ... >> <field ... >> </page> >> <page> >> <title>Options page 2</title> >> <field ... >> <field ... >> </page> >> </config> > > I don't think there is too much value in this, but I do think we can > support it with relatively little work. > > I've something to the schema which allows the addition of "sections" > which will be converted into FormUI fieldsets: > http://wiki.habariproject.org/en/User:arthus/ThemeConfig#Sections > . > > On Apr 27, 2009, at 9:56 AM, Owen Winkler wrote: >> I dislike the idea of pushing CSS through PHP every time, but it >> might >> be useful to include some generic functionality in Habari that >> handles >> "build caching". There is a module for Drupal called image_cache >> that >> is quite clever in how it accomplishes this. I will attempt to >> explain >> what it does in terms of providing dynamic CSS for Habari's themes. > > It had always been my intention to support the dynamic building of css > templates through this system. > > Your method seems to be the most sensible, both in terms of conserving > resources and allowing extensibility. > > I think the "cache" should be flushed in two instances: > 1) When the theme options are changed. > 2) Once a day (to make sure we always have a good copy) > > Furthermore, there should be an option to disable the cache somewhere > in the UI. That would give tinkerers the ability to work on the theme, > then re-enable the cache when they're done. > Where should such an option be? In the theme config or in the main > settings page? (I'm leaning towards main settings.) > >> There really isn't a need to use that one directory, but it would >> make >> it easier to route requests. I imagine a rewrite rule that resolves >> to >> a single hook, where the file that the request asks for is passed in. >> Plugins/Themes that can resolve the file simply return it, and the >> system takes care of putting the file where it belongs and managing >> versioning. The plugin would call a specific function to clear a >> file >> from the build cache. Also, some logic for versioning and >> appending a >> querystring to the URL (like .../style.css?6) would be handled by the >> system. > > What would the benefit of the querystring be? Shouldn't there really > just be one version regardless? > >> It sounds complicated, but it would make it all easier for the >> themer. >> >> Also... Rather than developing a brand new syntax for the dynamic >> theme >> bits, we could use HiEngine. HiEngine is already pretty close to the >> syntax described, and wouldn't take much more effort to add a default >> for a value that isn't set (something I was planning on doing >> anyway). > > HiEngine looks like a good option. > > Actually, I don't think we need the "default" option part. I think we > should keep "input" and "output" separate and the default part is > (kindof) input. The schema already has a place for a default option. > Plus, you'd probably end up using variables in multiple places – you > shouldn't need to copy the default between them. > >> So the syntax would simply be this instead, if you were pulling it >> from >> an option: >> {hi:option:color1 default="#f00"} > > I prefer this syntax, so we wouldn't have to hit the database for > options we're not using. > > I also think there should be some way for themes to assign additional > variables to the stylesheet – without necessarily making them user > configurable. > > This could probably be accomplished with a hook before we build the > template. > > On Apr 27, 2009, at 10:09 AM, Sean T Evans wrote: >> My concern is for themers like me who are most comfortable working >> directly in PHP and CSS. Requiring themers to learn a new "language" >> to >> take advantage of the configuration options seems a disservice and >> will >> also, I think, discourage development of additional theme engines, >> which, in turn, will discourage themers who use other engines from >> sharing their skill with Habari. > > Which part are you referring to? The XML or the HiEngine? > > For the configuration section, there are 2 ways you can build the > configuration: > 1) Use the (arguably easier) XML system to build your configuration > 2) Build the form using standard FormUI & PHP, within a theme hook > > In terms of HiEngine, I wonder if we could actually run both PHP and > HiEngine at once on the generation. I'd see it working like this: > 1) We open a buffer to catch the output > 2) The stylesheet is included > 3) We run the resultant css through the HiEngine > 4) We output/cache the CSS > > Since most requests will be served from the cache, this shouldn't be > too much of a hassle. > >> Perhaps the answer is to use the cached file as described by Owen, >> and >> take advantage of the Cascade to allow it to override the theme's CSS >> with no actual changes to what needs to happen in the standard .css >> file. > > To be clear, you don't have to do anything to the standard .css file. > All existing files would continue to work perfectly, we're just adding > some additional features which themes might leverage. > > Again, thanks for the feedback. I'll start work on the implementation > soon. > > On Apr 27, 2009, at 1:21 PM, Andrew Rickmann wrote: > >> >> re-generating on options save seems like the best option to me, but >> there is an issue with tinkerers who want to tweak the CSS manually. >> Perhaps if it re-generated when the options are saved or when the >> save >> date of the base CSS file altered? What kind of hit would that bring? >> >> The Hi engine syntax seems no less complex than anything else that >> might be in place so I don't see any harm in using that for the CSS >> replacement. >> >> 2009/4/27 Rich Bowen <[email protected]>: >>> >>> >>> On Apr 27, 2009, at 09:56, Owen Winkler wrote: >>> >>>> Assume you have a cache directory at /user/build. The theme would >>>> output the stylesheet URL as /user/build/style.css (for example). >>>> This >>>> file does not yet exist in the directory. >>>> >>>> Because the file does not exist, the request is routed through >>>> Habari. >>>> Habari, using rewrite rules that catch requests to the build cache, >>>> notes the request and builds the file. The file is served, but is >>>> also >>>> saved into the correct location in the cache directory. >>>> >>>> The result is that on the next request, the file exists. Apache >>>> sees >>>> that the file exists and serves it directly instead of routing >>>> through >>>> Habari. The file is served much faster because there is no PHP >>>> processing. >>> >>> >>> >>> ++1 >>> >>> Or a great big "REGENERATE THEME" button. Having to generate >>> anything >>> on the fly, every time, when it's exactly the same every time, is a >>> waste of my precious milliseconds. >>> >>> >>> -- >>> I have nature and art and poetry, >>> and if that is not enough, what is enough? >>> (Vincent van Gogh) >>> >>> >>> >>> >>> >>> >>>> >>> >> >>> > > > > --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/habari-dev -~----------~----~----~----~------~----~------~--~---
