You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@velocity.apache.org by Gabriel Sidler <si...@teamup.ch> on 2002/02/20 12:40:26 UTC
Re: Velocity View API for Struts [Phase 2]
Hi,
based on the output of phase 1 I put together a proposal on how to
divide the functionality into context tools and how to name the methods.
I grouped the functionality into 5 tools with related methods. Having
several tools leads to simpler methods names.
I find this more elegant than having one tool with long decriptive method
names. I have added examples to give you an impression of how methods
typically would be applied in a template.
I am looking forward to your feedback.
Gabe
PS: Please refer to version 0.3 of the API draft for more details about
each method. I have not duplicated this information here.
-------------------------------------------------------------------------------
PROPOSAL
Context Tools for Velocity for Struts, Phase 2
----------------------------------------------
Tool 1) Handling of URLs
------------------------
Class: org.apache.velocity.tools.struts.LinkTool
Recommended name in context: link
Methods:
public LinkTool setPath(String path)
public LinkTool setAction(String action)
public LinkTool setForward(String forward)
public LinkTool setAbsolute(String path)
public LinkTool addQueryData(String key, Object value)
public String getPath()
public String getQueryData()
public String getServerPath()
public String getBaseRef()
public String toString()
Examples:
- A form action
<form name="login" action='$link.setAction("login")'>
produces something like
<form name="login" action="/myapp/actions/loginaction">
- A HREF with a forward
<a href='$link.setForward("home")'>Home</a>
produces something like
<a href="/myapp/templates/index.vm">
- A HREF with an absolute URL
<a href='$link.setAbsolute("/templates/login/index.vm")'></a>
produces something like
<a href="http://myserver:port/myapp/templates/login/index.vm">Login Page</a>
- Create a <base> tag
<base href="$link.baseRef()">
produces something like
<base href="/myapp/templates/login/index.vm">
Tool 2) Message Resources
-------------------------
Class: org.apache.velocity.tools.struts.MessageTool
Recommended name in context: msg
Methods:
public String get(String key)
public String get(String key, Object args[])
public boolean exists(String key)
public Locale getLocale()
Examples:
- A simple internationalized output string
$msg.login014 # equivalent to $msg.get("login014")
- A submit button with an internationalized label
<input type="submit" name="newbutton" value='$msg.get("view35.new")'/>
renders something like
<input type="submit" name="newbutton" value='Neuer Patient anmelden'/>
Tool 3) Error Handling
----------------------
Class: org.apache.velocity.tools.struts.ErrorsTool
Recommended name in context: errors
Methods:
public boolean exists()
public int getSize()
public int getSize(String property)
public HashMap getAll()
public HashMap get(String property)
Examples:
- To output all queued error messages:
#if ($errors.exists() )
<p>There are $errors.size() errors. Please verify your input.</p>
<ul>
#foreach ($e in $errors.all() )
<li>$e</li>
#end
</ul>
#end
- To output all queued error messages for a specific property 'password':
#if ($errors.exists() )
<ul>
#foreach ($e in $errors.password )
<li>$e</li>
#end
</ul>
#end
Tool 4) Action Messages
-----------------------
Class: org.apache.velocity.tools.struts.MessagesTool
Recommended name in context: msgs
Methods:
public boolean exists();
public int getSize();
public int getSize(String property);
public HashMap getAll();
public HashMap get(String property);
Examples:
- To output all queued action messages:
#if ($msgs.exists() )
<p>There are $msgs.size() messages.</p>
<ul>
#foreach ($m in $msgs.all() )
<li>$m</li>
#end
</ul>
#end
- To output all queued action messages for a specific property 'password':
#if ($msgss.exists() )
<ul>
#foreach ($m in $msgs.password )
<li>$m</li>
#end
</ul>
#end
Tool 5) Action Form
-------------------
Class: org.apache.velocity.tools.struts.FormTool
Recommended name in context: form
Methods:
public ActionForm getForm() // was getActionForm()
public String getCancelName() // was getCancelMagicName()
public String getToken()
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VelTools] Velocity View API for Struts
Posted by Gabriel Sidler <si...@teamup.ch>.
Nathan Bubna wrote:
>
> Gabriel Sidler wrote:
> > Hi,
> > I have consolidated all past discussions in phase 1 and phase 2
> > into this latest draft v0.4. Discard all previous drafts.
> >
> > I added a section 2) on auto-population of the context. This documents
> > objects that are made available automatically in the Velocity context.
> > It represents the status of the current prototype.
> >
> > I welcome any feedback.
>
> +1 on everything. i like where things are headed!
Ok, that's great.
I am working now on turning the draft into code, documentation and
examples. In the process I came across several minor things that seem
suboptimal in the current draft. Expect some more details later this
week.
Gabe
--
Gabriel Sidler
Software Engineer, Eivycom GmbH, Zurich, Switzerland
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VelTools] Velocity View API for Struts
Posted by Nathan Bubna <na...@esha.com>.
Gabriel Sidler wrote:
> Hi,
> I have consolidated all past discussions in phase 1 and phase 2
> into this latest draft v0.4. Discard all previous drafts.
>
> I added a section 2) on auto-population of the context. This documents
> objects that are made available automatically in the Velocity context.
> It represents the status of the current prototype.
>
> I welcome any feedback.
+1 on everything. i like where things are headed!
> From my point of view we are now pretty close to a stable version and
> can soon move to the design, implementation and documentation.
>
> Gabe
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VelTools] Velocity View API for Struts
Posted by Gabriel Sidler <si...@teamup.ch>.
Hi,
I have consolidated all past discussions in phase 1 and phase 2
into this latest draft v0.4. Discard all previous drafts.
I added a section 2) on auto-population of the context. This documents
objects that are made available automatically in the Velocity context.
It represents the status of the current prototype.
I welcome any feedback.
>From my point of view we are now pretty close to a stable version and
can soon move to the design, implementation and documentation.
Gabe
-------------------------------------------------------------------------------
VELOCITY VIEW API FOR STRUTS
============================
Version 0.4, 22-Feb-2002
This document describes the Velocity View API for Struts.
1) Context Tools
2) Auto-Population of the Velocity Context
1) Context Tools
----------------
The following five context tools have been defined:
1.1) LinkTool - Support for working with hyper links, translation between logical
names and the corresponding paths
1.2) MessageTool - Support for working with Struts message resources
1.3) ErrorsTool - Support for working with Struts error messages
1.4) ActionMessagesTool - Support for working with Struts action messages
1.5) FormTool - Support for working with HTML forms in templates
1.1) LinkTool
--------------
Struts supports a configurable level of indirection between the URL of a
request and the handler of that request. For example, a URL of /main.do
may be mapped by configuration to a handler class.
Furthermore, Struts knows the concept of 'forwards'. A 'forward' is a name
for a request target, such as a request handler or simply a web page.
This configurable mapping of logical targets to actual targets allows
one to avoid hard-coded URLs in templates. All the logical links between
the different views of an application can be maintained in a configuration
file.
The LinkTool provides methods to work with hyperlinks:
o translate logical names to real paths
o construct and encode query strings
o retrieve server, port and path info for the current request
Class: org.apache.velocity.tools.struts.LinkTool
Recommended name in context: $link
Methods:
public LinkTool setPath(String path)
Returns a copy of this link with the given path setting.
No conversions are applied to path.
Note: It is Struts recommended practice to forward to
actions or forwards, but not directly to templates as this
bypassed the Struts controller. Consider using setAction()
or setForward() instead.
public LinkTool setAction(String action)
Returns a copy of this link with the given action name
converted into a server-relative path (as per configuration
in struts-config.xml).
Example:
<form name="login" action='$link.setAction("login")'>
produces something like
<form name="login" action="/myapp/actions/loginaction">
public LinkTool setForward(String forward)
Returns a copy of this link with the given forward name
converted into a server-relative path (as per configuration
in struts-config.xml).
Example:
<a href='$link.setForward("home")'>Home</a>
produces something like
<a href="/myapp/templates/index.vm">Home</a>
public LinkTool setAbsolute(String path)
Returns a copy of this link with the specified context-relative
path converted to an absolute path.
Example:
<a href='$link.setAbsolute("/templates/login/index.vm")'></a>
produces something like
<a href="http://myserver:port/myapp/templates/login/index.vm">Login Page</a>
public LinkTool addQueryData(String key, Object value)
Adds a key/value pair to the query data. This returns a new LinkTool
containing both a copy of this LinkTool's query data and the new data.
This makes repeated use in Velocity templates much easy. Query data is
URL encoded before it is appended.
public String getPath()
Returns the current path set for this link as set by
the methods setPath(), setAction(), setForward() or
setAbsolute(). Any conversions have been applied.
public String getQueryData()
Returns this link's query data as an url-encoded string
e.g. "key=value&foo=this+is+encoded".
public String getServerPath()
Returns the server & context url, e.g. "http://myserver.net/myapp".
public String getBaseRef()
Returns a full reference to the template without any query data.
e.g. "http://myserver.net/myapp/stuff/View.vm"
NOTE! This returns that base ref of the last request. This will NOT
represent any path or query data set for this LinkTool! A typical
application of this is with the HTML base tag.
e.g. <base href="$tool.baseRef">
public String toString()
Returns the full URL that's been built with this tool
e.g. "http://myserver.net/myapp/stuff/View.vm?id=42&type=blue"
Typically it is not necessary to call this method explicitely.
Velocity will call the toString() method automatically to
obtain a representable version of this object.
1.2) MessageTool
----------------
Struts supports internationalized messages. The messages are stored
in NVP files by language. The following methods operate on these message
files.
Class: org.apache.velocity.tools.struts.MessageTool
Recommended name in context: $msg
Methods:
public String get(String key)
Return the localized message for the specified key.
Example:
<input type="submit" name="newbutton" value='$msg.newpatient'/>
looks up a message with key="newpatient" and renders something like
<input type="submit" name="newbutton" value='Register new patient'/>
public String get(String key, Object args[])
Same as above, but supports parametric message strings, for example
for a message resource defined as:
warning.quota=Your mail folder is {0} MB above the limit of {1} MB.
{0} and {1} are replaced by the values passed. Up to five replacement
parameters are supported.
public boolean exists(String key)
Return true if a message string for the specified message key
is present for the user's Locale.
public Locale getLocale()
Retrieve and return the Locale for the user. If a Locale is
not found, the default locale is returned. Note: Struts' locale
is not request.getLocale().
1.3) ErrorsTool
---------------
Errors may stem from the validation of a submitted form or from the
processing of the request. If there are errors, they are made available
to the view to render. A few aspects about errors are:
o Error message strings are looked up in the message resources. Support
for internationalized messages is provided.
o Error messages can have up to five replacement parameters.
o Errors have a property that marks them as either 'global errors' (meaning
that they apply to an entire form) or 'specific errors' (meaning that they
are specific to one of the form elements). This allows to position error
messages precisely where the error occurred on the form.
Class: org.apache.velocity.tools.struts.ErrorsTool
Recommended name in context: $errors
Methods:
public boolean exist()
Returns true if there are errors queued, otherwise false.
public int getSize()
Returns the number of error messages queued.
public int getSize(String property)
Returns the number of error messages queued for a particular property.
public HashMap getAll()
Returns a HashMap of localized error messages for all errors queued.
A typical application would use a script similar to the following to
output the error messages.
Example:
<ul>
#foreach ($e in $errors.all )
<li>$e</li>
#end
</ul>
public HashMap get(String property)
Same as above but only the error messages for a particular property
are retrieved and returned.
Note:
To output a fully formatted error message similar to what the JSP tag
html:errors does, it is recommended to utilize a VelociMacro. The
following VelociMacro produces the same output as the html:errors JSP
tag:
#macro ( errorMarkup )
#if ($errors.exist )
<ul>
#foreach ($e in $errors.all )
<li>$e</li>
#end
</ul>
#end
#end
The following macro generates error markup for a particular property:
#macro ( errorMarkup $property)
#if ($errors.exist($property) )
<ul>
#foreach ($e in $errors.get($property) )
<li>$e</li>
#end
</ul>
#end
#end
1.4 ActionMessagesTool
----------------------
Action messages generalize the concept of error messages to include
all kinds of messages that an action might want to pass to the view.
So, every error message is an action message, but not every action
message is an error message. The set of methods are the same as for
handling error messages. Note: Action messages are not to be confused
with the message resources used for internationalized output.
Action messages are new in Struts 1.1. This tool will not work with
Struts versions prior to 1.1.
Class: org.apache.velocity.tools.struts.ActionMessagesTool
Recommended name in context: $actionmsgs
Methods:
public boolean exist();
Returns true if there are messages (stored under MESSAGE_KEY) OR
errors (stored under ERROR_KEY) queued, otherwise false.
public int getSize();
Returns the total number of messages and errors (stored under MESSAGE_KEY
and ERROR_KEY).
public int getSize(String property);
Returns the total number of messages and errors (stored under MESSAGE_KEY
and ERROR_KEY) for the specified property.
public HashMap getAll();
Returns a HashMap of localized messages and error messages (stored under
MESSAGE_KEY and ERROR_KEY).
public HashMap get(String property);
Same as above but only messages and error for a particular property
are returned.
Examples:
To output all queued action messages:
#if ($actionmsgs.exist() )
<p>There are $actionmsgs.size() messages.</p>
<ul>
#foreach ($m in $actionmsgs.all() )
<li>$m</li>
#end
</ul>
#end
To output all queued action messages for a specific property 'password':
#if ($actionmsgs.exist("password") )
<ul>
#foreach ($m in $actionmsgs.password )
<li>$m</li>
#end
</ul>
#end
1.5) FormTool
-------------
Struts has support to parse incoming HTTP requests and populate a Java bean
with the submitted request parameters. The Struts config file defines what
bean class to use for a particular request. Additionally, a hook allows the
application developer to include form validation code. The form bean is passed
around as an attribute to the servlet request.
FormTool provides miscellaneous methods to work with forms.
Class: org.apache.velocity.tools.struts.FormTool
Recommended name in context: $form
Methods:
public ActionForm getBean()
Retrieve and return the form bean associated with this request. The
ActionForm is typically needed by view designers to populate HTML form
elements with values.
Note that the form bean is available in the Velocity context by default
under the name defined in the Struts configuration. If the form bean
is used repeatedly, it is recommended to create a local variable pointing
to the bean rather than calling getBean() on each access.
Example:
#set ($defaults = $form.bean)
<input type="text" name="username" value="$defaults.username">
public String getCancelName()
Retrieve and return the magic name that is to be used for cancel buttons
in HTML forms. If this magic name is used for cancel buttons, the
automatic form validation is skipped if the cancel button caused the form
submission. If automatic form validation is not used, this is irrelevant.
public String getToken()
Retrieve and return the transaction control token for this session.
2) Auto-Population of the Velocity Context
------------------------------------------
VelocityViewServlet is the servlet class that is used with Struts applications
to process Velocity templates. It can be considered the equivalent of the
JSPServlet for Velocity templates.
VelocityViewServlet automatically populates the Velocity context with several
objects that are relevant to the template designer. This includes for example
servlet request, servlet response, servlet context, etc. This section documents
all objects that are made available automatically in the Velocity context. This
is part of the view API that is available to the template designer.
Strictly speaking, auto-population of the Velocity context is not specific to
Struts. It can be used with any servlet-based application. I describe it here,
because Struts is the first framework that makes use of VelocityViewServlet and
this information has not been documented anywhere yet. It will be part of a
user guide in the future.
2.1) Request, Response, Session, Servlet Context
------------------------------------------------
The following objects are added to the Velocity context:
Name Class / Interface
--------------|----------------------------------------------------------------
$request javax.servlet.http.HttpServletRequest
$session javax.servlet.http.HttpSession
$response javax.servlet.http.HttpServletResponse
$application javax.servlet.ServletContext
2.2) Attributes of Request, Session and Servlet Context
-------------------------------------------------------
The classes HttpServletRequest, HttpSession and ServletRequest support
attributes (see methods getAttribute(), setAttributes() of these
classes). This allows to associated arbitrary objects with the request,
session or servlet context. These attributes have been foreseen to provide
the application developer a mechanism to pass information between servlets.
Struts and other web frameworks make heavy use of these attributes to
pass data from the controller to the view of an application.
VelocityViewServlet makes all attributes of request, session and servlet
context automatically available as variables in the Velocity context. The
key of an attribute is used as the name of the variable in the Velocity
context.
Since request attributes, session attributes and servlet context attributes
each have their own name space, name clashes are possible. The following
lookup priorities apply when accessing a variable:
1) Search local Velocity context
2) Search request attributes
3) Search session attributes
4) Search servlet context attributes
Example:
In Struts action class:
ArrayList[] orders = <result of DB lookup>
request.setAttribute("orders", orders);
...
In Velocity template:
## $orders is automatically available in the context
#foreach ($o in $orders)
$o.amount: $o.text
#end
-------------------------------------------------------------------------------
Gabriel Sidler
Software Engineer, Eivycom GmbH, Zurich, Switzerland
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VelTools] Velocity View API for Struts [Phase 2]
Posted by Nathan Bubna <na...@esha.com>.
Gabriel Sidler wrote:
> Nathan Bubna wrote:
> [..]
> > > Any better ideas are highly welcome.
> >
> > did you give any thought to my suggestion of renaming the context key
for
> > MessageTool instead of the one for ActionMessagesTool? my suggestion
was to
> > change '$msg' to '$i18n' or '$text' (or something better if someone
thinks
> > of one) and to let ActionMessagesTool keep '$msgs'.
> >
> > whaddaya think?
>
> Yes, I gave it some thought. The MessageTool will easily be the most used
> context tool in any Struts application. The correspoding JSP tag is
<bean:message .../>
> In contrast, ActionMessages is new. Noboby is using it yet. So I'd rather
come up
> with some creative naming for action messages instead of for the well
established
> message resources.
good point.
> I actually begin to like your proposed $actionmsgs. Message tool ($msg)
typically
> will be used many times a page. Keeping it short is good. $actionmsgs
typically is
> used once per template. Having a slightly longer name is not an issue. The
> potential for confusion between $msg and $actionmsgs is small.
even better point.
> I propose that we go with these names for now. We can always come back and
> change later.
very true.
+1
Nathan Bubna
nathan@esha.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VelTools] Velocity View API for Struts [Phase 2]
Posted by Ted Husted <hu...@apache.org>.
The messages and errors are very closely related. The messages tag and
corresponding queue were really only invented to maintain backward
compatibility. We didn't want to change the behavior of the errors tag,
so we created another. It also gives people a way to send two streams of
application-generated messages to a page, one for errors and one for
confirmations.
You might want to think of them as queues or batches.
It is also important to note that the ActionMessage has been in the
nightly build for some time, and many people *are* actually using the
night build in production.
Also, the errors and messages queues have options that associate a
particular message with a particular property, and people often use this
feature to display the error next to the property, rather than in a
lump.
-Ted.
Gabriel Sidler wrote:
> Yes, I gave it some thought. The MessageTool will easily be the most used
> context tool in any Struts application. The correspoding JSP tag is <bean:message .../>
> In contrast, ActionMessages is new. Noboby is using it yet. So I'd rather come up
> with some creative naming for action messages instead of for the well established
> message resources.
>
> I actually begin to like your proposed $actionmsgs. Message tool ($msg) typically
> will be used many times a page. Keeping it short is good. $actionmsgs typically is
> used once per template. Having a slightly longer name is not an issue. The
> potential for confusion between $msg and $actionmsgs is small.
>
> I propose that we go with these names for now. We can always come back and
> change later.
>
> Gabe
>
> >
> > Nathan Bubna
> > nathan@esha.com
> >
> > --
> > To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> > For additional commands, e-mail: <ma...@jakarta.apache.org>
>
> --
> Gabriel Sidler
> Software Engineer, Eivycom GmbH, Zurich, Switzerland
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VelTools] Velocity View API for Struts [Phase 2]
Posted by Gabriel Sidler <si...@teamup.ch>.
Nathan Bubna wrote:
[..]
> > Any better ideas are highly welcome.
>
> did you give any thought to my suggestion of renaming the context key for
> MessageTool instead of the one for ActionMessagesTool? my suggestion was to
> change '$msg' to '$i18n' or '$text' (or something better if someone thinks
> of one) and to let ActionMessagesTool keep '$msgs'.
>
> whaddaya think?
Yes, I gave it some thought. The MessageTool will easily be the most used
context tool in any Struts application. The correspoding JSP tag is <bean:message .../>
In contrast, ActionMessages is new. Noboby is using it yet. So I'd rather come up
with some creative naming for action messages instead of for the well established
message resources.
I actually begin to like your proposed $actionmsgs. Message tool ($msg) typically
will be used many times a page. Keeping it short is good. $actionmsgs typically is
used once per template. Having a slightly longer name is not an issue. The
potential for confusion between $msg and $actionmsgs is small.
I propose that we go with these names for now. We can always come back and
change later.
Gabe
>
> Nathan Bubna
> nathan@esha.com
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
Gabriel Sidler
Software Engineer, Eivycom GmbH, Zurich, Switzerland
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Velocity View API for Struts [Phase 2]
Posted by Nathan Bubna <na...@esha.com>.
Gabriel Sidler said:
> $actionmsgs
this is my favorite of the suggestions... but what about keeping '$msgs'
and changing '$msg' to something else? (see below for more on that)
> $meldungen - switching language adds a new dimension :-)
heh. that's cool.
> I guess my favorite so far is $amessages. It's somewhat special, so people
will take
> note. Once they get the meaning of the word it should be easy to remember.
Few
> developers use action messages at the moment.
it's not bad, but i don't think we need 'messages' when 'msgs' says enough,
and i like 'action' better than 'a', because it will be clearer that we mean
"action messages" rather than "a messages".
> The class name of the tool is not sensitive, because it's used once. So, I
would
> propose:
>
> org.apache.velocity.tools.struts.ActionMessagesTool
+1
> Any better ideas are highly welcome.
did you give any thought to my suggestion of renaming the context key for
MessageTool instead of the one for ActionMessagesTool? my suggestion was to
change '$msg' to '$i18n' or '$text' (or something better if someone thinks
of one) and to let ActionMessagesTool keep '$msgs'.
whaddaya think?
Nathan Bubna
nathan@esha.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Velocity View API for Struts [Phase 2]
Posted by Gabriel Sidler <si...@teamup.ch>.
Nathan Bubna wrote:
[..]
> > Tool 4) Action Messages
> > -----------------------
> >
> > Class: org.apache.velocity.tools.struts.MessagesTool
> >
> > Recommended name in context: msgs
> >
> > Methods:
> >
> > public boolean exists();
> >
> > public int getSize();
> >
> > public int getSize(String property);
> >
> > public HashMap getAll();
> >
> > public HashMap get(String property);
>
> ok, now i'm confused. we can't have two classes named
> org.apache.velocity.tools.struts.MessagesTool and i don't like the idea of
> having both a $msg and $msgs in the context. that's just asking for trouble.
One of the remaining issues was to find a clever context name for Action messages
to avoid confusion with the message resources (named $msg in the context).
Some brainstorming yielded:
$messages - easily confused with $msg
$amessages
$actionmessages - too long
$amsg
$amsgs
$am
$actionmsgs
$actionmsg
$actionm
$meldungen - switching language adds a new dimension :-)
$infos
$notes
I guess my favorite so far is $amessages. It's somewhat special, so people will take
note. Once they get the meaning of the word it should be easy to remember. Few
developers use action messages at the moment.
The class name of the tool is not sensitive, because it's used once. So, I would
propose:
org.apache.velocity.tools.struts.ActionMessagesTool
Any better ideas are highly welcome.
Gabe
--
Gabriel Sidler
Software Engineer, Eivycom GmbH, Zurich, Switzerland
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Velocity View API for Struts [Phase 2]
Posted by Nathan Bubna <na...@esha.com>.
> Jim Seach wrote:
> [...]
> > Since it's exposing the form values, why not use:
> >
> > public ActionForm getValue()
> >
> > This might be more descriptive. we are exposing it in the view, and
> > designers might not have a clue what a JavaBean is. That would give
> > us:
> >
> > <input type="text" name="username" value="$form.value.username">
>
> Well, I am not fully sold on it.
me neither. it feels like a very misleading name to me.
> How about:
>
> public ActionForm getValues() // note the 's' to emphasize that
> // we retrieve multiple values
definitely better than getValue(). i could live with this i guess, but i
still don't feel it is quite as accurately descriptive as getBean(). we
are after all returning a single object that is not a collection (List, Map,
array, etc). I don't want designers to get the idea that they could do a
#foreach on it. i do see that $form.values.username could be more
comfortable to a designer unfamiliar with the concept of javabeans, but i
don't think it's a big issue. besides, even struts/jsp uses the term 'bean'
in its tags. i doubt any designers will struggle with it.
> public ActionForm getFormBean()
blech. redundancy. -1
> Or, we rename the $form tool to $formtool and name the method getForm()
> This would make: $formtool.form to access the form.
blech again. -1
> Or, we just keep the getBean() Method. It should be easy for designers
> to get the concept.
+1 (but i can live with getValues() if i'm outnumbered on this one.)
Nathan Bubna
nathan@esha.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Velocity View API for Struts [Phase 2]
Posted by Gabriel Sidler <si...@teamup.ch>.
Jim Seach wrote:
[...]
> Since it's exposing the form values, why not use:
>
> public ActionForm getValue()
>
> This might be more descriptive. we are exposing it in the view, and
> designers might not have a clue what a JavaBean is. That would give
> us:
>
> <input type="text" name="username" value="$form.value.username">
Well, I am not fully sold on it.
How about:
public ActionForm getValues() // note the 's' to emphasize that
// we retrieve multiple values
public ActionForm getFormBean()
Or, we rename the $form tool to $formtool and name the method getForm()
This would make: $formtool.form to access the form.
Or, we just keep the getBean() Method. It should be easy for designers
to get the concept.
I need to think a little more about it.
> > Note that the form bean is available in the request or session
> > attributes already. getBean() isn't really necessary. It just a
> > little
> > convenience. I kind of like it because if there is a method in the
> > API
> > this makes it explicit how to get a hold of the form bean.
> >
>
> As you say, it's just a convenience, but what a convenient one! I like
> it!
The form is in the context and can be accessed with the name that was
defined in struts-config.xml, eg
<input type="text" name="username" value="$loginForm.username">
So, the convenience offered by the getBean() method is really very minor.
Gabe
>
> Jim Seach
>
> __________________________________________________
> Do You Yahoo!?
> Yahoo! Sports - Coverage of the 2002 Olympic Games
> http://sports.yahoo.com
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
Gabriel Sidler
Software Engineer, Eivycom GmbH, Zurich, Switzerland
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Velocity View API for Struts [Phase 2]
Posted by Jim Seach <jw...@yahoo.com>.
--- Gabriel Sidler <si...@teamup.ch> wrote:
> Nathan Bubna wrote:
> >
> I just realize that getForm() is the wrong name anyway. What we are
> asking
> for the not really the form but rather the bean that contains the
> values
> entered/to be entered into the form. There may be multiple forms per
> template.
> So, getBean() would probably be a more accurate naming. How about
> this:
>
> public ActionForm getBean()
>
> In a template this would look like this:
>
> <input typ="text" name="username" value="$form.bean.username">
>
> For efficiency the recommended use should be:
>
> #set ($mybean = $form.bean)
> <input typ="text" name="username" value="$mybean.username">
> ...
Since it's exposing the form values, why not use:
public ActionForm getValue()
This might be more descriptive. we are exposing it in the view, and
designers might not have a clue what a JavaBean is. That would give
us:
<input type="text" name="username" value="$form.value.username">
>
> Note that the form bean is available in the request or session
> attributes already. getBean() isn't really necessary. It just a
> little
> convenience. I kind of like it because if there is a method in the
> API
> this makes it explicit how to get a hold of the form bean.
>
As you say, it's just a convenience, but what a convenient one! I like
it!
>
>
> Gabe
>
Jim Seach
__________________________________________________
Do You Yahoo!?
Yahoo! Sports - Coverage of the 2002 Olympic Games
http://sports.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Velocity View API for Struts [Phase 2]
Posted by Nathan Bubna <na...@esha.com>.
> > > Tool 4) Action Messages
> > > -----------------------
> > >
> > > Class: org.apache.velocity.tools.struts.MessagesTool
> > >
> > > Recommended name in context: msgs
[snip]
> Actually the classes are not the same. It's
> org.apache.velocity.tools.struts.MessageTool and
> org.apache.velocity.tools.struts.MessagesTool
oops. :-) see! i'm confused already!
> But I completely agree that it's confusing. I just didn't have a
> a good solution and was hoping that someone has. :-)
yeah i was hoping the same. i'll try and think about it myself too...
> In Struts the corresponding JSP tags are
>
> <html:messages ... />
> <bean:message ... />
>
> ActionMessage is the super class of ActionError. It is supposed to
> generalize the concept of error messages to all possible types of
> messages an action might want to make available to the view, like
> for example notfifications, warnings, confirmations, etc. I believe
> ActionMessage is new in the upcoming 1.1 release.
>
> MessageResource (#2) is entirely different dispite the closeness in
> nameing. It's deals with internationalized strings from a bundle of
> NVP files.
>
> So, the challenge is to find a good naming to make the difference
> between action messages and message resources clear.
yeah, i think you're right. most of my complaint was with the naming
similarities... although the relationship and functional similarity to
ActionErrors/ErrorsTool does make me wonder if there isn't some way to
connect/combine those with ActionMessages. but, again, it's still fuzzy to
me.
so i guess i'd have to say that if 'MessagesTool' does stay on its own, then
i'd prefer naming the class ActionMessagesTool and finding some sufficiently
different suggestions for context keys. $msg and $msgs will not do. hmm.
maybe it's MessageTool's key that needs changed... what about $i18n instead
of $msg? it's not as pretty, but it's a fairly accurate description.
> > > Tool 5) Action Form
> > > -------------------
> > >
> > > Class: org.apache.velocity.tools.struts.FormTool
[snip]
> That's an interesting idea, but I think it would be confusing. $form would
> look like the form bean itself, but it isn't. It is really a tool that
> provides methods to one *or* multiple forms in a template.
multiple forms, eh? hmm. how would that work with getForm() or getBean()?
anyway, yeah, i agree the get(String s) trick would be misleading. (but
still nifty... :-))
> I just realize that getForm() is the wrong name anyway. What we are asking
> for the not really the form but rather the bean that contains the values
> entered/to be entered into the form. There may be multiple forms per
template.
> So, getBean() would probably be a more accurate naming. How about this:
>
> public ActionForm getBean()
+1 yeah, that's clear and accurate.
> Note that the form bean is available in the request or session
> attributes already. getBean() isn't really necessary. It just a little
> convenience. I kind of like it because if there is a method in the API
> this makes it explicit how to get a hold of the form bean.
heh. that's true... still, i agree we should have this.
Nathan Bubna
nathan@esha.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Velocity View API for Struts [Phase 2]
Posted by Gabriel Sidler <si...@teamup.ch>.
Nathan Bubna wrote:
>
> hey Gabe, good stuff. comments inline...
I'm glad we are getting closer to a good solution.
> > Tool 3) Error Handling
> > ----------------------
[...]
> +1 i like this much better than the way i did it. only one suggestion...
> call the existence method 'exist()' instead of 'exists()'. it's better
> grammar that way.
Good point. Will integrate into the next version.
> > Tool 4) Action Messages
> > -----------------------
> >
> > Class: org.apache.velocity.tools.struts.MessagesTool
> >
> > Recommended name in context: msgs
> >
> > Methods:
> >
> > public boolean exists();
> >
> > public int getSize();
> >
> > public int getSize(String property);
> >
> > public HashMap getAll();
> >
> > public HashMap get(String property);
>
> ok, now i'm confused. we can't have two classes named
> org.apache.velocity.tools.struts.MessagesTool and i don't like the idea of
> having both a $msg and $msgs in the context. that's just asking for
> trouble. of course, i'd like to propose some solution, but i'm still very
> hazy on this whole ActionMessages vs. ActionErrors deal, so i'm not much use
> here at the moment. is there some way we can combine this into the
> ErrorsTool or maybe the MessageTool in #2?
Actually the classes are not the same. It's
org.apache.velocity.tools.struts.MessageTool and
org.apache.velocity.tools.struts.MessagesTool
But I completely agree that it's confusing. I just didn't have a
a good solution and was hoping that someone has. :-)
In Struts the corresponding JSP tags are
<html:messages ... />
<bean:message ... />
ActionMessage is the super class of ActionError. It is supposed to
generalize the concept of error messages to all possible types of
messages an action might want to make available to the view, like
for example notfifications, warnings, confirmations, etc. I believe
ActionMessage is new in the upcoming 1.1 release.
MessageResource (#2) is entirely different dispite the closeness in
nameing. It's deals with internationalized strings from a bundle of
NVP files.
So, the challenge is to find a good naming to make the difference
between action messages and message resources clear.
I need to think more about this. Maybe Ted has a suggestion?
> > Tool 5) Action Form
> > -------------------
> >
> > Class: org.apache.velocity.tools.struts.FormTool
> >
> > Recommended name in context: form
> >
> > Methods:
> >
> > public ActionForm getForm() // was getActionForm()
> >
> > public String getCancelName() // was getCancelMagicName()
> >
> > public String getToken()
>
> +1 for the most part...
> i like grouping this stuff together. i'm just not thrilled by the syntax.
> $form.token and $form.cancelName is good, but $form.form is a little
> redundant. here's a crazy idea for you... what would you think about
> giving FormTool a get(String s) method that would then do a little
> velocity-style reflection on the ActionForm itself? then we could do
> $form.foo instead of $form.form.foo. i'm not sure i'm sold on the idea
> myself just yet, but it could be fun...
That's an interesting idea, but I think it would be confusing. $form would
look like the form bean itself, but it isn't. It is really a tool that
provides methods to one *or* multiple forms in a template.
I just realize that getForm() is the wrong name anyway. What we are asking
for the not really the form but rather the bean that contains the values
entered/to be entered into the form. There may be multiple forms per template.
So, getBean() would probably be a more accurate naming. How about this:
public ActionForm getBean()
In a template this would look like this:
<input typ="text" name="username" value="$form.bean.username">
For efficiency the recommended use should be:
#set ($mybean = $form.bean)
<input typ="text" name="username" value="$mybean.username">
...
Note that the form bean is available in the request or session
attributes already. getBean() isn't really necessary. It just a little
convenience. I kind of like it because if there is a method in the API
this makes it explicit how to get a hold of the form bean.
Gabe
>
> Nathan Bubna
> nathan@esha.com
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
Gabriel Sidler
Software Engineer, Eivycom GmbH, Zurich, Switzerland
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Velocity View API for Struts [Phase 2]
Posted by Nathan Bubna <na...@esha.com>.
hey Gabe, good stuff. comments inline...
> --------------------------------------------------------------------------
-----
> PROPOSAL
>
> Context Tools for Velocity for Struts, Phase 2
> ----------------------------------------------
>
>
> Tool 1) Handling of URLs
> ------------------------
sounds good! +1
>
> Tool 2) Message Resources
> -------------------------
>
> Class: org.apache.velocity.tools.struts.MessageTool
>
> Recommended name in context: msg
i like this a lot! ...but i'm not sure how this works
with/against/over/around/under/through the ActionMessages stuff in #4. see
below.
> Tool 3) Error Handling
> ----------------------
>
> Class: org.apache.velocity.tools.struts.ErrorsTool
>
> Recommended name in context: errors
>
> Methods:
>
> public boolean exists()
>
> public int getSize()
>
> public int getSize(String property)
>
> public HashMap getAll()
>
> public HashMap get(String property)
+1 i like this much better than the way i did it. only one suggestion...
call the existence method 'exist()' instead of 'exists()'. it's better
grammar that way.
> Tool 4) Action Messages
> -----------------------
>
> Class: org.apache.velocity.tools.struts.MessagesTool
>
> Recommended name in context: msgs
>
> Methods:
>
> public boolean exists();
>
> public int getSize();
>
> public int getSize(String property);
>
> public HashMap getAll();
>
> public HashMap get(String property);
ok, now i'm confused. we can't have two classes named
org.apache.velocity.tools.struts.MessagesTool and i don't like the idea of
having both a $msg and $msgs in the context. that's just asking for
trouble. of course, i'd like to propose some solution, but i'm still very
hazy on this whole ActionMessages vs. ActionErrors deal, so i'm not much use
here at the moment. is there some way we can combine this into the
ErrorsTool or maybe the MessageTool in #2?
> Tool 5) Action Form
> -------------------
>
> Class: org.apache.velocity.tools.struts.FormTool
>
> Recommended name in context: form
>
> Methods:
>
> public ActionForm getForm() // was getActionForm()
>
> public String getCancelName() // was getCancelMagicName()
>
> public String getToken()
+1 for the most part...
i like grouping this stuff together. i'm just not thrilled by the syntax.
$form.token and $form.cancelName is good, but $form.form is a little
redundant. here's a crazy idea for you... what would you think about
giving FormTool a get(String s) method that would then do a little
velocity-style reflection on the ActionForm itself? then we could do
$form.foo instead of $form.form.foo. i'm not sure i'm sold on the idea
myself just yet, but it could be fun...
Nathan Bubna
nathan@esha.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Velocity View API for Struts [Phase 2]
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 2/20/02 6:53 AM, "Gabriel Sidler" <si...@teamup.ch> wrote:
> "Geir Magnusson Jr." wrote:
>>
>> By my clock, Phase 1 had a review period of 41 minutes. :)
>
Sorry. 39 minutes. Wouldn't want to tarnish your reputation.
> Our slogan is: "Speed innovation to market" :-)
Why not make it " Speed innovation market" and save some time there too...
> Seriously, the latest draft 0.3 of phase 1 includes only minor
> changes on the handling of URLs. I documented what I believe
> is the latest concensus.
>
> I put out a proposal on phase 2 to speed up the process a little
> bit. Don't let this stop you from commenting on phase 1. We'll
> make iterations of necessary.
I'm just so far behind... Don't let my concerns stop you, but others might
want a read :)
Speed innovation market!
geir
> Gabe
>
>
>>
>> I'll try to catch up...
>>
>> On 2/20/02 6:40 AM, "Gabriel Sidler" <si...@teamup.ch> wrote:
>>
>>> Hi,
>>> based on the output of phase 1 I put together a proposal on how to
>>> divide the functionality into context tools and how to name the methods.
>>
>> [SNIP]
>>
>> --
>> Geir Magnusson Jr. geirm@optonline.net
>> System and Software Consulting
>> "He who throws mud only loses ground." - Fat Albert
>>
>> --
>> To unsubscribe, e-mail:
>> <ma...@jakarta.apache.org>
>> For additional commands, e-mail:
>> <ma...@jakarta.apache.org>
>
> --
> Gabriel Sidler
> Software Engineer, Eivycom GmbH, Zurich, Switzerland
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
"They that can give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety." - Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Velocity View API for Struts [Phase 2]
Posted by Gabriel Sidler <si...@teamup.ch>.
"Geir Magnusson Jr." wrote:
>
> By my clock, Phase 1 had a review period of 41 minutes. :)
Our slogan is: "Speed innovation to market" :-)
Seriously, the latest draft 0.3 of phase 1 includes only minor
changes on the handling of URLs. I documented what I believe
is the latest concensus.
I put out a proposal on phase 2 to speed up the process a little
bit. Don't let this stop you from commenting on phase 1. We'll
make iterations of necessary.
Gabe
>
> I'll try to catch up...
>
> On 2/20/02 6:40 AM, "Gabriel Sidler" <si...@teamup.ch> wrote:
>
> > Hi,
> > based on the output of phase 1 I put together a proposal on how to
> > divide the functionality into context tools and how to name the methods.
>
> [SNIP]
>
> --
> Geir Magnusson Jr. geirm@optonline.net
> System and Software Consulting
> "He who throws mud only loses ground." - Fat Albert
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
Gabriel Sidler
Software Engineer, Eivycom GmbH, Zurich, Switzerland
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Velocity View API for Struts [Phase 2]
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
By my clock, Phase 1 had a review period of 41 minutes. :)
I'll try to catch up...
On 2/20/02 6:40 AM, "Gabriel Sidler" <si...@teamup.ch> wrote:
> Hi,
> based on the output of phase 1 I put together a proposal on how to
> divide the functionality into context tools and how to name the methods.
[SNIP]
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
"He who throws mud only loses ground." - Fat Albert
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>