Re: [xwiki-devs] [UX][Vote] Content Templates by default

[Ecaterina Moraru (Valica)]

Thanks for your votes.

I've added them in http://jira.xwiki.org/browse/XE-1564

Thanks,
Caty

On Wed, Jul 13, 2016 at 3:13 PM, Guillaume Delhumeau <
guillaume.delhum...@xwiki.com> wrote:

> +1 for integrating templates.
>
> "Article" is like a blog post man while "Encyclopedia" integrates a table
> on the right to describe an object or something. Their objective are
> different. But if we decide to keep only one of them, I would be OK
> (Encyclopedia being my favorite).
>
> 2016-07-12 13:55 GMT+02:00 Vincent Massol :
>
> >
> > > On 12 Jul 2016, at 13:48, Eduard Moraru  wrote:
> > >
> > > Hi,
> > >
> > > On Tue, Jul 12, 2016 at 1:31 PM, Ecaterina Moraru (Valica) <
> > > vali...@gmail.com> wrote:
> > >
> > >> Ideally we should make the templates independent and have a dedicated
> > >> section in e.x.o.
> > >> Users could browse and install them separate.
> > >>
> > >> We should also monitor what templates are interesting and which are
> not
> > >> (although this is a bit hard to do right now).
> > >>
> > >> Of course I also consider we could have better templates or diverse,
> but
> > >> this is not the point now.
> > >> The point is to add some templates and better show this feature. Since
> > we
> > >> are very generic it's hard to tell what templates each category of
> users
> > >> would need. That's why it would be better for them to select them, but
> > they
> > >> should be aware that they have this possibility.
> > >>
> > >> So currently the vote is favorable. I'm waiting until tomorrow so see
> > if we
> > >> have any blockers.
> > >>
> > >> Still not sure about how we should implement them best: in platform or
> > in
> > >> e.x.o? As a package or separate?
> > >>
> > >
> > > My preference goes towards a templates package, for start, in contrib,
> > that
> > > is included in the default flavor.
> >
> > I think I agree. We need to close the last discussion thread about the
> > scope for the xwiki github org and about platform. Right now the
> consensus
> > seems to be:
> > * the default platform distribution’s goal is to provide a basic working
> > wiki
> > * XE’s goal (and in the future another named flavor) is to provide a
> > full-fledged second generation wiki.
> > * Non core features go in contrib and generic ones are included in the XE
> > flavor
> >
> > Thanks
> > -Vincent
> >
> > > Thanks,
> > > Eduard
> > >
> > >
> > >>
> > >> Thanks,
> > >> Caty
> > >>
> > >> On Tue, Jul 12, 2016 at 12:39 PM, Eduard Moraru  >
> > >> wrote:
> > >>
> > >>> Hi,
> > >>>
> > >>> +1, generally.
> > >>>
> > >>> I also feel a bit frustrated by the seeming redundancy of having both
> > >>> Article and Encyclopedia on one side and Meeting Report and Simple
> page
> > >>> onthe other, since from a helicopter view they are 95% identical.
> > >> However,
> > >>> I believe that the whole point of templates is to have a very
> > specialized
> > >>> usecase that is answered and that the user can immediately use. If
> > every
> > >>> time someone wants a simple page, but selects meeting notes and
> > removes a
> > >>> lot of formatting, then they will just end up creating a simple page
> > >>> template.
> > >>>
> > >>> These are just a couple of usages that we consider to be very common
> > and
> > >>> which we decide to offer some help by default (in the default
> flavor).
> > >>> Others could be added (even from Caty`s extended list), since we`re
> > >> missing
> > >>> tables, macros and many other useful XWiki features that are
> otherwise
> > >> hard
> > >>> to discover.
> > >>>
> > >>> Thanks,
> > >>> Eduard
> > >>>
> > >>> On Tue, Jul 12, 2016 at 12:17 PM, Alexandru Cotiuga <
> > >>> alexandru.coti...@xwiki.com> wrote:
> > >>>
> >  Hello,
> > 
> >  + 1 for all
> >  The difference between Article and Encyclopedia could be increased
> by
> >  adding other specific elements on each one's layout.
> > 
> >  Thanks,
> >  Alex
> > 
> >  On Tue, Jul 12, 2016 at 12:11 PM, Ecaterina Moraru (Valica) <
> >  vali...@gmail.com> wrote:
> > 
> > > In case we don't like a particular Template, then the best strategy
> > >> is
> > >>> to
> > > have individual votes for them.
> > >
> > > @Anca, from your feedback is hard to know if you prefer Article
> over
> > > Encyclopedia.
> > >
> > > Since we need to release 8.2 final at the end of the week I would
> > >> like
> > >>> to
> > > advance with this topic: either by committing all the proposed
> > >>> templates
> >  or
> > > just a subset, but I need more opinions.
> > >
> > > Status:
> > > 1. Article (Article page): +1 Vincent, +1 Caty
> > > 2. Encyclopedia (Encyclopedia page): +1 Vincent, +1 Caty
> > > 3. Meeting Report (Agenda and notes): 1+ Vincent, +1 Caty, +1 Anca
> > > 4. Simple Page (With table of content): +1 Vincent, +1 Caty, +1
> Anca
> > >
> > > Thanks,
> > > Caty
> > >
> > >
> > 

Re: [xwiki-devs] Velocity 2.0 and DeprecatedCheckUberspector

[Thomas Mortagne]

On Thu, Jul 21, 2016 at 5:26 PM, Claude Brisson  wrote:
> Hi.
>
> I'm currently working on Velocity 2.0 packaging.

Great news :)

