I'm saying that the framework should be exposed to the View through a coherent
object, which we've been calling the ViewContext.
The ViewContext would be the cannonical means by which any rendering component
interacts with the framework, including our own JSP tags.
As far as a View technology
Hmmm...now I'm confused. As I understand, the point of Velocity Tools
was to create a framework that would allow tools that would be "pushed"
into a context to be used by the view. You are saying the tools would
be used themselves outside the view by the framework?
Don
Ted Husted wrote:
On Tu
On Tue, 15 Feb 2005 17:26:21 -0800, Don Brown wrote:
> For implementation, I would favor adding a
> ActionContext.getViewContext() method that returns a generic
> Context map. The request processing chain could have a command or
> chain of commands after the action executes to process the
> ViewCo
I see where you are coming from now Ted, and I agree a ViewContext would
be very useful. I had to write something similar for Struts BSF but to
put objects in the scripting scope.
To understand ViewContext, you need to realize:
data passed to view != request scope or even ActionContext
The reas
Ted Husted wrote:
http://jakarta.apache.org/velocity/tools/view/
It's *very* important to note that our tools (like Velocity's) would not be designed to emit markup. Just the dynamic data we need to wrap in markup when the page is rendered. This is *not* a suggestion that Core get back into the mar
On Fri, 11 Feb 2005 11:06:49 -0500, Ted Husted wrote:
> On Fri, 11 Feb 2005 06:30:04 -0600, Joe Germuska wrote:
>
>>> The last sentence is the use-case for a ViewContext.
>>>
>>> The use-case is not within the RequestProcessor but without.
>>> The ViewContext is the specific API we want to expose
On Fri, 11 Feb 2005 06:30:04 -0600, Joe Germuska wrote:
>> The last sentence is the use-case for a ViewContext.
>>
>> The use-case is not within the RequestProcessor
>> but without. The ViewContext is the specific API we want to
>> expose to the presentation layer, as opposed to the control
>> laye
At 7:27 AM -0500 2/11/05, Ted Husted wrote:
>Ý(Ah, that's one of the best things about Shale ... no such thing as
Ýa configuration bean, since the managed beans facility of JSF does
Ýall the work :-)
Good point. IMHO, we should think about plugging
in to Spring or Hivemind sooner than later.
Ide
>ÝThis also installs the "split" between the "process-action" and
Ý"process-view" sub-chains, although I haven't yet changed the
ÝSelectInput command to return "false" to eliminate the need for
Ýlater commands to check to see if the form was valid.
ÝI think the big outstanding question in my mind
Thanks for the input, Craig...
I'm not sure it is totally relevant here, but I've seen the concept
mentioned peripherally ... if the intent is that Struts 1.3 should
play nice in a portlet environment...
While I think this is nice in theory, it's not my driving intention,
simply because I have no
Inline.
On Thu, 10 Feb 2005 20:11:59 -0800, Craig McClanahan wrote:
> On Thu, 10 Feb 2005 21:45:04 -0600, Joe Germuska <[EMAIL PROTECTED]>
> wrote:
>
>> OK: the ComposableRequestProcessor now makes sure that the
>> context passed to the initial chain command is an instance of
>> ActionContext --
On Tue, 08 Feb 2005 17:01:14 -0600, Joe Germuska wrote:
> At 11:58 AM +0100 2/7/05, Wolfgang Gehner wrote:
>> We don't see a case for a switching contexts within the request
>> cycle to a "ViewContext".
>>
>> - Based on *last weeks* code, we created our own context named
>> "ActContext" that extend
On Sun, 06 Feb 2005 20:19:01 -0600, Joe Germuska wrote:
> I have just committed the suite of changes I was emailing about a
> few weeks ago. Please be aware that nightly builds are probably
> now the least stable that they've been in some time. I have spent
> some time this weekend working on a s
On Thu, 10 Feb 2005 21:45:04 -0600, Joe Germuska <[EMAIL PROTECTED]> wrote:
> OK: the ComposableRequestProcessor now makes sure that the context
> passed to the initial chain command is an instance of ActionContext
> -- this feels like a much stronger model than the wrapping process.
> I will prob
OK: the ComposableRequestProcessor now makes sure that the context
passed to the initial chain command is an instance of ActionContext
-- this feels like a much stronger model than the wrapping process.
I will probably completely remove the WrappingLookupCommand and
ContextWrapper classes from
> -Original Message-
> From: Joe Germuska [mailto:[EMAIL PROTECTED]
====
>
>
> At 11:58 AM +0100 2/7/05, Wolfgang Gehner wrote:
> >We don't see a case for a switching contexts within the request
> >cycle to a "ViewContext".
> >
> >- Based on *last weeks* code, we created our own con
At 11:58 AM +0100 2/7/05, Wolfgang Gehner wrote:
We don't see a case for a switching contexts within the request
cycle to a "ViewContext".
- Based on *last weeks* code, we created our own context named
"ActContext" that extends ServletWebContext, so we could add
convenience methods on it that k
- Based on *last weeks* code, we created our own context named
"ActContext" that extends ServletWebContext, so we could add
convenience methods on it that keep our action code clean (like we
want to get the bean in scope by calling "getBean" on the context,
"getIDParameter" to get a request par
We don't see a case for a switching contexts within the request cycle to
a "ViewContext".
- Based on *last weeks* code, we created our own context named
"ActContext" that extends ServletWebContext, so we could add convenience
methods on it that keep our action code clean (like we want to get th
I have just committed the suite of changes I was emailing about a few
weeks ago. Please be aware that nightly builds are probably now the
least stable that they've been in some time. I have spent some time
this weekend working on a simple site using the new code (including
struts-taglib and s
20 matches
Mail list logo
