You're bluring the distinction between client-side behaviour and
server-side behaviour a little there. Ignore the client side for the
moment; I'm talking only about how the application works on the server.
The issue is about how the JSP gets access to the data it needs to
display. Normally, as you say, there would be an action or some other
server-side component which executes before the JSP and places data into
some scope which the JSP then retrieves. That's what I'm refering to as
a 'push' model, in that there is some component pushing data out to the JSP.
In my case, I want the JSP to get access to the data by explicitly
requesting it -- i.e. 'pulling in' the data it needs. As I noted in my
other reply to you, this could be seen as breaking the MVC paradigm by
putting application logic in the JSP. There's some truth in that.
The reason I do it is quite simple. By having the JSPs aquire the data
they need in this way, it is much easier to customize the application
after it is delivered. Page flow can be changed, additional information
can be shown on an existing page, and so, all without modifying Java
code. That means I can deliver a highly customizable product. It's a
trade-off: I bend MVC encapsulation, but gain a significant benefit.
So, 'pull', in the context of this discussion, just refers to how the
JSP gets acces to the data it needs. In my implementation, the JSPs
instantiate beans which represent a view of the data they need. The
beans then do the work of interacting with the backend (via a service
layer). So the data access is really still in the controller part of the
application, it's just being triggered by the JSPs rather than by a
Struts action. In a way, you can think of it as using the JSPs to
declaratively describe what data they will use rather than having to
have an action or other component know in advance.
L.
Dakota Jack wrote:
A few thoughts:
(1) The push/pull dichotomy really does not apply to what you are
talking about. That relationship is between the client and the server
and has more to do with the nature of the protocol, viz. HTTP, being
employed in a browser context.
(2) Likewise, some of the other things you say seem to not track the
semantics of the actual problem space. For example, JSPs never
"capture data" but are used to create dynamic HTML in the response.
The data always comes from the request object which only indirectly is
related to the prior JSP page and the form elements available on that
page. We could always put together a request object without any JSP
at all and scoot it off to the server. Hackers, of course, do just
that.
(3) A JSP page "fronted" by a simple ActionForward cannot be populated
unless you have something put the populating bean in some scope.
Presumably that activity has to somehow be explained. Why you do not
what to use an ActionForm or this is not clear. I do many things, of
course, without the ActionForm participating, but the Action or the
ActionForm must be doing something. A simple ActionForward cannot
give you a bean with the data you need. Something is wrong with this
description. I would guess that you have some Action put the bean
into scope. This has nothing to do with "pull" as that term is
normally used in the "push/pull" discussions outside Dr. Dolittle's
push-pull llama.
(4) When you say there is no "custom" action to populate the bean but
that it is "pulled" from the page, I can only think that you mean you
have the code that should be in the model on the JSP page. If so,
this is not "pull" and is not a good idea.
Is that right? If not, then I don't know where the so-called "pull
data" is coming from.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
