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]