3 Apr
2016
3 Apr
'16
12:19 a.m.
+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 <vincent(a)massol.net> wrote:
--
Sergiu Dumitriu
http://purl.org/net/sergiu
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
On 01 Apr 2016, at 23:04, Sergiu Dumitriu
<sergiu(a)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 <vincent(a)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, vincent(a)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, vincent(a)massol.net (vincent(a)massol.net
(mailto:vincent@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#HBestPra…
)
>>>>
>>>> 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(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs