Andreas, Sorry, I am using a web front-end for my e-mail and it just wraps. I will try and match your layout :-).
As Jesse said, there are some existing components, but there are times where the existing ones don't meet your requirements. In our first release (2.0) we had our menus down the side. However, that is a bit of a problem. How do you handle the situation where someone has an option open and they click another option. There are several solutions to this problem: 1) Gray out the other ones. 2) You could warn them that they are going to lose their changes. 3) Or you retain all of their data and when they click back it is still there. In our 2.0 product the user lost all changes. We had an HTML guy who did not believe in "Cancel". In our 3.x product, you either cancel from where you are or "save" off your changes to back out. And "save" is not really true, we only "save" in one place. So at each "level" the user clicks "Done". The issue with either down the side or even across the top is you are building a tree structure. The question is what "Mouse" operations are available to the user and how do you respond if they have keyed in data? Lose it? Prompt them? Or save it off for now. With menus across the top, you still have the same issues. How many "levels" are you showing the user at one time? And can they jump there? If you think about your menu structure, you are really creating a Tree Structure. So, the question is how do you display it to the user and when they see it what can they click on? And what happens to the data that is there when they click somewhere else? We build our entire tree structure in memory. We don't traverse "pages" we traverse the tree. In our tree, each branch has nodes and those nodes store data in memory. So, we can have 130 nodes (pages) in memory at any point in time. If the user cancels, we throw them away. If they hit the "Save" button, we walk the tree, populate a structure and write it to disk. Our "menu" is internal to our data. If you pick a different path say change from Basic Auth to SSL, then the "menu" changes. So, we don't have an actual menu in a file somewhere. So, from a storage point of view, I don't know if XML vs. a database is really different. I think it depends on your comfort with maintenance of both. How will you populate the database for a menu? And more important how do you link the pages together? Most people would like to just hard-code them. Which work just fine until it doesn't. At some point, you will have an if statement that says go to page 3 if A or go to page 4 if B. Static external menus is fine as long as you don't want the options to be configurable. Menus are not as simple as people would like to think. I think that it starts to become more complex and what you end up with is a Finite State Machine (FSM). And the FSM defines the relationships between the pages. hth, Mark -----Original Message----- From: Andreas Bulling on behalf of Andreas Bulling Sent: Sat 6/3/2006 8:44 AM To: Tapestry users Subject: Re: Border question Hi Mark, first, a short notice: No offence, but could you please insert linebreaks in your answers as its quite time-consuming to break them manually (for example when using mutt) to be able to answer directly to your statements - thanks ;) | The question is are you trying | to define a generic menu component that can be "populated" with the links between the pages or are | you trying to create a project specific menu component that only has to work with your existing pages? Well, for sure the best would be to have a generic component capable of displaying an arbitrary set of pages and their structure as a menu... I don't know, I think at the moment a project-specific menu component should be enough. | Then the next question is what does it look like visually? Is it down the left side or across the top? Both ;) | If it is nested then each one would have it's list of pages. Which I think would support menus within menus. | As part of the "menu" component you would pass in a list of Menu Options and for each option a "Destionation Page". | If you take a step back, this is a tree structure. So, it could be stored in a database or an XML file. Or it could be | hard-coded in the supporting classes. The component itself could genereate different HTML/JavaScript as needed. | I would start by creating one manually to see how it works and how the L&F works. Then I would generalize it from there. What do you think is the "best": external XML, database oder hard-coded? What did you use for your menu component? Thanks! Andreas --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
