You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Ted Husted <hu...@apache.org> on 2005/02/15 13:29:24 UTC
ViewContext (was Re: ActionContext chain changes committed)
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: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: ViewContext (was Re: ActionContext chain changes committed)
Posted by Ted Husted <hu...@apache.org>.
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 would know, the ViewContext would be Struts.
Rather than create a monolithic ViewContext, I'm now suggesting that we create it as a facade over a standard set of Velocity Tools.
Developers could then plug in replacement tools, or add other application-specific tools to the context, for their own use.
-Ted.
On Wed, 16 Feb 2005 10:18:51 -0800, Don Brown wrote:
> 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 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
>>> ViewContext, adding in any other objects the view might need.
>>
>>
>> This might be the best way to say it:
>>
>> * ViewContext is a non-static TagUtils class
>>
>> made available through request-scope.
>>
>> Originally, I was thinking of the ViewContext as an augmented
>> Context, like the ActionContext. Essentially, the portion of the
>> Struts API that we need to write the taglibs: Methods like
>> getLocale and getTokenName, but without irrelevant methods that a
>> rendering technology doesn't need.
>>
>> When I started to looking at the Velocity Tools for an example of
>> just such an API, I realized that the tool mechanism itself is
>> also quite useful. Rather than come up with a static API, we
>> could take the Velocity route and put objects (or "tool") into
>> the ViewContext. The tools would then provide access to the
>> Struts internals, rather than the context itself.
>>
>> A synergistic approach might be to augment the ViewContext with
>> the methods we need to write tags and other rendering devices,
>> but implement those methods as a facade that calls into a
>> standard set of tool objects.
>>
>> So a call to
>>
>> * viewContext.getLocale
>>
>> might be implemented as
>>
>> * return textTool.getLocale(();
>>
>> where "textTool" is a private member instantiated when the
>> ViewContext is created for this request. The same TextTool would
>> also be available under a standard key through
>> ViewContext.get(String).
>>
>> We would plug our own "framework" tools into ViewContext and let
>> applications do the same with their own tools.
>>
>> The advantages being
>>
>> * No more static TagUtils
>> * Coherent API for tags and other rendering tools * Pluggable,
>> extensible implementation
>>
>> The best part is that the Velocity crew has already done all the
>> foundation work. We just have to adopt and adapt :)
>>
>> -Ted.
>>
>>
>> ------------------------------------------------------------------
>> --- To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org For
>> additional commands, e-mail: dev-help@struts.apache.org
>>
>
> --------------------------------------------------------------------
> - To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org For
> additional commands, e-mail: dev-help@struts.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: ViewContext (was Re: ActionContext chain changes committed)
Posted by Don Brown <mr...@twdata.org>.
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 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
>> ViewContext, adding in any other objects the view might need.
>
>
> This might be the best way to say it:
>
> * ViewContext is a non-static TagUtils class
>
> made available through request-scope.
>
> Originally, I was thinking of the ViewContext as an augmented Context, like the ActionContext. Essentially, the portion of the Struts API that we need to write the taglibs: Methods like getLocale and getTokenName, but without irrelevant methods that a rendering technology doesn't need.
>
> When I started to looking at the Velocity Tools for an example of just such an API, I realized that the tool mechanism itself is also quite useful. Rather than come up with a static API, we could take the Velocity route and put objects (or "tool") into the ViewContext. The tools would then provide access to the Struts internals, rather than the context itself.
>
> A synergistic approach might be to augment the ViewContext with the methods we need to write tags and other rendering devices, but implement those methods as a facade that calls into a standard set of tool objects.
>
> So a call to
>
> * viewContext.getLocale
>
> might be implemented as
>
> * return textTool.getLocale(();
>
> where "textTool" is a private member instantiated when the ViewContext is created for this request. The same TextTool would also be available under a standard key through ViewContext.get(String).
>
> We would plug our own "framework" tools into ViewContext and let applications do the same with their own tools.
>
> The advantages being
>
> * No more static TagUtils
> * Coherent API for tags and other rendering tools
> * Pluggable, extensible implementation
>
> The best part is that the Velocity crew has already done all the foundation work. We just have to adopt and adapt :)
>
> -Ted.
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: ViewContext (was Re: ActionContext chain changes committed)
Posted by Ted Husted <hu...@apache.org>.
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
> ViewContext, adding in any other objects the view might need.
This might be the best way to say it:
* ViewContext is a non-static TagUtils class
made available through request-scope.
Originally, I was thinking of the ViewContext as an augmented Context, like the ActionContext. Essentially, the portion of the Struts API that we need to write the taglibs: Methods like getLocale and getTokenName, but without irrelevant methods that a rendering technology doesn't need.
When I started to looking at the Velocity Tools for an example of just such an API, I realized that the tool mechanism itself is also quite useful. Rather than come up with a static API, we could take the Velocity route and put objects (or "tool") into the ViewContext. The tools would then provide access to the Struts internals, rather than the context itself.
A synergistic approach might be to augment the ViewContext with the methods we need to write tags and other rendering devices, but implement those methods as a facade that calls into a standard set of tool objects.
So a call to
* viewContext.getLocale
might be implemented as
* return textTool.getLocale(();
where "textTool" is a private member instantiated when the ViewContext is created for this request. The same TextTool would also be available under a standard key through ViewContext.get(String).
We would plug our own "framework" tools into ViewContext and let applications do the same with their own tools.
The advantages being
* No more static TagUtils
* Coherent API for tags and other rendering tools
* Pluggable, extensible implementation
The best part is that the Velocity crew has already done all the foundation work. We just have to adopt and adapt :)
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: ViewContext (was Re: ActionContext chain changes committed)
Posted by Don Brown <mr...@twdata.org>.
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: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: ViewContext (was Re: ActionContext chain changes committed)
Posted by Vic <vi...@friendvu.com>.
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 markup business. It's a suggestion that we provide a clean and easy way to adapt Struts to any rendering technology.
>
>
It quacks like a Duck.
What does this have to do w/ .... Tapestry? ;-)
.V
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org