On Mon, Jan 19, 2009 at 10:37 PM, Ville Virtanen <ville.virta...@cerion.fi>wrote:
> > It sounds like an addition that would be good to have when implementing > non-standard persistence strategies. Thanks. Haven't heard from Howard but I'll open an issue anyway. I can get this done without this enhancement, but it makes sense to me. Ps. I'm very interested in the results Kalle if you care to share? (Or > Kristian for that matter. Would it be possible to add a project to > tapestry.formos.com?) The current plan is to make it available as a submodule of Trails ( http://markmail.org/message/htv4tdxidex4xpv5#query:trails-dev%20conversation+page:1+mid:4pjnurcvwnw3untq+state:results). But don't hold your breath - taking it from a prototype to a generic, publicly available library including documentation will take some time. I just quickly browsed through Kristian's implementation and the major difference between his and mine is that his is more generic akin to Seam's while mine is specifically conversation-within-page. But because of this convention/requirement (in the latter), tracking conversations and ending them automatically when they are abandoned or become idle is much easier. Kalle > Kalle Korhonen-2 wrote: > > > > Hey Kristian, thanks a lot for sending your project; it'll be interesting > > to > > compare the implementations. Yes, of course there's a million different > > ways > > of solving the problem but since the Tapestry architecture and services > > offer a lot of functionality already for this, I tried to reuse most of > > it. > > And except for this small part, it worked out very well. Howard, care to > > weigh in your opinion - would it not make sense to allow to selectively > > discard changes of specific persistent strategies? > > > > Kalle > > > > > > On Mon, Jan 19, 2009 at 3:14 AM, Kristian Marinkovic < > > kristian.marinko...@porsche.co.at> wrote: > > > >> hi kalle, > >> > >> i've tried to solve this with another indirection :). > >> > >> i encapsulate all conversation specific data in a ConversationContext > >> object. > >> if i want to invalidate a conversation i just remove this context. > >> > >> i'm going to send you a zip with my experimental project > >> to your gmail address. maybe it helps. > >> > >> g, > >> kris > >> > >> > >> > >> > >> Kalle Korhonen <kalle.o.korho...@gmail.com> > >> 19.01.2009 06:36 > >> Bitte antworten an > >> "Tapestry users" <users@tapestry.apache.org> > >> > >> > >> An > >> Tapestry users <users@tapestry.apache.org> > >> Kopie > >> > >> Thema > >> Discard persistent field changes for one strategy only? > >> > >> > >> > >> > >> > >> > >> I would like to discard all changes for one strategy only. > >> PersistentFieldManager always iterates over all strategies when calling > >> discardChanges() and I don't see any (easy) way to decorate the > >> PersistentFieldManager to allow it to discard selectively for some > >> strategies only. Would it be possible to add a discardChanges(String > >> strategyName, String pageName) operation to PersistentFieldManager or to > >> make the getStrategy(String strategyName) public? Or is there any other > >> way > >> to get a hold of a strategy in a service that the strategies haven't > been > >> contributed for if I know the type? This functionality would be needed > >> for > >> conversational scope implementation. At least in my mind it makes > perfect > >> sense to allow this, I'll open an issue if somebody agrees. For now, I > >> can > >> make it work by contributing the same > ConversationPersistentFieldStrategy > >> to > >> another service in addition to PersistentFieldManager in my AppModule, > >> but > >> I > >> can't make it "plugn'n'play" without the "selective discard" > >> functionality. > >> > >> Kalle > >> > >> > > > > > > -- > View this message in context: > http://www.nabble.com/Discard-persistent-field-changes-for-one-strategy-only--tp21537228p21557882.html > Sent from the Tapestry - User mailing list archive at Nabble.com. > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org > >
