Re: Browser Back Button
And I'll be contrary and toss in a Yes, but ... (apol: Eric Berne) (as usual, corrections to my notes are welcome) Yes, but you have to do it programmatically. I don't think there's anything in j2ee (or any other web app) interfaces or implementations that handles this, as Phil said, so you have to make it happen by using tokens and hand-written code etc etc. Unless you are progamming a bank's online faciliity or a www air traffic controller, try not to go this way (I've done one - it was fairly easy in retrospect but adds a moderately painful comprehensibility and navigation burden to the app, so I'm not advising it as a first choice). Safer to abide by available technologies and their proper application, as Phil was saying. The Back button and serverside webapps *naturally* clash if you provide no specific code to handle it - *you* have to anticipate that and program around that reality, from as early as possible in the dev cycle. Worse is that the implementation of behaviour of Back by different browsers is quite different, some taking the purely snapshot view, others taking the resubmit the url policy ... so there is great variation in outcomes! Unfortunately a lot of developers coming from passive web page development (where Back works perfectly every time) don't realise that there's a problem until they've completed their first decent size active serverside web app and someone (usually the customer) says but it breaks if I click *Back*. This question was popped here a week ago ... perhaps we need an auto-responder! Rob Philihp Busby wrote: No. When people have a problem with back buttons, 95% of the time they are either doing one of the following: - Confusing the GET and POST methods and their intended purpose with forms. - Abusing client-side browser scripting for forwarding users. On 5/11/06, temp temp [EMAIL PROTECTED] wrote: Is there any way I can realize using java that the user clicked on browsers back button ? Thanks Regards - Yahoo! Mail goes everywhere you do. Get it on your phone. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Loosely coupled pages and actions
Michael Jouravlev wrote: First, about input=pagename bit. I personally believe that * input property should be deprecated * if it is not deprecated, then it should be at least renamed to error, because input is a misleading name input property is not an input page, it is the location where control is forwarded in case of error. I think that input page that preceds an action and the target location for situation when error occurred are totally different concepts. Thanks ... I'm busily patting myself on the back at present for getting that bit right, though I suspect others may inject differing opinions and say that the error handling should be via an include in the input page! (ouch) I currently just use it to link to a common self-standing validation error handling jsp, as you said. Rob - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Loosely coupled pages and actions
Michael Jouravlev wrote: On 5/3/06, Rob Manthey [EMAIL PROTECTED] wrote: ... action knowing dynamically what jsp it's called from ... Despite that HTTP is stateless, the application has its state, which is defined by * state stored on the server, like session-scoped data * input data that was submitted with request Based on this information, application updates the Model (and its state) if needed (that is, updates session objects or writes to a database, database being a part of server state), and displays a view. It may choose a view out of several possible views based on current state (again, if you do not use session-scoped objects, current state is completely defined by input data and maybe by some stuff that you pulled from the database). Yep, this is currently what I understand and what my app does, so I'm glad I'm not too far off-track so far! :) If you care about where your action is called from, Only so much as to have a page for the server to send back to the user - ie: the page that they were on - not some other interim page. just pass this info along as request parameter, this is the easiest thing. Or, instead of passing something like calledFrom=SearchPage you can pass something like searchCriteria= The action would know that it needs to perform a search and to return found. ... which is where I was heading, but thought I'd pull on the reins and say am I doing this right? Is there a part of the framework that I'm missing that does this for me. (I suspect this'd be resolved outright if my app was using AJAX for the shared actions ... ?) Try this as well: http://wiki.apache.org/struts/DataEntryForm Had a peek - this looks like mandatory reading for me next up. The above link needs some polishing, but it already has some usable ideas. Write (or curse) back if my babbling was not clear ;-) Michael. Thanks heaps Rob - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: request scope paging
Dave Newton wrote: Kyle W. Cartmell wrote: I understand the concept behind this, but does anyone actually use this in production code? Seems more trouble than it's worth since the user could simply start multiple sessions. How? Isn't that browser-dependent? And no, I wouldn't bother dealing with this use-case unless it was a requirement (which it sometimes is :) This situation was so pervasive and compromising that we decided to include handling for it in our production code. The consequences of users injecting requests from the stale windows that arise from the assorted manifestations of multiple browser windows were too problematic for our support side and and we felt that it left the users doubting our software's hardiness and useability. A self-inflicted requirement to some degree, mainly to avoid a perception of and criticism as weak software - irrespective of having warned users not to open multiple windows on the same data object, and making all claims that it's not our software, it's http's issue. Consequently we've ended up with a web app that probably behaves a little less like http://www.* and a little more like C:\Program Files\* (which is what the generic manager thinks in terms of ... MS Office does it so why can't our website?) There's probably less pain involved if you set out to manage that case from the outset, rather than blending it in late. Perhaps it would make a nice plugin taglib for contribution to OS? Rob - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: What To Do If Users Use the Browser Back Button?
Caroline Jen wrote: ...etc... But, we are getting in trouble if users use the browser Back button. After several clicks on the browser Back button, we get system errors. What to do to handle the situation? ...etc... This must be one of the most frequently asked questions on this list. Is it worth someone putting a FAQ on the Struts website so that askers of this much-repeated question can be directed there? Pretty much goes hand in hand with equally notorious My site works fine, until I open another browser window aka multiple browser windows problem. Also worth a FAQ? I know they're not expressly Struts question, but are very commonly asked here ... If no one else is interested I might throw together something and post it on a domain elsewhere for public FAQing, but I'd need some time for self-education and assistance to proof read whatever I would put up. Also I'm buried in real (and home!) work at present. Thanks Rob - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: What To Do If Users Use the Browser Back Button?
Caroline Jen wrote: ... in trouble if users use the browser Back button. After several clicks on the browser Back button, we get system errors. What to do to handle the situation? have a look through some of these ... http://marc.theaimsgroup.com/?l=struts-userw=2r=1s=back+buttonq=b try: http://marc.theaimsgroup.com/?l=struts-userm=113160817003562w=2 and the ensuing answers in that thread ... have fun Rob - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: What To Do If Users Use the Browser Back Button?
Frank W. Zammetti wrote: Rob, might I suggest the Wiki? That's kind of the point of its existence :) good call. i'm off for the weekend now, so no more fun for me today ;) back for more on monday. cheers Rob - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Are layers 'that evil'?
I found this recent par on a local JUG resonated for me and had some theme parallels to Rick's current thread ... how much do we over-code in ignorance of the natural mechanisms available? (Sure, the uber-coders among us can code better frameworks and deserve the fruits, but not we lesser-lings, who usually tangle things more by trying on that caper.) Rob Paul Reedman wrote: snip/ I still run into Java projects that build their own frameworks !!! Yes Struts or hibernate is not good enough, we need our own framework, so lets spend precious several weeks (or months) of the project time recasting a new web framework. Another thing I have noticed is that Java people love building layers. So a particular developer doesn't like the interface into hibernate or struts (or whatever framework) so they build another layer on top of the framework. This layer then becomes complicated and so a whole bunch of other people add to the layer in an attempt to make it easier. (which doesn't happen because all they have done is to make it more complicated) Of course this new layer hides everything and soon you have no idea what you are doing. Importantly no one documents this new layer, so when new people join the project, they ask I don't understand this framework... Of course they don't know that underneath all of this software is plain old struts which has disappeared from view. snip/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Loosely coupled pages and actions
Hi, I have some actions that I have decoupled from their jsps, so that I can use the corresponding html components on various pages and move them around as the client changes their mind about requirements. I have implemented a programmatic mechanism for the action to know which assets to populate and which jsp to render after the action has completed, but it's getting a little tricky with some boundary fault cases, as I've also implemented a window uniquifier to permit multiple browser windows being acted in without session collisions. Anyway, can someone point out what I've overlooked? Is there a simpler (framework) way of a loosely coupled action knowing dynamically what jsp it's called from (esp: note the cases of the component being or not being in a jsp:include) so that it can populate the right assets and render the right jsp? Using the struts-config.xml action input entry only allows one point of origin, and using request.getRequestURI() returns the last *action* not the originating jsp to forward back to (not helpful when the last action is itself one of these decoupled actions, as opposed to an inital jsp entry action). Thanks in advance for any input. Rob - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Loosely coupled pages and actions
Thanks Michael. I'm just picking my way through your answer ... Ok, the jsp:include bit is interesting ... and I'm going to consume that in detail later, that's a lesser case at present. One question on the non-include side ... - Michael Jouravlev wrote: On 5/3/06, Rob Manthey [EMAIL PROTECTED] wrote: ... action knowing dynamically what jsp it's called from ... Unless it is the case of jsp:include, I personally believe that action should not know or care to know where the request came from. I'm anticipating that this is on the back of an MVC axiom that the action updates the model and then the jsp just fetches the assets it wants from the model, so the which assets does the action need to populate is catered for by not anticipating which page you are heading for, just update all assets that the action has tainted. (I'm probably still missing the finer points, as this seems not to be as lightweight an approach as updating the assets that were tainted by the action *and* are going to be wanted in the next jsp, but ok it would solve the asset selection problem.) However (correct me please), surely *something* needs to know which jsp to fetch to return to the user ... ? If this is removed from the action's responsibility, how do I configure the Struts1 framework to dynamically route back to the right page when an action can be called from multiple jsps ... ? struts-config.xml seems to only allow one page for an action to anonymously default back to after completion ... action input=pagename. Your patience is appreciated. If the answer is in a nuance of your previous reply, feel free to textually slap me. Rob - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Loosely coupled pages and actions
Michael Jouravlev wrote: On 5/3/06, Rob Manthey [EMAIL PROTECTED] wrote: action knowing dynamically what jsp it's called from ... ... If you like, you can stick your last location into your HTML forms as a hidden field, or into all links as a parameter in a rewrite-URL manner. Yuk. Yes, I was deliberately avoiding that type of bare-your-soul-to-the-user html programmatic stuff. I'm acheiving a lot with serverside programmatic side-steps at present, and was aware of that possibility, but am trying to find any way to avoid adding another special field in my url rewrites. Rob - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Loosely coupled pages and actions
Michael Jouravlev wrote: On 5/3/06, Rob Manthey [EMAIL PROTECTED] wrote: ... action knowing dynamically what jsp it's called from ... [1] http://www.caucho.com/resin-3.0/webapp/faq.xtp request attributes available in target.jsp request.getAttribute(javax.servlet.forward.request_uri) /testapp/index.jsp I'm looking at testing some code around this ... let me know if I'm definitely barking up the wrong tree. Thanks for the tips by the way. Rob - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
