[TYPO3-ect] MVC Project

[Jeff Segars]

Hey Michael.

> Jeff, this is awesome news! I was going to work on exactly this after my 
> thesis is done (still a long way to go), but the similarities are really 
> striking (btw. even my class is called TCAobject ;)).

Thanks for your interest!  If I remember correctly, you've used Rails 
lately, right?  My ideas have been heavily influenced by ActiveRecord 
for Rails and Hibernate for Java.  Funny coincidence on the naming :)

> I'd be very curious to see more of your code and I am really confident 
> that this will be a nice base for 5.0 core. As I am not in the R&D-Team, 
> I can't give any official statement, but I know that Kasper very much 
> supports this approach.
> I don't know how far you are with this, but it looks absolutely promising.

The code is at the point being very workable for demo purposes.  Reading 
from the database has been tested the most, but record insertion and 
update are both working too.

I need to do a little more code cleanup before its ready for any eyes 
but my own, but I should have it in our public Subversion repository in 
the next day or so.

>> $user = tx_tcaobj::find(3); // Returns the user object with ID 3
> 
> My (dummy) code looks extremely similar to this, although the above 
> misses the table parameter in the constructor (which TCA should be used 
> for the model).

Oops, you're right.  Should have been....
 >> $user = tx_tcaobj::find('fe_user', 3);

> Second, do you have separate classes for every column? E.g. wouldn't it 
> be even more elegant if you could just do
> $user->username = "michael";
> $user->save();

This was my initial thought as well and its definitely a cleaner approach.

I ended up going with a separate object, however, because validation and 
other things that can be applied to each column seem to work better 
within the class hierarchy.  I think having a separate class also puts 
us in a better position for a view component like scaffolding at a later 
date since we'll know the type of each column from its object type.

If there's a way that those things can be accomplished without the 
overhead of a class, though, I'm all for it :)

> Anyway, these are details. We should definitely move this issue out of 
> ECT and into -dev, as it is a core issue.

Sure, I've been trying to keep it quiet until I was sure this was a 
concept that would work.  I feel like it's far enough along now that I 
know it's not a terrible idea that I'll want to throw away:)


Thanks,
Jeff