>
> If that's OK with you, I would like to incorporate
> DeprecatedCheckUberspector.java into Velocity, but I need a statement from
> your part to be able to change its licence to Apache 2.0 (LGPL and Apache
> 2.0 licences aren't compatible).

+1 for me

>
> By the way, I take this opportunity to tell you that if there is another
> specific part of xwiki-commons-velocity that you think should be integrated
> on our side, or an important missing feature you'd like to insist on, don't
> hesitate. I already integrated VELOCITY-825, for instance, so String->Enum
> constant conversions are now handled by Velocity. There may be other
> important conversion cases you'd like to see handled.

Note that XWiki goes far beyond String->Enum. When the signature of a
method cannot be found it search for method with similar number of
arguments and use xwiki-commons-properties module (similar to apache
beanutils) to try to convert the parameter it gets into the types of
the method parameters. We are using this a lot so it would probably be
a nice to have in Velocity (probably something based on beanutils that
could be extended on our side to use all xwiki-commons-properties
supported types). See
https://github.com/xwiki/xwiki-commons/blob/master/xwiki-commons-core/xwiki-commons-velocity/src/main/java/org/xwiki/velocity/introspection/MethodArgumentsUberspector.java.

Maybe it's not the case in Velocity 2.0 anymore, but restriction on
Class methods access is way too strong in 1.7 so we overwritten secure
introspector to accept more calls. See
https://github.com/xwiki/xwiki-commons/blob/master/xwiki-commons-core/xwiki-commons-velocity/src/main/java/org/xwiki/velocity/introspection/SecureIntrospector.java.

We implemented a directives based try/catch support for Velocity
recently. We don't use it much yet (too young) but we probably will.
Could be interesting on Velocity side. See
https://github.com/xwiki/xwiki-commons/blob/master/xwiki-commons-core/xwiki-commons-velocity/src/main/java/org/xwiki/velocity/introspection/TryCatchDirective.java.

>
> Regards,
>
>   Claude
>
> ___
> devs mailing list
> devs@xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs



-- 
Thomas Mortagne
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] Velocity 2.0 and DeprecatedCheckUberspector

[Sergiu Dumitriu]

One thing that would be nice to have is the custom whitespace filter
that the {{velocity}} macro has: see
http://extensions.xwiki.org/xwiki/bin/view/Extension/Velocity+Macro#HParametersdefinition
and
http://extensions.xwiki.org/xwiki/bin/view/Extension/Velocity+Macro+Filter

Basically, Velocity only supports literal whitespace processing, with
every space and newline going into the output, while we like to be able
to indent our sources without padding the output with lots of extra spaces.

On 07/22/2016 02:49 AM, Vincent Massol wrote:
> Hi Claude,
> 
>> On 21 Jul 2016, at 17:26, Claude Brisson  wrote:
>>
>> Hi.
>>
>> I'm currently working on Velocity 2.0 packaging.
>>
>> If that's OK with you, I would like to incorporate 
>> DeprecatedCheckUberspector.java into Velocity, but I need a statement from 
>> your part to be able to change its licence to Apache 2.0 (LGPL and Apache 
>> 2.0 licences aren't compatible).
> 
> Thanks for reaching out. A big +1 from me too. The more we can move to 
> Velocity the better it is.
> 
>> By the way, I take this opportunity to tell you that if there is another 
>> specific part of xwiki-commons-velocity that you think should be integrated 
>> on our side, or an important missing feature you'd like to insist on, don't 
>> hesitate. I already integrated VELOCITY-825, for instance, so String->Enum 
>> constant conversions are now handled by Velocity. There may be other 
>> important conversion cases you'd like to see handled.
> 
> Ok cool.
> 
> On your side, if you see other issues that you’d be willing to integrate let 
> us know.
> 
> Thanks
> -Vincent
> 
>> Regards,
>>
>>  Claude

-- 
Sergiu Dumitriu
http://purl.org/net/sergiu/
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] Velocity 2.0 and DeprecatedCheckUberspector

[Vincent Massol]

Hi Claude,

> On 21 Jul 2016, at 17:26, Claude Brisson  wrote:
> 
> Hi.
> 
> I'm currently working on Velocity 2.0 packaging.
> 
> If that's OK with you, I would like to incorporate 
> DeprecatedCheckUberspector.java into Velocity, but I need a statement from 
> your part to be able to change its licence to Apache 2.0 (LGPL and Apache 2.0 
> licences aren't compatible).

Thanks for reaching out. A big +1 from me too. The more we can move to Velocity 
the better it is.

> By the way, I take this opportunity to tell you that if there is another 
> specific part of xwiki-commons-velocity that you think should be integrated 
> on our side, or an important missing feature you'd like to insist on, don't 
> hesitate. I already integrated VELOCITY-825, for instance, so String->Enum 
> constant conversions are now handled by Velocity. There may be other 
> important conversion cases you'd like to see handled.

Ok cool.

On your side, if you see other issues that you’d be willing to integrate let us 
know.

Thanks
-Vincent

> Regards,
> 
>  Claude

___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs