On 6/27/06, Michael Jouravlev <[EMAIL PROTECTED]> wrote:
On 6/23/06, Paul Benedict <[EMAIL PROTECTED]> wrote:
> I find two uses of action mappings in my applications. One loads data for view, another
writes data and then goes to a view. These views, I suppose, would logically be
"pages" if Struts were a page-based controller. But I do find this kind of
use-case always cropping into my apps, and one of my biggest problems is that when I do a
save or cancel, I have no automated stack that tells me what my last logical view was.
>
> So I'd like to propose allowing developers to mark actions as a page or a
view (and I have not finialized my nomenclature, so please help me word it
better). Then Struts can keep a running stack, at some N depth (maybe just 1),
that would allow me to always return to the previous view.
>
> <action mapping .... page="true" />
>
> In the Action class:
> Action.findPreviousPageForward();
>
> Thoughts, O comrades?
Paul, first about "view" attribute. I bunnied up it first ;-) It is mine :-))
Now about going to a previous view. I guess that in attempt to break
from stateless page-oriented paradigm of many Struts apps I might have
gotten into confines of object-oriented paradigm. So please correct me
if I will be wrong here.
To me, Action or Action/ActionForm combination represents a logical
web resource, or a business object if you will. It is usually a
stateful object: even if I don't use session, I might save its state
in the database. So to me, navigating to Action means "Hey, object,
show yourself in the way that corresponds to your current state". This
is particularly true when pages are fronted with Action classes. When
I navigate to a web resource I don't really know what will be shown. I
think that Craig had this idea in mind when he explained why
ActionForward should represent a logical outcome of an Action, not a
menu choice [1].
So, to me going to "previous view" does not make a lot of sense. What
if the object that is rendered by this view has changed its state or
has gone out of scope?
Umm... From another point of view, you want to mark a whole mapping as
"view", this is different than marking a particular page. So, you mean
that some of your actions/resources can render themselves and some
cannot, and you want to keep count only of these that can? In this
case my argument above does not make much sense but I will keep it
anyway ;-)
On the other hand, if it is an interactive application, a user must
always be presented with something to look at, right? So if response
is not immediately followed by a redirected request, it represents a
view. These views can be accounted for without modifying action
mapping.
I think I miss something here :-) Maybe you want to say, that an
action can have different query parameters and thus one action will be
considered as different resources. While browser differentiates
resources by full URL including parameters, you want to differentiate
just by base URL, right? I guess this makes sense...
Michael.
[1] http://wiki.apache.org/struts/ActionForward
Ok, I think I got it :)
Say, you have a.do with page="true"
Then you call b.do with no page attribute, this action does not return
a view and forwards directly to c.do
Then you fool around c.do, producing c.do?param1, c.do?param2, c.do?param3
Then you want to cancel your c.do action as if it were a dialog
window. You want to return to a.do. You cannot simply use last URL,
because it would be c.do?param2 since browser treats URL as different
if they have different params.
Am I right?
Whenever you call an action, controller would verify if it is a
"current" action. If yes, it won't add it to the "unwind list". Same
with actions that do not produce views.
I think this makes sense. It will be useful.
Of course, if you open a new window after, say, c.do?param3 and the go
to a previous action, you will get a.do in your second window. Is this
a bug? I guess not. After all, if a user opens a new window he knows
what to expect ;-)
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
