Thomas Tuddenham  wrote:
> I'd prefer to have classes-based application, with some class(es)
> responsible for presentation tasks. Then anyone will be able to
> extend them to use templates (or even Smarty itself), XSLT or any
> other mechanism.
> I think some kind of MVC is needed.
Some kind of object model would be good. I'm crap at reading
procedural code nowadays - I've been spoiled. But it would help to
have an OO model as the basis for the architecture - just to give it

Yes, the "traditional" procedural code is ok while you're writing it, but will become *not obvious* just after a month :-)

Out of curiousity, why avoid frameworks? Surely it's better to
leverage off common code than to recreate the same value as someone
else - just my personal beef about the way we software developers
tend to scratch the same itch over and over again.

I agree. Perhaps, it's just a [bad] habit of mine... Sometimes they seem to produce too much code.
I prefer to use someone's classes rather than whole frameworks.
But, from the other hand, any framework is a pack of classes :-)
>> I'm at a bit of a crossroad and am not sure whether I should be
>> spending
>> time on the Rails port of PHPSurveyor or spend my time adding
>> directly
>> to the PHP version. Knowing where we're going architectural-speaking
>> would help me understand where's the best place to throw my energies.
> Yes, applied to future development, this is exactly what I've meant.
> Not quite sure what you mean by "Rails port"...
> I was thinking of making some external classes to call their
> methods in current code (not too far in future, though :-)

The Rails port was my attempt at converting PhpSurveyor to Ruby on
Rails. I've just had a half hour talk with a mate of mine where I
pretty well convinced myself to drop the project - for the same
reasons as above. I'd rather add value to PHPSurveyor than recreate
that same value in a different language - even if I find Rails easier
to work with. What I'd like to do is give PhpSurveyor a RESTful
interface - possibly the same idea as your "external classes".

I think you're right. PHP has it's own OOP capabilities quite powerful nowadays.
Also, it's possible to create structure (and OOP schema) regardless to any language, isn't it?

>> BTW, I'm also working on an updated admin interface based on the
>> BaseCamp UI.
> That would be great!
> So far I've got only an approx. idea of "my" interface (discussing
> user tasks with client). ...
> BTW, the BaseCamp UI seems a bit too heavy (at least for my needs)
> - it loads almost 1mb for each couple of screens. Are you
> reproducing the whole thing (ajax etc) or just the main look/
> functions?

Errm.. what the hell are you doing to BaseCamp to pull down 1mb? The
BaseCamp UI is pretty light - no images per se and pretty simple
CSS / Javascript, etc. I just ran a few screens through Firefox and
the most I came up with was 78Kb. And BaseCamp is the new 'Outlook'
you know.. everyone's copying it :)

As far as I can judge (worked with it mostly last summer), they're  tracking user history etc which causes a load of this large.
BUT, it was almost a year ago!  37Signals is a very progressive team, so current interface can be much better.
As to  "everyone's copying" - it depends :-) Each users group has specific habits etc, so sometimes BaseCamp-like UI can be a huge overkill. Especially if users are "not too literate" and not familiar with BaseCamp.