First of all thanks for your time and the answer. I still though don't have a solution to my problem. The last thing you proposed was to have a screens.view.Default.class in every dir that groups a number of templates. Ok, but why should this module ever be called??? (I miss something). I tried it and it is not being called...
Let me give some more details on my problem and maybe you can propose me something better that I have not think of. I have a quite big app (200+ templates, 400+ classes) and I have grouped all screen templates under directories according to the functionallity, e.g. /screens/view/ /screens/update/ ... Because the menus of the application started to get too big to show in all screens, I decided to use a javascript menu with drop down menus that sits on the top navigation of each screen. My problem is that I have a number of menus that are standard throughout the whole application and some others that are added or removed accodding to the functional area (or even the screen). So for example, when I am in the 'view' area of my app (templates under the /screens/view dir) I want to add a 'view' menu to my standard menu. In order to avoid having different layouts and top navigations for each group of screens I decided to build the top.vm navigation in a way that is common to ALL screens; so the way to find out the extra menus that each screen (or group of screens) needs is to use the standard mechanism of turbine that groups the modules in a hierarchical way under directories. So, in the top.java class (the one corresponding to the top.vm template) I call the data.getLayout() method in order to let turbine decide which one is the layout being used (according to the standard rules) and then if this class implements a propriatery interface (called MenuAware) that only has one method (getExtraMenus[]) i use the Assembler factory to get an instance of the Layout class and call this method to get the extra menus to display in the top vm. The reason I used this approach was that I tried to find an easy way to 'group' screens with the same extra menu in a standard way; and I thought why not use Turbine itself that can decide the correct Layout class that will use for each screen, and then just go and get that layout. So if I want to have an extra menu item on a screen, I just need to copy my standard Layout template to the correct dir (with the name Default or even the exact name of the screen template, if this is the case) and add a class layouts.view.Default that implements my propriatery interface. As you see, I only want to use the Layout class as a way to plugin my interface and have a standard way of locating it. Unfortunately, Turbine (as I mentioned before) does not use the Layout class that corresponds to the Layout template I am using. Just to mention that the app is being organized in large functional areas and the main reason for doing all this is to avoid having each screen module override the getLayout method. Any more ideas on the above? Thanks in advance, Costas > Costas Stergiou wrote: > > > > > Screen classes contain a method String getLayout(RunData) which > > > determine the Layout module that is used. The default implementation > > > > Layout module meaning the Layout class? > > Yes. > > > Because, the Layout template > > is correctly being used (the one matching the name and directory of the > > screen temlate), but the correspondin Layout class is not being used. > > > > > looks in TR.props. So if you want to set a different Layout you need to > > > create a Screen that matches your screen template and return the correct > > > Layout from the above mentioned method. > > > > I do use my own propriatery layout (set in TR.props) but this is the only > > layout > > class being used. > > On the other hand, having to override the getLayout() method for every > > screen I am using is really difficult. > > I would assume you only have a few layouts and the same layout is used > for related screens. Put the related screens in a directory structure > so that one Screen module is used per Layout. > > If all your screens are using different Layouts, I am not sure why you > are even using layouts at all. > > > Why Turbine does not locate > > and use the Layout class the same way it does with the Layout template? > > When designing the templating system, I felt that people should not be > placing objects in the context for layouts because more than likely that > part of the page belonged in a navigation if the contents changed. So > only one Layout module would ever be necessary, it placed the tools to > render navigations and the screen into the context. This did not turn > out to be the case for everyone, but I have yet to need more. The > system I described to you predates the template systems and is very > flexible. The couple times others have stated they needed different > Layout modules, I pointed out this way of achieving it and they were > satisfied. Some did not even want the layout template to be governed by > the screen template and wanted it per user or something else. The > current system allows that. > > If you are needing Layout modules at all, I assume you would probably > have enough Screens already created populating the template contexts, so > it should not be a problem. > > > I have a layout template named /view/Default.vm that is used for a dozen of > > templates > > that are below the /view directory; but the corresponding view.Default > > layout class is > > never being used. > > Is this correct? > > do you not have a screens.view.Default.class? if not, why not add one > and override the getLayout method? This does not sound like every > screen needing a different layout that you described above. > > > john mcnally > > --------------------------------------------------------------------- > 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]
