Re: Layout class not used (tdk2.1)

[Costas Stergiou <cs...@aias.gr>]

I think this covers my requirement quite well. Thanks very much
for your help and information.
Costas

----- Original Message -----
From: "John McNally" <jm...@collab.net>
To: <tu...@jakarta.apache.org>
Sent: Friday, September 28, 2001 6:49 PM
Subject: Re: Layout class not used (tdk2.1)


> 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: turbine-user-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: turbine-user-help@jakarta.apache.org
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: turbine-user-help@jakarta.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-user-help@jakarta.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org