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]
