i dont like what you proposed. i dont think we need the extra added
complexity.
maybe what we can do is refactor our feedback message system to work with
Object instead of String.
taking your specific example, what that will mean is that we would keep
IValidationError object instead of translating it into a string.
that way you can store whatever you want and create your own feedbackpanels
that render it in different ways.
how does that sound?
-Igor
On 10/4/06, Ernesto Reinaldo Barreiro <[EMAIL PROTECTED]> wrote:
The only thing I'm asking is to make it more extensible: in a previous
e-mail, that I posted today, I explained in detail, I hope, what I wanted
and the problems I have found. There I explained a solution (tested on my
own toy application). But later on I found those fixes were not enough...
In short, just imagine in our application we want to have a unique system
for providing FeedBack messages. The way it is implemented now you create
ValidationErrors on the FormComponent classes that are only used to
produce
Strings mesages and all other information associated with the
ValidationErrors are lost (on the Component error method). For instance,
we
would like to extend the FeedbackPanel (in fact we have already done it to
some extend) to provide more information on the exception that generated a
message (if the message come from an exception): for instance show a tree
with nested exception etc. Now that information is lost..
In my previous post I proposed to use a
IFeedbackMessageRegisteringStrategy
interface (with a default implementation) to allow plugin different
Strategies for registering messages. What it is done now is just the
defaul
strategy... But that does not (completely) solves the problem is I cannot
provide my own extensions of the classes FeedbackMessages and
FeedbackMessages.
Ernesto
igor.vaynberg wrote:
>
> our entire feedback messaging system has been designed around text
> messages.
> are you saying you want to be able to supply an object of any type as
> feedback?
>
> -Igor
>
>
> On 10/4/06, Ernesto Reinaldo Barreiro <[EMAIL PROTECTED]> wrote:
>>
>>
>> In a previous post I asked for some modifications related to the
>> mechanism
>> wicket uses for to handle FeedbackMessages. Investigating a bit more I
>> discovered that the methods getFeedbackMessages() of Page and Session
are
>> declared as final.which does not allows to plug in your own
>> implementation
>> (an extension) of a FeedbackMessages class.
>>
>>
>> public final FeedbackMessages getFeedbackMessages()
>> {
>> if (feedbackMessages == null)
>> {
>> feedbackMessages = new FeedbackMessages();
>> }
>> return feedbackMessages;
>> }
>>
>> It would be nice to have the final removed or at least provide a way to
>> plug
>> in a different kind of FeedbackMessages class (e.g by making it return
an
>> interface instead of a class). The same applies to the FeedbackMessage
>> class.
>>
>> Well having failed to achieve my goal (just wrap FeedbackMessage with
my
>> own extension) at the Page and Session levels I tried to do it at the
>> FeedbackMessagesModel level. There I discovered this method
>>
>> /**
>> * Override this method to post process to the FeedbackMessage
>> list.
>> *
>> * @param messages
>> * List of sorted and filtered FeedbackMessages for
>> further
>> * processing
>> * @return The processed FeedbackMessage list
>> */
>> protected List<FeedbackMessage> processMessages(final
>> List<FeedbackMessage>
>> messages)
>> {
>> return messages;
>> }
>>
>> which would have been suitable for the task. But unfortunately it is
>> protected and I can't use it to wrap the FeedbackMessages with my own
>> ones...
>>
>> Best regards,
>>
>> Ernesto
>>
>> --
>> View this message in context:
>>
http://www.nabble.com/problems-regarding-FeedbackMessages-tf2384705.html#a6647213
>> Sent from the Wicket - Dev mailing list archive at Nabble.com.
>>
>>
>
>
--
View this message in context:
http://www.nabble.com/problems-regarding-FeedbackMessages-tf2384705.html#a6647836
Sent from the Wicket - Dev mailing list archive at Nabble.com.
