Laurie Harper wrote:
Nope, Dave nailed it. Re-read the requirement I described. The point
is to avoid using actions to load the data and pass it to the view. If
you re-read my description of what I mean by 'push' vs. 'pull' rather
than simply saying the terms mean something different it might
This is a long thread, so it might be worth repeating that Laurie
wants her (human) clients to be able to write Java code on the JSP
page. She seems to call this "data pulling".
On 5/29/05, Ted Husted <[EMAIL PROTECTED]> wrote:
> On 5/28/05, Laurie Harper <[EMAIL PROTECTED]> wrote:
> > Thanks for
On 5/28/05, Laurie Harper <[EMAIL PROTECTED]> wrote:
> Thanks for the reference Craig; but unless I'm mis-reading you, that
> still leaves me with data lookup 'hard coded' in Java classes. My goal
> is to be able to change a page's data requirements without
> recompilation.
If it would be OK to e
Thanks for the reference Craig; but unless I'm mis-reading you, that
still leaves me with data lookup 'hard coded' in Java classes. My goal
is to be able to change a page's data requirements without
recompilation. I'll take a look at Shale though and see if it has
anything to help in that conte
Blvd, #1096
Las Vegas, NV 89156
Phone:(702)643-7425
Fax:(702)974-0341
*Note new email changed from [EMAIL PROTECTED]
-Original Message-
From: Dakota Jack [mailto:[EMAIL PROTECTED]
Sent: Saturday, May 28, 2005 11:58 AM
To: Struts Users Mailing List; [EMAIL PROTECTED]
Subject: Re: DynaAction
The View Helper pattern creates presentation *content* which requires
processing of dynamic business data. The forces are that the business
data assimillation requirements are nontrivial, embedding business
logic in the view would promote a copy-and-paste type of reuse, you
want a clean separation
essage -
> From: "Laurie Harper" <[EMAIL PROTECTED]>
> To:
> Sent: Sunday, May 22, 2005 7:36 PM
> Subject: Re: DynaActionForm and the 'pull' model
>
>
> > There's no code in the JSPs, though you could make the argument that
> > having the
From: "Laurie Harper" <[EMAIL PROTECTED]>
To:
Sent: Sunday, May 22, 2005 7:36 PM
Subject: Re: DynaActionForm and the 'pull' model
There's no code in the JSPs, though you could make the argument that
having the JSPs fetch the data they need, through whatever me
On 5/24/05, Laurie Harper <[EMAIL PROTECTED]> wrote:
> Nope, Dave nailed it. Re-read the requirement I described. The point is
> to avoid using actions to load the data and pass it to the view. If you
> re-read my description of what I mean by 'push' vs. 'pull' rather than
> simply saying the terms
Dakota Jack wrote:
[...] and am not interested in Dave's little flame bit.
You were interested enough to assume that what I said was flame bait and
respond passive-aggresively, when really all I said was that it was
obvious that we weren't talking about the same thing. Now for a _better_
e
Okay, Laurie. I did miss that you were somehow setting it up so that
clients could actually modify your JSP pages directly. That surprises
me and I missed it. Good for Dave, he caught that. I still don't see
where you said that, but if that is the project, then I certainly have
no more to say a
Sorry, Laurie, but if you are going to define your own meanings for
"request" and so on, then I just don't have time to learn how you are
speaking, even if what you said was enticing. I am not saying you are
wrong, just that I would prefer to use terms in a standard way to
avoid having to learn id
Nope, Dave nailed it. Re-read the requirement I described. The point is
to avoid using actions to load the data and pass it to the view. If you
re-read my description of what I mean by 'push' vs. 'pull' rather than
simply saying the terms mean something different it might help.
I think I'll dr
It doesn't help to say 'your terms do not have the meaning you've
defined them to have for purposes of this discuession' and conclude that
the following arguments are invalide. Re-read the requirement I stated
below. Your concluding comments do not in any way address it.
L.
Dakota Jack wrote:
Michael Jouravlev wrote:
You do realize, that JSP _is_ a part of app source code, do you? And
Err, well, yes... ;-)
the more you put into JSP, the more this supposedly dumb JSP page will
look like "real code"? If you ship without source code, you'd rather
precompile the JSPs.
That would mak
That's an interesting approach, though I think a much more complicated
solution than I need. My objective isn't to allow clients to script
actions or otherwise modify their behaviour, but to make that
unnecessary. This approach would certainly allow one to provide much
more power if that were n
Dakota Jack wrote:
If these are the issues, then you must be speaking some language with Ms. Harper
that I don't know.
Of that I have little doubt.
Dave
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands
Okay, Michael. If this is what you like, good luck. I am stopping
the conversation from my side if it is staying at this level.
On 5/23/05, Michael Jouravlev <[EMAIL PROTECTED]> wrote:
> > > JSPs "fetch" data indeed is putting application logic in the JSPs.
> > > This does not give you flexibili
I believe the point was nothing like this at all, Dave. Don't know
why you thought it was. Seems like you just thought this stuff up
separate to me. However, certainly I don't think that the issue
whether or not you are writing a CMS is relevant to the issues
discussed. I also have no idea why
Normally, Camilo, when you have a question you start your own thread.
On 5/23/05, Camilo Quevedo <[EMAIL PROTECTED]> wrote:
> Hi, I'm trying to create a struts application, but it seams that when i
> ask for a user input (html:form) it doesn't,t recognize the special
> characters. How can I config
> > JSPs "fetch" data indeed is putting application logic in the JSPs.
> > This does not give you flexibility. Quite the opposite, it ties your
> > model and you view down by coupling them. Rather than give you
> > flexibility it hamstrings you.
So what? These two will always be related unless y
Dakota Jack wrote:
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.
I believe the point was that this isn't an option. It seems to me, in
this case, that the client wants more contro
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 para
Rather than pollute the view (if one chooses to perceive it that way...
I'm staying away from that debate!), why not introduce some sort of
scripting engine into the mix? I'm not really sure precisely where
because I don't know your project, but I say this based on your comment:
"True, at develop
Hi, I'm trying to create a struts application, but it seams that when i
ask for a user input (html:form) it doesn't,t recognize the special
characters. How can I configure my application so that it accepts
special character??
So far I've done this:
i my jsp I put <%@ page contentType="text/ht
Dakota Jack wrote:
If you want to discuss this, I have a number of things to say. If you
So I see on your other reply ;-)
find that "argumentative", then I won't offer anything more. Having
No, I'm happy to discuss; it's always worth hearing another person's
perspective.
JSPs "fetch"
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 displ
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
a
If you want to discuss this, I have a number of things to say. If you
find that "argumentative", then I won't offer anything more. Having
JSPs "fetch" data indeed is putting application logic in the JSPs.
This does not give you flexibility. Quite the opposite, it ties your
model and you view do
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
There's no code in the JSPs, though you could make the argument that
having the JSPs fetch the data they need, through whatever means, is
putting application logic in the JSPs. And yes, this is generally not
reommended. In this case it's minimal and the trade off is the
flexibility it provides
You are just coding on the JSP page, which for reasons that have been
discussed to death is a bad idea. If you like it, have at it. But,
generally speaking this is a very bad idea.
On 5/19/05, Laurie Harper <[EMAIL PROTECTED]> wrote:
> Adam Hardy wrote:
> > Laurie,
> >
> > my chosen option woul
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 s
Adam Hardy wrote:
I'm not really keen to 'pollute' the view objects with String-type
derived properties just for the HTML presentation; the view objects
are how any client (web app, web service, Swing GUI, etc) would
interact with the application. This also implies having
String-to-model conve
Adam Hardy wrote:
On 19/05/05 21:29 Laurie Harper wrote:
This is what I decided to try first. I threw together a prototype last
night, and it seams to work well. Basically, the idea is:
- extend the view API to include 'View.toMap(Map props)' and 'void
View.fromMap(Map props)' on each view c
Adam Hardy wrote:
I'm not really keen to 'pollute' the view objects with String-type
derived properties just for the HTML presentation; the view objects
are how any client (web app, web service, Swing GUI, etc) would
interact with the application. This also implies having
String-to-model conve
On 19/05/05 21:29 Laurie Harper wrote:
This is what I decided to try first. I threw together a prototype last
night, and it seams to work well. Basically, the idea is:
- extend the view API to include 'View.toMap(Map props)' and 'void
View.fromMap(Map props)' on each view class
- you can the
On 19/05/05 21:29 Laurie Harper wrote:
my chosen option would be to use your view objects as form objects,
where you modify the view object by adding string-typed getters and
setters for every property.
I'm not really keen to 'pollute' the view objects with String-type
derived properties ju
Adam Hardy wrote:
Laurie,
my chosen option would be to use your view objects as form objects,
where you modify the view object by adding string-typed getters and
setters for every property.
I'm not really keen to 'pollute' the view objects with String-type
derived properties just for the HTML p
Laurie,
my chosen option would be to use your view objects as form objects,
where you modify the view object by adding string-typed getters and
setters for every property. I don't really get what you mean in your (2).
I think the parameter handling issue is hugely debatable. I've lost
count of
[Appologies for the long post; hopefully it'll spark some interesting
discussion though.]
Does anybody develop with Struts using a 'pull' model (where JSPs 'pull'
in the data they need, rather than having it 'pushed' to them by a
calling action)? I've been doing this successfully for some time with
41 matches
Mail list logo
