revigniter - Model-View-Controller in Rev terms?

[David Bovill]

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.