Top Note: This has become an example of how to edit several parts of the website including adding xslt.
- XSLT. - SSI - How html pages are transformed into AOO branded html pages. - Top Navigation customized for an NL. - Page Template Skeleton - Branding - including Header and Footer construction. On Sep 29, 2012, at 12:16 PM, Rob Weir wrote: > On Sat, Sep 29, 2012 at 2:40 PM, Dave Fisher <[email protected]> wrote: >> >> On Sep 29, 2012, at 2:25 AM, Andrea Pescetti wrote: >> >>> Rob Weir wrote: >>>> A technical solution could be to put the strings into their own XML >>>> file, so different localized versions could be used. These would be >>>> strings like column headers, the text of the disclaimer, etc. >>> >>> This would be perfect, and flexible enough. >> >> The CMS can be setup to build XML files from XSLT files with only some >> slight efforts with perl. >> >> Here are eccn / exports from the lib/view.pm for www.apache.org: >> >> sub exports { >> my %args = @_; >> my $template = "content$args{path}"; >> $args{breadcrumbs} = ASF::View::breadcrumbs($args{path}); >> >> my $page_path = $template; >> $page_path =~ s/\.[^.]+$/.page/; >> if (-d $page_path) { >> for my $f (grep -f, glob "$page_path/*.mdtext") { >> $f =~ m!/([^/]+)\.mdtext$! or die "Bad filename: $f\n"; >> $args{$1} = {}; >> read_text_file $f, $args{$1}; >> } >> $args{table} = `xsltproc $page_path/eccnmatrix.xsl >> $page_path/eccnmatrix.xml`; >> >> } >> >> return Template($template)->render(\%args), html => \%args; >> } >> >> and the lib/path.pm: >> >> [qr!^/licenses/exports/index\.html$!, exports => {} ], >> >> >> Done properly we can drop the NL files in a consistent area. Interesting... >> >> Ideally all that should be changed is the XML and then the site is properly >> rebuilt. >> >> What will this xlstproc call look like if there are two XML files - one for >> columns and the other for data? >> > > I don't know xsltproc, but most XSLT engines have a way to pass in an > XSLT parameter via the command line. So we'd pass in the locale id, > e.g., "it" for Italian. Then within the XSLT we could use the > document() call to load a string resource file whose name is based in > part on the locale, for example, strings_<locale>.xml. Or > <locale>/strings.xml, depending on whether you want these centralized > or not. > > But one other assumption to check: can we pipeline the CMS processing > steps together? In other words, if we generate a bare-bones XHTML > from the XSLT transform. can we then feed that XHTML back into the CMS > to apply the usual template for the header/footer, etc.? Sure that's very much what we already do with all of the existing html: (1) Strip out header, body tag and content. (2) Push the existing html through the CMS templating engine. I'll annotate the process because the ssi part if important to consider here: sub html_page { my %args = @_; my %styleargs = @_; my $file = "content$args{path}"; my $template = $args{template}; $args{breadcrumbs} = breadcrumbs($args{path}); (a) Get the html file contents read_text_file $file, \%args; (b) Each page may have an attachments directory with mdtext special content - read those. my $page_path = $file; $page_path =~ s/\.[^.]+$/.page/; if (-d $page_path) { for my $f (grep -f, glob "$page_path/*.mdtext") { $f =~ m!/([^/]+)\.mdtext$! or die "Bad filename: $f\n"; $args{$1} = {}; read_text_file $f, $args{$1}; } } (c) Grab the folder or main ssi.mdtext defining special items like translations. my $ssi_header_file = ssiheaderfile($args{path}); $args{ssi} = {}; read_text_file $ssi_header_file, $args{ssi}; (d) Extract the head, bodytag and content from the html file contents if ($args{content} =~ m!<head.*?>(.*?)</head>(?:.*?<body(.*?)>)?(.*?)(?:</body>|\Z)!si) { @args{qw/head bodytag content/} = ($1, $2, $3); } (e) Create the breadcrumbs for the header $args{breadcrumbs} =~ s/home/$args{ssi}{headers}{home}/; (f) Render through the templating engine with the collected arguments. return Template($template)->render(\%args), html => \%args; } (3) ssi.mdtext files are used to do folder specific ssi overrides into the template: templates/ssi.mdtext doctype: /doctype.html brand: /brand.html footer: /footer.html topnav: /topnav.html home: home templates/it/ssi.mdtext doctype: /doctype.html brand: /it/brand.html footer: /footer.html topnav: /it/topnav.html home: home Adding a consultant tag to these files makes sense. (4) content/it/topnav.mdtext The place to put this new consultants link would be in these files. divid: topnava - [Prodotto][m0] - [Download][m1] - [Supporto][m2] - [Estensioni][m3] - [Modelli][m4] - [Collabora][m5] [m0]: /it/informazioni/prodotto/writer.html "Descrizione di Apache OpenOffice" [m1]: /it/download/ "Scarica OpenOffice" [m2]: /it/supporto/index.html "Supporto per OpenOffice" [m3]: http://extensions.openoffice.org "Estensioni per OpenOffice: aggiungi nuove funzioni" [m4]: http://templates.openoffice.org "Modelli di documento per OpenOffice" [m5]: /it/contribuire/index.html "Aiuta il progetto OpenOffice" (5) templates/skeleton.html FYI - the full page - note the ssi.headers variables come from the selected ssi.mdtext. <!--#include virtual="{{ ssi.headers.doctype }}" --> <html> <head> <link href="/css/ooo.css" rel="stylesheet" type="text/css"> {% if head %}{{ head|safe }}{% else %} <title>{% block title %}{{ headers.title }}{% endblock %}</title> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> {% if headers.css %}<link href="{{ headers.css }}" rel="stylesheet" type="text/css">{% endif %} {% endif %} <!--#include virtual="/google-analytics.js" --> </head> <body{% if bodytag %} {{ bodytag|safe }}{% endif %}> <!--#include virtual="{{ ssi.headers.brand }}" --> <div id="topbara"> {% if ssi.headers.topnav %}<!--#include virtual="{{ ssi.headers.topnav }}" -->{% endif %} <div id="breadcrumbsa">{% block breaddcrumbs %}{{ breadcrumbs|safe }}{% endblock %}</div> </div> <div id="clear"></div> {% if ssi.headers.leftnav %}<!--#include virtual="{{ ssi.headers.leftnav }}" -->{% endif %} {% if ssi.headers.rightnav %}<!--#include virtual="{{ ssi.headers.rightnav }}" -->{% endif %} <div id="content"> {% block legacy %}{% if ssi.headers.legacy %}<div class="legacy">{{ ssi.headers.legacy }}</div>{% endif %}{% endblock %} {% block title %}{% if headers.title %}<h1 class="title">{{ headers.title }}</h1>{% endif %}{% endblock %} {% block content %}{{ content|markdown }}{% endblock %} </div> <!--#include virtual="{{ ssi.headers.footer }}" --> </body> </html> (6) content/brand.mdtext You are certainly familiar with this parallel structure. home: home search: search name: Apache OpenOffice (incubating) tagline: (incubating) | The Free and Open Productivity Suite logo: AOO_logos/OOo_Website_v2_copy.png domain: www.openoffice.org divid: bannera announce: Please help us collect and rate ideas for OpenOffice 4.0 announceurl: https://www.google.com/moderator/#16/e=2011d5 announcetip: Read the announcement (7) templates/brand.html This is really more about the site banner is more about refresh and transition to TLP. <div id="{{ headers.divid }}"> <div id="bannerleft"><a title="Apache OpenOffice (incubating)" href="/"><img id="ooo-logo" alt="{{ headers.name }}" src="/images/{{ headers.logo }}"/></a></div> <div id="bannerright"> <a title="Apache Incubator" href="http://incubator.apache.org";><img id="asf-logo" alt="Apache Incubator" src="/images/apache-incubator-logo.png"/></a> <div style="relative; margin: 14px 0 0 0; height: 24px;"> <form id="cse-search-box-header" action="http://www.google.com/search"; method="get"> <div> <input type="hidden" name="domains" value="{{ headers.domain }}"/> <input type="hidden" name="sitesearch" value="{{ headers.domain }}"/> </div> <div class="topsrchbox"> <input name="resultsPerPage" value="40" type="hidden"/> <input name="q" id="query" type="text"/> <input name="Button" value="{{ headers.search }}" type="submit" class="topsrchbutton"/> </div> </form> </div> </div> {% block tagline %}{% if headers.tagline %}<div id="bannercenter"><br/>{{ headers.tagline }}</div>{% endif %}{% endblock %} </div> {% block announce %}{% if headers.announce %}<div id="announce"><a href="{{ headers.announceurl }}" title="{{ headers.announcetip }}">{{ headers.announce }}</a></div>{% endif %}{% endblock %} (8) templates/footer.html Remove the disclaimer - other changes? <div id="{{ headers.divid }}"> <div id="poweredbya"><p><img src="/images/feather-small.gif" alt="Apache Feather"/></p></div> <div id="copyrighta"> <p style="text-align:center;"> <a href="/license.html">Copyright & License</a> | <a href="/privacy.html">Privacy</a> | <a href="/contact_us.html">Contact Us</a> | <a href="http://www.apache.org/foundation/contributing.html#Paypal";>Donate</a> </p> <p> Apache and the Apache feather logos are trademarks of The Apache Software Foundation. OpenOffice.org and the seagull logo are registered trademarks of The Apache Software Foundation. Other names appearing on the site may be trademarks of their respective owners. </p> <p> Apache OpenOffice is an effort undergoing incubation at The Apache Software Foundation (ASF), sponsored by the Apache Incubator. Incubation is required of all newly accepted projects until a further review indicates that the infrastructure, communications, and decision making process have stabilized in a manner consistent with other successful ASF projects. While incubation status is not necessarily a reflection of the completeness or stability of the code, it does indicate that the project has yet to be fully endorsed by the ASF.</p> </div> </div> (9) Rebranding is easy to do and reverse. Regards, Dave > > -Rob > > >> Regards, >> Dave >> >>> >>>> Another solution would be to have one master consultant listing, but >>>> add a field to indicate the geographic scope of their business. ... >>>> Pardon my ignorance here, but how do consultants tend to work in >>>> Europe? Are they easily able to offer services through the EU? >>> >>> This option is probably not needed. Individual consultants will often work >>> within one country only, and those who offer services in multiple countries >>> can fill in multiple applications (and then we would have the issue that >>> geography and language do not map one-to-one, so this approach couldn't be >>> easily generalized). >>> >>> Regards, >>> Andrea. >>
