FeedbackMessages belong to the page they are put on. There is nothing that prevents you from doing the following:
Page target = new MyPage();
target.info("My superduper infomessage");
setResponsePage(target);
I wouldn't like it when a message from a previous page that didn't have a feedback panel or flash panel suddenly pop up on another unrelated page. Or a message from 5 requests ago.
Putting (more) magic into the framework is not the way to go.
I think the problem is not in feedback messages or flash panels. The problem is that we can't have components that have multiple instances but share state across the session. I have come across this problem and solved it by having the component push its (internal) state into the session, but I think that is wrong as it breaks encapsulation.
Say you want to build a (generic) breadcrumbs component, without having to do your own model, then you are in a spot which Wicket doesn't excel. You can't move the component from one page to the next (nor would you want to), and the component can't keep its state across requests.
class FooPage extends Page {
public FooPage() {
add(new BreadCrumbs("bc", "Foo"));
}
}
class BarPage extends Page {
public BarPage() {
add(new BreadCrumbs("bc", "Bar"));
}
}
As a user of the BreadCrumbs component, I don't want to have to distribute the model of the component across my pages. That would clutter the interfaces. I think this is what Sprign WebFlow and Seam are targeting: state that spans multiple requests/pages. IMO feedback panels touch this same subject.
Martijn
On 3/23/06, Johan Compagner <[EMAIL PROTECTED]> wrote:
but that just means that you rewrite feedback messages so that they are as flash now
Just a matter of where you start.
And feedbackmessages are hold on to in a page now so they should be removed from there.
And feedbackmessage are bound to a component. And that is also what you don't want
if they are hold on to over pages. Because then we have a mem leak.
johanOn 3/23/06, Eelco Hillenius < [EMAIL PROTECTED]> wrote:Then you don't get my point. I say keep feedback, but let it work like
flash. We want (or we should want) the possible detail of feedback
messages (level and filtering), but we want the retention of flash
messages.
Eelco
On 3/23/06, Johan Compagner < [EMAIL PROTECTED]> wrote:
> hmm if i read this thread
> Then i would say.. remove the feedback. And keep the flash.
> Flash seems to work the way we want and feedback doesn't
>
> johan
>
>
>
> On 3/23/06, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
> >
> On 3/22/06, Igor Vaynberg < [EMAIL PROTECTED]> wrote:
> > i set out to achieve exactly what i achieved. as you point out feedback
> > messages do not last across requests. so lets say i am on edit page and i
> > just clicked save. the edit page returns me to the list page, i would like
> > to see a confirmation message on the list page that whatever i was editing
> > has been successfully saved. this message should be set by the edit page,
> > but displayed on the list page and should last across any redirects we do
> to
> > get to the list page from the edit page. furthermore, once it is displayed
> > it should not be displayed again.
>
> Yes. Like CDApp /used to do/ with feedback messages. Unfortunately we
> have a long history with breaking/ fixing/ breaking and fixing
> feedbackmessages again, and CDApp is broken again due to the fact that
> onBeginRequest never had clear semantics, and feedbackmessages are
> queried before that method is called.
>
> > these messages arent really meant to be "scoped" because there is no scope
> > really. what i would like to maybe see is a error/info/warn levels like we
> > have with feedback messages. i didnt do that because i couldnt decide on a
> > good api, should i introduce flashInfo/flashWarn/flashError into component
> > or should i add a boolean to our info/warn/error methods to tell it
> whether
> > to store the message in flash scope or not? another thing i couldnt decide
> > on is whether or not to make our feedbackpanel also display the messages
> in
> > the flash store.
> >
> > because i couldnt decide on those points above i implemented the simplest
> > possible solution. if you see a way to have this functionality without the
> > api bloat im all ears.
>
> Well, the thing is that you are really trying to fix feedback
> messages. Feedback messages /should/ work like those flash messages,
> and the fact that they currently don't is faulty. I think we should
> remove the flash methods again - even though there is this slight hype
> factor to them ;) - and change the feedback messages implementation
> and put them in the session instead of the page. I don't really know
> what tricky details that could involve - I'm too bloody bussy writing
> that bloody rotten book -, but that would be the idea.
>
> > i upgraded wicket-phonebook to use this so you can check it out there.
>
> Yeah. CDApp has exactly the same needs. Probably every CRUD or app
> with master/ detail pages out there.
>
> Eelco
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting language
> that extends applications into web and mobile media. Attend the live webcast
> and join the prime developer group breaking into this new coding territory!
> http://sel.as-us.falkag.net/sel?cmdlnk&kid0944&bid$1720&dat1642
> _______________________________________________
> Wicket-develop mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/wicket-develop
>
>
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmdlnk&kid0944&bid$1720&dat1642
_______________________________________________
Wicket-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-develop
--
Cast your final vote for Wicket in the SourceForge.net 2006 Community Choice Awards!
http://www.wilsonresearch.com/2006/ostgawards06/ostgawards4.php
