On 7/7/05, Rick Reumann <[EMAIL PROTECTED]> wrote: > (moved to new topic heading, but keeping seem referenceID for those > threading).. > > Michael Jouravlev wrote the following on 7/7/2005 1:40 PM: > > > Ok, Rick, lets pull out and compare :-) But before I go into > > presenting my approach, could you tell me, what happens in your app > > when a user clicks Refresh? Or Back? > > Sure. No problem. It depends on the application. If it's a requirement > that data does not get submitted twice I simply use the token approach > that is very easy to implement. It doesn't take much at all to ensure > duplicate entries do not get entered.
Yes, it does not take much. But it is not the best solution. Token works *after* POST request has been resubmitted. It can help to prevent *data resubmission* on business/persisntence layer, but it does nothing to prevent browser message: "Do you want to resend POSTDATA?" What? What is POSTDATA? I don't care what it is, and I don't know do I want to resend it or not, just show the damn page. The simple "send POST, get page" approach results in horrible UI, like I had to go through when I was ordering parts for my car. Car make->POST form. Model->POST form. Year->POST form. Suspension part->POST form. Struts (no put intended)->POST form -> (looking for Tokico struts, don't see any). Go Back. "Do you want to resend POSTDATA?" - No -> I see the same page. Back again. "Do you want to resend POSTDATA?" - Yes -> The previous page is reloaded with the same POST, running the same query on the server. Same happens three or four more times. I wanted to strangle the programmer who desinged that. Right, if pages were cachable, it would help. Or if I used Opera. But this is only one example of many. In other cases Opera does not help, it gets in the way. Another example. You want to log in. You enter name, it is incorrect, it is redisplayed. Again, and again, and again. You decided to drop the idea, and to return back. How many times you need to click Back? Also, token does knows nothing about your business data. You are shopping in the online store. You selected item, clicked "Add to cart", it was added, and you forwarded to another page. Then you realised that you need two of them. You click Back, see the same item again and click "Add to cart". Now it tells you that you cannot do this, because you are resubmitting the same request, apparently by mistake. Your webapp can prove it to you, it has the token. But it is not a mistake, you actually want to add the same item again. So, tokens better than nothing, like Yugo comparing to bike. But it is still a Yugo. (I am not selling Lexus here, merely a Corolla). > > DispatchAction and its subclasses accepts input as form submission > > only (POST), because it detects input phase or render phase by request > > type. I think, this is a reasonable limitation. > > Not true. I pass stuff with a get all the time using a URL. This was a typo, I corrected it in another thread. I meant DialogAction. I need to distinguish between input phase and render phase. > I see what you are doing - > basically have a generic Action that tells the form to update, delete, > etc. Again, I think this is pretty 'cool' but I don't think it is that > much of a time saver Rick, I am sorry, but you don't see it (yet). It would be a generic action if it had not have two-phase request processing. I have a SelectAction for what you think it is, just an improved DispatchAction. But DialogAction is much more that an action with predefined handlers. I mean, DialogAction does not have predefined handlers at all (it has default getView() though). CRUDAction has predefined handlers, it is based on DialogAction, thus it has full power of two-phase request processing. > and it is definitely a totally different paradigm > from all the Struts stuff out there. Is this bad? > Not saying it's not a good concept, > I'm just stating that is more difficult to grasp at first since it's not > how Struts was desgined. Right, so I suggest another way of doing things. I think, a better way. But it is not a replacement for other Struts stuff, this is merely an addition. > You are free to mold it however you want and > that's the beauty of open source, but I don't see your solution as that > much more of a time saver or any easier to understand than the basic > approaches. It is easy to understand and to use, once you get the idea, what two-phase processing (aka Redirect-after-Post) is good for. *AND* it allows to build almost fool-proof UI with better user experience. > ALSO I will amost GUARANTEE you that in reality you will almost always > end up having to do other things when an update/edit/delete takes > place... This is just a base CRUDAction, subclass it if you need. But I believe that it is good as it is for 90% cases. > > Anyway, my version does not differ from other handlers. > > Data is loaded from the backend by crudForm.crudLoadForUpdate() > > method. This method has to load existing data either directly into > > action form or into nested BO/VO. > > But it does differ as to where this stuff is being done. yes, stuff is done where it should be done in OO app - at the same place where data is. > > "Get users" is the action not directly related to CRUD, so it is not > > implemented in CRUDAction, which is a standard action class and can be > > used directly, without modification. "Get users" is implemented in a > > separate action. > > AHHH ok see, but now look... this why I think your solution is > confusing.... Some DB stuff (gets, updates, etc) is being done in > ActionForms (CRUDFOrms) and other times it's being done in standard > Actions. I'm sorry I just find this confusing. Stuff being done in too > many different places. Some done in ActionForms, some in Actions. We all know, that EJB is not good for everything, and ORM tools too. If you need one object, go get it via EJB or Hibernate or whatever. If you need a list of objects, or not even objects, just couple of fields and ID, then good old SELECT is usually much faster *and* easier. Anyway, the ItemListAction is just a helper which shows item list. It was not supposed to demonstrate great OO techniques. But if you think that it is so much inconsistent, I can redesign it. But again, ItemListAction is not part of CRUDAction. The latter works with single object using ID. The list action shows a list of objects. These things are not tied together. On the other hand I already have CRUDComboAction (not in current download), which combines both. I guess I need to replace former with latter ;-) > the difference is I'm handling all of my other opeartions in Actions > also and not in ActionForms. You are doing some in ActionForms and some > in Actions. I often treat Action and ActionForm as part of one entity, so sometimes I do stuff here, sometimes there. When both classes work in pair (and they often do), this should not really matter. But I agree with you, that more consistent approach would be better. > > This works for me too :-) Here is the live demo of above CRUD application: > > http://www.superinterface.com/strutsdialog/cruditemlist.do > > Looks nice. Where is the full source code for this application including > the JSPs etc? I didn't see it in the dialog project that I downloaded? It is there: \dialogs\src\net\sf\dialogs\samples\crudaction All CRUD stuff (not the item list) is done with CRUDFormSample and standard CRUDAction. CRUDFormSample extends CRUDForm implements ICRUDForm ICRUDForm is standard interface for CRUD operations, it does not preclude from extending other action forms, like ValidateAction. CRUDForm is the base action form which you do not *have* to extend, but then you would need to copy some stuff from it to your concrete action form. It initializes current form state, and also checks for scope, with which form is defined. > The only negative I see is that if someone is going to invest the time > to use the framework like you have set up for Struts dialog, I'd rather > suggest they start working with JSF. To me, their concept in the regard > to how you are using ActionForms, falls more in line with JSF (and > webworks)... a backing type bean that handles the operations on itself. > I'm sure i'm mangling up terms I know. JSF allows to easily set up for two-phase processing, you are right. But it does not provide "web islands" mode, that is, when different pages are delivered from the same web location. This allows to cut on the browser page history. Also, JSF uses JSF. There are a lot of people who want to continue using JSP, and not to invest in new component technology. And by the way, speaking of components, Struts Dialogs allows to create JSP Components with only one <jsp:include>. > My main thrust, though, is not that Struts Dialog doesn't look nice, I > just think that it's very radically different from how people expect > Struts to work People expect of Struts either to change or to die. I don't want it to die, not yet, as well as I don't want to learn a new one, therefore I created my stuff. But seems that it is easier to start off a new framework, even if it is a spinoff off an existing one, than to try to change what is considered "traditional" and "normal". > and if people start using it that are new and start > asking questions on the struts list, they will be totally lost. First, I am not going anywhere, at least not now ;-) Second, I already have pretty good documentation, and I will extend it and make it more clear. If Struts Dialogs were accepted in Struts core, then the suggested way would become a traditional way, and would be documented and would have javadocs, etc. Also, if it became "normal", then newbies will not quesion "why I should use this over that", they will simply use it ;-) I understand that veteran Struts users have their ways. I do not suggest to change these ways, I am offering a choice of doing stuff differently. Choice is good, is not it? Is not it the power of open source? Michael. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
