Philippe Bossut wrote:
John Anderson wrote:
Blocks should always be model, widgets should always be view.
I'm assuming this to make sense of the next paragraph.
If the selection isn't part of the block or the collection it won't
be persisted, which won't work. In relality the selection is stored
in both the widget and a block or collection.
As far as I remember, Views are supposed to be "data ignorant". For
sure, a model data cannot be stored in Views and Model at the same
time. So, either:
- Block/Widgets/xx are not following the MVC model and we should not
continue to use this term in the discussion
or
- We need to fix Block/Widgets so that they are conforming to MVC
I have no religion as to whether or not we should use MVC and I know
of quite a few good UI that didn't use them. I think however we should
not call something MVC if it's not.
I don't agree with this. I think the MVC description make sense in this
context and helps improve the understanding and simplify the design --
even though a widget (which we don't control), happens to also have a
local cache of the data (which isn't persisted).
We need to keep they in sync. If the widget changes its selection we
need to reflect it in a persistant model. If something outside the
platform changes the persistent model we need to have a way to
sychronize the widgets's idea of the selection.
So, MVC discussion aside, it looks like widgets and blocks should be
able to decide individually when receiving a notification if they are
already synced or not and, if they are, hold off generating
notification themselves, therefore stopping the notification generation.
It's often difficult to write a piece of code that can tell we're
already synced, so we sometimes have to update more than what really
changed. Therefore, any time we can easily eliminate unnecessary
notificaitons it's nice to take advange of them.
Philippe
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev
