well, as i said i dont see any value in the extra strategy. there are only a
few options that make sense when thinking about how and where to store the
feedback messages/objects and i believe we have picked and implemented the
one that makes most sense.
but lets see what other devs think.
-Igor
On 10/4/06, Ernesto Reinaldo Barreiro <[EMAIL PROTECTED]> wrote:
Maybe you are right and I added to much extra complexity... But I still
think
it would be nice to have some kind of plugable feedback reporting
strategy.
If you combine that with allowing the field message of the class
FeedbackMessage to be any object then the system would be rather flexible
as
I can plug in a different strategy that instead of storing the text
message
on that field would store the whole ValidationError class or whatever
class
I need (because I can ValidationError setVar method to pass extra info) .
That way what you have now would still work fine and I could plugin any
object(s) I need.
Respect to the methods on getFeedbackMessages() on Page and Session you
could still keep then final but If you remove the final and allow the
strategy thing then no modifications to FeedbackMessage class woul be
needed
(as I could plug in my own FeedbackMessage's).
Ernesto
igor.vaynberg wrote:
>
> 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.
>>
>>
>
>
--
View this message in context:
http://www.nabble.com/problems-regarding-FeedbackMessages-tf2384705.html#a6648512
Sent from the Wicket - Dev mailing list archive at Nabble.com.
