SetView.js contains a class called "maria.SetView". borrow.js does not contain a class but a function called "maria.borrow". Regardless these files all are concatenated to become a file simply called maria.js.
Thanks for taking a look at Maria. You definitely got the gist of how things work with Maria but there are a few subtleties that might change your perspective on the relationship between views and controllers in an app built with Maria.
So it is actually the view that handles the DOM events.
If you don't want the controller to handle the raw DOM event or you don't want a controller involved in handling the event at all, you can define the handler methods on the view yourself and then the auto-generated methods will not be created. For example,
maria.ElementView.subclass(myApp, 'MyView', {
uiActions: {
'click .alpha' : 'onClickAlpha' ,
'mouseover .beta': 'onMouseoverBeta'
},
properties: {
onClickAlpha: function(evt) {
// not sending evt to the controller
// and controller method name is different
this.getController().onSomething(1, 2, 3);
},
onMouseoverBeta: function(evt) {
alert('no controller involved here');
},
...
Also about who should query the form data: the view or the controller. I believe the view should be the only player in the game that knows about the DOM. If the way that the form data has to be retrieved from the DOM changes, then only the view needs to be updated. This makes sense to me as the view is the one that creates the form so the view should encapsulated all access to the form.
In the real world, the view/controller separation can be fuzzy. With Maria you can easily live without any controllers and have the views handle all user events or you can go wild with controllers and have all kinds of interchangeable view behavior thanks to the flexibility provided by controllers and the strategy pattern.
I'm still interested in hearing a convincing argument for decoupled controllers. Your statement that the view should be responsible for DOM interrogation rings true to me, and seems to reinforce the idea that the view should just handle input instead of splitting it out into a controller.
A controller and the strategy pattern allow a view to behave differently by plugging in a different controller into the view. This interchangeability of behavior is not something I've leaned on frequently in my own programming.
I am finding, while programming example applications for Maria, that splitting the event handling out to the controller is forcing me to make better APIs on my views to keep the DOM encapsulated. Allowing the controller to get the form data, without exposing any DOM information, for example. The view code ends up being very satisfying in a way I haven't experienced before.
What I'm hoping will happen is that after using strict view and controller separation for a while, I'll start to get insights where the strategy part could be used more. I think its the kind of thing that will sneak up on me over time and I'll start to see more uses for it.
Are not the event objects technically part of the DOM, though? It seems to me the view should unpack the event objects, and then delegate to a controller method, passing only non-DOM-related data. The controller then contains the "business logic" which is what everyone seems to put in controllers anyway.
You're right about the event being part of the DOM. If that is a concern, you can define your own view handlers that unpack the DOM event and forward the data to the controller handler. There is no way to autogenerate view handlers that know what needs to be unpacked in what way.
They didn't say "The King Henry VIII is dead. Long live the King Edward VI". In the JavaScript article, The "OLD king" is "JavaScript the source language". The "NEW king" is "JavaScript the compilation target". So the idea of old and new is in there. Sort of. :-)
Features that can be added through libraries should be added that way. You cannot add new syntax which involves scoping of variables through libraries. How would you do destructuring assignments with a library and have it as succinct as it can be done with syntax?
If you like minimalistic languages, have you checked out Scheme? Because of its macros, the core language can stay small and the users can expand its syntax.
He wasn't asking you to write code. If you read it, he is asking about writing code that is better, or more specifically, products that are better. A list of projects you've worked on is mostly irrelevant in the face of that accusation.
His "challenge" is too ridiculous to even reply to. Of course software that has had millions of users (and hundreds of contributers) over 30 years is going to be better than what some language advocate is going to be able to crank out in a week or month or year. Put enough time and polish into something, and it's going to be good regardless of what language you choose.
It would be a waste of time to rewrite some well-established project to prove some point about a language. ("Hey, I spent a year of my free time to make a $foo that's not as good as the $foo that already exists! Yeah!!!") It's much better to incrementally move away from the legacy code, to make future incremental improvements. (Firefox is a good example; more and more of the code is safe Javascript instead of raw C++. That's because it's easier to write/test/enhance, and because modern computers and virtual machines make the overhead acceptable.)
There is, of course, a surprising amount of non-C code out there. Firefox is Javascript. Emacs is Lisp. SBCL is Lisp. GHC is Haskell. Xmonad is Haskell. Debian's packaging system is Perl. The websites you use daily are Perl/Python/Ruby/PHP. And so on. Of the software packages that I use on a daily basis, very few are pure C. (xmms2 is. That's all.)
C exists in production software, but that's because it was the only option when these programs were being developed.
Take a snapshot of new ideas and projects being started right now, and see if C is still the most popular. That is a more reliable indicator of the state of the art.
You're straw-manning. I didn't say that C was the best language for everything, nor did I even say it was better than Haskell.
I was responding specifically to your claim that Haskell was better than C for the tasks that C is good at. And I asked for one example of a non-trivial core library (again, not a framework: something like crypto, graphics, numerics, yada yada -- things that are hard, not toys) that would prove that. And there are none.
Obviously I think that says something about the wonderful advantages you think Haskell has.
> Put enough time and polish into something, and it's going to be good regardless of what language you choose.
I don't think the evidence supports that claim. Witness the select() API or any number of other issues in the modern libc which have gone unaddressed for so many years. Then look at how libraries are occasionally rewritten better in a matter of months. It should be possible to develop software in new languages that compels the user compared to what they already have access to, else why develop a new language?
When you say millions of users, I think I'm not communicating well. When I say "products," I mean products where the programming language is actually relevant: libraries and frameworks. You don't need millions of users to be considered a huge success in that market.
So I guess my continued question is, have you written any libraries that got serious traction because they were much better than an alternative written in C? Because if you read him charitably, that's what the comment we're discussing was really asking for. You replied with a laundry list of projects and nothing actually relevant.
> more and more of the code is safe Javascript instead of raw C++
I'd be interested to see the extent to which this is actually true. Do you have a plot of the linguistic composition of the program over the years? Or at least some links to news articles to back up your claim?
> Of the software packages that I use on a daily basis, very few are pure C. (xmms2 is. That's all.)
I take it you don't use an operating system? Or do you mean to say that by including a little bit of non-C code, something significant has changed in the overall composition of the software you use?
> and see if C is still the most popular. That is a more reliable indicator of the state of the art.
I disagree that language popularity in new projects is a reliable indicator of anything except what language is popular at a given time.
GHC is not just Haskell. The runtime is written in C and C--.
C has its place. Anything close to the machine metal and bootstrapping code could and should be written in C. Don't confuse "all programs" with "all programs I like to write."
Please write about how you do this and how you interact with the files (loading and serializing). I'm looking at alternatives to using relational databases and information about how to avoid data corruption (features analogous to transactions) is scare. How would you convince a mission critical site developer that this is safe?
It doesn't matter it is in Erlang - you can do it in any language. A Lisp that implements software transactional memory is Clojure (runs on the JVM):
http://clojure.sourceforge.net/
I wrap code that changes things within a call to atomic,
which prevents the thread from switching in the middle of it. That solves the problem of two threads trying to modify an object at the same time. I don't add any protections against e.g. the host machine's power being shut off in the middle of writing a file, though maybe MzScheme does.
The answer to your specific question, though, is that I wouldn't try. News isn't written like banking software.
Transaction isolation would be handled like any non-database backed application: use your language and/or library's native thread synchronization features.
As for persisting transactions, you could marshall to file the deltas for each transaction, and on regular intervals apply them to the full image to create an up-to-date image.
Just remember to yield every now and then if you do anything lengthy. Depending on your application, it may not be that bad, and if you don't need anything fancier in the way of scheduling fairness, it makes your life really simple.
Yep, the CSP style of channel communication is great. Those thinking Erlang is better than sliced bread need to make sure they're up on what came before and after; http://swtch.com/~rsc/thread/ Personally, I find Erlang to be too clunky as a language. Good for special purpose telephone switching software maybe, but for general programming the CSP style can be done in nicer ways than having to switch to a whole new language.
Not CSP, no, but libraries that bolt onto existing languages, e.g. C, Python. I'd love to see it become more of a mainstream technique in Python than `import threading', etc.
Ignore the crufty Occam (Transputer anyone?) syntax, just concentrate on the concepts. Although some of the PDFs seem to have many pages, often a page is the same as the previous with a minor change; they're slides!
