Kevin Clark wrote:
>
> 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.
The RunData object is meant to provide convenient access to data
relevant to the current request. You should add data to the session.
Preferrably through the User object, but possibly directly in the
session. Both these objects are available from RunData, so maybe I am
being too nitpicky, but I do not think it is good to think of the
RunData as storing information across separate requests.
> 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.
>
The page module is a good candidate to place code should be executed for
every request. Or something that might be of value would be to add a
call from the page to a default action, if defined. Then the code would
go into an action.
> 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
> >
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/turbine%40list.working-dogs.com/>
Problems?: [EMAIL PROTECTED]
