Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » Elevate Web Builder Technical Support » Support Forums » Elevate Web Builder 2 Preview » View Thread |
Messages 1 to 3 of 3 total |
Design a Menu |
Fri, May 1 2015 3:29 AM | Permanent Link |
Matthew Jones | The discussion recently about a "menu" component made me think about
how I'd go about making one. What would I want in such a component anyway? And when I thought about it, I thought it worth having a discussion here to gather opinion, because I don't think it is straightforward. A menu in a Delpgi desktop application is a Row of labels that have drop down items. Everyone knows what that is. Advanced menu systems have a Toolbar link too, and Actions make them easier to control. But what is a menu on a web page? It occasionally is a long line of items. But more commonly it is a "hamburger icon" with a drop down list. And how much design time UI do you want? How much is sensible, and how much actually needed. My initial design then, goes as follows: The component set consists of a TMenuPanel, a TMenuButton, and a TMenuItem. TMenuPanel is the visual container that you can customise to make your menu look how you want. It contains nothing itself other than being the "end caps" for TMenuButton. You can put in a single TMenuButton, or a lot of them if you want a full menu bar. I guess you could have an event handler here for common child menu handling. TMenuItem is the visual container that you can customise to make your menu items look how you want. It doesn't do a lot itself as it is mainly managed by the TMenuButton. TMenuButton is the component that does the real work. Visually, it may have an icon and or text label. When you click on it, a panel containing TMenuItems stretches down (or up?) to display the TMenuItems. Click on a menu item and the menu disappears and an event is fired to tell you which. Click away from the menu and the drop down disappears. Now the bit I think that will be most controversial. I'd define the menu content as a simple string list. It would look like: 1=File open 2=File close 14=File save 16=Export>20=To file|21=To PDF|22=To JSON 30=Send email The numbers are the event number that will come back to the event to tell you which was pressed. The text is what is displayed. If the text contains a > character, then it defines a sub-menu, of similar OR-separated items. I think this is a sensible thing as it is easy to define at design time and in code. And I think that code is going to be a common place for it to be updated. Why not have it as a TStringList that can be built up from a list of names and then assigned? Anyway, that's how I'd do it on the thinking I've done so far. What did I forget? What would make it better? |
Mon, May 11 2015 4:00 AM | Permanent Link |
Matthew Jones | Matthew Jones wrote:
> My initial design then, goes as follows: > > The component set consists of a TMenuPanel, a TMenuButton, and a > TMenuItem. I'm surprised no one saw fit to blast my design - no one really interested in a menu component? |
Mon, May 11 2015 5:59 PM | Permanent Link |
Doug B | "Matthew Jones" wrote:
> My initial design then, goes as follows: > > The component set consists of a TMenuPanel, a TMenuButton, and a > TMenuItem. That sounds like a reasonable approach. AFAIC, using the VCL model for the object hierarchy makes sense to me. After all, why reinvent the wheel? As far as the implementation goes, there are many JavaScript menu implementations out there and some use CSS (although I'm still unclear how CSS plays a role and/or can be leveraged in EWB 2). So I imagine someone more familiar with JavaScript might be able to offer more constructive feedback. > Now the bit I think that will be most controversial. I'd define the > menu content as a simple string list. This could make it easy to dynamically create menus, however I would prefer not to be locked into a specific format, since this could easily be done yourself just like in the VCL (e.g., http://stackoverflow.com/questions/2345381/delphi-dynamic-menu-items). A fluent interface could also be implemented on top of that if desired. Of course, the menu would also have to be responsive depending upon the device resolution, so that it could be displayed as a "hamburger icon" with a drop down list, like you mentioned. But I wouldn't want that to be the default display mode. Doug |
This web page was last updated on Friday, April 19, 2024 at 07:09 AM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |