Sounds like a good plan so far Gabriel.
Since we're in phase 1, i guess this is the place for me to comment on the
methods being discussed and ignore the question of signatures and grouping
for the time being. :) As such, this will probably the phase where i have
the least to say. anyway, here's my thoughts.
> Category: Handling of URLs
> --------------------------
>
> public String actionURL(String action)
+1
> public String forwardURL(String forward)
+1
> public String forwardURL(String target, String parameters)
>
> Same as above but appends the string parameters are the end of the
URL.
> Example:
> <a href='$tool.forwardURL("home", "frames=no&style=simple")'>Home</a>
> produces something like
> <a href="/myapp/templates/index.vm?frames=no&style=simple">
-1
i think it would be far better to put the adding of query data in a separate
method like the LinkTool i wrote does. (of course, i don't think that
LinkTool is good for the Struts/Velocity project because it lacks the
methods above). I have several reasons for wanting this:
1. elegance. imo this doesn't have it. (ok, so that's pretty subjective,
but the next one is serious.)
2. URL encoding. I wouldn't want a forward(target, params) method to have
to parse and then encode the values, and i certainly don't want to have to
do the encoding manually in templates.
3. what if you want to append query data to an action or absolute URL?
then we'd have to have xxxx(target, params) methods for those as well.
So, i would prefer to see $urltool.forward(foo) and friends return a
instance of urltool so we can then call an addQueryData(key, value) on it.
> public String absoluteURL(String path)
+1
> public String baseRef()
+1
> Category: Messages
> ------------------
>
> public String message(String key)
+1
> public String message(String key, Object args[])
+1
> public boolean isMessage(String key)
+1
> Category: Error Handling
> ------------------------
>
> public boolean hasErrors()
+1
> public int errorSize()
-1
> public int errorSize(String property)
-1
Ok, here's my thoughts on these last two...
It's not that i object to having the functionality. We DO need that, i'm
just not convinced these are methods we need to clutter up the tool API
with. IMO what we should aim for is to have the getErrors() or errors() or
whatever methods return an object that has a size() method. That way we can
just use $tool.errors.size() This would provide equal functionality and
would keep needless clutter out of the tool.
> public String[] errors()
+1 on the functionality. (but let's not return a String[]. I'd really like
to see something closer to what MessageTool does here.)
> public String[] errors(String property)
+1 (same comment as above)
> public String errorMarkup()
+0 i'm not thrilled by it, but as long as all the actual markup is pulled
from properties files under the view designer's control, i won't object.
But if i see ANY html or other markup stuck in the java, then i am a -137 on
it.
> public String errorMarkup(String property)
+0 (same as above)
> Category: ActionForm
> --------------------
>
> public ActionForm getActionForm()
+1
> Category: Miscellaneous
> -----------------------
>
> public Locale getLocale()
+1
good stuff Gabriel, thanks for doing all this.
Nathan Bubna
[EMAIL PROTECTED]
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
