I've read through Michael Haufe's example a few more times, and
re-read the old article by Peter Michaux. And through all of it, I like
the idea of structuring stuff. The major divisions of responsibility
make sense. And to a certain extent, the lines of communication
make sense. But in all of these implementations there feels (to me)
like a whole lotta stuff I don't need. Or don't need yet. Or don't understand. Or something.
So I've tried to build everything up as simply as I could manage.
I don't need to dynamically change the list of observers beyond
adding at least one: so it's just one one-liner function; etc. I did run
in to one weird corner in trying to make a Button out of a View.
It doesn't really need a model. But I have to give it some kind of
model because the constructor needs to add itself as an observer
to *something*.
But this feels like progress on the major front. It's a little sloppy
and free-for-all inside the objects, but everything is *inside* the
objects! This code doesn't actually draw anything except the
buttons. And the buttons don't visibly do anything. But importantly
they do all of this nothing *without errors*.
You don't need a model. It could be just the Controller and View.
One thing I'd consider is to align the obervers with the DOM.
One challenge being that the DOM elements have a private list of observers
Thinking about this as I write it: Maybe a weird hack could be
to have a dummy HTML element in the model just to take advantage
of its event code.
If I have time this weekend, I'll play with the idea.
On Saturday, 18 December 2021 at 21:14:27 UTC+1, Michael Haufe (TNO) wrote:
You don't need a model. It could be just the Controller and View.Just the opposite is the case: if you don't need anything, you need a model, otherwise it's a view-model, otherwise it's a model-view-view-mdel, otherwise it's full fledged MVC.
One thing I'd consider is to align the obervers with the DOM.Again, on the contrary: observables are more fundamental and more ubiquitous than any DOM.
One challenge being that the DOM elements have a private list of observersOnce challenge is to avoid any such coupling, and that's where one wants a view.
Thinking about this as I write it: Maybe a weird hack could beFrom bad to worse: that would very ugly, not just unnecessary and in fact upside down.
to have a dummy HTML element in the model just to take advantage
of its event code.
If I have time this weekend, I'll play with the idea.Of all the ideas...
On Saturday, December 18, 2021 at 3:56:49 PM UTC-6, ju...@diegidio.name wrote:
On Saturday, 18 December 2021 at 21:14:27 UTC+1, Michael Haufe (TNO) wrote:
We're referring to a button. A model gives you nothing there.You don't need a model. It could be just the Controller and View.Just the opposite is the case: if you don't need anything, you need a model, otherwise it's a view-model, otherwise it's a model-view-view-mdel, otherwise it's full fledged MVC.
It's not contrary, it's orthogonal. Right now he has to manage observers himself in the model, but the DOMOne thing I'd consider is to align the obervers with the DOM.Again, on the contrary: observables are more fundamental and more ubiquitous than any DOM.
is managing them in the view. There are two different approaches to managing these right now. These should
be normalized. Since you can't avoid using the DOM here one might as well bring the other approach into alignment.
You're free to present something better.One challenge being that the DOM elements have a private list of observersOnce challenge is to avoid any such coupling, and that's where one wants a view.
Thinking about this as I write it: Maybe a weird hack could beFrom bad to worse: that would very ugly, not just unnecessary and in fact upside down.
to have a dummy HTML element in the model just to take advantage
of its event code.
If I have time this weekend, I'll play with the idea.Of all the ideas...
On Thursday, December 16, 2021 at 11:18:18 PM UTC-6, luser...@gmail.com wrote:
I've read through Michael Haufe's example a few more times, andMost likely "don't need yet". MVC is overkill for simplistic pages or things don't really rise to the level of an application.
re-read the old article by Peter Michaux. And through all of it, I like
the idea of structuring stuff. The major divisions of responsibility
make sense. And to a certain extent, the lines of communication
make sense. But in all of these implementations there feels (to me)
like a whole lotta stuff I don't need. Or don't need yet. Or don't understand. Or something.
Recall that Peter Michaux and I both presented an MVC library in ~100 lines. With such examples they should be treated as impressionistic and incomplete.
So I've tried to build everything up as simply as I could manage.You don't need a model. It could be just the Controller and View.
I don't need to dynamically change the list of observers beyond
adding at least one: so it's just one one-liner function; etc. I did run
in to one weird corner in trying to make a Button out of a View.
It doesn't really need a model. But I have to give it some kind of
model because the constructor needs to add itself as an observer
to *something*.
But this feels like progress on the major front. It's a little sloppyI'm glad you've made progress with my back-of-napkin example.
and free-for-all inside the objects, but everything is *inside* the objects! This code doesn't actually draw anything except the
buttons. And the buttons don't visibly do anything. But importantly
they do all of this nothing *without errors*.
There are plenty of places that could be improved with naming
conventions, refactoring, utilities, etc.
One thing I'd consider is to align the obervers with the DOM.
Since the DOM uses `addEventListener` is might be more
clear to rename `observedBy` to something similar.
`container` might be more intuitive being renamed to `parent`
Should the Notes be responsible for toggling? Would that make more sense in the owning controller?
Again on the event management side. Note that the DOM's 'addEventListener' can accept an object as its second parameter.[snip interesting event handling example]
This could be a good opportunity to simplify all of the event management in general
An example:
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 414 |
Nodes: | 16 (2 / 14) |
Uptime: | 68:03:54 |
Calls: | 8,677 |
Calls today: | 6 |
Files: | 13,247 |
Messages: | 5,944,381 |