cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Washeim <>
Subject Re: Thoughts on a data-driven web site
Date Thu, 22 Jun 2000 22:10:43 GMT
on 22/6/00 9:16 pm, Stefano Mazzocchi at wrote:

> Jonathan Stimmel wrote:


>> Too often, some VP
>> will say to an engineer, "we just made a deal, and have committed
>> to implementing this complex new feature by next week" (slightly
>> exaggerated).  By making it easy to hack the infrastructure to do
>> a quick hack, the VP will be encouraged to do so again, leading
>> to another hack, until the site ends up being a giant collection
>> of hacks (which we already have :{).
> Cocoon1 doesn't help, I totally agree. But here we talk about C2 and the
> sitemap gives you the control tool you needed to ensure your lazy
> engineers do their job the "elegant" and designed way.... or go thru
> loops to make the sitemap change.

Ok, guys, reality check time.

I'm the chief bru-ha-ha, CTO, of one company, TD of another. I attempt, as
much as I'm able, to protect developers from slash and burn
'dis-engineering'. Most honourable, professionals in my kind of position
will do the same. 

However, at some scale (once you have more than 10 large clients and 40+
developers) it is inevitable that some projects will need to be executed
under less than favourable conditions.

That is, we will contrive a hack. It will happen.

What I wish to express is that cocoon (1.x.x for that matter, with which I'm
currently 'hacking') encourages SOUND engineering. Even novel, elegant
practices ( xsp tag-libs positively discourage hacking, in fact enforcing

I suggest that you leave the hack-a-bility well enough alone. Otherwise,
cocoon will be passed over for numerous projects precisely because it
enforces more discipline than may be allowed in some cases. Honestly,
engineers who are professional will, with time, re-work the hacked version
into something of beauty (I know that my team working on eurofootball
certainly will). 

It is also just plainly and always that re-factoring will take place.
Usually, after something akin to prototyping. Web-apps, by the very nature
of the market-place in which they exist tend to be prototyped and are rarely
entirely designed from the get go. Perhaps it's different within the IT
departments of large corporations. They, however, cannot compete in the
market I operate in. In fact, most of their projects take years to complete
and often fail at that.

My company in Canada, Critical Mass, would simply be unable to compete if we
had to engineer everything using, as we often do in re-factoring, use cases,
conceptual models, etc. We must use these techniques after some more rapid
process if our software isn't eventually going to fail to be maintainable,
scalable, etc . . .

I really believe that Cocoon will promote good practice and bad practice
will persist despite cocoon if need be. In the end, it's a question of
setting a good example in the context (which tag-libs do).

My two bits.

Mark (Poetaster) Washeim

'On the linen wrappings of certain mummified remains
found near the Etrurian coast are invaluable writings
that await translation.

Quem colorem habet sapientia?'

Evan S. Connell


View raw message