At 18:30 01/15/01, Christoph Reck wrote:
>If you read carefully, phase 2 is optional (note these are steps
>and not options/posbilities). If no class file is found matching
>the template name, it searches for a Deffault.class. If latter is
>not there, no Java code (beside a possible action) is executed.
Oh, I didn't know about default classes. I got only a stacktrace on my
screen. There is a respective JSP but no ErrorGenera.class. If I remove the
"ask screen for its layout" part in DefaultPage, then it works.
Horrible Exception: java.lang.ClassNotFoundException:
Requested Screen not found: ErrorGeneral
Turbine looked in the following modules.packages path:
[org.apache.jetspeed.modules, org.apache.turbine.modules]
at
org.apache.turbine.modules.ScreenLoader.getInstance(ScreenLoader.java:190)
at
org.apache.turbine.modules.pages.DefaultPage.doBuild(DefaultPage.java:166)
at org.apache.turbine.modules.Page.build(Page.java:92)
at org.apache.turbine.modules.PageLoader.exec(PageLoader.java:122)
at org.apache.turbine.Turbine.doGet(Turbine.java:391)
So there's possibly a setting missing in my TR.p. How do I set the default
class?
ingo.
>So the simplest solution (lately called the "pull model") is to
>provide a basic Default.java implementation that (conditionally)
>populates the context for all templates.
>
>:) Christoph
>
>ingo schuster wrote:
> >
> > At 16:56 01/15/01, Will Stranathan wrote:
> > >There are (at least) two phases to populating the Context for rendering on
> > >the template:
> > >
> > >1) When submitting a form, make sure that the action says something like
> > >action="$link.setPage("ViewResults.vm").setAction("SubmitQuery")" When
> > >you do this, the appropriate doWhatever(RunData, Context) method in
> > >SubmitQuery.class will be called, and you can put stuff into the
> context there.
> > >2) Furthermore, when ViewResults.vm is rendered, it will search for a
> > >ViewResults class with a doBuildTemplate(RunData, Context) method that can
> > >also be used for populating the Context which is what the template will
> > >use to populate itself.
> >
> > Ok, I understand that there are two possibilities, I just wonder if the
> > second one is "clean". Somebody who doesn't know turbine well would expect
> > screens to be a view and not partly view, partly controller. Furthermore,
> > if I choose to use possibility 1 only, DefaultPage still forces me to
> > provide an empty <screen>.class for every screen I use - even if this
> > screen is a pure view (template) that doesn't need any code.
> > Well, I suppose that if I don't want this I'll have to implement my own
> > page class, it's just that in my opinion 1) should be the standard way and
> > not 2).
> > But that's my 2 cents. ;-)
> >
> > ingo.
> >
> > >Although my examples here used Velocity, I'm sure it works similarly
> in JSP.
> > >
> > >Will Stranathan
> > >
> > >ingo schuster wrote:
> > >
> > >>Hi,
> > >>I'm slightly confused about how the templating in turbine is supposed to
> > >>be used.
> > >>Speaking in M-V-C, I assumed that the screen templates would be the view,
> > >>just displaying the results of the processing that the controller
> > >>(turbine, action) has done.
> > >>But if I use that approach (action does the processing, provides the
> > >>screen with the results, and the screen is simply a template file, in my
> > >>case a jsp), won't then the DefaultPage attempt to load the screen.class
> > >>in order to ask it for the layout? If my screen is only of a template
> > >>file, there is no class to instantiate!
> > >>So, do I have to override the doBuild in my JspPage?
> > >>ingo.
>
>
>------------------------------------------------------------
>To subscribe: [EMAIL PROTECTED]
>To unsubscribe: [EMAIL PROTECTED]
>Search: <http://www.mail-archive.com/turbine%40list.working-dogs.com/>
>Problems?: [EMAIL PROTECTED]
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/turbine%40list.working-dogs.com/>
Problems?: [EMAIL PROTECTED]
