If I read correctly, you do have a Screen module (class) per template,
so you do have the ability to add the getLayout(RunData) method. You
just do not want to duplicate the method in every class. So write a
Screen class (why not still call it screens.${submenu}.Default) and
implement the getLayout method there. Then have your screen template
specific Screen modules extend Default.
When I said to add the screens.view.Default screen earlier, I assumed
you did not already have a Screen module per template, so a single
Screen could be used for all the templates in a subdirectory. Obviously
if the more specific Screen match is made, the default is not going to
be.
john mcnally
Costas Stergiou wrote:
>
> 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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
