I'm working on a Backbone application, and I have almost everything working, except the way I should read data from a form.
I have a few views and templates that create the form elements, and a "save" button. When I click that button it fires a view event, and there is where I would like to know if there is a "best practice" to read that info.
The options I was thinking were:
Reading the inputs using jQuery, like jQuery('#name').val(), which
would be annoying if you have a big form.
Using serializeArray
The last one would be something like https://github.com/derickbailey/backbone.syphon, but not sure how popular is it.
So, which is the best "backbone way" to do it?
Thanks a lot!
What is the best way is hard to say as it depends.
The example you show in your post are all meant for one action: submitting a form to a backend. Then, syphon (made by a great developper) and serializeArray (or just $(form).serialize()) are great solution (obviously the first one isn't great for a big form - so I'd forget this one).
Although, if your form is meant to update a model in realtime, and that this form should reflect change to model. Then, I'd go for a data-binding library. The best I know is Backbone.stickit; there's also Backbone.ModelBinder. I used both and they're great, although the first one use a little bit less boilerplate.
Related
One of the most convenient things about AngularJS was the two-way binding. Would it be advisable to replicate that with a much smaller library like PubSubJS and not use AngularJS? Or, would that create many more events that PubSubJS is intended to handle?
For example, imagine a form app where you type a first name into an input and that publishes the firstName event. There is a subscriber for the name that add that to the page title and an <h2/> at the top of the page. Then you select an option in the "Level of Education" select and it publishes "Masters Degree". Then a subscriber displays other inputs based on the value.
So that is a fairly simple example of course but could PubSubJS be used like that to build a more complex single-page app with might have been $scope.firstName in AngularJS now just being the firstName event with the value as a param? The benefits being that is a much small library and you have a much more fault-tolerant decoupling of the code but that would also mean that a lot of events are being fired. Another benefit of it would be that you could go back and later write something like a page interaction analytics module that tracks events without ever having to touch the original code.
I don't know about PubSub (I'm not familiar) but the pattern used by angularjs is basically the same thing as MVVM (Model-View View-Model) or any other two-way binding mechanisms. So I think yes it could be duplicated.
EDIT: Sorry, you were asking if was advisable. I'd say no, other emerging functional approaches are better suited.
I'm using AngularJS 1 with angular-material and ui-router.
Does anyone know what the best practice is for providing a UI for some "new foobar" type thing? In other words, let’s say I have a ui.route putting me at /app/#/foobars/ which shows a list of all the foobars. At the bottom right is a FAB with a big plus sign, which will bring up a new UI something to allow the user to specify how they want their foobar. What is the best practices for this "UI something" that comes up, using Angular?
Should I use an angular-material dialog? (That’s my first inclination, but it seems old-fashioned.)
Do I create a route to /app/#/new-foobar/ and just bring up another UI? (This seems heavy-handed; I don’t want to change the URI, plus I probably want to get back to where I came from after creating the foobar.)
I think that ui-router allows nested states; is this something I would use? But I don't want the new view/component to be embedded in the current view --- I would expect a card or something to somehow "overlay" whatever view is showing.
I wouldn't use nested states for this, as they are intended for things such a master/detail navigation.
The answer to your question is "it depends", as many situations in programming there're always some tradeoffs you must consider. Depending if you're targeting a desktop or a mobile app you'll have more or less space to put these options on the screen. If there're a lot of configuration options you should define a completly different state on wich you layout them and apply this configuration when you come back to the list. If there are not too much of them or you want to keep them visible at the same time as the list, you can go with a SideNav panel that can be locked open depending on the resolution. An alternative I've used sometimes is using a subheader to show some controls, as you can make it "stick" below the header or let it go if you scroll the list. As I told you before is a matter of choices and tradeoffs, and some sense of usability and simplicity towards the final user. There's no silver bullet nor best practice, just follow your intuition. Good luck!
I am new to Windows programming, as in my previous work I've mostly been involved with web technologies, and mostly in the backend. I have inherited a Winforms application, and one of my biggest nightmares is navigating through the endless states a form can be in.
To give you an example, a form has the state 'New' and 'Edit' depending on whether the user decided to Add or Edit a record. On this form, we have logic. If this texbox has a certain value, then these other textboxes are disabled, etc. This leads to endless chaining of these rules. So, a textbox's TextChanged event will influence another field. It in turn will fire X event that changes the state of other controls. It quickly devolves into a tangled mess that is impossible to maintain.
There has to be a better way... something simple and elegant that solves this problem. Any suggestions?
What I do is to have a single method called FormatControls(). In this method, I implement all the logic such as myTextbox.Enabled = mycheckBox.Checked and so on.
I call this method from my event handlers in the form, such as on checked changed, etc... I also call it when appropriate (ie, form newly loaded with no data, record loaded from database, etc). This has suited me well for many years now, it makes everything less complex.
You are correct, if you do not have a pattern in use it can turn into a too-complex thing.
You can try to use tha Application.Idle event to perform the enable disable logic and insulate this part from the business logic part.
Depending on what controls you have on your form, you might be able to do away with the separate textboxes and add/delete buttons and replace the whole works with a DataGrid.
In CakePHP I have a layout created and named default.ctp. In that layout I have a sidebar with some blocks and there're some statistics taken from the database.
My solution: I just created model called Sidebar.php and there're some functions, then I set up data in controller to display it in layout. Is this the best solution? As far I know, I will have to re-set every data in every controller, so need suggestions how to solve that.
Bear in mind that this is coming from a 10,000' level - I know nothing of your particular circumstances, but IMO it's not the best solution. I say that because you've created a model that represents a presentation component. If it were me, I'd probably look at using an element for display. Displaying dynamic components gets a little dodgy, but can be done without violating the MVC "covenant".
Your models should represent your domain entities (you've mentioned nothing about what your stats represent, so I won't offer any specific examples), not how they're presented.
I am currently loading the default file, page.xaml, but in that page, I am loading the content from another xaml file. With each "page" change, I just load the content from a different xaml file, and on and on.
Example: this.Content = new StartPage();
I'm running into some syntax issues, however, because of the way I am changing my content, and was wondering if there is a definitive answer on how to accomplish this?
For example, when trying to capture user's keystrokes, I would normally do:
this.Keydown += new KeyEventHandler(this_KeyDown);
but that event handler doesn't even fire in my situation. So, I'm looking for a new approach to my content-switching approach before revisiting the keystroke problem.
Have you looked at using Silverlight 3. It has a new Page Navigation functionality.Silverlight 3 Navigation
As far as content switching goes, I've always done what you propose in the question. Normally I create a MainPage.xaml which has has the frame of the application (usually a Grid for me). One of the cells in the Grid is considered the content area of the app. When the user takes an action that I would consider to be navigation, I create a new instance of a Page, which for me is a file like MyUserControl.xaml, and then add it to the appropriate content cell in the Grid. MainPage stays around for the life of the application and assists with navigation.
If you want something fancier, and want to take advantage of browser based back/forward buttons, you could look into the SL3 navigation like Correl suggested.
A Big problem with what your're doing is that journalization doesnt take place automatically when you swap out framework elements by creating them and plugging them in the codebehind. This means that you lose the back and forward functionality of the browser. You can manually journalize stuff when you swap out pages, but this is simply a hack to get your navigation approach working.
Take a look at Prism at www.compositewpf.codeplex.com/, specifically the MVVM method of GUI design, it'll save you alot of time later on. And remember, you dont need to go hardcore when you look at MVVM, u could always cut out alot of "dynamic" functionality if you're a one man band
Also swap to silverlight 3 and use the navigation application. If you cant, take a look at helix 0.3, it'll provide a more asp oriented approach to navigation. the link provides a really really good starting point, its a three part article, i suggest you read all three and download the sample application and understand it.
A book could have been written on your question, this has to suffice for now.