You cannot talk about request objects and ignore the client. The requests come from the client.
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. The coupling is the problem. Coupling leads to fragile, rigid, code which is expensive to maintain. 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. 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] > > -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
