> Nathan, thanks for the feedback. I have a few follow up questions. Would
> you please clarify.
will do. read down.
...
> > 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.
sweet.
> > > public int errorSize()
> > -1
> >
> > > public int errorSize(String property)
> >
> > -1
> >
...
> 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?
that's a good point. i'm still not thrilled to have them, but i think
that's just because i can't see myself using them independently of calling
errors(), but i can imagine scenarios where others might wish to do so. so
if you see need for them, i'll back you up on it. +1
> >
> > > 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?
yeah. i'm not very into the ErrorMap/PREFIX hack myself. i basically said
as much in my comments in MessageTool. You also make a good point about
having people being able to do something like:
#foreach($e in $tool.errors) $e <br> #end
that wouldn't work on a Map. we'd have to use $tool.errors.values()
instead. now, i know that's not a big difference, but we probably do better
to avoid it. if i have to choose between a Map and a Set or List, i'd
choose Map, but perhaps a custom class (mabye internal, maybe not) is in
order. If I remember correctly, it's iterator() that Velocity looks for
when trying to loop over an object. so something like this should handle
both cases:
public class ErrorMessages
{
private HashMap map;
public ErrorMessages()
{
map = new HashMap();
}
public void put(String key, String value)
{
map.put(key, value);
}
public String get(String key)
{
return (String)map.get(key);
}
public Iterator iterator()
{
return map.values().iterator();
}
}
but this is untested and off the top of my head, what do you think?
> > > 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?
hmm. i guess i'm not totally clear on how the header and footer would be
used. does every individual error message get wrapped by the header and
footer or does the header/footer wrap all the messages as a group?
actually... i don't think it makes a difference. i think i just went -1 on
these methods. unless i'm missing something, i don't see how this
errorMarkup stuff is at all necessary. if the header and footer wrap all
the messages as a group, people should just do something like:
$msg.get('error.header')
#foreach( $e in $tool.errors )
$e <br>
#end
$msg.get('error.footer')
of if wrapping each individually, something like:
#foreach( $e in $tool.errors )
$msg.get('error.header')
$e <br>
$msg.get('error.footer')
#end
either way, the more i think about it, the more i think this whole
'errorMarkup' idea is rendered completely unnecessary by Velocity. or am i
missing something?
...
Nathan Bubna
[EMAIL PROTECTED]
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
