Hi Ralf - I'm going to take a second look at revIgnitor - and pretty much agree with the entire approach and the mapping of MVC concepts to Rev. I am looking forward to integrating my code into your framework :)
This is how I see the mapping: *View* Yes the visual appearance of the interface that lays out the data on screen ready for interaction. But specifically it includes any presentation logic such as code for resizing the view, or changing it's visual appearance. Also in general I feel that views map to groups with behaviors - therefore the Datagrid is a view. you should be able to drag and drop views onto cards and ideally nest them within each other, and to do this in a way which is completely independent of your particular applications logic and data. These views usually have custom properties that allow you to get and set their data in a standard way and also to change their appearance - a test of their MVC'ness is the ability to move them around and use them as is without editing their code in any way. I have found it very useful to test out views precisely this way by keeping them in an external library and testing the ability to drag and drop them into a variety of situations (manually or under script control). It would be possible to consider some cards or even stacks as views - so far I don;t do that - but it is possible for instance to automatically create stacks as dialogues which contain group views - so for instance I use the standard video, image, xml, and tree views to display data in a window using a command such as "display_Image someUrl" which creates a new stack, and copies the image view to that stack. It's a side effect of creating a good view that you also create some good dialogue stacks. *Models* I've not done that much on these and intend to use Trevors sqlYoga, and / or the work that Ralf has done. The important bit for me is the ability to move from arrays to databases - so I have an abstraction layer that uses arrays, but can easily be switched to XML or a database. *Controllers* The glue. I agree with Ralf that the best place usually for this code is the card script. And in simple terms it does everything else required to glue the views to the data. It is where the code that really defines the logic of your application is. I have a way of creating this code which automatically creates a basic interface - so this is often where I start coding -dragging a few basic views onto screen to display the data, and gradually defining the model. At the end I create new custom views for the application - perhaps by cloning one of the existing ones and if it is useful adding it to the library. _______________________________________________ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution