slashcode-development

[Slashcode-development] some of my thoughts/requests for slashcode devel

[James M. <jm...@tr...>]

Hi all,

To the fine folks who develop slashcode regularly, thanks for your
work. 

What I am most concerned with at the moment is migrating my website
style from tables to CSS.  

(By way of background, I use slashcode more as a library than as a
readymade website.  I use the login and authentication stuff without
ever looking at the code, I use the DB interface, and I use the
template toolkit display calls.  And of course, I use the admin
interface to edit templates. )

Over the weekend I finally had a look at that write up on A List Apart
mentioned a few weeks ago in slashdot.  Now I've got one site
rendering in xhtml strict, with a css style sheet, and not a table tag
in site.  But to do so I push in lots of stuff for the CSS template
through a hashref when I call the make header routine, and most
egregiously, I hacked the menu system, overloading the "value" entries
to also set the id tag for each list item, as in:

 <ul>[% FOR i = items %]
  [%- myvalue = i.value -%]
  [%- matches = myvalue.match('(op).(\w+)\"') %]
  <li id="nav-[%- matches.1 -%]"><a [% i.value %]>[% i.label %]</a></li>
 [% END %]</ul>


Couple of thoughts on this (having not looked at CVS code, btw).
First, I can only seem to access the menu entries in the menus table
by a mysql console, not the admin interface.  Is this a feature or a
bug?  Second, the menus table could use another hook or two for style
sheets, to avoid my ugly text parsing hack.  Something like 

styleid varchar (20) NOT NULL, 
styleclass varchar(20) NOT NULL default "menuitem",

would probably do it.  I would do that, but the code that renders the
menu would need to be changed, thus breaking my compatibility with the
slash libraries. (Hmm, I just thought that maybe it is possible to
subclass something like the Environment module to override that
function???)  Third, I am not sure whether it is appropriate to put
the css style sheet in a separate, static file, or render it with a
template.  I do the latter right now, since my usage sets the names of
style ids on the fly based on passed arguments, so that I can add to
the menu with minimal fuss, as in:

... perl to get an arraref to my menu values (parsing op="text"
entries), passed as navids to template ...

[% FOREACH nid = navids %] #[%- nid %] #nav-[%- nid %][%- ', ' UNLESS loop.last -%]
 [% END %]  {
    background-position:0 -150px;
    border-width:0;
}

[% FOREACH nid = navids %] #[%- nid %] #nav-[%- nid %] a[%- ', ' UNLESS loop.last -%]
 [% END %]  {
    background-position:100% -150px;
    padding-bottom:5px;
    color:#333;
}

(which copies shamelessly a technique from another article in A List
Apart)

Any thoughts on static versus dynamic css?  I think the bandwidth
savings quoted by the "recoding slashdot" article depend upon a cached
css file.  Perhaps if the css file is dynamically rendered, then the
savings go poof.  An alternative is to have a mix; some css static,
other stuff dynamic, as files static_layout.css, static_markup.css,
and then any dynamic styles pushed into the header after the
stylesheet include commands.

But I think the attraction of slashcode to me is dynamically
generating and rendering content.  Philosophically, should the the css
be considered decoration that can be static, like the various icons
and borders, or dynamic, like the content?  I think it should be
dynamic, since it opens up more possibilities (such as the extensible
menu styles above), and it puts the code in the db where it can be
manipulated through temlate toolkit.

hoping this long post is appropriate for this list,
James

Re: [Slashcode-development] some of my thoughts/requests for slashcode devel

[Clifton W. <cl...@sl...>]

On Monday 15 December 2003 12:34, James Marca wrote:

> Couple of thoughts on this (having not looked at CVS code, btw).
> First, I can only seem to access the menu entries in the menus
> table by a mysql console, not the admin interface. 

No, this is in the API, you can either do it through Perl:

	perl -MSlash::Test=virtualuser -le \ 
		'print Dumper($slashdb->getMenuItems(<menuname>))'

So if you wanted to get all the menus for the admin pages, for 
example:

	perl -MSlash::Test=<virtualuser> -le \
		'print Dumper($slashdb->getMenuItems("admin"))'

Note, the call to Dumper() is just there to show you what the data
structure looks like, feel free to set the value used to a scalar
and use as you see fit.

If you want to use this exclusively in a template, you can do:

	[% menus = Slash.db.getMenuItems("admin") %]

> Second, the menus table could use another hook
> or two for style sheets, to avoid my ugly text parsing hack. 
> Something like
>
> styleid varchar (20) NOT NULL,
> styleclass varchar(20) NOT NULL default "menuitem",
>
> would probably do it.  I would do that, but the code that renders
> the menu would need to be changed, thus breaking my compatibility
> with the slash libraries. (Hmm, I just thought that maybe it is
> possible to subclass something like the Environment module to
> override that function???)

Another (and non-normalized) way to do this would be to 
create another table:

	create table menu_styles (
		id		mediumint(5) unsigned NOT NULL,
		styleid 	varchar(20) NOT NULL,
		stylecss	varchar(20) NOT NULL default "menuitem",
		UNIQUE KEY (id)
	);

Any menuitem you retrieve using getMenuItem() will have a unique
ID associated with it, you can then use your own SQL call to 
get the style:

	($style_id, $style_css) = $slashdb->sqlSelect(
		'styleid, stylecss',
		'menu_styles',
		'id=' . $slashdb->sqlQuote($menuitem->{id})
	);

Or via template:

	[% 
		styleinfo = Slash.db.sqlSelect(
			'styleid, stylecss',
			'menu_styles',
			'id=' . Slash.db.sqlQuote(menu_id)
		);
	%]

This gives you the advantage of compatibility with the Slash 
libraries, and flexibility to add whatever you need to 
the menu_styles table, at the expense of maintaining your
own code. If you don't need to do anything more complex
than this, this should suit you just fine.

This is only just one solution, of course. I just thought I should
share. =)

> Third, I am not sure whether it is
> appropriate to put the css style sheet in a separate, static file,
> or render it with a template.  
> [ ... ]
> Any thoughts on static versus dynamic css?  I think the bandwidth
> savings quoted by the "recoding slashdot" article depend upon a
> cached css file.  Perhaps if the css file is dynamically rendered,
> then the savings go poof.  An alternative is to have a mix; some
> css static, other stuff dynamic, as files static_layout.css,
> static_markup.css, and then any dynamic styles pushed into the
> header after the stylesheet include commands.
>
> But I think the attraction of slashcode to me is dynamically
> generating and rendering content.  Philosophically, should the the
> css be considered decoration that can be static, like the various
> icons and borders, or dynamic, like the content?  I think it
> should be dynamic, since it opens up more possibilities (such as
> the extensible menu styles above), and it puts the code in the db
> where it can be manipulated through temlate toolkit.

You don't mention what types of style sheets need the dynamic
treatment, nor where you are generating them in the overall scheme
of Slash. I can only make a general suggestion here that may or
may not be appropriate for what you are doing, I'd need more 
information before would be able to suggest something that
isn't a shot in the dark. I can suggest one thing, however.

If you have a specific set of CSS styles that need to be regenerated
over the course of the day, you could make a task to update these
dynamically (the file is served static, but dynamically generated
ever <x> minutes or <y> hours).

Take a look at some of the code in:

	/usr/local/slash/site/<yoursite>/tasks

For some examples of what I mean. You create whatever code 
snippet you need inside the task structure and let slashd handle
the execution at the times you specify (slashd uses cron timespecs 
to schedule code execution).

Hope these suggestions help. If you'd like to go into more detail
with such things, please drop us another line. 

- C