> On Mar 23, 2015, at 2:18 PM, Brian Kardell <bkard...@gmail.com> wrote: > > At some level, you can safely say that you will tend to like your own > design and find others a bit harder to understand.. Having experience > with a whole lot of previous attempts, but not yours, for example, I > can't say that I find yours to be especially simple or intuitive, but > I won't claim to represent the norm any more than I ask you not to - > so I agree, actual data is required.
The data I have is the outside virality of this. We could probably even quantify this. I have to rely on outside feedback as well, and do take into considerations people's comments and iterate on the proposal as needed. Obviously Javascript developer are against it, but regular web developers look like they’re into it. This really should be part of the out-of-the-box HTML default use model. > I will say that the XML nature > is problematic, as is SQL for reasons we can actually point to. I’ll change the example to JSON. The SQL section could come later as well. > Additionally, I will say that your list is pretty short, you'd also > have to include things like XBL and MDV > (http://mdv.googlecode.com/svn/trunk/docs/design_intro.html) and a > whole bunch of other stuff that had powerful support and lots of > investment, and give them some serious consideration as to why they > failed to get agreement, implementation, adoption and staying power - > then think about how your proposal would not fall victim to the same > pressures. For me, personally at least, I think there are existing > proposals which I already prefer more. I'm not seeing how an element > is a 'controller' for example or how you make a controller > non-imperative - even models generally have a data layer in a lot of > frameworks which would currently confound me as to how to accomplish > relation/request management declaratively.. I know we can get there, I > want to get there - I just haven't seen the right proposal yet that > answers all of those things. It definitely seems like for now you'd > need a pretty rich JS API which you haven't even hinted at here. For this proposal, the controller isn’t an element. It’s the browser itself. The user interacts with the document View layer. He clicks on a link: <A href=“http://api.mywebsite.com/data-endpoint”> The view layer notifies the browser of a click. The browser fetches http://api.mywebsite.com/data-endpoint and loads data into the model objects. The model objects update the document View layer. So, when you consider the browser to be the controller, this design and use model makes sense, and follows the same use model as now. Instead of loading a new page, you load data objects now. All the logic to do that is in the browser. Plus, the browser already has a whole Javascript framework that can be used to enhance its behaviour. If I want to do some processing on the models, just write some Javascript callback code to do so. Bam. Done and done. People are freaking out about the idea of separation of concerns with the HTML acting as logic, but it isn’t doing logic here. The browser is still responsible for logic, and it has default behaviors for these models ("Clicking on this link loads external data into this model") which you can extend ("convert the Markdown model data into HTML", or "load API data at a scroll point”) -bobby --- Bobby Mozumder Editor-in-Chief FutureClaw Magazine mozum...@futureclaw.com <mailto:mozum...@futureclaw.com> +1-240-745-5287 www.futureclaw.com <http://www.futureclaw.com/> twitter.com/futureclaw <https://www.twitter.com/futureclaw> www.linkedin.com/in/mozumder <http://www.linkedin.com/in/mozumder>
