You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@wicket.apache.org by Ernesto Reinaldo Barreiro <re...@isencia.com> on 2006/10/04 22:03:51 UTC
problems regarding FeedbackMessages
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.
Re: problems regarding FeedbackMessages
Posted by Ernesto Reinaldo Barreiro <re...@isencia.com>.
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 <re...@isencia.com> 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 <re...@isencia.com> 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 <re...@isencia.com> 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.
Re: problems regarding FeedbackMessages
Posted by Igor Vaynberg <ig...@gmail.com>.
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 <re...@isencia.com> 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 <re...@isencia.com> 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 <re...@isencia.com> 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.
>
>
Re: problems regarding FeedbackMessages
Posted by Ernesto Reinaldo Barreiro <re...@isencia.com>.
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 <re...@isencia.com> 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 <re...@isencia.com> 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.
Re: problems regarding FeedbackMessages
Posted by Igor Vaynberg <ig...@gmail.com>.
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 <re...@isencia.com> 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 <re...@isencia.com> 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.
>
>
Re: problems regarding FeedbackMessages
Posted by Ernesto Reinaldo Barreiro <re...@isencia.com>.
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 <re...@isencia.com> 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.
Re: problems regarding FeedbackMessages
Posted by Igor Vaynberg <ig...@gmail.com>.
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 <re...@isencia.com> 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.
>
>