In the mid-90s, Australia was begging American developers to move there; what happened? And why are you in Singapore, anyway?
-----Original Message----- From: Andrew Hill [mailto:[EMAIL PROTECTED] Sent: Sunday, August 10, 2003 10:58 PM To: Struts Users Mailing List Subject: RE: [FRIDAY] Impossible requirements & customer expectation management [WAS: method to get new Id to next action when old Id is in request?] Not here there arent. A mere 4 years experience doesnt even qualify you for an entry level position in this economy anymore. Its been an IT desert for a couple of years now and no end in sight... (And why is it that the 'morons' as you put it, are always the ones with the money?) hehe I suppose one of the advantages of being low on the food chain in a salaried position is that I get to explain the impracticality to someone who can understand it, and they get to figure out how to explain it to the boss (who in my company is tech savvy which makes things easier). Id be interested to know what the client gets told in the end though ;-) -----Original Message----- From: Simon Kelly [mailto:[EMAIL PROTECTED] Sent: Friday, 8 August 2003 21:15 To: Struts Users Mailing List Subject: Re: [FRIDAY] Impossible requirements & customer expectation management [WAS: method to get new Id to next action when old Id is in request?] +several million ----- Original Message ----- From: "Mark Galbreath" <[EMAIL PROTECTED]> To: "'Struts Users Mailing List'" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Friday, August 08, 2003 2:18 PM Subject: RE: [FRIDAY] Impossible requirements & customer expectation management [WAS: method to get new Id to next action when old Id is in request?] Move on. There are plenty of jobs for the competent and there is no point in wasting your time developing for morons. -----Original Message----- From: Andrew Hill [mailto:[EMAIL PROTECTED] Sent: Friday, August 08, 2003 7:29 AM To: Struts Users Mailing List Subject: RE: [FRIDAY] Impossible requirements & customer expectation management [WAS: method to get new Id to next action when old Id is in request?] So what does one do when one has requirements that are (for all practical purposes) impossible? How does one actually go about convincing a Customer/PHB/VIP that its impossible without them thinking one is incompetent and making excuses? -----Original Message----- From: ansuman_behera [mailto:[EMAIL PROTECTED] Sent: Friday, 8 August 2003 19:20 To: Struts Users Mailing List Subject: RE: [FRIDAY] method to get new Id to next action when old Id is in request? no offence meant James but I've had past experience when the so called architects and designer of my client have asked me not to use hidden variables...period... they would not listen to anything, they would not discuss about and hence my question. Obviously you do understand that the answer given by you is something I cannot tell to my customers but thanks for answering anyway. ansuman -----Original Message----- From: James Mitchell [mailto:[EMAIL PROTECTED] Sent: Friday, August 08, 2003 4:43 PM To: Struts Users Mailing List Subject: RE: method to get new Id to next action when old Id is in request? That's ridiculous. If that were true, then just give up and go home. -- James Mitchell Software Engineer / Struts Evangelist http://www.struts-atlanta.org 770-822-3359 AIM:jmitchtx > -----Original Message----- > From: ansuman_behera [mailto:[EMAIL PROTECTED] > Sent: Friday, August 08, 2003 2:51 AM > To: Struts Users Mailing List > Subject: RE: method to get new Id to next action when old Id is in > request? > > > what if there is a restriction that the developers should not be using > hidden variables? what do you do in this case? > > -----Original Message----- > From: Rohit Aeron [mailto:[EMAIL PROTECTED] > Sent: Friday, August 08, 2003 11:54 AM > To: Struts Users Mailing List > Subject: RE: method to get new Id to next action when old Id is in > request? > > > Try putting up id as a hidden variable... > > Eg: > > <html:hidden name="FormBean" property="id"/> > > > it would work > > regards > Rohit > > -----Original Message----- > From: Adam Hardy [mailto:[EMAIL PROTECTED] > Sent: Friday, August 08, 2003 2:56 AM > To: Struts Users Mailing List > Subject: method to get new Id to next action when old Id is in > request? > > I have two actions chained together. They both take the same formbean. > The first is sectionInsert.do and the second, which sectionInsert > forwards to on success, is sectionEdit.do > > sectionInsert.do receives the properties of a Section in the request > parameters, including id=0 where it is 0 because it does not exist in > the DB yet. So it inserts the new Section into the DB and returns the > new id, which is needed by sectionEdit to put into the html for the > edit page. > > I originally thought I could save the new id to the formbean and this > would get passed on, but sectionEdit instantiates its own formbean and > fills it with the request parameters - include id=0. > > Is there an intuitive way of passing on the new id? > > I already use sectionEdit.do as a first action by calling it with an > id on a querystring, where the formbean picks it up. I would like to > use a method that is easy for both these situations. > > I'd appreciate any inspiration. > Adam > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > > *---------- > This message and any attachment(s) is intended only for the use of the > addressee(s) and may contain information that is PRIVILEGED and > CONFIDENTIAL. If you are not the intended addressee(s), you are hereby > notified that any use, distribution, disclosure or copying of this > communication is strictly prohibited. If you have received this > communication in error, please erase all copies of the message and its > attachment(s) and notify the sender or Kanbay postmaster immediately. > > Any views expressed in this message are those of the individual sender > and not of Kanbay. > > Although we have taken steps to ensure that this e-mail and any > attachment(s) are free from any virus, we advise that in keeping with > good computing practice the recipient should ensure they are actually > virus free. > > > --------------------------------------------------------------------- > 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]
