Nathan, thanks for the feedback. I have a few follow up questions. Would
you please clarify.
Nathan Bubna wrote:
>
> > 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.
Ok, makes sense. I'll integrate that in the next draft.
> > 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.
I saw that in your MessageTool.java and I basically agree. The reason I left these
two methods anyway was that errors() is a fairly expensive method whereas
errorSize() is very cheap. errors() looks up all the message strings and
does the parametric replacement operations. That's a lot of overhead if you
just need the number of messages.
Makes sense?
>
> > 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.)
In your MessageTool you defined an internal class ErrorMap that is returned. I didn't
see the value of doing this. Can you elaborate on that? Specifically I felt that
the introduction of the PREFIX is too much magic behavior. It makes assumptions about
the
keys of the error messages (in an application that I'm currently working on all
errors tags are numbered). I believe the typical way people would use the errors()
method is something like:
<ul>
#foreach ($e in $struts.errors())
<li>$e</li>
#end
</ul>
What usage scenario did you have in mind?
I propose this:
public HashMap errors()
public HashMap errors(String property)
It is close to what you had but avoids the prefix magic. Agree?
> > 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.
I fully agree with you here regarding the HTML in Java. That won't happen.
An alternative could be that we allow footer and header as parameters. That
would be more explicit and less magic.
public String errorMarkup(String footer, String header)
What is better?
As soon as I have your feedback I draft up a revised version of the API and send
it around.
Gabe
--
Gabriel Sidler
Software Engineer, Eivycom GmbH, Zurich, Switzerland
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
