Hi, so you suggest that we may should use only serializable objects as arguments?
The TextTemplateResourceReference is also using a Model. So maybe we should refactor all to not use models at all? https://ci.apache.org/projects/wicket/apidocs/8.x/org/apache/wicket/request/resource/ResourceReference.html In my opinion there should be a unified way for all RR. kind regards Tobias > Am 14.06.2018 um 19:49 schrieb Sven Meier <[email protected]>: > > Hi, > > a model doesn't make too much sense here, because references don't get > detached. > > I find the usage of a model here and in FileSystemResource a little > misleading: > Yes, the LDM will drop the reference once it is serialized (because of its > transient reference), > but it is 'detached' explicitly in #respond() only, which doesn't actually > happen until the resource is fetched in a different request. > > Have fun > Sven > > >> Am 14.06.2018 um 18:25 schrieb Tobias Soloschenko: >> +1 - at this time I was not aware of what all has to be serializable. So yep >> I would suggest to use the Model at this place, too. >> >> kind regards >> >> Tobias >> >>> Am 14.06.2018 um 07:50 schrieb Martin Grigorov <[email protected]>: >>> >>> With WICKET-6504 we improved FileSystemResource to use >>> LoadableDetachableModel<Path> instead of just path. >>> Maybe the same should be done for the ResourceReference too ? >>> >>> On Thu, Jun 14, 2018 at 4:24 AM Maxim Solodovnik <[email protected]> >>> wrote: >>> >>>> You can have String path (instead of Path path) >>>> And it will works as expected :) >>>> >>>> WBR, Maxim >>>> (from mobile, sorry for the typos) >>>> >>>>> On Thu, Jun 14, 2018, 04:23 sorinev <[email protected]> wrote: >>>>> >>>>> Perfect, that worked. What's the side effect of this vs the other way, if >>>>> any? >>>>> >>>>> -- >>>>> Sent from: >>>>> http://apache-wicket.1842946.n4.nabble.com/Users-forum-f1842947.html >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: [email protected] >>>>> For additional commands, e-mail: [email protected] >>>>> >>>>> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] >
