Re: [Firebird-website] [Firebird-general] Re: Fb Website

[Pavel C. <pc...@ib...>]

marius adrian popa napsal(a):
> I talked with my boss Dan Masca from reea.net and we will alocate
> people for this task (we have something like 100
> people:designers/webprogramers/linux admins )
> I will be the project manager and the contact point

That's great and your help is greatly appreciated.

> Also on the list we should talk about project specs
> 
> 1.We need a few designs to choose from

I'd rather start with content requirements / site layout, then we may
proceed to actual design. I'll post my take on it as separate thread.

> 2.From designs mockups I should create the html (modern css based)

Actually, it should be a set of HTML templates. The "sketch" HTML could
be a start until we'll decide what template system we'd use.

> 3.On final stage we should implement it in the actual code (we need
> access to the code)

Although the current site uses PHP, the amount of code is minimal (plus
a lot of now defunct artefacts). It's mostly a glue code to assemble
pages from various bits and pieces. The content itself is stored in flat
text files (HTML chunks or PHP variables as data records). It's quite
simple but very effective. I'd like keep it that way, although I would
rather abandon PHP for something better (Python or Ruby) to handle the
glue, and real HTML templates stored separately (now it's inside the PHP
boilerplate code).

BTW, I'm willing to commit myself to write the glue code in Python once
the site structure would be defined. It's actually not much work using
Pylons or any other modern framework, because all we need is just
intelligent URL routing and some information gathering for templates.
The real devil is in the templates itself, which I'd gladly delegate to
someone more skilled in web design :)

> Later we can
> Choose an cms that supports firebird : drupal or later next year
> wordpress (after is ported)
> or site must be codded in something modern like django/cakphp

We used CMS before and ditched it in favour of flat files. Working with
content via web interface is slow and complicated, backup is
unnecessarily complicated especially when any database is involved,
there are security risk etc. It's great for sites over you haven't full
administrative control and where almost everybody makes content, but
that's not our case. We have only few webmasters that work with the
content and we have the full control over the website's computer.

On the other hand with minimal code behind and no database, it's really
easy to have a local copy of the site kept in sync via rsync, unison or
any syncing tool you like, and edit the content in your favourite text
editor. The side effect is that we have several backup copies of the
site all the time (each webmaster has one). It's also possible to store
everything into SVN.

The content is now stored as HTML "chunks" in separate files which isn't
the best option (one must know and use the HTML/CSS used by our site),
so I'd like adopt some more markup-independent format (reStructured Text
is great candidate) for new one, but I'd like keep the general concept
for content management.

best regards
Pavel Cisar