Dakota Jack wrote:
You cannot talk about request objects and ignore the client. The
requests come from the client.
Sure, but I'm not talking about request objects. A request to
http://host/myapp/something.jsp (with no query parameters) contains no
request data, but the JSP still has to display information. What I'm
taling about is how that information is retrieved from the backend.
Any data coming to a JSP comes in the same way. This is not pull and
this is not push. The data comes from some class existing in some
scope: page, request, session, application. You are not doing
anything new. You are just doing the old stuff badly, I believe. I
only say that to be helpful as I can be and not to belittle you or
anything like that.
Your cases has the JSP more than requesting the data. Your case has
the JSP in charge of getting the data. That is very different. Any
data coming to a JSP must be "requested", i.e. gotten from some call
from the JSP page. Your pages does more, viz. instantiates the
objects, etc. which provide the data on the JSP page.
Again, your idea that way is flexible is not true. You are less able
to "customize" with your approach because you have all sorts of
disparate code tied to each other. If you have a variable on a JSP
page be a logical reference to data, then the physical source of that
data becomes irrelevant. You, however, make direct references rather
than logical references and tie down your code completely.
JSPs access data through page/request/session scoped variables, just
like yours do. With a push methodology, a JSP may assume that there will
be a request scoped variable 'user' which references a bean of type
UserView. It renders the page by making reference to the properties of
this bean through the 'user' variable.
The only difference with a pull methodology is that, somewhere in the
JSP, there is a <jsp:useBean class="UserView"/>. The rest of the JSP is
written exactly as it would have been using a pull methodology. There's
no 'disparate code' and the references to data are no more or less
direct than when using push.
The coupling is the problem. Coupling leads to fragile, rigid, code
which is expensive to maintain.
Absolutely, which is why it's important when using pull to keep it
simple and make sure data retrieval is as declarative as possible. I'm
certainly not advocating that JSPs should be making JDBC calls or anything.
I hope this is helpful, and realize that I am just stating my opinion.
I don't think you are at all right, but certainly am willing to
listen to what you have to say.
As I said in my previous post, you need to understand the design
constraints. No approach solves every solution, no design rule is
inviolate. I'm using a pull model to solve a very specific requirement:
that the data displayed on a JSP page should be able to be changed /from
the JSP page/, without access to the application source code.
I can see why it looks, at first glance, like I'm doing something badly
wrong but, in the light of that requirement, I'm not aware of another
approach that's workable. Feel free to suggest alternatives if you have
them :-)
L.
On 5/22/05, Laurie Harper <[EMAIL PROTECTED]> wrote:
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
