You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@turbine.apache.org by Michael Stanley <mp...@syr.edu> on 2001/04/16 16:44:04 UTC
Quick Question
In an Action is it possible to retrieve the most recent Screen? Layout?
Mike
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
Re: Quick Question
Posted by Michael Stanley <mp...@syr.edu>.
> Either way I think it is best to use request parameters (usually
> specified as pathinfo in turbine) over session. As this limits the use
> of multiple browser windows or at least makes their management more
> complex.
I personally liked the idea of putting lastTemplate info in the session
as this puts more of the logic in the screen as apposed to the Template
itself. I don't like the approach of setting parameters, but you make a
good point with the multiple windows problem. I didn't think of that.
Mike
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
RE: Seperating Application Flow from actions/views
Posted by Pere Torrodellas <pt...@fihoca.com>.
Hi,
I'm not sure if the following is relevant to your discussion, but to add my 2
cents...
Just before discovering Turbine and getting involved in our present test, I
designed and developed a Workflow framework that I think follows some of your
ideas. It does work in our testing environment, but has not been used in any
real development yet. These are its general characteristics:
- A workflow is defined in XML as a set of states.
- A workflow can be applied to any Object that implements a specific interface.
- More than one workflow can be defined and launched on an Object at the same
time. The framework controls mutual pre-requisites and exclusive use of the
controlled object to synchronise them.
- Each workflow state has a set of actions, whose successfull completion leads
to a new state. An unsuccessful action leaves the Object in the state it was.
All this is defined in the XML file.
- Each action can have a set of pre-requisites (states of other workflows, also
defined in the XML file) that must be met for the action to be selectable for
execution (f.e. "Publish Document" can not be executed before the
"Authorisation" workflow reaches the "Is Authorised" state).
- Actions can be synchronous or asynchronous.
- An action can perform any process on the controlled Object. Actions can be
defined to have exclusive control on the controlled Object while executing, or
able to share control with actions of other wokflows that are running in
parallel
- Actions get input data from the requester as an object of a specific class,
and report the results in the same way.
- There is an interface to control permissions to launch workflows and execute
actions.
- Given a user, an object and a state, the framework reports what actions the
user can request according to his/her permissions.
- There's a log to register who does what and when.
Seen under the Turbine light:
- A Turbine Action/Screen would be the requester of the controlled object(s)
state and possible actions, reporting them to the user in any suitable way.
- A Turbine Action would request the execution of a workflow action selected by
the user, and decide what Screen to return in function of the results.
- The execution permissions would be managed with Turbine Security.
- The Object state(s) would be controlled with the Turbine DB and Peers.
- The framework log would be set to use Turbine Log.
I'm sure that there's still a lot of work to be done on it; maybe our next
project will use it with Turbine.
I'm not sure of the legal status of all this, but I certainly can discuss the
general ideas if anyone is interested.
Pere Torrodellas
----- Mensaje original -----
De: Russell Edens <ru...@speakeasy.net>
Para: <tu...@jakarta.apache.org>
Enviado: miércoles 18 de abril de 2001 23:05
Asunto: Seperating Application Flow from actions/views
> John McNally wrote:
> > I am not satisfied with the approach, though. I think an xml
> > specification of application flow would be much better, so that actions
> > and templates do not have to contain so much of this logic. I think
> > this has broader scope than intake and just handling error screens and
> > so should be built separately. But of course that is quite a project.
>
> This is a worthy project. Before using Turbine we built a system that defined
> the relationships between views and models in XML. It worked great. The
> application flow was not defined in the view, this allowed views to be reused
> without adding custom logic. We also used this layer to define the binding
> between the model and the view. This way the same view could render different
> data depending on the users context. As an example, a screen that updates
> employee information would bind to a different model depending on if the
logged
> in employee was 'self' or 'manager'. The binding of the view and model used
> roles to determine the appropriate binding.
>
> An extreem example of the power of this system was a Shopping cart application
> that allowed a customer service rep to logon to impersonate the user. What
> views they could see were determined by the XML. It was a sub-set of what the
> user saw. They could see the shopping basket but could not submit it. In
> essense they could trouble shoot the entire application with the user in
> read-only mode. The views to render this did not change at all. The models
did
> not change at all. New XML defining what screen flow based on role was all
that
> was added to achieve this.
>
> My intention was to either build this layer on top of Turbine or add it to
> Turbine. If there is a general consensus that this functionality is worth
> building into Turbine - I'm game.
>
>
> ---------------------------------------------------------------------
> 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
Re: Seperating Application Flow from actions/views
Posted by Leon Messerschmidt <le...@opticode.co.za>.
> This is a worthy project. Before using Turbine we built a system that
defined
> the relationships between views and models in XML. It worked great. The
> application flow was not defined in the view, this allowed views to be
reused
> without adding custom logic. We also used this layer to define the
binding
> between the model and the view. This way the same view could render
different
> data depending on the users context. <snip>
AssemblerFactories are responsible for creating the screen or "logic" for a
specific view. You can possibly create a custom AssemblerFactory that knows
about your mapping. Just a thought...
~ Leon
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
Re: Location of javadoc api documentation for the tdk builds?
Posted by Jason van Zyl <jv...@apache.org>.
Darren Pamatat wrote:
>
> Where is the javdoc api documentation for the tdk builds found at:
> http://jakarta.apache.org/turbine/tdk/
>
> The tdk includes all kinds of documentation but is missing the api
> (javadocs) for the turbine packages. Where is the javadoc
> corresponding to these versions?
The missing turbine api docs has been noted. I forgot to
generate the docs before I built the last tdk.
>
> Thanks
> Darren
>
> __________________________________________________
> Do You Yahoo!?
> Yahoo! Auctions - buy the things you want at great prices
> http://auctions.yahoo.com/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-user-help@jakarta.apache.org
--
jvz.
Jason van Zyl
jvanzyl@apache.org
http://jakarta.apache.org/velocity
http://jakarta.apache.org/turbine
http://tambora.zenplex.org
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
Re: Mail Archives???
Posted by Jon Stevens <jo...@latchkey.com>.
on 4/26/01 5:52 AM, "Darren Pamatat" <dp...@yahoo.com> wrote:
> It seems that the mail-archives for turbine is not being updated
> anymore. Is there a new archive somewhere else?
>
> Thanks,
> Darren
Brian says that the emails are being sent to mail-archive.com yet they
aren't showing up and they want to see proof of that...and I haven't heard
back from Brian about it...
-jon
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
Mail Archives???
Posted by Darren Pamatat <dp...@yahoo.com>.
It seems that the mail-archives for turbine is not being updated
anymore. Is there a new archive somewhere else?
Thanks,
Darren
__________________________________________________
Do You Yahoo!?
Yahoo! Auctions - buy the things you want at great prices
http://auctions.yahoo.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
Re: Help setting up TDK on Linux
Posted by "Randall G. Alley" <ir...@bellsouth.net>.
Thanks Jon.
Jon Stevens wrote:
> on 4/25/01 6:44 PM, "Randall G. Alley" <ir...@bellsouth.net> wrote:
>
> > That was the last thing I tried, and it didn't work for me. I've been fiddling
> > with this since the switch to Catalina, and I've never
> > got reloading to work with Catalina. Is anyone else actually got it working
> > now
> > ?
> >
> > last try was using the scarab example from server.xml :
> >
> > <Context path="/scarab" docBase="scarab" reloadable="true" debug="0">
> > <Logger className="org.apache.catalina.logger.FileLogger"
> > prefix="scarab_log." suffix=".txt"
> > timestamp="true"/>
> > <Loader checkInterval="1"
> > className="org.apache.catalina.loader.StandardLoader"/>
> > <Manager debug="99"/>
> > </Context>
>
> I'm sorry, but you are going to have to come up with a repeatable set of
> code (ie: a simple Turbine webapp) based on a recent Catalina nightly
> snapshot and instructions on how to duplicate it and then get Craig to look
> into it.
>
> Craig.McClanahan@eng.sun.com
>
> This is what I would have to do if I was in your shoes (and I would) but I
> don't have time to deal with the issue and it isn't a priority for me right
> now.
>
> -jon
>
> ------------------------------------------------------------------------
> ---------------------------------------------------------------------
> 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
Re: Help setting up TDK on Linux
Posted by Jon Stevens <jo...@latchkey.com>.
on 4/25/01 6:44 PM, "Randall G. Alley" <ir...@bellsouth.net> wrote:
> That was the last thing I tried, and it didn't work for me. I've been fiddling
> with this since the switch to Catalina, and I've never
> got reloading to work with Catalina. Is anyone else actually got it working
> now
> ?
>
> last try was using the scarab example from server.xml :
>
> <Context path="/scarab" docBase="scarab" reloadable="true" debug="0">
> <Logger className="org.apache.catalina.logger.FileLogger"
> prefix="scarab_log." suffix=".txt"
> timestamp="true"/>
> <Loader checkInterval="1"
> className="org.apache.catalina.loader.StandardLoader"/>
> <Manager debug="99"/>
> </Context>
I'm sorry, but you are going to have to come up with a repeatable set of
code (ie: a simple Turbine webapp) based on a recent Catalina nightly
snapshot and instructions on how to duplicate it and then get Craig to look
into it.
Craig.McClanahan@eng.sun.com
This is what I would have to do if I was in your shoes (and I would) but I
don't have time to deal with the issue and it isn't a priority for me right
now.
-jon
Re: Help setting up TDK on Linux
Posted by "Randall G. Alley" <ir...@bellsouth.net>.
That was the last thing I tried, and it didn't work for me. I've been fiddling
with this since the switch to Catalina, and I've never
got reloading to work with Catalina. Is anyone else actually got it working now
?
last try was using the scarab example from server.xml :
<Context path="/scarab" docBase="scarab" reloadable="true" debug="0">
<Logger className="org.apache.catalina.logger.FileLogger"
prefix="scarab_log." suffix=".txt"
timestamp="true"/>
<Loader checkInterval="1"
className="org.apache.catalina.loader.StandardLoader"/>
<Manager debug="99"/>
</Context>
Jon Stevens wrote:
> on 4/25/01 4:01 PM, "Randall G. Alley" <ir...@bellsouth.net> wrote:
>
> [snipped to the meat of the message]
>
> > We're using tdk13 at present, and still have to restart Catalina after
> > recompiling classes. Is anyone else getting the class reloading to work ?
>
> I have gotten it to work in the past. If you try it with Scarab's sandbox
> settings, it will most likely work.
>
> -jon
>
> --
> If you come from a Perl or PHP background, JSP is a way to take
> your pain to new levels. --Anonymous
> <http://jakarta.apache.org/velocity/ymtd/ymtd.html>
>
> ---------------------------------------------------------------------
> 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
Re: Help setting up TDK on Linux
Posted by Jon Stevens <jo...@latchkey.com>.
on 4/25/01 4:01 PM, "Randall G. Alley" <ir...@bellsouth.net> wrote:
[snipped to the meat of the message]
> We're using tdk13 at present, and still have to restart Catalina after
> recompiling classes. Is anyone else getting the class reloading to work ?
I have gotten it to work in the past. If you try it with Scarab's sandbox
settings, it will most likely work.
-jon
--
If you come from a Perl or PHP background, JSP is a way to take
your pain to new levels. --Anonymous
<http://jakarta.apache.org/velocity/ymtd/ymtd.html>
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
Help setting up TDK on Linux
Posted by "Randall G. Alley" <ir...@bellsouth.net>.
Ok, I admit it. I'm a Linux idiot. :>} But I'm trying to reform myself.
Could someone give me some pointers (possibly in private e-mail if this
is off topic) about where to install, what permissions, and so forth ? My
idea is to install the tdk/tomcat on my (underused) Linux box (which is
much faster than the NT stations), and continue editing, compiling and
controlling things primarily from NT workstations.
We're using tdk13 at present, and still have to restart Catalina after
recompiling classes. Is anyone else getting the class reloading to work ?
I've tried all the server.xml context settings mentioned on the list, but
no luck. Anyway, this forces us to continually restart Catalina. I would
think we could keep a telnet session open to the Linux machine to do
this. This would be vastly easier if I didn't have to restart all the
time. I've got Samba sharing going, so directory access from the NT
machines is no problem.
Thanks in advance.
I'd be infernally grateful.
Randy
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
Re: TDK-Torque and ForiegnKey into TURBINE_USER
Posted by Chris Campbell <ca...@zodiacnetworks.com>.
Hmmm... when I try this, I still get errors.: The sql gets generated with an
unresolved $fk variable for Turbine_User, even if the whole Turbine_User
table is copied into the project.xml file! And the generated
TurbineUser.java file is generated as an empty file. Hmmm... something wierd
is gonig on in torque land, is it me?
Chris
----- Original Message -----
From: Leon Messerschmidt
To: turbine-user@jakarta.apache.org
Sent: Thursday, April 19, 2001 12:10 AM
Subject: Re: TDK-Torque and ForiegnKey into TURBINE_USER
Hi Chris,
You can create a dummy table for TURBINE_USER to prevent this error.
Unfortunately you'll end up with wrong TurbineUser* classes in your om
directory. I usually delete these and edit the code by hand to make it
compile.
I'd be grateful if you have a patch that works :-)
~ Leon
----- Original Message -----
From: "Chris Campbell" <ca...@zodiacnetworks.com>
To: <tu...@jakarta.apache.org>
Sent: Thursday, April 19, 2001 2:13 AM
Subject: TDK-Torque and ForiegnKey into TURBINE_USER
> When I try to establish a foreignKey in a project-schema.xml table that
> refrences TURBINE_USER's USER_ID, my om classes are not correctly
generated.
>
> During om class generation I get this error:
>
> java.lang.NullPointerException
> at org.apache.xerces.framework.XMLParser.parse(XMLParser.java:917)
> at
>
org.apache.turbine.torque.transform.XmlToAppData.parseFile(XmlToAppData.java
> :134)
> at
>
org.apache.turbine.torque.ant.VTorqueTask.initControlContext(VTorqueTask.jav
> a:230)
> at
> org.apache.velocity.texen.ant.TexenTask.execute(TexenTask.java:299)
> at org.apache.tools.ant.Target.execute(Target.java:153)
> at org.apache.tools.ant.Project.runTarget(Project.java:898)
> at org.apache.tools.ant.Project.executeTarget(Project.java:536)
> at org.apache.tools.ant.taskdefs.Ant.execute(Ant.java:213)
> at
> org.apache.tools.ant.taskdefs.CallTarget.execute(CallTarget.java:103)
>
> at org.apache.tools.ant.Target.execute(Target.java:153)
> at org.apache.tools.ant.Project.runTarget(Project.java:898)
> at org.apache.tools.ant.Project.executeTarget(Project.java:536)
> at org.apache.tools.ant.Project.executeTargets(Project.java:510)
> at org.apache.tools.ant.Main.runBuild(Main.java:421)
> at org.apache.tools.ant.Main.main(Main.java:149)
>
> And the class that has the foriegn key does not get fully rendered. For
> example, the following method:
>
> public void setUserPrefrences(UserPrefrences v) throws Exception
> {
> aUserPrefrences = null;
> set${column.JavaName}(v.get${colFK.JavaName}());
> aUserPrefrences = v;
> }
>
> Is setting the foreingKey to refrence Turbine_User user_id column
possible?
> ( Or the wrong thing to do ?)
>
> Thanks
> Chris
>
>
> ---------------------------------------------------------------------
> 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
problem with order-by
Posted by kidong <Ki...@public.uni-hamburg.de>.
hello,
i have problem with order-by function with criteria.
my first database connection to retrieve all rows is so:
Criteria crit2 = new Criteria();
Vector v2 = org.apache.turbine.ProjektePeer.doSelect( crit2 );
connection null!
i have tried again with this code:
Criteria crit2 = new Criteria();
Vector v2 = org.apache.turbine.ProjektePeer.doSelect( crit2,
GetDBConnection.getAnotherDBConnection() );
it runs fine.
and now,
Criteria crit2 = new Criteria();
crit2.addOrderByColumn( ProjektePeer.NAME );
Vector v2 = org.apache.turbine.ProjektePeer.doSelect( crit2,
GetDBConnection.getAnotherDBConnection() );
, where GetDBConnection class is following:
=================================================================
package de.silverscreen.turbine.bugtracker.util;
import java.lang.*;
import org.apache.turbine.util.db.pool.ConnectionPool;
import org.apache.turbine.util.db.pool.DBConnection;
/**
* the small database connections are made.
* When necessary, static final string could be modified.
*/
public class GetDBConnection
{
public static final String DRIVER = "org.gjt.mm.mysql.Driver";
public static final String URL =
"jdbc:mysql://127.0.0.1/bugtracker?user=root";
public static final String ANOTHER_URL =
"jdbc:mysql://127.0.0.1/zef?user=root";
public static final String USER = "root";
public static final String PASSWORD = "";
/*
public static final String URL =
"jdbc:mysql://62.157.88.3:3306/bugtracker?user=silver";
public static final String ANOTHER_URL =
"jdbc:mysql://62.157.88.3:3306/zef?user=silver";
public static final String USER = "silver";
public static final String PASSWORD = "tmfitsxy";
*/
public static DBConnection getDBConnection() throws Exception
{
ConnectionPool cp = new ConnectionPool ( DRIVER, URL, USER,
PASSWORD );
return cp.getConnection();
}
public static ConnectionPool getConnectionPool() throws Exception
{
return new ConnectionPool ( DRIVER, URL, USER, PASSWORD );
}
public static DBConnection getAnotherDBConnection() throws Exception
{
ConnectionPool cp = new ConnectionPool ( DRIVER, ANOTHER_URL, USER,
PASSWORD );
return cp.getConnection();
}
}
========================================================================
i got the following exception:
[Thu Apr 19 21:06:49 GMT+02:00 2001] -- INFO -- IDBroker thread was started.
[Thu Apr 19 21:06:49 GMT+02:00 2001] -- ERROR -- Turbine.handleException:
null
[Thu Apr 19 21:06:49 GMT+02:00 2001] -- ERROR --
Exception: java.lang.NullPointerException
Stack Trace follows:
java.lang.NullPointerException
at
org.apache.turbine.om.peer.BasePeer.createQueryString(BasePeer.java:1004)
at org.apache.turbine.om.peer.BasePeer.doSelect(BasePeer.java:1114)
at
org.apache.turbine.BaseProjektePeer.doSelectVillageRecords(BaseProjektePeer.
java:187)
at org.apache.turbine.BaseProjektePeer.doSelect(BaseProjektePeer.java:148)
at
de.silverscreen.turbine.bugtracker.modules.screens.Index.doPerformThis(Index
.java:29)
at
de.silverscreen.turbine.bugtracker.modules.screens.Index.doBuildTemplate(Ind
ex.java:18)
at
org.apache.turbine.modules.screens.VelocityScreen.doBuildTemplate(VelocitySc
reen.java:115)
at
org.apache.turbine.modules.screens.TemplateScreen.doBuild(TemplateScreen.jav
a:135)
any idea would be very thankful to me.
thanks,
kidong
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
Re: TDK-Torque and ForiegnKey into TURBINE_USER
Posted by John McNally <jm...@collab.net>.
I started down a path like this and reverted back to just declaring the
relevant parts of the table in the xml and then telling torque not to
generate sql for the table.
This way torque still generates methods and classes for the related
table. I think it should be possible to set up the class hierarchy so
that the torque class extends your custom table class or the other way
around. It is complicated, but the alternative of leaving out any
reference to an external table in the om/peer classes does not seem like
a very good solution.
John McNally
Chris Campbell wrote:
>
> That's a bit beyond me at this point. But my initial guess would be to add
> an externalTable element to the database.dtd. It appears that the XmlParser
> is choking on the fact that the foreign-key's foriegnTable attribue doesn't
> match up to any of the tables defined in the xml.
>
> For the sake of argument, maybe something like this would work:
>
> <!ELEMENT externalTable >
> <!ATTLIST table
> name CDATA #REQUIRED
> javaName CDATA #IMPLIED
> >
>
> and
> <!ELEMENT external-foreign-key (reference+)>
> <!ATTLIST external-foreign-key
> externalForeignTable CDATA #REQUIRED
> >
>
> and
> <!ELEMENT database(table+, externalTable*)>
> <blahblah>
>
> Then in XML
>
> <external-foreign-key externalForeignTable="TURBINE_USER">
> <reference local="USER_ID" foreign="USER_ID"/>
> </foreign-key>
>
> Does any of this make sense? If I was more competent with XML stuff I would
> try it, but I'm just so unfamiliar with the torque code and am swamped with
> work...
>
> Chris
>
> ----- Original Message -----
> From: Leon Messerschmidt
> To: turbine-user@jakarta.apache.org
> Sent: Thursday, April 19, 2001 12:10 AM
> Subject: Re: TDK-Torque and ForiegnKey into TURBINE_USER
>
> Hi Chris,
>
> You can create a dummy table for TURBINE_USER to prevent this error.
> Unfortunately you'll end up with wrong TurbineUser* classes in your om
> directory. I usually delete these and edit the code by hand to make it
> compile.
>
> I'd be grateful if you have a patch that works :-)
>
> ~ Leon
>
> ----- Original Message -----
> From: "Chris Campbell" <ca...@zodiacnetworks.com>
> To: <tu...@jakarta.apache.org>
> Sent: Thursday, April 19, 2001 2:13 AM
> Subject: TDK-Torque and ForiegnKey into TURBINE_USER
>
> > When I try to establish a foreignKey in a project-schema.xml table that
> > refrences TURBINE_USER's USER_ID, my om classes are not correctly
> generated.
> >
> > During om class generation I get this error:
> >
> > java.lang.NullPointerException
> > at org.apache.xerces.framework.XMLParser.parse(XMLParser.java:917)
> > at
> >
> org.apache.turbine.torque.transform.XmlToAppData.parseFile(XmlToAppData.java
> > :134)
> > at
> >
> org.apache.turbine.torque.ant.VTorqueTask.initControlContext(VTorqueTask.jav
> > a:230)
> > at
> > org.apache.velocity.texen.ant.TexenTask.execute(TexenTask.java:299)
> > at org.apache.tools.ant.Target.execute(Target.java:153)
> > at org.apache.tools.ant.Project.runTarget(Project.java:898)
> > at org.apache.tools.ant.Project.executeTarget(Project.java:536)
> > at org.apache.tools.ant.taskdefs.Ant.execute(Ant.java:213)
> > at
> > org.apache.tools.ant.taskdefs.CallTarget.execute(CallTarget.java:103)
> >
> > at org.apache.tools.ant.Target.execute(Target.java:153)
> > at org.apache.tools.ant.Project.runTarget(Project.java:898)
> > at org.apache.tools.ant.Project.executeTarget(Project.java:536)
> > at org.apache.tools.ant.Project.executeTargets(Project.java:510)
> > at org.apache.tools.ant.Main.runBuild(Main.java:421)
> > at org.apache.tools.ant.Main.main(Main.java:149)
> >
> > And the class that has the foriegn key does not get fully rendered. For
> > example, the following method:
> >
> > public void setUserPrefrences(UserPrefrences v) throws Exception
> > {
> > aUserPrefrences = null;
> > set${column.JavaName}(v.get${colFK.JavaName}());
> > aUserPrefrences = v;
> > }
> >
> > Is setting the foreingKey to refrence Turbine_User user_id column
> possible?
> > ( Or the wrong thing to do ?)
> >
> > Thanks
> > Chris
> >
> >
> > ---------------------------------------------------------------------
> > 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
Re: TDK-Torque and ForiegnKey into TURBINE_USER
Posted by Chris Campbell <ca...@zodiacnetworks.com>.
That's a bit beyond me at this point. But my initial guess would be to add
an externalTable element to the database.dtd. It appears that the XmlParser
is choking on the fact that the foreign-key's foriegnTable attribue doesn't
match up to any of the tables defined in the xml.
For the sake of argument, maybe something like this would work:
<!ELEMENT externalTable >
<!ATTLIST table
name CDATA #REQUIRED
javaName CDATA #IMPLIED
>
and
<!ELEMENT external-foreign-key (reference+)>
<!ATTLIST external-foreign-key
externalForeignTable CDATA #REQUIRED
>
and
<!ELEMENT database(table+, externalTable*)>
<blahblah>
Then in XML
<external-foreign-key externalForeignTable="TURBINE_USER">
<reference local="USER_ID" foreign="USER_ID"/>
</foreign-key>
Does any of this make sense? If I was more competent with XML stuff I would
try it, but I'm just so unfamiliar with the torque code and am swamped with
work...
Chris
----- Original Message -----
From: Leon Messerschmidt
To: turbine-user@jakarta.apache.org
Sent: Thursday, April 19, 2001 12:10 AM
Subject: Re: TDK-Torque and ForiegnKey into TURBINE_USER
Hi Chris,
You can create a dummy table for TURBINE_USER to prevent this error.
Unfortunately you'll end up with wrong TurbineUser* classes in your om
directory. I usually delete these and edit the code by hand to make it
compile.
I'd be grateful if you have a patch that works :-)
~ Leon
----- Original Message -----
From: "Chris Campbell" <ca...@zodiacnetworks.com>
To: <tu...@jakarta.apache.org>
Sent: Thursday, April 19, 2001 2:13 AM
Subject: TDK-Torque and ForiegnKey into TURBINE_USER
> When I try to establish a foreignKey in a project-schema.xml table that
> refrences TURBINE_USER's USER_ID, my om classes are not correctly
generated.
>
> During om class generation I get this error:
>
> java.lang.NullPointerException
> at org.apache.xerces.framework.XMLParser.parse(XMLParser.java:917)
> at
>
org.apache.turbine.torque.transform.XmlToAppData.parseFile(XmlToAppData.java
> :134)
> at
>
org.apache.turbine.torque.ant.VTorqueTask.initControlContext(VTorqueTask.jav
> a:230)
> at
> org.apache.velocity.texen.ant.TexenTask.execute(TexenTask.java:299)
> at org.apache.tools.ant.Target.execute(Target.java:153)
> at org.apache.tools.ant.Project.runTarget(Project.java:898)
> at org.apache.tools.ant.Project.executeTarget(Project.java:536)
> at org.apache.tools.ant.taskdefs.Ant.execute(Ant.java:213)
> at
> org.apache.tools.ant.taskdefs.CallTarget.execute(CallTarget.java:103)
>
> at org.apache.tools.ant.Target.execute(Target.java:153)
> at org.apache.tools.ant.Project.runTarget(Project.java:898)
> at org.apache.tools.ant.Project.executeTarget(Project.java:536)
> at org.apache.tools.ant.Project.executeTargets(Project.java:510)
> at org.apache.tools.ant.Main.runBuild(Main.java:421)
> at org.apache.tools.ant.Main.main(Main.java:149)
>
> And the class that has the foriegn key does not get fully rendered. For
> example, the following method:
>
> public void setUserPrefrences(UserPrefrences v) throws Exception
> {
> aUserPrefrences = null;
> set${column.JavaName}(v.get${colFK.JavaName}());
> aUserPrefrences = v;
> }
>
> Is setting the foreingKey to refrence Turbine_User user_id column
possible?
> ( Or the wrong thing to do ?)
>
> Thanks
> Chris
>
>
> ---------------------------------------------------------------------
> 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
Re: TDK-Torque and ForiegnKey into TURBINE_USER
Posted by John McNally <jm...@collab.net>.
some things that I have added that could help with integration:
you can define a table in the xml schema and not have the sql generated
with the <table skipSql="true" attribute.
you can setup a class hierarchy like
BaseObject
TurbineUser
BaseTorqueTurbineUser
TorqueTurbineUser
and
BasePeer
TurbineUserPeer
BaseTorqueTurbineUserPeer
TorqueTurbineUserPeer
i.e. there are attributes <table baseClass and basePeer where you can
give the fully qualified classNames.
So it is conceivable to have torque generate the User class. There
could be quite a bit of complication in that the user class is expected
to be manipulated through TurbineSecurity.
I know Jon Stevens is looking at this, time permitting, but I wanted to
throw this information out there in case it helps anyone else
considering the problem.
John McNally
Leon Messerschmidt wrote:
>
> Hi Chris,
>
> You can create a dummy table for TURBINE_USER to prevent this error.
> Unfortunately you'll end up with wrong TurbineUser* classes in your om
> directory. I usually delete these and edit the code by hand to make it
> compile.
>
> I'd be grateful if you have a patch that works :-)
>
> ~ Leon
>
> ----- Original Message -----
> From: "Chris Campbell" <ca...@zodiacnetworks.com>
> To: <tu...@jakarta.apache.org>
> Sent: Thursday, April 19, 2001 2:13 AM
> Subject: TDK-Torque and ForiegnKey into TURBINE_USER
>
> > When I try to establish a foreignKey in a project-schema.xml table that
> > refrences TURBINE_USER's USER_ID, my om classes are not correctly
> generated.
> >
> > During om class generation I get this error:
> >
> > java.lang.NullPointerException
> > at org.apache.xerces.framework.XMLParser.parse(XMLParser.java:917)
> > at
> >
> org.apache.turbine.torque.transform.XmlToAppData.parseFile(XmlToAppData.java
> > :134)
> > at
> >
> org.apache.turbine.torque.ant.VTorqueTask.initControlContext(VTorqueTask.jav
> > a:230)
> > at
> > org.apache.velocity.texen.ant.TexenTask.execute(TexenTask.java:299)
> > at org.apache.tools.ant.Target.execute(Target.java:153)
> > at org.apache.tools.ant.Project.runTarget(Project.java:898)
> > at org.apache.tools.ant.Project.executeTarget(Project.java:536)
> > at org.apache.tools.ant.taskdefs.Ant.execute(Ant.java:213)
> > at
> > org.apache.tools.ant.taskdefs.CallTarget.execute(CallTarget.java:103)
> >
> > at org.apache.tools.ant.Target.execute(Target.java:153)
> > at org.apache.tools.ant.Project.runTarget(Project.java:898)
> > at org.apache.tools.ant.Project.executeTarget(Project.java:536)
> > at org.apache.tools.ant.Project.executeTargets(Project.java:510)
> > at org.apache.tools.ant.Main.runBuild(Main.java:421)
> > at org.apache.tools.ant.Main.main(Main.java:149)
> >
> > And the class that has the foriegn key does not get fully rendered. For
> > example, the following method:
> >
> > public void setUserPrefrences(UserPrefrences v) throws Exception
> > {
> > aUserPrefrences = null;
> > set${column.JavaName}(v.get${colFK.JavaName}());
> > aUserPrefrences = v;
> > }
> >
> > Is setting the foreingKey to refrence Turbine_User user_id column
> possible?
> > ( Or the wrong thing to do ?)
> >
> > Thanks
> > Chris
> >
> >
> > ---------------------------------------------------------------------
> > 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
Re: TDK-Torque and ForiegnKey into TURBINE_USER
Posted by Leon Messerschmidt <le...@opticode.co.za>.
Hi Chris,
You can create a dummy table for TURBINE_USER to prevent this error.
Unfortunately you'll end up with wrong TurbineUser* classes in your om
directory. I usually delete these and edit the code by hand to make it
compile.
I'd be grateful if you have a patch that works :-)
~ Leon
----- Original Message -----
From: "Chris Campbell" <ca...@zodiacnetworks.com>
To: <tu...@jakarta.apache.org>
Sent: Thursday, April 19, 2001 2:13 AM
Subject: TDK-Torque and ForiegnKey into TURBINE_USER
> When I try to establish a foreignKey in a project-schema.xml table that
> refrences TURBINE_USER's USER_ID, my om classes are not correctly
generated.
>
> During om class generation I get this error:
>
> java.lang.NullPointerException
> at org.apache.xerces.framework.XMLParser.parse(XMLParser.java:917)
> at
>
org.apache.turbine.torque.transform.XmlToAppData.parseFile(XmlToAppData.java
> :134)
> at
>
org.apache.turbine.torque.ant.VTorqueTask.initControlContext(VTorqueTask.jav
> a:230)
> at
> org.apache.velocity.texen.ant.TexenTask.execute(TexenTask.java:299)
> at org.apache.tools.ant.Target.execute(Target.java:153)
> at org.apache.tools.ant.Project.runTarget(Project.java:898)
> at org.apache.tools.ant.Project.executeTarget(Project.java:536)
> at org.apache.tools.ant.taskdefs.Ant.execute(Ant.java:213)
> at
> org.apache.tools.ant.taskdefs.CallTarget.execute(CallTarget.java:103)
>
> at org.apache.tools.ant.Target.execute(Target.java:153)
> at org.apache.tools.ant.Project.runTarget(Project.java:898)
> at org.apache.tools.ant.Project.executeTarget(Project.java:536)
> at org.apache.tools.ant.Project.executeTargets(Project.java:510)
> at org.apache.tools.ant.Main.runBuild(Main.java:421)
> at org.apache.tools.ant.Main.main(Main.java:149)
>
> And the class that has the foriegn key does not get fully rendered. For
> example, the following method:
>
> public void setUserPrefrences(UserPrefrences v) throws Exception
> {
> aUserPrefrences = null;
> set${column.JavaName}(v.get${colFK.JavaName}());
> aUserPrefrences = v;
> }
>
> Is setting the foreingKey to refrence Turbine_User user_id column
possible?
> ( Or the wrong thing to do ?)
>
> Thanks
> Chris
>
>
> ---------------------------------------------------------------------
> 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
TDK-Torque and ForiegnKey into TURBINE_USER
Posted by Chris Campbell <ca...@zodiacnetworks.com>.
When I try to establish a foreignKey in a project-schema.xml table that
refrences TURBINE_USER's USER_ID, my om classes are not correctly generated.
During om class generation I get this error:
java.lang.NullPointerException
at org.apache.xerces.framework.XMLParser.parse(XMLParser.java:917)
at
org.apache.turbine.torque.transform.XmlToAppData.parseFile(XmlToAppData.java
:134)
at
org.apache.turbine.torque.ant.VTorqueTask.initControlContext(VTorqueTask.jav
a:230)
at
org.apache.velocity.texen.ant.TexenTask.execute(TexenTask.java:299)
at org.apache.tools.ant.Target.execute(Target.java:153)
at org.apache.tools.ant.Project.runTarget(Project.java:898)
at org.apache.tools.ant.Project.executeTarget(Project.java:536)
at org.apache.tools.ant.taskdefs.Ant.execute(Ant.java:213)
at
org.apache.tools.ant.taskdefs.CallTarget.execute(CallTarget.java:103)
at org.apache.tools.ant.Target.execute(Target.java:153)
at org.apache.tools.ant.Project.runTarget(Project.java:898)
at org.apache.tools.ant.Project.executeTarget(Project.java:536)
at org.apache.tools.ant.Project.executeTargets(Project.java:510)
at org.apache.tools.ant.Main.runBuild(Main.java:421)
at org.apache.tools.ant.Main.main(Main.java:149)
And the class that has the foriegn key does not get fully rendered. For
example, the following method:
public void setUserPrefrences(UserPrefrences v) throws Exception
{
aUserPrefrences = null;
set${column.JavaName}(v.get${colFK.JavaName}());
aUserPrefrences = v;
}
Is setting the foreingKey to refrence Turbine_User user_id column possible?
( Or the wrong thing to do ?)
Thanks
Chris
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
Re: Location of javadoc api documentation for the tdk builds?
Posted by Jon Stevens <jo...@latchkey.com>.
on 4/18/01 4:56 PM, "Darren Pamatat" <dp...@yahoo.com> wrote:
> Where is the javdoc api documentation for the tdk builds found at:
> http://jakarta.apache.org/turbine/tdk/
>
> The tdk includes all kinds of documentation but is missing the api
> (javadocs) for the turbine packages. Where is the javadoc
> corresponding to these versions?
>
> Thanks
> Darren
Check out Turbine from CVS.
Type:
cd jakarta-turbine/build
./build-turbine.sh javadocs
-jon
--
If you come from a Perl or PHP background, JSP is a way to take
your pain to new levels. --Anonymous
<http://jakarta.apache.org/velocity/ymtd/ymtd.html>
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
Location of javadoc api documentation for the tdk builds?
Posted by Darren Pamatat <dp...@yahoo.com>.
Where is the javdoc api documentation for the tdk builds found at:
http://jakarta.apache.org/turbine/tdk/
The tdk includes all kinds of documentation but is missing the api
(javadocs) for the turbine packages. Where is the javadoc
corresponding to these versions?
Thanks
Darren
__________________________________________________
Do You Yahoo!?
Yahoo! Auctions - buy the things you want at great prices
http://auctions.yahoo.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
Seperating Application Flow from actions/views
Posted by Russell Edens <ru...@speakeasy.net>.
John McNally wrote:
> I am not satisfied with the approach, though. I think an xml
> specification of application flow would be much better, so that actions
> and templates do not have to contain so much of this logic. I think
> this has broader scope than intake and just handling error screens and
> so should be built separately. But of course that is quite a project.
This is a worthy project. Before using Turbine we built a system that defined
the relationships between views and models in XML. It worked great. The
application flow was not defined in the view, this allowed views to be reused
without adding custom logic. We also used this layer to define the binding
between the model and the view. This way the same view could render different
data depending on the users context. As an example, a screen that updates
employee information would bind to a different model depending on if the logged
in employee was 'self' or 'manager'. The binding of the view and model used
roles to determine the appropriate binding.
An extreem example of the power of this system was a Shopping cart application
that allowed a customer service rep to logon to impersonate the user. What
views they could see were determined by the XML. It was a sub-set of what the
user saw. They could see the shopping basket but could not submit it. In
essense they could trouble shoot the entire application with the user in
read-only mode. The views to render this did not change at all. The models did
not change at all. New XML defining what screen flow based on role was all that
was added to achieve this.
My intention was to either build this layer on top of Turbine or add it to
Turbine. If there is a general consensus that this functionality is worth
building into Turbine - I'm game.
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
Re: RunData parameter history ( was: Quick Question )
Posted by Johnny Cass <ar...@jab.org>.
John McNally wrote:
>
> This sounds fine to me. I assume you are storing the vector in the
> session.
Each portlet manages it's own history vector. Parameterparsers are only
added to the portlet's history if they have an effect on the portlet's
content.
> How do you handle browsers within the same session at
> different states?
This is the one snag... :(
> It is not a problem to declare an application single
> browser only, I just do not want it to become the standard imposed by
> Turbine. And there is no reason to do it for a simple String parameter,
> like lastTemplate.
>
> The other problem to be addressed is if other state data is being stored
> in the session, you need to save copies of the User temp and perm
> hashtables.
In our case, we want the state to be determined by the URL alone. There
shouldn't be any other state dependencies.
> And in general you need to worry about other storage of
> data. The solution is very application dependent.
>
> john mcnally
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
Re: RunData parameter history ( was: Quick Question )
Posted by John McNally <jm...@collab.net>.
This sounds fine to me. I assume you are storing the vector in the
session. How do you handle browsers within the same session at
different states? It is not a problem to declare an application single
browser only, I just do not want it to become the standard imposed by
Turbine. And there is no reason to do it for a simple String parameter,
like lastTemplate.
The other problem to be addressed is if other state data is being stored
in the session, you need to save copies of the User temp and perm
hashtables. And in general you need to worry about other storage of
data. The solution is very application dependent.
john mcnally
Johnny Cass wrote:
>
> Jon Stevens wrote:
> >
> > on 4/16/01 12:47 PM, "Daniel Rall" <dl...@collab.net> wrote:
> >
> > Jon Stevens <jo...@latchkey.com> writes:
> >
> > nextNextTemplate
> >
> > nextTemplateSquared
> >
> > templateAfterTheNextTemplate
> >
>
> I tried to do something similar using Jetspeed. I wanted to add 'Back'
> and 'Forward' buttons for each portlet ( just like a browser ). I wrote
> a RunDataParameterHistory class that added the RunData's ParameterParser
> object to a Vector on each new request.
>
> When the portlet renders, it checks if one of the back or forward
> buttons were pressed and then uses the previous or next ParameterParser
> object from the history for all processing instead of the current
> request's RunData's ParameterParser.
>
> I have no idea if this behaviour is at all acceptable.
>
> What I liked about it is that *ALL* the RunData parameters are
> preserved. So if you displayed a specific template, executed an action,
> and supplied parameters for that action on some previous request, all
> you needed to do was fetch the right ParameterParser from the history
> and the page will render exactly the way it did the first time ( with
> all the actions executed again and the right template displayed ).
>
> Anybody think I took a wrong turn?
>
> - Johnny
>
> ---------------------------------------------------------------------
> 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
Re: RunData parameter history ( was: Quick Question )
Posted by Johnny Cass <ar...@jab.org>.
Jon Stevens wrote:
>
> on 4/16/01 12:47 PM, "Daniel Rall" <dl...@collab.net> wrote:
>
> Jon Stevens <jo...@latchkey.com> writes:
>
> nextNextTemplate
>
> nextTemplateSquared
>
> templateAfterTheNextTemplate
>
I tried to do something similar using Jetspeed. I wanted to add 'Back'
and 'Forward' buttons for each portlet ( just like a browser ). I wrote
a RunDataParameterHistory class that added the RunData's ParameterParser
object to a Vector on each new request.
When the portlet renders, it checks if one of the back or forward
buttons were pressed and then uses the previous or next ParameterParser
object from the history for all processing instead of the current
request's RunData's ParameterParser.
I have no idea if this behaviour is at all acceptable.
What I liked about it is that *ALL* the RunData parameters are
preserved. So if you displayed a specific template, executed an action,
and supplied parameters for that action on some previous request, all
you needed to do was fetch the right ParameterParser from the history
and the page will render exactly the way it did the first time ( with
all the actions executed again and the right template displayed ).
Anybody think I took a wrong turn?
- Johnny
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
Re: Quick Question
Posted by Jon Stevens <jo...@latchkey.com>.
on 4/16/01 12:47 PM, "Daniel Rall" <dl...@collab.net> wrote:
> Jon Stevens <jo...@latchkey.com> writes:
>
>> on 4/16/01 11:27 AM, "John McNally" <jm...@collab.net> wrote:
>>
>>> 3. The purpose of the nextTemplate is to keep the application flow
>>> specification out of the java actions. Though it is only successful in
>>> the simple cases where there is one nextTemplate. In many circumstances
>>> there is at least two potential nextTemplates and in this case you are
>>> back to coding the choice in the action.
>>
>> I think that this is really application specific and not Turbine specific.
>> We could simply standardize (in Scarab) on nextTemplate, nextTemplate2 and
>> that wouldn't be an issue.
>
> nextTemplate2 is not a meaningful name.
nextNextTemplate
nextTemplateSquared
templateAfterTheNextTemplate
I wasn't trying to solve the problem, only give suggestions.
-jon
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
Re: Quick Question
Posted by Daniel Rall <dl...@collab.net>.
Jon Stevens <jo...@latchkey.com> writes:
> on 4/16/01 11:27 AM, "John McNally" <jm...@collab.net> wrote:
>
> > 3. The purpose of the nextTemplate is to keep the application flow
> > specification out of the java actions. Though it is only successful in
> > the simple cases where there is one nextTemplate. In many circumstances
> > there is at least two potential nextTemplates and in this case you are
> > back to coding the choice in the action.
>
> I think that this is really application specific and not Turbine specific.
> We could simply standardize (in Scarab) on nextTemplate, nextTemplate2 and
> that wouldn't be an issue.
nextTemplate2 is not a meaningful name.
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
Re: Quick Question
Posted by Jon Stevens <jo...@latchkey.com>.
on 4/16/01 11:27 AM, "John McNally" <jm...@collab.net> wrote:
> 3. The purpose of the nextTemplate is to keep the application flow
> specification out of the java actions. Though it is only successful in
> the simple cases where there is one nextTemplate. In many circumstances
> there is at least two potential nextTemplates and in this case you are
> back to coding the choice in the action.
I think that this is really application specific and not Turbine specific.
We could simply standardize (in Scarab) on nextTemplate, nextTemplate2 and
that wouldn't be an issue.
-jon
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
Re: Quick Question
Posted by John McNally <jm...@collab.net>.
Let me try to answer this again a bit clearer.
1. I think this should be coded in the http request data and not stored
in the session.
2. This can be standardized as a pair of parameters
a) template and nextTemplate
b) previousTemplate and template
scarab is using (a). But I have no objection to style (b) it might be
good to standardize and build in some convenience functionality.
3. The purpose of the nextTemplate is to keep the application flow
specification out of the java actions. Though it is only successful in
the simple cases where there is one nextTemplate. In many circumstances
there is at least two potential nextTemplates and in this case you are
back to coding the choice in the action.
So if the benefit of removing the application flow from the java classes
is to be achieved, it will require a more comprehensive solution. Or
maybe someone would like to comment against this goal?
John McNally
John McNally wrote:
>
> Intake provides methods for determining if data entered is valid. The
> general method I use for processing forms is to default back to the form
> used to enter the data. If the data is valid the template is set to the
> success screen which is added to the query/request parameters as
> "nextTemplate". Other than habit and similarity to cgi-style
> applications, I am not sure it has any advantage over:
>
> Some may prefer to set the template in the form action attribute to
> default to the success template and then have the action revert to a
> "lastTemplate" in the case of invalid data. It may be easier to code a
> general solution for this approach.
>
> Either way I think it is best to use request parameters (usually
> specified as pathinfo in turbine) over session. As this limits the use
> of multiple browser windows or at least makes their management more
> complex.
>
> I am not satisfied with the approach, though. I think an xml
> specification of application flow would be much better, so that actions
> and templates do not have to contain so much of this logic. I think
> this has broader scope than intake and just handling error screens and
> so should be built separately. But of course that is quite a project.
>
> John McNally
>
> Jason van Zyl wrote:
> >
> > Michael Stanley wrote:
> > >
> > > > You can store information like this in the session with
> > > > data.getUser().setTemp("last_template", template)
> > >
> > > Well I though about that too. This solution doesn't work however unless
> > > a user is logged in.
> >
> > Is this for users that never login, or is this for failed login
> > attempts. Can you not use the anonymous user to store info for
> > the first case?
> >
> > > I would think it be better to store the information
> > > in the Session. After further inspection I think it be good to add code
> > > that stores Screen and Layout in the Session within the TemplateScreen
> > > doBuild (or doPostBuild - however I don't know if it be a good idea to
> > > store screens that caused errors). Then add functions to RunData
> > > getLastScreen and setLastScreen (same for layout). The setLastScreen can
> > > be initialized from the Session data previous to changing it.
> > >
> > > I'm going to patch this and send it to you later in the day.
> >
> > All you have to do is store the template, the rest can be determined
> > by the template service. For error processing it would be nice to
> > be able to have methods to control the flow in the case of errors,
> > I agree. I just want to make sure this isn't something that intake
> > is already going to deal with.
> >
> > >
> > > > But it might be nice to come up with some standard tags for this,
> > > > I'm not sure if intake deals with error processing. John, does it?
> > >
> > > I'm not sure what intake does. Can you give me a brief overview and
> > > perhaps and example?
> >
> > It is a service that will deal with form validation primarily, there
> > really aren't any docs, and the only example is in the scarab code
> > base.
> >
> > I'll take a look over your last email, I'm not sure what you are
> > trying to do.
> >
> > > > >
> > > > > Mike
> > > > >
> > > > > ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
> > > > > For additional commands, e-mail: turbine-user-help@jakarta.apache.org
> > >
> > > > --
> > > > jvz.
> > >
> > > > Jason van Zyl
> > > > jvanzyl@apache.org
> > >
> > > > http://jakarta.apache.org/velocity
> > > > http://jakarta.apache.org/turbine
> > > > http://tambora.zenplex.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
> >
> > --
> > jvz.
> >
> > Jason van Zyl
> > jvanzyl@apache.org
> >
> > http://jakarta.apache.org/velocity
> > http://jakarta.apache.org/turbine
> > http://tambora.zenplex.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
Re: Quick Question
Posted by John McNally <jm...@collab.net>.
Intake provides methods for determining if data entered is valid. The
general method I use for processing forms is to default back to the form
used to enter the data. If the data is valid the template is set to the
success screen which is added to the query/request parameters as
"nextTemplate". Other than habit and similarity to cgi-style
applications, I am not sure it has any advantage over:
Some may prefer to set the template in the form action attribute to
default to the success template and then have the action revert to a
"lastTemplate" in the case of invalid data. It may be easier to code a
general solution for this approach.
Either way I think it is best to use request parameters (usually
specified as pathinfo in turbine) over session. As this limits the use
of multiple browser windows or at least makes their management more
complex.
I am not satisfied with the approach, though. I think an xml
specification of application flow would be much better, so that actions
and templates do not have to contain so much of this logic. I think
this has broader scope than intake and just handling error screens and
so should be built separately. But of course that is quite a project.
John McNally
Jason van Zyl wrote:
>
> Michael Stanley wrote:
> >
> > > You can store information like this in the session with
> > > data.getUser().setTemp("last_template", template)
> >
> > Well I though about that too. This solution doesn't work however unless
> > a user is logged in.
>
> Is this for users that never login, or is this for failed login
> attempts. Can you not use the anonymous user to store info for
> the first case?
>
> > I would think it be better to store the information
> > in the Session. After further inspection I think it be good to add code
> > that stores Screen and Layout in the Session within the TemplateScreen
> > doBuild (or doPostBuild - however I don't know if it be a good idea to
> > store screens that caused errors). Then add functions to RunData
> > getLastScreen and setLastScreen (same for layout). The setLastScreen can
> > be initialized from the Session data previous to changing it.
> >
> > I'm going to patch this and send it to you later in the day.
>
> All you have to do is store the template, the rest can be determined
> by the template service. For error processing it would be nice to
> be able to have methods to control the flow in the case of errors,
> I agree. I just want to make sure this isn't something that intake
> is already going to deal with.
>
> >
> > > But it might be nice to come up with some standard tags for this,
> > > I'm not sure if intake deals with error processing. John, does it?
> >
> > I'm not sure what intake does. Can you give me a brief overview and
> > perhaps and example?
>
> It is a service that will deal with form validation primarily, there
> really aren't any docs, and the only example is in the scarab code
> base.
>
> I'll take a look over your last email, I'm not sure what you are
> trying to do.
>
> > > >
> > > > Mike
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
> > > > For additional commands, e-mail: turbine-user-help@jakarta.apache.org
> >
> > > --
> > > jvz.
> >
> > > Jason van Zyl
> > > jvanzyl@apache.org
> >
> > > http://jakarta.apache.org/velocity
> > > http://jakarta.apache.org/turbine
> > > http://tambora.zenplex.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
>
> --
> jvz.
>
> Jason van Zyl
> jvanzyl@apache.org
>
> http://jakarta.apache.org/velocity
> http://jakarta.apache.org/turbine
> http://tambora.zenplex.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
Re: Quick Question
Posted by Jason van Zyl <jv...@apache.org>.
Michael Stanley wrote:
>
> > You can store information like this in the session with
> > data.getUser().setTemp("last_template", template)
>
> Well I though about that too. This solution doesn't work however unless
> a user is logged in.
Is this for users that never login, or is this for failed login
attempts. Can you not use the anonymous user to store info for
the first case?
> I would think it be better to store the information
> in the Session. After further inspection I think it be good to add code
> that stores Screen and Layout in the Session within the TemplateScreen
> doBuild (or doPostBuild - however I don't know if it be a good idea to
> store screens that caused errors). Then add functions to RunData
> getLastScreen and setLastScreen (same for layout). The setLastScreen can
> be initialized from the Session data previous to changing it.
>
> I'm going to patch this and send it to you later in the day.
All you have to do is store the template, the rest can be determined
by the template service. For error processing it would be nice to
be able to have methods to control the flow in the case of errors,
I agree. I just want to make sure this isn't something that intake
is already going to deal with.
>
> > But it might be nice to come up with some standard tags for this,
> > I'm not sure if intake deals with error processing. John, does it?
>
> I'm not sure what intake does. Can you give me a brief overview and
> perhaps and example?
It is a service that will deal with form validation primarily, there
really aren't any docs, and the only example is in the scarab code
base.
I'll take a look over your last email, I'm not sure what you are
trying to do.
> > >
> > > Mike
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: turbine-user-help@jakarta.apache.org
>
> > --
> > jvz.
>
> > Jason van Zyl
> > jvanzyl@apache.org
>
> > http://jakarta.apache.org/velocity
> > http://jakarta.apache.org/turbine
> > http://tambora.zenplex.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
--
jvz.
Jason van Zyl
jvanzyl@apache.org
http://jakarta.apache.org/velocity
http://jakarta.apache.org/turbine
http://tambora.zenplex.org
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
Re: Quick Question
Posted by Jon Stevens <jo...@latchkey.com>.
on 4/16/01 11:23 AM, "Michael Stanley" <mp...@syr.edu> wrote:
> I know, I was wrong about when that user object gets initiated. I was
> under the impression that it was a null object until login. This I
> realize is not the case. :-)
>
> Mike
Long ago (about 1.5 years) it used to be, but we fixed that...
-jon
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
Re: Quick Question
Posted by Michael Stanley <mp...@syr.edu>.
> > I was under the
> > (false) impression that it was stored within a user object that gets
> > initiated after login.
> It is stored in a user object.
I know, I was wrong about when that user object gets initiated. I was
under the impression that it was a null object until login. This I
realize is not the case. :-)
Mike
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
Re: Quick Question
Posted by Jon Stevens <jo...@latchkey.com>.
on 4/16/01 10:38 AM, "Michael Stanley" <mp...@syr.edu> wrote:
> I was under the
> (false) impression that it was stored within a user object that gets
> initiated after login.
It is stored in a user object.
-jon
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
Re: Quick Question
Posted by Michael Stanley <mp...@syr.edu>.
> >> You can store information like this in the session with
> >> data.getUser().setTemp("last_template", template)
> >
> > Well I though about that too. This solution doesn't work however unless
> > a user is logged in.
> Yes it does. Anonymous users can be tracked via session id.
Well, than that solves that. I wasn't aware that
data.getUser().setTemp() stored values in the session. I was under the
(false) impression that it was stored within a user object that gets
initiated after login.
The solution I came up with is actually the same thing, but sloppier :-)
Thanks for your help
Mike
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
Re: Quick Question
Posted by Leon Messerschmidt <le...@opticode.co.za>.
-1
If you open multiple browser instances (in some environments people tend to
do that) on the client side this code is going to break.
~ Leon
----- Original Message -----
From: "Michael Stanley" <mp...@syr.edu>
To: <tu...@jakarta.apache.org>
Sent: Tuesday, April 17, 2001 1:28 AM
Subject: Re: Quick Question
Here are a couple of patches that I wrote that add methods to the RunData
object to retrieve Last Screen etc. They use user temp info to
temporarily keep track of screen templates and layout templates.
Here they are:
*** RunData.java Fri Apr 13 17:17:50 2001
---
/home/paragon/platform/src/turbine-deploy/src/java/org/apache/turbine/ut
il/RunData.java Mon Apr 16 15:36:54 2001
***************
*** 617,620 ****
--- 617,649 ----
* @return a hashtable for debug variables.
*/
public Hashtable getVarDebug();
+
+ /**
+ * Sets the Last Screen Template
+ *
+ * @param last_screen the last screen template
+ */
+ public void setLastScreenTemplate(String last_screen);
+
+ /**
+ * Gets the Last Screen Template
+ *
+ * @return the last screen template
+ */
+ public String getLastScreenTemplate();
+
+ /**
+ * Sets the Last Layout Template
+ *
+ * @param last_layout the last layout template
+ */
+ public void setLastLayoutTemplate(String last_layout);
+
+ /**
+ * Gets the Last Layout Template
+ *
+ * @return the last layout template
+ */
+ public String getLastLayoutTemplate();
+
}
*** DefaultTurbineRunData.java Fri Apr 13 17:17:51 2001
---
/home/paragon/platform/src/turbine-deploy/src/java/org/apache/turbine/se
rvices/rundata/DefaultTurbineRunData.java Mon Apr 16 16:39:10 2001
***************
*** 287,292 ****
--- 287,302 ----
private Hashtable varDebug = new Hashtable();
/**
+ * A holder for last screen template.
+ */
+ private String lastScreenTemplate = null;
+
+ /**
+ * A holder for last layout template.
+ */
+ private String lastLayoutTemplate = null;
+
+ /**
* Attempts to get the User object from the session. If it does
* not exist, it returns null.
*
***************
*** 1377,1380 ****
--- 1387,1426 ----
{
getServerData().setScriptName(sn);
}
+
+ /**
+ * Sets the Last Layout Template
+ *
+ * @param last_layout the last layout template
+ */
+ public void setLastLayoutTemplate(String last_layout){
+ lastLayoutTemplate = last_layout;
+ }
+
+ /**
+ * Sets the Last Screen Template
+ *
+ * @param last_screen the last screen template
+ */
+ public void setLastScreenTemplate(String last_screen) {
+ lastScreenTemplate = last_screen;
+ }
+
+ /**
+ * Gets the Last Layout Template
+ *
+ * @return the last layout template
+ */
+ public String getLastLayoutTemplate() {
+ return lastLayoutTemplate;
+ }
+
+ /**
+ * Gets the Last Screen Template
+ *
+ * @return the last screen template
+ */
+ public String getLastScreenTemplate() {
+ return lastScreenTemplate;
+ }
}
*** TemplateScreen.java Fri Apr 13 17:17:54 2001
---
/home/paragon/platform/src/turbine-deploy/src/java/org/apache/turbine/mo
dules/screens/TemplateScreen.java Mon Apr 16 16:44:52 2001
***************
*** 67,72 ****
--- 67,73 ----
import org.apache.turbine.util.*;
import org.apache.turbine.services.*;
import org.apache.turbine.services.template.*;
+ import org.apache.turbine.services.resources.TurbineResources;
/**
* Template Screen.
***************
*** 114,121 ****
*/
protected void doPostBuildTemplate( RunData data )
{
! // empty
}
/**
* This method is called by the Screenloader to construct the
--- 115,157 ----
*/
protected void doPostBuildTemplate( RunData data )
{
! // Set the values of the last templates used
! setLastTemplates(data);
}
+
+ /**
+ * This method is used to set lastScreen and lastLayout in
+ * the RunData object. It uses a users session's data to
+ * temporarily store current template values.
+ * This method can be overridden (??)
+ * @param data Turbine information
+ * @return void
+ */
+ protected void setLastTemplates(RunData data) {
+
+ // Set default Screen
+ String defaultScreen =
+ TurbineResources.getString("template.homepage");
+
+ // Set default Layout
+ String defaultLayout =
+
TurbineResources.getString("services.TurbineTemplateService.default.layo
ut.template");
+
+ // Add values to RunData object
+ data.setLastScreenTemplate((String)
+ data.getUser().getTemp("last_screen",
+
defaultScreen));
+ data.setLastLayoutTemplate((String)
+ data.getUser().getTemp("last_layout",
+
defaultLayout));
+
+ // Store current template values in User's Session
+ String last_screen = data.getScreenTemplate();
+ data.getUser().setTemp("last_screen", last_screen);
+
+ String last_layout = data.getLayoutTemplate();
+ data.getUser().setTemp("last_layout", last_layout);
+ }
/**
* This method is called by the Screenloader to construct the
---------------------------------------------------------------------
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
Re: Quick Question
Posted by Sean Legassick <se...@informage.net>.
In message <B7...@latchkey.com>, Jon Stevens
<jo...@latchkey.com> writes
><http://scarab.tigris.org/source/browse/scarab/src/java/org/tigris/scarab/ut
>il/ScarabLink.java?rev=1.2&content-type=text/x-cvsweb-markup>
>
>The commented out part of setPage() is similar to what you are talking
>about.
Yep, that's the kind of thing - lots of things can be automatically
encoded into the URI via this methodology.
--
Sean Legassick
sean@informage.net
Je suis un homme: rien d'humain en m'est étranger
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
Re: Quick Question
Posted by Sean Legassick <se...@informage.net>.
In message <20...@dingus.1019>, Michael Stanley
<mp...@syr.edu> writes
>Would it? If a user recalls a URI from ScreenX lastTemplate will be set
>to ScreenX, or if a user calls a URI from an outside page
>(www.somewherelese.com) lastTemplate will be set to template.homepage.
>This default behavior avoids the confusion.
Could still be confusing, if say an action is directing the user to
lastTemplate with an error message ... although a user recalling a URI
containing form data is slightly obscure (although not impossible).
> I was however looking for a solution to avoid the template
>writter having to write a code like
>
>$link.setAction("some.action").setPage("resultPage").setQueryData("last_
>template", $data.getScreenTemplate()
The solution I had in mind avoids this step, the "link" context object
could be configured to set the parameter automatically. I think I'll add
this functionality to TemplateLink and make the behaviour switchable via
a global property.
>and
>
>$data.getParameters().getString("last_template")
Yep, this is how you'd get it - (well actually you could say
$data.Parameters.last_template for brevity)
--
Sean Legassick
sean@informage.net
Je suis un homme: rien d'humain en m'est étranger
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
Re: Quick Question
Posted by Michael Stanley <mp...@syr.edu>.
> As a preference, it feels a bit wrong to put something that is a request
> specific variable (what template generated this request) into the
> session.
Ok I see that.
> Pragmatically, as well as the multiple windows issue, if the user
> recalls a URI from their favorites in the middle of a session (or
> otherwise uses a previously remembered URI) the session method will
> result in confusion.
Would it? If a user recalls a URI from ScreenX lastTemplate will be set
to ScreenX, or if a user calls a URI from an outside page
(www.somewherelese.com) lastTemplate will be set to template.homepage.
This default behavior avoids the confusion.
> If you don't want people hand navigating around your app then the
> session access counter uses a combination of session data and URI data
> precisely because this causes a disparity that can be spotted...
I understand but I'm not really concerned with people hand navigating
through the app. I simply just felt the need to have a standard way of
getting the lastTemplate. I don't really see a difference with putting
this in the request data vs the session data (except for the Multiple
Window problem which I guess is reason enough to do it via request
method) I was however looking for a solution to avoid the template
writter having to write a code like
$link.setAction("some.action").setPage("resultPage").setQueryData("last_
template", $data.getScreenTemplate()
and
$data.getParameters().getString("last_template")
I simply felt that it be beneficial to have LastTemplate always available
via methods such as
$data.getLastTemplate()
$data.setLastTemplate()
Mike Stanley
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
Re: Quick Question
Posted by Sean Legassick <se...@informage.net>.
In message <20...@dingus.1019>, Michael Stanley
<mp...@syr.edu> writes
>Why do you prefer holding lastTemplate in request parameters rather than
>in session data? Is it more efficient (memory, speed)? Or is it simply
>preference?
As a preference, it feels a bit wrong to put something that is a request
specific variable (what template generated this request) into the
session.
Pragmatically, as well as the multiple windows issue, if the user
recalls a URI from their favorites in the middle of a session (or
otherwise uses a previously remembered URI) the session method will
result in confusion.
If you don't want people hand navigating around your app then the
session access counter uses a combination of session data and URI data
precisely because this causes a disparity that can be spotted...
--
Sean Legassick
sean@informage.net
Je suis un homme: rien d'humain en m'est étranger
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
Re: Quick Question
Posted by John McNally <jm...@collab.net>.
Michael Stanley wrote:
>
> Why do you prefer holding lastTemplate in request parameters rather than
> in session data? Is it more efficient (memory, speed)? Or is it simply
> preference?
>
> Mike
>
I think the complexity in dealing with multiple browser windows is not
worth saving a few characters of request parameters. We could adopt the
session approach to the other standard request parameters (action,
template) as well, but they are implemented as request parameters. If
you think the session is a better place to store data like this, make a
case for it.
It could be said that the only reason to implement the template data as
request data is that it facilitates log analysis and bookmarking in
which the lastTemplate data is not as important. But I am just trying
to figure out why the session might be preferred, and I do not see it.
John McNally
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
Re: Quick Question
Posted by Michael Stanley <mp...@syr.edu>.
Why do you prefer holding lastTemplate in request parameters rather than
in session data? Is it more efficient (memory, speed)? Or is it simply
preference?
Mike
> +1
> john mcnally
> Sean Legassick wrote:
> >
> > In message <3A...@collab.net>, John McNally
> > <jm...@collab.net> writes
> > >-1 you did not convince me that storing this in the session is a good
> > >idea. It is only required to set the screen template and that can
> > >easily be accomplished in the url's generated for a template.
> >
> > Rather than hand-stuffing lastTemplate into the request params in a
> > template, an overridden version of TemplateLink could be written that
> > does this automatically... (and easily slotted in by altering the
> > tool.request.link entry in TR.properties)
> >
> > I've been meaning to look at doing this for an automatic session access
> > counter generating TemplateLink - I could do the same for lastTemplate
> > as well (it's something I've wanted).
> >
> > --
> > Sean Legassick
> > sean@informage.net
> > Je suis un homme: rien d'humain en m'est étranger
> >
> > ---------------------------------------------------------------------
> > 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
Re: Quick Question
Posted by Jon Stevens <jo...@latchkey.com>.
<http://scarab.tigris.org/source/browse/scarab/src/java/org/tigris/scarab/ut
il/ScarabLink.java?rev=1.2&content-type=text/x-cvsweb-markup>
The commented out part of setPage() is similar to what you are talking
about.
-jon
on 4/16/01 7:14 PM, "John McNally" <jm...@collab.net> wrote:
> +1
> john mcnally
>
> Sean Legassick wrote:
>>
>> In message <3A...@collab.net>, John McNally
>> <jm...@collab.net> writes
>>> -1 you did not convince me that storing this in the session is a good
>>> idea. It is only required to set the screen template and that can
>>> easily be accomplished in the url's generated for a template.
>>
>> Rather than hand-stuffing lastTemplate into the request params in a
>> template, an overridden version of TemplateLink could be written that
>> does this automatically... (and easily slotted in by altering the
>> tool.request.link entry in TR.properties)
>>
>> I've been meaning to look at doing this for an automatic session access
>> counter generating TemplateLink - I could do the same for lastTemplate
>> as well (it's something I've wanted).
>>
>> --
>> Sean Legassick
>> sean@informage.net
>> Je suis un homme: rien d'humain en m'est étranger
>>
>> ---------------------------------------------------------------------
>> 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
>
--
If you come from a Perl or PHP background, JSP is a way to take
your pain to new levels. --Anonymous
<http://jakarta.apache.org/velocity/ymtd/ymtd.html>
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
Re: Quick Question
Posted by John McNally <jm...@collab.net>.
+1
john mcnally
Sean Legassick wrote:
>
> In message <3A...@collab.net>, John McNally
> <jm...@collab.net> writes
> >-1 you did not convince me that storing this in the session is a good
> >idea. It is only required to set the screen template and that can
> >easily be accomplished in the url's generated for a template.
>
> Rather than hand-stuffing lastTemplate into the request params in a
> template, an overridden version of TemplateLink could be written that
> does this automatically... (and easily slotted in by altering the
> tool.request.link entry in TR.properties)
>
> I've been meaning to look at doing this for an automatic session access
> counter generating TemplateLink - I could do the same for lastTemplate
> as well (it's something I've wanted).
>
> --
> Sean Legassick
> sean@informage.net
> Je suis un homme: rien d'humain en m'est étranger
>
> ---------------------------------------------------------------------
> 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
Re: Quick Question
Posted by Sean Legassick <se...@informage.net>.
In message <3A...@collab.net>, John McNally
<jm...@collab.net> writes
>-1 you did not convince me that storing this in the session is a good
>idea. It is only required to set the screen template and that can
>easily be accomplished in the url's generated for a template.
Rather than hand-stuffing lastTemplate into the request params in a
template, an overridden version of TemplateLink could be written that
does this automatically... (and easily slotted in by altering the
tool.request.link entry in TR.properties)
I've been meaning to look at doing this for an automatic session access
counter generating TemplateLink - I could do the same for lastTemplate
as well (it's something I've wanted).
--
Sean Legassick
sean@informage.net
Je suis un homme: rien d'humain en m'est étranger
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
Re: Quick Question
Posted by Jon Stevens <jo...@latchkey.com>.
on 4/16/01 4:41 PM, "John McNally" <jm...@collab.net> wrote:
> -1 you did not convince me that storing this in the session is a good
> idea. It is only required to set the screen template and that can
> easily be accomplished in the url's generated for a template.
>
> john mcnally
-1 on code formatting reasons as well.
There is documentation on the website which says how to format code
properly.
-jon
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
Re: Quick Question
Posted by John McNally <jm...@collab.net>.
-1 you did not convince me that storing this in the session is a good
idea. It is only required to set the screen template and that can
easily be accomplished in the url's generated for a template.
john mcnally
Michael Stanley wrote:
>
> Here are a couple of patches that I wrote that add methods to the RunData
> object to retrieve Last Screen etc. They use user temp info to
> temporarily keep track of screen templates and layout templates.
>
> Here they are:
>
> *** RunData.java Fri Apr 13 17:17:50 2001
> ---
> /home/paragon/platform/src/turbine-deploy/src/java/org/apache/turbine/ut
> il/RunData.java Mon Apr 16 15:36:54 2001
> ***************
> *** 617,620 ****
> --- 617,649 ----
> * @return a hashtable for debug variables.
> */
> public Hashtable getVarDebug();
> +
> + /**
> + * Sets the Last Screen Template
> + *
> + * @param last_screen the last screen template
> + */
> + public void setLastScreenTemplate(String last_screen);
> +
> + /**
> + * Gets the Last Screen Template
> + *
> + * @return the last screen template
> + */
> + public String getLastScreenTemplate();
> +
> + /**
> + * Sets the Last Layout Template
> + *
> + * @param last_layout the last layout template
> + */
> + public void setLastLayoutTemplate(String last_layout);
> +
> + /**
> + * Gets the Last Layout Template
> + *
> + * @return the last layout template
> + */
> + public String getLastLayoutTemplate();
> +
> }
>
> *** DefaultTurbineRunData.java Fri Apr 13 17:17:51 2001
> ---
> /home/paragon/platform/src/turbine-deploy/src/java/org/apache/turbine/se
> rvices/rundata/DefaultTurbineRunData.java Mon Apr 16 16:39:10 2001
> ***************
> *** 287,292 ****
> --- 287,302 ----
> private Hashtable varDebug = new Hashtable();
>
> /**
> + * A holder for last screen template.
> + */
> + private String lastScreenTemplate = null;
> +
> + /**
> + * A holder for last layout template.
> + */
> + private String lastLayoutTemplate = null;
> +
> + /**
> * Attempts to get the User object from the session. If it does
> * not exist, it returns null.
> *
> ***************
> *** 1377,1380 ****
> --- 1387,1426 ----
> {
> getServerData().setScriptName(sn);
> }
> +
> + /**
> + * Sets the Last Layout Template
> + *
> + * @param last_layout the last layout template
> + */
> + public void setLastLayoutTemplate(String last_layout){
> + lastLayoutTemplate = last_layout;
> + }
> +
> + /**
> + * Sets the Last Screen Template
> + *
> + * @param last_screen the last screen template
> + */
> + public void setLastScreenTemplate(String last_screen) {
> + lastScreenTemplate = last_screen;
> + }
> +
> + /**
> + * Gets the Last Layout Template
> + *
> + * @return the last layout template
> + */
> + public String getLastLayoutTemplate() {
> + return lastLayoutTemplate;
> + }
> +
> + /**
> + * Gets the Last Screen Template
> + *
> + * @return the last screen template
> + */
> + public String getLastScreenTemplate() {
> + return lastScreenTemplate;
> + }
> }
>
> *** TemplateScreen.java Fri Apr 13 17:17:54 2001
> ---
> /home/paragon/platform/src/turbine-deploy/src/java/org/apache/turbine/mo
> dules/screens/TemplateScreen.java Mon Apr 16 16:44:52 2001
> ***************
> *** 67,72 ****
> --- 67,73 ----
> import org.apache.turbine.util.*;
> import org.apache.turbine.services.*;
> import org.apache.turbine.services.template.*;
> + import org.apache.turbine.services.resources.TurbineResources;
>
> /**
> * Template Screen.
> ***************
> *** 114,121 ****
> */
> protected void doPostBuildTemplate( RunData data )
> {
> ! // empty
> }
>
> /**
> * This method is called by the Screenloader to construct the
> --- 115,157 ----
> */
> protected void doPostBuildTemplate( RunData data )
> {
> ! // Set the values of the last templates used
> ! setLastTemplates(data);
> }
> +
> + /**
> + * This method is used to set lastScreen and lastLayout in
> + * the RunData object. It uses a users session's data to
> + * temporarily store current template values.
> + * This method can be overridden (??)
> + * @param data Turbine information
> + * @return void
> + */
> + protected void setLastTemplates(RunData data) {
> +
> + // Set default Screen
> + String defaultScreen =
> + TurbineResources.getString("template.homepage");
> +
> + // Set default Layout
> + String defaultLayout =
> +
> TurbineResources.getString("services.TurbineTemplateService.default.layo
> ut.template");
> +
> + // Add values to RunData object
> + data.setLastScreenTemplate((String)
> + data.getUser().getTemp("last_screen",
> +
> defaultScreen));
> + data.setLastLayoutTemplate((String)
> + data.getUser().getTemp("last_layout",
> +
> defaultLayout));
> +
> + // Store current template values in User's Session
> + String last_screen = data.getScreenTemplate();
> + data.getUser().setTemp("last_screen", last_screen);
> +
> + String last_layout = data.getLayoutTemplate();
> + data.getUser().setTemp("last_layout", last_layout);
> + }
>
> /**
> * This method is called by the Screenloader to construct the
>
> ---------------------------------------------------------------------
> 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
Re: Quick Question
Posted by Michael Stanley <mp...@syr.edu>.
Here are a couple of patches that I wrote that add methods to the RunData
object to retrieve Last Screen etc. They use user temp info to
temporarily keep track of screen templates and layout templates.
Here they are:
*** RunData.java Fri Apr 13 17:17:50 2001
---
/home/paragon/platform/src/turbine-deploy/src/java/org/apache/turbine/ut
il/RunData.java Mon Apr 16 15:36:54 2001
***************
*** 617,620 ****
--- 617,649 ----
* @return a hashtable for debug variables.
*/
public Hashtable getVarDebug();
+
+ /**
+ * Sets the Last Screen Template
+ *
+ * @param last_screen the last screen template
+ */
+ public void setLastScreenTemplate(String last_screen);
+
+ /**
+ * Gets the Last Screen Template
+ *
+ * @return the last screen template
+ */
+ public String getLastScreenTemplate();
+
+ /**
+ * Sets the Last Layout Template
+ *
+ * @param last_layout the last layout template
+ */
+ public void setLastLayoutTemplate(String last_layout);
+
+ /**
+ * Gets the Last Layout Template
+ *
+ * @return the last layout template
+ */
+ public String getLastLayoutTemplate();
+
}
*** DefaultTurbineRunData.java Fri Apr 13 17:17:51 2001
---
/home/paragon/platform/src/turbine-deploy/src/java/org/apache/turbine/se
rvices/rundata/DefaultTurbineRunData.java Mon Apr 16 16:39:10 2001
***************
*** 287,292 ****
--- 287,302 ----
private Hashtable varDebug = new Hashtable();
/**
+ * A holder for last screen template.
+ */
+ private String lastScreenTemplate = null;
+
+ /**
+ * A holder for last layout template.
+ */
+ private String lastLayoutTemplate = null;
+
+ /**
* Attempts to get the User object from the session. If it does
* not exist, it returns null.
*
***************
*** 1377,1380 ****
--- 1387,1426 ----
{
getServerData().setScriptName(sn);
}
+
+ /**
+ * Sets the Last Layout Template
+ *
+ * @param last_layout the last layout template
+ */
+ public void setLastLayoutTemplate(String last_layout){
+ lastLayoutTemplate = last_layout;
+ }
+
+ /**
+ * Sets the Last Screen Template
+ *
+ * @param last_screen the last screen template
+ */
+ public void setLastScreenTemplate(String last_screen) {
+ lastScreenTemplate = last_screen;
+ }
+
+ /**
+ * Gets the Last Layout Template
+ *
+ * @return the last layout template
+ */
+ public String getLastLayoutTemplate() {
+ return lastLayoutTemplate;
+ }
+
+ /**
+ * Gets the Last Screen Template
+ *
+ * @return the last screen template
+ */
+ public String getLastScreenTemplate() {
+ return lastScreenTemplate;
+ }
}
*** TemplateScreen.java Fri Apr 13 17:17:54 2001
---
/home/paragon/platform/src/turbine-deploy/src/java/org/apache/turbine/mo
dules/screens/TemplateScreen.java Mon Apr 16 16:44:52 2001
***************
*** 67,72 ****
--- 67,73 ----
import org.apache.turbine.util.*;
import org.apache.turbine.services.*;
import org.apache.turbine.services.template.*;
+ import org.apache.turbine.services.resources.TurbineResources;
/**
* Template Screen.
***************
*** 114,121 ****
*/
protected void doPostBuildTemplate( RunData data )
{
! // empty
}
/**
* This method is called by the Screenloader to construct the
--- 115,157 ----
*/
protected void doPostBuildTemplate( RunData data )
{
! // Set the values of the last templates used
! setLastTemplates(data);
}
+
+ /**
+ * This method is used to set lastScreen and lastLayout in
+ * the RunData object. It uses a users session's data to
+ * temporarily store current template values.
+ * This method can be overridden (??)
+ * @param data Turbine information
+ * @return void
+ */
+ protected void setLastTemplates(RunData data) {
+
+ // Set default Screen
+ String defaultScreen =
+ TurbineResources.getString("template.homepage");
+
+ // Set default Layout
+ String defaultLayout =
+
TurbineResources.getString("services.TurbineTemplateService.default.layo
ut.template");
+
+ // Add values to RunData object
+ data.setLastScreenTemplate((String)
+ data.getUser().getTemp("last_screen",
+
defaultScreen));
+ data.setLastLayoutTemplate((String)
+ data.getUser().getTemp("last_layout",
+
defaultLayout));
+
+ // Store current template values in User's Session
+ String last_screen = data.getScreenTemplate();
+ data.getUser().setTemp("last_screen", last_screen);
+
+ String last_layout = data.getLayoutTemplate();
+ data.getUser().setTemp("last_layout", last_layout);
+ }
/**
* This method is called by the Screenloader to construct the
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
Re: Quick Question
Posted by Jason van Zyl <jv...@apache.org>.
Michael Stanley wrote:
>
> > >> You can store information like this in the session with
> > >> data.getUser().setTemp("last_template", template)
> > >
> > > Well I though about that too. This solution doesn't work however unless
> > > a user is logged in.
>
> > Yes it does. Anonymous users can be tracked via session id.
>
> I still think it be beneficial to have methods
>
> data.getLastScreen()
> data.getLastLayout()
>
All you need is the screen or the template, the layout is
determined by the screen, and if you set the screen or template
the accompanying layout will also be set. You don't have to
set both any longer.
> available.
>
> Mike
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-user-help@jakarta.apache.org
--
jvz.
Jason van Zyl
jvanzyl@apache.org
http://jakarta.apache.org/velocity
http://jakarta.apache.org/turbine
http://tambora.zenplex.org
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
Re: Quick Question
Posted by Michael Stanley <mp...@syr.edu>.
> >> You can store information like this in the session with
> >> data.getUser().setTemp("last_template", template)
> >
> > Well I though about that too. This solution doesn't work however unless
> > a user is logged in.
> Yes it does. Anonymous users can be tracked via session id.
I still think it be beneficial to have methods
data.getLastScreen()
data.getLastLayout()
available.
Mike
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
Re: Quick Question
Posted by Jon Stevens <jo...@latchkey.com>.
on 4/16/01 9:19 AM, "Michael Stanley" <mp...@syr.edu> wrote:
>> You can store information like this in the session with
>> data.getUser().setTemp("last_template", template)
>
> Well I though about that too. This solution doesn't work however unless
> a user is logged in.
Yes it does. Anonymous users can be tracked via session id.
-jon
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
Re: Quick Question
Posted by Michael Stanley <mp...@syr.edu>.
> You can store information like this in the session with
> data.getUser().setTemp("last_template", template)
Well I though about that too. This solution doesn't work however unless
a user is logged in. I would think it be better to store the information
in the Session. After further inspection I think it be good to add code
that stores Screen and Layout in the Session within the TemplateScreen
doBuild (or doPostBuild - however I don't know if it be a good idea to
store screens that caused errors). Then add functions to RunData
getLastScreen and setLastScreen (same for layout). The setLastScreen can
be initialized from the Session data previous to changing it.
I'm going to patch this and send it to you later in the day.
> But it might be nice to come up with some standard tags for this,
> I'm not sure if intake deals with error processing. John, does it?
I'm not sure what intake does. Can you give me a brief overview and
perhaps and example?
> >
> > Mike
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: turbine-user-help@jakarta.apache.org
> --
> jvz.
> Jason van Zyl
> jvanzyl@apache.org
> http://jakarta.apache.org/velocity
> http://jakarta.apache.org/turbine
> http://tambora.zenplex.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
Re: Quick Question
Posted by Jason van Zyl <jv...@apache.org>.
Michael Stanley wrote:
>
> > You could use ..
>
> > data.getScreen()
>
> > but this gives you the intened screen to execute...
>
> > but instead of using the screen to be executed as the default
> > _success_ screen use it as the _retry_ screen.
>
> > Then on success, you could set the _success_ screen.
>
> This isn't a good solution because I'm calling my action from a
> navigation and the success and retry screen should be the user's most
> recent screen.
>
> > There's a few possibilities, but as far as I know there is
> > no method like that. You might possibly fond the solution by
> > looking at the api.
> > Examine the Actions, they might have something like that...
>
> I've combed through the API and the code and I don't think there is a
> method like that. I think I might patch it in though. It seems like it
> be very useful.
>
> I would think that RunData should have a method like getLastScreen() or
> something. Any thoughts pre-patch ?
You can store information like this in the session with
data.getUser().setTemp("last_template", template)
But it might be nice to come up with some standard tags for this,
I'm not sure if intake deals with error processing. John, does it?
>
> Mike
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-user-help@jakarta.apache.org
--
jvz.
Jason van Zyl
jvanzyl@apache.org
http://jakarta.apache.org/velocity
http://jakarta.apache.org/turbine
http://tambora.zenplex.org
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
Re: Quick Question
Posted by Michael Stanley <mp...@syr.edu>.
> WOAH! What? You are totally not using Turbine's module order correctly.
> Please go back and read this:
> <http://jakarta.apache.org/turbine/fsd.html>
> -jon
I'm sorry I must of said something confusing. I understand thow
Turbine's module order works. My point was that I have a link that
executes an action. This link is located in one of the Navigation
screens. In the action, on a certain scenario, I would like to retrieve
the most recent screen. Therefor I don't want to hardcode the redirect
but rather grab the most recent screen from some method.
Mike
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
Re: Quick Question
Posted by Jon Stevens <jo...@latchkey.com>.
on 4/16/01 8:48 AM, "Michael Stanley" <mp...@syr.edu> wrote:
> This isn't a good solution because I'm calling my action from a
> navigation and the success and retry screen should be the user's most
> recent screen.
WOAH! What? You are totally not using Turbine's module order correctly.
Please go back and read this:
<http://jakarta.apache.org/turbine/fsd.html>
-jon
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
Re: Quick Question
Posted by Michael Stanley <mp...@syr.edu>.
> You could use ..
> data.getScreen()
> but this gives you the intened screen to execute...
> but instead of using the screen to be executed as the default
> _success_ screen use it as the _retry_ screen.
> Then on success, you could set the _success_ screen.
This isn't a good solution because I'm calling my action from a
navigation and the success and retry screen should be the user's most
recent screen.
> There's a few possibilities, but as far as I know there is
> no method like that. You might possibly fond the solution by
> looking at the api.
> Examine the Actions, they might have something like that...
I've combed through the API and the code and I don't think there is a
method like that. I think I might patch it in though. It seems like it
be very useful.
I would think that RunData should have a method like getLastScreen() or
something. Any thoughts pre-patch ?
Mike
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
Re: Quick Question
Posted by "Albrecht F.Leiprecht" <al...@mail.ccc-casino.com>.
You could use ..
data.getScreen()
but this gives you the intened screen to execute...
but instead of using the screen to be executed as the default
_success_ screen use it as the _retry_ screen.
Then on success, you could set the _success_ screen.
There's a few possibilities, but as far as I know there is
no method like that. You might possibly fond the solution by
looking at the api.
Examine the Actions, they might have something like that...
so long
albi
----- Original Message -----
From: Michael Stanley <mp...@syr.edu>
To: <tu...@jakarta.apache.org>
Sent: Monday, April 16, 2001 10:44 AM
Subject: Quick Question
> In an Action is it possible to retrieve the most recent Screen? Layout?
>
> Mike
>
> ---------------------------------------------------------------------
> 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