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 -~----------~----~----~----~------~----~------~--~---
