Re: Re: Org publish hierarchies and style variable

[Richard Riley <rileyrgdev@googlemail.com>]

Sebastian Rose <sebastian_rose@gmx.de> writes:

> Richard Riley <rileyrgdev@googlemail.com> writes:
>>> That's why I stick with the 'level-files' solution. This way it works
>>> without any server-side scripting, postprocessing, networking and simply
>>> on each and ervery host. Even when accessed through the file: protocol
>>> localy. All I need is emacs and a webbrowser to browse my notes or test
>>> publishing.
>>
>> I think cascading stylesheets using relative file notation provide the
>> same benefit. Note "think" since its been a while since I implemented my
>> org solution for my small web.
>
>
> Yes, if all you use is stylesheet. I use paths in my setup for

My comments are limited to Stylesheets at present.

> org-info.js too, and you could add libraries (Perl, PHP....) or
> something. Thanks to the level files, it's easy to move the file
> around. Also, they provide 'view classes'. E.g., I can change a simple
> file into a presentation by adding a few characters I remember, instead
> of changing/adding all those lines of a export template.

I think you have lost me here. The cascaded method does have level
files. At a default they simply cascade to the one above if it exists.

And the relative cascade works with all protocols. Possibly we are
agreeing. Since I do not understand what you mean above when you talk
about adding/changing lots of lines or adding a few characters to a
presentation. Do you mean adding some style info?

>
> Admittendly, I move files quite often. I split them in several files as
> they grow, put those files into an extra directory and so on.
>
>
>>> To do fancy stuff, we may use the either :style in
>>> org-publish-projects-alist or the corresponding #+STYLE: file-variable
>>> (e.g. in a level-file), to add arbitrary stuff to the head section. I'll
>>> just use the #+STYLE: option for readability.
>>
>> You need to add it to each file if its a file specific style - that's
>> fine.
>
>
> Just make it the value of :style in org-publish-projects-alist.
> #+STYLE: just overwrites that.

Yes : file specific as I mentioned above should you want it.  With my
way you can have the basic cascade and the file specifics I think. 

>
>
>>> An other solution to use only one stylesheet, and be able to move files
>>> around (not working through the file: protocol or without network, just
>>> as Bernt's setup):
>>>
>>> #+STYLE: <base href="http://host.domain.tld" />
>>
>> Assuming it is a web specific style this is not necessary using cascades
>> as I outlined and which also works with out "real host" testing. I can
>> see this being possibly necessary when you want to borrow other peoples
>> styles however.
>
> No, not neccessary. Just one possibilty to have a stylesheet in the
> document root, and use just one header for all files.

One header for all the files? Yes. But this can still use cascaded
styles.

>
> If you have http://host.domain.tld/main.css, all files may use
>
> <base href="http://host.domain.tld" />
> <link rel="stylesheet" type="text/css" href="main.css" />
>
> regardless of position in the directory tree.

Of course : hard coded to a single style. A more flexible, I feel,
approach is to use the cascaded styles and have root style include that
host specific one.

>
>>>
>>> If Php is supported on all hosts, you may use the next snippet, to make
>>> it portable (publish on several hosts without changing anything):
>>>
>>> :#+STYLE: <?php
>>> :#+STYLE: echo '<base href="http://' . $_SERVER['SERVER_NAME'] . '" />';
>>> :#+STYLE: ?>
>>>
>>>
>>> That way _all_ the URLs in stylesheets
>>> (background-image:url(images/foo.gif)), image tags, hyperlinks etc. are
>>> resolved relative to http://host.domain.tld.
>>
>> This has further ramifications I think. Namely including things
>> relative. e.g sub dir in a web http:/web/proj1. Normally if I do not
>> provide a full URL I want it relative. e.g "url:./images/proj1.jpg"
>
>
> That's, what the base element is for. The nice part of it is, that all
> _realtive_ paths are relative to the address basis (which makes them
> abolute, yes), which means I don't have to change them, when I move the
> file around.

And thus means the example I gave above is broken. I think I don't like
setting the base href to be honest. It tend to think of it as less
flexible. Sure SOME individual files might want to do this but to set
this up as part of the project definition is losing flexibility and
localization as I outlined above with my proj1 example.
>
>
> It has indeed some disadvantages:
>
>   - relative links will not work for the *.org files.
>   - file: protocol does not work.

And this is a major disadvantage. And one not met with relative cascades.
>
>
> That's why I don't use it here. If I was to publish to a website, I
> would take it in account. No need to change any image URL in the files,
> when moving them from one directory to another.

I'm not sure I understand your meaning here. Moving image files around?
Basically you seem to be advocating hard coded locations as opposed to
project local locations-

>
> /Normal/ links _to_ the file will always stop working, when moving a
> file. That's one of the reasons, why we use databases instead of plain
> HTML files for real web sites. However, the relative links _from_ the
> moved file to others will still work, if you supply a address basis.
>
>
>
> Best,

-- 
 important and urgent problems of the technology of today are no longer the satisfactions of the primary needs or of archetypal wishes, but the reparation of the evils and damages by the technology of yesterday.  ~Dennis Gabor, Innovations:  Scientific, Technological and Social, 1970