You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Werner Punz <we...@gmx.at> on 2005/07/28 00:18:55 UTC
bean traversal question
Hi I am banging sort of my head here....
I am sort of new to struts (due to project requirements), in every
webapp you often have the problem of having to pass complex objects over
a handful of forms.
In JSP you only have the option of pushing the object into the session
and fill the data by hand which has changed.
or that you traverse all the data over all forms via hidden fields.
In JSF you have the option in some frameworks to have special constructs
which serialize and restore the objects while filling in the form data
coming from the request.
(x:saveState from myfaces comes to mind)
this saves a lot of time because you only have to reference the
component data which actually is used in the form.
I was wondering if there is such a shortcut way in plain struts as well.
If anybody could hint me towards such a solution, I would be grateful.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: bean traversal question
Posted by Werner Punz <we...@gmx.at>.
Michael Jouravlev wrote:
>
> There are no standard ways to do this. Creating wizards myself, I was
> thinking about some kind of garbage collector for session object. This
> project: http://wfnm.sourceforge.net/ seems to have this feature. It
> has some other features so I don't know can you pull out the session
> garbage collection feature only or not. I guess not, because it
> detects garbage in relation to the flow. Thus seems that you have to
> define the flow, which is unfortunate. Anyway, I did not really use
> this project, so you may try and report results ;-)
>
just checked it out, looks exactly like what I need...
I will give it a try, once I reach the point where I need it
(which will come in a few days)
thanks for pointing me towards it.
Werner
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: bean traversal question
Posted by Werner Punz <we...@gmx.at>.
Rick Reumann wrote:
> Michael Jouravlev wrote the following on 7/28/2005 4:30 PM:
>
>> Ahem, actually I am all in for sessions. I just don't see why it
>> storing stuff in an action form with session scope is universally
>> frowned upon, while sticking same stuff directly into session is OK
>> ;-)
>
>
> Most seem to frown on both scenarios. Personally, I like the Session:)
> The concept of the "session cleanup" tool has been talked about so many
> times on this list, but I've yet to see an easy implementation of it.
> For me, I'd rather use the Session until some manager starts complaining
> that the app has performance issues (and even then I'd probably add more
> RAM vs throw away my reliance on the Session:)
>
Well speaking of MyFaces/JSF again, I did something like x:saveState on
the session side.
x:saveState itself is very easy to use x:saveState name="#{dataobject}"
in a form means that the object is serialized
if you run into the x:saveState name="#{dataObject}" in the next form
the object is basically recycled before the incoming values are applied
and so on, the first time you hit a page without x:saveState
name="#{dataobject}" the object is garbage collected.
http://wiki.apache.org/myfaces/SaveState
It does not get easier. All the implementations of dialog systems with
their dedicated dialog configs in the configuration files are way more
complex than that and do not achieve significantly more, expect pushing
the system into the config files (which in many cases is not needed,
especially not for wizards).
Having such a mechanism in struts would ease things tremendously.
> For a wizard like Werner initially described, I'd use a Session based
> form in a heart-beat. I use session scoped forms and they work wonderfully.
>
I am not against sessions otherwise I would not have implemented an
x:saveState on a session base once, in fact I prefer sessions to plain
serialisation for many reasons, (for those who are familiar with jsf,
the code is on jsf-comp on sourceforge), the problems with sessions is
just, that you have to garbage collect the objects from the session
manually, and that is rather error prone, especially once you hit
unexpected conditions.
With a handful of users, stuffing everthing into sessions works
wonderfully but with a few hundred or thousand, it does not anymore,
that is unfortunately the main problem, so you dump the data out of the
session regularily.
But for my current project I probably will use a dialog system and check
how it works out (Spring Dialog probably would be the perfect choice,
since I use Spring anyway, for the business and data layer)
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: bean traversal question
Posted by Rick Reumann <st...@reumann.net>.
Michael Jouravlev wrote the following on 7/28/2005 4:30 PM:
> Ahem, actually I am all in for sessions. I just don't see why it
> storing stuff in an action form with session scope is universally
> frowned upon, while sticking same stuff directly into session is OK
> ;-)
Most seem to frown on both scenarios. Personally, I like the Session:)
The concept of the "session cleanup" tool has been talked about so many
times on this list, but I've yet to see an easy implementation of it.
For me, I'd rather use the Session until some manager starts complaining
that the app has performance issues (and even then I'd probably add more
RAM vs throw away my reliance on the Session:)
For a wizard like Werner initially described, I'd use a Session based
form in a heart-beat. I use session scoped forms and they work wonderfully.
--
Rick
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: bean traversal question
Posted by Michael Jouravlev <jm...@gmail.com>.
On 7/28/05, Werner Punz <we...@gmx.at> wrote:
> Michael Jouravlev wrote:
>
> > On a side note, I cannot get why storing data in an action form is
> > considered wrong, while directly accessing session is OK. I think
>
> Well it is quite the opposite in JSF... using the session is
> sort of a secure source of getting heavy beating (which is half right
> but too extreme), while the so called backend beans are combined
> controller/nmodel objects which basically are kept over all phases
> of the rendering cycle.
>
> The no use of session if possible results in such things like
> x:saveState which serializes everything to pass data over the
> cycle boundaries without having to pass parameters.
Ahem, actually I am all in for sessions. I just don't see why it
storing stuff in an action form with session scope is universally
frowned upon, while sticking same stuff directly into session is OK
;-)
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: bean traversal question
Posted by Werner Punz <we...@gmx.at>.
Michael Jouravlev wrote:
> On a side note, I cannot get why storing data in an action form is
> considered wrong, while directly accessing session is OK. I think
Well it is quite the opposite in JSF... using the session is
sort of a secure source of getting heavy beating (which is half right
but too extreme), while the so called backend beans are combined
controller/nmodel objects which basically are kept over all phases
of the rendering cycle.
The no use of session if possible results in such things like
x:saveState which serializes everything to pass data over the
cycle boundaries without having to pass parameters.
An interesting approach if you ask me, but puts too much emphasis on the
serialisation mechanism, a mixed form would be better, where you can
chose one way or the other.
> quite opposite. I prefer to stick data related to an action, into
> action form. It is more controlled, more visible, and then I can
> simply remove one action form object from the session to clear the
> whole tree.
>
Well a combind form, controller approach is closer to classical UIs than
the way struts does it. Although I can see the logic behind the approach
of struts in a http context, it is sort of confusing.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: bean traversal question
Posted by Michael Jouravlev <jm...@gmail.com>.
On 7/28/05, Werner Punz <we...@gmx.at> wrote:
> Actually I was thinking also along the lines of having some kind of
> garbage collecting mechanism.
> I did something like that in JSF very easy (reprogrammed parts of the
> x:saveState)
> the trick was to push the object into the session with some kind of key
> which stores the current and the old session and at the end of each
> rendering cycle (which is the problem because struts behaves totally
> different)
>
>
> I basically dumped the objects from the old url and pushed the newly
> registrated ones into the central object storage.
>
> That trick worked very well, because you have clear distinctive phases
> in JSF which mark the before assigning the data part and the after
> rendering part of the request and you already have a save and restore
> mechanism on component level which utilizes those two phases.
You can do the same in Struts. Well, in Struts Dialogs ;-) which like
JSF also has distinctive phases and stores state on server. Actually,
I am going to implement this feature.
The idea is that an action is a web resource. An action can have
multiple states and can reder different pages. The fact that action
mapping can have only one corresponding action form, works pretty
well. I stick all data that I use in a resource, into action form and
set form scope to "session". Then I can have a wizard (controlled by a
single action), or a login/logout component. Once I leave that action,
I can simply remove the action form from the session.
I will have to define subsession groups, and each action mapping would
be able to participate in one or more subsessions. Once I leave a
subsession, I can remove an action form with all its corresponding
data.
On a side note, I cannot get why storing data in an action form is
considered wrong, while directly accessing session is OK. I think
quite opposite. I prefer to stick data related to an action, into
action form. It is more controlled, more visible, and then I can
simply remove one action form object from the session to clear the
whole tree.
Michael.
--
Struts Dialogs
http://struts.sourceforge.net/strutsdialogs
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
[OT] Re: bean traversal question
Posted by Dave Newton <ne...@pingsite.com>.
Werner Punz wrote:
> I tried to move over a similar mechanism in Struts, but basically
> failed due to time constraints, which I cannot resolve by technical
> means ;-)
If you were Really Good you could. Probably not a pure software
solution, though, especially if any space-time distortion is involved.
Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: bean traversal question
Posted by Werner Punz <we...@gmx.at>.
Michael Jouravlev wrote:
> On 7/28/05, Werner Punz <we...@gmx.at> wrote:
>
>>I after Wendy gave me the advice to rephrase the question I will try to
>>rephrase it.
>>
>>Being new to struts, I want to know how people deal with data objects
>>which need a scope bigger than request but smaller than session.
>
>
> There are no standard ways to do this. Creating wizards myself, I was
> thinking about some kind of garbage collector for session object. This
> project: http://wfnm.sourceforge.net/ seems to have this feature. It
> has some other features so I don't know can you pull out the session
> garbage collection feature only or not. I guess not, because it
> detects garbage in relation to the flow. Thus seems that you have to
> define the flow, which is unfortunate. Anyway, I did not really use
> this project, so you may try and report results ;-)
>
Actually I was thinking also along the lines of having some kind of
garbage collecting mechanism.
I did something like that in JSF very easy (reprogrammed parts of the
x:saveState)
the trick was to push the object into the session with some kind of key
which stores the current and the old session and at the end of each
rendering cycle (which is the problem because struts behaves totally
different)
I basically dumped the objects from the old url and pushed the newly
registrated ones into the central object storage.
That trick worked very well, because you have clear distinctive phases
in JSF which mark the before assigning the data part and the after
rendering part of the request and you already have a save and restore
mechanism on component level which utilizes those two phases.
I tried to move over a similar mechanism in Struts, but basically failed
due to time constraints, which I cannot resolve by technical means ;-)
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: bean traversal question
Posted by Michael Jouravlev <jm...@gmail.com>.
On 7/28/05, Werner Punz <we...@gmx.at> wrote:
> I after Wendy gave me the advice to rephrase the question I will try to
> rephrase it.
>
> Being new to struts, I want to know how people deal with data objects
> which need a scope bigger than request but smaller than session.
There are no standard ways to do this. Creating wizards myself, I was
thinking about some kind of garbage collector for session object. This
project: http://wfnm.sourceforge.net/ seems to have this feature. It
has some other features so I don't know can you pull out the session
garbage collection feature only or not. I guess not, because it
detects garbage in relation to the flow. Thus seems that you have to
define the flow, which is unfortunate. Anyway, I did not really use
this project, so you may try and report results ;-)
Michael.
--
Struts Dialogs
struts.sourceforge.net/strutsdialogs
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: bean traversal question
Posted by Michael Jouravlev <jm...@gmail.com>.
On 7/28/05, Michael Jouravlev <jm...@gmail.com> wrote:
> There should be set of policies. For example, if you navigate to an
> action which is not part of any subsession (or scenario, I like this
> word), do you trash all existing scenarios or you keep them?
If you look at Spring Web Flow, you would see that they allow to
define huge app-sized flows and subflows. This is madness, and I do
not favor this. I think it is much easier not to have a flow at all,
and instead to define single-level peer components (resources,
actions, scenarios, whatever you call them). If you need a wizard,
make it one action.
The idea of subflows is do you allow certain set of actions in certain
state or not. "State" is the keyword. If state is used uniformly in
application, subflows would not be needed, just set or clear the
state. Right... Essentially, flow with sublows is a hierarchical
state. I guess I need to think of something generic app-wide state
management.
Michael.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: bean traversal question
Posted by Michael Jouravlev <jm...@gmail.com>.
On 7/28/05, Rick Reumann <st...@reumann.net> wrote:
> Michael Jouravlev wrote the following on 7/28/2005 6:48 PM:
>
> > Wizard should be handled by *one* action, then cleanup would be
> > simple. Have you found time to look at my stuff? ;-)
>
> Sorry Michael I have not:( Send me the link again.
No rush :) Though you might like it, because it uses session. On the
other hand, you may hate it, because it uses DispatchAction flavor ;)
Project link:
http://struts.sourceforge.net/strutsdialogs
Login/Logout/Signup combo component:
http://www.superinterface.com/wizard/signupWizard.do
Signup Wizard only:
http://www.superinterface.com/strutsdialog/wizardaction.do
All samples:
http://www.superinterface.com/strutsdialog/index.htm
> But, that being said, where clean up becomes a problem is when the user
> goes to some other action? I agree one Action helps but what if they
> click on some other link from your menu that goes to some other Action?
> In other words they don't 'officially' quit the wizard flow. That's when
> it becomes a bit of a pain (assuming you care to clean up:)
No pain. You just have to decide, do you want to allow people to leave
wizard in the middle and then come back, you you do not. If you do,
then you leave it as it is, so when they come back to the same
component, they would see same page and same data. If you don't want
to keep it, then trash the wizard. This should be set per component.
There should be set of policies. For example, if you navigate to an
action which is not part of any subsession (or scenario, I like this
word), do you trash all existing scenarios or you keep them?
The downside of my components, is that there can be only one instance
of every component per session. Wicket guys, for example, use
versions. But their version usage is not very smart, they simply
create new version each time a component is accessed. I need to think
of better way of creating of several versions to be used either on one
page, or in different browser windows. But I am not sure that this is
possible...
Michael.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: bean traversal question
Posted by Shekhar Jain <sh...@gmail.com>.
What we have done is kept all forms in session as "form". That way if
the user jumps to another set of pages and discards halfway tru the
current process the "form" session variable just gets reused and we
don't have to worry too much about cleanup
Shekhar
On 7/28/05, Rick Reumann <st...@reumann.net> wrote:
> Michael Jouravlev wrote the following on 7/28/2005 6:48 PM:
>
> > Wizard should be handled by *one* action, then cleanup would be
> > simple. Have you found time to look at my stuff? ;-)
>
> Sorry Michael I have not:( Send me the link again.
>
> But, that being said, where clean up becomes a problem is when the user
> goes to some other action? I agree one Action helps but what if they
> click on some other link from your menu that goes to some other Action?
> In other words they don't 'officially' quit the wizard flow. That's when
> it becomes a bit of a pain (assuming you care to clean up:)
>
>
> --
> Rick
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: bean traversal question
Posted by Rick Reumann <st...@reumann.net>.
Michael Jouravlev wrote the following on 7/28/2005 6:48 PM:
> Wizard should be handled by *one* action, then cleanup would be
> simple. Have you found time to look at my stuff? ;-)
Sorry Michael I have not:( Send me the link again.
But, that being said, where clean up becomes a problem is when the user
goes to some other action? I agree one Action helps but what if they
click on some other link from your menu that goes to some other Action?
In other words they don't 'officially' quit the wizard flow. That's when
it becomes a bit of a pain (assuming you care to clean up:)
--
Rick
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: bean traversal question
Posted by Michael Jouravlev <jm...@gmail.com>.
On 7/28/05, Rick Reumann <st...@reumann.net> wrote:
> Ed Griebel wrote the following on 7/28/2005 5:11 PM:
> > Rick-
> >
> > I'm faced with this same problem on a new project and have been
> > thinking along these same lines. What kind of issues have you run
> > into?
>
> I really haven't run into many problems when I use a Session based form
> for a wizard approach. Since you can only start the wizard typically at
> a particular entry point, you just make sure the session scoped form is
> a fresh new one at that point. I'm lazy though and don't implement a
> clean-up mechanism.
Wizard should be handled by *one* action, then cleanup would be
simple. Have you found time to look at my stuff? ;-)
Michael.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: bean traversal question
Posted by Rick Reumann <st...@reumann.net>.
Ed Griebel wrote the following on 7/28/2005 5:11 PM:
> Rick-
>
> I'm faced with this same problem on a new project and have been
> thinking along these same lines. What kind of issues have you run
> into?
I really haven't run into many problems when I use a Session based form
for a wizard approach. Since you can only start the wizard typically at
a particular entry point, you just make sure the session scoped form is
a fresh new one at that point. I'm lazy though and don't implement a
clean-up mechanism.
--
Rick
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: bean traversal question
Posted by Michael Jouravlev <jm...@gmail.com>.
On 7/28/05, Ed Griebel <ed...@gmail.com> wrote:
> Rick-
>
> I'm faced with this same problem on a new project and have been
> thinking along these same lines. What kind of issues have you run
> into?
I am interested too ;)
> The kind of things that I see being a problem is specifying
> which sets of actions are associated with what items in a session, and
> which sets of actions are resumable and which ones clear state if one
> navigates away from the path.
I think it should be pretty easy. An action mapping can belong to one
or several subsessions. This can be defined in <action> element of
config file. In my case ;) I have pretty coarse actions, I base them
on DispatchAction (actually SelectAction, but whatever). One action
contains a component, and serves all requests to this component, and
displays all pages of this component. It can be a Login component, or
CRUD component, or a wizard. So, correlating a component to action to
data that is used by it is easy.
In some cases, say in one version of CRUD sample, I may have two
actions which work with the same set of data. In this case both
actions would correspond to one subsession.
Once I load any other action which does not correspond to this
subsession, I can safely remove the CRUD action form with all stuff
sitting in it from the session. One line of code. Ok, two lines ;) On
next request RequestProcessor will call RequestUtils.createActionForm
which will create fresh instance if needed. Voila. Note that this
works even with Back button, because I use "no-store" pages, which are
reloaded on Back. Reload calls actio outside of subsession, and
subsession is removed. This will fail only if a user will go to a
completely different site, so at most application will keep *one*
object hanging in the session. I don't care ;) Note I've purposefully
avoided mentioning the "F" [flow] word.
One of my design ideas (which probably are stolen from someone whom
I've purposefully avoided mentioning too) is that flow is not needed.
Each component like login, or menu or subscriptions or language
selection (these are from MailReader) should be totally independent,
but stateful. Flow only has to be supported for small sections, like a
wizard, which fits fully into one action.
Why application flow should not be needed? Because flow ties your
hands and does not allow to easily develop reusable components. Say,
you have flow: welcome -> choose language -> login -> main menu ->
subscriptions. What if you get to main menu, then go back, log out,
and then navigate to main menu again? Should flow control engine throw
an exception, notifying you that you broke flow? Nah. Instead, main
menu simply checks can it be shown or not (logged in or logged out).
If it can, the it shows itself, if not, it goes to login page.
Generic application flow is a bad thing, small action-scoped wizards rule! ;-))
Michael.
--
Struts dialogs, components, controls, wizards and other good stuff
http://struts.sourceforge.net/strutsdialogs
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: bean traversal question
Posted by Ed Griebel <ed...@gmail.com>.
Rick-
I'm faced with this same problem on a new project and have been
thinking along these same lines. What kind of issues have you run
into? The kind of things that I see being a problem is specifying
which sets of actions are associated with what items in a session, and
which sets of actions are resumable and which ones clear state if one
navigates away from the path. Oh yeah, and the general mechanism used
to store information, is it one big bean or a session, but that's
almost trivial compared to the other things I mentioned.
Note I've purposefully avoided mentioning the "W" [wizard] word :-)
-ed
On 7/28/05, Rick Reumann <st...@reumann.net> wrote:
> Werner Punz wrote the following on 7/28/2005 11:46 AM:
> >
> > c) You can try to add the stuff manually to the session and remove it
> > later, which also is problematic in case of an error because then you
> > have a mem leak caused, by a tangeling object in the session.
>
> Above is talked about a lot on this list, but have yet to see a good
> implementation of it. I think it will be a difficult undertaking and
> could be a pain to configure. The control mechanism will have to figure
> out when and what to clear out of the Session at any given time. Say the
> user clicks on some other link.. that path(I'm assuming) will have to be
> checked to see if it's safe to remove x number of Session based objects.
> I've tossed around with the idea of associating certain 'paths' with a
> Session scoped action form and as each request passes through the main
> filter it would check the path and based on the path and certain objects
> in scope certain ones would be be removed. Seemed like such a pain
> though so I gave up before I even really started on it:)
>
>
> --
> Rick
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: bean traversal question
Posted by Rick Reumann <st...@reumann.net>.
Werner Punz wrote the following on 7/28/2005 11:46 AM:
> There are some ways to handle this
> a) You can dump anything into the session, which means you run into
> memory problems in the long run.
I use this solution and have yet to run into any sort of memory
problems. Resources aren't 'that' expensive. Use the Session unless you
find out you have performance issues.
> b) you can put everything into hidden fields, which means you have
> myriads of hidden fields, which is slow and error prone to implement.
Maintenance nightmare.
>
> c) You can try to add the stuff manually to the session and remove it
> later, which also is problematic in case of an error because then you
> have a mem leak caused, by a tangeling object in the session.
Above is talked about a lot on this list, but have yet to see a good
implementation of it. I think it will be a difficult undertaking and
could be a pain to configure. The control mechanism will have to figure
out when and what to clear out of the Session at any given time. Say the
user clicks on some other link.. that path(I'm assuming) will have to be
checked to see if it's safe to remove x number of Session based objects.
I've tossed around with the idea of associating certain 'paths' with a
Session scoped action form and as each request passes through the main
filter it would check the path and based on the path and certain objects
in scope certain ones would be be removed. Seemed like such a pain
though so I gave up before I even really started on it:)
--
Rick
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: bean traversal question
Posted by Werner Punz <we...@gmx.at>.
I after Wendy gave me the advice to rephrase the question I will try to
rephrase it.
Being new to struts, I want to know how people deal with data objects
which need a scope bigger than request but smaller than session.
I will give an example, you have some kind of wizard interface with
myriads of input fields distributed over multiple forms.
There are some ways to handle this
a) You can dump anything into the session, which means you run into
memory problems in the long run.
b) you can put everything into hidden fields, which means you have
myriads of hidden fields, which is slow and error prone to implement.
c) You can try to add the stuff manually to the session and remove it
later, which also is problematic in case of an error because then you
have a mem leak caused, by a tangeling object in the session.
Other frameworks have interesting approaches to solve this.
MyFaces has x:saveState which basically serializes the data objects away
and loads then once you reach the next page (and before the request
data is assigned)
Rails according to a friend has some kind of data structure which you
can tell to extend to the next request, where you can dump data.
And there is Shale with the dialog system, which allows you to specify
scopes smaller than session but bigger than request.
How is this problem resolved in struts in a proper manner?
Werner
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: htnm:base rewrites anchor tag
Posted by Dave Newton <ne...@pingsite.com>.
Shekhar Jain wrote:
>No I'm just using a plain <a href="#top" ... to go to the top of the page
>
>
I think you need to look at what the html <base...> tag does.
http://www.faqs.org/docs/htmltut/linking/_BASE.html
Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: htnm:base rewrites anchor tag
Posted by Shekhar Jain <sh...@gmail.com>.
No I'm just using a plain <a href="#top" ... to go to the top of the page
Shekhar
On 7/28/05, Dave Newton <ne...@pingsite.com> wrote:
> Shekhar Jain wrote:
>
> >I have a jsp page which in which I am using the <html:base> at the top
> >of the page. However I find that then all the links to anchor tags get
> >rewrriten with the jsp page. Is there any way to prevent this from
> >happening
> >
> >
> Are the links-to-anchor-tags struts tags? If so, perhaps consider using
> straight html tag if you don't need the struts tags' functionality; one
> point of html:base is to allow html:link tags to rewrite appropriately.
>
> (Or don't use html:base?)
>
> Dave
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: htnm:base rewrites anchor tag
Posted by Dave Newton <ne...@pingsite.com>.
Shekhar Jain wrote:
>I have a jsp page which in which I am using the <html:base> at the top
>of the page. However I find that then all the links to anchor tags get
>rewrriten with the jsp page. Is there any way to prevent this from
>happening
>
>
Are the links-to-anchor-tags struts tags? If so, perhaps consider using
straight html tag if you don't need the struts tags' functionality; one
point of html:base is to allow html:link tags to rewrite appropriately.
(Or don't use html:base?)
Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
htnm:base rewrites anchor tag
Posted by Shekhar Jain <sh...@gmail.com>.
I have a jsp page which in which I am using the <html:base> at the top
of the page. However I find that then all the links to anchor tags get
rewrriten with the jsp page. Is there any way to prevent this from
happening
Shekhar Jain
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org