The idea of the startegy class is simple: just let the developer decide how
he wants to report the feedback messages. For instance if I would like to
make persistent all the feedback messages before I show them to the user
the way it is done now I would have to override each single FormComponent of
the framework to provide my own implementation on error(IValidationError).
With a strategy that is simple. I would plug in a new strategy that does the
logging and then calls the default strategy that does add the message to the
page's feedBack messages list. The final touch would be if I can decide
myself what that messages list is and what the actual messages are because
then I would have full control of the system. If those two things are
plugable then the system besides being simple and clean would be also a lot
more flexible.
Thanks a lot for your time and for the great framework! (this last thank
goes to all the developers)
Ernesto
igor.vaynberg wrote:
>
> 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.
>>
>>
>
>
--
View this message in context:
http://www.nabble.com/problems-regarding-FeedbackMessages-tf2384705.html#a6648951
Sent from the Wicket - Dev mailing list archive at Nabble.com.
