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 reason is the request scope usually contains all sort of objects that need to be shared for a request, and most of those objects don't have anything to do with the view. In JSP, there isn't any other way to transfer objects, but in, say, Velocity, it has its own context that you can populate, and every object in the request scope would not be a good idea.

For Cocoon and Struts Flow, this is handled by the "action" explicitly passing certain business objects to the view in the sendPageAndWait() method. You create an anonymous map and give your objects keys. I believe tapestry also has a way to ensure only certain objects are exposed to the view.

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 ViewContext, adding in any other objects the view might need.

Don



Ted Husted wrote:
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 to the
presentation layer, as opposed to the control  layer. So, the
ViewContext has no semanticas in regard to  navigation and may
have additional semantics in regard to  rendering. Following
the well-worn Velocity philosophy, we want  the ViewContext to
be read-only, free of HTTP and navigational  semantics, and
easy to mock for testing view tools (and only view  tools).

What you see is what you want :)


OK; technically the ContextBase exposes the base context, so we'd have to decide if the ease of not copying or proxying for each specific property outweighs the risk of exposing that for those who want to play with fire.

Thanks for weighing in!

Joe


The thing with the ViewContext is that it is not so much a subclass or superclass of the ActionContext, but a helper class, like TagUtils.

A good model for us to follow would be the VelocityTools for
Struts. If the ViewContext exposed this API, and nothing else, the
Velocity gang have already shown that these methods are all we need
to render the V in MVC :)

* http://jakarta.apache.org/velocity/tools/struts/

The tools are helper beans which we could combine into a single
API, and call it the ViewContext.

Ideally, the ViewContext should make an extension like
VelocityTools obsolete. If these tools are all Velocity needs to
integrate wth Stuts, then I'm sure this API is all that tags and
other rendering systems really need too.

I'll try to put something together and add an interface and base
implementation to o.a.s.chain.contexts so that we have something to
play with.

-Ted.



I'm behind on the other recent threads, but I had this as a draft, and thought it would be better to put it on the table sooner than later.


I don't know if this overlaps with the other threads, but I might not be able to get caught up on those until later this week.

----

<proposal>

A "View Tool" is an object with public properties, including JavaBeans, that is automatically injected to the ViewContext.

Tools are specified in the Struts config by the (new) toolbox element;

----

<toolbox>
  <tool>
   <key>math</key>
   <scope>application</scope>
   <class>org.apache.velocity.tools.generic.MathTool</class>
  </tool>
  <tool>
     <key>wrench</key>
     <class>PipeWrench</class>
  </tool>
  <data type="number">
     <key>app_version</key>
     <value>0.9</value>
  </data>
</toolbox>

----

A tool differs from a plugin in that a plugin is placed directly in the servlet 
application scope. A View Tool is only available through the ViewContext. The ViewContext 
is specialized Context stored under a request attribute, usually "view".

Any object with a zero-argument constructor can be used as a tool. Tools that implement the Struts ViewTool interface will be passed the Struts ActionContext upon instantiation.

</proposal>


Basically, I'm suggesting we implement the Velocity ViewTool strategy in Struts Classic (milestone TBD) to make it


* easier to integrate Strus with any given rendering technology, and * make Struts extensible in ways we have not yet dreamed.

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 
markup business. It's a suggestion that we provide a clean and easy way to 
adapt Struts to any rendering technology.

Here's a concatenation of the Velocity Tools now in production use. One 
approach would be to define an interface for each of these. The ViewContext 
interface would then specify a getter for each. We could plugin a standard 
implementation, but people could also plugin their own.

-----

$errors

exist -         Returns true if there are errors queued, otherwise false.
getSize -       Returns the number of error messages queued.
getGlobal -     This a convenience method and the equivalent of 
$errors.get($errors.globalName)
getAll -        Returns a list of localized error messages for all errors 
queued.
get -           Returns a list of localized error messages for a particular 
category of errors.
getMsgs -       Renders the queued errors messages.

----

$form

getBean -       Retrieve and return the form bean associated with this request.
getCancelName - Returns the query parameter name under which a cancel button 
press must be reported if form validation is to be skipped.
getToken -      Retrieves and returns the transaction control token for this 
session.
getTokenName -  Returns the query parameter name under which a transaction 
token must be reported.

----

$link

setAction -     Returns a copy of this StrutsLinkTool instance with the given 
action path converted into a server-relative URI reference.
setForward -    Returns a copy of this StrutsLinkTool instance with the given 
global forward name converted into a server-relative URI reference.

----

$messages

exist -         Returns true if there are action messages queued, otherwise 
false.
getSize -       Returns the number of action messages queued.
getGlobal -     This a convenience method and the equivalent of 
$messages.get($messages.globalName)
getAll -        Returns a list of localized action messages for all action 
messages queued.
get -           Returns a list of localized action messages for a particular 
category of action messages.

----

$text

get -           Looks up and returns the localized message for the specified 
key.
exists -        Checks if a message string for a specified message key exists 
for the user's locale.
getLocale -     Returns the user's locale. If a locale is not found, the 
default locale is returned (deprecated - will be removed in VelocityTools 1.2).

----

$tiles

importAttributes -      Imports all attributes in the current tiles definition 
into the named context
getAttribute -          Returns a named tiles attribute from the current tiles 
definition
importAttribute -       Imports a named attribute in the current tiles 
definition into the named context.
get -                   Inserts the named tile into the current tile.

----

$validator

getPage -               Gets the current page number of a multi-part form.
setPage -               Sets the current page number of a multi-part form.
getMethod -             Gets the method name that will be used for the 
javascript validation method name if it has a value.
setMethod -             Sets the method name that will be used for the 
javascript validation method name if it has a value.
getHtmlComment -        Gets whether or not to delimit the javascript with html 
comments.
setHtmlComment -        Sets whether or not to delimit the javascript with html 
comments.
getSrc -                Gets the src attribute's value when defining the html 
script element.
setSrc -                Sets the src attribute's value (used to include an 
external script resource) when defining the html script element.
getCdata -              Returns the cdata setting "true" or "false".
setCdata -              Sets the cdata status.
getJavascript -         Generates javascript to perform validations on a 
struts-defined form.
getDynamicJavascript -  Generates the dynamic javascript methods to perform 
validation on a struts-defined form.
getStaticJavascript -   Generates all the static javascript methods from 
validator-rules.xml.

----

Thoughts?

-Ted.



---------------------------------------------------------------------
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]



Reply via email to