Adrian Rossouw wrote:
We need to separate out the actual variables needed, into their own function (ie: getting rid of all that horrendous '#tree' logic, and actually just defining the two trees separately). We also define the actual type of the variable (ie: integer, blah), wether they are optional or not. etc, which ties into the validation. This is the level where CCK would get integrated.
Then each model, can have multiple views. Only one of these views is a form.
I just want to comment on that last sentence, in case it didn't jump out at everyone else; Adrian is saying we will be able to theme atomic data... not just whole nodes, with multiple views. This data, thanks to CCK, will be available at two levels; the field level, and the type level (sorry if the terms aren't in CCK-speak). That means, in an event, you can theme the calendar widget for the date (field level), as well as the whole event (including location, ticket price etc). And you can do each of these tasks several times, giving each different representation a name, called a view. If you can get your hands on the appropriate data and make the right function call, you can generate any view of any data and embed it into anything else. So if I wanted show the *when* of my concert schedule, I'd call a function that asked for "Events as times". I'd get a list of starting and ending times for my events (because the event@time view of an event returns only times). And if I wanted to show the *where* of my events, I'd use the "Events as locations" view. perhaps this would return a Google map, because that's the way I built the event@location view. Of course there is the "Event as form" view (for editing events), and the "Event as event" view, which shows the whole event and all its info. Adrian's plans for us are pretty incredible. If anyone hasn't comprehended his meta-view of Drupal, you should pester him with questions until you do. -Robert