I can't promise when, but whenever I find myself working on it again, I'll try to remember to contact you guys, or at least I'll repost. Right now I'm working on Swing stuff, but I'll be doing another web app soon, and maybe I can try something better then.

Erik


Freddy Villalba A. wrote:

Ok guys,

Don't want to be the party-booer, but since we have kind of agreed to some
point, shouldn't it be better to move this discussion off this usergroup?

Whoever takes the initiative, please send me the new location.

Cheers all,
Freddy.

-----Mensaje original-----
De: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
Enviado el: jueves, 07 de octubre de 2004 16:51
Para: [EMAIL PROTECTED]
Asunto: RE: cleaning session


Don't put this example under Apache License then. ;-) Or have it patented (with the new patent laws in Europe no problem).

Hiran (getting offtopic)

-----------------------------------------
Hiran Chaudhuri
SAG Systemhaus GmbH
Elsenheimer Straße 11
80867 München
Phone +49-89-54 74 21 34
Fax   +49-89-54 74 21 99






-----Original Message-----
From: Erik Weber [mailto:[EMAIL PROTECTED]
Sent: Donnerstag, 7. Oktober 2004 15:33
To: Struts Users Mailing List
Subject: Re: cleaning session

Yes, that is a good example.

My only requirement here is that no one from STANDARDS BANK
may ever make use of it.

:)

Erik



Freddy Villalba A. wrote:



There is another typical example:

You have a search screen. after performing a search, you


select one of


the items in order to... say... edit it. You go to the


edition screen


(form) and, once you've concluded working with that item (typically:
saved, deleted or canceled), you return to the search screen, where
you'd see the (refreshed version of the) last search


results' table (to


keep it simple, don't even assume there is pagination).



