You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Rick Reumann <st...@reumann.net> on 2005/07/07 20:57:03 UTC
dialog stuff (was) Re: Refresher for newbies...
(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. If the user hits 'back' on their
browser button most of the time that page info displayed is cached by
the browser. If it's critical that the page always show fresh data
(which usually it is not) then ther are ways to ensure that also (doing
the pragma, no-cache stuff like you do in your DialogAction).
> I will use my DialogAction, which subclasses DispatchAction, adding an
> important feature to it: two-phase request processing aka
> Redirect-after-Post. It helps to avoid resubmits, and makes the whole
> process of input/change state/render view much easier.
Like I said if resubmits are in issue just use the Token approach. It's
super easy and documented.
> My DialogAction or its subclass CRUDAction (thanks for this great
> example, I have action exactly for this use case) does not have any
> default values. If you navigate to the action, it simply shows current
> data for current state. So, as you see, my actionform has session
> scope to be stateful.
My DispatchAction doesn't have default values either. I'm not sure what
you are talking about here. If I want to keep state, I simply give my
ActionForm session scope and or if I want list of users to have state I
put it in session scope. What's new about giving an ActionForm session
scope?
>
> I don't care much about how VO/BO is mapped to actionform. Basically,
> if you want values to be populated from request, and to be used in
> JSP, either create setter/getters in the actionform, or set VO/BO as
> nested property of the actionform.
Agreed. I often do the same (nest a VO/BO in my ActionForm, although
this wouldn't be the initial approach I'd give someone just starting out).
> I have generic CRUDAction, which has create(), duplicate(), edit(),
> view() and delete() methods. And of course, getView(), which renders a
> proper page.
Yes I see that.
>
> 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.
> The corresponding create() method in CRUDAction from Struts Dialogs
> looks like this:
>
> public ActionForward onCreate (ActionMapping mapping,
> ActionForm form,
> HttpServletRequest request,
> HttpServletResponse response)
> throws Exception {
>
> // Action Form must implement ICRUDForm
> ICRUDForm crudForm = (ICRUDForm) form;
>
> // Create new business object (item), and get back errors if any
> ActionMessages messages = crudForm.crudCreate();
>
> // Successfully created new object and initialized action form
> if ((messages == null) || messages.isEmpty()) {
> // Need to handle this "forward" object in struts-config.xml
> return mapping.findForward(CRUDConstants.MAPPING_ON_CREATE_SUCCESS);
>
> // On error save messages into session. Struts 1.2.6+ has
> // a special method for it; this code saves errors directly
> // to session for compatibility with older Struts versions.
> } else {
> HttpSession session = request.getSession();
> session.setAttribute(Globals.ERROR_KEY, messages);
> // Handle this "forward" object in struts-config.xml
> return mapping.findForward(CRUDConstants.MAPPING_ON_CREATE_FAILURE);
> }
> }
Yes, I saw this in the code I download. 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 and it is definitely a totally different paradigm
from all the Struts stuff out there. 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. 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.
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... maybe you'l have requirements that you need to stuff something
else into the request, maybe something else into the session - you'll
say do this all in your the CRUDForm subclass, which yes you can do but
to me it's not intutive. I think what IS intutive is getting a handle to
HtttpServletRequest in a SERVLET. That's what people are used to
using. Pushing this stuff off to a CRUDForm is definitely different.
>>// THE SET UP FOR EDIT
>>
>> Ok, this is the one you were asking about. Now you have to think about
>>how you would get here? Typically you'd get to an edit page by clicking
>>on a user record to say "Hey, I want to edit this guy's user
>>information" So imagine a case where we have a list of users and
>>'userID" for each in the list, they click on the link and they'll come
>>to this method which will get our user and then forward them to a page
>>to do the editing. The method will look like...
>>
>>public ActionForward setUpForEdit(ActionMapping mapping, ActionForm
>>form, HttpServletRequest request, HttpServletResponse response) throws
>>Exception {
>>
>> UserActionForm userForm = (UserActionForm)form;
>> //userID is set in this form when the user clicked on the link
>> //lets get our real business object of this user, based on ID..
>> UserVO user = ourBackendDelegate.addUser( userForm.getUserID() );
>> //copy the other way this time, from UserVO to our Form...
>> PropertyUtils.copyProperties( userForm, user );
>> //finally we are going to reuse or form for add and edit, so
>> //we will set up our dispatch/action parameter
>> userForm.setDispatch("edit");
>> return mapping.findForward("to_form");
>>}
>
>
> I guess in the above method you meant to write
> UserVO user = ourBackendDelegate.getUser( userForm.getUserID() );
Yes! Great catch..thanks:)
>
> 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.
>>//The get users - this will display our users on the page
>>public ActionForward getUsers(ActionMapping mapping, ActionForm form,
>>HttpServletRequest request, HttpServletResponse response) throws Exception {
>> //lets say pass in companyID
>> Integer companyID = Integer.valueOf( request.getParameter("companyID"));
>>
>> //get our list of users to display on page
>> List users = ourBackendDelegate.getUsers( companyID );
>> request.setAttribute("users", users );
>>
>> return mapping.findForward("to_display");
>>}
>
>
> "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. Just
provide a GetUserAction or getUsers dispatch method... an
UpdateUserAction or updateUser dispatch method. It's consistent and easy
for anyone to follow.
>
>
>>4) sample config...
>>
>>
>><action path="/userMaintenance" type="com.foobar.UserAction"
>> name="userActionForm"
>> scope="request"
>> validate="false"
>> parameter="dispatch">
>> <forward name="to_form" path="/userForm.jsp"/>
>> <forward name="to_display" path="/displayUsers.jsp"/>
>> </action>
>
>
> Here is mine, it is not users, but abstract items with ID, stringvalue
> and numvalue. You see a lot of mappings for different occasions, but
> most of them simply reload the same action, and can be replaced with
> standard "ON-RELOAD".
>
> <!-- CRUD action helper: item list -->
> <action path="/cruditemlist"
> type =
> "net.sf.dialogs.samples.crudaction.ItemListActionSample"
> name = "dummyForm">
> <forward name = "showlist" path="/crudaction-list.jsp"/>
> </action>
>
> <!-- CRUD action -->
> <action path="/crudaction"
> type = "net.sf.dialogs.actions.crud.CRUDAction"
> name = "crudform"
> scope = "session"
> validate = "false"
> parameter = "DIALOG-EVENT">
>
> <!-- Where to hand control over after input phase (POST) -->
>
> <forward name="ON-CREATE-SUCCESS" path="/crudaction.do"
> redirect="true"/>
> <forward name="ON-DUPLICATE-SUCCESS" path="/crudaction.do"
> redirect="true"/>
>
> <forward name="ON-PREVIEW" path="/crudaction.do" redirect="true"/>
> <forward name="ON-EDIT" path="/crudaction.do" redirect="true"/>
> <forward name="ON-LOAD-FAILURE" path="/erroraction.do"
> redirect="true"/>
>
> <forward name="ON-DELETE-SUCCESS" path="/cruditemlist.do"
> redirect="true"/>
> <forward name="ON-DELETE-FAILURE" path="/erroraction.do"
> redirect="true"/>
>
> <forward name="ON-CANCEL" path="/cruditemlist.do" redirect="true"/>
> <forward name="ON-CLOSE" path="/cruditemlist.do" redirect="true"/>
>
> <forward name="ON-STORE-SUCCESS" path="/cruditemlist.do"
> redirect="true"/>
>
> <forward name="ON-STORE-FAILURE" path="/crudaction.do"
> redirect="true"/>
> <forward name="ON-INVALID-DATA" path="/crudaction.do"
> redirect="true"/>
>
> <!-- Which page to load on the output phase or on refresh (GET) -->
>
> <!-- Edit Mode -->
> <forward name="CRUD-UI-MODE-EDITABLE" path="/crudaction-edit.jsp"/>
> <!-- Preview Mode -->
> <forward name="CRUD-UI-MODE-READONLY" path="/crudaction-noedit.jsp"/>
> <!-- Illegal mode, item is not active -->
> <forward name="CRUD-UI-MODE-INACTIVE"
> path="/crudaction-notactive.jsp"/>
>
> </action>
> <action path="/erroraction" forward="/crudaction-error.jsp"/>
>
>>5) Sample form
>>
>><html:form action="/userMaintenance">
>> Name: <html:text property="name"/><br/>
>> <html:hidden property="userID"/>
>> <html:hidden property="dispatch"/>
>>
>> <html:submit value="${userForm.dispatch}"/>
>> <!-- above button logic can be done many ways, just for
>> simplicity i'm using the dispatch name-->
>><html:form>
>
>
> Here is mine, this one is for edit. There is another for view, which
> does not have edit fields.
>
> <html:form action="/crudaction.do">
> <table border="1" width="300" >
> <tr>
> <td>Item ID</td>
> <td><bean:write name="crudform" property="itemId"/></td>
> </tr>
> <tr>
> <td>String value</td>
> <td><html:text name="crudform" property="stringValue"/></td>
> </tr>
> <tr>
> <td>Num value</td>
> <td><html:text name="crudform" property="intValue"/></td>
> </tr>
> <tr>
> <td colspan="2">
> <INPUT type="submit" size="10" name="DIALOG-EVENT-CANCEL"
> value="Cancel">
> <INPUT type="submit" size="10" name="DIALOG-EVENT-DELETE"
> value="Delete">
> <INPUT type="submit" size="10" name="DIALOG-EVENT-SAVE"
> value="Save Changes">
> </td>
> </tr>
> </table>
> </html:form>
>
>>6) Sample page displaying users lets them edit and delete them
>>
>><c:forEach items='${users}' var='users'>
>> <c:url var="editUrl" scope="page" value="/userMaintenance.do">
>> <c:param name="dispatch" value="setUpForEdit"/>
>> <c:param name="userID" value="${user.userID}"/>
>> </c:url>
>> <c:url var="removeUrl" scope="page" value="/userMaintenance.do">
>> <c:param name="dispatch" value="delete"/>
>> <c:param name="userID" value="${user.userID}"/>
>> </c:url>
>> ${user.name} <a href="${editUrl}">[ EDIT ]</a> <a
>>href="${removeUrl}">[ DELETE ]</a>
>></c:forEach>
>
>
> You mean the list? It does not directly relate to CRUD, does not it?
No, not specifically. But it does relate to a common event users want -
a list of items for display. As I mentioned I'm curious where you would
populate this list? According to your config file you'd be doing this in
the Action class: ItemListActionSample which is what I'm doing also,
but 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.
> But here it is, for completeness:
>
> <table border="1" width="100%">
> <tr>
> <th>ID</th>
> <th>Str Value</th>
> <th>Int Value</th>
> <th colspan="4">Operation</th>
> </tr>
>
> <logic:iterate id="item" name="crud-item-list"
> type="net.sf.dialogs.samples.crudaction.business.BusinessObj">
> <html:form action="/crudaction.do">
> <tr>
> <td><bean:write name="item" property="itemId"/></td>
> <td><bean:write name="item" property="stringValue"/></td>
> <td><bean:write name="item" property="intValue"/></td>
>
> <td>
> <html:submit property="DIALOG-EVENT-INIT-DUPLICATE"
> value="Duplicate Item"/>
> </td>
>
> <td>
> <html:submit property="DIALOG-EVENT-INIT-VIEW"
> value="View Item"/>
> </td>
>
> <td>
> <html:submit property="DIALOG-EVENT-INIT-UPDATE"
> value="Update Item"/>
> </td>
>
> <td>
> <html:submit property="DIALOG-EVENT-DELETE"
> value="Delete Item"/>
> </td>
> </tr>
> <html:hidden name="item" property="itemId"/>
> </html:form>
> </logic:iterate>
> </table>
> <br/>
> <html:form action="/crudaction.do">
> <html:submit property="DIALOG-EVENT-INIT-CREATE"
> value="Create New Item"/>
> </html:form>
>
>>Basically 90% of applications are doing something similar to the above.
>>Presenting data to users and often letting them click on things to edit.
>>Personally, this concept works well for me. There are several tweeks I
>>have to do for more complex things, but this is the 'meat' of most
>>applications.
>
>
> 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?
Overall, at first glance, my conclusions so far haven't changed...
I think what you have so far is cool, and I think it's definitely more
Object Oriented which I like - makes sense from an OO perspective for
the Object to know how to update itself etc.
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.
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 and if people start using it that are new and start
asking questions on the struts list, they will be totally lost.
--
Rick
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: dialog stuff (was) Re: Refresher for newbies...
Posted by Michael Jouravlev <jm...@gmail.com>.
On 7/8/05, Wendy Smoak <ja...@wendysmoak.com> wrote:
> From: "Michael Jouravlev" <jm...@gmail.com>
> > Rick, check out this one:
> > http://www.superinterface.com/strutsdialog/crudactionlite.do
> > All CRUD operations in one web island. Check out your Back button ;-)
>
> Michael, check your link... "Cannot find bean crud-item-list in any scope"
>
> I'm interested but haven't found time to look at in depth. Patience...
Oops, was rushing yesterday. I just did a quick fix, should work now.
Please, open in a new window and see is your Back button enabled,
while you playing with the items.
I would be interested to know how it works on Mac, I don't have access to one.
Michael.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: dialog stuff (was) Re: Refresher for newbies...
Posted by Michael Jouravlev <jm...@gmail.com>.
On 7/7/05, Michael Jouravlev <jm...@gmail.com> wrote:
> Oh, I am sorry, you misunderstood me. What I did, is combined
> ItemListAction with CRUDAction, so I show list from the same location.
> It gives the usual benefits of web island. Basically, the whole thing,
> list and edit and view forms, and all operations, and everyting take
> one slot in page history. So, no going Back ever. You see the list -
> you cannot go back to the item you just edited. You see an item, you
> cannot go back to the list (only through buttons on the form). I will
> try to deploy it today or tomorrow.
Rick, check out this one:
http://www.superinterface.com/strutsdialog/crudactionlite.do
All CRUD operations in one web island. Check out your Back button ;-)
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: dialog stuff (was) Re: Refresher for newbies...
Posted by Michael Jouravlev <jm...@gmail.com>.
On 7/7/05, Rick Reumann <st...@reumann.net> wrote:
> Michael Jouravlev wrote the following on 7/7/2005 5:13 PM:
>
> > 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).
>
> Yes, it does sound like your approach to the whole 'back' issue problem
> handles things in a much nicer fashion. I'll definitely have to look at
> least how you handle it. (I might not buy the whole Corolla but would
> like those fancy rims:)
Rick, first of all, I am grateful for warm reply. I highly value
opinion of veteran users like you. But now, when I got your attention,
I started to think "what if what I have is really not that good"? I
wanted others to "get" and to appreciate my ideas (actually, most of
these ideas are flying around and are used in other projects, but
whatever). Now I feel like having a test in a college. ;)
I want to try explain my approach to Back button here, before you
start looking at the code. Quite a few people told me, that my
approach is not using technology, it is bending technology and working
against it, that it is not how people got used to do stuff. This is
discouraging, but seems to be true. For example, in my Windows
programming days I always payed attention to proper keyboard support,
that all operations were available from keyboard, that all tabstops
were correct, etc. But very fiew people use keyboard, when they learn
how to move mouse around. They could care less how good keyboard
support was.
Same with web apps. Many (most?) developers and users do not care
about Back button or Refresh, because they do not use them. They see
the message "Do not click back button after check out" or "Do not
click submit button again" and they do not do it. They do not realise
that applicaiton they are using is not perfect, because they are not
QA engineers, they do not click all buttons here and there, they just
follow the path. So, some of my reasonings can seem irrelevant to
many.
I have an opinion on web apps. Let's put Ajax and Flash aside, and
talk about "normal" web app. I see two different modes. First, is
traditional "hyperdocument" mode, when you have pages, links, you
follow link, get to another page; then you can go back to the previous
page if needed. This mode works well for static or quasi-static pages,
documents, online magazines, different hierarchical things like list
of the goods in online store. This mode is usually stateful, at least
in regards to what you see on your way there and back.
Another mode is tied to application state. If you added goods to the
cart in online store, then whenever you navigate to the cart, you
should see its current content. Even if you use Back button, this is
my opinion. Same, checkout process: when it finished, server changed
its status, your cart is disposed, so if you go back, you should not
see the cart and, what even worse, to have chance to submit it again.
No, when you go back, you should see message that cart was disposed.
So, this mode is usually stateful, and it keeps browser pages (view)
synchronized with server (model). This is where I get strange looks.
>From here I went a little further and thought, that there are
objects/entities in an application, which are stateful, and can be
rendered differently according to their current state. So, why would
one want to be able to navigate to different pages of this object? It
is more logical to navigate to the *object* itself, which renders
itself differently depending on state. On the one hand, this approach
still allows to bookmark an object, though not a particular page
belonging to that object. On the other hand, you do not need to click
Back several times to return from this object. Because if all pages
are loaded from the same location (location == URL + parameters), then
browser would consider these pages as one resource, and would put only
one entry in the page history. This is like "single-page application".
But this term is already used by Flash and Ajax apps, which do not
reload page and load data in background. So I decided to call these
objects "web islands". They are not so slick as Ajax because they are
reloaded after each data submit. On the other hand, they are reloaded
from the same location, thus logically correspond to one resource. I
think this is kinda cool. But also this allows to protect users from
double submit. For example, the wizard which you can see here:
http://www.superinterface.com/strutsdialog/wizardaction.do is served
from one location. So unless you use Opera, you will notice, that your
Back button is not enabled while you use this wizard. And you cannot
go back to previous wizard page using browser button. This wizard is a
"web island".
My email is getting too long, and have not had a beer yet...
> > *AND* it allows to build almost fool-proof UI with better user experience.
>
> This part does interest me a lot.
I hope you will not get too excited, I don't want to promise too much.
The idea of two-phase processing (I like this new term, the old one is
Redirect-after-Post) is to give a user more freedom in clicking
buttons that he can reach to, at the same time trying to limit access
to these buttons when possible ;)
Say, you use Opera, which is the worst case for my stuff. Still, you
get benefits because if you deliberately or by chance click Refresh
button, nothing will happen, the result page will be simply reloaded.
A user will not see nagging POSTDATA message (I HATE THEM, can i get
the larger letters?), and application will not have to fight with
resubmitted data.
Going Back on Opera is kinda sucky, because even if you mark page with
"no-cache, no-store", Opera does not reload a page. *And* it stores
all pages in the history, even if they are loaded from the same
location. Bummer. So, the only positive result with Opera is safe
Refresh. Not much. So you still need to use tokens. Tokens is the
whole other story, I prefer to use model state or timestamp for that.
I think that model knows better is it possible to resubmit data or
not. But this is not relevant here.
For other browsers like MSIE or Firefox, things look much sleeker.
They reload non-cached page if you go back, *and* they keep only one
entry for each resource even if this resource responds with different
content. In this case web islands work like a charm. Here is what you
get:
* If you respond with differnt content from the same location, then
while you are at this location, you cannot go back to previous page
from this location. This protects you from resubmitting the form from
previous page.
* You can freely refresh a page too.
* You can go to another site, then navigate to web island *using
address bar* and you will get your object in the same state in which
it was left. This is not a particular win of redirect stuff, this is
just because I store state on the server and I do not pass any state
variables (freaking _viewstate) in the request/response. But with my
pattern which includes redirect I just have to use server state. So,
if you not like to store state in session, then my stuff is not for
you...
* If you click Back button, you return from web island as a whole. So,
if you tried five times to log in, then you need only one click to go
back, because there is only one entry in the page history (see above).
> I'd love to be able to pull
> your CRUDform out and use in a Swing app if I needed (possibly it can, I
> don't have the code here at home right now).
Um, don't think it would work. There is not much in that form...
> > On the other hand I already have CRUDComboAction (not in current
> > download), which combines both. I guess I need to replace former with
> > latter ;-)
>
> Actually I think that would be a good idea. It definitely will make the
> framework no chance of an 'addition' any more but I think that's a more
> consistent approach to take. (I believe this is what WebWorks does and
> is a similar approach to the backing bean concept in JSF?). Plus the
> ActionForm is just sort of goofy anyway:) I just assume stick my single
> VO in there anyway vs creating all those duplicate properties.
Oh, I am sorry, you misunderstood me. I did not make a great thing
combing action and action form. Er, no. What I did, is combined
ItemListAction with CRUDAction, so I show list from the same location.
It gives the usual benefits of web island. Basically, the whole thing,
list and edit and view forms, and all operations, and everyting take
one slot in page history. So, no going Back ever. You see the list -
you cannot go back to the item you just edited. You see an item, you
cannot go back to the list (only through buttons on the form). I will
try to deploy it today or tomorrow.
But I still have the idea of generic Action + Form combo, so I hope I
will implement it too ;)
> however I have this feeling (probably unfounded) that
> companies are going to feel overwhelmed with the choices out there and
> simply say "Screw it, I'll just go with an MS solution."
The good thing that company I currently work at is about to have
another web project and hopefully I will be able to use my own stuff.
On the other hand, I am not sure how I can use it at work, and still
keep it for myself and as opensource. I hope that putting it out to
the sourceforge should help a bit.
Thanks for warm reply, it is really encouraging ;)
Michael.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: dialog stuff (was) Re: Refresher for newbies...
Posted by Adam Hardy <ah...@cyberspaceroad.com>.
Michael Jouravlev wrote the following on 7/7/2005 5:13 PM:
> The good thing that company I currently work at is about to have
> another web project and hopefully I will be able to use my own stuff.
> On the other hand, I am not sure how I can use it at work, and still
> keep it for myself and as opensource. I hope that putting it out to
> the sourceforge should help a bit.
Modularise it and put it out on SourceForge quickly! Make sure that your
email address registered at SourceForge is not your company email!
(Otherwise you might end up like Mark Galbreath!) Then just use it like
any other open-source component.
Rick Reumann on 08/07/05 05:24, wrote:
> [SNIP] This is the reason
> actually that I'm going to start learning .NET stuff. I think what you
> are proposing seems very exciting and I look forward to keeping tabs on
> the progress, however I have this feeling (probably unfounded) that
> companies are going to feel overwhelmed with the choices out there and
> simply say "Screw it, I'll just go with an MS solution."
That's exactly why I suggested that Struts should 'shrink' - at least
struts-core should shrink. At the risk of boring the list, I'll just cut
and paste what I wrote (it disappeared without a reply earlier):
In my humble opinion the struts community has not grasped an opportunity
which would see it compete against .NET and other java frameworks.
Struts should shrink.
I'm thinking of Maven. The most contentious yet inspired point about
Maven is that you just have to follow the 'Maven way' or you won't gain
any advantage over Ant. Yet if you do make that paradigm shift and do
your project the Maven way, the benefits are massive.
Struts should offer a best-of approach, and offer a whole set of
documentation that steers the web developer down that path.
Such a focus during future struts development would allow many
compromises to be thrown out in favour of the more efficient but
limiting choices, which would translate into shorter turn-around times
for struts web-app developers who went along with it.
So Rick, I agree with your opinion, but not with your consequent actions
(learning .NET) and Michael, I disagree here - choice is not good! Well
not for newbies.
Adam
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: dialog stuff (was) Re: Refresher for newbies...
Posted by Rick Reumann <st...@reumann.net>.
Michael Jouravlev wrote the following on 7/7/2005 5:13 PM:
> 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).
Yes, it does sound like your approach to the whole 'back' issue problem
handles things in a much nicer fashion. I'll definitely have to look at
least how you handle it. (I might not buy the whole Corolla but would
like those fancy rims:)
> 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.
Yea, I really should be fair and look at your stuff longer. It's just so
overwhelming with all the technologies out there and different ways of
doing things... it just gives me a headache and I'm burned out doing it;)
>>and it is definitely a totally different paradigm
>>from all the Struts stuff out there.
>
>
> Is this bad?
No, not if the shift yields good benefits, which I'm sure you will argue
the shift would provide and it's not fair for me to say it wouldn't
without looking into it further.
>
>
>>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.
Well, I might beg to differ a bit there, I think it's a bit more than
'addition.'
> *AND* it allows to build almost fool-proof UI with better user experience.
This part does interest me a lot.
>>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.
Probably true.
>
>
>>>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.
I could see arguments both ways. Seems to still be debate if doing
something like dao.update( someObject ) is better than doing
someObject.update() where the later takes care of updating itself. If
you could all that stuff to work without the stinking thing to have to
be so tied to Struts I'd jump on your stuff in a heartbeat (then again
JSF does manage this I believe). In other words I should be able to use
a generic object that does all the CRUD stuff you mentioned without it
having to be so tied to the Struts model. I'd love to be able to pull
your CRUDform out and use in a Swing app if I needed (possibly it can, I
don't have the code here at home right now).
> On the other hand I already have CRUDComboAction (not in current
> download), which combines both. I guess I need to replace former with
> latter ;-)
Actually I think that would be a good idea. It definitely will make the
framework no chance of an 'addition' any more but I think that's a more
consistent approach to take. (I believe this is what WebWorks does and
is a similar approach to the backing bean concept in JSF?). Plus the
ActionForm is just sort of goofy anyway:) I just assume stick my single
VO in there anyway vs creating all those duplicate properties.
> 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.
Yea, see if you can wrap into one. That would be pretty cool.
>
> It is there: \dialogs\src\net\sf\dialogs\samples\crudaction
Ok, I'll look tomorrow.
> 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>.
Interesting and yea, I'm not convinced 'yet' to jump the Struts/JSP ship
yet. Although one thing I always have to consider is what technology is
going to put food on the table. I'm not a technology bigot so I don't
care that much if I'm coding .NET (which I haven't really touched yet)
as long as it's paying me. My idealistic days now seem behind me:(
> 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".
True.
> 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?
Well said. I have to admit my initial reaction was "Oh here we go again,
another twisting of the framework or 'yet another frameork' in general"
and I had a knee jerk reaction - especially in regard to that it seemed
to be proposed to someone completely new to Struts and might have
confused him. Part of my initial reaction was grounded in that I
personally feel overwhelmed with the technologies out there. Just count
one day how many web frameworks are out there. This is the reason
actually that I'm going to start learning .NET stuff. I think what you
are proposing seems very exciting and I look forward to keeping tabs on
the progress, however I have this feeling (probably unfounded) that
companies are going to feel overwhelmed with the choices out there and
simply say "Screw it, I'll just go with an MS solution." They might even
be somewhat technical and still make the decision since there is
something to be said for using a technology that might be
less-than-ideal, but yet easier to find developers to code with it and
that understand it. (Although it can easily be argued that these 'run of
the mill' developers aren't going to be as smart as some guy that love
open source stuff.) I'm just trying to use my crystal ball and envision
how IT managers are going to think.
--
Rick
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: dialog stuff (was) Re: Refresher for newbies...
Posted by Michael Jouravlev <jm...@gmail.com>.
On 7/7/05, Rick Reumann <st...@reumann.net> 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: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: dialog stuff (was) Re: Refresher for newbies...
Posted by Michael Jouravlev <jm...@gmail.com>.
I released Struts Dialogs 1.21. The biggest change is moving to
net.jspcontrols.* package name.
I wrote some docs on how to create wizards with WizardAction:
http://struts.sourceforge.net/strutsdialogs/wizardaction.html
Michael.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: execute instead of get and post
Posted by Rick Reumann <st...@reumann.net>.
Michael Jouravlev wrote the following on 7/7/2005 5:26 PM:
> On 7/7/05, Rick Reumann <st...@reumann.net> wrote:
>
>>klute wrote the following on 7/7/2005 3:07 PM:
>>
>>
>>>It seems like it would make sense to have both so that
>>>you can use GET to set up a particular form and POST
>>>to process that form. Instead, I'd have to look at the
>>>request to see what was invoked and then conditionally
>>>do some processing.
>>
>>No need for conditional process based on GET or POST, you should be
>>either directing control based on either...
>>
>>A) Separate mappings that point to different Action classes
>>
>> /setUpEdit.do
>> /edit.do
>>
>>or
>>
>>B) pass in a dispatch parameter if using a DispatchAction (You can still
>>use separate mappings also if you want also).
>>
>>--
>>Rick
>
>
> Not quite. POST is generally for data input (form processing). GET is
> generally for pulling static pages or semi-static result pages or at
> least for performing idemponent actions. These methods have different
> semantics. This difference is the cornerstone of approach that I use
> now [plug skipped].
My only point is that klute doesn't really need to worry about whether
it's a GET or POST in order to process what he needs if he does things
in a conventionaly way. He shouldn't be using the same entry semantics
for going to a 'setup' vs 'a true edit' - that's just silly and would
make it extremely difficult for someone working on the code to even
firgure out what's going on. Just create some meaninful action mapping
names and/or dispatch method names and all is well and he won't have to
worry about GET vs POST.
--
Rick
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Paging in DisplayTag
Posted by BH...@powersystems.rockwell.com.
This is dependent on how you have structured you database query. There are
multiple solutions to what you are attempting to do.
1. Create a query that will return the entire resultset and store that
resultset in the session as you metion. If you are returning an extremely
large result set, running the application in a clustered environment with
percistant sessions to a database, or have a large number of users, this
could prove problematic. The more you put into the session, the more
memory your application will use. Additionally, if you persist your
session, you are requerying each time you mention a session. This could be
a mojor performance hit. Finnally, you are moving a lot of data across the
network. If 90% of the users will find what they need on the first 1 or 2
pages of a resultset, pulling back the data to populate the reset of the
menus is a waste of resources.
2. If all users are going to use the same resultset (ie multipage menuing
or a product catalog), this may be a occation for a singleton class with a
collection containing the data. You could refresh this singleton based on
a timeframe to insure it remains current. this will only work for
semistatic results.
3. Implement a fast lane reader pattern. This will subdivide your SQL
results to return only the page that is being displayed using boundry
conditions in the SQL or Stored procedure. This will require a database
hit between each page, but if the database is properly indexed and you are
using a connection pool, you can still retain very fast performance.
I am sure there are many more ways to address this problem, but these are
the three that I have had the most experiance with. It boils down to ever
situation is different and you have to customize your solution based on the
data, the business requirement, and the user habits.
Phani
<phanidhar_j@yaho
o.com> To
Struts Users Mailing List
07/07/2005 06:19 <us...@struts.apache.org>, Michael
PM Jouravlev <jm...@gmail.com>
cc
Please respond to Subject
"Struts Users Paging in DisplayTag
Mailing List"
<user@struts.apac
he.org>
Hi,
Shud my Action form be in session scope if I want to
specify pagesize in display tag for paging..
Because I get the following error:
Error 500: Cannot find bean storeForm in any scope
Thanks,
Phani.
__________________________________
Do you Yahoo!?
Yahoo! Mail - You care about security. So do we.
http://promotions.yahoo.com/new_mail
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Paging in DisplayTag
Posted by Phani <ph...@yahoo.com>.
Hi,
Shud my Action form be in session scope if I want to
specify pagesize in display tag for paging..
Because I get the following error:
Error 500: Cannot find bean storeForm in any scope
Thanks,
Phani.
__________________________________
Do you Yahoo!?
Yahoo! Mail - You care about security. So do we.
http://promotions.yahoo.com/new_mail
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: execute instead of get and post
Posted by Michael Jouravlev <jm...@gmail.com>.
On 7/7/05, Rick Reumann <st...@reumann.net> wrote:
> klute wrote the following on 7/7/2005 3:07 PM:
>
> > It seems like it would make sense to have both so that
> > you can use GET to set up a particular form and POST
> > to process that form. Instead, I'd have to look at the
> > request to see what was invoked and then conditionally
> > do some processing.
>
> No need for conditional process based on GET or POST, you should be
> either directing control based on either...
>
> A) Separate mappings that point to different Action classes
>
> /setUpEdit.do
> /edit.do
>
> or
>
> B) pass in a dispatch parameter if using a DispatchAction (You can still
> use separate mappings also if you want also).
>
> --
> Rick
Not quite. POST is generally for data input (form processing). GET is
generally for pulling static pages or semi-static result pages or at
least for performing idemponent actions. These methods have different
semantics. This difference is the cornerstone of approach that I use
now [plug skipped].
Michael.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: execute instead of get and post
Posted by Rick Reumann <st...@reumann.net>.
klute wrote the following on 7/7/2005 3:07 PM:
> It seems like it would make sense to have both so that
> you can use GET to set up a particular form and POST
> to process that form. Instead, I'd have to look at the
> request to see what was invoked and then conditionally
> do some processing.
No need for conditional process based on GET or POST, you should be
either directing control based on either...
A) Separate mappings that point to different Action classes
/setUpEdit.do
/edit.do
or
B) pass in a dispatch parameter if using a DispatchAction (You can still
use separate mappings also if you want also).
--
Rick
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
execute instead of get and post
Posted by klute <so...@yahoo.com>.
Is there a good reason why Struts does not distinguish
between GET and POST requests and tunnels both through
execute()?
It seems like it would make sense to have both so that
you can use GET to set up a particular form and POST
to process that form. Instead, I'd have to look at the
request to see what was invoked and then conditionally
do some processing.
James
____________________________________________________
Sell on Yahoo! Auctions no fees. Bid on great items.
http://auctions.yahoo.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org