On 2012-06-28, Tim Howe <th...@bendtel.net> wrote:
> On Thu, 28 Jun 2012 11:09:37 -0700
> patrick keshishian <pkesh...@gmail.com> wrote:
>
>> On Thu, Jun 28, 2012 at 10:53 AM, Tim Howe <th...@bendtel.net> wrote:
>> > On Thu, 28 Jun 2012 10:26:52 +0200
>> > Marc Espie <es...@nerim.net> wrote:
>> >
>> >> If you guys are serious about anything, go look at ports-readmes.
>> >>
>> >> It does extract information from the ports tree, and creates readmes for
>> >> all ports.
>> >>
>> >> Currently, it's a static port. It could very well be a dynamic
>> application.
>> >>
>> >> You can experiment with css, you can experiment with nginx.
>> >>
>> >> Preferably, don't add large dependencies (python or ruby out of the
>> question),
>> >> write it as a perl fcgi or something, you can use Plack or Catalyst or
>> >> whatever.
>> >>
>> >>
>> >> Or hey, at least tweak the templates to be nicer.
>> >
>> >        Perl FTW.  I think the site could easily be built with ttree.
>> > You will have easy to manage templates and content that anyone with
>> > some html knowledge can edit as easily as before; plus you will have
>> > static html output.  Parts that should be templated can be in a
>> > flexible and easy to decipher/learn way.  Little or no knowledge of
>> > Template::Toolkit would be required for most changes to be made.
>> >
>> >        It's pretty easy to bootstrap with your existing layout and
>> > content.  The build process could be managed with an easy make script.
>> > Template Toolkit is in the ports tree.
>> >
>> >      
>>
>  http://www.devshed.com/c/a/Perl/Building-a-Complete-Website-using-the-Templa
>> te-Toolkit/
>>
>> from the page you referenced:
>>
>>      | Although HTML is simple, it does tend to be rather
>>      | verbose. It's all too easy for the core content of
>>      | the page to be obscured by the extra markup
>>      | required around it
>>
>> Then, the next link on that page takes you to:
>>
>>
> http://www.devshed.com/c/a/Perl/Building-a-Complete-Website-using-the-Templat
>> e-Toolkit/1/
>>
>> Yes, that *IS* much, /much/ better than the initial HTML.
>>
>> --patrick

It is, but their spelling of names of fictional planets is atrocious ;)

>
>       90-something percent of the files would only contain the html
> content and a tag that references what wrapper is used for it.  Editing
> content would not require knowing or working around any TT markup,
> which was the main point I was trying to make.
>
> --TimH
>
>

The only way I can see this really working whilst keeping things in
CVS is if the generated HTML is removed from the CVS web tree,
otherwise it's likely to get edited directly and we have a
mess where changes have to be merged back to the source files as
already happens with the existing templated pages on occasion.

So IMO the whole site would need to be generated automatically
from templates either on the web server and mirrors, or on some
other trusted machine generating pages to feed out to these.

As such, whatever templating system is used is going to have to
be acceptable to people running the website and mirrors (or at
least a trusted central machine) to run *automatically*.
The existing mirrors will need to change how they sync, and
the people working on website (including translation) would
need to adapt tools and working methods.

I do see advantages from switching to something like this,
e.g.: easier way to do manpage references, automatically
generating tables of contents, single system for building
everything, having an easier way to template translations of
the common generated parts (ftp.html, groups.html etc).

But OTOH these aren't *all* that fiddly/annoying to do
anyway and the areas that really benefit from templating already
have it (albeit hand-rolled and maybe not quite as nice as TT).
So even before considering what's involved in moving the site
content across, there'd need to be a decent improvement and
saving of ongoing work to be worth the effort to change
existing infrastructure ... worth it? maybe, but if it's at
the expense of time spent on improving the content (and there
are areas which could _really_ use work to catch up with
changes in the last 5+ years *cough*networking*cough*),
then I'm not so sure...

Reply via email to