George Lessmann wrote:
> > I'm not sure I understand what you mean by the "input level". Could you
> > describe it further?
>
> First, my understanding of Struts is that actions happen at the form level,
> such that a form action is further inspected to determine what needs to be
> done. In my system, I go to the lower level of granularity to the actual
> input events.
>
Yes, that is pretty much the case (Struts currently being form oriented). Your
first level of granularity is the action URL that the form is submitted to, and
that action can (if it chooses to) dispatch to a "sub-action" dependent on some
fields that were submitted. In the example app, for example :-), the "action"
field is used to distinguish sub-actions that are handled very similarly, but
with just a few differing details, by the same action.
>
> Let's say I have a form. On that form I can do a few actions, namely Update,
> Add, and Delete. In my architecture, I have it like so:
>
> <input type="submit" name="formname.update" value="Update">
> <input type="submit" name="formname.add" value="Add">
> <input type="submit" name="formname.delete" value="Delete">
>
> The form is posting to:
>
> <form name="formname" action="/AppServlet" method="post">
>
One option would be to use JavaScript event handlers on the three submit
buttons, and change where the submit would actually go to.
> Right now, those actions are separate objects but I'm not to sure I like
> that, but I'm also not a fan of runtime introspection.
You probably will not like the way that ActionForm beans work, then :-).
> My goal, though, is
> to remove most, if not all, switch-like logic. Also, I'm trying to get my
> application flow to become as far removed as possible, since one of my goals
> is to make an application mapping app.
On the TODO list for 1.1 is to look at how a finer-grained "workflow" type model
might fit into the overall framework. In addition, there's been some discussion
of handling events finer-grained than a submit -- everything from clientside
JavaScript field validations to interacting with the host "in the middle of" a
page. But that's all in the future ... present day Struts 1.0 is very much
form-oriented (using your terminology).
>
> Anyway, I hope this makes some sort of sense. Getting an understanding of
> the motives of Struts while trying to keep what I like about my stuff is a
> prescription for headaches.
Yah, that makes a lot more sense.
Like any framework, Struts expects you to "buy in" to the design philosophies
that it is based on. People that do find it to be tremendously helpful. People
that don't are going to select something different. (And, for a wide range of
the middle ground, there is also room to customize the details of how Struts
works by subclassing, but it's probably not going to be easily to make
fundamental changes by following this route).
>
> George Lessmann
>
> Ponvia Technology, Inc
Craig
