I didn't do a very good job of making myself clear. Let me clarify:
1) I stated that "I" am interested in keeping track of how the users
navigate the site, when actually, my application is. The application is
dynamically building relationships between information that my users move
(navigate) to/from. This will affect how the content is displayed in the
future. Rather than digging this info from a log file, I would prefer to put
this code somewhere between Screen and subclasses of VelocityScreen in the
inheritance hierarchy.
2) I also asked--where would be the "appropriate place" to put this
information into the RunData object. I actually meant to ask where would be
the correct place to add this *method* that would add the parameters to the
RunData object. After thinking about this, I've thought of one solution, but
I'm not an extremely experienced java programmer and I'd love feedback. I
plan to:
1) Subclass VelocityScreen with MyVelocityScreen
2) Add the code to store this request's paramters in the RunData object (so
it will be available to the next request) and the code that will build the
relationships I mentioned above, to MyVelocityScreen's doBuildTemplate()
method.
3) Build an abstract method MyVelocityScreen.myDoBuildTemplate() and call it
at the end of MyVelocityScreen.doBuildTemplate()
4) Write the "screen" classes to extend MyVelocityScreen and overide the
MyVelocityScreen.myDoBuildTemplate() method.
Is this complete ugly and pointless? am I missing something? or would this
be an appropriate way to accomplish my goal?
-Kevin
>Kevin Clark wrote:
> >
> > For a number of reasons, I would like to have the previous request's
> > parameters available to the next request. For example, in the action
> > attribute of <form> parameters (in my velocity templates), I specify the
> > page that I want people to see upon completing the form correctly. In
>the
> > action that processes the data in the form, I validate the data and
>return
> > the user to the form with FormMessages if there were problems.
>Currently, I
> > hard code the template name that I want to return the user to if there
>are
> > problems in the action (this means that my action can only process data
>from
> > a particular template).
>
>You can specify the template to return to as a hidden field in the form
>itself, there is no reason to modify anything to achieve this.
>
> > I would also like to implement this because I am interested in
> > how users navigate the site, and plan to keep track of this by the
>sequence
> > of URLs they follow.
>
>Turn on logging in Apache or whatever server you are using. ???
>
> > So my question is, in Turbine, where would be the appropriate place to
>add
> > this extra data to the RunData?
>
>The appropriate place to place it would be the session as the data is
>supposed to persist across requests. The user object which is loaded
>into RunData at each request, data.getUser().getTemp(xxx) is a useful
>abstraction for storing and retrieving items from the session using
>get/setPerm methods will save the information in the database for
>storage across sessions as well (as long as you make sure the objects
>are serializable.)
>
>An example that saves the current state information to return to the
>present screen in the event that a user clicked the back button in a
>protected form is available by looking at the sessionvalidators and
>InvalidState screens.
>
>It could be of some value to support a history so that <back> form
>buttons could be made to work more easily. You will have to be clear
>about how session data must be stored, for example in Users temp/perm
>hashtables, so that it can be kept in the proper state as well.
>
>John McNally
>
> > _________________________________________________________________
> > Get your FREE download of MSN Explorer at http://explorer.msn.com
> >
> > ------------------------------------------------------------
> > To subscribe: [EMAIL PROTECTED]
> > To unsubscribe: [EMAIL PROTECTED]
> > Search: <http://www.mail-archive.com/turbine%40list.working-dogs.com/>
> > Problems?: [EMAIL PROTECTED]
>
>
>------------------------------------------------------------
>To subscribe: [EMAIL PROTECTED]
>To unsubscribe: [EMAIL PROTECTED]
>Search: <http://www.mail-archive.com/turbine%40list.working-dogs.com/>
>Problems?: [EMAIL PROTECTED]
>
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/turbine%40list.working-dogs.com/>
Problems?: [EMAIL PROTECTED]
