+0 I can`t help but feel we are stretching Velocity more than what it was built for and we might end up with a more verbose and spaghetti code than what we would have liked (and than we currently have).
As long as we try not to abuse it, I guess we can see how it goes. Thanks, Eduard On Sat, Apr 2, 2016 at 11:59 AM, Vincent Massol <vinc...@massol.net> wrote: > > > On 01 Apr 2016, at 23:04, Sergiu Dumitriu <ser...@xwiki.org> wrote: > > > > I think that it's a good idea for script services to throw somewhat > > expected exceptions, signalling invalid usage attempts (user not > > authorized, wrong arguments...) that would then be caught in Velocity. > > But deeper platform issues (DB errors, unexpected NPE, OOM...) should be > > handled outside the user's code itself, at the skin level (view.vm). > > Sure, that’s the point. The scripts can decide to catch or not (ie. to > handle or not). If not then it’s caught anyway at the level of > MacroTransformation (for macros) or at the level of contentview.vm. In the > majority of cases there isn’t much that the script can do and it shouldn’t > catch anything (it should catch only if it can handle it, i.e. do something > with the exception). > > Thanks > -Vincent > > > > > On 04/01/2016 05:45 AM, Vincent Massol wrote: > >> So far we have the following devs who agree: > >> - thomas > >> - marius > >> - vincent > >> > >> What about Edy, Sergiu and the others? > >> > >> Thanks > >> -Vincent > >> > >>> On 31 Mar 2016, at 14:17, Vincent Massol <vinc...@massol.net> wrote: > >>> > >>> Guys, I’d like that we progress on this. > >>> > >>> I didn’t get any agreement or disagreement to this proposal. > >>> > >>> Any take? > >>> > >>> Thanks > >>> -Vincent > >>> > >>> > >>>> On 18 Jan 2016, at 11:03, vinc...@massol.net wrote: > >>>> > >>>> Hi devs, > >>>> > >>>> After a lot of thinking and experimentation (see the thread’s > details), I have found that this first proposal is not a good idea. I’m > thus proposing to replace it with the following best practice: > >>>> > >>>> * Let our script services generate exceptions > >>>> * If the velocity scripts with to handle the exceptions, then they > should use the #try() directive. If they don’t want to, they don’t have to > do anything since the MacroTransformation or the template (contentvars.vm > for example) will catch it and display it to the user. > >>>> > >>>> More precisely I’m proposing that: > >>>> > >>>> * Existing Script APIs in Java should not be modified as that would > break backward compatibility. New signatures can be added and old one > deprecated and moved to the legacy modules. After new signatures have been > introduced, existing velocity scripts can be updated to use the new > signatures and to use the #try directive if needed. > >>>> * New Script APIs must use the new best practices (if agreed :)), > i.e. throw Exceptions, and new velocity scripts must use the #try() > directive if they need to handle exceptions. > >>>> > >>>> WDYT? > >>>> > >>>> Thanks > >>>> -Vincent > >>>> > >>>> > >>>> On 14 Jan 2016 at 17:51:04, vinc...@massol.net (vinc...@massol.net > (mailto:vinc...@massol.net)) wrote: > >>>> > >>>>> Hi devs, > >>>>> > >>>>> Right now our strategy is for script services and script APIs in > general to catch exceptions, store them and offer a getLastError() method > to get them (see > http://extensions.xwiki.org/xwiki/bin/view/Extension/Script+Module#HBestPractices > ) > >>>>> > >>>>> However it would be much nicer to: > >>>>> * Let our script services generate exceptions > >>>>> * Offer a velocity script service to get the last exception raised > by a java call from velocity > >>>>> * Implement this uberspector to catch the exceptions and to set them > in the execution context > >>>>> > >>>>> That should be quite easy to implement IMO. > >>>>> > >>>>> WDYT? > >>>>> > >>>>> Thanks > >>>>> -Vincent > >>>>> > >>>>> PS: This is http://jira.xwiki.org/browse/XWIKI-2374 > >>> > >> > >> _______________________________________________ > >> devs mailing list > >> devs@xwiki.org > >> http://lists.xwiki.org/mailman/listinfo/devs > >> > > > > > > -- > > Sergiu Dumitriu > > http://purl.org/net/sergiu > > _______________________________________________ > > devs mailing list > > devs@xwiki.org > > http://lists.xwiki.org/mailman/listinfo/devs > > _______________________________________________ > devs mailing list > devs@xwiki.org > http://lists.xwiki.org/mailman/listinfo/devs > _______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
