[General] About the MVC pattern

> Hi,
>
> I'm trying to grasp the MVC pattern in LK. There seems to be
> alternative approaches for constructing the model.@least
> subclassing the Model class and using Records.
>
> I'd appreciate if someone could explain the motivations of the
> different approaches. I'd be also very interested in your assessment
> of the stability of the current implementation, and of course possible
> future plans.
>
> After some experiments and reading the code, I've got the impression
> that the Records approach is suitable when the model is a simple data
> model and you can use the Record's getter/setter magic. And when the
> model is more complex and should contain some logic, you should
> subclass Model. Please comment weather this is to the point or not.
>
> BR,
> Juhani R?nkimies
>
> _______________________________________________
> General mailing list
> [hidden email]
> http://livelykernel.sunlabs.com/mailman/listinfo/general

> Hi Junani,
>        the current codebase is indeed confusing in this area, mostly because
> it contains two different architectures for MVC, the new one and the old
> one, preserved for compatibility (since not all the code has been ported to
> the new architecture).
>        In both the new and the old architecture, in principle every object
> can act as a Model. Objects not specifically designed to be models can act
> as models, as long some of their methods are designated as model variable
> getters and setters. Those model variables may or may not correspond to
> actual JavaScript properties, i.e., they may be computed. The
> View.connectModel() method specifies which  concrete JavaScript methods of
> the model object act as getters and setters of the View's abstract model
> (*).
>        But since any object can be a model, there's no universal mechanism
> for the model to notify views that a model value has changed. To address
> this need, the old mechanism provides the Model class, which keeps track of
> the views it's connected to (its dependents), and notifies them when its
> variable values change. The new mechanism doesn't use Model any more, and
> instead relies on the Record class, which itself doesn't know anything about
> MVC, but it knows how to notify observers when its property values change.
> Thus Record is a convenient Model, but not every Model has to be a Record
> (Records could also be used independently of the MVC pattern). On the other
> hand, Records currently do not support computed variables, and so for every
> getter/setter pair there is a JavaScript property defined in the Record
> instance.
>
>        In terms of specific examples, NetRequest typically uses a model that
> is not a Record, since it only writes to the model and is typically not
> interested in receiving updates when model values change. The WeatherWidget,
> on the other hand, uses a Record for its model, because its views are
> interested in receiving notifications when model variables change.
>
>        I hope this is useful, if not, please keep asking. As far as the
> stability of the implementation, well, I think there's room to simplify and
> generalize the new MVC architecture, although it's already used quite
> extensively by Fabrik and other parts of the system. Ideally the old MVC
> architecture would be phased out and pruned from the codebase, but it hasn't
> happened yet.
>
>        Krzysztof
>
>
> (*) I try to use the words 'formal' and 'actual' in this context, in analogy
> to function invocation terminology: every View has its own notion of what
> its model is, and uses formal model variable names, much like a function
> body uses formal argument names. When the Model is connected to the View,
> the model's variables are in a way similar to actual arguments of a function
> invocation. The Model-View hookup provides a mapping between View's model
> variables (formals) and the getters and setters of the Model (actuals), much
> like a function invocation creates a mapping between formal and actual
> arguments.
>
>
> On Dec 14, 2008,@4:28 AM, Juhani R?nkimies wrote:
>
>> Hi,
>>
>> I'm trying to grasp the MVC pattern in LK. There seems to be
>> alternative approaches for constructing the model.@least
>> subclassing the Model class and using Records.
>>
>> I'd appreciate if someone could explain the motivations of the
>> different approaches. I'd be also very interested in your assessment
>> of the stability of the current implementation, and of course possible
>> future plans.
>>
>> After some experiments and reading the code, I've got the impression
>> that the Records approach is suitable when the model is a simple data
>> model and you can use the Record's getter/setter magic. And when the
>> model is more complex and should contain some logic, you should
>> subclass Model. Please comment weather this is to the point or not.
>>
>> BR,
>> Juhani R?nkimies
>>
>> _______________________________________________
>> General mailing list
>> [hidden email]
>> http://livelykernel.sunlabs.com/mailman/listinfo/general
>
>

> .....
> Wouldn't it be easy to add something like Record.newPlainClass(spec)?
> (at least if the default values for the properties are ignored)
> It could then be used like this:
>
> Record.newPlainClass(spec).subclass('MyModelClass', ...);
>
> where MyModelClass could define functionality around the generated
> getters and setters.
>