search

symphonycms / getsymphony-html

Symphony Community Site - HTML Templates
http://symphonycms.github.com/getsymphony-html/
9 stars 3 forks source link

Including the Network and Footer #2

Open nilshoerrmann opened 11 years ago

nilshoerrmann commented 11 years ago

Factory bundles two XSL templates for the network and the footer. Our idea was that these templates are used directly so that we can push changes to those areas of all network sites by updating Factory. Those files are static at the moment but they should be replaced by dynamic versions as soon as we have an official XML source on getsymphony.com we can use here.

So – in order to be future-proof – I'd like to suggest to directly link to /workspace/assets/themes/xsl/ and remove the identical files in /workspace/utilities/.

bauhouse commented 11 years ago

I like your thinking, Nils. I'll fix that up. What do you think of the location of the Factory assets? Does it make sense to you to have them in a themes directory? Theming isn't something that we've talked much about, but I think it would be good to suggest a standard approach.

nilshoerrmann commented 11 years ago

When working on Factory, I was thinking about something like /workspace/factory. My first idea was /workspace/assets/factory but we then started bundling XSL files and these are normally not stored in the assets folder in Symphony projects.

As we don't have different network themes so far, I wasn't thinking of that term. In my eyes factory is the new Symphony metaphor for network theme. So if the network will be redesigned in a few years time, this will just be a new version of Factory in my eyes (the name belongs to Symphony, not to us, so it doesn't matter who is in charge of the design).

Of course, every network site owner can name these folders as he likes, but certainly the main site will set a standard. So I'd just use factory instead of theme as mentioned above. But actually, it doesn't really matter :)

Are there any advantages for us to use the more abstract name theme?

/cc @johannahoerrmann

bauhouse commented 11 years ago

I was thinking ahead to be able to easily apply different themes to the same functionality as what we will be delivering with the ensemble, so, if anyone wanted to create something similar, it might be a relatively simple task to swap out the Factory framework with a different design. That might be thinking too far ahead, but I wanted to at least have that option in mind as I was putting the templates together.

I agree that it doesn't really matter, so for now, I will keep it simple and follow your suggestion, Nils:

something like /workspace/factory

bauhouse commented 11 years ago

I was considering your request to include the network.xsl and footer.xsl files, and now as I am trying to see how that could happen, I am realizing that there is a dependency on the $config variable that is declared on line 15 of the docs.xsl and whose value is defined in the config.xml file. I suppose I should redeclare the variable in the site's master.xsl template, where I can define the value as I like.

Because the Factory configuration file hard-codes the root URL, it becomes a problem if you want a URL that is going to work across multiple GitHub repositories when generating the GitHub pages and working in localhost development environments. So, this might be the way to go when we get around to deploying, but while this is in development, it's really cumbersome.

I am trying to keep the generated HTML files environment-agnostic by generating relative URLs.

Do you have any suggestions on how I can pull in the network and footer templates and be able to deal with the dependency on the root value?

nilshoerrmann commented 11 years ago

Ah, right, I haven't thought about that when introducing the $config variable. In this case, the Factory templates have to be adjusted to match the standard Symphony $root declaration.

Because the Factory configuration file hard-codes the root URL, it becomes a problem if you want a URL that is going to work across multiple GitHub repositories when generating the GitHub pages and working in localhost development environments. So, this might be the way to go when we get around to deploying, but while this is in development, it's really cumbersome.

We had to hardcode the configuration because we weren't able to generate links that worked across our different environments (localhost subfolders vs. Github Pages). So right now we set the configuration manually on all forks and mark the file as unchanged (not sure if that is actually a Git or a Tower command).

I'll have to check that out again.

bauhouse commented 11 years ago

For now, I'm doing things a little differently, to be able to dynamically render the network navigation and set the active class for the current site.

I load the _network.xml file in the master.xsl template.

I wasn't successful with GitHub pages (waiting more than 10 minutes to find out there was an error), so I'm testing the HTML on my own domain.

bauhouse commented 11 years ago

Just to be clear here, I was able to get the HTML rendering just fine for the GitHub pages.