having fussed with various MVC approaches quite a bit, I'd just recommend figuring out what the use-case is that you're trying to optimize for.
#Meteor keyup event code#
And to add the flexibility back in will require thousands of KB of code to be added to the ViewModel package or it's configuration. There might be 'thousands of KB of code saved', but you're also depriving the developer of UI flexibility. Plus, there's a lot of lock-in with regards to UI.
Unless you have a really specific use case which the abstraction layer optimizes for (form autogeneration and form-builder apps, in the case of autoforms), the extra configuration winds up being overhead, and there's no net gain with larger real-world apps. I've both been down the path that you're heading on, and have seen attempts at building largish projects using a similar abstraction layer (which the autoforms package implements, as Serkan mentions).
consider whether the Template API is already acting like your ViewModel, just named differently.Īnyhow. it's going to be exactly the same amount of modification and flexibility that's currently already baked into the Template API. And there will be a zillion other permutations.Īnd, as you go along, you'll discover that the amount of one-off modifications you need to add to your viewmodel to make it useful in the real applications. The third collection will only need Edit button. And the second collection will need a Flag and Delete button. But in a larger app, your first collection might need an Edit and Active/Inactive button.
You're getting a handle on the CRUD pattern right now, and assuming that each row needs an Edit and Delete button. When you start using your viewmodel package in lots of apps, my suspicion is that you're going to find it needs lots of custom modifications. until you start building lots of applications, and need to start customizing it for different apps. it's already baked into the core Meteor API. However, I do think that when you look into the problem a bit more, you'll eventually come to the realization that the Meteor Development Group has been thinking about a lot of the same questions, and that a lot of the MVVM pattern that you're attempting to create. Which means you're asking exactly the right questions and thinking about exactly the right problems. that you're also thinking about reconciling server and client patterns. Since you're trying to create ViewModels, it's obvious that you're using something of a server-side MVC pattern. I've actually written a post on MVC patterns in Meteor, in case you're interested, which I'm still developing. Glad you're thinking about MVVM patterns! I'm convinced you're scratching the surface of a really big conversation that needs to happen in the Meteor community about reconciling client-side and server-side MVC application patterns. Just as an FYI, the forms-kitchensink app has been upgraded to clinical-ui-forms, as part of the Clinical UI boilerplate I'm developing. Thanks, in advance, for even reading this mind blast of questions- let alone respond to them. Via Reddis could some one return to the form page and either a) enter a simple 5 digit code and their entire form would re-populate (for their editing) or b) just begin typing in their unique info and the form repopulate with their given data (the form might match I.P.
#Meteor keyup event zip#
So does that mean that one might need to use autoform in conjunction with view model? Or can a vocabulary of controls provide all the elements one needs for building out forms?Ģ) I imagine that a simple css-reference in the controls could align the input fields in various column (2,3,4) format: no?ģ) I presume that the input data is being stored in Mongo, from where it could easily be flowed into/through MixPanel or some analytic or sentiment analysis resource?Ĥ) Could 'watchers' be on alert for a) certain area codes or zip codes or b) flag words (expressed sentiment) and then 1) render a colored field behind that particular stored/shown data-entry and 2) immediately alert (SMS/email) the proper person?ĥ) Say this was used with an involved form. I'm excited by what I see, but that energy spurs a volley of non-coder questions:ġ) you state that view model is not autform.
0 kommentar(er)