-----Mensaje original-----
De: Erik Weber [mailto:[EMAIL PROTECTED] Enviado el:


jueves, 07


de octubre de 2004 15:31
Para: Struts Users Mailing List
Asunto: Re: cleaning session


I think a good place to start would be to start a list of


situations or


use cases encountered where this type of device was implemented or
needed (not just with "wizards", but with session attributes


in general


I think). Then we could look at the list after a while and


see what all


or many of the entries have in common -- try to recognize a pattern.
Then maybe we could try to create a class that solves the common
problem
-- one that could be inserted into a filter, a request processor, or
whatever, making it generically applicable (Struts or not).


I would be


willing to contribute if it caught on, because I certainly have
encountered a need for this more than once.

For example, I recently I finished a Struts application that had an
area (a set of pages/commands) for "vendors". One of the things a
vendor could do was search for an item, and then upload files to
"attach" to that item (such as photographs). So the


ActionForm used for


the file upload screen not only kept track of the normal properties
associated with file uploading, but also the item. The item,


in turn,


housed a collection of attributes describing every file currently
attached to that item. So when you viewed the upload screen,


you could


see all the existing uploads, and the details about the item


you were working with.


Even though it wasn't a proper "wizard", I decided to keep


the form in


session scope, because users could make mistakes (such as invalid
input) and continually end up back at the screen. I didn't


want to keep


reloading the item and all the existing file info every time


the page


was needed. So I ended up writing a "cleanup" method in a


base Action


class that got rid of the form when it figured that the vendor was
probably finished using the file upload area (such as when


he returned


"home").

Probably you guys have far better examples, but that's just


one off the


top of my head.

And XML is almost always good.

Erik



Freddy Villalba A. wrote:





Well guys, although on the same direction you are pointing to, I do
believe though that the more framework-independent the solution is,
the better. So, my thought:

Why not have a XML descriptor where you can explicitly


define your wizards?


In that way:
(1) No matter where your resources are, they'll get cleansed.
(2) You'll be able to reuse resources at free will on


several wizards


(without having to replicate them).
(3) You won't have to set up any structure or hardcode anything in
order to determine what's to be cleansed an what not.

What do you think?

-----Mensaje original-----
De: Erik Weber [mailto:[EMAIL PROTECTED] Enviado


el: jueves,


07 de octubre de 2004 13:26
Para: Struts Users Mailing List
Asunto: Re: cleaning session


Yeah, "similar naming convention" is the key to making it easier on yourself.

Also, as I tried to suggest once before (in a riddle -- "a


single key


can open many doors" -- ha ha ha grasshoppah), you can store
references to many objects under a single attribute key (using
structured/nested beans, maps, etc.). Delete the single attribute
(perhaps when a user returns to a main view) and you delete


the entire


tree of references, freeing up all that memory with one


statement and


without having to write too much conditional code. I'm not sure if
this strategy is feasible with Struts session-scoped forms though.

Erik


[EMAIL PROTECTED] wrote:







Hi, Erik and Freddz.

I like the idea of having a wizard whose data gets cleaned


as soon as


it's






scope is left.






How about this: Have all resources for one wizard in a URL


subdirectory.






Have a similar naming convention for the resources the


wizard leaves


in the session. If a http request comes for an url, the


janitor filter


could




remove




all wizard's session resources that do not match the


current request's


directory.






This way the janitor could be fairly generic.

Hiran

-----------------------------------------
Hiran Chaudhuri
SAG Systemhaus GmbH
Elsenheimer Straße 11
80867 München
Phone +49-89-54 74 21 34
Fax   +49-89-54 74 21 99












-----Original Message-----
From: Erik Weber [mailto:[EMAIL PROTECTED]
Sent: Donnerstag, 7. Oktober 2004 11:55
To: Struts Users Mailing List
Subject: Re: cleaning session

This is similar to what I usually implement. I have been


gradually


developing a "session manager" or perhaps a "session


janitor" that


watches/tracks workflow and cleans up stuff from memory (session)
that isn't needed anymore. It could be a filter or a


custom request


processor in the world of Struts. Since I most often use my own
controller Servlet I have my own place to put it, but


basically, it


gets invoked before any request handlers.

Erik


Freddy Villalba A. wrote:









Hi,

I have never implemented anything like this (with Struts),








but this is








the first thing I can think of...

Assuming your wizard is one-way (by this, I mean you


have a linear


graph - 1<->2<->3... -, no bifurcations and /or








intersections and / or








parallelism), you could "define" your "workflow" by








"tagging" the pages it is made of...








then, manage the wizard from a filter that is able to


detect your


getting into one and your leaving it. Once it detects








someone's left a








wizard, and knowing its components, it could have them








cleaned off the








corresponding Session.

I believe, however, that this approach wouldn't work if


the graph


is not linear.

I'll be glad to here your feedback (everybody).

HTH,
Freddy.

-----Mensaje original-----
De: Paul McCulloch [mailto:[EMAIL PROTECTED]
Enviado el: jueves, 07 de octubre de 2004 10:27
Para: 'Struts Users Mailing List'
Asunto: RE: cleaning session


That isn't the purpose of the (confusingly named) reset








method. Reset








is there to, typically, deal with the html forms submit








checkbox fields








(they don't submit anything if they are null).

Paul











-----Original Message-----
From: Leandro Melo [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 06, 2004 5:43 PM
To: Struts Users Mailing List
Subject: Re: cleaning session


If you have your action in HttpSession, why don`t you just








call reset








whenever a user clicks on the button supposed to start


this wizard?



--- struts lover <[EMAIL PROTECTED]> escreveu:










Hello everyone,
I am facing this problem of session. I have my action form in
session(a wizard like thing). Now if the user starts


filling in


values and clicks on the NEXT button, to go on to the next
screen and then instead of completing the process of


application,








clicks on








some other link.
Again he wants to start with the application process, the form
get pre-populated with the previous values, as the


form in still


in session. I want a clean form.
How to overcome this problem???
Any ideas???
Thanks.



_______________________________
Do you Yahoo!?
Declare Yourself - Register online to vote today!
http://vote.yahoo.com












------------------------------------------------------------








---------












To unsubscribe, e-mail:
[EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]












__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

------------------------------------------------------------








---------








To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]











*************************************************************








*********








Axios Email Confidentiality Footer
Privileged/Confidential Information may be contained in this








message.








If you are not the addressee indicated in this message (or








responsible








for delivery of the message to such person), you may not copy or
deliver this message to anyone. In such case, you should








destroy this








message, and notify us immediately. If you or your employer does
not consent to Internet email messages of this kind,


please advise


us immediately. Opinions, conclusions and other information








expressed in








this message are not given or endorsed by my Company or








employer unless








otherwise indicated by an authorised representative








independent of this message.








WARNING:
While Axios Systems Ltd takes steps to prevent computer viruses


from being transmitted via electronic mail attachments we cannot








guarantee








that attachments do not contain computer virus code.  You








are therefore








strongly advised to undertake anti virus checks prior to








accessing the








attachment to this electronic mail.  Axios Systems Ltd grants no
warranties regarding performance use or quality of any








attachment and








undertakes no liability for loss or damage howsoever caused.
*************************************************************








*********








---------------------------------------------------------


----------


-- To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


---------------------------------------------------------


----------


-- To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]












----------------------------------------------------------


----------


- To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]










-----------------------------------------------------------


----------


To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]










------------------------------------------------------------


---------


To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


------------------------------------------------------------


---------


To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]








---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]






---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]


--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]





--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to