Re: [website-dev] is there a way to clean the template code of OOo
TJ Frazier <[email protected]>
| Newsgroups | gmane.comp.openoffice.devel.website |
|---|---|
| Message-ID | <[email protected]> |
On 5/11/2010 08:29, Christian Lohmaier wrote:
> ...
> Well, any effort now, before the migration to Kenai would be a waste
> of efforts IMHO. Better be the first to raise your hand when the
> staging server is available. I'm pretty sure we need to do some more
> or less heavy adaption of the website anyway.
>
> [snip]
>
> Yes, css is full of legacy cruft. But it isn't easy to just throw out
> everything as OOo is huge and you never know who else is using parts
> of it.
> Not to mention the servlets, IZ, Mailinglists, anything that is
> dynamic basically. That combined with different level of access rights
> (not all users see every control available), then you need to be extra
> careful.
>
> But yes, the migration to Kenai is a great opportunity to get this
> straight/to clean up.
> ...
It seems just common sense to put off changes until the conversion, but
sometimes common sense is just ... wrong.
Forgive the old guy for maundering on, here, but in forty years of
systems programming, I got called in on a /lot/ of conversions,
upgrades, re-hosting, ... Here's my advice from down in the trenches.
Any improvements you can make in the old code, /provided/ they can be
completely tested and shown to work, are very worth doing. "Mission
creep" is a deadly enemy of good conversions. Doing the work now also
allows for major "schedule slip" in the conversion ("We won't be able to
start for another six months."). It makes the conversion effort easier
because it defines what the output should be, and reduces the level of
expertise required for the conversion. It also allows for the inevitable
"got to have this" work, which will tie up the resources one might
fondly imagine would be available for cleanup. (I'm thinking of old
PITAs like unified login, and message numbers on e-mails, not to mention
golden-rule stuff like re-branding.) In short, do as much as you can
ahead of time; you'll be glad you did.
And if there are "cruft" parts of the code that are in fact being used
in some obscure place, the time to find that out is /now/ -- some
feature may be wacky for a day, until we restore the missing code, but
it may be missing for a long time if we suddenly discover that it needs
to be converted.
--
/tj/