The benefit of the Stack class is that it allows plugin developers to
inject new stylesheet and javascript output that might be required for
their plugin functionality, both without having to use strange hacks or
worry about dependency chains.
But there are some issues that I would like to address and correct
quickly for Habari 0.9.
==NAMED SCRIPTS==
This would allow developers to specify an extant script by name, rather
than finding and using a complete URL. For example, if Habari ships
with jQuery or a CSS reset, the developer would need only reference
these scripts by name in a call to Stack::add(). This would add
whatever is required to make that script work, including correct URL
references and placement in the output based on dependency.
This is something that people have wanted for a while, I think, because
WordPress offers a semblance of it. I'm not convinced WordPress'
implementation is the best, but it's worth looking at as an example.
==EASY STACK ADDITIONS==
It's possible to create very simple themes in Habari without a theme.php
class file, but adding custom stylesheets and scripts for those themes
while simultaneously allowing the Stack output to function properly is a
problem.
I think it would be beneficial to make it easier to add stylesheets for
novice theme authors.
For example, (and this is a crazy off-the-wall notion presented merely
to illustrate one solution I'm considering) we could add code that
implements a parser to take normally output HTML and add it to a stack.
Consider the following:
<?php Stack::build_begin('template_stylesheet'); ?>
<link rel="stylesheet" href="<?php echo Site::get_url('theme',
'/reset.css'); ?>" id="css_reset">
<link rel="stylesheet" href="<?php echo Site::get_url('theme',
'/style.css'); ?>" id="css_style">
<?php Stack::build_end('template_stylesheet'); ?>
<?php echo $theme->header(); ?>
The above code would (line by line) start a new build buffer for the
stack "template_stylesheet", collect the output lines for the style
inclusion, end the buffer (causing the system to parse and add the
individual elements to the stack), then output the stack normally.
As the elements are parsed, their names would be taken from the id
attribute provided in the HTML, and dependencies would be created in
order of their output. In the example above, the stack element
"css_style" would be dependent on "css_reset", due to the order of
output. In this way, plugins could insert new CSS files into the stack
with dependencies set correctly.
Another advantage with an approach like this would be that whole tags,
not just a stylesheet URL, would be added to the stack. There are
currently output limitations in the Stack implementation that do not
allow alteration of the output tag. For example, it is not possible to
set the "rel" attribute of the link element for the stylesheet, which
makes it impossible to add LESS CSS link elements via the Stack. This
functionality is desirable.
I'm also considering adding stack values to the theme XML, which I think
would allow additional functionality beyond just that dealing with
stylesheets and scripts, without having to create a theme.php class.
This abstracts functionality from the code somewhat, but I think themers
and plugin devs would benefit from an easy way to modify a stack without
having to create a whole class.
Implementing something like this may fundamentally change the way Stack
outputs for stylesheets, because it currently expects that anything you
add to a stack is a value (or set of values) that needs to be inserted
into a tag. This is why I'm presenting this to the list -- because it
will affect most themes.
There may be a way to add this kind of functionality without breaking
everything, but in the past we've simply broken backwards compatibility
for the benefit of not keeping around cruft. I think this may be one of
those instances.
Owen
--
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
