I'm making a small application where you can add and delete movies etc. Now i'm supposed to add a Webusercontrol to my webpage (yes this is schoolwork). Do you have any smart situations where you need a webusercontrol? Not a menu because I have made that in my masterpage alreay.
Thanks in advance!
Anywhere you need to reuse the same UI logic over and over again, is one good reason to do so. Or if you just need to break up the length of the page so it isn't so large from a visual perspective, that can sometimes be a reason to do so too.
A user control is a container, so you can contain grouped logic together. A menu can be a user control so the logic around it is grouped together, but doesn't have to be.
There is no hard and fast rule.
Related
If the view which serves for creating an item contains some dropboxes / checkboxes / whatever with values from the server, should it send separate requests for filling up those controls with values (one request per each collection of data) or it is better to have a single api endpoint that returns all of the necessary data for filling up the form on front-end?
For the sake of simplicity, I've simulated here an example: Say we're building an app for a car servicing company where clients can make appointments:
Should the front-end app make 2 get requests to api/models and api/services, or these collections can be returned from the server in a single response (from api/appointments/createformdata), What are the best practices regarding to this?
Thank you in advance!
Well, since in your example, both combo boxes need values, then I would load up on first page load. There would be no need for separate requests unless those combo boxes are dependent on data in the form, and then in that case you have no choice but to wait for user input to determine that.
so, say you have two combo boxes, and the 2nd one is cascaded by the 1st combo choice? Well, the first combo box does not change - so load it up at page load time, and you have to do that anyway. No use writing out separate events or code to load that first combo that MUST be loaded in the first place.
however, the 2nd combo box? Well, since its values are based on the first one, then once again, you have no choice, do you?
So, I don't see any real use case, that if two combo boxes are independent to each other, then I see next to no reason why separate requests would be required, and that just loading up both combo boxes on first page load would not suffice here? (then you don't need ANY separate requests).
Now, if there is some kind of tab, or UI and the user can't see nor use the combo boxes right away, or may never even select say some tab out of a tab control? Well, ok, in that case then you speed up the page load by not filling out the combo boxes until such time the user gets to that part of the form (maybe some pop dialog, or maybe some kind of wizard steps).
But, once again, if the two combo boxes are not dependent on each other? Then I see no reason to use two requests or events to load up both of them. But then again, it would beg the question as to how you did in the past load up the combo boxes anyway?
I mean, if each combo box was some ajax call, then keep using two of them, and keep the two requests. Since attempting to merge, or put two ajax calls that fill out two combo boxes as one call is a pain, and does not follow a re-use design patter. The result is messy code, and worse force you to write code that does two things.
I mean, if you build a nice general routine to call + fill out the combo box, then continue to use that code to fill out the 2nd one. I would not blow up really nice working code to somehow fill out two simple combo boxes on a page and attempt to use one request for that filing out of the combo boxes.
And as I stated, if the combo boxes are in plain view from the start of the page load, then code behind on first page load is the place to do this unless some rather huge performance issue were to crop up. As a result, you now don't have ANY separate requests to fill out the combo's, do you?
But then again, a combo box is good for what, 30, maybe 50 choices tops, and after that, you need a different UI, and thus once again, you don't have a problem performance wise by doing this either way, do you?
And if you are trying to fix or avoid a performance problem? Then you putting too many choices into the combo box, and that is the wrong ui choice, and then once again, you don't have this issue, do you?
I have two options. I need 48 of a certain type control; it needs to respond to clicks and taps (for touch devices).
I could use Buttons, using the TextButtonStyle, and the Click event. Or I could use TextBlock, with the Tapped event.
I reckon buttons may be more "expensive" to create. OTOH, although I believe "Tapped" is also called when the user clicks the component, this makes me a little nervous due to its nomenclature, I guess.
Another difference is that a button takes up only the width necessary, whereas a TextBlock takes everything; and I want the underlying Grid to be tappable, so the TextBlock is kind of a problem that way. Is there a property that will make it more modest like the button?
There is design guidance for Windows Store apps on when and how to use buttons at http://msdn.microsoft.com/en-US/library/windows/apps/hh465470. Based on your description and this guidance, it sounds like buttons are the way to go. Responding to click events is what they were made for, and TextBlocks add the extra issues that you describe.
I have to create a Dynamic menu in ASP.NET. I want to use dynamic LinkButtons (or can be a Menu Control), but should be appended with sequence numbers. Eg: 1,2,3a 3b etc..and these sequcenes could be dynamic. Any idea. I used a repeater with a label and LinkButton in it, but having problems with view state. Any idea how to append sequence to menu??
Essentially, you have two paradigms with web applications, at least from this conversation's standpoint.
Stream out the HTML, creating it as you stream
Create containers that can bind to data and shape the data
Your concept seems to be "only #1 is dynamic", but that is not true. Any time you can change the data and get a different output, you are dealing with something dynamic. My personal feeling is shape the menu data prior to binding. This cannot always be done, but more oft than not, it can. The second method would be to attach to an event like a item binding or row binding event. Controlling the HTML stream and writing out individual items is generally my last resort.
Now to the viewstate issue. Viewstate is a bastard when you start adding things to an item after binding and semi-problematic when you are playing the dynamic game from #1 above. The problem is things added after the initial definition cannot easily be set up with automagic bits. You end up having to rebind each time. This is why shaping data and then binding is superior. Even in cases where you have to rebuild, you can cache the shaped data and quickly rebind. It takes more "up front" work, but is less problematic.
The actual container you are binding with is inconsequential. Unless you can't use the menu control for some reason (other than having to dynamically add, which can be solved by playing with the bound data), I would head this direction. Actually, I would head this direction and use the CSS friendly adapters so you can alter the look and feel more easily. :-)
I've got a flex app with a DataGrid with several columns (defined in the MXML file), and I need to "introspect" the grid columns. That is, I need to write some ActionScript code which, given the DataGrid object, can determine various things about the grid (and more specifically, the columns of the grid).
In particular, if a column is just plain text output, I don't really care about it... but if it's got "actionable" controls within it (checkboxes, linkbuttons, etc) I do.
First, I'm assuming that columns which contain "actionable" contents will be within <mx:itemRenderer> tags (else it would just be plain text); please let me know if this is incorrect.
Next I need to "dig down" into the structures, pulling the AS object corresponding to the <mx:DataGridColumn> out of the <mx:DataGrid> (I've got this), then pulling the AS object corresponding to the <mx:itemRenderer> out of the mx:DataGridColumn (two diff ways to do this; neither seems very useful), then pulling the AS object that corresponds to the <mx:Component> out of the mx:itemRenderer (if any; it's unclear to me whether the mx:Component actually creates an object), and finally pulling the AS object corresponding to the <mx:LinkButton> (or whatever) out of the mx:Component.
Does anyone know how to do this?
P.S. I understand that there's almost no limit to what could be lurking within the itemRenderer; if I can dig down that far, I'm willing to test for a handful of things that I expect and ignore the rest.
To clarify somewhat, I've been asked to provide Section 508 compliance (accessibility) to an existing application. There are a lot of pieces to this, of course, including screen readers, etc... but one of the first steps is making sure that the application can be used without a mouse.
Many of the existing screens have a UI technique consisting of a DataGrid with item renders which place controls like radio buttons and linkbuttons and whatnot into the cells (same type of control all the way down the column). All well and good, except I can find no way to interact with these controls via the keyboard.
So, I modified one screen to have a hot key which pops up a context menu, allowing the user to arrow up/down among the actionable items, and press ENTER to choose one (toggle the checkbox, press the linkbutton, etc). But this was screen-specific, and it will be too easy for someone to update the screen (e.g. adding another actionable column) and neglect the menu.
A better (?) approach was suggested: subclass the data grid, introspect to find the actionable columns, build the menu automatically, and now all we have to do is swap out the SuperDataGrid for the DataGrid, and our screens will be 508 compliant.
If someone can recommend a better way to make the screens 508-compliant (without redesigning the UI) and with minimal per-screen effort, I'm all ears.
Maybe I'm not being clear enough, since you keep missing the point, so let me try again.
I'm NOT writing application-level code... if I were, I'd know exactly what the logic is doing and I'd be able to use the bound data in the normal way. In fact, the application-level code DOES use the bound data in the normal way. But that's totally beside the point.
What I'm TRYING to do is write "infrastructure-level" code: that is, code which runs "below" the level of the application logic. I'm trying to effectively add a feature to DataGrids which Adobe should have included, but didn't. If I can get this class working, it will be possible to just drop it into dozens of screens WITHOUT ME, AS THE CLASS AUTHOR, KNOWING ANYTHING ABOUT THOSE SCREENS OR THE LOGIC WITHIN THEM. The only way I can imagine this working is to look into the datagrid and discover, at run time, what types of controls lurk within it, and possibly what they're bound to (actually, I can probably just execute whatever the click="foo()" attribute says to do, and I won't need to know what they're bound to).
Does this make sense?
Is it possible?
Item renders interact with the outside world through their data property. They should render the data as desired and make changes to data as required. They should not reach outside and you should not try to reach in to affect an item renderer directly.
As far as the underlying problem you're trying to solve, you haven't stated it at all. You're describing a desire to follow through on a particular solution only but haven't described the underlying problem. What are you really trying to accomplish? Don't talk about getting access to item renders or digging into the DataGrid, but what interaction or affect on the rows do you want? The problem is your approach is somewhat backwards and that's why it's not working out.
I have a bit of doubt regarding my application which is being created using Mate framework. The first thing user has to do is to log in, so I created Login.mxml view. After a successful login I need to display the main view with applicationControlBar at the top and a workspace below. At the moment I have two separate views, so if I understand correctly it makes sense using ViewStack.
Thing is, I'd like also to display some kind of panel with buttons on top of the workspace after login - here is screenshot. After clicking on a button the panel should dissapear. To complicate things a little bit more, there is a possibility for this panel to change state. Clicking on a specific button may result in showing progress bar at the bottom of panel.
I feel I should create separate view, MenuDialog.mxml and put there buttons, progress bar and states, but how to display it on the top of the workspace? I hope my problem is clear enough :)
I would make the panel a popUp, with the main application (or the ViewStack's parent container) as the parent of the popUp. You can use the PopUpManager Class to close it based on user actions within the Panel.
Assuming that perhaps you do not want a modal login style panel (which many apps these days eschew) then you should absolutely use states rather than ViewStacks.
States are a much cleaner way to distinguish the various, uh, states that your UI can be in -LOGGED_IN, LOGGED_OUT, etc.
It may take a little to get used to working with states, but once you do, you'll never go back. :-)