On 5/23/05, Laurie Harper <[EMAIL PROTECTED]> wrote: > 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.
A string containing a protocol (http) a URL (host) and a number of other identification matters (myapp, something.jsp) whether having query parameters or not is not a request. All sorts of data goes with a request on all occasions which enable the communications in for example, http to take place. > 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 repeat, again, you are not using the terms "pull", or "push", or "request" the way they are used. Your use is idiosyncratic. There is not hing declarative about your approach either. This is not what "declarative" means in this context. > 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. This is not, again, a "pull/push" issue. Pull and push are relationships between client and server. Your relationship is between the view and the model. This also is not related to "design constraints" or "design rules". This is just coding on the JSP page and is really not a good idea. It is such a bad idea that whole technologies are invented to avoid it. If you are running a "mom and pop" show, this is not important. In that case, not much would be important. But, in the "craft" of programming, which admittedly is not rocket science, it is important. > > 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 :-) Just use some framework, like Struts. Write your actions and your model to take are of this business and feed the data to the appropriate scopes and objects. -- "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]
