Re: [xwiki-devs] Slightly improved default pdf export look and feel

[Anca Luca]

Hello all,

as promised, the pull request is now merged (for 10.10-rc-1) and documented
in the release notes for users.

Anca

On Sun, Oct 21, 2018 at 8:58 PM Anca Luca  wrote:

> Hello Vincent,
>
> done, I attached the same page exported with the previous export, for
> comparison.
>
> On Sun, Oct 21, 2018 at 12:41 AM Vincent Massol 
> wrote:
>
>> Hi Anca,
>>
>> Thanks for working on this.
>>
>>  I wanted to quickly check it out so I went to the jira issue. What would
>> have been nice would have been to have two 2 PDF exports (one before and
>> one after), or simply 2 screenshots. Just to see visually what the changes
>> you made are looking like. But if you don’t have the time for this, don’t
>> worry, we can work with the text/PR. However, if you had some screenshots,
>> it could go in the Release notes to show the improvements to the user.
>>
>> Thanks
>> -Vincent
>>
>> > On 21 Oct 2018, at 01:50, Anca Luca  wrote:
>> >
>> > Hello devs,
>> >
>> > I've whipped up quickly a couple of changes to the default PDF export of
>> > the XWiki platform, to try to make it look a little nicer.
>> > I created the issue here https://jira.xwiki.org/browse/XWIKI-15761 and
>> the
>> > pull request here https://github.com/xwiki/xwiki-platform/pull/900 .
>> > I would like to merge that into master unless somebody has something
>> > against it, so please speak up now.
>> >
>> > Longer story:
>> > I know that "nicer" is a subjective term, and that a lot more can be
>> done
>> > to improve this default PDF export. My idea was that the current
>> defaults
>> > we have (for the font family, for example, or the information we
>> display in
>> > the pdf header/footer and the style associated) are not the result of an
>> > actual studied choice, iirc they are just defaults that were set like
>> that
>> > in the first version of that export and never changed. Thus, I don't see
>> > why we couldn't slightly change these defaults (without changing the
>> > information displayed or risking regressions) to have a slightly better
>> > looking default PDF, while still allowing all customizations just they
>> way
>> > they worked before.
>> > These modifications are not blocking nor replacing in any way the more
>> > serious improvements that can be done on the PDF export, they're just
>> > slightly improving the current defaults.
>> >
>> > Best regards,
>> > Anca
>>
>>

Re: [xwiki-devs] Slightly improved default pdf export look and feel

[Anca Luca]

Hello Vincent,

done, I attached the same page exported with the previous export, for
comparison.

On Sun, Oct 21, 2018 at 12:41 AM Vincent Massol  wrote:

> Hi Anca,
>
> Thanks for working on this.
>
>  I wanted to quickly check it out so I went to the jira issue. What would
> have been nice would have been to have two 2 PDF exports (one before and
> one after), or simply 2 screenshots. Just to see visually what the changes
> you made are looking like. But if you don’t have the time for this, don’t
> worry, we can work with the text/PR. However, if you had some screenshots,
> it could go in the Release notes to show the improvements to the user.
>
> Thanks
> -Vincent
>
> > On 21 Oct 2018, at 01:50, Anca Luca  wrote:
> >
> > Hello devs,
> >
> > I've whipped up quickly a couple of changes to the default PDF export of
> > the XWiki platform, to try to make it look a little nicer.
> > I created the issue here https://jira.xwiki.org/browse/XWIKI-15761 and
> the
> > pull request here https://github.com/xwiki/xwiki-platform/pull/900 .
> > I would like to merge that into master unless somebody has something
> > against it, so please speak up now.
> >
> > Longer story:
> > I know that "nicer" is a subjective term, and that a lot more can be done
> > to improve this default PDF export. My idea was that the current defaults
> > we have (for the font family, for example, or the information we display
> in
> > the pdf header/footer and the style associated) are not the result of an
> > actual studied choice, iirc they are just defaults that were set like
> that
> > in the first version of that export and never changed. Thus, I don't see
> > why we couldn't slightly change these defaults (without changing the
> > information displayed or risking regressions) to have a slightly better
> > looking default PDF, while still allowing all customizations just they
> way
> > they worked before.
> > These modifications are not blocking nor replacing in any way the more
> > serious improvements that can be done on the PDF export, they're just
> > slightly improving the current defaults.
> >
> > Best regards,
> > Anca
>
>

[xwiki-devs] Slightly improved default pdf export look and feel

[Anca Luca]

Hello devs,

I've whipped up quickly a couple of changes to the default PDF export of
the XWiki platform, to try to make it look a little nicer.
I created the issue here https://jira.xwiki.org/browse/XWIKI-15761 and the
pull request here https://github.com/xwiki/xwiki-platform/pull/900 .
I would like to merge that into master unless somebody has something
against it, so please speak up now.

Longer story:
I know that "nicer" is a subjective term, and that a lot more can be done
to improve this default PDF export. My idea was that the current defaults
we have (for the font family, for example, or the information we display in
the pdf header/footer and the style associated) are not the result of an
actual studied choice, iirc they are just defaults that were set like that
in the first version of that export and never changed. Thus, I don't see
why we couldn't slightly change these defaults (without changing the
information displayed or risking regressions) to have a slightly better
looking default PDF, while still allowing all customizations just they way
they worked before.
These modifications are not blocking nor replacing in any way the more
serious improvements that can be done on the PDF export, they're just
slightly improving the current defaults.

Best regards,
Anca

Re: [xwiki-devs] [Contrib] New application for copying pages from one wiki to another (name suggestions welcome)

[Anca Luca]

Hello all,

I guess we'd be going for application-xcopy .
Can you please create the repo? (for now, I think only repo is needed, not
yet jira)
Thanks a lot!

@Vincent: it's not coded with filter stream, is plain XWiki Document API,
coded as an async job (which can be launched from a regular script).

Thanks,
Anca



On Tue, Aug 21, 2018 at 4:49 PM Ecaterina Moraru (Valica) 
wrote:

> For me it would be "Multipage Copy Application", application-multipagecopy,
> similar to what we have for the Multipage Export Application.
>
> Thanks,
> Caty
>
> On Mon, Aug 20, 2018 at 11:58 PM Clément Aubin 
> wrote:
>
> > Hi Anca and Stéphane, hi all,
> >
> > Thanks for sharing that piece of code ; this opens a ton of possiblities
> > and use cases for other XWiki extensions working between wikis!
> >
> > Regarding the naming of the application itself, application-wikicopy
> > looks nice as it shows a bit what the application does, you could also
> > consider application-xcopy as you are kind of eXtending the copy
> > function of the wiki (also it looks a bit sexier than wikicopy IMO :) ).
> >
> > Thanks,
> > Clément
> >
> > On 08/20/2018 04:39 PM, Anca Luca wrote:
> > > Hello XWiki devs,
> > >
> > > slauriere and I have worked on an extension that copies pages from one
> > wiki
> > > (based on a HQL query selecting them) to another wiki, allowing to
> > exclude
> > > some class properties from objects in those pages, if the objects are
> > > present.
> > > It's coded as an async job, it can be manually triggered or scheduled
> > with
> > > a scheduler job.
> > >
> > > We used it to implement some publication scenario, where contributors
> > work
> > > on a set of documents on a subwiki and then these documents, if
> > validated,
> > > get copied (published) to another subwiki periodically. The validation
> is
> > > based on the custom structure of those documents, using the generic
> > feature
> > > of this extension that allows to select documents to be published based
> > on
> > > a query. Otherwise there's nothing else related to publication in the
> > code
> > > of the application itself.
> > >
> > > We'd like to publish this application on contrib, so can we please
> have a
> > > repo for it?
> > >
> > > However, we have some trouble choosing its name. The name that we used
> so
> > > far is "publication application" but we think it might be misleading
> esp.
> > > because of the similarity with publication workflow with which it has
> > > nothing to do.
> > >
> > > So, if you have an idea for a name that would correctly illustrate this
> > > work (and its future enhancements), please help us choose its name and
> > > create the repo.
> > >
> > > Thanks,
> > > Anca
> > >
> >
>

[xwiki-devs] [Contrib] New application for copying pages from one wiki to another (name suggestions welcome)

[Anca Luca]

Hello XWiki devs,

slauriere and I have worked on an extension that copies pages from one wiki
(based on a HQL query selecting them) to another wiki, allowing to exclude
some class properties from objects in those pages, if the objects are
present.
It's coded as an async job, it can be manually triggered or scheduled with
a scheduler job.

We used it to implement some publication scenario, where contributors work
on a set of documents on a subwiki and then these documents, if validated,
get copied (published) to another subwiki periodically. The validation is
based on the custom structure of those documents, using the generic feature
of this extension that allows to select documents to be published based on
a query. Otherwise there's nothing else related to publication in the code
of the application itself.

We'd like to publish this application on contrib, so can we please have a
repo for it?

However, we have some trouble choosing its name. The name that we used so
far is "publication application" but we think it might be misleading esp.
because of the similarity with publication workflow with which it has
nothing to do.

So, if you have an idea for a name that would correctly illustrate this
work (and its future enhancements), please help us choose its name and
create the repo.

Thanks,
Anca

Re: [xwiki-devs] [Proposal] New extension point: content header

[Anca Luca]

+1

On Wed, May 9, 2018 at 5:02 PM, Thomas Mortagne 
wrote:

> +1
>
> On Wed, May 9, 2018 at 4:16 PM, Stéphane Laurière
>  wrote:
> > Hi all,
> >
> > I'd like to propose a new UI extension point: content header (or before
> > content). My current motivation for it relates to the page-relations
> > application that will display the pages related to the current one: it
> can
> > be handy to have the relations displayed in the content header for
> > navigation purpose (even though other areas in the UI would make sense,
> such
> > as a dedicated navigation panel). Other usages I have in mind: display
> > content licensing information, content warning, display that the page is
> > currently not editable as the wiki is read only, let the user choose
> between
> > displaying tags before or after content... Note that Caty already
> proposed
> > an extension point for the customizing the content footer:
> > http://jira.xwiki.org/browse/XWIKI-13081
> >
> > I created the following issue: https://jira.xwiki.org/browse/XWIKI-15252
> >
> > What do you think?
> >
> > Cheers
> >
> > Stéphane
> >
> >
> > --
> > Stéphane Laurière
> > XWiki www.xwiki.com
> > @slauriere
> >
> >
>
>
>
> --
> Thomas Mortagne
>

Re: [xwiki-devs] [Proposal] So which protection to we want by default for extensions pages

[Anca Luca]

Hello

On Thu, May 3, 2018 at 3:30 PM, Thomas Mortagne 
wrote:

> On Thu, May 3, 2018 at 3:09 PM, Ecaterina Moraru (Valica)
>  wrote:
> > On Thu, May 3, 2018 at 2:56 PM, Thomas Mortagne <
> thomas.morta...@xwiki.com>
> > wrote:
> >
> >> By "users" and "devs" you mean "basic" and advanced, right ?
> >>
> >
> > It would be ideal if we could just say it's just basic or advanced. I
> meant
> > more from a purpose point of view.
> > "Devs" can be defined as advanced users or advanced admins, but the main
> > differentiator is their clear intention to modify and create apps.
>
> Sure but there is no standard way to indicate that someone is a "dev"
> in XWiki so I will need more details :)
>

Imo, the dev persona always has admin rights. If they're described as "want
to modify and create apps", both of these imply having admin rights:
installing apps so that they can modify them requires admin rights, while
creating a new app requires admin rights as well (I might be wrong on this
one, though). Also, "developing" on a wiki often means "doing what you can
from configuration and code the rest", so I guess we can safely assume that
they will be admins.

As a default setting I'm actually hesitating between 2b and 0, with the
possibility to restrain it further in the direction of 2a. I think it could
do the job.

Thanks,
Anca


>
> IMO the closest we have right now is "advanced" so that' what I listed.
>
> >
> >
> >
> >>
> >> On Thu, May 3, 2018 at 12:11 PM, Ecaterina Moraru (Valica)
> >>  wrote:
> >> > How I see this problem for extension technical pages:
> >> > - users -> EDIT right forced false. They don't see the "Edit" button,
> so
> >> > they are not tempted to edit.
> >> > - devs -> WARN. They should be able to modify the pages, but on their
> own
> >> > expense.
> >> > - admins -> WARN. They should be able to control everything, but be
> aware
> >> > of the risks.
> >> >
> >> > From what I see the above goes into 1b or 3. The only difference is
> if we
> >> > should force or not the developers to be admins and also be advanced
> >> users,
> >> > which in practice it usually happens.
> >> >
> >> > Simpler visualization of the proposal, where -ED=(EDIT right to DENY)
> and
> >> > W=(Warning):
> >> >
> >> >   |   Users  |   Admins |
> >> >   |Basic|Advanced|Basic|Advanced|
> >> > 0 |  W  |   W|  W  |   W|
> >> > 1a| -ED |   W| -ED ||
> >> > 1b| -ED |   W|  W  |   W|
> >> > 2a| -ED |  -ED   | -ED |  -ED   |
> >> > 2b| -ED |  -ED   |  W  |   W|
> >> > 3 | -ED |  -ED   | -ED |   W|
> >> >
> >> > Thanks,
> >> > Caty
> >> >
> >> >
> >> >
> >> > On Wed, May 2, 2018 at 8:02 PM, Thomas Mortagne <
> >> thomas.morta...@xwiki.com>
> >> > wrote:
> >> >
> >> >> Right I actually forgot to list one possibility in the first mail:
> >> >>
> >> >> 0) Warning for everyone (so what we have in 10.3)
> >> >>
> >> >> On Wed, May 2, 2018 at 6:56 PM, Vincent Massol 
> >> wrote:
> >> >> > Hi Thomas,
> >> >> >
> >> >> >> On 30 Apr 2018, at 14:29, Thomas Mortagne <
> thomas.morta...@xwiki.com
> >> >
> >> >> wrote:
> >> >> >>
> >> >> >> Hi xwikiers,
> >> >> >>
> >> >> >> In 10.3 we introduced a warning to discourage users from editing
> >> >> >> extension pages (unless the extension indicate it's OK to edit
> it).
> >> >> >>
> >> >> >> This was a first version to have something in 10.3 but the initial
> >> >> >> (vague) plan (for 10.4 this time) base on previous discussions
> was:
> >> >> >>
> >> >> >> * EDIT right forced false for basic users
> >> >> >> * still a warning for advanced users
> >> >> >> * various options to change that (EDIT right forced false for
> >> >> >> everyone, warning for everyone, etc.)
> >> >> >
> >> >> > Note: I haven’t read what’s below yet (looks complex ;)).
> >> >> >
> >> >> > From a functional POV the minimal needs IMO are:
> >> >> >
> >> >> > * The warning you’ve already implemented is good as the default
> >> >> > * We also need to take the hosting use case, where some company
> >> provide
> >> >> xwiki hosting and they want to prevent users (including admins, for
> >> >> superadmin it’s ok) from editing extension pages so that they can
> >> perform
> >> >> xwiki upgrades automatically with no conflicts.
> >> >> >
> >> >> > Ofc if we can support Advanced user vs Simple user use cases (i.e.
> >> >> forbid simple user from editing extension pages) that’s nice too but
> >> less
> >> >> important IMO.
> >> >> >
> >> >> > Thanks
> >> >> > -Vincent
> >> >> >
> >> >> >> That was before I actually look at what we can do with our
> security
> >> >> system :)
> >> >> >>
> >> >> >> Turns out that it's not a huge fan of dynamic criteria like
> >> >> >> "basic/advanced user", it's still possible but will require a big
> of
> >> >> >> work. Also since ADMIN imply EDIT forbidding basic admin to edit a
> >> >> >> protected document would not exactly be straightforward.
> >> >> >>
> >> >> >> Before 

Re: [xwiki-devs] [Proposal] Solutions to hide some pages from the navigation panel

[Anca Luca]

Hello all,

so, if I remember correctly, the navigation panel is just a call to the
documentsTree macro. Unless otherwise specified, my remarks below are about
the documentTree macro features.

On Wed, May 2, 2018 at 6:02 PM, Marius Dumitru Florea <
mariusdumitru.flo...@xwiki.com> wrote:

> Hi devs,
>
> Some users have complained that the navigation panel shows top level pages
> that they don't need/want to navigate to, most importantly the XWiki page.
>
> There are multiple ways in which we can fix this.
>
> Solution 1: Content Page
>
> Create a top level "Content" page for user content and configure the
> navigation panel to show the contents of this page.
>
> Pros:
> * Namespace isolation (no conflicts between user pages and application
> pages)
>
> Cons:
> * The user may want to navigate to a top level application page (although
> it's better to use the application panel for this instead)
> * All the paths / references used to access the user content will start
> with this "Content" page
>

The documentTree macro already has this feature, actually, to be able to
start in a given root and I thought about this solution (manually
implemented with a custom documentTree with a custom root).
However, I think it's too restrictive (to force all content to be rooted in
"Content") and in order to technically make it happen you'd need to change
too many places of XWiki: the create, copy and move screens (when location
is chosen) in order to make sure that user does not create content
somewhere else.


>
>
> Solution 2: Blacklisting
>
> Add support for specifying a list of (top level) pages to exclude from the
> navigation panel.
>

Most of the usecases I had fall into this category, with blacklisting only
at root level (if this makes it easier to implement or doesn't introduce
perf. issues).
So to me the pages to exclude would be a feature of the documentTree macro
(which can also be used as a gadget on a dashboard).


>
> Pros:
> * The user (top level) pages created later on will be visible in the
> navigation panel
> * The blacklist could be used to filter not only top level pages but also
> any nested page from the navigation panel.
>
> Cons:
> * The blacklist depends on the installed apps. The administrator may have
> to update the blacklist when new applications are installed
>

Actually, this is a feature :) : any page (be it extension or user created
content) is whitelisted until an administrator decides that it should not
be in the tree. Note that it's the administrator that installs extensions
on a wiki, and at least in theory it's not done every morning. For the
management of the blacklists of the navigation panel (what navigation panel
will pass to the documentTree macro), we can use an administration section,
just like we do for what the applications panel displays by default :D. In
addition, it would be consistent with what we already have!


> * The blacklist depends on whether you view hidden pages or not. If you
> don't view hidden pages then the blacklist probably contains 4 pages: Help,
> Menu, Sandbox, XWiki (there is an application panel entry for each of them
> except XWiki), which is manageable. If you view hidden pages then you need
> to black list 28+ pages which is hard to manage and maintain.
>

The fact that you see too many pages when you activate hidden pages in your
profile is a problem that is not specific to the tree, so it shouldn't
surprise anyone that the tree also shows too many things.
To me, seeing hidden pages is not a "regular user in production" setting,
it's mostly for setup / development phase.


> * The filtering needs to happen on the database (otherwise we break the
> pagination) so the database queries will become a bit more complex, which
> could led to some performance penalty, depending on how long the blacklist
> is.


>
> Solution 3: Whitelisting
>
> Add support for controlling the list of top level pages that are displayed
> in the navigation panel.
>

this is the same principle as blacklisting (only "reversed"), and as far as
I can project now, it already has a workaround: having multiple
documentTree calls with the root parameter set and showroots to true.
Also, the default create button of the wiki creates pages on the root of
the wiki, next to "Main" and this would mean that the administrator would
need to update the navigation panel any time a page is created, which is
way more often than "any time an extension is installed".


>
> Pros:
> * the whitelist doesn't depend on the installed extensions or hidden pages
> so it's easier to maintain.
> * the whitelist can be used to order the top level pages visible in the
> navigation panel.
> * the whitelist can be used to show at the top level (for navigation
> purpose) a page that is not really a top level page
> * No performance penalty
>
> Cons:
> * The user (top level) pages created later on will not be visible in the
> navigation panel. The administrator will have to add them to the whitelist
> if they 

Re: [xwiki-devs] [Contrib] Request for a repository for a tool to export documents to spreadsheet

[Anca Luca]

Thanks!

On Fri, Feb 23, 2018 at 10:39 AM, Vincent Massol <vinc...@massol.net> wrote:

> Hi,
>
> Done:
> * Github: https://github.com/xwiki-contrib/application-export-spreadsheet
> * JIRA: https://jira.xwiki.org/browse/SPREADEXP
>
> Thanks
> -Vincent
>
> > On 23 Feb 2018, at 10:34, Anca Luca <lu...@xwiki.com> wrote:
> >
> > Hello Vincent,
> >
> >
> >
> > On Fri, Feb 23, 2018 at 10:31 AM, Vincent Massol <vinc...@massol.net>
> wrote:
> >
> >>
> >>
> >>> On 23 Feb 2018, at 10:24, Anca Luca <lu...@xwiki.com> wrote:
> >>>
> >>> Hello all,
> >>>
> >>> I would need a repository on xwiki-contrib to publish an extension to
> >> allow
> >>> exporting a bunch of documents to a spreadsheet format: one line per
> >>> document, with configurable columns read from the objects of those
> >>> documents.
> >>> Currently it exports only CSV but we could add other spreadsheet
> >>> formats (notably
> >>> xls), so it should have a more generic name than csv. Not sure if it
> >> would
> >>> contain other formats that are not spreadsheet-like, so I think
> >> spreadsheet
> >>> is enough.
> >>
> >> We need to find the name: http://contrib.xwiki.org/
> >> xwiki/bin/view/Main/WebHome#HChoosingthename
> >>
> >> application-spreadsheet ?
> >> application-spreadsheet-export ?
> >>
> >
> > application-export-spreadsheet ?
> >
> >
> >> Is it made of pages, does it have some Java JARs?
> >>
> >
> > only pages, for now. Could change in the future, though.
> >
> > Thanks!
> >
> >
> >>
> >> Thanks
> >> -Vincent
> >>
> >>>
> >>> Thanks,
> >>> Anca
>
>

Re: [xwiki-devs] [Contrib] Request for a repository for a tool to export documents to spreadsheet

[Anca Luca]

Hello Vincent,



On Fri, Feb 23, 2018 at 10:31 AM, Vincent Massol <vinc...@massol.net> wrote:

>
>
> > On 23 Feb 2018, at 10:24, Anca Luca <lu...@xwiki.com> wrote:
> >
> > Hello all,
> >
> > I would need a repository on xwiki-contrib to publish an extension to
> allow
> > exporting a bunch of documents to a spreadsheet format: one line per
> > document, with configurable columns read from the objects of those
> > documents.
> > Currently it exports only CSV but we could add other spreadsheet
> > formats (notably
> > xls), so it should have a more generic name than csv. Not sure if it
> would
> > contain other formats that are not spreadsheet-like, so I think
> spreadsheet
> > is enough.
>
> We need to find the name: http://contrib.xwiki.org/
> xwiki/bin/view/Main/WebHome#HChoosingthename
>
> application-spreadsheet ?
> application-spreadsheet-export ?
>

application-export-spreadsheet ?


> Is it made of pages, does it have some Java JARs?
>

only pages, for now. Could change in the future, though.

Thanks!


>
> Thanks
> -Vincent
>
> >
> > Thanks,
> > Anca
>
>

[xwiki-devs] [Contrib] Request for a repository for a tool to export documents to spreadsheet

[Anca Luca]

Hello all,

I would need a repository on xwiki-contrib to publish an extension to allow
exporting a bunch of documents to a spreadsheet format: one line per
document, with configurable columns read from the objects of those
documents.
Currently it exports only CSV but we could add other spreadsheet
formats (notably
xls), so it should have a more generic name than csv. Not sure if it would
contain other formats that are not spreadsheet-like, so I think spreadsheet
is enough.

Thanks,
Anca

Re: [xwiki-devs] A subtle problem with the Workflow Application and nested pages

[Anca Luca]

Hello Clemens,

Indeed, this is _one_ of the problems that the workflow application has on
a "nested" environment.

I think it's a good approach for the fix, the only thing that you should
try to take care of is to make this as generic as possible wrt the
configured draft space in the publication workflow config of the document
being published (fix links relative to this space). Don't hesitate, if
needed, to add a configuration of the "default publication space" in the
publication workflow config, I found the need for it in other situations as
well, so it won't hurt.

Also, one issue I can think of (which is related to the other issues that
publication workflow has on nested) is that the page to which the link is
might not yet be published, and in this case, imo, the link should be
refactored and be a "broken link" until the target page gets published.

Thanks for working on this,
Anca

On Thu, Nov 30, 2017 at 12:10 AM, Clemens Robbenhaar  wrote:

> Hi Devs,
>
>  some users reported a problem to me concerning the Publication Workflow
> Application and the nested pages feature.
> The problem is as follows:
>
>  In their old instance (some 6.4.x) they had a draft space and a public
> space and workflows attaching each page in the draft space with a page in
> the public space in an 1:1 manner, like:
>
>   Draft.WebHome --> Public.WebHome
>   Draft.PageA   --> Public.PageA
>   Draft.PageB   --> Public.PageB
>
> Now if a link in, say, PageA in the Draft space points to another page,
> e.g. PageB, this is done via a relative link like [[link text>>doc:PageB]]
> After publishing PageA, the link of the published variant points to the
> published variant of PageB (and not the variant in the Draft space), which
> is the desired effect from the users point of view.
>
> Now after migration to 9.10 the situation is as follows:
>
>   Draft.WebHome--> Public.WebHome
>   Draft.PageA.WebHome  --> Public.PageA.WebHome
>   Draft.PageB.WebHome  --> Public.PageB.WebHome
>
> Now a link to PageB in PageA looks like: [[link
> text>>doc:Draft.PageB.WebHome]] because both pages are no longer in the
> same space, but each in their own space.
> Publishing the draft makes the link in the published variant point back to
> the Draft space, of course. However this is different from the behavior
> before nested pages and the users experience this as a bug.
>
> A manual solution would be to edit all pages and make the links point to
> the published variant of the pages. However this is not only a cumbersome
> and error prone task, but also the users are used to the "automatic" link
> conversion that made links in the published variant point to published
> pages and are wont to continue setting links to pages in the draft space,
> expecting them to point to the "right place" after publishing.
> The fact that now titles are used throughout in the navigation tree, and
> the titles of the draft and published variant are usually the same and thus
> indistinguishable complicates the problem even more.
>
> To fix this I could write a separate extension that listens to Publish
> events send from the Workflow extension, and which converts the links in
> the published variant before it gets saved.
> However I remember that I once experienced strange issues where the events
> were sometimes not send to the event listener in question, probably due
> some class loader issues or the like.
> (I only experienced these problems in a production instance and was not
> able to hunt them down in a development instance.)
>
> Also I cannot think of a use case where users want to link from a
> published variant back into the draft space (except for pointing to the
> draft version of the page itself, which is provided by the panel, however.)
>
> Thus I would like to implement the link transformation in the extension
> itself. If a link in a page points to a page in the draft space of that
> workflow, I would change that link in the published variant to point to the
> corresponding published variant of the link target.
> I could add a checkbox to the workflow class so people can switch of that
> link transformation if they do not want it.
>
>
> What do you think? Are there any objections to implementing such a
> feature? Or do you have different ideas how to solve the problem?
>
> Best Regards
> Clemens
>

Re: [xwiki-devs] [Proposal] Using the browser's print feature instead of our PDF Export for the UI

[Anca Luca]

Hello Vincent, all

Thanks for these clear responses.
See below some more info, from my experience.



On Thu, Jan 26, 2017 at 11:15 AM, Vincent Massol  wrote:

> Hi everyone,
>
> Thanks to everyone who answered on this topic and help brainstorm about
> it. I made a mistake sending this as a proposal; I should have sent it as a
> brainstorming instead.
>
> Note that I’ve also discussed with Anca yesterday and she told me that I
> haven’t been nice in the way I answered her questions (not explaining
> enough and throwing off her questions). I wanted to publicly apologise for
> this since this wasn’t my intention and when reading my answers again I can
> see why this was felt this way. Let me try to improve below :)
>
> I also failed to explain properly the context that led me to send this
> email: our roadmap for 9.0/9.1/9.2 had the table issue to fix (there was 2
> days allocated to it) and Guillaume worked on analysing it and the
> conclusion was that it would take more than 2 days and would need to send
> some PR (or fork) FOP and thus this issue is now dropped for 9.0/9.1/9.2. I
> was trying to think out of the box and in order to provide a solution to
> Olivier Seres (who raised the issue recently) I proposed to him that he
> used the browser’s print feature and it did work better for this specific
> use case. So I thought to myself: maybe there’s some value in using this
> more.
>
> So let me try to recap what was said and reach a conclusion on this thread.
>
> Features needed:
> ==
>
> * Table of contents. This is a difficult one. We can have a TOC generated
> in our print.vm. The hard part is finding out the corresponding page
> numbers for the use case when the user wants to print the PDF. It could
> maybe be solved by setting fixed margins/paper size/orientation. But it
> doesn’t look easy. I haven’t checked how it’s done in the PDF export though
> so I could be wrong.
>

As far as I remember, this is relying on an xsl-fo feature, the same one
that we use to obtain the number of printed pages (when we print
pagination, in footer, like 1/3, 2/3).


>
> * Page headers/footers. This is also a difficult one because even though
> this is part of the css3-page spec, it’s not yet implemented by browsers
> and especially by chrome. There are plenty of people trying to do this when
> I googled it with various more or less successful options. A promising
> possibility was the position:fixed option but it has its own issues (chrome
> said they fixed the issue but not sure it’s true) and we’d need to make
> sure that the text really goes in the margin and not in the content. It’s
> possible that a combination of various solutions depending on the browser
> could work but it’s not perfect and it’s complex.
>
> * Margin sizes/orientation/paper size. This seems supported by the @page
> CSS element and I saw it was mentioned to be supported by chrome but I
> didn’t get to test it nor across browsers. To be tested.
>
> * Local links. This should be ok I think since in the print.vm we can
> control which XWikiServletURLFactory to use and generate anchors for local
> links. This is essentially what we’re already doing for HTML export in the
> ExportURLFactory class. However Anca raised the point that it doesn’t seem
> to work on FF. Would need to be checked further.
>
> * External links. I don’t think there’s any real issue here. I tried
> PDF-printing a web page with links and it worked fine. I think the reason
> it doesn’t work when doing this in xwiki could be because of our print.css
> which removes the display of “a”:
>
> #commentform, .xwikitabbar li, #Historyshortcut, #Informationshortcut,
> .separator,
> .commentheader .commenttools a, a.tag-delete , .tag-add a {
>   display: none !important;
> }
>
> * Browser-dependent result. True. In addition we’d need to ensure that
> browser offer a print to PDF feature. I know this is true on Mac and also
> on FF in unix (on Thomas’s computer and I think Thomas told me he didn’t
> have any add on). Haven’t checked other combinations. Denis mentioned that
> it’s not the default in Windows < 10.
>
> Research
> 
>
> The following alternatives to FOP exist but have their own limitations
> (see Denis answer for details):
> * PDF Clown
> * PDFBox
> * wkhtmltopdf
> * pdfkit
> * iText
> * Flying saucer, see http://flyingsaucerproject.github.io/flyingsaucer/r8/
> guide/users-guide-R8.html#pdf
>
> Conclusions
> =
>
> I feel there are several main use cases:
>
> * Wanting to print the current page. The browser print feature could work
> fine for this if we were to improve a bit our print.css (inherit from
> view.css for example)
> * Wanting to have some professional quality PDF export. There’s no doubt
> that the best solution for this is ATM our FOP-based PDF export and w
> * Scripted PDF exports (to generate invoices automatically for example).
> Again our FOP-based PDF export is the best answer.
>
> So I agree with all of you 

Re: [xwiki-devs] [Proposal] Using the browser's print feature instead of our PDF Export for the UI

[Anca Luca]

On Fri, Jan 20, 2017 at 2:10 PM, Vincent Massol <vinc...@massol.net> wrote:

> Hi Anca,
>
> > On 18 Jan 2017, at 18:05, Anca Luca <lu...@xwiki.com> wrote:
> >
> > Interesting, however, I see at least 2-3 possible limitations:
> >
> > * we will drop cover and table of contents
>
> Actually we won’t. The idea would be to have to a Print button inside
> XWiki (right now we have Print Preview) and we would add support for cover
> + TOC in print.vm.
>
> > * browsers (operating systems?) that don't have print to pdf option, will
> > not have this working anymore
>
> I think all OSes support this. Do you have any meaningful OS/Browser in
> mind? We could still leave it as an option to use our PDF Export if users
> need it.
>
> > * less customizations will be possible on this PDF (e.g. can we control
> > header / footer of the browser's print to PDF? Margins size, etc)
>
> Yes we can. This is controlled by the Browser which allows you to
> customise this.
>
> For the content of header/footer that’s easy, that would be the print.vm
> controlling them.
>

Could you please link me to some documentation (or element name or
something) that would help me understand more precisely what technology we
could use to achieve this?

Thanks


>
> > * multipage pdf export (that we currently have in multiple forms) will
> have
> > to be re-thought
>
> Yes indeed. We would still be able to support this if we want by having
> our print.vm support it.
>
> > * will links continue to work properly as links inside the pdf ( I will
> > need to test - actually, I was talking about links that link to another
> > place in the PDF, but while testing I realized that my Firefox did not
> > export any link as link in pdf - internal or external - it only exported
> > text)
>
> Actually that should work better than what we have now ;)
>
> Note that we can do anything we want since we control the print.vm so we
> can use any XWikiServletURLFactory we want.
>
> > * as resulting from the previous small test but easy to generalize: the
> > result of this feature will start to be browser dependent .
>
> So we control the layout completely. Then indeed it’s up to the browser to
> print. I don’t know if various browser print thing differently and how much
> difference there are between them.
>
> All I know is that they’ve spent way more men/hours than we’ve done on
> making a nice print ;)
>
> So again my goal in this proposal is to benefit from the Print feature of
> browsers, externalise the feature as much as possible (similar to what
> we’ve done with CKEditor). I wouldn’t want to drop our PDF export since it
> has some use cases, for example for generating export from scripts.
>
> I’m only referring to the basic Print option here and to transform the
> Print Preview into a Print one and tune it a bit to look as nice as
> possible. And make the Export to PDF optional and off by default.
>
> Thanks
> -Vincent
>
> > For the problems of Apache FOP, does anyone have any idea what libraries
> do
> > other software use for this kind of functionality? (maybe there is a more
> > cool lib that we haven't found out about)
> >
> > Anca
> >
> >
> > On Wed, Jan 18, 2017 at 2:54 PM, Vincent Massol <vinc...@massol.net>
> wrote:
> >
> >> Hi devs,
> >>
> >> We have plenty of existing limitations in our PDF export (table
> >> autoresize, etc) which comes from FOP and our usage of it. And it’s
> hard to
> >> improve it.
> >>
> >> I’d like to propose the following:
> >>
> >> * Promote the browser’s print to PDF feature instead of our PDF Export
> by
> >> triggering the browser’s print feature when clicking on Export > PDF in
> the
> >> UI.
> >> * Work on our print.css so that it has all the styles we have in view
> mode
> >> (right now for ex, info boxes for ex do not have a nice style).
> >> * Move our PDF Export java code out of xwiki-platform and into an
> optional
> >> extension that we move into xwiki-contrib. The use case for it would be
> >> when you need to generate PDF from scripts.
> >>
> >> WDYT?
> >>
> >> Thanks
> >> -Vincent
>
>

Re: [xwiki-devs] [Proposal] Using the browser's print feature instead of our PDF Export for the UI

[Anca Luca]

On Fri, Jan 20, 2017 at 2:10 PM, Vincent Massol <vinc...@massol.net> wrote:

> Hi Anca,
>
> > On 18 Jan 2017, at 18:05, Anca Luca <lu...@xwiki.com> wrote:
> >
> > Interesting, however, I see at least 2-3 possible limitations:
> >
> > * we will drop cover and table of contents
>
> Actually we won’t. The idea would be to have to a Print button inside
> XWiki (right now we have Print Preview) and we would add support for cover
> + TOC in print.vm.
>
> > * browsers (operating systems?) that don't have print to pdf option, will
> > not have this working anymore
>
> I think all OSes support this. Do you have any meaningful OS/Browser in
> mind? We could still leave it as an option to use our PDF Export if users
> need it.
>
> > * less customizations will be possible on this PDF (e.g. can we control
> > header / footer of the browser's print to PDF? Margins size, etc)
>
> Yes we can. This is controlled by the Browser which allows you to
> customise this.


> For the content of header/footer that’s easy, that would be the print.vm
> controlling them.
>
> > * multipage pdf export (that we currently have in multiple forms) will
> have
> > to be re-thought
>
> Yes indeed. We would still be able to support this if we want by having
> our print.vm support it.
>
> > * will links continue to work properly as links inside the pdf ( I will
> > need to test - actually, I was talking about links that link to another
> > place in the PDF, but while testing I realized that my Firefox did not
> > export any link as link in pdf - internal or external - it only exported
> > text)
>
> Actually that should work better than what we have now ;)
>
> Note that we can do anything we want since we control the print.vm so we
> can use any XWikiServletURLFactory we want.
>

I'm not sure we fully understand eachother...

I printed to pdf with Firefox on Ubuntu the standard Sandbox.WebHome page
and none of the links we have in there are actually clickable, they are
plain text (in the Links section, with external links, or in the Table of
contents section, with internal links).

I don't understand exactly how XWikiServletURLFactory would help us control
links inside the pdf itself, if the pdf is generated by the client-side
software (it's true that html anchors seem to work for chrome, so that is
one way of doing it, but apparently not on firefox).

For the other points I would need to test more to see if they actually
answer what I am thinking of..

Anca



>
> > * as resulting from the previous small test but easy to generalize: the
> > result of this feature will start to be browser dependent .
>
> So we control the layout completely. Then indeed it’s up to the browser to
> print. I don’t know if various browser print thing differently and how much
> difference there are between them.
>
> All I know is that they’ve spent way more men/hours than we’ve done on
> making a nice print ;)
>
> So again my goal in this proposal is to benefit from the Print feature of
> browsers, externalise the feature as much as possible (similar to what
> we’ve done with CKEditor). I wouldn’t want to drop our PDF export since it
> has some use cases, for example for generating export from scripts.
>
> I’m only referring to the basic Print option here and to transform the
> Print Preview into a Print one and tune it a bit to look as nice as
> possible. And make the Export to PDF optional and off by default.
>
> Thanks
> -Vincent
>
> > For the problems of Apache FOP, does anyone have any idea what libraries
> do
> > other software use for this kind of functionality? (maybe there is a more
> > cool lib that we haven't found out about)
> >
> > Anca
> >
> >
> > On Wed, Jan 18, 2017 at 2:54 PM, Vincent Massol <vinc...@massol.net>
> wrote:
> >
> >> Hi devs,
> >>
> >> We have plenty of existing limitations in our PDF export (table
> >> autoresize, etc) which comes from FOP and our usage of it. And it’s
> hard to
> >> improve it.
> >>
> >> I’d like to propose the following:
> >>
> >> * Promote the browser’s print to PDF feature instead of our PDF Export
> by
> >> triggering the browser’s print feature when clicking on Export > PDF in
> the
> >> UI.
> >> * Work on our print.css so that it has all the styles we have in view
> mode
> >> (right now for ex, info boxes for ex do not have a nice style).
> >> * Move our PDF Export java code out of xwiki-platform and into an
> optional
> >> extension that we move into xwiki-contrib. The use case for it would be
> >> when you need to generate PDF from scripts.
> >>
> >> WDYT?
> >>
> >> Thanks
> >> -Vincent
>
>

Re: [xwiki-devs] [Proposal] Using the browser's print feature instead of our PDF Export for the UI

[Anca Luca]

Interesting, however, I see at least 2-3 possible limitations:

* we will drop cover and table of contents
* browsers (operating systems?) that don't have print to pdf option, will
not have this working anymore
* less customizations will be possible on this PDF (e.g. can we control
header / footer of the browser's print to PDF? Margins size, etc)
* multipage pdf export (that we currently have in multiple forms) will have
to be re-thought
* will links continue to work properly as links inside the pdf ( I will
need to test - actually, I was talking about links that link to another
place in the PDF, but while testing I realized that my Firefox did not
export any link as link in pdf - internal or external - it only exported
text)
* as resulting from the previous small test but easy to generalize: the
result of this feature will start to be browser dependent .

For the problems of Apache FOP, does anyone have any idea what libraries do
other software use for this kind of functionality? (maybe there is a more
cool lib that we haven't found out about)

Anca


On Wed, Jan 18, 2017 at 2:54 PM, Vincent Massol  wrote:

> Hi devs,
>
> We have plenty of existing limitations in our PDF export (table
> autoresize, etc) which comes from FOP and our usage of it. And it’s hard to
> improve it.
>
> I’d like to propose the following:
>
> * Promote the browser’s print to PDF feature instead of our PDF Export by
> triggering the browser’s print feature when clicking on Export > PDF in the
> UI.
> * Work on our print.css so that it has all the styles we have in view mode
> (right now for ex, info boxes for ex do not have a nice style).
> * Move our PDF Export java code out of xwiki-platform and into an optional
> extension that we move into xwiki-contrib. The use case for it would be
> when you need to generate PDF from scripts.
>
> WDYT?
>
> Thanks
> -Vincent

Re: [xwiki-devs] [Brainstorming] Restrict parent page based on its type

[Anca Luca]

Hello Marius,

I think the topic of dynamic configuration of available templates is a very
good topic.

The only problem I see with the solution above is that it might cover only
a subset of the dynamic templates that we might want to configure, and once
we add this mechanism it will be harder to take it back to replace it with
a more generic one. So it would interesting to make a collection of
usecases for dynamic template configuration that we have, to see how many
of them we can cover with the mechanism you proposed (you called the thread
"Brainstorming" :) )

The usecases I had so far or that I can think of:
* template should be available only in documents that have a specific name,
under a grandparent in the tree which is typed (in my case, I had subtrees
dedicated to departments, with an object to configure departments, and
then, in the children of these departments a page always had the same name
(say, "Ideas") and here the Idea template had to be available. This usecase
can be reduced to your case, if we create a class for the Ideas homepage
and restrict the ideas template to this class
* template should be available under a parent but only first level. E.g.
Ideas can be created, they are created as non-terminal because regular
pages need to be linkable under, but an Idea should not be creatable under
an Idea. This would need a different mechanism, what you proposed is not
enough. This usecase can also be reduced to your usecase, provided that the
parentType is about the direct parent (and not ancestor).
* template should be available in a subtree (all descendants) of a page
with a given type, not only as a direct child.
* Edy mentioned in a mail blacklisting, I think I had that case too (having
a page that is the exception to the general rule on the wiki, rather than
the other way around)
* preventing blank XWiki pages from being created in a subtree, only
allowing a structured page (from a template) to be created in a given place
in the tree (kind of like the "add new application entry" of AWM, but
through the + button)

Note that, for the first 2 cases, reducing them to your usecase would mean
to create a class only for this, for binding the provider to it as a
parent. This is not something that an App within minutes does, for example,
although it covers the roughly the same usecase (non structured page is the
parent of multiple structured pages).

One of the ideas I had at some point was allowing a parent to configure the
available templates under it, and not the other way around, but I don't
have much more details about this (would they be preferences?, would it be
an object?, etc).

I would have to think more about this before giving a final answer,
Anca





On Tue, Nov 29, 2016 at 10:23 AM, Marius Dumitru Florea <
mariusdumitru.flo...@xwiki.com> wrote:

> Hi devs,
>
> I have an XWiki application that creates two types of pages. Let's call
> them Category and Procedure. The application has two template providers
> that allow the users to create Categories and Procedures anywhere on the
> wiki using the Create Page menu. I would like to restrict the creation like
> this:
>
> * You can create a new Category page either as a top level page or as a
> child of an existing Category page
> * You can create a new Procedure page only as a child of an existing
> Category or Procedure page
>
> Category -> ... Category -> Procedure -> ... -> Procedure
>
> One solution to achieve this is to add a new property to the template
> provider, e.g. "parentType", that specifies the type of pages (XClass
> references) that are allowed as parent. We would use a Database List with
> multiple selection and relational storage. We can use the empty string to
> represent "no parent" (i.e. top level page). An empty list would mean no
> parent type restriction.
>
> Category template provider: {parentType: ["CategoryClass", ""]}
> Procedure template provider: {parentType: ["CategoryClass",
> "ProcedureClass"]}
>
> Do you think this is useful? Do you see any problem with this solution? Is
> it worth implementing?
>
> Thanks,
> Marius
>

Re: [xwiki-devs] [Idea] XClass Preferences

[Anca Luca]

Hello all,



On Tue, Nov 29, 2016 at 9:47 AM, Marius Dumitru Florea <
mariusdumitru.flo...@xwiki.com> wrote:

> Hi devs,
>
> I have an XWiki application that has a template provider which allows the
> users to create application entries anywhere on the wiki using the Create
> Page menu. I would like to control entirely how application entries are
> displayed to the user. I can do this partially from my sheet but:
>
> * I can't control the panels. I would like to display panels that are
> specific to my application whenever a user is viewing an application entry,
> no matter where the application entry is located.
>

Note that this was possible, until http://jira.xwiki.org/browse/XWIKI-8269
was implemented (you'd set a variable in the sheet of the page, containing
a list of panels, just like we do for docextra tabs). I would have liked
that feature to stay as well.
I see usecases for it, but I also remember we had problems with an
application arriving on the wiki and imposing its panels, the Blog app. At
some point, the Blog app was setting both panel sets, left and right, and
we had an issue with that because we had setup the applications panel
navigation for the whole wiki as a panel in the left panels, and the fact
that the Blog app was overwriting it was a problem.

* I can't control the color theme or the icon theme. I would like to use a
> custom color theme and icon theme without affecting the other pages from
> the wiki.
>

I'm not sure I like that much the idea of changing the colors of the whole
UI whenever the type of page changes in the wiki, although I see a usecase.
I am wondering if a little color adjustment could not be handled through an
SSX, pulled by the proper sheet at the proper moment.


> * I can't control the layout (the skin). I can hide the extra tabs from the
> sheet but I can't hide a panel column or control the panel column width.
>

The examples you gave are still related to panels. I would be curious what
other elements of the skin could be customizable by an application.


>
> One solution to fix my problem is to introduce XClass Preferences, same as
> we have page and wiki preferences. XClass preferences would have priority
> over page and wiki preferences, inheriting from them. We can implement it
> using either a naming convention, Preferences, or using some
> xobject on the XClass, similar to the ClassSheetBinding xobject.
>
> Do you see any problem with solution? I can think of one: access rights.
> Does it make sense to have access rights specific to an XClass? E.g. "only
> this group can edit instances of this XClass".
>

Of course it does, but the other case makes sense as well (having the
rights be controlled classically, by the place where the page is rather
than by its type).


>
> Do you think it is worth implementing? Another solution would be to allow
> the sheet to overwrite some of the preferences, but the problem is that the
> sheet is executed after the page HTML has started to be written to the
> response.
>

What I don't like too much about these ideas is that we would basically be
adding a mechanism that would allow a page type to influence the whole UI /
wiki. Note that this is how currently the languages work (seeing a page in
french also changes the languague of the whole UI to french), and we're not
that convinced it's a good thing (I've heard it seen as a feature almost as
many times as I've heard it seen as a bug).

So, to me, it is good to have developement tools that would allow to
customize these, and we need to be able to control these as a developer,
but I think that an extra mechanism would add extra complexity (as Edi
said) and still not be as generic enough as the development solutions we
currently have (e.g. you wouldn't be able to remove the extra tabs
conditionally, say, depending on the current user role).

So I would be more for giving more control to the sheet (if we could
improve some vms evaluation in the skin, for example), but keeping these
customizable in the sheet rather than with an additional preference
mechanism.

I am still thinking, I see the pros and cons for this as well...


Thanks,
Anca


>
> Thanks,
> Marius
>

Re: [xwiki-devs] [Contrib][BatchImport] Release of batch import application version 1.2

[Anca Luca]

The release is done, the new version 1.2 is available on maven and will
soon be available on extensions.xwiki.org as well.

Anca

On Wed, Oct 5, 2016 at 6:04 PM, Anca Luca <lu...@xwiki.com> wrote:

> Hello all,
>
> Alex and I have fixed a couple of issues on the batch import application
> (issues BATCHIMP-1,2,3,4,5,6) and I would like to release version 1.2 of
> this application.
>
> Functionally, these changes bring translations being properly activated
> when the app is installed, one more option configurable from the UI (clear
> names) and some support for the new format of AWM (the nested spaces one).
> It does not break compatibility, as I managed to write code that should
> work fine in all cases (nested or not).
>
> If nobody has anything against, I will release this tonight.
>
> Thanks a lot,
> Anca
>
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

[xwiki-devs] [Contrib][BatchImport] Release of batch import application version 1.2

[Anca Luca]

Hello all,

Alex and I have fixed a couple of issues on the batch import application
(issues BATCHIMP-1,2,3,4,5,6) and I would like to release version 1.2 of
this application.

Functionally, these changes bring translations being properly activated
when the app is installed, one more option configurable from the UI (clear
names) and some support for the new format of AWM (the nested spaces one).
It does not break compatibility, as I managed to write code that should
work fine in all cases (nested or not).

If nobody has anything against, I will release this tonight.

Thanks a lot,
Anca
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [contrib][workflow-publication][Proposal] request for a new release on Tuesday (6.9.)

[Anca Luca]

Hello Clemens, all

On Mon, Sep 5, 2016 at 1:24 PM, Vincent Massol  wrote:

> Hi Clemens,
>
> > On 03 Sep 2016, at 22:04, Clemens Klein-Robbenhaar <
> c.robbenh...@espresto.com> wrote:
> >
> > Hi Devs,
> >
> > if nobody objects I would like to cut a new release for the Publication
> Workflow Application
> > at http://extensions.xwiki.org/xwiki/bin/view/Extension/
> XWiki+Publication+Workflow+Application
> >
> > The version number would be 1.7
> >
> > I would like to make the release on Tuesday (unless Monday is a bank
> holiday or the like, in case of the release date shifts to Wednesday)
> >
> > The release would fixes the following issues:
> >
> > http://jira.xwiki.org/browse/XAWORKFLOW/fixforversion/16658
> >
> > The main change would be some basic support for multi-language
> documents, which I know someone would really appreciate.
> >
> > There are two new translation keys:
> >
> > one is introduced for XAWORKFLOW-27 and is shown in the workflow panel
> as a hint
> > for the publisher who is publishing a multi-language document, informing
> about the fact that all language variants are going to be published
> >
> > workflow.panel.publish.hintLanguages
> >
> > and one that showed up as missing while checking XAWORKFLOW-28:
> >
> > PublicationWorkflow.PublicationWorkflowConfigClass_groupedit_hint =
> Edit Workflow Group
> >
> > Unfortunately the default "Translations" document is in French, and as I
> did not want to show in translation key for unsupported languages, I just
> filled in an English text.
> > If someone could replace these "dummy translations" with a proper French
> text this would be really appreciated.
> >
> >
> > Are there any objections to the release? Does someone want more time to
> look at the changes?
>
> This looks good to me. FYI I’ve pinged Anca who’s the creator of this
> extension AFAIK.
>

I looked really quickly at the code and I made two comments on the commits
in question. I am not against the release, but I would feel more
comfortable if we addressed these two commits.

But then again, if you're in a hurry, you can release 1.7 like this (which
risks to have some issues) and then fix the subjects addressed in these
comments in subsequent 1.7.x .

Anca


>
> > Cheers
> > Clemens
> >
> > P.S. if there are no objections I can handle most parts of the release
> on my own, but need a bit of help with updating the versions in JIRA.
>
> Sure, I can help if need be.
>
> Thanks
> -Vincent
>
> ___
> 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

Re: [xwiki-devs] [Contrib][Ratings] Release a bugfix version of the ratings application from the contrib project

[Anca Luca]

Hello,

here is what was done on the ratings application for this release:
* a branch was created on contrib for maintaining the bugfix old version:
https://github.com/xwiki-contrib/application-ratings/tree/stable-1.3.x
* version 1.3.5 was released from this branch
* for the 3 problems fixed on this version, the following was done:
- one issue did not reproduce on the latest version of platform ratings
- the one from commit 07758a698d400ed275cde1e6fde4515d41711b40 : the fact
that saving ratings in different spaces did not work
- a second issue did reproduce and was reported (the one fixed in
commit cd2c190e22f709e2b55fed19be25ea8ef7631730), but was not yet fixed:
http://jira.xwiki.org/browse/XWIKI-13545 . However, this is not a critical
bug (not even sure if it's a bug, is more a configuration that is not
followed). It would need to be analysed and defined the correct desired
behaviour in the ratings application
- the third issue reproduced, was reported and fixed in
http://jira.xwiki.org/browse/XWIKI-13543 (the one from commit
4a5ed2ca13d1a01962a7d9edeb8b34134a6ad704 ).

Hope this is acceptable for the contrib rules.

Note: all the work was done by https://github.com/rstavro , I am just the
messenger.

Thanks,
Anca

On Wed, Jun 29, 2016 at 11:51 AM, Ecaterina Moraru (Valica) <
vali...@gmail.com> wrote:

> I agree to release this version, only if it's tested and fixed on Platform
> too (8.x+ or even 7.4.x+). Only in this case we could consider it to be a
> bugfix release.
> And if we don't do the testing now, it will not be done at all, thus
> forking the code.
>
> To be honest, I would prefer to delete / remove the commits rights for
> applications that we move in Platform or not move things in Platform
> anymore and keep separate version for them (... etc the whole discussion
> about Contrib).
>
> Thanks,
> Caty
>
>
> On Wed, Jun 29, 2016 at 12:45 PM, Anca Luca <lu...@xwiki.com> wrote:
>
> > Hello all,
> >
> > while using the ratings application on an XWiki 6.2.4, we encountered
> some
> > bugs related to the storage of ratings in a separate space and with the
> > update of a user's rating.
> >
> > We fixed them in these 2 commits:
> >
> >
> https://github.com/xwiki-contrib/application-ratings/commit/07758a698d400ed275cde1e6fde4515d41711b40
> > and
> >
> >
> https://github.com/xwiki-contrib/application-ratings/commit/cd2c190e22f709e2b55fed19be25ea8ef7631730
> > .
> >
> > Now, the contrib ratings application was indeed "retired" so we normally
> > should not use the contrib repo anymore.
> > However, the work in these 2 commits is about fixing bugs (which might
> even
> > be affecting the most recent version of ratings - we need to check that,
> > didn't check it yet), and I don't see exactly what other option we have
> in
> > this case (note that we cannot switch to the "platform ratings" as we're
> on
> > XWiki 6.2.4 and ratings are in platform since 6.4.
> >
> > So, this is what I propose:
> > * release a 1.3.5 version from the contrib code
> >   - if I understand correctly how extensions.xwiki.org works, this
> release
> > will not appear as "most recent" on the application page
> >   - if I understand correctly how maven works, this version will not be
> > considered more recent than 8.1 even if released after, because of the
> > version number.
> > * this means that the version 1.3.5 will be available as an upgrade to
> the
> > users that use the contrib extension (v 1.3.4 or lower), will be
> available
> > for new install to all users for which the dependencies requirements are
> > satisfied and will not impact the users which use the platform version of
> > the ratings app.
> > Please let me know if I'm wrong in my reasoning.
> >
> > The advantage of this release would be publishing the bugfix work that
> > we've done and making it available to all users of the ratings extension
> on
> > versions lower than 6.4.
> > Also, for us the advantage would be not having to deal with a code fork
> and
> > manage a release / snapshot of this forked code separately.
> >
> > Unless somebody -1s this in the very close feature, we will go ahead with
> > the release.
> >
> > Thanks,
> > Anca
> >
> > P.S. There is a larger discussion to have about how to provide bugfixes
> on
> > older versions of platform applications without upgrading all the wiki,
> but
> > this should be in another mail or on IRC (e.g. if we discover that indeed
> > these issues affect ratings app, the platform version, and we make fixes
> > for these bugs, how can we provide these fixes to an XWiki 6.4 user?)
> > ___
> > 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

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

[Anca Luca]

On Mon, Jul 11, 2016 at 2:00 PM, Ecaterina Moraru (Valica) <
vali...@gmail.com> wrote:

> On Mon, Jul 11, 2016 at 2:54 PM, Anca Luca <lu...@xwiki.com> wrote:
>
> > Hello Caty,
> >
> >
> >
> > On Thu, Jul 7, 2016 at 4:12 PM, Ecaterina Moraru (Valica) <
> > vali...@gmail.com
> > > wrote:
> >
> > > Hi,
> > >
> > > By default there are not many page templates an user could see.
> > > In order for users to understand the power and purpose of XWiki, it
> would
> > > be helpful to add more content templates by default.
> > >
> > > Content Templates are templates that don't belong to a particular
> > > application, but provides an initial content structure. The templates
> > will
> > > be suggested in the creation step.
> > >
> > > Here are some templates we could add by default:
> > >
> >
> http://design.xwiki.org/xwiki/bin/view/Proposal/TemplatesDefault#HProposal
> > > 1. Article
> > > 2. Encyclopedia
> > >
> >
> > I think these two are the same one, they should be collapsed into only
> one
> > template. I don't really understand the differences between these two.
> >
>
> The differences are in layout.
>

In my opinion this is not enough to have both of them. For me, the goal of
the templates by default is to help discover the template feature and its
benefits to users, and the way to do that would be to show interesting
usecases of the template feature. Having two templates for the same usecase
but with different layout is not aligned with this goal, but would be more
aligned with the goal of showing that we can do different fancy layouts. In
addition, this logic would allow to have multiple templates for the other
usecases as well, with different layout, which would not be a good idea
(e.g. another meeting report, with a different layout) because would bloat
the list...

Anyone else?

Thanks,
Anca


>
>
> >
> >
> > > 3. Meeting
> > >
> >
> > Should be called Meeting Report (or meeting notes), so that the
> difference
> > with the meeting extension is more obvious.
> >
>
> I will use "Meeting Report"
>
>
> >
> > > 4. Simple Page
> > >
> >
> > Should have the word Table of Contents in the name, so that its purpose
> is
> > obvious from the start (otherwise "simple page" and the default "blank
> > page" are not very easy to differentiate ).
> >
> >
> The difference is viewed in the Description, see
>
> http://design.xwiki.org/xwiki/bin/download/Proposal/TemplatesDefault/WebHome/descriptions.png
>
> Thanks,
> Caty
>
>
> > Another template could be added, "Index page", with a simple livetable
> > listing all the children (and descendants) pages of the current page.
> It's
> > handy when creating the root page of a subtree on the wiki (would have
> the
> > same purpose as "Dashboard", to be a scripted homepage from where the
> > subtree of that page can be accessed).
> >
> > Thanks,
> > Anca
> >
> >
> > >
> > > You can test them on
> > > http://design.xwiki.org/xwiki/bin/view/Proposal/TemplatesDefault/ (use
> > the
> > > Create button)
> > >
> > > Please vote if you agree these templates should be added by default or
> > > otherwise let me know your feedback.
> > >
> > > Thanks,
> > > Caty
> > > ___
> > > 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
>
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

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

[Anca Luca]

Hello Caty,



On Thu, Jul 7, 2016 at 4:12 PM, Ecaterina Moraru (Valica)  wrote:

> Hi,
>
> By default there are not many page templates an user could see.
> In order for users to understand the power and purpose of XWiki, it would
> be helpful to add more content templates by default.
>
> Content Templates are templates that don't belong to a particular
> application, but provides an initial content structure. The templates will
> be suggested in the creation step.
>
> Here are some templates we could add by default:
> http://design.xwiki.org/xwiki/bin/view/Proposal/TemplatesDefault#HProposal
> 1. Article
> 2. Encyclopedia
>

I think these two are the same one, they should be collapsed into only one
template. I don't really understand the differences between these two.


> 3. Meeting
>

Should be called Meeting Report (or meeting notes), so that the difference
with the meeting extension is more obvious.


> 4. Simple Page
>

Should have the word Table of Contents in the name, so that its purpose is
obvious from the start (otherwise "simple page" and the default "blank
page" are not very easy to differentiate ).

Another template could be added, "Index page", with a simple livetable
listing all the children (and descendants) pages of the current page. It's
handy when creating the root page of a subtree on the wiki (would have the
same purpose as "Dashboard", to be a scripted homepage from where the
subtree of that page can be accessed).

Thanks,
Anca


>
> You can test them on
> http://design.xwiki.org/xwiki/bin/view/Proposal/TemplatesDefault/ (use the
> Create button)
>
> Please vote if you agree these templates should be added by default or
> otherwise let me know your feedback.
>
> Thanks,
> Caty
> ___
> 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

Re: [xwiki-devs] Integration of ratings in xwiki-platform

[Anca Luca]

Hello Caty,

I just sent a mail entitled "Release a bugfix version of the ratings
application from the contrib project" about this particular project, not
all retired projects, if you want to discuss this topic on a very specific
use-case. This mail discusses the modification of the old project out of a
_need_ and not "by mistake".  Preventing modifications "by mistake" would
be yet another topic...

Indeed there is a generic strategy to discuss, also in the context of what
Eduard said below (moving projects out of platform and in contrib back
again could make things a little bit easier...). And I don't know of the
existance of such a strategy either.

Thanks,
Anca



On Mon, Jun 27, 2016 at 4:09 PM, Ecaterina Moraru (Valica) <
vali...@gmail.com> wrote:

> Do we have a strategy for retired projects?
>
> They have been marked as [Retired] in JIRA, but this doesn't prevent users
> from creating issues or add new code there.
> Should we have deleted the contrib sources? Should we at least change
> permissions and restrict creation of issues and code commits? Do we plan to
> maintain in parallel the 2 repos?
>
> Thanks,
> Caty
>
> On Thu, Dec 4, 2014 at 2:29 PM, Victor Rachieru  >
> wrote:
>
> > The new module can be a new version of the one on xwiki-contrib and not
> > break the extensions that have a dependency to the old module.
> >
> > The script service basically remains intact. The methods contained by
> that
> > service maintain the same signatures. Nothing has changed from this point
> > of view.
> > So previous versions of the ratings module (the ones from contrib) can
> use
> > the service just as before without it breaking things.
> >
> > The issue that arises from changing the package name is that any code
> that
> > uses classes from that package explicitly will be broken.
> >
> > Example:
> > -
> > Say you have a java or groovy script in which you
> > want to use a class from the ratings api package or typed variables. That
> > code will be broken due to the fact that packages don't match anymore.
> >
> > org.xwiki.contrib.ratings.Rating myRating = new
> > org.xwiki.contrib.ratings.Rating();
> > or
> > org.xwiki.contrib.ratings.RatingAPI myRating =
> > services.ratings.getRating(doc, author);
> >
> > on the other hand
> >
> > services.ratings.getRating(doc, author).getVote(); should be ok
> >
> >
> > The question is:
> > -
> > Is there somebody who used classes from the api package in their code or
> > the use of this module has been limited to calling the service from
> > velocity and just setting/getting votes?
> >
> > Thanks,
> > Victor
> >
> > On Wed, Dec 3, 2014 at 5:30 PM, Thomas Mortagne <
> thomas.morta...@xwiki.com
> > >
> > wrote:
> >
> > > On Wed, Dec 3, 2014 at 4:11 PM, Victor Rachieru
> > >  wrote:
> > > > Hei devs,
> > > >
> > > > I intend to integrate the ratings application which is now on
> > > xwiki-contrib
> > > > into the xwiki-platform.
> > > >
> > > > This in mainly due to 3 points:
> > > > -
> > > > 1/ give the ability to use ratings in a wiki
> > > > 2/ using it to provide ratings for the Extension Repository
> Application
> > > > (XWIKI-7780)
> > > > 3/ display ratings within Extension Manager (XWIKI-11509)
> > > >
> > > > The first point can be accomplished by using the ratings app as is
> but
> > > the
> > > > other two imply that the ratings app should be a module that is
> > > maintained
> > > > by XWiki. It makes sense that if the Extension Repository App and
> > > Extension
> > > > Manager which are maintained by XWiki depend on the Ratings App, that
> > > this
> > > > itself is maintained by XWiki as well.
> > > >
> > > > The steps needed for this is as follows:
> > > > -
> > > > 1/ create a new module in the xwiki-platform core for the ratings
> > > > - xwiki-platform-core
> > > > -- xwiki-platform-ratings
> > > > --- xwiki-platform-ratings-api
> > > > --- xwiki-platform-ratings-ui
> > > > 2/ change the artifact id from "application-ratings" to
> > > > "xwiki-platform-ratings"
> > > > 3/ change the package from "org.xwiki.contrib.ratings" to
> > > > "org.xwiki.platform.ratings"
> > > >
> > > > Implications
> > > > -
> > > > 1/ clone of the existing code is now in xwiki-platform under a
> > different
> > > > artifact id (having duplicate code, this takes us to #2)
> > > > 2/ the code from xwiki-contrib would probably have to be deemed as
> > > "retired"
> > > > 3/ the applications with a dependency to the xwiki-contrib ratings
> > would
> > > > have to be upgraded to depend on the module from xwiki-platform
> > > > 4/ the script service would remain unchanged (changing the artifact
> id
> > > and
> > > > package name does not affect the service)
> > > > 5/ if by any chance someone has code that uses the classes from the
> > > ratings
> > > > app on contrib, by upgrading, that code will cease to function
> > > >
> > > > Please state you position on this matter.
> > > >
> > > > Links
> > > > 

[xwiki-devs] [Contrib][Ratings] Release a bugfix version of the ratings application from the contrib project

[Anca Luca]

Hello all,

while using the ratings application on an XWiki 6.2.4, we encountered some
bugs related to the storage of ratings in a separate space and with the
update of a user's rating.

We fixed them in these 2 commits:
https://github.com/xwiki-contrib/application-ratings/commit/07758a698d400ed275cde1e6fde4515d41711b40
and
https://github.com/xwiki-contrib/application-ratings/commit/cd2c190e22f709e2b55fed19be25ea8ef7631730
.

Now, the contrib ratings application was indeed "retired" so we normally
should not use the contrib repo anymore.
However, the work in these 2 commits is about fixing bugs (which might even
be affecting the most recent version of ratings - we need to check that,
didn't check it yet), and I don't see exactly what other option we have in
this case (note that we cannot switch to the "platform ratings" as we're on
XWiki 6.2.4 and ratings are in platform since 6.4.

So, this is what I propose:
* release a 1.3.5 version from the contrib code
  - if I understand correctly how extensions.xwiki.org works, this release
will not appear as "most recent" on the application page
  - if I understand correctly how maven works, this version will not be
considered more recent than 8.1 even if released after, because of the
version number.
* this means that the version 1.3.5 will be available as an upgrade to the
users that use the contrib extension (v 1.3.4 or lower), will be available
for new install to all users for which the dependencies requirements are
satisfied and will not impact the users which use the platform version of
the ratings app.
Please let me know if I'm wrong in my reasoning.

The advantage of this release would be publishing the bugfix work that
we've done and making it available to all users of the ratings extension on
versions lower than 6.4.
Also, for us the advantage would be not having to deal with a code fork and
manage a release / snapshot of this forked code separately.

Unless somebody -1s this in the very close feature, we will go ahead with
the release.

Thanks,
Anca

P.S. There is a larger discussion to have about how to provide bugfixes on
older versions of platform applications without upgrading all the wiki, but
this should be in another mail or on IRC (e.g. if we discover that indeed
these issues affect ratings app, the platform version, and we make fixes
for these bugs, how can we provide these fixes to an XWiki 6.4 user?)
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [UX][Vote] Future of Main.Welcome

[Anca Luca]

+1 for 2.

I don't think we need a welcome message in the dashboard anymore.

On Mon, Jun 27, 2016 at 5:17 PM, Ecaterina Moraru (Valica) <
vali...@gmail.com> wrote:

> On Wed, Jun 22, 2016 at 2:24 PM, Vincent Massol 
> wrote:
>
> > Hi Caty,
> >
> > > On 21 Jun 2016, at 14:58, Ecaterina Moraru (Valica)  >
> > wrote:
> > >
> > > Hi,
> > >
> > > This thread is about deciding on a future for the Main.Welcome page.
> This
> > > page was used as the first gadget's content and was intended to be
> > modified
> > > by the users. In 8.2M2 we changed the content of Main.WebHome page to
> > > provide simple wiki text instead of the Dashboard include, deprecating
> > > somehow the purpose of the Welcome page.
> > >
> > > Problem: In the 'Navigation' panel the "Welcome to your wiki" is
> > displayed
> > > as a child page of "Home". Users might ask what is the purpose of this
> > page.
> > >
> > > We could either:
> > > 1. Keep it
> > > 1.A and mark it as hidden: in order to not be displayed in the
> Navigation
> > > tree
> > > 1.B and move it to Dashboard: instead of being in the Main space, since
> > now
> > > it's used only there.
> > > 1.C and change the text: from a generic 'Welcome' message, to
> > instructions
> > > on how to edit the Dashboard (we would need a separate proposal on the
> > > content + if we want to display other gadgets)
> > >
> > > 2. Remove it
> > > We could consider that its content is deprecated by the new
> Main.WebHome
> > > page, so no need for this page. So we could delete the page + remove it
> > > from Dashboard. Dashboard could highlight more advanced gadgets
> (needing
> > > the separate Dashboard proposal).
> > >
> > > Let me know what you think,
> >
> >
> > +1 for 2. It’s not needed anymore since it’s been replaced by the new
> home
> > page. It’s better to make the Dashboard useful right away (ie with useful
> > content).
> >
> > Now, I haven’t checked, but if we still generate subwiki’s home pages
> with
> > the Dashboard, I believe we may also want to review this (for some of the
> > same reasons we modified the main wiki’s home page, such as easiness of
> > editing it) and replace it with a new subwiki home page.
> >
>
> When we create subwikis, they have the same content as the main wiki (the
> new homepage and panels).
>
> Current Status:
> 1. Keep it: +1 (Edy), +0.5 (Marius), +0.5 (GD)
> 1.A and mark it as hidden:
> 1.B and move it to Dashboard: (Edy), (Marius), (GD)
> 1.C and change the text: (Marius), (GD)
> 2. Remove it: +0.5 (Marius), +1 (Vincent)
>
>
> Some questions:
> a. Do we have a procedure for deleting pages from l10n? a way to retire
> them? (some property in l10n + removal from the release script = [2])
> b. Do we have a procedure when the translations of a page change path?
> (like moving from Main space to Dashboard space = [1.B])
> c. Do we have a procedure for deprecating the whole content of a page?
> (let's say we don't do the move, we keep it in Main, how do we mark that
> the whole content is changed in English, but needs to be updated in the
> other languages? = [1.C])
>
> Thanks,
> Caty
>
>
> >
> > For me we should definitely not have some welcome message in the
> Dashboard
> > app anymore. It’s not its purpose.
> >
> > Thanks
> > -Vincent
> >
> > > Caty
> > ___
> > 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

Re: [xwiki-devs] [xwiki-users] Not able to create xwiki pages from PDF document

[Anca Luca]

Hello,

The pdf macro that you installed is for visualizing the pdf documents, not
for transforming them into a wiki page (importing their content as a wiki
page). That's what most of the extensions that you find under the "pdf"
search do.

For importing a pdf document as a wiki page, you should try the office
importer
http://extensions.xwiki.org/xwiki/bin/view/Extension/Office+Importer+Application
. This application is bundled by default in recent versions of XWiki, so
don't need to install anything, you'll just need to configure it properly.
The documentation mentions it imports PDF documents, so it should do what
you want (I personally didn't use it with pdf documents but it works fine
with other office documents).
Office importer application needs a running open office / libre office
server installed and running on the server on which XWiki is running,
please read carefully installation instructions here
http://extensions.xwiki.org/xwiki/bin/view/Extension/Office+Importer+Application#HPrerequisites26InstallationInstructions
especially the parts about configuring the office server.

Enjoy,
Anca


On Tue, Jun 7, 2016 at 3:07 PM, Prabhushankar T 
wrote:

> Hi
>
> I am trtying to explore Xwiki and stuck with creating pages fromexistiing
> PDF documents. I installed extention "PDF 3.0" macro and after the
> installation, it was not available in the macro list to use for page
> creation.
>
> Even though we have PDF Embedded viewer and PDF viewer are installed, PDF
> macro i snot listed. Please guide me how can I solve this page and create
> pages using PDF documents.
>
> PS: I don't want to insert PDF document as PDF viewer in any way. I want to
> make pages from the PDF documents.
>
> Please help me in this.
>
> --
> Thanks and Regards
> Prabhushankar
> Solus Security Solutions, Bangalore
> ___
> users mailing list
> us...@xwiki.org
> http://lists.xwiki.org/mailman/listinfo/users
>
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [UX] Page templates availability

[Anca Luca]

On Tue, Jun 7, 2016 at 5:13 PM, Anca Luca <lu...@xwiki.com> wrote:

> Hello all,
>
> On Mon, Jun 6, 2016 at 6:31 PM, Ecaterina Moraru (Valica) <
> vali...@gmail.com> wrote:
>
>> Hi,
>>
>> The Template Provider allows setting the locations where the template must
>> be available.
>> Some applications need/encourage their pages to be located in a particular
>> app location.
>> Currently, if we set such a location for a template, the template will be
>> listed in the "Create Page" step only if the user navigates to that
>> location and clicks on the "Add" button.
>>
>> One behavior could be that all templates are displayed each time the user
>> clicks on 'Add', regardless of the initial location.
>> This would mean splitting the current Location functionality into
>> "Template
>> Visibility" and "Creation location restrictions":
>> - Ideally "Template Visibility" should not be restricted, but we would
>> need
>> to keep this field in order to be backward compatible with the current
>> behavior.
>> - "Creation location restrictions" would indicate if the page needs to be
>> created in a particular location. The user will not be allowed to create
>> somewhere else and be warned by an error message.
>>
>
> I would identify 3 things that a template provider should be able to do:
> * be visible only in certain locations (the current feature, but maybe a
> bit more sophisticated)
> * recommend a location for the pages created from that template -
> "recommend" here would mean that the user could change that location if
> they wanted
> * restrict a location for the pages created from that template -
> "restrict" would mean that the location would be chosen by the template
> provider and the user would not be able to change it
>
> Note that the 3 above don't exclude eachother, so we can have them all
> implemented as options of the template provider.
> I think that the template provider should be able to fully control them.
> I.e. the template provider should decide if the location is to be
> restricted or only recommended. In addition, I see usecases for all 3 of
> them, so I don't think we should completely exclude one from the picture.
>
> Now, in my opinion, the rest is about how we present these options in the
> creation screen (do we present them all as equally important?) and what do
> we implement for the default applications. See my answers to your questions
> below.
>
>
>>
>> This mail's purpose is to debate:
>> A. If templates should be visible everywhere or just in a particular
>> location?
>>
>
> As I said, we should allow the template provider to decide that, as we
> currently do.
>
>
>> B. Should we recommend applications to restrict the creation of pages to a
>> particular location?
>>
>
> I think this depends on the application, on what kind of data it
> stores, how it handles rights, etc.
>
> Now, for a general recommendation, I think it would not be efficient to
> recommend restriction. I think at most we could guide towards a
> "recommended" location for the pages (in the sense described above), but it
> really depends on each application. There is great value in being able to
> create application pages anywhere on your wiki, so we shouldn't recommend
> against.
> HOWEVER
> My biggest concern here is that the users could very easily get confused
> between the application concept and the application page concept. For
> example, assume we'd have a blog post template provider available
> everywhere on the wiki, without a recommended location. I fear that the
> users will not realize that choosing the "Blog Post" template provider in
> the create page screen is not equivalent with creating a blog post using
> the create blog post form on the homepage of the blog application (the page
> accessible when clicking on the blog application). Same for all the app
> within minutes: "Create new entry" on the homepage of the application will
> create a new entry of the application "contained" in the application (read
> "in the data subtree of the application"), while choosing the template of
> that application from a create screen will not have the same effect. I can
> easily see the users getting a little confused with these.
>



Actually, the more I think, the more I realise that applications is a
delicate subject and that it really depends on the application.
Currently we have lots (if not all) of the applications which completely
abstract the concept of page, so the concept of location of that page in
t

Re: [xwiki-devs] [UX] Page templates availability

[Anca Luca]

Hello all,

On Mon, Jun 6, 2016 at 6:31 PM, Ecaterina Moraru (Valica)  wrote:

> Hi,
>
> The Template Provider allows setting the locations where the template must
> be available.
> Some applications need/encourage their pages to be located in a particular
> app location.
> Currently, if we set such a location for a template, the template will be
> listed in the "Create Page" step only if the user navigates to that
> location and clicks on the "Add" button.
>
> One behavior could be that all templates are displayed each time the user
> clicks on 'Add', regardless of the initial location.
> This would mean splitting the current Location functionality into "Template
> Visibility" and "Creation location restrictions":
> - Ideally "Template Visibility" should not be restricted, but we would need
> to keep this field in order to be backward compatible with the current
> behavior.
> - "Creation location restrictions" would indicate if the page needs to be
> created in a particular location. The user will not be allowed to create
> somewhere else and be warned by an error message.
>

I would identify 3 things that a template provider should be able to do:
* be visible only in certain locations (the current feature, but maybe a
bit more sophisticated)
* recommend a location for the pages created from that template -
"recommend" here would mean that the user could change that location if
they wanted
* restrict a location for the pages created from that template - "restrict"
would mean that the location would be chosen by the template provider and
the user would not be able to change it

Note that the 3 above don't exclude eachother, so we can have them all
implemented as options of the template provider.
I think that the template provider should be able to fully control them.
I.e. the template provider should decide if the location is to be
restricted or only recommended. In addition, I see usecases for all 3 of
them, so I don't think we should completely exclude one from the picture.

Now, in my opinion, the rest is about how we present these options in the
creation screen (do we present them all as equally important?) and what do
we implement for the default applications. See my answers to your questions
below.


>
> This mail's purpose is to debate:
> A. If templates should be visible everywhere or just in a particular
> location?
>

As I said, we should allow the template provider to decide that, as we
currently do.


> B. Should we recommend applications to restrict the creation of pages to a
> particular location?
>

I think this depends on the application, on what kind of data it
stores, how it handles rights, etc.

Now, for a general recommendation, I think it would not be efficient to
recommend restriction. I think at most we could guide towards a
"recommended" location for the pages (in the sense described above), but it
really depends on each application. There is great value in being able to
create application pages anywhere on your wiki, so we shouldn't recommend
against.
HOWEVER
My biggest concern here is that the users could very easily get confused
between the application concept and the application page concept. For
example, assume we'd have a blog post template provider available
everywhere on the wiki, without a recommended location. I fear that the
users will not realize that choosing the "Blog Post" template provider in
the create page screen is not equivalent with creating a blog post using
the create blog post form on the homepage of the blog application (the page
accessible when clicking on the blog application). Same for all the app
within minutes: "Create new entry" on the homepage of the application will
create a new entry of the application "contained" in the application (read
"in the data subtree of the application"), while choosing the template of
that application from a create screen will not have the same effect. I can
easily see the users getting a little confused with these.

I think we can have solutions to this confusion that are only reelated to
presentation, not to technical stuff, so it should not be scary.

Thanks,
Anca




>
> Let me know what you think.
>
> Thanks,
> Caty
>
> Related:
> [1] http://jira.xwiki.org/browse/XWIKI-8759
> [2]
>
> http://design.xwiki.org/xwiki/bin/view/Proposal/HomepageSketches/HomepageTemplateAvailability/
> ___
> 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

[xwiki-devs] [contrib][workflow-publication] Release of Publication Workflow application version 1.5.1

[Anca Luca]

Hello all,

A new version of the application workflow was released this morning,
version 1.5.1. It contains only one fix compared to 1.5, issue
http://jira.xwiki.org/browse/XAWORKFLOW-16 , which is actually quite
particular (we might want to revert this modification at some point in a
future version, as it's only impacting some upgraded instances).

Enjoy!

Anca

Sent from my phone
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [Proposal] Roadmap for XWiki 8.2

[Anca Luca]

Hello all,

On Fri, May 20, 2016 at 9:39 AM, Vincent Massol  wrote:

> Hi devs,
>
> We’re releasing XWiki 8.& next Monday and we now need to think about what
> to implement in 8.2.
>
> I’ve discussed with the XWiki SAS developers and here’s below what we’d
> like to do in the coming timeframe. Note that several XWiki SAS devs will
> continue to work on some internal XWiki SAS projects during this timeframe
> and thus will have less time for XWiki dev for 8.2.
>
> Priority 1:
>
> * CKEditor Polish + Bug fixes + Plugin extensibility + extra stuff to be
> defined (custom editors for macros, etc) - Marius
> * OpenId Connect SSO finishing + polishing - Thomas
> * Curated extensions feature in EM (curated extensions listed + ability to
> see others if explicitly asked) - Thomas
> * Propose some strategy to curate extensions on e.x.o + curate them -
> Vincent
> * XWiki home page Welcome Tour - Alex
> * Improvement to activeinstalls to capture some more information (ideas:
> email hash for unicity, country, number of users) - Vincent
> * Nested App Migrator polishing/bug fixing - GuillaumeD
>

It's possible that I will also take a look at the migrator issues, if I
will need to use it during this cycle, but I cannot guarantee anything.


> * Bug Fixing Day - All
>
> Priority 2:
>
> * Addition of a paying + trial feature in EM (see that an app is paying +
> has a trial and show it) - Thomas
> * XWiki Home page usability improvements - ?
>
> Dates (note that XWiki SAS has its yearly seminar just after the 18th of
> July hence why I’m proposing to release at that time):
>
> * 8.2M1: 6 June 2016
> * 8.2M2: 20 June 2016
> * 8.2RC1: 4 July 2016
> * 8.2Final: 18 July 2016
>
> WDYT?
>
> Thanks
> -Vincent
>
> ___
> 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

Re: [xwiki-devs] [Proposal] Add mechanism to allow following only contrib related mails

[Anca Luca]

+1 for [Contrib][]


On Wed, Apr 27, 2016 at 2:42 PM, Thomas Mortagne <thomas.morta...@xwiki.com>
wrote:

> Then [Contrib][] I guess.
>
> On Wed, Apr 27, 2016 at 1:59 PM, Anca Luca <lu...@xwiki.com> wrote:
> > Actually I don't like the idea of having the name of the application
> itself
> > and not a unique keyword because it's not easy to have filters in the
> mail
> > client for all the names of the applications on contrib (I cannot imagine
> > how I would create these filters). With a single keyword filters are
> easier
> > to do.
> >
> > Let's please decide quickly on this, because I see there is already
> contrib
> > related activity that I am missing...
> >
> > Thanks,
> > Anca
> >
> > On Mon, Apr 25, 2016 at 12:27 PM, Eduard Moraru <enygma2...@gmail.com>
> > wrote:
> >
> >> On Fri, Apr 8, 2016 at 1:00 PM, Vincent Massol <vinc...@massol.net>
> wrote:
> >>
> >> > Hi,
> >> >
> >> > > On 08 Apr 2016, at 11:43, Anca Luca <lu...@xwiki.com> wrote:
> >> > >
> >> > > Hello all,
> >> > >
> >> > > Since http://xwiki.markmail.org/thread/jrug6cbbqpia5bx4 (but not
> only)
> >> > the
> >> > > rule says that we should discuss contrib related stuff with the
> >> > community.
> >> > > In my case, I cannot manage to follow all the mails on the
> >> > devs@xwiki.org
> >> > > (because they are a lot) but I would be particularly interested of
> not
> >> > > missing the ones about contrib extensions.
> >> >
> >> > Since the dev rules for xwiki contrib are now the same as for xwiki
> core
> >> > (i.e. dev.xwiki.org), I’m not sure if it makes sense to differentiate
> >> > proposals. Maybe you could just filter mails with "[Proposal]" and
> >> "[VOTE]”?
> >> >
> >> > > However, today, I don't know how
> >> > > to differentiate them, I would need to read all devs@xwiki.org to
> not
> >> > miss
> >> > > one.
> >> > >
> >> > > There are multiple solutions that I can propose for this, please
> let me
> >> > > know what you think:
> >> > > 1/ have a contrib mailing list
> >> >
> >> > I feel that xwiki-contrib might be large enough now to warrant a
> mailing
> >> > list but maybe not 2 (users and devs).
> >> >
> >> > However there are issues:
> >> >
> >> > * Notifications from jira. We could have a single cont...@xwiki.org
> >> > mailing for everything related to contrib (users, devs,
> notifications).
> >> >
> >> > * Users don’t know if what they’re using from e.x.o is from Core or
> from
> >> > Contrib so they’d have a hard time choosing the right list from
> >> > http://dev.xwiki.org/xwiki/bin/view/Community/MailingLists. For
> example
> >> > right now we have: "us...@xwiki.org : For questions about using
> XWiki,
> >> > using the XWiki API, suggestions for improvements, ideas, etc.”
> >> >
> >> >
> >> > > 2/ have an alias for the contrib that would send on the same list,
> this
> >> > way
> >> > > we could filter by the "to" field
> >> > > 3/ have a convention about mails related to contrib (e.g. [Contrib]
> in
> >> > the
> >> > > subject) that would allow to filter
> >> >
> >> > This is probably the simplest ATM. The pros is that it wouldn’t create
> >> any
> >> > fragmentation between Contrib and Core, which is probably a good
> thing.
> >> >
> >> > > 4/ any other technical solution that I didn't think about that would
> >> > allow
> >> > > to automatically decide if a mail is about contrib or not, without
> >> > reading
> >> > > it :D
> >> > >
> >> > >
> >> > > 1, 2 and even 4 are perfectly fine with me, 3 is a bit risky because
> >> > people
> >> > > might not follow conventions.
> >> > >
> >> > > What do you think?
> >> >
> >> > If we follow the direction that we’re trying to take, which is to
> have a
> >> > single large community (ie bring contrib and core together), I think
> the
> >> > best is to keep usin

Re: [xwiki-devs] [Proposal] Add mechanism to allow following only contrib related mails

[Anca Luca]

Actually I don't like the idea of having the name of the application itself
and not a unique keyword because it's not easy to have filters in the mail
client for all the names of the applications on contrib (I cannot imagine
how I would create these filters). With a single keyword filters are easier
to do.

Let's please decide quickly on this, because I see there is already contrib
related activity that I am missing...

Thanks,
Anca

On Mon, Apr 25, 2016 at 12:27 PM, Eduard Moraru <enygma2...@gmail.com>
wrote:

> On Fri, Apr 8, 2016 at 1:00 PM, Vincent Massol <vinc...@massol.net> wrote:
>
> > Hi,
> >
> > > On 08 Apr 2016, at 11:43, Anca Luca <lu...@xwiki.com> wrote:
> > >
> > > Hello all,
> > >
> > > Since http://xwiki.markmail.org/thread/jrug6cbbqpia5bx4 (but not only)
> > the
> > > rule says that we should discuss contrib related stuff with the
> > community.
> > > In my case, I cannot manage to follow all the mails on the
> > devs@xwiki.org
> > > (because they are a lot) but I would be particularly interested of not
> > > missing the ones about contrib extensions.
> >
> > Since the dev rules for xwiki contrib are now the same as for xwiki core
> > (i.e. dev.xwiki.org), I’m not sure if it makes sense to differentiate
> > proposals. Maybe you could just filter mails with "[Proposal]" and
> "[VOTE]”?
> >
> > > However, today, I don't know how
> > > to differentiate them, I would need to read all devs@xwiki.org to not
> > miss
> > > one.
> > >
> > > There are multiple solutions that I can propose for this, please let me
> > > know what you think:
> > > 1/ have a contrib mailing list
> >
> > I feel that xwiki-contrib might be large enough now to warrant a mailing
> > list but maybe not 2 (users and devs).
> >
> > However there are issues:
> >
> > * Notifications from jira. We could have a single cont...@xwiki.org
> > mailing for everything related to contrib (users, devs, notifications).
> >
> > * Users don’t know if what they’re using from e.x.o is from Core or from
> > Contrib so they’d have a hard time choosing the right list from
> > http://dev.xwiki.org/xwiki/bin/view/Community/MailingLists. For example
> > right now we have: "us...@xwiki.org : For questions about using XWiki,
> > using the XWiki API, suggestions for improvements, ideas, etc.”
> >
> >
> > > 2/ have an alias for the contrib that would send on the same list, this
> > way
> > > we could filter by the "to" field
> > > 3/ have a convention about mails related to contrib (e.g. [Contrib] in
> > the
> > > subject) that would allow to filter
> >
> > This is probably the simplest ATM. The pros is that it wouldn’t create
> any
> > fragmentation between Contrib and Core, which is probably a good thing.
> >
> > > 4/ any other technical solution that I didn't think about that would
> > allow
> > > to automatically decide if a mail is about contrib or not, without
> > reading
> > > it :D
> > >
> > >
> > > 1, 2 and even 4 are perfectly fine with me, 3 is a bit risky because
> > people
> > > might not follow conventions.
> > >
> > > What do you think?
> >
> > If we follow the direction that we’re trying to take, which is to have a
> > single large community (ie bring contrib and core together), I think the
> > best is to keep using the same lists as now but do a best effort of using
> > "[Contrib]” for mails related only to contrib stuff.
> >
>
> IMO contrib devs should be up to date with the changes in the platform and
> we should keep the communication tight with the platform. As we can see,
> many topics on contrib apps trace down to the platform and vice-versa.
>
> It would also not be very helpful for the project/community to do such a
> segregation, so I agree with Vincent.
>
> Since we are talking about contrib (which are devs and which have a guide
> to follow), as Thomas suggested, it would be a helpful idea to mention the
> app in the subject so that we can apply filters in the mail client, should
> we need them.
>
> Thanks,
> Eduard
>
>
> >
> > Thanks
> > -Vincent
> >
> > > Anca
> >
> > ___
> > 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

Re: [xwiki-devs] [Brainstorming] Improving easiness of creating wiki links

[Anca Luca]

Hello all,

For me the issue is larger than just the wiki links, page references are
required in multiple other places, most notably in the macro parameters in
the macro wizard of the wysiwyg. If creation of links can be workedaround
by using the links dialog of the wysiwyg, filling in wiki parameters can
not be worked around.
Also, the problem becomes even more important with nested spaces being
there, since WebHome is never displayed in the URL but always required when
referring to a page in a wiki macro parameter.
Also, note that not being able to point correctly to a page from the
parameters of a wiki macro will render very interesting wiki macros useless
for some users (e.g. the include/display macros, the documents macro to
display all the children of a document, etc).

What I propose is to implement H quickly, since it seems quite simple, to
compensate for this miss, and then explore one of the other solutions,
which seem more complex. I created an issue for this since for me is more
like a bug, especially when it comes to regular users having to give a
parameter to a wiki macro http://jira.xwiki.org/browse/XWIKI-13362 .

Thanks,
Anca

On Thu, Dec 17, 2015 at 2:56 PM, vinc...@massol.net 
wrote:

> Hi devs,
>
> A user has reported the following, mentioning it was taking a lot of
> steps, and we’ve all experimented that creating wiki links could be easier:
>
> “
> 1. Go to page you want to link to (Target Page).
> a. Copy URL
> 2. Go to page where you want to add the link (Source Page)
> 3. Edit it using Wiki Syntax Editor
> 4. Create the link
>i.Write [[
>ii.   write label
>iii.  write >>
>iv.   paste the link pointing to Target Page
>v.Remove https://w.amazon.com/bin/view  from pasted link
>vi.   Replace manually all encoded URL strings (like + and other
> symbols)
>vii.  Replace “/” with “.”
>viii. Add WebHome
>ix.   write ]]
> 5. Save
> 6. Done.
> "
>
> So I’d like to brainstorm about what we could do to make it easier to
> creating wiki links.
>
> Some ideas:
>
> A) Remove step 4. ix with http://jira.xwiki.org/browse/XWIKI-12920
>
> B) The label>> parts (steps ii and iii) can be omitted, especially when
> the link label generation is configured to use titles
>
> C) The real solution for me is autocomplete on links:
> http://jira.xwiki.org/browse/XWIKI-206 This should probably be
> implemented in the autocomplete extension: see
> http://extensions.xwiki.org/xwiki/bin/view/Extension/AutoCompletion+API
>  and
> http://extensions.xwiki.org/xwiki/bin/view/Extension/AutoCompletion+Application
>
> D) Using CTRL+G helps since it provides the reference and helps in finding
> the page to link to. It can be considered as a simplified autocomplete, ie
> a simplified impl for C).
>
> E) Marius mentioned elsewhere: "I would also like to have a common Insert
> Link dialog between the CKEditor and the Wiki Editor. You click on a button
> on the tool bar, you get a dialog where you can search for the target page
> (or select it from the tree) and then click Insert, which will generate the
> wiki syntax for your. The Insert Link dialog can have a shortcut key for
> quick access. Of course autocomplete is nicer but it's more work, while the
> Insert Link dialog is a must for the CKEditor anyway.”
>
> F) Marius mentioned elsewhere: "We can also implement a dedicated "Insert
> Reference" dialog for the Wiki Editor that offers a text input where you
> can paste an URL and the dialog attempts to extract the entity reference
> from the URL and inserts it in the Wiki Editor text area to be used for
> links but also for macros or anywhere where you might need a document
> reference. This can be implemented as an XWiki extension.”
>
> G) Add the ability to paste a full URL in the reference part of wiki links
> and upon save the Rendering will automatically transform it into a document
> reference if it’s a local link. And if you want a real url for a local link
> then you’d need to use the “url:” prefix. Implementation: One relatively
> simple solution is to parse the URL (using a
> ResourceTypeResolver/ResourceReferenceResolver) and then serialize it and
> verify if the result matches the passed URL. If it does it means it’s a
> local URL.
>
> H) Caty mentioned elsewhere: "We could display the reference of a page in:
> a. a Permalink dialog (containing the URL + reference) that the user can
> copy paste in browser input or editor
> b. Information tab
> c. other?”
>
>
> IMO the best (possibly not the easiest) are C) and G). With those 2 we
> would get:
> * easy pasting of existing URLs
> * easily finding the page you want to link to when you don’t have its URL
>
> Now, even if we agree to do C) and G) in the future I still think that all
> the other ideas (ie. E, F and H) could also be implemented.
>
> WDYT?
>
> Thanks
> -Vincent
>
> ___
> devs mailing list
> devs@xwiki.org
> 

[xwiki-devs] [Proposal] Add mechanism to allow following only contrib related mails

[Anca Luca]

Hello all,

Since http://xwiki.markmail.org/thread/jrug6cbbqpia5bx4 (but not only) the
rule says that we should discuss contrib related stuff with the community.
In my case, I cannot manage to follow all the mails on the devs@xwiki.org
(because they are a lot) but I would be particularly interested of not
missing the ones about contrib extensions. However, today, I don't know how
to differentiate them, I would need to read all devs@xwiki.org to not miss
one.

There are multiple solutions that I can propose for this, please let me
know what you think:
1/ have a contrib mailing list
2/ have an alias for the contrib that would send on the same list, this way
we could filter by the "to" field
3/ have a convention about mails related to contrib (e.g. [Contrib] in the
subject) that would allow to filter
4/ any other technical solution that I didn't think about that would allow
to automatically decide if a mail is about contrib or not, without reading
it :D


1, 2 and even 4 are perfectly fine with me, 3 is a bit risky because people
might not follow conventions.

What do you think?

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

Re: [xwiki-devs] [Proposal] Nested Spaces support for Contrib Applications

[Anca Luca]

Hello all,

I think the best would be 2, but it could be discussed on an app by app
basis and, in my opinion, the options need to be looked in the context of
what does it mean that an "application needs to pass to Nested Spaces".
This is my view on it:


   - Requirement of a nested spaces version should be done if the
   functionalities of the application demand it (there is a feature that is
   added to the functionality that needs nested spaces in order to work)
  - Note that application can *work* on nested spaces without
  *requiring* nested spaces (because of the general backwards
  compatibility of nested spaces feature), this bullet above is about
  requiring nested spaces.
   - Even if previous versions can still be supported by an application
   migrated to nested spaces, if this adds a lot of bloat and "if"s in the
   code and extra complexity, the benefits are probably not worth it (it
   should still be discussed though) - this would be option 0
   - A particular case is when an application does not work on nested
   spaces in its current form and needs to be modified to support nested
   spaces. In this case, there needs to be an effort to find a reasonable
   approach that would allow the application to work, with the same code, on
   both nested spaces and non-nested spaces (which could be possible because
   of the generic backwards compat of nested spaces)


Otherwise put, I am fine that there are applications on which we apply 2
(and even 3) , but there needs to be a good reason  to pass to Nested
Spaces for an application, potentially joined by a validation discussion
with the community. If we decide we go to nested for an app, both 2 and 3
are fine. In such a case I would be against option 0 that Vincent
mentioned: adds complexity and bloats the code for an application, raises
the learning curve and it will be removed in the future.

Now please note that applying 2 means that if you're in the middle of the
developpement for a version of an application, on which some issues were
already fixed, and you want to move to a nested spaces version, it would be
nice to release current work first as the "last version before nested
spaces" and only then break compat. This is also valid for planning the
versions of the application: bugfixes / features that don't require nested
spaces should be planned in earlier, separate versions than features that
would require nested spaces.


On Fri, Apr 1, 2016 at 8:48 AM, Alexandru Cotiuga <
alexandru.coti...@xwiki.com> wrote:

> Hello devs,
>
> Since I already experimented the Nested Spaces behaviour on the Forum
> application and there are other applications that might need it also, I
> think it's time to start discussing this topic and to decide what strategy
> should be implemented on contrib applications.
>
> What I have done in the Forum app was to handle both Pre NS and NS versions
> of XWiki, writing specific code for each case (wrapped in if-else
> statements), which proved to be the most complex and hard to maintain way,
> without much benefit. Sooner or later, everybody will have a NS Xwiki
> version and then all the support for Pre NS would become useless and then
> the code should be cleaned, which would be a lot of work again.
>
> Besides this already tried strategy, there are some others to be discused:
>
> 1: Support both Pre NS and NS versions but in different branches.
> 2: Move to NS, but keep fixing bugs for Pre NS in a separate branch. (This
> is what I'm proposing)
> 3: Move to NS without any maintance on Pre NS.
> 4: Others?
>
> In all the cases, a data migration should be performed.
>

Depends on what we understand by data migration: if the data format changes
(e.g. the data of the application needs to have a new hierarchical
structure because a functionality requires this hierarchy - e.g. inheriting
rights) then we need to have a data migration, as in take into account the
fact that there will be upgrades of the application, and that we should
have an unique format of data for the application in question (e.g. there
is no reason that the data structure is different between a user that has
installed the app on a fresh 7.4 and a user that has upgraded the
application from a previous version on a 7.4 xwiki).
If "data migration" is about just transforming all existing pages of
an/created by an application (which are terminal) into non-terminal pages,
then it should not be done unless there is a feature that requires it. I
think this data migration needs to be looked at as a change in the
application data structure (from a 2 levels hierarchy to an infinite
hierarchy) and should be done only if there is a functional benefit that
justifies it. In this context, breaking compat of the FAQ app by moving the
FAQ pages to a "Data" subspace of the FAQ space for the sole reason that
this is what AWM is doing now is not ok, because the reason is not good
enough. So, imo, since these reasons will really differ from app to app and

Re: [xwiki-devs] [Proposal] Improving how we work in xwiki-contrib

[Anca Luca]

On Thu, Mar 24, 2016 at 4:12 PM, Vincent Massol <vinc...@massol.net> wrote:

> Hi Anca,
>
> > On 24 Mar 2016, at 15:38, Anca Luca <lu...@xwiki.com> wrote:
> >
> > Hello Vincent,
> >
> > so, if I understand correctly, all rules about development from
> >
> http://dev.xwiki.org/xwiki/bin/view/Community/DevelopmentPractices#HGeneralDevelopmentFlow
> > and http://dev.xwiki.org/xwiki/bin/view/Community/Committership and
> > potentially other places will now apply to the community XWiki Contrib as
> > well, except for the releases, for which a rule specific to contrib was
> > created.
>
> All pages from dev.xwiki.org apply, not just the ones you mentioned. The
> full dev.xwiki.org is about development practices for the xwiki open
> source project and the idea is to have a single way to do development for
> the XWiki open source project.
>
> To give some examples:
> * Hall of fame page applies
> * Governance page for xwiki.org applies
> * Building page applies
> * etc


Actually, I was thinking about a very precise situation: changing the
minimal compatible version of XWiki for an extension. There are a bunch of
rules on dev.xwiki.org which cover this case (e.g. (1) or (2)).
However, I am worried that it will be difficult for contributors to
discover these rules and understand that they apply to their case, since
there is a lot of documentation and it takes time and experience to
understand this documentation properly. Since my assumption is that the
expectation from a contributor is to be able to be a contributor while not
being "full time" in the community, I made the proposal about the cheat
sheet with examples.
Also, since some of the generic dev.xwiki.org rules won't be followed
because leniency and flexibility (e.g. (2) is not even followed by the apps
we made as part of platform), I imagine that contributors could have a
wrong evaluation about the importance of a certain rule for extensions
(e.g. keeping a low version of compatibility is important for extensions,
in my opinion, but I am not expecting everybody to understand it in the
same way).

So, to try to make it short, do we have a plan to handle this kind of
things to make it easy to work together on extensions?
("Easy" compared to the xwiki.org community, for which being a committer
requires a certain time spent in the community, deep understanding of
rules, trust in the judgement, a certain committment).

Thank you for reading,
Anca

(1) "In general votes should be sent in case of big changes (whether it's
about code or about processes or people)." from
http://dev.xwiki.org/xwiki/bin/view/Community/Committership#HVoting
(2) "In your POM always try to depend on the oldest version of
commons/rendering/platform dependencies for which your code works. At
least, ensure that your Applications works on the latest LTS version of
XWiki. This will allow the largest number of users to use your
application." from
http://dev.xwiki.org/xwiki/bin/view/Community/ApplicationDevelopmentBestPractices


>
> However it’s possible that the wording we have in some of those places are
> not good for contrib because they were written before we decided to fold in
> contrib. Thus we should rewrite those few places where the wording is
> awkward. I can do it if someone points me to them.
>
> > I think it would be a good idea to prepare a sort of a cheat sheet or
> > "short version" of these rules, for people to easily read and understand
> > how to work with the new concept of community XWiki Contrib. This could
> > also work as a guide for users that are already extension developers, and
> > they need to quickly understand what changes for them with this new
> > organisation.
>
> Sure I agree in theory, but:
> 1) I don’t have the time (it’s a huge task)
> 2) dev.xwiki.org is already a cheat sheet. There’s no extra stuff there.
> It contains the bare minimum already
> 3) if we were to do this it would a major pain to maintain since we’d need
> to keep the 2 versions in sync and there’s really not enough people helping
> on xwiki.org to do this.
>
> Thanks
> -Vincent
>
> > Thanks,
> > Anca
> >
> >
> > On Mon, Mar 21, 2016 at 5:20 PM, Vincent Massol <vinc...@massol.net>
> wrote:
> >
> >>
> >>> On 21 Mar 2016, at 16:57, Clemens Klein-Robbenhaar <
> >> c.robbenh...@espresto.com> wrote:
> >>>
> >>> +1
> >>>
> >>> I spend some time about nitpicking the "the recommended development
> >> practices to follow are those found on dev.xwiki.org", because it is
> not
> >> exactly obvious which parts on dev.xwiki.org are development practices
> >> and this apply and whi

Re: [xwiki-devs] [Proposal] Improving how we work in xwiki-contrib

[Anca Luca]

Hello Vincent,

so, if I understand correctly, all rules about development from
http://dev.xwiki.org/xwiki/bin/view/Community/DevelopmentPractices#HGeneralDevelopmentFlow
and http://dev.xwiki.org/xwiki/bin/view/Community/Committership and
potentially other places will now apply to the community XWiki Contrib as
well, except for the releases, for which a rule specific to contrib was
created.
I think it would be a good idea to prepare a sort of a cheat sheet or
"short version" of these rules, for people to easily read and understand
how to work with the new concept of community XWiki Contrib. This could
also work as a guide for users that are already extension developers, and
they need to quickly understand what changes for them with this new
organisation.

Thanks,
Anca


On Mon, Mar 21, 2016 at 5:20 PM, Vincent Massol  wrote:

>
> > On 21 Mar 2016, at 16:57, Clemens Klein-Robbenhaar <
> c.robbenh...@espresto.com> wrote:
> >
> > +1
> >
> > I spend some time about nitpicking the "the recommended development
> practices to follow are those found on dev.xwiki.org", because it is not
> exactly obvious which parts on dev.xwiki.org are development practices
> and this apply and which ones are not
> > (e.g. http://dev.xwiki.org/xwiki/bin/view/Community/Governance does not
> apply, but e.g.Code style probably does, and then some parts of
> http://dev.xwiki.org/xwiki/bin/view/Community/DevelopmentPractices apply,
> and some not - e.g "Release Manager" is explicitly about XWiki core, but
> the general infra structure and coding advice applies …
>
> Actually the goal is to make it all apply in the future by rephrasing the
> places that currently only make sense for the xwiki github org. Note that
> http://dev.xwiki.org/xwiki/bin/view/Community/Governance does apply (a
> project on xwiki-contrib also has some web pages on xwiki.org) :)
>
> > ... but then I decided to forget about it because a bit of common sense
> allows this to sort out by itself; the important thing is be nice, and a
> bit lore lenient and relaxed no new contributors, so they feel welcome :)
>
> Yup :)
>
> Thanks
> -Vincent
>
> > Clemens
> >
> > - Ursprüngliche Nachricht -
> > Von: Vincent Massol
> > Am:  Tuesday, 15.03.2016, 13:12
> > An: Xwiki Developers
> > Betreff: [xwiki-devs] [Proposal] Improving how we work in xwiki-contrib
> >
> >
> >> Hi all,
> >>
> >> This mail is about trying to improve how we work in xwiki-contrib and
> it supersedes the proposal I sent at
> http://markmail.org/message/qzc7ipiu6lazwbwr
> >>
> >> Issues with current way of working in xwiki-contrib:
> >>
> >> * Each project has a lead but this lead is MIA for a lot of extensions
> and it's a pain to maintain (I'm trying to do it but it's a pain)
> >> * It doesn't make much sense to have a lead for an extension but then
> allowing anyone to commit on it without the lead's approval, nor allowing
> anyone to release new versions of that project without the lead
> participating to the discussion.
> >> * Right now a committer can release a project using maven but doesn't
> have permissions to release it in jira nor creating a new version, causing
> synchronization issues
> >> * The XWiki core committers are going to move a lot of non-core
> extensions to xwiki-contrib but there's no clear lead for a lot of those
> extensions since they were developed collaboratively and there's no notion
> of lead in the xwiki github organization. In practice the person from the
> XWiki core devs to work on a given extension varies over time (that’s how
> those extensions were built). It's not possible (and not a good idea) to
> give a long-time leadership to a single person.
> >>
> >> Proposal:
> >> =
> >>
> >> * XWiki Contrib is a community where extensions for XWiki can be
> developed and maintained together. It's a place that is of interest for
> people who want to share their sources and work collaboratively with others
> on them. If the intent is only to make an extension available to users of
> XWiki then it's enough to publish the binaries on extensions.xwiki.org
> (and put the souces anywhere they wish, including on the e.x.o page or on
> their github account if they have one).
> >>
> >> * XWiki Contrib is defined by the xwiki-contrib github organization
> >>
> >> * Anyone can request to join this community. This is the main
> difference with the xwiki github organization where you need to be voted in
> to become a committer. The main rationale is that making a mistake in the
> core has more impact than doing this in an extension. The second rationale
> is that this is an experiment to see if we can have a more vibrant
> community as a result of being more open, without loosing too much quality.
> >>
> >> * Once someone joins, he/she has commit access to all repositories in
> xwiki-contrib (and he/she's also added to a group on jira allowing him to
> create versions and releasing them.). The goal is to favor
> cross-pollination. In case this causes 

Re: [xwiki-devs] PDFMulti Export

[Anca Luca]

Hello Alessandro,

I am curious what exactly is going wrong when you have a lot of pages to
export. Where does it block exactly?

Otherwise, there is an API for exporting multiple pages as PDF, if you can
build your list of pages to export programatically you can use directly the
API to get them exported :
http://extensions.xwiki.org/xwiki/bin/view/Extension/Multipage+PDF+Export .

Happy XWikiing.
Anca

On Thu, Jan 7, 2016 at 2:20 PM, Alessandro Strambini <
aless.stramb...@gmail.com> wrote:

> Hello,
>
> I wanted to ask if there is any Tool or Script at the moment to export
> Multiple Pages as PDF (like The PDFCollection Maker extension
>
> http://extensions.xwiki.org/xwiki/bin/view/Extension/PDF+Export+Collection+Application
> )
> or the MultiPage Export, which works for me but not when i have alot of
> Pages to export.
> Im at version 7.2 and it seems like the Collection one isnt working
> anymore. Is there any alternative? Or did i skipped some important
> configuration change that it should work?
>
> I would be glad for any help.
>
> Best Regards
>
> Alessandro Strambini
> ___
> 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

[xwiki-devs] [myxwiki] new wiki request

[Anca Luca]

Hello XWikiers,

I would need a wiki on myxwiki.org in order to test/demo collaboration with
somebody remote (and a pain to get a public IP for a local instance of
mine).
It would be temporary so it will be deletable after a while (I will let you
know when you can throw it away).

My username is lucaa, the wiki should be called lucaa.myxwiki.org .

Thank you very much,
Anca
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [Proposal] 2 new rules for Application Best Practices

[Anca Luca]

On Sat, Nov 14, 2015 at 3:17 PM, vinc...@massol.net <vinc...@massol.net>
wrote:

> Hi Anca,
> On 14 Nov 2015 at 10:57:24, Marius Dumitru Florea (
> mariusdumitru.flo...@xwiki.com) wrote:
>
> Hi Anca,
>
> On Fri, Nov 13, 2015 at 8:51 PM, Anca Luca <lu...@xwiki.com> wrote:
>
> > Hello all,
> >
> > my 2 cents on the "Data" or "Entries" subspace.
> > ( But too late, since I see the issue was already closed :( )
> Thanks for taking the time to participate.
>
> > I'm afraid that, even if technically it seems like a nice idea, it's not
> > that nice for a "regular non-developer user" which perceive an
> application
> > as only having data.
>
>
>
> > They don't need to and won't know that the code of
> > that application is also stored on the wiki, in another subspace that is
> > called "Code".
>
>
> The Code space is still hidden so a regular user doesn't see it. There's no
> change in this regard.
>
>
> > There is complaint about the size and the amount of bloat in
> > the XWiki URLS (the /xwiki/bin/view/ part) and this would be an extra
> one,
> > for the case of applications. I don't think url rewrite should be
> > considered so easily as an option because it's technically not so easy to
> > achieve and I think that there can be an issue with colision (e.g.
> between
> > MyApp/WebPreferences and MyApp/Data/WebPreferences).
> >
>
> So you think having MyApp and MyAppCode is better?
> You need to read the whole discussion thread and see that we’ve discussed
> about what you said already and we’ve weighted pros and cons to decide in
> the end that all things considered the Code and Data subspaces were
> probably the best solution.


> If you think they are not, please make a proposal that you think would be
> better (ideally taking into account the arguments that we’ve already
> discussed) and we can discuss updating what’s been already done.
>

Actually, I read the discussion and I re-read it now. And, depending on how
the "delete application data" is implemented (IIRC In the UI now) we could
more go for detailed delete options (by default and in the app withim
minutes itself). All the arguments that were brought in the discussion are
correct, I just think that in some of them the 80-20 rule was wrongly
estimated:
* deleting a whole application data is frequent, but not _that_ frequent
(20%).
* it was said that a url rewrite should be doable (people really bothered
by the Data particle should be able to do it). No, it's not that easy (less
than 20% of the people bothered by the Data particle can do it).
* less than 20% of usecases have an application within minutes that has two
data spaces. Actually, I am wondering how is that an app within minutes
still, because out of my knowledge this is not a known feature of app
within minutes, and it means that some customization has been done to that
application. For me, if an application was customized, it's still an
application but not "within minutes" anymore.
* if we're talking about applications in general, I think just as frequent
is the case when the same application has multiple data spaces (e.g. having
multiple blogs, each in a different space, in a different point in the
hierarchy). Having multiple subspaces in the application space would not
help much in this case.
* for the rights issue, in 80% of the cases the code authors are data
authors as well, there are just additional rights on the code (sub) space,
so it's normal that code space inherits from app space.
* deleting a space without some of its subspaces is a larger problem than
app within minutes, so a more generic solution for that could be
interesting. Also, I think it would be a frequent problem (80%), so having
a flexible solution for it can be interesting.

Actually, the only thing on which I have a doubt that it would affect 80%
of the usecases is the Data particle itself in the url :) (maybe more like
50-50 :D) . However, from the discussions in the thread I kind of had the
feeling that it being annoying is considered to fall in the 20% bucket,
compared to the other arguments which would be 80. I have the opposite
feeling, as I explained above in the bullet list.

It's a good thing that it's configurable, though.

In what concerns the more generic topic of best practices: In the cases of
larger customizations that I met so far (on non-nested spaces, though), the
isolation was much more important: all the code for all the applications
and all the customizations is in one space, in order to be able to manage
it together as a group (rights, UI settings, deployment, search, etc),
while the data was spread around in spaces that are dedicated exclusively
to data, potentially more data spaces for all the different areas of
applications co

Re: [xwiki-devs] Release validation

[Anca Luca]

Hello Paul,

I released your extension, you can find it here:
http://maven.xwiki.org/releases/org/xwiki/contrib/application-rightsui-simplifier/1.0/
.

You can no go ahead and add it on extensions.xwiki.org (by maven import)
and document it.

Thank you for your contribution,
Anca

On Fri, Nov 13, 2015 at 7:18 PM, Paul Pantiru 
wrote:

> Hello devs,
>
> Would someone be kind to validate my extension on nexus, please?
>
> extension id : application-rightsui-simplifier
> vesion: 1.0
>
> Thanks,
> Paul Pantiru
> ___
> 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

Re: [xwiki-devs] [Proposal] 2 new rules for Application Best Practices

[Anca Luca]

Hello all,

my 2 cents on the "Data" or "Entries" subspace.
( But too late, since I see the issue was already closed :( )

I'm afraid that, even if technically it seems like a nice idea, it's not
that nice for a "regular non-developer user" which perceive an application
as only having data. They don't need to and won't know that the code of
that application is also stored on the wiki, in another subspace that is
called "Code". There is complaint about the size and the amount of bloat in
the XWiki URLS (the /xwiki/bin/view/ part) and this would be an extra one,
for the case of applications. I don't think url rewrite should be
considered so easily as an option because it's technically not so easy to
achieve and I think that there can be an issue with colision (e.g. between
MyApp/WebPreferences and MyApp/Data/WebPreferences).

But I guess this is really too late now...

Thanks,
Anca

On Tue, Oct 27, 2015 at 11:34 AM, Guillaume "Louis-Marie" Delhumeau <
gdelhum...@xwiki.com> wrote:

> Hello.
>
> Why not using "Entries" instead of "Data" for the name? It will be shown
> both in the URL and in the breadcrumb, and fit with most of the use-cases.
>
> Users can still change the title of the "Entries" space to have a more
> specific name such as "Ideas", "Meetings", etc...
>
> Just my 2 cents.
>
> 2015-10-26 10:45 GMT+01:00 Marius Dumitru Florea <
> mariusdumitru.flo...@xwiki.com>:
>
> > On Fri, Oct 23, 2015 at 5:06 PM, Clemens Klein-Robbenhaar <
> > c.robbenh...@espresto.com> wrote:
> >
> > >
> > > > On Wed, Sep 30, 2015 at 11:16 AM, Guillaume "Louis-Marie" Delhumeau <
> > > > gdelhum...@xwiki.com> wrote:
> > > >
> > > >> 2015-09-30 10:58 GMT+02:00 vinc...@massol.net :
> > > >>
> > > >>>
> > > >>> On 30 Sep 2015 at 10:53:48, Thomas Mortagne (
> > thomas.morta...@xwiki.com
> > > >>> (mailto:thomas.morta...@xwiki.com)) wrote:
> > > >>>
> > >  I think what I like best is some option in the refactoring API to
> > >  indicate that you want to delete only final documents in the space
> > (so
> > >  skipping space home page and spaces).
> > > >>>
> > > >>> That could be interesting for some use cases but it’s risky for
> this
> > > one.
> > > >>> Several apps may generate terminal pages and users could create
> > > terminal
> > > >>> pages in app spaces too. So that would not just remove the app
> > > technical
> > > >>> pages, it could remove more.
> > > >>>
> > > >>
> > > >> The idea of Thomas is an option to only delete *terminal* pages
> > located
> > > in
> > > >> the space with a depth of 1. Said differently, the direct and
> terminal
> > > >> children of the page.
> > > >>
> > > >> This way, you can delete all data located in the space without
> > removing
> > > the
> > > >> code (because the code would be located in a deeper depth), but it
> > works
> > > >> only if the app generates data as terminal pages. It is the case
> right
> > > now,
> > > >> but new apps should work differently and create their data as
> regular
> > > >> Nested Pages.
> > > >>
> > > >
> > > > I don't agree at all on this later statement. New apps _may_ work
> > > > differently and create nested pages, but it _should_ not.
> > > > Anyway, this is why I am wondering about properly separating WebHome,
> > > Code
> > > > and Data.
> > > > I do not think we need stable names, but the structure matter. If
> Data
> > > does
> > > > not look nice, you may leave apps decide for themselves, the rules
> > being
> > > > put your data in subspaces, and code in the Code subspace, or
> something
> > > > like that. Please note that using "space" in the previous rules looks
> > bad
> > > > to me, since we do not have space anymore ;)
> > > >
> > > [...]
> > >
> > >
> >
> > > Just another random thought: some applications might really want to
> have
> > > two "data" spaces;
> > > for example currently in the blog you cannot have a category and a blog
> > > post with the same name.
> > > If both end up in their respective "subfolders" "Blog.Posts" and
> > > "Blog.Categories", the problem goes away.
> > >
> >
> > Indeed, but I don't think it contradicts the rule. IMO the best practice
> > should be to group the application data in one or more subspaces under
> the
> > application space. If the application generates only one type of data
> (e.g.
> > Events) then it makes sense to have only one Data subspace. If the
> > application generates two or more types of data (Categories and Posts)
> then
> > it may need more subspaces. The only question is whether we should group
> > these subspaces under a Data subspace, e.g.
> >
> > App / Data / Categories
> >
> > or leave them directly under the application space:
> >
> > App / Categories
> >
> > I prefer the second option.
> >
> > Another thing to decide is whether the Data space should be named "Data"
> or
> > some domain-specific name. Considering that we can set the title of the
> > home page to anything we want, I prefer to use "Data" as name, so that
> the
> > code deals with a 

Re: [xwiki-devs] [Proposal] Removal of XWiki.RequiredRightClass page

[Anca Luca]

-1 to remove it.

** I don’t think we’re using that information much and its need is supposed
to go away once signed scripts is there

I will agree to remove it when signed scripts will be there.

** There’s no way to force pages requiring PR to add such an XObject and
thus it’s not done consistently

but it _could_ be done. If an application developer would like to do it,
they should be able to do it.

** We don’t even have a page listing all pages requiring PR and even if we
had one I’m not exactly what it would bring. I guess the idea was to make
it simpler to install/upgrade XWiki but we’ve fixed this already in the
Wiki Creation Wizard for example so the need is less now.

There are extensions that use it, like Admin Tools:

https://github.com/xwiki-contrib/application-admintools/blob/master/src/main/resources/Admin/CheckProgrammingRights.xml#L327

Thanks,
Anca


On Fri, Mar 20, 2015 at 11:57 AM, vinc...@massol.net vinc...@massol.net
wrote:

 Hi devs,

 In xwiki-enteprise we have XWiki.RequiredRightClass. We’ve started
 discussing it in the past in the “Split XE pages” mail thread and I’d like
 to move forward.

 So we need to decide what to do about it. Several options:

 * We discussed moving it to xwiki-platform-administration but it shouldn’t
 go there IMO since we’re trying to make this module almost empty (just
 providing the extension points mechanism) and have admin features
 dispatched in the modules providing them. Also it would mean forcing
 unnecessary dependencies on xwiki-platform-administration from several
 modules (6-7 right now).
 * It could go in a new xwiki-platform-security-ui module.
 * It could be moved to Java but we don’t have a clear policy nor decision
 if we want to favor xclasses written in java or opposite, decide that we
 don’t want that and move away from XClasses in Java. So we’d need to decide
 this first.
 * We could also simply remove it! Rationale:
 ** I don’t think we’re using that information much and its need is
 supposed to go away once signed scripts is there
 ** There’s no way to force pages requiring PR to add such an XObject and
 thus it’s not done consistently
 ** We don’t even have a page listing all pages requiring PR and even if we
 had one I’m not exactly what it would bring. I guess the idea was to make
 it simpler to install/upgrade XWiki but we’ve fixed this already in the
 Wiki Creation Wizard for example so the need is less now.

 So overall I’m more in favor of dropping this experiment which IMO wasn’t
 very successful.

 WDYT?

 Thanks
 -Vincent



 ___
 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

Re: [xwiki-devs] Ownership of the metadata about the subwiki

[Anca Luca]

This is a very interesting usecase, Guillaume, because it goes a bit
against the idea that the wiki admins should have the rights to change
the settings of the subwikis. So this shows that we need to describe
properly the usecases, and potentially choose between old wikis usecases
and workspaces usecases.

Let's keep the discussion going,
how do you guys feel about this? Who does this data belong to?

Thanks,
Anca

On Mon, Dec 22, 2014 at 9:35 AM, Guillaume Lerouge guilla...@xwiki.com
wrote:

 Hi,

 I've recently met this issue on a 6.3 instance. I wanted to set it up so
 that each sub-wiki would be independent from the others (local-users only).
 Users and admins that are local to a wiki should NOT know that there are
 other wikis on the farm.

 As expected, when creating a wiki and selecting local-only users, the 3
 possible wiki types were greyed out since they don't make sense in that
 configuration. However, I discovered that local users that have the admin
 right on a sub-wiki still get access to the Users section of the
 administration, where they can... change the wiki type.

 Since they're only local users, that does not cause a security issue - they
 still cannot see any other wiki on the farm. However, it doesn't make sense
 letting the local admin change that setting: the only thing they can do is
 mess things up.

 One solution in my case could be to switch to the old wiki-only wiki
 manager, without workspaces, but I'm not 100% sure that's what we want to
 do? In that case, why should we permit workspaces with local-users only in
 the first place?

 Thanks,

 Guillaume

 On Tue, Dec 16, 2014 at 8:21 PM, Anca Luca lu...@xwiki.com wrote:
 
  Hello devs,
 
  = Short story =
 
  Since the metadata about a subwiki (pretty name, description, users
 scope)
  are in the middle between main wiki and the subwiki (are used on both),
 who
  should have the last word about this data? Global admin of the farm of
  local admin of the subwiki?
 
  = Long story =
 
  while looking at http://jira.xwiki.org/browse/XWIKI-11416 , we came
 across
  a couple of questions about what is a subwiki and who owns (controls)
 the
  metadata about it.
 
  It all started with the fact that XWIKI-11416 would imply allowing the
  local admins of the subwiki (potentially local users) to edit information
  which is stored on the main wiki. There are 2 important things to discuss
  about this requirement:
 
  A.
  1/ it is important that the metadata about a subwiki can be controlled by
  the local admin group, or another _group_ of people. The owner of the
 wiki
  is not enough, as owner is not a role and can only be fulfilled by one
  person, which is limiting in terms of collaboration.
  2/ the wiki description and pretty name are stored on the main wiki
 today,
  in the wiki descriptor, while information about the user scope and
  membership are stored on the subwiki. This was changed recently, when the
  wiki concept was revamped and integrated with workspaces, in 5.3 (before
  that, everything was on the main wiki).
 
  A 2/ takes us to the main question of this mail: who is responsible /
  should should be responsible for the information about a subwiki? One
  direct consequence of this answer is the storage of this data, but the
  implications are larger than that because they can define the usecases
 that
  we support for the new wikis (as they are defined by the new
 implementation
  from 5.3).
 
  This question arises because this metadata is quite tricky as it
 represents
  the relation between the main wiki and the subwikis, so it could be
  considered that both main wiki and subwikis have priority on it.
 
  Please express your opinion about the following approaches, both as a
  general guideline, and in particular in the context of the 5 items from
 the
  descriptor that we're discussing: pretty name, wiki description,
 membership
  type, user scope, owner.
 
  B
  1/ the global admin must be able to control the data about the subwikis,
  regardless of the opinion of the local admins
  2/ the local admins should be free to configure the data about the
  subwikis, without the global admin controlling these settings. Note that
  this is already the case for wiki rights, by construction of the wiki,
 and
  recently this was chosen for user scope and membership type by storing
 them
  on to the subwiki in 5.3
  3/ both approaches should be possible, depending on the type of farm we
  make (farm of wikis with subwikis with local users which don't know one
  about the existence of the other wikis, a la myxwiki.org or farm of
 wikis
  where users can create wikis of their own, workspaces style)
  4/ both approaches should be possible, depending on the type of wiki,
 which
  should be decided by the global admin (on the same farm we could have
 some
  wikis on which global admin decides this metadata and some wikis on which
  local admins decide it)
 
  Note that B 3 and 4, in my opinion, have consequences on the type

Re: [xwiki-devs] [Brainstorming] Improving the Top level Menu/Breadcrumb/Navigation

[Anca Luca]

On Thu, Oct 9, 2014 at 5:59 PM, vinc...@massol.net vinc...@massol.net
wrote:






 On 9 Oct 2014 at 17:57:46, Jeremie BOUSQUET (jeremie.bousq...@gmail.com
 (mailto:jeremie.bousq...@gmail.com)) wrote:

  Hi,
 
  In fact, colibri top-menu was better than bootstrap buttons ! :D
 
  Why not putting back old ways of interacting ?
  - re-add display of dropdown menu on hover [1]
  - re-add underlining on hover of links in menu text

 The reason we changed that was for mobiles. We could decide to have
 different behaviors on mobile and desktops but not sure it’s best. WDYT?



I think it's not bad to have a slightly different behaviour for desktop and
mobile. I don't have much experience with this but I think that we should
not ruin desktop experience because it has to work on mobile. If different
behaviour is the solution, let's do it.

I think the old behaviour with the hover was quite natural, and the fact
that bootstrap does not have those buttons by default is because it's
mobile first. But, as much as we'd want it, XWiki is not yet mobile first
(I would say most of the usage of XWiki today is still desktop, but since I
don't have statistics I cannot prove it. I can only use my personal
statistic, from my experience and the cases I know).

2 clicks feels completely unnatural on desktop, especially when coming from
colibri.

I would not want to let Bootstrap kill our UI choices, I think it's the bad
reason to say that we won't do it because bootstrap does not have a
default component for it.

Thanks,
Anca




 Thanks
 -Vincent

  Problem I feel is for second item as it seems bootstrap won't easily
 allow
  you to hover on something (for dropdown) and click on it (to do something
  else than show dropdown). Also I suppose there are impacts on mobile
  version.
 
  I don't think the new flamingo way is bad, but visually it looks very
  similar to colibri (a text + a little triangle), but when you hover
 nothing
  happens, and you have no visual clue that something different may happen
 if
  you click on the text or on the triangle. For example take the New
 button
  in Outlook 2007 which is exactly a dropdown button, when I hover on it I
  see a clear separation between the New text, and the arrow, so I can
  assume that both lead to different results.
 
  With the Add and Edit buttons it's completely different, you see the
  separation, and on hoovering the color changes (of the text OR of the
 arrow
  background). You are prepared to the fact that something different will
  occur.
  But doing the same in top menu would clearly not fit expected lookfeel
 of
  this beautiful skin...
 
  BR,
  Jeremie
 
  [1] - http://cameronspear.com/demos/bootstrap-hover-dropdown/
 
  2014-10-09 16:02 GMT+02:00 vinc...@massol.net :
 
  
  
  
  
  
   On 9 Oct 2014 at 14:23:49, Eduard Moraru (enygma2...@gmail.com(mailto:
   enygma2...@gmail.com)) wrote:
  
On Thu, Oct 9, 2014 at 3:15 PM, vinc...@massol.net
wrote:
   





 On 9 Oct 2014 at 14:02:05, Eduard Moraru (enygma2...@gmail.com
 (mailto:
 enygma2...@gmail.com)) wrote:

  Folks, you speak of consistency and then come up with this
   solution...
 
  So we have a problem with non-standard bootstrap dropdown
 buttons
   that
  our users (whoever they may be) have a problem with understanding
   that
  there is either an action or a dropdown involved in the same
 button,
   like
  they can encounter in other interfaces along their computer usage
 history.
 
  Our solution is to stop using the mixed mode, and only use the
   standard
  bootstrap dropdown buttons that have their first action in the
   submenu
 the
  thing that would have happened in the past when the users clicked
 directly
  the action part of the mixed button we were using.
 
  Ok, we implement this solution, but we only do it for the top
 navigational
  elements. We completely ignore the Add and the Edit buttons
 that
  suffer from exactly the same problem.
 
  My question is: why?
 
  If we do/did decide that this is the way to go, we should at
 least be
  consistent and do it everywhere in the UI, otherwise it just
 causes
  frustrations.

 There’s a difference. For the Edit/Add button click the button
 will do
 what the user wants. Click the arrow is only for advanced featurs.

   
It seems they either don’t understand the little triangles and what
 it’s
about (submenu?) or they click on the menu itself and go to another
 page
when they were expecting some menu to drop down, or..
   
There is no difference from the problem you have mentioned in the
 OP.
   The
user sees an arrow and clicks on the button to expand the menu, but
   instead
ends up reloading the page (either to edit mode or to view mode, same
thing). You will say that he wanted to edit anyway, yes, but maybe
 he did
not want to edit in the default mode, 

Re: [xwiki-devs] [Proposal] Simplified Home Page

[Anca Luca]

Hello Edi,


On Mon, Oct 20, 2014 at 12:34 PM, Eduard Moraru enygma2...@gmail.com
wrote:

 On Fri, Oct 17, 2014 at 7:26 PM, Anca Luca lu...@xwiki.com wrote:

  Hello all,
 
  so on the topic of removing the dashboard from the homepage and if
 people
  need it they can access it independently.
 
  In my opinion, this dashboard does not really exist or have any value
  beyond the homepage. I mean, what does it mean, what is it used for
 besides
  the homepage? What would the dashboard be used other than having an
  overview of the wiki? And if people remove it from the homepage of the
  wiki, what would they put instead? An overview of the wiki? Isn't that
 what
  dashboard means?
 

 The idea of this proposal was that the homepage should be customized by the
 admin. It should be a homepage. Instead of a Dashboard, it should contain
 information about the purpose of the wiki, information for newcomers,
 information about the organization, some video, etc. All of this we plan to
 encourage the admins to customize so that they take ownership of their
 wiki instead of seeing it as just a tool with default settings. Some may
 see disadvantages to this, and prefer default tools, but others may see the
 value of getting the user/admin involved.

 The Dashboard should be seen as a place to go to in order to see what is
 going on. Dashboards in the wild also tend to be customizable per users (we
 technically support that as well, but it could be improved, i.e. have a
 default user dashboard in the 'My dashboard' section in the user profile
 instead of the empty space that is right now in view mode, promote it more,
 etc.). They also tend to be used by more technical people

 Once the admin is involved and now aware of how to do things, he can easily
 include the dashboard on the homepage if that is his view on the purpose of
 his wiki. We can even propose it in the default content of the homepage.

 What you choose depends a lot on the usecase you have for your wiki, i.e.
 what flavor you`re using. For example, a dashboard is good for
 intranet/groupware but not that good for public websites. We are
 considering here what we want the default experience to offer/encourage and
 maybe we should not really focus on/be influenced by any of the flavors/use
 cases we are having in mind.


 
  By this logic, I would find it strange to have a homepage and a
 dashboard,
  as 2 separate entities, because for me they would mean the same thing. So
  multiple possibilities:
  1/ our _default_ dashboard displayed on the homepage (included or not, I
  don't care) is not good enough because it does not offer a good _default_
  overview of the wiki. We need to change the dashboard.


 This is not part of the use cases [1] extracted from previous discussions.
 Are you proposing that we add offer a good overview of the wiki as a new
 use case/goal or is this just a rewording of UC5 (navigation) ?


I need to think a little more about this in order to make a complete
answer, but I read the list of usecases and I remarked one thing:

In all UC1 to UC5, I think your user is more of an admin than a user. I
see the following flow in working with a wiki:
Alice downloads the wiki and plays around with it locally, tests it and
checks its features. Then, she is convinced by the tool and decides to move
this to the next level and install the wiki on a server (or get it
installed) so that she can collaborate with her colleagues, Bob, Billy and
Bogdan. To me Alice is not a user, she's more like a wiki admin. Then when
the wiki is installed on the server, the three B boys are the users and
Alice might become a user as well, or might always stay a little more
admin. When she moves from her private tests to a public tool, Alice
prepares the homepage of the wiki so that it matches the purpose of the
wiki and the B boys. Alice will need to UC3: The user needs to be able to
easily replace the home page with his content but the B boys won't.

I think that the admin (Alice) homepage needs cannot be analysed
independently from the user (Bob, Billy and Bogdan) homepage needs, because
we risk to provide the admin with customization tools that they will never
need because the user will never need such a customization.


Thanks,
Anca



 Thanks,
 Eduard

 [1] http://design.xwiki.org/xwiki/bin/view/Proposal/HomepageUseCases


  In this case, we
  improve the way we modify this dashboard, to allow people to change the
  default overview which guides the user through the wiki with an
 overview
  that is more adapted to the user's usecase.
  2/ we change the homepage and we remove the dashboard from it and
 implement
  an overview of the wiki differently (which would still be a dashboard at
  the conceptual level but implemented differently). In this case, the
  Dashboard.WebHome should be removed completely from the menu, because the
  dashboard _is_ the home page (see my remark above) :) . We can make the
  homepage a regular page so that users can edit it very

Re: [xwiki-devs] [Brainstorming] Improving the Top level Menu/Breadcrumb/Navigation

[Anca Luca]

Hi all,

I kind of liked this solution as well, I think, I sort of ended up getting
used to it. Indeed maybe the button needs to be more obviously a button.

The big disadvantage of hover is that people don't realise that the menu is
clickable by itself. I have seen a lot of users trying to choose something
from the submenu, not even trying to click on the top of the menu because
they don't realize the menu is clickable itself as well. This is also valid
for the edit menu, but a bit less bothering because regular users in
general don't have a submenu for the edit menu.

So, if I was to choose now, then maybe the 6.2.1 version would be the
one, but with an improvement of the arrow to make it look more like an
extra clickable button to unpack more options.
Also, maybe a combination of the 2: clickable menu and an extra option to
go to the space in the menu if the user unpacks it.

I would be curious of Vincent's experience, which started this change in
the first place (the fact that people don't figure out that they can unpack
the menu or that they click the whole item to unpack the menu).

Thanks,
Anca

On Tue, Oct 21, 2014 at 3:43 PM, Guillaume Lerouge guilla...@xwiki.com
wrote:

 Hi,

 on this topic, I liked this intermediary solution a lot for the desktop
 mode:

- *Nothing happening on hover*
   - I actually think removing the on hover behavior is great in the top
   bar
   - I've seen it generate confusion / frustration in the wild,
   especially when there's a menu, (for which on hover behavior makes
 sense)
   underneath


- *Entity name is a link to the wiki home / space home / page*


- *Clicking on the arrow button displays the menu*
   - Maybe the actual issue is to make the arrow more prominent as a
   clickable button?

 Thanks,

 Guillaume

 On Tue, Oct 21, 2014 at 11:33 AM, vinc...@massol.net vinc...@massol.net
 wrote:

  It's hard to disagree with this and I also agree it would be a pity to
  have a suboptimal desktop experience because of touch devices :)
 
  Remaining questions:
 
  * How much work is it to maintain 2 versions of the menus (one for touch
  devices and one for Desktop)?
  * Is it natural/ok for users to have the Colibri behavior when using
  boostrap menus/buttons?
 
  Thanks
  -Vincent
 
 
  On 21 Oct 2014 at 11:00:48, Anca Luca (lu...@xwiki.com(mailto:
  lu...@xwiki.com)) wrote:
 
   On Thu, Oct 9, 2014 at 5:59 PM, vinc...@massol.net
   wrote:
  
   
   
   
   
   
On 9 Oct 2014 at 17:57:46, Jeremie BOUSQUET (
  jeremie.bousq...@gmail.com
(mailto:jeremie.bousq...@gmail.com)) wrote:
   
 Hi,

 In fact, colibri top-menu was better than bootstrap buttons ! :D

 Why not putting back old ways of interacting ?
 - re-add display of dropdown menu on hover [1]
 - re-add underlining on hover of links in menu text
   
The reason we changed that was for mobiles. We could decide to have
different behaviors on mobile and desktops but not sure it’s best.
  WDYT?
   
  
  
   I think it's not bad to have a slightly different behaviour for desktop
  and
   mobile. I don't have much experience with this but I think that we
 should
   not ruin desktop experience because it has to work on mobile. If
  different
   behaviour is the solution, let's do it.
  
   I think the old behaviour with the hover was quite natural, and the
 fact
   that bootstrap does not have those buttons by default is because it's
   mobile first. But, as much as we'd want it, XWiki is not yet mobile
 first
   (I would say most of the usage of XWiki today is still desktop, but
  since I
   don't have statistics I cannot prove it. I can only use my personal
   statistic, from my experience and the cases I know).
  
   2 clicks feels completely unnatural on desktop, especially when coming
  from
   colibri.
  
   I would not want to let Bootstrap kill our UI choices, I think it's the
  bad
   reason to say that we won't do it because bootstrap does not have a
   default component for it.
  
   Thanks,
   Anca
  
  
  
   
Thanks
-Vincent
   
 Problem I feel is for second item as it seems bootstrap won't
 easily
allow
 you to hover on something (for dropdown) and click on it (to do
  something
 else than show dropdown). Also I suppose there are impacts on
 mobile
 version.

 I don't think the new flamingo way is bad, but visually it looks
 very
 similar to colibri (a text + a little triangle), but when you hover
nothing
 happens, and you have no visual clue that something different may
  happen
if
 you click on the text or on the triangle. For example take the
 New
button
 in Outlook 2007 which is exactly a dropdown button, when I hover on
  it I
 see a clear separation between the New text, and the arrow, so I
  can
 assume that both lead to different results.

 With the Add and Edit buttons it's completely different, you
 see
  the
 separation

Re: [xwiki-devs] [Proposal] Simplified Home Page

[Anca Luca]

Hi Edi,

I sort of understand from this mail that you think I am defending the
dashboard on the homepage. I cannot figure out how you got that idea.

The only thing I was saying in the previous mail is that 2 dashboards  by
default don't make sense for me, because dashboard means to me overview and
I think we should rather make it easy for users to turn their homepage in a
proper overview rather than have 2 overviews. Because if we have the
dashboard separately (as today), then the Alices will create on the
homepage their own overview of the wiki, and then Bob, Billy and Bogdan
will have 2 of them. This is not necessarily bad, to be able to have
multiple dashboards, because you can imagine multiple facets of the same
wiki, but I think for a default wiki user is confusing (seeing the homepage
which is an overview and having a link on the right that takes to an
overview).

When I said that the 2 personas need to be analyzed together it was more
about what kind of customization we promote to the admin (Alice). E.g.
explaining as a generic thing that they could include another page and they
could customize could be too generic for the need of Alice, which is to
create a proper welcome page for the B-boys. If we knew / decided on what
is a proper welcome page for the B-boys, then we could make a choice about
how to allow Alice to take ownership, encourage editing, etc AND, in
addition, go towards the users oriented homepage.

On Tue, Oct 21, 2014 at 3:32 PM, Eduard Moraru enygma2...@gmail.com wrote:

 Hi Anca,

 On Tue, Oct 21, 2014 at 12:38 PM, Anca Luca lu...@xwiki.com wrote:

  Hello Edi,
 
 
  On Mon, Oct 20, 2014 at 12:34 PM, Eduard Moraru enygma2...@gmail.com
  wrote:
 
   On Fri, Oct 17, 2014 at 7:26 PM, Anca Luca lu...@xwiki.com wrote:
  
Hello all,
   
so on the topic of removing the dashboard from the homepage and if
   people
need it they can access it independently.
   
In my opinion, this dashboard does not really exist or have any value
beyond the homepage. I mean, what does it mean, what is it used for
   besides
the homepage? What would the dashboard be used other than having an
overview of the wiki? And if people remove it from the homepage of
 the
wiki, what would they put instead? An overview of the wiki? Isn't
 that
   what
dashboard means?
   
  
   The idea of this proposal was that the homepage should be customized by
  the
   admin. It should be a homepage. Instead of a Dashboard, it should
 contain
   information about the purpose of the wiki, information for newcomers,
   information about the organization, some video, etc. All of this we
 plan
  to
   encourage the admins to customize so that they take ownership of
 their
   wiki instead of seeing it as just a tool with default settings. Some
 may
   see disadvantages to this, and prefer default tools, but others may see
  the
   value of getting the user/admin involved.
  
   The Dashboard should be seen as a place to go to in order to see what
 is
   going on. Dashboards in the wild also tend to be customizable per users
  (we
   technically support that as well, but it could be improved, i.e. have a
   default user dashboard in the 'My dashboard' section in the user
 profile
   instead of the empty space that is right now in view mode, promote it
  more,
   etc.). They also tend to be used by more technical people
  
   Once the admin is involved and now aware of how to do things, he can
  easily
   include the dashboard on the homepage if that is his view on the
 purpose
  of
   his wiki. We can even propose it in the default content of the
 homepage.
  
   What you choose depends a lot on the usecase you have for your wiki,
 i.e.
   what flavor you`re using. For example, a dashboard is good for
   intranet/groupware but not that good for public websites. We are
   considering here what we want the default experience to offer/encourage
  and
   maybe we should not really focus on/be influenced by any of the
  flavors/use
   cases we are having in mind.
  
  
   
By this logic, I would find it strange to have a homepage and a
   dashboard,
as 2 separate entities, because for me they would mean the same
 thing.
  So
multiple possibilities:
1/ our _default_ dashboard displayed on the homepage (included or
 not,
  I
don't care) is not good enough because it does not offer a good
  _default_
overview of the wiki. We need to change the dashboard.
  
  
   This is not part of the use cases [1] extracted from previous
  discussions.
   Are you proposing that we add offer a good overview of the wiki as a
  new
   use case/goal or is this just a rewording of UC5 (navigation) ?
  



That would be proposal 1 here:
http://design.xwiki.org/xwiki/bin/view/Proposal/HomepageProposal1Keepcurrenthomepagefixproblems
rather than a UC.

Since I don't know anymore what this mail is about and I am sure we're
gonna get lost in details, here is my proposal (corresponsad to by option
2) expressed

Re: [xwiki-devs] [Proposal] Simplified Home Page

[Anca Luca]

On Tue, Oct 21, 2014 at 7:47 PM, Anca Luca lu...@xwiki.com wrote:

 Hi Edi,

 I sort of understand from this mail that you think I am defending the
 dashboard on the homepage. I cannot figure out how you got that idea.

 The only thing I was saying in the previous mail is that 2 dashboards  by
 default don't make sense for me, because dashboard means to me overview and
 I think we should rather make it easy for users to turn their homepage in a
 proper overview rather than have 2 overviews. Because if we have the
 dashboard separately (as today), then the Alices will create on the
 homepage their own overview of the wiki, and then Bob, Billy and Bogdan
 will have 2 of them. This is not necessarily bad, to be able to have
 multiple dashboards, because you can imagine multiple facets of the same
 wiki, but I think for a default wiki user is confusing (seeing the homepage
 which is an overview and having a link on the right that takes to an
 overview).

 When I said that the 2 personas need to be analyzed together it was more
 about what kind of customization we promote to the admin (Alice). E.g.
 explaining as a generic thing that they could include another page and they
 could customize could be too generic for the need of Alice, which is to
 create a proper welcome page for the B-boys. If we knew / decided on what
 is a proper welcome page for the B-boys, then we could make a choice about
 how to allow Alice to take ownership, encourage editing, etc AND, in
 addition, go towards the users oriented homepage.

 On Tue, Oct 21, 2014 at 3:32 PM, Eduard Moraru enygma2...@gmail.com
 wrote:

 Hi Anca,

 On Tue, Oct 21, 2014 at 12:38 PM, Anca Luca lu...@xwiki.com wrote:

  Hello Edi,
 
 
  On Mon, Oct 20, 2014 at 12:34 PM, Eduard Moraru enygma2...@gmail.com
  wrote:
 
   On Fri, Oct 17, 2014 at 7:26 PM, Anca Luca lu...@xwiki.com wrote:
  
Hello all,
   
so on the topic of removing the dashboard from the homepage and if
   people
need it they can access it independently.
   
In my opinion, this dashboard does not really exist or have any
 value
beyond the homepage. I mean, what does it mean, what is it used for
   besides
the homepage? What would the dashboard be used other than having an
overview of the wiki? And if people remove it from the homepage of
 the
wiki, what would they put instead? An overview of the wiki? Isn't
 that
   what
dashboard means?
   
  
   The idea of this proposal was that the homepage should be customized
 by
  the
   admin. It should be a homepage. Instead of a Dashboard, it should
 contain
   information about the purpose of the wiki, information for newcomers,
   information about the organization, some video, etc. All of this we
 plan
  to
   encourage the admins to customize so that they take ownership of
 their
   wiki instead of seeing it as just a tool with default settings. Some
 may
   see disadvantages to this, and prefer default tools, but others may
 see
  the
   value of getting the user/admin involved.
  
   The Dashboard should be seen as a place to go to in order to see what
 is
   going on. Dashboards in the wild also tend to be customizable per
 users
  (we
   technically support that as well, but it could be improved, i.e. have
 a
   default user dashboard in the 'My dashboard' section in the user
 profile
   instead of the empty space that is right now in view mode, promote it
  more,
   etc.). They also tend to be used by more technical people
  
   Once the admin is involved and now aware of how to do things, he can
  easily
   include the dashboard on the homepage if that is his view on the
 purpose
  of
   his wiki. We can even propose it in the default content of the
 homepage.
  
   What you choose depends a lot on the usecase you have for your wiki,
 i.e.
   what flavor you`re using. For example, a dashboard is good for
   intranet/groupware but not that good for public websites. We are
   considering here what we want the default experience to
 offer/encourage
  and
   maybe we should not really focus on/be influenced by any of the
  flavors/use
   cases we are having in mind.
  
  
   
By this logic, I would find it strange to have a homepage and a
   dashboard,
as 2 separate entities, because for me they would mean the same
 thing.
  So
multiple possibilities:
1/ our _default_ dashboard displayed on the homepage (included or
 not,
  I
don't care) is not good enough because it does not offer a good
  _default_
overview of the wiki. We need to change the dashboard.
  
  
   This is not part of the use cases [1] extracted from previous
  discussions.
   Are you proposing that we add offer a good overview of the wiki as a
  new
   use case/goal or is this just a rewording of UC5 (navigation) ?
  



 That would be proposal 1 here:
 http://design.xwiki.org/xwiki/bin/view/Proposal/HomepageProposal1Keepcurrenthomepagefixproblems
 rather than a UC.

 Since I don't know anymore what this mail is about and I

[xwiki-devs] About using bootstrap/flamingo for customizations in XWiki

[Anca Luca]

Hello guys,

I have tried to learn a bit of bootstrap last night to figure out how to do
things, and I did the following test page to test the grid system:

http://incubator.myxwiki.org/xwiki/bin/view/Sandbox/TestFlamingo?skin=flamingo

I have a few questions related to using the grid system (I didn't yet get
to other parts of bootstrap/flamingo):
The questions will get fuzzy-er and fuzzy-er as they advance. Please bare
with me, I have a lot of questions and little knowledge about bootstrap, I
am trying to figure out how should it be used in general (it's supposed to
be simple but I don't feel like it) and if there are some special rules of
usage in XWiki.

1/ What would be the proper structure if we wanted to make a grid layout in
a wiki page ?
My experiments show that the first example, div class=row and then columns
inside will not work (example doesn't fit properly). The second example
works, but that means we need to add .container-fluid all around that.
Let's assume for the next questions that we're using the .container-fluid
structure.
2/ On the bootstrap website here
http://getbootstrap.com/css/#overview-container I found that neither
container is nestable . I don't really know how to understand this phrase,
especially in the context of needing to put it in the content of my page in
order to make a grid. Is it dangerous to put it? Could it end up being
nested and thus not good?
3/ On the bootstrap website here http://getbootstrap.com/css/#grid I found
that any row must be in a container (which matches my usage). But I am
looking at the .document-header which contains the title and the edit
buttons, and it is not in a container. Or is it? If that one is in a
container, does that mean that we have a global container in the page in
XWiki which would also surround the page content (#xwikicontent) and then
if I put another .container-fluid in the document content in order to make
the grid I would be nesting containers?
4/ I didn't fully understand this story about the negative margins that
compensate for padding in order for columns to align with non-grid
content... ( 5th and 6th bullets in here http://getbootstrap.com/css/#grid  ).
I did some examples in my test page in section Fits properly, and I would
like to understand better this principle / approach. What would be the
correct way to mix  match full width elements and grid in the document
content? (by full width I mean either a paragraph with text, or other
elements that need to take up the whole width of the document content area
#xwikicontent).
a) anything that has to be full-width should be out of a .container-fluid
and whenever I want columns I make a new .container-fluid? -- the text
this is the  in section Fits Properly
b) can I put stuff in a container fluid? If I do, then why is it indented?
The text dancing in section Fits Properly
c) I read in BS documentation that only columns should be direct children
of .row so the text text in section Fits Properly is not an option
(although correctly displayed). Please confirm
d) I added a third column, with size 12 at the end, to get something full
width. I guess this is one approach, but then its text is not aligned with
the left of the column, but, because it is a column itself, it has a
padding of 10px. So the texts are aligned (text in half column with text in
full width but the full width text is not aligned with the border of the
half column). Is it a bad practice to put borders directly on the
bootstraps column? Should I be putting border on an element that I have put
inside the bootstrap column? In this case, I would get a lot of space
between the left side of the screen and my text. Maybe some of that space
gets colored in a different color theme?
e) should I be matching and mixing full-width stuff and grid stuff at all?
Is this a good idea? or if I need a part of the content in a grid then I
just make all content a grid and make col-12 for all the stuff that needs
to be full-width?
5/ Also, I just noticed now that the content of a page is not (in) a column
( #xwikicontent ). I was thinking that it could be a 12 size column which
we could split further by using this strategy:
http://getbootstrap.com/css/#grid-nesting . Since the document-header is a
row with columns, I was thinking that the lower part of the page could be
as well... This way, aligning stuff inside could be more natural (see
subquestion 4 d before).

Thank you a lot for your patience, I do take RTFMs as I am sure there are
parts of the internet that could enlight me on the topic. What I would like
to know is how did we plan to use bootstrap grid in the context of XWiki
for custom stuff, if there are some special rules...

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

Re: [xwiki-devs] About using bootstrap/flamingo for customizations in XWiki

[Anca Luca]

Hi Cati,

On Fri, Oct 17, 2014 at 3:03 PM, Ecaterina Moraru (Valica) 
vali...@gmail.com wrote:

 On Fri, Oct 17, 2014 at 1:45 PM, Anca Luca lu...@xwiki.com wrote:

  Hello guys,
 
  I have tried to learn a bit of bootstrap last night to figure out how to
 do
  things, and I did the following test page to test the grid system:
 
 
 
 http://incubator.myxwiki.org/xwiki/bin/view/Sandbox/TestFlamingo?skin=flamingo
 
  I have a few questions related to using the grid system (I didn't yet get
  to other parts of bootstrap/flamingo):
  The questions will get fuzzy-er and fuzzy-er as they advance. Please bare
  with me, I have a lot of questions and little knowledge about bootstrap,
 I
  am trying to figure out how should it be used in general (it's supposed
 to
  be simple but I don't feel like it) and if there are some special rules
 of
  usage in XWiki.
 
  1/ What would be the proper structure if we wanted to make a grid layout
 in
  a wiki page ?
  My experiments show that the first example, div class=row and then
 columns
  inside will not work (example doesn't fit properly). The second example
  works, but that means we need to add .container-fluid all around that.
  Let's assume for the next questions that we're using the .container-fluid
  structure.
 

 Theoretical you cannot nest .containers since they add padding and you will
 not be able to align the inner grids (they will be shifted with the value
 of the padding) (that's why the rows is using negative margin).

 In theory the good solution is the first one (just with the row). Why is
 not working is because on #xwikicontent we have 'overflow: auto'. If you
 remove that line, the grid should be displayed correctly (from the text
 alignment point of view). Why we have 'overflow: auto'? Because of
 http://jira.xwiki.org/browse/XWIKI-10791 and because in XWiki.XWikiSyntax
 we have very big tables, etc. I don't have a clear solution for this
 problem, maybe is simpler than what I think, but the big issue is that in
 #xwikicontent we have, depending on the context, either layout containers,
 either text (for wiki pages). The user's content needs to be overflowed,
 while when doing interface the developers are in control of the grid and
 know 'exactly' was goes in.



  2/ On the bootstrap website here
  http://getbootstrap.com/css/#overview-container I found that neither
  container is nestable . I don't really know how to understand this
 phrase,
  especially in the context of needing to put it in the content of my page
 in
  order to make a grid. Is it dangerous to put it? Could it end up being
  nested and thus not good?
  3/ On the bootstrap website here http://getbootstrap.com/css/#grid I
 found
  that any row must be in a container (which matches my usage). But I am
  looking at the .document-header which contains the title and the edit
  buttons, and it is not in a container. Or is it? If that one is in a
  container, does that mean that we have a global container in the page
 in
  XWiki which would also surround the page content (#xwikicontent) and then
  if I put another .container-fluid in the document content in order to
 make
  the grid I would be nesting containers?
 

 Flamingo is not a clean skin. We still haven't a response to the Standards
 discussion http://design.xwiki.org/xwiki/bin/view/Proposal/UIStandards .
 What do you do when writing application in Flamingo? Do you keep some of
 the old classes? do you replace them with Bootstrap ones? In Flamingo we
 have a mix :) depending on whom did the commit. You will see places where
 the old structure is kept and other places where you have Boostrap classes.
 Would you have expected to have something like div
 id='xwikimaincontainer' class='container-fluid'? This is a solution too,
 but it increases the HTML. Also maybe we would want to add the Bootstrap
 classes and remove the old ones (in order to keep the structure clean), but
 no one know if that ids and classes are used in some JS somewhere in the
 platform and thus you shouldn't remove them.


Indeed, removing the ids can be dangerous.

It would have been easier to read the html, but I could do it with the
links under.


 So in order not to add Bootstrap classes, but have their functionality, we
 'cheated' by using LESS (mixins and extends). For example

 https://github.com/xwiki/xwiki-platform/blob/master/xwiki-platform-core/xwiki-platform-flamingo/xwiki-platform-flamingo-skin/src/main/resources/flamingo/less/layout.less#L4
 and

 https://github.com/xwiki/xwiki-platform/blob/master/xwiki-platform-core/xwiki-platform-flamingo/xwiki-platform-flamingo-skin/src/main/resources/flamingo/less/layout.less#L8
 With LESS and Boostrap mixins we made contentcontainer a .row without
 explicitly writing it in the structure. You can take a look at layout.less
 (and actually more less files in less/ folder). I assume some things might
 not be perfect since Flamingo was done in a hurry.


Indeed these links help a lot, now it all makes more sense

Re: [xwiki-devs] About using bootstrap/flamingo for customizations in XWiki

[Anca Luca]

On Fri, Oct 17, 2014 at 4:55 PM, Anca Luca lu...@xwiki.com wrote:

 Hi Cati,

 On Fri, Oct 17, 2014 at 3:03 PM, Ecaterina Moraru (Valica) 
 vali...@gmail.com wrote:

 On Fri, Oct 17, 2014 at 1:45 PM, Anca Luca lu...@xwiki.com wrote:

  Hello guys,
 
  I have tried to learn a bit of bootstrap last night to figure out how
 to do
  things, and I did the following test page to test the grid system:
 
 
 
 http://incubator.myxwiki.org/xwiki/bin/view/Sandbox/TestFlamingo?skin=flamingo
 
  I have a few questions related to using the grid system (I didn't yet
 get
  to other parts of bootstrap/flamingo):
  The questions will get fuzzy-er and fuzzy-er as they advance. Please
 bare
  with me, I have a lot of questions and little knowledge about
 bootstrap, I
  am trying to figure out how should it be used in general (it's supposed
 to
  be simple but I don't feel like it) and if there are some special rules
 of
  usage in XWiki.
 
  1/ What would be the proper structure if we wanted to make a grid
 layout in
  a wiki page ?
  My experiments show that the first example, div class=row and then
 columns
  inside will not work (example doesn't fit properly). The second
 example
  works, but that means we need to add .container-fluid all around that.
  Let's assume for the next questions that we're using the
 .container-fluid
  structure.
 

 Theoretical you cannot nest .containers since they add padding and you
 will
 not be able to align the inner grids (they will be shifted with the value
 of the padding) (that's why the rows is using negative margin).

 In theory the good solution is the first one (just with the row). Why is
 not working is because on #xwikicontent we have 'overflow: auto'. If you
 remove that line, the grid should be displayed correctly (from the text
 alignment point of view). Why we have 'overflow: auto'? Because of
 http://jira.xwiki.org/browse/XWIKI-10791 and because in XWiki.XWikiSyntax
 we have very big tables, etc. I don't have a clear solution for this
 problem, maybe is simpler than what I think, but the big issue is that in
 #xwikicontent we have, depending on the context, either layout containers,
 either text (for wiki pages). The user's content needs to be overflowed,
 while when doing interface the developers are in control of the grid and
 know 'exactly' was goes in.



  2/ On the bootstrap website here
  http://getbootstrap.com/css/#overview-container I found that neither
  container is nestable . I don't really know how to understand this
 phrase,
  especially in the context of needing to put it in the content of my
 page in
  order to make a grid. Is it dangerous to put it? Could it end up being
  nested and thus not good?
  3/ On the bootstrap website here http://getbootstrap.com/css/#grid I
 found
  that any row must be in a container (which matches my usage). But I am
  looking at the .document-header which contains the title and the edit
  buttons, and it is not in a container. Or is it? If that one is in a
  container, does that mean that we have a global container in the page
 in
  XWiki which would also surround the page content (#xwikicontent) and
 then
  if I put another .container-fluid in the document content in order to
 make
  the grid I would be nesting containers?
 

 Flamingo is not a clean skin. We still haven't a response to the Standards
 discussion http://design.xwiki.org/xwiki/bin/view/Proposal/UIStandards .
 What do you do when writing application in Flamingo? Do you keep some of
 the old classes? do you replace them with Bootstrap ones? In Flamingo we
 have a mix :) depending on whom did the commit. You will see places where
 the old structure is kept and other places where you have Boostrap
 classes.
 Would you have expected to have something like div
 id='xwikimaincontainer' class='container-fluid'? This is a solution too,
 but it increases the HTML. Also maybe we would want to add the Bootstrap
 classes and remove the old ones (in order to keep the structure clean),
 but
 no one know if that ids and classes are used in some JS somewhere in the
 platform and thus you shouldn't remove them.


 Indeed, removing the ids can be dangerous.

 It would have been easier to read the html, but I could do it with the
 links under.


 So in order not to add Bootstrap classes, but have their functionality, we
 'cheated' by using LESS (mixins and extends). For example

 https://github.com/xwiki/xwiki-platform/blob/master/xwiki-platform-core/xwiki-platform-flamingo/xwiki-platform-flamingo-skin/src/main/resources/flamingo/less/layout.less#L4
 and

 https://github.com/xwiki/xwiki-platform/blob/master/xwiki-platform-core/xwiki-platform-flamingo/xwiki-platform-flamingo-skin/src/main/resources/flamingo/less/layout.less#L8
 With LESS and Boostrap mixins we made contentcontainer a .row without
 explicitly writing it in the structure. You can take a look at layout.less
 (and actually more less files in less/ folder). I assume some things might
 not be perfect since Flamingo

Re: [xwiki-devs] [Discussion] Where does livetable belong?

[Anca Luca]

On Wed, Oct 15, 2014 at 12:45 PM, Eduard Moraru enygma2...@gmail.com
wrote:

 Marius, thanks for the explanation, but I had no confusion there. Maybe I
 did not explain myself clear enough.

 The question (originally asked by Vincent) from the OP is Can/should we
 use the livetable inside templates? Is the livetable part of
 xwiki-platform-web or is a removable extension (xwiki-platform-livetable)?


Yes, we should be able to use it.

Otherwise, as you said above,  . The rightsUI would need a change as well,
since it can no longer rely on the livetable .  So how would this happen
from a practical point of view? We'd have another sort of table in the
platform-web default ressources which can be used by the vms, which is nice
and fancy and shiny but it's _not_ the livetable? And then the livetable
would continue to be a nice and shiny table but a different one, installed
as an extension? What would be the point of that? Or we'd make the rights
UI ugly because we won't make another shiny table? It doesn't make sense.
We need a nice table to implement default features, let the livetable be it
(and have only one), even if it means changing the livetable from an
extension to a standard web feature.

Thanks,
Anca



 Do we want to have that as a common practice inside templates when listing
 documents or not?

 If we do want it to be used inside templates, does it make sense to ask
 each template to implement its own data source (like you are proposing now
 for the delete space UI example) or should we allow the templates to use
 the default data source (by making it a template as well)?

 Thanks,
 Eduard





 On Wed, Oct 15, 2014 at 11:42 AM, Marius Dumitru Florea 
 mariusdumitru.flo...@xwiki.com wrote:

  Edy, you're mixing two things:
 
  (1) The live table widget. This is currently provided by
  xwiki-platform-web. The widget has some HTML template (currently in
  macros.vm), some JavaScript code (livetable.js) and some CSS
  (livetable.css). The widget is configurable. The main configuration
  option is the data source. As written on
 
 
 http://extensions.xwiki.org/xwiki/bin/view/Extension/Livetable+Macro#HParameter24options
  you can specify the data source either using the 'resultPage' or the
  'url' parameter. What's important is that it can use **any** data
  source.
 
  (2) The default data source. This is currently provided by
  xwiki-platform-livetable. Many applications have their own data
  sources though. You don't need this to use the live table widget.
 
  For the delete space UI issue you can use the url parameter server
  the live table JSON from a template, so you don't need
  xwiki-platform-livetable.
 
  The only question for me is whether the default data source should be
  moved to a template or not. I don't think we need to move it.
 
  Thanks,
  Marius
 
  On Tue, Oct 14, 2014 at 10:52 PM, Eduard Moraru enygma2...@gmail.com
  wrote:
   Hi devs,
  
   While looking into the delete space UI issue [1], we first thought
 about
   directly using the livetable macro to list the documents to be deleted
  from
   the space.
  
   Now the problem, as state by Vincent: Can/should we use the livetable
   inside templates? Is the livetable part of xwiki-platform-web or is a
   removable extension (xwiki-platform-livetable)?
  
   Currently, xwiki-platform-livetable only contains the 2 pages that
  generate
   the JSON for the livetable, but the html markup is generated by the
   #livetable macro (macros.vm) and the livetable.css and livetable.js
 files
   are all in xwiki-platform-web.
  
   The only case of it being used in templates right now is in rightsUI.vm
  [2]
   where the macro is not directly called, but the html markup is created
 by
   hand and the javascript and css is included.
  
   IMO, we should decide on a single approach for the livetable and use it
  all
   the way. What we do currently can be confusing even for us.
  
   I currently see two directions:
  
   1) Move the content of xwiki-platform-livetable in a xwiki-platform-web
  as
   templates so that the livetable is a core feature and that it also
 works
  in
   the UI when the database is empty.
  
   2) Move the livetable macro (as wiki macro?), js (as JSX) and css (as
  SSX)
   from xwiki-platform-web to xwiki-platform-livetable and see the
 livetable
   as just another extension/feature that is only present when installed.
  The
   rightsUI would need a change as well, since it can no longer rely on
 the
   livetable and probbaly we would also need to find a way to allow
  extenions
   to contribute filesystem resources.
  
   I thought it would be a good idea to open a discussion on this topic
  since
   it's currently, AFAIK, a grey area.
  
   WDYT?
  
   Thanks,
   Eduard
  
   --
   [1] http://jira.xwiki.org/browse/XWIKI-8320
   [2]
  
 
 https://github.com/xwiki/xwiki-platform/blob/master/xwiki-platform-core/xwiki-platform-flamingo/xwiki-platform-flamingo-skin/src/main/resources/flamingo/rightsUI.vm
   

Re: [xwiki-devs] [Proposal] Simplified Home Page

[Anca Luca]

Hello all,

so on the topic of removing the dashboard from the homepage and if people
need it they can access it independently.

In my opinion, this dashboard does not really exist or have any value
beyond the homepage. I mean, what does it mean, what is it used for besides
the homepage? What would the dashboard be used other than having an
overview of the wiki? And if people remove it from the homepage of the
wiki, what would they put instead? An overview of the wiki? Isn't that what
dashboard means?

By this logic, I would find it strange to have a homepage and a dashboard,
as 2 separate entities, because for me they would mean the same thing. So
multiple possibilities:
1/ our _default_ dashboard displayed on the homepage (included or not, I
don't care) is not good enough because it does not offer a good _default_
overview of the wiki. We need to change the dashboard. In this case, we
improve the way we modify this dashboard, to allow people to change the
default overview which guides the user through the wiki with an overview
that is more adapted to the user's usecase.
2/ we change the homepage and we remove the dashboard from it and implement
an overview of the wiki differently (which would still be a dashboard at
the conceptual level but implemented differently). In this case, the
Dashboard.WebHome should be removed completely from the menu, because the
dashboard _is_ the home page (see my remark above) :) . We can make the
homepage a regular page so that users can edit it very easily by default,
but we also allow them to easily make it a dashboard with gadgets and drag
 drop, so that they can organize their content. I am thinking for example
of a button on the homepage, in view mode injected with javascript or UI
extension or I don't know, which runs a script that creates a new version
of the homepage which contains a dashboard macro call and a default gadget
and the user is taken to the edit mode of the homepage, with the dashboard
editor in it.

The only reason why the dashboard is separate now, in Dashboard.WebHome, is
for legacy reasons, because it used to be included as the homepage of all
sort of default spaces, so we needed something that can be re-used for
spaces homes as well. Otherwise, from my point of view, it does not need to
be a separate entity. I mean, one should be able to create as many
dashboards as they'd want (on any page they want), but by default the
dashboard of the wiki is only one, the homepage of the wiki.

Anca

On Tue, Sep 16, 2014 at 3:23 PM, vinc...@massol.net vinc...@massol.net
wrote:

 Hi devs,

 As you know I started working on a Home Page Application, see:
 - JIRA with screenshots: http://jira.xwiki.org/browse/XWIKI-10586
 - Discussion thread: http://markmail.org/message/ghelufamwucog46x

 I have it all done locally but I refrained from committing it because on
 the email thread some expressed their doubts.

 I started thinking about it and I expressed some idea in the thread
 started by Caty about Wiki - Space - Page concepts pitch:
 http://markmail.org/message/jefze7nvprz36pkw

 I’m pasting it here again for discussion (with some edits):

 
 BTW concerning the home page, I’m more and more leaning towards removing
 the dashboard from it (it’s accessible from the App panel anyway) and
 instead have it contain:
 - explanation about how the wiki is organized (wikis, spaces, pages)
 - explanation about base concepts (editing, saving, etc)
 - encourage the user to edit this home page to make it his own and put the
 content he wishes instead

 I think this would solve the following issues:
 - users always want to customize the home page and this makes it easy
 (it’s a standard page, no dashboard). This is also a way for them to take
 ownership of the wiki as theirs.
 - explains the main concepts of wiki, space, page

 Of course, we also need to provide a navigation panel for easy navigation
 in the wiki/spaces/pages.
 “

 If we agree about the idea of removing the dashboard and instead have a
 simple page then we’ll need to discuss the exact content and for that I’m
 proposing to discuss with Caty/GuillaumeD and make a proposal for further
 discussion. Of course any idea in reply to this email would also be much
 appreciated.

 But first things first! We first need to decide if this is a good idea or
 not.

 WDYT?

 Thanks
 -Vincent
 ___
 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

Re: [xwiki-devs] Fwd: [Discussion] New location of the Add menu in the new Flamingo skin

[Anca Luca]

Hello all,

Guillaume D tallked to me about this so, as any visual issue, I have an
opinion about it too.

I think thhe button should be, at least for now, in the top menu (see under
for the explanation if you want).
Hoewver, var 3 has 2 problems for me:
1. the + button for the add in the top menu is 1/ not consistent with other
menus which have labels and 2/ can be interpreted as a more menus, like
you'd click on the + to get hidden menu items
2. If I have a 1920px screen, what reason in the world would I have to not
want to see the full search input directly? I think a full search input is
better, greyed as proposed  in 3.2

I would like something like Var 2, with Add button controlled by color
theme with the possibility to choose for it the same color as the menu, to
melt it in the menu (so that it would be less visibile). And a grayed
search box, or responsive so that if the screen is small, it's reduced to
an icon (like in Var 3).

Now, on the placement of the button:  I think it's hard to understand how
can Add Space or Add Wiki be next to editing the current page.
Indeed, you can consider that, since the created page is a child page of
the current page, it makes sense to Add a page in the context of the
current page BUT, until rights are inherited on the parent-child relation,
this is a very dangerous logic to highlight to users. Also, you can choose
the space of the new page upon creation, thus creating it  elsewhere but
the current context, so it can be considered as a non-context related
action.

Sorry I didn't feedback earlier about this, it seems it's indeed easier
when you see it (or show it to other people). Also it was probably always
surrounded a bit by the whole confusion created for me by the placement of
the edit buttons to the right (I am used to going to the left so it's
always puzzling for me; I'll just get used to it, this is a change I like).

Thanks,
Anca


On Fri, Oct 3, 2014 at 6:53 PM, vinc...@massol.net vinc...@massol.net
wrote:






 On 3 Oct 2014 at 18:40:50, Jeremie BOUSQUET (jeremie.bousq...@gmail.com
 (mailto:jeremie.bousq...@gmail.com)) wrote:

  2014-10-03 15:57 GMT+02:00 Ecaterina Moraru (Valica) :
 
   On Fri, Oct 3, 2014 at 4:50 PM, vinc...@massol.net
   wrote:
  
   
   
   
   
   
On 3 Oct 2014 at 15:33:53, Ecaterina Moraru (Valica) (
 vali...@gmail.com
(mailto:vali...@gmail.com)) wrote:
   
 On Fri, Oct 3, 2014 at 3:28 PM, vinc...@massol.net
 wrote:

 
 
 
 
 
  On 3 Oct 2014 at 13:05:08, Ecaterina Moraru (Valica) (
vali...@gmail.com
  (mailto:vali...@gmail.com)) wrote:
 
   Hi,
  
   Some notes about the proposal:
  
   - I like the 'Add' represented as '+' and after the
 Wiki/Space/Page
   breadcrumb, because is somehow consistent with the '+' (More
  applications)
   from the AppBar. Provides a way to create elements of a
 particular
type
  in
   the near vicinity where the elements are displayed.
 
  What I don’t like is that it’s the only menu entry at the top
 that
  wouldn’t have any text (just an icon) and it’s one of the most
important
  one.
 

 As I said in the proposal Well known actions are represented with
   icons,
 while we provide text only for user generated entities
 (Wiki/Space/Page/User names)”.
   
But I don’t see this anywhere in the current UI: we have “Edit”,
 “Add”,
“More Actions..” which are all well known actions...
   
Is that a new rule you’d like to have?
   
If it is, it makes more sense to me to move all to this new rule at
 once
instead of doing an exception just for the Add button, don’t you
 think
   so?
   
  
   So yes, is not something existing, it was more of a premise I based my
   design when I did iterations (in order to assure consistency).
   For example, one of the iterations looks like this
  
  
 http://design.xwiki.org/xwiki/bin/download/Proposal/FlamingoAddMenuLocationIterations/11.2M.png
   (where even Edit and More actions are replaced with only icons) ... but
   again these are design ideas, iterations and proposals.
  
 
  I really like this one, as it's consistent with your premise and not
 half
  consistent”.

 Yes I also like it because it makes the UI a bit less cluttered. What I
 don’t like is “half consistent”, i.e. just the “+” without the rest using
 long names.

 Now I’m not sure if at this stage we’re prepared to make such a larger
 jump/change for 6.2.2. This is why I was proposing to move the Add feature
 at the top while keeping the “Add” text for now and do what Caty proposes
 as the next step. OTOH if everyone agrees with this change right now, I’m
 fine with going ahead with it right now too...

 Thanks
 -Vincent

  I understand Vincent's point, but my issue is that the + in top menu
  doesn't look like an icon, it looks like a '+' character, and could use
  same font as the other text on left side (except that it's a bit
 thicker).
  

[xwiki-devs] [Contrib] Creation of Jira Project for the Publication Workflow application

[Anca Luca]

Hello XWiki devs,

A while ago I started the publication workflow application (
https://github.com/xwiki-contrib/workflow-publication/ ), but didn't set it
up with a Jira Project at that point.

Could someone please create the Jira issue for this project, please?

Thanks a lot,
Anca
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [Contrib] Create a repository for the Hierarchy Macro

[Anca Luca]

Hello Devs,

As far as I know it's not a refactoring of the old macro because some
parameters / parameters behaviour was not kept 100%. It's missing some
features, basically. Adding some with the cost of removing others.

So if we consider it a new version of the old one, installing an upgrade
will break the behaviour. You'd tell me we could wait to release the new
version it only when ready, but then people could not take advantage of its
features (which are cool).

We could have it as a new extension until we implement all the features of
the old one, and then we mark it as implementing the same feature so that
the old one could be upgraded to the new one.

Anca


On Wed, May 21, 2014 at 7:11 PM, vinc...@massol.net vinc...@massol.netwrote:





 On 21 May 2014 at 18:08:33, Lyes Bandou (lyes.ban...@xwiki.com(mailto:
 lyes.ban...@xwiki.com)) wrote:

  Code of the two macros is not the same,

 This doesn’t matter much if the new code is considered a refactoring of
 the old code.

  The new macro has the same name and
  keeps most paramettres, but the behavior is not the same it uses Ajax to
  load the data (using JSON) and the older macro display the documents
  hierarchy in a space , the new macro can uses documents list as documents
  roots of the tree (plus another paramettres)
 
 
  I suggest Dynamic Tree Macro as the new name.

 The real question is: do we need the 2 macros at once?

 I guess we need to ask the question to the author of the first macro:
 Anca, Paul, Mircea.

 Because from a user point of view, it’s a nightmare to have several
 extensions doing the same thing, the user never knows which one to use.

 Anca/Paul/Mircea, do you have an opinion?

 Thanks
 -Vincent

  On Wed, May 21, 2014 at 4:40 PM, Thomas Mortagne
  wrote:
 
   Same question, why is a new repository needed exactly ? If it's THE
   new version then it's the same extension and it should be the same
   repository, even if you rewrite half of it in a 2.0 version.
  
   On Wed, May 21, 2014 at 5:37 PM, vinc...@massol.net
   wrote:
Do you really need a new extension? Couldn’t you improve the existing
   one then?
   
Thanks
-Vincent
   
On 21 May 2014 at 17:35:52, Lyes Bandou (lyes.ban...@xwiki.com
 (mailto:
   lyes.ban...@xwiki.com)) wrote:
   
This is the new version of Hierarchy Macro (
http://extensions.xwiki.org/xwiki/bin/view/Extension/HierarchyMacro
 )
   with
the addition of to many parameters
   
   
On Wed, May 21, 2014 at 4:26 PM, Thomas Mortagne
wrote:
   
 Are you talking about

 http://extensions.xwiki.org/xwiki/bin/view/Extension/HierarchyMacro ?

 If not you might want to find another name since this one already
 have
 https://github.com/xwiki-contrib/macro-hierarchy.

 On Wed, May 21, 2014 at 5:23 PM, Lyes Bandou
 wrote:
  Hello devs,
 
  I would like a repository for the Hierarchy Macro on
  https://github.com/xwiki-contrib.
 
  Hierarchy Macro use jQuery and jsTree (http://www.jstree.com)
 to
   display
  dynamique tree view of wiki documents based on parent/child
   relationships
 
  Thank you in advance.
 
 
  Lyes Bandou
   
___
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
  
  ___
  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

Re: [xwiki-devs] [Proposal] Solution to make it easy to debug JS in XWiki

[Anca Luca]

On 05/14/2013 08:57 AM, Guillaume Louis-Marie Delhumeau wrote:

Hi devs,

Can't we rewrite all JSFX URLs with a suffix when $request.minify is set to
false?

I mean, when the developer do
$xwiki.jsfx.use('uicomponents/widgets/upload.js'), the JSFX module actually
add 'uicomponents/widgets/upload_full.js' to the webpage, if the file
exists?

There will be no cache problem, and it is easy to implement.


it could work, yes, I thought about the jsfx/jsx modifying the URL but 
what I don't like that much about this solution is the fact that the 
sent file will not correspond anymore to the file demanded by the 
developer that did the include. This can be troubling, and could also 
have some dirty side-effects, because it's automatic and magic.
Also, we still would need a solution for jsx, knowing that in the case 
of the jsx there is no file. We could invent a new action, jsxdebug, for 
example. This could also work for jsfx/jsrx maybe...


Anca



Louis-Marie

2013/5/13 Anca Luca lu...@xwiki.com


On 05/04/2013 09:28 AM, Vincent Massol wrote:


On May 3, 2013, at 3:41 PM, Denis Gervalle d...@softec.lu wrote:

  On Thu, May 2, 2013 at 2:53 PM, Vincent Massol vinc...@massol.net

wrote:

  Hi devs,

ATM the solution is described here:
http://dev.xwiki.org/xwiki/**bin/view/Community/Debugging#**
HDebuggingJavaScripthttp://dev.xwiki.org/xwiki/bin/view/Community/Debugging#HDebuggingJavaScript

What would you think about doing this instead:
* Package both the minimized and the non minimized version in our WAR
(it
shouldn't add too much weight to our overall WAR size)
* Have a directory structure like this:

resources/.../module/
   |_ non minified js file here
   |_ min/minified js files here

* This would allow to put in our xwikivars.vm something like (pseudo
code):

#if ($!request.minify == 'false')
   #set ($jsDir = '/')
#else
   #set ($jsDir = 'min/'
#end

* Then everywhere we reference JS files we use $jsDir. For example in
attachmentsinline.vm:

$xwiki.jsfx.use('uicomponents/**widgets/${jsDir}upload.js',
{'forceSkinAction': true, 'language': ${xcontext.language}})


This assumes that everywhere we reference js files is always in velocity,
which is not true. I can think of at least one place, the dashboard macro (
https://github.com/xwiki/**xwiki-platform/blob/**
e7c3855397bee00a5f1fe8b6fe9da6**08d4c4bb7f/xwiki-platform-**
core/xwiki-platform-dashboard/**xwiki-platform-dashboard-**
macro/src/main/java/org/xwiki/**rendering/internal/macro/**
dashboard/DashboardMacro.java#**L232https://github.com/xwiki/xwiki-platform/blob/e7c3855397bee00a5f1fe8b6fe9da608d4c4bb7f/xwiki-platform-core/xwiki-platform-dashboard/xwiki-platform-dashboard-macro/src/main/java/org/xwiki/rendering/internal/macro/dashboard/DashboardMacro.java#L232).
 Now, I admit that one might not be the cleanest code ever, but I wonder
what would stop anybody from wanting to include a resource from java or,
say, groovy?


  …

This would allow to remove the debug profile and make it much faster
to
debug XWiki issues, even in production systems.

WDYT?

  Looks great, would be even better if the same option were passed

automatically for JSX as well, which would ensure that all JS are not
minified.


This is already the case and that's why I chose the minify request
parameter name :)

See the following in AbstractSxAction.java:

  if (BooleanUtils.toBoolean(**StringUtils.defaultIfEmpty(
  request.get(COMPRESS_SCRIPT_**REQUEST_PARAMETER), true)))
{
  extensionContent = sxType.getCompressor().**
compress(extensionContent);
  }


indeed, but this uses the parameters of the URL to the js (the jsx action
URL). not the params of the page that demands the js. Which means that if
you want to debug a page, you'd have to figure out all the scripts that the
page is using, and make sure you add, one way or another, the minify=false
parameter.

Also, it works if you load the jsx onDemand (when you'd be able to, say,
request the jsx and add the {minify: false} parameter), but it won't work
for the automatically loaded jsx like always on this wiki or always on
this page. Also, adding this minify parameter to the call could be a pain,
because you might not know which is the script that is loading the jsx, you
have to go look for it, etc.

In the light of these 2 (3) things, it could maybe be nicer with some sort
of a preference or so, although serving 2 different js for the same URL is
not friendly with the browser cache. I need to think a bit more thorough to
come up with an idea about how to make it better from this point of view.

Anca




Thanks
-Vincent

__**_
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/**mailman/listinfo/devshttp://lists.xwiki.org/mailman/listinfo/devs


__**_
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/**mailman/listinfo/devshttp://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [Proposal] Solution to make it easy to debug JS in XWiki

[Anca Luca]

On 05/04/2013 09:28 AM, Vincent Massol wrote:

On May 3, 2013, at 3:41 PM, Denis Gervalle d...@softec.lu wrote:


On Thu, May 2, 2013 at 2:53 PM, Vincent Massol vinc...@massol.net wrote:


Hi devs,

ATM the solution is described here:
http://dev.xwiki.org/xwiki/bin/view/Community/Debugging#HDebuggingJavaScript

What would you think about doing this instead:
* Package both the minimized and the non minimized version in our WAR (it
shouldn't add too much weight to our overall WAR size)
* Have a directory structure like this:

resources/.../module/
  |_ non minified js file here
  |_ min/minified js files here

* This would allow to put in our xwikivars.vm something like (pseudo code):

#if ($!request.minify == 'false')
  #set ($jsDir = '/')
#else
  #set ($jsDir = 'min/'
#end

* Then everywhere we reference JS files we use $jsDir. For example in
attachmentsinline.vm:

$xwiki.jsfx.use('uicomponents/widgets/${jsDir}upload.js',
{'forceSkinAction': true, 'language': ${xcontext.language}})


This assumes that everywhere we reference js files is always in 
velocity, which is not true. I can think of at least one place, the 
dashboard macro ( 
https://github.com/xwiki/xwiki-platform/blob/e7c3855397bee00a5f1fe8b6fe9da608d4c4bb7f/xwiki-platform-core/xwiki-platform-dashboard/xwiki-platform-dashboard-macro/src/main/java/org/xwiki/rendering/internal/macro/dashboard/DashboardMacro.java#L232 
). Now, I admit that one might not be the cleanest code ever, but I 
wonder what would stop anybody from wanting to include a resource from 
java or, say, groovy?



…

This would allow to remove the debug profile and make it much faster to
debug XWiki issues, even in production systems.

WDYT?


Looks great, would be even better if the same option were passed
automatically for JSX as well, which would ensure that all JS are not
minified.

This is already the case and that's why I chose the minify request parameter 
name :)

See the following in AbstractSxAction.java:

 if (BooleanUtils.toBoolean(StringUtils.defaultIfEmpty(
 request.get(COMPRESS_SCRIPT_REQUEST_PARAMETER), true))) {
 extensionContent = 
sxType.getCompressor().compress(extensionContent);
 }


indeed, but this uses the parameters of the URL to the js (the jsx 
action URL). not the params of the page that demands the js. Which means 
that if you want to debug a page, you'd have to figure out all the 
scripts that the page is using, and make sure you add, one way or 
another, the minify=false parameter.


Also, it works if you load the jsx onDemand (when you'd be able to, say, 
request the jsx and add the {minify: false} parameter), but it won't 
work for the automatically loaded jsx like always on this wiki or 
always on this page. Also, adding this minify parameter to the call 
could be a pain, because you might not know which is the script that is 
loading the jsx, you have to go look for it, etc.


In the light of these 2 (3) things, it could maybe be nicer with some 
sort of a preference or so, although serving 2 different js for the same 
URL is not friendly with the browser cache. I need to think a bit more 
thorough to come up with an idea about how to make it better from this 
point of view.


Anca



Thanks
-Vincent

___
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

Re: [xwiki-devs] [Discussion] Why drop the $msg script binding in the future?

[Anca Luca]

Hi all,

a bit late to the party, I just found out today that $msg.get is now 
deprecated.


On 03/15/2013 01:45 PM, Vincent Massol wrote:

Hi,

On Mar 15, 2013, at 1:21 PM, Eduard Moraruenygma2...@gmail.com  wrote:


Are we sure we want to drop the $msg binding in the future [1]?

IMO yes, for consistency, but it's a good question to ask. It's not just about $msg but 
about all bindings. If we allow shortcut aliases for bindings we need to make 
this general and allow any services binding to offer shortcuts.


Well... it's complicated. We would also remove $xwiki in the future? 
maybe $xcontext as well? it will all be prefixed with $services?


I think that while it's a good idea for code beauty reasons, it's highly 
impractical. Script authors are already used with $msg.get(), the new 
$services.localization.render() does at least the same thing as $msg.get 
(or doesn't it?), it's longer to write **and to read** (services 
itself is longer than msg.get so no matter what you put after, it's 
already longer) , and it will generate tons and tons and tons and tons 
and tons (I cannot emphasize this enough) of logs saying that script X 
is using a deprecated function, until you change all your scripts and 
all the extensions on extensions.xwiki.org so that when you install 
something your logs are still readable (or maybe we can disable these logs?)




One reason we introduced $services was to keep the xcontext namespace free for 
applications to use.


Compared to other services, $services.localization would be used heavily

I had personally proposed l10n to make it a bit shorter but it wasn't 
accepted. My proposal was: $services.l10n


inside scripts and we would basically have 2 options:
1. use $services.localization.render('key') (you fall asleep writing this
every time)
2. always declare a variable in your script like #set ($keys =
$services.localization) and then do $keys.render('key')

3. Use the translation macro if you're in wiki pages: {{translation key=…/}}


This is, imho, a little quarter of a solution. In practice, html macro 
with wiki=false is used far more than we'd like.
Now, sure, we can choose to ignore that, but that would be another 
discussion.


Also, the problem of all 3 solutions above is that they require 
refactoring of a lot of code (I for one use a lot the localization tool, 
not only for localization, but also to make it easy for people that 
don't know code to decide what the interface of the application should say).





AFAIK, we have already considered in the past that a similarly used service
like $services.model is already becoming a bit annoying having to write the
oh-so-very-long $services.model.createDocumentReference(wiki,
space,name); do we want to get the same effect with the new localization
module?

@Edy, we really need to commit the auto completion feature ;)


I understand and agree that the new localization module is more powerful
and flexible than the XWikiMessageTool, but I feel that those new features
are not required in day to day use and unnecessarily crowd/pollute the
regularly used API.

You're loosing me here. I thought you were only talking about the binding name 
and here you start to say that you want to go back to XWikiMessageTool?


This transition should IMO be smoother

Smoother than what?


I think what Edi means, and I agree with him, is that he doesn't really 
understand why can't we just have the old $msg.get function call the new 
localization service and be done with it?





and with less impact than what is
currently being proposed. If the new localization module can provide all
the features of the XWikiMessageTool, then I propose that we simply reuse
the $msg binding as it is and, in the background, transform
XWikiMessageTool into a facade (as I see we have already pretty much done
to preserve backwards compatibility), but agree that we *keep* $msg as the
simplified translations binding, to be used in day to day operations and,
for more complex tasks, the dev needs to use $services.localization instead.

I don't understand what you mean. If your idea is to get $msg.get() rather than 
$msg.render() which is the new API then I don't agree. If what you propose is just to 
have a generic script service alias notion where $msg would be the same as 
$services.localization then I'm more inclined to think about it :)


See above.



BTW I would not want to reuse the same name ($msg) because it's misleading.


Why would that be misleading? Isn't the new localization service an 
improvement of the old one? It's a new tool?
Since I contribute less and less, I am now more a user of the xwiki 
platform than a developer of it, and honestly, as a user, I perceive the 
work that was done on localization as an improvement of what was there 
before and I don't like the idea that for an improvement of the platform 
I use I need to rewrite all my code, and use a new, longer, function 
call, and learn new function names et all: as a script author, I'm 

[xwiki-devs] [contrib] New repository on xwiki-contrib for a publication workflow application

[Anca Luca]

Hi all,

I did some sort of an implementation of a publication workflow 
application,  which allows to take a document through various states and 
finally publish it in a mirror space once it is validated, and 
subsequent versions of the same document are handled, with distinct 
rights and comments between the draft version and published version.


For now, this application is here 
https://github.com/lucaa/workflow-publication and I would like to 
publish it in xwiki-contrib, in a repository called the same, 
workflow-publication, in order to release it on xwiki maven.


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

Re: [xwiki-devs] [contrib] New repository on xwiki-contrib for a publication workflow application

[Anca Luca]

Hi all,

I created the repository at 
https://github.com/xwiki-contrib/workflow-publication and transfered the 
ownership of my repo to xwiki-contrib.
I also released an 1.0-rc-1 version, if somebody would be nice enough to 
promote that release for me?


Thanks a lot,
Anca

On 02/21/2013 02:53 PM, Anca Luca wrote:

Hi all,

I did some sort of an implementation of a publication workflow 
application,  which allows to take a document through various states 
and finally publish it in a mirror space once it is validated, and 
subsequent versions of the same document are handled, with distinct 
rights and comments between the draft version and published version.


For now, this application is here 
https://github.com/lucaa/workflow-publication and I would like to 
publish it in xwiki-contrib, in a repository called the same, 
workflow-publication, in order to release it on xwiki maven.


Thanks,
Anca


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

Re: [xwiki-devs] Trouble Accessing Database List Elements

[Anca Luca]

Hi Robert,

yes, it's possible, but you need to develop a bit yourself.

You have 2 choices:
1/ you modify the sheet and, for this specific property, you display a 
link instead of the value
2/ you make a custom displayer for your property in the class (as 
described here 
http://extensions.xwiki.org/xwiki/bin/view/Extension/User+Property+Custom+Display 
) and you display, in the case of the view, a link instead of the value. 
This would be the nicer choice.


Note that, as far as I know, both of these mean going out of the app 
within minutes framework so you need to do some tests and check what 
happens when you re-generate your application on modifications of the 
class, for example, with app within minutes, if your changes are 
overwritten or not.


Happy xwikiing,
Anca

On 02/11/2013 04:35 PM, Robert Southwell wrote:

Hi All,

I am creating a new Class using the 'AppWithinMinutes' dialogue that will hold 
information on projects.
Within which I am trying to add a Database List.
This list is supposed to enable users that are creating a new 'Project' page to 
link the page with one or more 'Clients' (each 'Client' has its own page within 
a 'Clients' space).

I can get a list of all the clients from which the user can select from using 
the following HQL:

select doc.name, doc.name from XWikiDocument as doc where
doc.space = 'Clients' and
doc.name  'WebHome' and
doc.name  'ClientsClass' and
doc.name  'ClientsTemplate' and
doc.name  'ClientsSheet' and
doc.name  'WebPreferences'
order by doc.name

however the returned list is just text, and i would like it if they were 
'links' to the actual Client Page.
Is this even possible? as i've been search for hours!

Thanks in advance.

Rob Southwell
Professional Services
Helyx SIS Ltd

M: 07762 767575
T:  01684 273725
F:  01684 853430
E:  r.southw...@helyx.co.ukmailto:r.southw...@helyx.co.uk
W: www.helyx.co.ukhttp://www.helyx.co.uk/
Registered in England No:  04464638.  Registered Office:  Millennium House, 65 
Walton Street, Aylesbury, Buckinghamshire, UK, HP21 7QG
DISCLAIMER AND CONFIDENTIALITY NOTICE
The content of this email (and any attachments to it) is confidential and may 
contain privileged information. It is intended solely for the use of the 
individual(s) or entity to which it is addressed. If you are not an intended 
recipient, please notify the sender immediately and do not disclose the 
contents to another person, use it for any purpose, or store or copy the 
information on any medium.
The views expressed in this e-mail are those of the individual and not 
necessarily the views or opinions of Helyx SIS Ltd. Please note that the author 
of this e-mail is not authorised to conclude any contract on behalf of Helyx 
SIS Ltd by e-mail.

___
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

Re: [xwiki-devs] OpenFire xwiki integration?

[Anca Luca]

On 02/08/2013 11:02 AM, Guillaume Lerouge wrote:

Hi Paul,

I remember that back in the summer of 2010 some XWiki developers looked at
integrating a XMPP server with XWiki. If I remember correctly, a LDAP
server was used for user management and both the XMPP server and the wiki
were plugged into it.


We were using an external OpenFire, which used an LDAP auth, the same 
that XWiki was using. Thus, there were the same users, but not the wiki 
users but the LDAP ones. Because of that, at least during the hackathon, 
we didn't manage to automatically log in people to the chat when they 
were logged in in the wiki, even if they were, actually, the same users 
(the user had to retype pass).


There was a small chat box popping up in wiki pages as well as a list of
connected users from which one could initiate conversations. It was very
experimental, worked fine for about 15 users but I have no idea about
scaling.


I forgot the name of the js lib we used for UI, there was a little js 
API for communicating with an XMPP, one I had seen at a fosdem a few 
years ago. I can dig for that code to check it out if you want.


Happy XWiki-ing,
Anca



Thanks,

Guillaume

On Thu, Feb 7, 2013 at 10:43 PM, Paul Libbrechtp...@hoplahup.net  wrote:


Hello fellow XWiki developers,

I was wondering if anyone had taken the time to have a joint install of
XWiki and OpenFire, apparently a fairly scalable XMPP server with nice
feature completeness.
Something should be done at the UI level, such as candy-chat probably.
My question is more about the server side, there seems to be a way to
write an adapter to fetch user-information from a database, so that
exposing users of XWiki might be simple.

Did anyone try this already?
Did it scale?

thanks in advance

paul


___
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

Re: [xwiki-devs] [Brainstorming] XWiki Flavors

[Anca Luca]

On 02/08/2013 02:32 PM, Vincent Massol wrote:

On Feb 8, 2013, at 1:39 PM, Eduard Moraruenygma2...@gmail.com  wrote:


On Thu, Feb 7, 2013 at 6:47 PM, Vincent Massolvinc...@massol.net  wrote:


On Feb 7, 2013, at 5:38 PM, Eduard Moraruenygma2...@gmail.com  wrote:


On Thu, Feb 7, 2013 at 6:31 PM, Vincent Massolvinc...@massol.net

wrote:

Hi Caty,

On Feb 7, 2013, at 5:08 PM, Ecaterina Moraru (Valica)

vali...@gmail.com

wrote:


Hi,

XWiki Flavors are a set of predefined extensions having a specific use
case in mind. XWiki Flavors can be considered specializations of XWiki
instances suited for different purposes like public websites,
intranets, content sharing, project management, community status,
business intelligence, etc.

Scenario: You want to install XWiki. The installer will propose
different 'flavors' and will install automatically all required
extensions. This way you will have a product close to your initial
needs. You can later refine it by installing / uninstalling other
extensions.

So when I first thought about the process of installing a Flavor I
imagined that I could customize what I wanted from the Flavor and
select just the things I need. Actually for me Flavors were like
categories with subcategories, and more of a classification system,
than a packaging one.



http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Flavours/customizedInstall.png

Also another difference in my vision is that I had a Base Package that
contains the common denominator for all Flavors. The Base Package
should contain basic mechanics for managing content and users.
Selecting no flavor will still result in having basic wiki features
(page creation, attachments, history, users, etc.).

After some discussions with Eduard I understood that Flavors could be
defined as extensions and they could contain just a list of
dependencies on other extensions. The Extension Manager will install
the 'exact' list it gets from the definition without the ability to
exclude some dependencies.

Indeed.


I've watched the 'recent' mails about XWiki Flavors [1] [2] [3] [4]
and for me the conclusion is clear: we will never agree on what
starting features are the best and that will solve everybody's
problems. But that is ok and normal and the strength of XWiki is it's
extensibility.

So the next idea was to have a Flavor Creator that will allow users to
create their own collections of extensions. This collection should be
then published to extensions.xwiki.org and could appear in the
installer list as suggestions.

Some thoughts:

* Yes, the idea is that anyone can contribute a flavor on xwiki.org,
since it's an extension like any other (it would just have a new type,
called flavor since we don't have this ATM). The DW will list all

flavors

it can find from e.x.o. This is where we need some ways to bring the

best

flavors to the top. My idea was to add ratings to the Repository app for
that


I agree with this. IMO, we should bring back the idea of extension types
(including this new flavour type) and, as you`ve mentioned, add things
like ratings.

Not sure we're talking about the same thing. There are already extension
types (they correspond to the mavenpackaging  element). Currently AFAIK
the EM has implementations for XAR and JAR. We need to add either support
for POM or create a new Maven packaging but that's probably unnecessary,
supporting POM is enough.


What I meant was the ability to specify for each extension that it is an
application, a macro, a skin, a flavour, etc.

I think type and category are 2 separate things.

For category I was thinking about just using the existing tag feature and 
making that visible in the EM UI.


Hm, but we have that, no? a beautiful tagcloud on top of the extensions 
livetable on the main page.


The only issue is that tags UI is  by default on the bottom of the page, 
and for extension authors it's not really straightforward to go there 
and fill in the tags. Maybe if we put a warning in edit mode or 
something, to tell people to not forget to add tags so that the tags are 
easier to discover.


Anca



WDYT?

Thanks
-Vincent


Thanks,
Eduard



Also, this should be reflected in the EM UI to allow a user to do

browsing

(by extension types) and not only searching (which is a bit intimidating

to

new users).

Yup.

Thanks
-Vincent


Thanks,
Eduard



* Also, in the DW the user should be allowed to not install any flavor

so

that he can then install extensions one by one if he so wishes

* Re the base package there's no need to have one since extensions

declare

their require dependencies


http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Flavours/flavorCreator.png

If Application Within Minutes let's you create your own applications,
the Flavor Creator would let you make packages of extensions for a
specific purpose. This way we strengthen XWiki's extensibility and we
let the users take the power and customize the solutions that are
perfect for them.

Sounds good.

Re: [xwiki-devs] [Discussion] Should technical pages hide the bottom tabs?

[Anca Luca]

On 01/23/2013 07:20 AM, Sergiu Dumitriu wrote:

On 01/20/2013 02:48 PM, Vincent Massol wrote:

On Jan 20, 2013, at 6:54 PM, Sergiu Dumitriuser...@xwiki.com  wrote:


On 01/20/2013 11:31 AM, Vincent Massol wrote:

On Jan 20, 2013, at 5:22 PM, Sergiu Dumitriuser...@xwiki.org  wrote:


Hi devs,

For content pages, the bottom tabs (comments, attachments, history,
information) are very useful features. But does it make sense to keep
those active for very technical pages?

For example, when viewing details about a tag, (Main/Tags?do=viewTag),
why should people be allowed to comment? They might wrongly think that
they're commenting on a tag, but that's just one complex page that
handles almost everything about tags, so a comment like this tag has a
typo doesn't help at all.

Other pages should have no bottom tabs as well: user directory, blog
category management, the whole scheduler space, share by email...

While the homepage is a technical page (by default), it does make sense
to leave the comments active, since it's the entry point for every user
(although I think that the messaging system is a better way to send
global messages).


IMO, the advantage is that we're hiding actions that are rarely useful,
but could be misused. The disadvantage is that we're breaking the
universality of the UI.

I'm +1 for hiding, fewer mis-usable features is always better.

What if admins want to leave comments on a tech page modified by another admin 
to ask some question for example?

Sending a message to another admin should be done by... sending a
message, not by commenting. A direct message will reach a user faster
than hoping that the target user will stumble upon the page and read the
comment.

If you're saying that comments are useless then we should remove comments… :)


Said differently, shouldn't bottom tabs (comments, attachments, etc) be visible 
to admins for example? This could be achieved by only giving view rights to non 
admins by default on tech pages.

Tech pages aren't supposed to be viewed only by admins. They're useful
pages for every user, so they should be visible (view tag cloud, view
documents tagged with a specific tag, view the list of users, browse
blog categories...). And not having view right doesn't mean that the
bottom tabs will be hidden. Just the add comment, add attachment
actions will be unavailable.

ok my bad, I meant edit/comment rights, not view rights.


And even if adding is disabled, but why should this information be
visible to any user at all? Forbidding edit still means that a user
wanting to see which pages are tagged with needsreview will see a Hey
John, could we have an undo to tag renaming? comment. What would you
think if you saw that?

Again if your point is that comments are useless then we should remove 
comments. I think there's a place for comments but it seems your discussion is 
actually asking us to define more precisely what is the use case/need for 
comments.

Also I think there's a difference between a Tag Dashboard page which is a 
technical page but for end users and a technical page not for end users (i.e. 
hidden page). Both will need different solutions I think. So this proposal 
should address both needs.


Another use case: imagine I'm an admin and I want to modify a tech page and I'd 
like to add an attachment to that page… IMO bottom tabs are still useful for 
admins on tech pages.

This isn't about disabling attachments and comments. The bottom tabs are
almost an _invitation_ to do stuff. Without them, it is still possible
to go to the attachments page by clicking on the Attachments (0) link
below the title. De-contextualizing these actions will reduce the risk
of associating a comment/attachment with a particular view of the
scripted page.

If the bottom tabs are removed then those links will also need to be removed 
obviously since otherwise a user can click on them...


IMO the issue is different. If a tech is not supposed to be modified by the 
user then users should have only view rights on the page and NOT edit rights. 
This will solve this issue.

It's not just about changing, but also about what's visible on the
screen, and the usefulness of such information vs. the number of WTFs
generated.

I don't see any WTF. For me any page that is a end user visible page can have comments 
without any WTF. For example on the tag dashboard page, someone may comment and say 
how do I get the tag dashboard to display xxx? or anything else in just the 
same way it's done on any other page.

In addition I'm actually finding the removal of the bottom tab a huge WTF. As a user 
I know what a page is, and if I see those tabs are not present on some pages, I'll 
think what WTF? Why is there not tabs there….


Forget about admins, they will still be able to add comments
and attachments. Think about simple users searching for stuff and seeing
a comment completely unrelated to what they're searching for.

I forgot to say that this has already been done in a few 

Re: [xwiki-devs] [Contrib] Repository request: multipagepdfexport-application-spaceexport

[Anca Luca]

On 12/28/2012 03:52 PM, Anca Luca wrote:

Hi all,

I am about to contribute an application I made to provide an UI for 
multipage pdf export ( 
http://extensions.xwiki.org/xwiki/bin/view/Extension/Multipage+PDF+Export 
) to help export pages in a space, displayed in a hierarchy like UI 
(using the hierarchy macro), and, after long reflection, I decided to 
put this application in its own repository (another option would have 
been to put it in the multipagepdfexport repository already existing). 
The choice is motivated mainly by the need to version it independently.


Repository name: multipagepdfexport-application-spaceexport
User name: lucaa


I created this repository for myself at 
https://github.com/xwiki-contrib/multipagepdfexport-application-spaceexport 
.


Anca Luca



Thanks a lot,
Anca Luca


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

[xwiki-devs] [Contrib] Repository request: multipagepdfexport-application-spaceexport

[Anca Luca]

Hi all,

I am about to contribute an application I made to provide an UI for 
multipage pdf export ( 
http://extensions.xwiki.org/xwiki/bin/view/Extension/Multipage+PDF+Export ) 
to help export pages in a space, displayed in a hierarchy like UI (using 
the hierarchy macro), and, after long reflection, I decided to put this 
application in its own repository (another option would have been to put 
it in the multipagepdfexport repository already existing). The choice is 
motivated mainly by the need to version it independently.


Repository name: multipagepdfexport-application-spaceexport
User name: lucaa

Thanks a lot,
Anca Luca
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [VOTE] Dynamically registered wiki translations

[Anca Luca]

Hi Thomas,

On 10/25/2012 04:07 PM, Thomas Mortagne wrote:

Hi devs,

Following the discussion about general architecture of the new
localization module


Still haven't read it, I marked it as important.


here is a more detailed proposal for the
dynamically registered wiki translations pages.

Here is how I propose to indicate that a document contains key=value
pair translations:
* put an object of class XWiki.TranslationDocumentClass
* set the visibility field to Global, Current wiki, Current user

As for the content of the document it will stay the same as in
preferences based documents for now.


This is to preserve backwards compat, right?
Because I think it's important to be able to write an application which 
can be installed in versions  4.3 and not have to have 2 translation 
documents.




I have other fields in mind for later (on demand, translation message
syntax, etc.) but this is a 4.3 proposal here.


We should keep in mind backwards compat for these too.

Otherwise sounds correct to me, +1.

Thanks,
Anca



WDYT ?

Here is my +1.


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

Re: [xwiki-devs] [VOTE] Dynamically registered wiki translations

[Anca Luca]

On 10/26/2012 03:06 PM, Thomas Mortagne wrote:

On Fri, Oct 26, 2012 at 2:48 PM, Anca Luca lu...@xwiki.com wrote:

Hi Thomas,


On 10/25/2012 04:07 PM, Thomas Mortagne wrote:

Hi devs,

Following the discussion about general architecture of the new
localization module


Still haven't read it, I marked it as important.



here is a more detailed proposal for the
dynamically registered wiki translations pages.

Here is how I propose to indicate that a document contains key=value
pair translations:
* put an object of class XWiki.TranslationDocumentClass
* set the visibility field to Global, Current wiki, Current user

As for the content of the document it will stay the same as in
preferences based documents for now.


This is to preserve backwards compat, right?

Not really, just don't have the time to design and vote a new syntax
so for the first version only the current syntax will be supported.


Because I think it's important to be able to write an application which can
be installed in versions  4.3 and not have to have 2 translation documents.

The idea if that you would have a field (or you would directly use the
document field I'm not sure yet) where you would indicate the syntax
of the translation message and it would default on the current one
when nothing is set. So there will be no backward compatibility issue.


Yes, I understand, if it doesn't impact the format of the document 
itself, it should be fine.


Thanks,
Anca






I have other fields in mind for later (on demand, translation message
syntax, etc.) but this is a 4.3 proposal here.


We should keep in mind backwards compat for these too.

Otherwise sounds correct to me, +1.

Thanks,
Anca



WDYT ?

Here is my +1.


___
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

Re: [xwiki-devs] [VOTE] Modification to groupid for contrib projects

[Anca Luca]

+1

sounds decent to me.

Anca


On 08/13/2012 04:34 PM, Vincent Massol wrote:

hi devs,

I'd like to propose a small improvement for contrib project group ids. ATM our 
rule is:

A generic maven groupId : org.xwiki.contrib (until the project reaches a certain 
size and visibility, in which case it can have its own maven group id)
( see http://contrib.xwiki.org/xwiki/bin/view/Main/WebHome)

I'd like to change that to:
A generic maven groupId : org.xwiki.contrib.module name (until the project 
reaches a certain size and visibility, in which case it can have its own maven group id)

So for example if I have a Mail Archive Application I'd use the groupid:
org.xwiki.contrib.mailarchive

Here's my +1 for the change

Thanks
-Vincent

___
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

[xwiki-devs] [Contrib] Open 3 contrib projects - batch import, hierarchy macro and pdf multipage export

[Anca Luca]

Hi xwiki devs,

I would like to move 3 projects from xwiki-contrib/sandbox to individual 
repos in xwiki-contrib:

https://github.com/xwiki-contrib/sandbox/tree/master/xwiki-batchimport
https://github.com/xwiki-contrib/sandbox/tree/master/xwiki-multipagepdfexport
https://github.com/xwiki-contrib/sandbox/tree/master/xwiki-hierarchymacro

Could someone create these 3 repositories for me?

I only need github repositories for now, no jira nor ci. My github 
username is lucaa.


Thanks a lot,
Anca


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

Re: [xwiki-devs] [Proposal] Title improvements (for 4.2 or 4.3)

[Anca Luca]

On 06/25/2012 09:24 AM, Vincent Massol wrote:

Hi guys,

Some time back we started improving title handling, I'd like that we continue 
this and I'm proposing some further improvements below:

* Make the title field contain wiki syntax (same as the content field) instead 
of just velocity
it's interesting if we have an i18n macro... for the rest of the 
formatting I'm not sure... I don't know if formatting in titles is used 
that often



* Make the title field a textarea so that we can have more than 1 line

big +1, not for the lines, but for the size (255 becomes quickly too small)

* Display a textarea of 1 line initially (to preserve space) but enlarge the 
textarea visibility by several line on the first Enter keypress in the field
more or less, I think we should keep it simple for the titles: no 
wysiwyg editor, no textarea, just as it was until now, except that longer.

* Stop trying to extract title content from the doc content
* Have a backward compat param to still support the old mode, but have it off 
by default in 4.2/4.3
This is interesting too, but I don't have a strong opinion, although not 
extracting titles anymore would be wonderful :) .

side
* Introduce a {{i18n}} macro (or {{translate}}, or …)
/side


+1

I think we should also have a discussion about the purpose of the title 
(now that we can put anything in document name) and how titles should be 
used by default by the platform, but I need to clear the ideas a bit in 
my head before starting it.


Thanks,
Anca



Advantages:
* Same as the content field - More consistency
* More power since we use wiki syntax and we can use any script language
* Removes the WTF symptom when a user edits a page having velocity script in 
the title since they'll see it displayed in WYSIWYG mode with the title content 
evaluated
* Removes the uncertainty about title extraction (for ex if some macro 
generates headings) but still allow it if it's really needed - Since the user 
will be able to write scripts in the title textarea and those scripts can 
extract stuff from the doc content if they really need it
* We'll be able to add a l18n macro and thus display the title translations 
nicely in the wysiwyg editor

WDYT?

Thanks
-Vincent

___
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

Re: [xwiki-devs] [Proposal] Title improvements (for 4.2 or 4.3)

[Anca Luca]

On 06/25/2012 09:52 AM, Thomas Mortagne wrote:

On Mon, Jun 25, 2012 at 9:24 AM, Vincent Massol vinc...@massol.net wrote:

Hi guys,

Some time back we started improving title handling, I'd like that we continue 
this and I'm proposing some further improvements below:

* Make the title field contain wiki syntax (same as the content field) instead 
of just velocity

I'm generally +1 for wiki content everywhere possible. Note that this
is not going to be a smooth migration since a lot of titles contains
velocity in XE for example and in most application in general.


* Make the title field a textarea so that we can have more than 1 line
* Display a textarea of 1 line initially (to preserve space) but enlarge the 
textarea visibility by several line on the first Enter keypress in the field

Would be nice to support that for object fields too.


* Stop trying to extract title content from the doc content

Big +1 as I always been. But not sure it's the same subject. We can do
that whatever is the decision for the rest especially since we already
voted it once...


* Have a backward compat param to still support the old mode, but have it off 
by default in 4.2/4.3

If by old mode you mean velocity only content we can't exactly talk
about compat param. It's going to be more a switch since you can't
really have both old velocity based content and generic wiki content
at the same time. That makes this parameter pretty much unsuable IMO
(either you break all old stuff or all new stuff).

Another idea (which is probably worst given all the APIs change that
could produce but worth mentioning) could be to add a new field
(something like titleContent) which would be wiki based and
deprecated title field which keep working the same way. When the
compatibility parameter is enabled, fallback on title when
titleContent is empty. We could enable it by default in 4.2 and
disable it in 4.3. At least this system makes easier to have both
modes working together.


I don't like this idea at all, not because of the APIs, but because we 
already have document name and document title between which users/devs 
don't really understand/know how to manage the difference , I don't 
think we should have another field (which will be there for quite some 
versions and then we'll have issues when we'll want to remove it, etc).  
I think I prefer some migration issues than this.


Anca




side
* Introduce a {{i18n}} macro (or {{translate}}, or …)
/side

Not critical but yes we are using $msg.get a lot in our applications
titles at least so would be nice to have a pure wiki replacement since
it's a bit more painful to have to write
{{velocty}}$msg.get('toto'){{/velocty}} in title than page content.


Advantages:
* Same as the content field - More consistency
* More power since we use wiki syntax and we can use any script language
* Removes the WTF symptom when a user edits a page having velocity script in 
the title since they'll see it displayed in WYSIWYG mode with the title content 
evaluated
* Removes the uncertainty about title extraction (for ex if some macro 
generates headings) but still allow it if it's really needed - Since the user 
will be able to write scripts in the title textarea and those scripts can 
extract stuff from the doc content if they really need it
* We'll be able to add a l18n macro and thus display the title translations 
nicely in the wysiwyg editor

WDYT?

+1 to do this change when possible but I don't have much idea to make


Thanks
-Vincent

___
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

Re: [xwiki-devs] [Proposal] Title improvements (for 4.2 or 4.3)

[Anca Luca]

On 06/25/2012 10:59 AM, Eduard Moraru wrote:

Hi,

On Mon, Jun 25, 2012 at 10:24 AM, Vincent Massol vinc...@massol.net wrote:


Hi guys,

Some time back we started improving title handling, I'd like that we
continue this and I'm proposing some further improvements below:

* Make the title field contain wiki syntax (same as the content field)
instead of just velocity


I am not a big fan of seeing code (of any kind) in titles. IMO, it is bad
practice and we should discourage people from doing it. You have lots of
problems when some application lists the titles of pages with code in their
title or, worse, when the application tries to render those titles. You
have all sorts of security issues and generally bad things when the writer
of that title does not assume that it is going to be rendered outside his
page. I know it is a cool feature, but it is causing too much headache to
handle correctly.

AFAIK, 90% of the times when we need the title to be rendered is because we
need translation keys. We could very well have a filtered wiki syntax, that
allows only calls to the new {{translation}} macro.


As Thomas said, there are cases when something else is used (with 
velocity code, yes). Now this something else might indeed be only 10% of 
the cases, but we should still keep it possible. Not show it in the UI 
because 90% of the people don't care about it, but still keep it possible.




An alternative to people that *really* want to generate their title trough
a script is to actually keep the title extraction from the document content
and make them have to generate a h1 element from the content, not from
the title. This means that they have to leave the actual title empty for
the extraction to be triggered and, if I am not mistaken, applications that
want to list document titles can use
api.Document.gerRenderedTitle(document.syntax.toIdString()) (as they
probably did before) and the first heading (that is either static or
programmatically generated)


No, not programatically generated. Last time I checked,  title 
extraction tool was not evaluating scripts.
Also this extraction thing is really crap because it's hard to use: it 
uses a hack to not display the title twice, which is to search for the 
h1 with a regex (aa!) in a vm to put a hidden class so that it's not 
displayed. This makes it terribly painful to re-use those title and 
content somewhere else since you don't know if you'll have 2 titles or 
just one (in a pdf export, for example).


Thanks,
Anca


will be displayed, which sounds good to me.

So I would be +1, considering the comment above (restricted use of macros).



* Make the title field a textarea so that we can have more than 1 line
* Display a textarea of 1 line initially (to preserve space) but enlarge
the textarea visibility by several line on the first Enter keypress in the
field
* Stop trying to extract title content from the doc content


+1



* Have a backward compat param to still support the old mode, but have it
off by default in 4.2/4.3
side
* Introduce a {{i18n}} macro (or {{translate}}, or …)


+1



/side

Advantages:
* Same as the content field - More consistency
* More power since we use wiki syntax and we can use any script language


More problems for devs, more raised eyebrows from users. :)



* Removes the WTF symptom when a user edits a page having velocity script
in the title since they'll see it displayed in WYSIWYG mode with the title
content evaluated
* Removes the uncertainty about title extraction (for ex if some macro
generates headings) but still allow it if it's really needed - Since the
user will be able to write scripts in the title textarea and those scripts
can extract stuff from the doc content if they really need it
* We'll be able to add a l18n macro and thus display the title
translations nicely in the wysiwyg editor

WDYT?

Thanks
-Vincent

___
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

Re: [xwiki-devs] [Proposal] Title improvements (for 4.2 or 4.3)

[Anca Luca]

On 06/25/2012 11:03 AM, Vincent Massol wrote:

On Jun 25, 2012, at 10:51 AM, Anca Luca wrote:


On 06/25/2012 09:24 AM, Vincent Massol wrote:

Hi guys,

Some time back we started improving title handling, I'd like that we continue 
this and I'm proposing some further improvements below:

* Make the title field contain wiki syntax (same as the content field) instead 
of just velocity

it's interesting if we have an i18n macro... for the rest of the formatting I'm 
not sure... I don't know if formatting in titles is used that often


* Make the title field a textarea so that we can have more than 1 line

big +1, not for the lines, but for the size (255 becomes quickly too small)

* Display a textarea of 1 line initially (to preserve space) but enlarge the 
textarea visibility by several line on the first Enter keypress in the field

more or less, I think we should keep it simple for the titles: no wysiwyg 
editor, no textarea, just as it was until now, except that longer.

I really think we need wysiwyg, same as for content because it's wiki syntax.


This is a technical argument. If 80% of the people in 80% of the cases 
don't need / care about formatting titles (putting bold, italic, wiki 
macros, links, images and other  stuff in the titles) then we should not 
put it only because it's possible (and yes, sure, consistent with the 
implementation!). 80% (*) of the people will want to set a text and will 
see this whole sofisticated thing with links, images, macros which will 
generate a WTF and a feeling of overdone.


(*) I might be wrong on the numbers, my feeling is that 80% expect 
simple text for the title, but we can research, if you want.



Could you explain your rationale for not having wiki syntax in the title field?

? have I ever said that?
We can have it, but we should not show it because people don't use it 
and can create confusion. Now, the problem if we don't show it is that 
people will put ** and other wiki syntax which will get interpreted and 
they won't understand why.


Also not having wysiwyg will not remove the WTF effect we currently have, see 
http://markmail.org/thread/jwbbz4ypjqcpwral


We could have another solution for that besides a fully fledged wysiwyg. 
Note that I am only against about a fully fledged wysiwyg. If we find 
some other visual solution (e.g. as Jerome suggested) I have nothing 
against, I'm just saying that title should stay simple and the wysiwyg 
is not simple (if only for the fact that it has 2 rows of buttons!).


For translations though, if a wiki is put in multilanguage mode and you 
make a translation of the document, you can translate the title, IIRC. 
So aren't only the application developers concerned about the 
translations of the titles? (because they script the pages and they 
don't want to make 3 translations only to provide the title in a 
different language). Because if it's the case, it's also the situation 
for the velocity titles, so there is no need to show these features to 
regular users, we just need to make a better (easier to customize) 
default xar. Maybe distribute language by language instead of all in one 
pack?


Actually, this is another interesting question: do users actually use 
translations for document titles, or the pb is only when they want to 
customize the default xar?


Thanks,
Anca



Thanks
-Vincent


* Stop trying to extract title content from the doc content
* Have a backward compat param to still support the old mode, but have it off 
by default in 4.2/4.3

This is interesting too, but I don't have a strong opinion, although not 
extracting titles anymore would be wonderful :) .

side
* Introduce a {{i18n}} macro (or {{translate}}, or …)
/side

+1

I think we should also have a discussion about the purpose of the title (now 
that we can put anything in document name) and how titles should be used by 
default by the platform, but I need to clear the ideas a bit in my head before 
starting it.

Thanks,
Anca


Advantages:
* Same as the content field - More consistency
* More power since we use wiki syntax and we can use any script language
* Removes the WTF symptom when a user edits a page having velocity script in 
the title since they'll see it displayed in WYSIWYG mode with the title content 
evaluated
* Removes the uncertainty about title extraction (for ex if some macro 
generates headings) but still allow it if it's really needed - Since the user 
will be able to write scripts in the title textarea and those scripts can 
extract stuff from the doc content if they really need it
* We'll be able to add a l18n macro and thus display the title translations 
nicely in the wysiwyg editor

WDYT?

Thanks
-Vincent

___
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

Re: [xwiki-devs] [Proposal] Title improvements (for 4.2 or 4.3)

[Anca Luca]

On 06/25/2012 12:22 PM, Eduard Moraru wrote:

On Mon, Jun 25, 2012 at 1:19 PM, Anca Luca lu...@xwiki.com wrote:


On 06/25/2012 10:59 AM, Eduard Moraru wrote:


Hi,

On Mon, Jun 25, 2012 at 10:24 AM, Vincent Massol vinc...@massol.net
wrote:

  Hi guys,

Some time back we started improving title handling, I'd like that we
continue this and I'm proposing some further improvements below:

* Make the title field contain wiki syntax (same as the content field)
instead of just velocity


I am not a big fan of seeing code (of any kind) in titles. IMO, it is bad
practice and we should discourage people from doing it. You have lots of
problems when some application lists the titles of pages with code in
their
title or, worse, when the application tries to render those titles. You
have all sorts of security issues and generally bad things when the writer
of that title does not assume that it is going to be rendered outside his
page. I know it is a cool feature, but it is causing too much headache to
handle correctly.

AFAIK, 90% of the times when we need the title to be rendered is because
we
need translation keys. We could very well have a filtered wiki syntax,
that
allows only calls to the new {{translation}} macro.


As Thomas said, there are cases when something else is used (with velocity
code, yes). Now this something else might indeed be only 10% of the cases,
but we should still keep it possible. Not show it in the UI because 90% of
the people don't care about it, but still keep it possible.



Can you please give me some examples where this feature is essential to the
functionality/user experience of an application? (also please see my reply
to Thomas' comment).


2 typical cases:
1/ you have a text in a property in an object in the document and you 
want that text to be displayed as the document title. For various 
reasons, this text cannot be in the document title field itself or in 
the document name (it's not unique, it's not short enough, the text is 
actually part of the type structure and the structure would be 
incomplete if you put the data in the title since title is not semantic 
(it just means document title it doesn't mean frequently asked 
question in a FAQ application, for example ), you don't want to 
duplicate texts (once in a prop once in the title), in enough cases it's 
wrongly used by devs that don't think about using titles and re-add a 
property -- also because http://jira.xwiki.org/browse/XWIKI-7905 --, etc)
2/ indeed you want to decorate the title: e.g. for the search, you want 
to display the searched word in the title; you have a page with scripted 
content that lists all documents for  a tag, or for some property, you 
want the title to be different depending on what that tag is or the property

Also:
3/ We need 1/ and 2/. Indeed they might be just bells and whistles but 
we need them to provide nice things and we want these nice things. Not 
having them will not stop from providing nice things, it will only lead 
to hacking it: customizing .vms to hide the title and then putting it 
with hacked html and css from the document content (i've seen it done), 
or even customizing it directly in the .vm.


As I said in one of my previous mails, I think it's only for devs, a lot 
less for users. So we don't need to show it, for the users the title 
should stay simple, but all these things need to stay possible since 
otherwise everybody will customize by its own mean, more or less 
correct, in 80% of cases (for devs, I repeat).


Thanks,
Anca



Thanks,
Eduard




An alternative to people that *really* want to generate their title trough
a script is to actually keep the title extraction from the document
content
and make them have to generate a h1 element from the content, not from
the title. This means that they have to leave the actual title empty for
the extraction to be triggered and, if I am not mistaken, applications
that
want to list document titles can use
api.Document.gerRenderedTitle(**document.syntax.toIdString()) (as they
probably did before) and the first heading (that is either static or
programmatically generated)


No, not programatically generated. Last time I checked,  title extraction
tool was not evaluating scripts.
Also this extraction thing is really crap because it's hard to use: it
uses a hack to not display the title twice, which is to search for the h1
with a regex (aa!) in a vm to put a hidden class so that it's not
displayed. This makes it terribly painful to re-use those title and content
somewhere else since you don't know if you'll have 2 titles or just one (in
a pdf export, for example).

Thanks,
Anca


  will be displayed, which sounds good to me.

So I would be +1, considering the comment above (restricted use of
macros).


  * Make the title field a textarea so that we can have more than 1 line

* Display a textarea of 1 line initially (to preserve space) but enlarge
the textarea visibility by several line on the first Enter keypress in
the
field

Re: [xwiki-devs] [Proposal] Title improvements (for 4.2 or 4.3)

[Anca Luca]

On 06/25/2012 02:44 PM, Guillaume Lerouge wrote:

Hi,

this looks like a lot of complex things to do for an result that will not
be user friendly.

First, I don't really thing we want users to put styles, links or wiki
macros in titles. The Title is just that, a pretty name for the page. I
don't know any web application that handles the title as anything else than
a simple, one-line-long input field. Handling it differently is going to
create a lot of confusion for users.

We could make entering the title mandatory to make sure there's always one,
and thus remove the need to compute it from the content of the page. If the
title is not given (due to a script creating a page), it could
automatically be filled with the page name when the page is created.

Second, applications that need it would be responsible to compute the right
title for any page based on data entered by the user and would feed it to
the title field upon saving the page.


That's not that easy like that, because it would mean duplicating the 
data and keeping redundant data in sync. I think being able to reuse a 
field with some velocity in the title is a good idea, especially now 
when you can have a sheet for the title too (the new sheets mechanism 
uses the title from the sheet and renders it in the context of the 
document bound to that sheet).
I have seen it (your proposal) done a few times with a listener that is 
responsible to keep data in sync, and it's not that right (let alone the 
fact that duplicating data is not a good idea). What is important though 
is to judge correctly if the title needs to be in a property of the 
class and reused or if it should be put directly in the display title of 
the document. This is a relevant issue in this direction 
http://jira.xwiki.org/browse/XWIKI-7369 as, once fixed, it will show 
application creators that there already is a pretty name for a document 
and that they can use it to put data in (along with 
http://jira.xwiki.org/browse/XWIKI-7905 which will actually allow people 
to use this title as part of the structured document metadata).


Third, we already have a mechanism to handle internationalized content in
wiki pages - the translations of that page in other languages when in
multilingual mode.


I think too that the i18n of titles should also be approached from this 
side: maybe we can do something about i18n in general which will allow 
easier internationalization of titles, instead of changing the titles to 
accomodate easier calls to $msg.get() (since we would need to blow a bit 
the dust off the i18n module as well :) ).


Thanks,
Anca



Right now, it feels like we're about to try to implement something very
complex for the sake of making developer's live a bit easier, while at the
same time sacrificing ease-of-use in a very big way. This is not something
that I feel will benefit XWiki in the long run, whether for users or for
devs.

If we want to change the way the title works, I'd like us to *start with a
list of use cases* and see *how the proposed solution impacts them and
makes them better.*

Thanks,

Guillaume

On Mon, Jun 25, 2012 at 1:01 PM, Anca Luca lu...@xwiki.com wrote:


On 06/25/2012 12:22 PM, Eduard Moraru wrote:


On Mon, Jun 25, 2012 at 1:19 PM, Anca Luca lu...@xwiki.com wrote:

  On 06/25/2012 10:59 AM, Eduard Moraru wrote:

  Hi,

On Mon, Jun 25, 2012 at 10:24 AM, Vincent Massol vinc...@massol.net
wrote:

  Hi guys,


Some time back we started improving title handling, I'd like that we
continue this and I'm proposing some further improvements below:

* Make the title field contain wiki syntax (same as the content field)
instead of just velocity

  I am not a big fan of seeing code (of any kind) in titles. IMO, it is

bad
practice and we should discourage people from doing it. You have lots of
problems when some application lists the titles of pages with code in
their
title or, worse, when the application tries to render those titles. You
have all sorts of security issues and generally bad things when the
writer
of that title does not assume that it is going to be rendered outside
his
page. I know it is a cool feature, but it is causing too much headache
to
handle correctly.

AFAIK, 90% of the times when we need the title to be rendered is because
we
need translation keys. We could very well have a filtered wiki syntax,
that
allows only calls to the new {{translation}} macro.

  As Thomas said, there are cases when something else is used (with

velocity
code, yes). Now this something else might indeed be only 10% of the
cases,
but we should still keep it possible. Not show it in the UI because 90%
of
the people don't care about it, but still keep it possible.


  Can you please give me some examples where this feature is essential to

the
functionality/user experience of an application? (also please see my reply
to Thomas' comment).


2 typical cases:
1/ you have a text in a property in an object in the document and you want
that text to be displayed

Re: [xwiki-devs] [Proposal] Title improvements (for 4.2 or 4.3)

[Anca Luca]

On 06/25/2012 12:40 PM, Anca Luca wrote:

On 06/25/2012 11:03 AM, Vincent Massol wrote:

On Jun 25, 2012, at 10:51 AM, Anca Luca wrote:


On 06/25/2012 09:24 AM, Vincent Massol wrote:

Hi guys,

Some time back we started improving title handling, I'd like that 
we continue this and I'm proposing some further improvements below:


* Make the title field contain wiki syntax (same as the content 
field) instead of just velocity
it's interesting if we have an i18n macro... for the rest of the 
formatting I'm not sure... I don't know if formatting in titles is 
used that often



* Make the title field a textarea so that we can have more than 1 line
big +1, not for the lines, but for the size (255 becomes quickly too 
small)
* Display a textarea of 1 line initially (to preserve space) but 
enlarge the textarea visibility by several line on the first Enter 
keypress in the field
more or less, I think we should keep it simple for the titles: no 
wysiwyg editor, no textarea, just as it was until now, except that 
longer.
I really think we need wysiwyg, same as for content because it's wiki 
syntax.


This is a technical argument. If 80% of the people in 80% of the cases 
don't need / care about formatting titles (putting bold, italic, wiki 
macros, links, images and other  stuff in the titles) then we should 
not put it only because it's possible (and yes, sure, consistent with 
the implementation!). 80% (*) of the people will want to set a text 
and will see this whole sofisticated thing with links, images, macros 
which will generate a WTF and a feeling of overdone.


(*) I might be wrong on the numbers, my feeling is that 80% expect 
simple text for the title, but we can research, if you want.


Could you explain your rationale for not having wiki syntax in the 
title field?

? have I ever said that?
We can have it, but we should not show it because people don't use it 
and can create confusion. Now, the problem if we don't show it is that 
people will put ** and other wiki syntax which will get interpreted 
and they won't understand why.


Also not having wysiwyg will not remove the WTF effect we currently 
have, see http://markmail.org/thread/jwbbz4ypjqcpwral


We could have another solution for that besides a fully fledged 
wysiwyg. Note that I am only against about a fully fledged wysiwyg. If 
we find some other visual solution (e.g. as Jerome suggested) I have 
nothing against, I'm just saying that title should stay simple and the 
wysiwyg is not simple (if only for the fact that it has 2 rows of 
buttons!).


For translations though, if a wiki is put in multilanguage mode and 
you make a translation of the document, you can translate the title, 
IIRC. So aren't only the application developers concerned about the 
translations of the titles? (because they script the pages and they 
don't want to make 3 translations only to provide the title in a 
different language). Because if it's the case, it's also the situation 
for the velocity titles, so there is no need to show these features 
to regular users, we just need to make a better (easier to customize) 
default xar. Maybe distribute language by language instead of all in 
one pack?


Another idea I just had is to modify the import/xar install tool to 
allow to choose the languages to import. Thus each document will contain 
text where it has to contain text (instead of msg.get) and users can 
choose on import which languages they want to import, depending on their 
wikis.


Anca



Actually, this is another interesting question: do users actually use 
translations for document titles, or the pb is only when they want to 
customize the default xar?


Thanks,
Anca



Thanks
-Vincent


* Stop trying to extract title content from the doc content
* Have a backward compat param to still support the old mode, but 
have it off by default in 4.2/4.3
This is interesting too, but I don't have a strong opinion, although 
not extracting titles anymore would be wonderful :) .

side
* Introduce a {{i18n}} macro (or {{translate}}, or …)
/side

+1

I think we should also have a discussion about the purpose of the 
title (now that we can put anything in document name) and how titles 
should be used by default by the platform, but I need to clear the 
ideas a bit in my head before starting it.


Thanks,
Anca


Advantages:
* Same as the content field - More consistency
* More power since we use wiki syntax and we can use any script 
language
* Removes the WTF symptom when a user edits a page having velocity 
script in the title since they'll see it displayed in WYSIWYG mode 
with the title content evaluated
* Removes the uncertainty about title extraction (for ex if some 
macro generates headings) but still allow it if it's really needed 
- Since the user will be able to write scripts in the title 
textarea and those scripts can extract stuff from the doc content 
if they really need it
* We'll be able to add a l18n macro and thus display the title 
translations nicely

Re: [xwiki-devs] [xwiki-users] Panels backward compatibility

[Anca Luca]

On 06/13/2012 06:09 PM, Sergiu Dumitriu wrote:

On 06/13/2012 09:17 AM, Vincent Massol wrote:


On Jun 13, 2012, at 2:52 PM, Anca Luca wrote:


On 06/13/2012 02:44 PM, Vincent Massol wrote:

On Jun 13, 2012, at 2:39 PM, Anca Luca wrote:


On 06/13/2012 01:52 PM, Raluca Stavro wrote:

Hi,

On Wed, Jun 13, 2012 at 2:15 PM, Vincent 
Massolvinc...@massol.net   wrote:



On Jun 13, 2012, at 12:44 PM, Raluca Stavro wrote:


I'm resending this mail by using the right subject pattern.

Hello,

I am trying to upgrade an old XEM to 3.5.1.
In this XEM there are some custom panels which have been 
converted to 2.0

syntax and contain code like this:

{{velocity}}
  {{html}}
#panelheader(...)
...
#panelfooter()
  {{/html}}
{{/velocity}}


Do the panels really need the {{html}} wrapper?
If no, then you must remove it.
If yes, then you should consider rewriting them using wiki syntax 
only, then remove the {{html}} wrapper.
If you can't do that, then just move the wrapper inside the 
panelheader/footer.


You can do that automatically with a script.

Because since 2.7.2 panel macros were converted to 2.0 syntax, 
because
panel macros from inside macros.vm were modified by calling 
{{html}} wiki
macro and because we can't use nested {{html}} macros without 
wiki=true
parameter, I don't know how to fix this issue besides modifying 
panel

code.


I don't understand this. Are you saying that in macros.vm #panelheader 
uses {{html}}? That's not true, the panelheader/footer macros only use 
wiki syntax, not {{html}}. The problem isn't that nested {{html}} 
macros don't work, but that wiki syntax doesn't work in {{html}} 
without wiki=true.


This XEM has more than 70 wikis and this I can't just modify 
all custom

(converted to 2.0 syntax) panels manually.
Is there a nice solution to this problem ?

Idea 1:
==

Add a new #panelheaderold macro in macros.vm and replace all 
calls of
#panelheader to #panelheaderold in your panels (easy to do with 
a XWQL

query and 3 lines of scripts).

Slowy migrate panels to new syntax.

Note:
=

Actually in the future we need to add a new {{panel}} macro, 
something

like:

{{panel style=.. title=…}}
… content here …
{{/panel}}

Idea 2:
==

Create a custom Panel wiki macro (give it a name other than 
panel!),

search for:
{{velocity}}{{html}}#panelheader….#panelfooter{{/html}}{{/velocity}} 
(use

a regex)

Replace with your panel macro.


Should I open an issue on Jira ?

Nope

So this means that none of the macros in macros.vm are API?
Which means that there is no API to make a panel header consistent 
with the panel headers of the default panels?
Good point. Macros in macros.vm are supposed to be APIs and it 
means we broke the backward compatibility at some point in the past 
(2.7 as suggested by Raluca).


The macros still work for both xwiki/1.0 and xwiki/2.x panels. What 
doesn't work is putting the whole panel content inside a {{html}} 
block, without any wiki parsing.


The problem was that there was a misunderstanding of the macros 
behavior. The macros were supposed to work well in wiki syntax. 
Initially, that meant the only xwiki syntax, which did mix HTML with 
the rest of the wiki and velocity syntax. When new wiki syntaxes were 
introduced and the macros were updated, the behavior remained the 
same: the #panelheader/footer macros work well in both xwiki/1.0 and 
xwiki/2.x syntaxes. But pure HTML isn't really a wiki syntax. The fact 
that for a few releases the macros worked in pure HTML embedded in an 
xwiki/2.0 document, but not directly in a xwiki/2.0 document, was a 
bug, not a contract. 
Unfortunately some developers did rely on this bug.


I wouldn't call it a bug, because if we do so, then we can argue that 
it's a bug that has been there for at least one major cycle, and that 
macros.vm is still not stable according to 
http://jira.xwiki.org/browse/XWIKI-6062 so we might still have bugs 
about it (and that is for about 2.5 major cycles, which is a bit too 
much from my point of view).


What I would say about this is that apparently we don't know / have a 
convention about how should the macros in macros.vm be used: with syntax 
interpreted or not, in an html macro or not. This is where the confusion 
comes from: while the old panelheader macro _needed_ html macro 
(potentially with syntax activated), the current one needs _only wiki 
syntax_ (potentially in an html macro). There is a context which 
satisfies both (html macro with wiki syntax activated) but it was not 
documented anywhere, I'm not even sure it is _the rule_ for macros in 
macros.vm, so people used what it worked, in this case a plain simple 
html macro whose wiki parameter defaults to false.


The wysiwyg macros in macros.vm, for example, I would say they need to 
be called in a html macro with syntax switched off, but it's just a 
guess, looking at the code.


I think we need to:
1/ make a decision about what is API from macros.vm
2/ make a decision about what _was_ API from

Re: [xwiki-devs] [Proposal] XWiki Days every month?

[Anca Luca]

On 04/27/2012 01:03 PM, Vincent Massol wrote:

Hi devs,

We've had several special days in the past:

* Deprecation day
** 26 April 2012: http://markmail.org/thread/c5oytyvgw6fcimqq

* Bug fixing days:
** 11 june 2008: http://xwiki.markmail.org/thread/oyfxis3umqrvutxm
** 18 June 2008: http://xwiki.markmail.org/thread/brfx6gme37vgr3m5
** 25 Jun 2008: http://markmail.org/message/nrobo3x4ppgssklk
** July 2008: http://xwiki.markmail.org/thread/mn5veblndbtgcsm5
** 10 Feb 2011: http://xwiki.markmail.org/thread/rierrb2wk72dkpqy and result 
http://www.xwiki.org/xwiki/bin/view/Blog/BugFixingDayFebruary2011

* DocHour days:
** 5 March 2008: http://xwiki.markmail.org/thread/dyypju5dn23wkwr2

I think it's a good concept and I'd like to propose that we regularly (once 
every month?) have an XWiki Day.

Ideas for such days:

* Bug fixing day: Reduce bug count
* Doc day: improve xwiki.org
* Deprecation day: reduce # of deprecated calls. Around 1700: 
http://nemo.sonarsource.org/drilldown/violations/XWIKI?rule=squid%3ACallToDeprecatedMethodrule_sev=MINOR
* Violation day: reduce # of violations. 10274 right now: 
http://nemo.sonarsource.org/drilldown/violations/XWIKI


Wow, wow, I'll make sure i'm not here when that will happen... :)


* Javadoc Day: Add missing javadocs in our code and remove checkstyle excludes
* Code Coverage Day: Add as many tests as possible (unit and functional)
* Broken Links Day: fix as many broken links as possible on xwiki.org. To find 
them is easy: we just need to enable the IRC Link Checker botlet and wait on 
IRC to get them!


These violation(!), deprecation broken links days could have a 
positive name: we're not doing a day to break links, we're doing a day 
to fix the broken links so it should be called something like unbroken 
links day or links day or something about what they fix.


Otherwise, yes, I think it's a good idea, although I'm not gonna +1 that 
since there are little chances I can actually participate to it.


Thanks,
Anca



I propose that whenever a day is over, we send a mail with the Date and Topic 
for the next day and it has to be about 1 month from the date of the mail.

To get this started I volunteer to be responsible for sending Day emails for 
now, unless someone else is interested to do this.

WDYT?

Thanks
-Vincent



___
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

Re: [xwiki-devs] [Proposal] Choosing the default component implementation

[Anca Luca]

On 04/06/2012 08:51 AM, Vincent Massol wrote:

On Apr 5, 2012, at 6:51 PM, Anca Luca wrote:


On 04/05/2012 06:42 PM, Vincent Massol wrote:

Hi Sergiu,

On Apr 5, 2012, at 5:55 PM, Sergiu Dumitriu wrote:


Hi devs,

Currently, requesting a component instance without a hint will look for the implementation that 
uses the default hint, which makes it difficult to change the implementation in an 
XWiki instance. Sure, it is easy as long as all the implementations use the default 
hint, but choosing the default between alternative implementations that should all still be usable 
by themselves is not possible.

Also, default is not really a good hint, since it describes the state of the 
implementation, not the technology, the aspect that makes it different from the others. 
It would be better to name each implementation with a proper hint.

I propose to define a mapping that can specify which hint is the default for a 
component. In a text file, META-INF/component-defaults.txt, we'll keep 
componentinterface=defaulthint mappings. For example:

com.xpn.xwiki.store.XWikiStoreInterface=hibernate
com.xpn.xwiki.store.migration.DataMigrationManager=hibernate

And then, when we lookup the current storage implementation, we don't need to 
check what is the configured hint in xwiki.cfg (or xwiki.properties), we can 
just request the default implementation.

If there's no mapping for a component, we'll continue to use the default hint.

I'm not sure where exactly to keep such files. We bundle a components.txt file 
in each jar containing component implementations. We could do the same for the 
components we consider the platform defaults, and allow overrides in the 
WEB-INF/classes/META-INF/component-defaults.txt file. Still, this means that 
whenever platform defaults change, we need to keep another special section in 
the release notes, to let users know about these changes, so that they can 
manually revert to the old default if they need to.

In the future we could change existing components to give proper hints instead of 
default, where such a change is applicable.

Another idea is to not use default at all, and instead go for a generic xwiki, xe, 
xwiki-platform or something like that whenever there's just one implementation for a component and we can't 
find another hint to describe it.

WDYT?

This is not really how it's been designed ATM. Whenever you wish to use a 
different implementation of a component you use a component implementation with 
the same role and same hint. You then make it available in your classpath. (Of 
course you can also do this at runtime simply by registering a new 
implementation over the old one).

To decide which implementation is used you use a priority order, as described 
on:
http://extensions.xwiki.org/xwiki/bin/view/Extension/Component+Module#HOverrides

I'd be curious to know your exact use case and understand why the current 
mechanism doesn't work for it.

One usecase I see is that you have multiple implementations and you want to 
change the default one for a specific running instance of xwiki.

This is supported already.


Overwrite mechanism only allows you to say which impl should be used from the 
_components with the same hint_. However, you cannot change the hint of a 
component at configuration time, so if you have a standard distr of xwiki and 
you want to use ldap authentication, let's say (if only auth was impl with 
components), unless you do some java to add the default hint to the ldap 
implementation and then to specify that this one has priority over all the 
default ones, I don't see how you can re-wire the default.

Yes that's because the hint is not a configuration param. It's an intrinsic 
information about what it represents. When you have:

@Named(ldap)
public class DefaultLDAPAuthenticator implements Authenticator
...

It means that (Authenticator,ldap) means the LDAP Authenticator implementation and not 
something else. If you want to change that implementation you need to write a component with 
(Authenticator,ldap).

Now if what you want is way to have *several* implementations of the same Role 
at once in the classloader you need to use different hints and if what you want 
is pick one implementation from those various implementation and make it your 
default you need to configure somewhere which one to use. We use that 
everywhere in the XE.

2 examples:
* Macros. In this case it's the user who says which ones to use by using the 
hint as the macro name telling XWiki which macro implementation to use: 
{{hint .../}}
* Storage implementation. In this case we want only one default storage impl to 
be used. What we do is have a Storage Manager which is in charge of deciding 
which implementation to use. In this case the selection is based on a 
configuration param which contains the hint of the implementation to use (for 
ex:  xwiki.store.main.hint=hibernate).

I don't see the limitation. It's even more powerful than what you suggest 
(which

Re: [xwiki-devs] [Proposal] Choosing the default component implementation

[Anca Luca]

I On 04/06/2012 09:35 AM, Vincent Massol wrote:

Hi Sergiu,

Note that below I'm going to play the devil's advocate since I think it's 
important we really think hard before changing anything and verify if our 
current implementation is not enough.

See below.

On Apr 5, 2012, at 8:44 PM, Sergiu Dumitriu wrote:


On 04/05/2012 12:51 PM, Anca Luca wrote:

On 04/05/2012 06:42 PM, Vincent Massol wrote:

Hi Sergiu,

On Apr 5, 2012, at 5:55 PM, Sergiu Dumitriu wrote:


Hi devs,

Currently, requesting a component instance without a hint will look
for the implementation that uses the default hint, which makes it
difficult to change the implementation in an XWiki instance. Sure, it
is easy as long as all the implementations use the default hint,
but choosing the default between alternative implementations that
should all still be usable by themselves is not possible.

Also, default is not really a good hint, since it describes the
state of the implementation, not the technology, the aspect that
makes it different from the others. It would be better to name each
implementation with a proper hint.

I propose to define a mapping that can specify which hint is the
default for a component. In a text file,
META-INF/component-defaults.txt, we'll keep
componentinterface=defaulthint mappings. For example:

com.xpn.xwiki.store.XWikiStoreInterface=hibernate
com.xpn.xwiki.store.migration.DataMigrationManager=hibernate

And then, when we lookup the current storage implementation, we don't
need to check what is the configured hint in xwiki.cfg (or
xwiki.properties), we can just request the default implementation.

If there's no mapping for a component, we'll continue to use the
default hint.

I'm not sure where exactly to keep such files. We bundle a
components.txt file in each jar containing component implementations.
We could do the same for the components we consider the platform
defaults, and allow overrides in the
WEB-INF/classes/META-INF/component-defaults.txt file. Still, this
means that whenever platform defaults change, we need to keep another
special section in the release notes, to let users know about these
changes, so that they can manually revert to the old default if they
need to.

In the future we could change existing components to give proper
hints instead of default, where such a change is applicable.

Another idea is to not use default at all, and instead go for a
generic xwiki, xe, xwiki-platform or something like that
whenever there's just one implementation for a component and we can't
find another hint to describe it.

WDYT?

This is not really how it's been designed ATM. Whenever you wish to
use a different implementation of a component you use a component
implementation with the same role and same hint. You then make it
available in your classpath. (Of course you can also do this at
runtime simply by registering a new implementation over the old one).

To decide which implementation is used you use a priority order, as
described on:
http://extensions.xwiki.org/xwiki/bin/view/Extension/Component+Module#HOverrides


I'd be curious to know your exact use case and understand why the
current mechanism doesn't work for it.

...choosing the default between alternative implementations that should all **still 
be usable by themselves** is not possible

The overrides mechanism allows to change which component will be returned for the 
default hint, but all the others will be invisible.


One usecase I see is that you have multiple implementations and you want
to change the default one for a specific running instance of xwiki.

Overwrite mechanism only allows you to say which impl should be used
from the _components with the same hint_. However, you cannot change the
hint of a component at configuration time, so if you have a standard
distr of xwiki and you want to use ldap authentication, let's say (if
only auth was impl with components), unless you do some java to add the
default hint to the ldap implementation and then to specify that this
one has priority over all the default ones, I don't see how you can
re-wire the default.

Exactly. For most of the services the XWiki platform currently has (storage, cache), we 
don't have a default implementation, but we rely on a kind of factory to lookup the 
configured default. That is an actual factory class in the case of the cache service, but just more 
code in the old XWiki.java class for the storage initialization.

Yep that's how it works.


A standard way of selecting the default means that we'll need less factories, 
and less code is always a good thing.

Yes but it has more limitation to what we have since with a proper Factory you 
can imagine all kind of logic to decide which implementation to use (hour of 
the day, whether the user is a premium user or not, etc).

BTW we do support Providers and the goal of the Provider is to be a factory for 
a given Role. So from now on, there should be no need to implement a Factory 
proper. Implementing a Provider

Re: [xwiki-devs] [Proposal] Choosing the default component implementation

[Anca Luca]

On 04/06/2012 12:36 PM, Vincent Massol wrote:

On Apr 6, 2012, at 11:43 AM, Anca Luca wrote:


I On 04/06/2012 09:35 AM, Vincent Massol wrote:

Hi Sergiu,

Note that below I'm going to play the devil's advocate since I think it's 
important we really think hard before changing anything and verify if our 
current implementation is not enough.

See below.

On Apr 5, 2012, at 8:44 PM, Sergiu Dumitriu wrote:


On 04/05/2012 12:51 PM, Anca Luca wrote:

On 04/05/2012 06:42 PM, Vincent Massol wrote:

Hi Sergiu,

On Apr 5, 2012, at 5:55 PM, Sergiu Dumitriu wrote:


Hi devs,

Currently, requesting a component instance without a hint will look
for the implementation that uses the default hint, which makes it
difficult to change the implementation in an XWiki instance. Sure, it
is easy as long as all the implementations use the default hint,
but choosing the default between alternative implementations that
should all still be usable by themselves is not possible.

Also, default is not really a good hint, since it describes the
state of the implementation, not the technology, the aspect that
makes it different from the others. It would be better to name each
implementation with a proper hint.

I propose to define a mapping that can specify which hint is the
default for a component. In a text file,
META-INF/component-defaults.txt, we'll keep
componentinterface=defaulthint mappings. For example:

com.xpn.xwiki.store.XWikiStoreInterface=hibernate
com.xpn.xwiki.store.migration.DataMigrationManager=hibernate

And then, when we lookup the current storage implementation, we don't
need to check what is the configured hint in xwiki.cfg (or
xwiki.properties), we can just request the default implementation.

If there's no mapping for a component, we'll continue to use the
default hint.

I'm not sure where exactly to keep such files. We bundle a
components.txt file in each jar containing component implementations.
We could do the same for the components we consider the platform
defaults, and allow overrides in the
WEB-INF/classes/META-INF/component-defaults.txt file. Still, this
means that whenever platform defaults change, we need to keep another
special section in the release notes, to let users know about these
changes, so that they can manually revert to the old default if they
need to.

In the future we could change existing components to give proper
hints instead of default, where such a change is applicable.

Another idea is to not use default at all, and instead go for a
generic xwiki, xe, xwiki-platform or something like that
whenever there's just one implementation for a component and we can't
find another hint to describe it.

WDYT?

This is not really how it's been designed ATM. Whenever you wish to
use a different implementation of a component you use a component
implementation with the same role and same hint. You then make it
available in your classpath. (Of course you can also do this at
runtime simply by registering a new implementation over the old one).

To decide which implementation is used you use a priority order, as
described on:
http://extensions.xwiki.org/xwiki/bin/view/Extension/Component+Module#HOverrides


I'd be curious to know your exact use case and understand why the
current mechanism doesn't work for it.

...choosing the default between alternative implementations that should all **still 
be usable by themselves** is not possible

The overrides mechanism allows to change which component will be returned for the 
default hint, but all the others will be invisible.


One usecase I see is that you have multiple implementations and you want
to change the default one for a specific running instance of xwiki.

Overwrite mechanism only allows you to say which impl should be used
from the _components with the same hint_. However, you cannot change the
hint of a component at configuration time, so if you have a standard
distr of xwiki and you want to use ldap authentication, let's say (if
only auth was impl with components), unless you do some java to add the
default hint to the ldap implementation and then to specify that this
one has priority over all the default ones, I don't see how you can
re-wire the default.

Exactly. For most of the services the XWiki platform currently has (storage, cache), we 
don't have a default implementation, but we rely on a kind of factory to lookup the 
configured default. That is an actual factory class in the case of the cache service, but just more 
code in the old XWiki.java class for the storage initialization.

Yep that's how it works.


A standard way of selecting the default means that we'll need less factories, 
and less code is always a good thing.

Yes but it has more limitation to what we have since with a proper Factory you 
can imagine all kind of logic to decide which implementation to use (hour of 
the day, whether the user is a premium user or not, etc).

BTW we do support Providers and the goal of the Provider is to be a factory for 
a given Role. So

Re: [xwiki-devs] [Proposal] Choosing the default component implementation

[Anca Luca]

Hi Sergiu,

I think that components and xwiki defaults are 2 distinct issues, and 
here you're talking about defaults for xwiki (meta) services, not the 
defaults for what a service means from a (lower level) component pov.


At component level, from my pov, default means I don't care, I just 
need one.
At xwiki services level (storage, authentication, datamigration, etc), 
default means: whichever is considered standard in the running 
instance of xwiki.


I understand the need (which is why I love declarative wiring of 
components, a la osgi/apache felix), yet I'm not 100% sure that we need 
another mechanism to make it happen.


We have already changed the component overriding mechanism to allow 
potentially infinite overriding, changing the 'default' implementation 
in the whole instance can be achieved with this.


Also, we could still keep these configs in the 
xwiki.cfg/xwiki.properties file (yet another configuration file 
components-defaults.txt would be a pain from my pov) and change the 
behaviour of the component manager (yey) to take that into account on 
lookup. In the end, it _is_ about configuration (whether your xwiki 
should use hibernate or other store).


Actually there's a third thing: the fact that default is not reflecting 
the technology and for that there is a simple solution: you can have 
multiple hints for a component. Thus, a hibernate thingy would have 
hibernate and default hints. However, you need to check that the 
Component manager is giving you the same instance when you ask for one 
or the other of the hints (I think there was an issue like that with 
components implementing multiple roles).


see below for more

On 04/05/2012 05:55 PM, Sergiu Dumitriu wrote:

Hi devs,

Currently, requesting a component instance without a hint will look 
for the implementation that uses the default hint, which makes it 
difficult to change the implementation in an XWiki instance. Sure, it 
is easy as long as all the implementations use the default hint, but 
choosing the default between alternative implementations that should 
all still be usable by themselves is not possible.


Also, default is not really a good hint, since it describes the 
state of the implementation, not the technology, the aspect that makes 
it different from the others. It would be better to name each 
implementation with a proper hint.


I propose to define a mapping that can specify which hint is the 
default for a component. In a text file, 
META-INF/component-defaults.txt, we'll keep 
componentinterface=defaulthint mappings. For example:


com.xpn.xwiki.store.XWikiStoreInterface=hibernate
com.xpn.xwiki.store.migration.DataMigrationManager=hibernate

And then, when we lookup the current storage implementation, we don't 
need to check what is the configured hint in xwiki.cfg (or 
xwiki.properties), we can just request the default implementation.


If there's no mapping for a component, we'll continue to use the 
default hint.


I'm not sure where exactly to keep such files. We bundle a 
components.txt file in each jar containing component implementations. 
We could do the same for the components we consider the platform 
defaults, and allow overrides in the 
WEB-INF/classes/META-INF/component-defaults.txt file. Still, this 
means that whenever platform defaults change, we need to keep another 
special section in the release notes, to let users know about these 
changes, so that they can manually revert to the old default if they 
need to.


Why? if they requested the default, as per my starting remark, it means 
I don't care, I just need one. So why should it matter that the 
implementation changed?


Actually, if all the hint changes we make are about replacing default 
implementations with hinted implementations and using the new hint as 
the default, there shouldn't be any problem for the user. If we change 
the default implementation itself, we'd need to announce that regardless 
of the way we use to configure that (using default hint or proxying the 
default with a declarative, overridable wiring) .




In the future we could change existing components to give proper hints 
instead of default, where such a change is applicable.


Another idea is to not use default at all, and instead go for a 
generic xwiki, xe, xwiki-platform or something like that 
whenever there's just one implementation for a component and we can't 
find another hint to describe it.


I'm not sure we need that.  We can consider it's a namespaced name and 
that default means default in xwiki.




WDYT?


In the end I agree, I think it's a good idea to:
1/ remove the obligation of having one component that has the hint default
2/ allowing the default to be wired at configuration phase rather than 
at development phase, in a declarative file that an admin can more 
easily operate with.


but it shouldn't be in yet another configuration file, it should be in 
one of the standard configuration files (actually the one and only 

Re: [xwiki-devs] [Brainstorming] Pretty printing XML when exporting XAR?

[Anca Luca]

On 04/05/2012 06:36 PM, Vincent Massol wrote:

Hi devs,

We need to take a decision. There are 2 places where we have XMLs:

A) In our SCM when we store our documents and when we call mvn xar:format
B) When we export XARs

Right now we pretty print in A) (very recent, I've done this a few days ago) 
but not in B) which is not optimal since users absolutely need to call 
xar:format to be able to diff their output with what is in our SCM.

* Solution 1: we don't pretty print in A and B
* Solution 2: we pretty print in A and B

What would you prefer?


I prefer solution 2), as long as we're sure that it never adds extra 
whitespaces in the text nodes.





Thanks
-Vincent

___
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

Re: [xwiki-devs] [Proposal] Choosing the default component implementation

[Anca Luca]

On 04/05/2012 06:42 PM, Vincent Massol wrote:

Hi Sergiu,

On Apr 5, 2012, at 5:55 PM, Sergiu Dumitriu wrote:


Hi devs,

Currently, requesting a component instance without a hint will look for the implementation that 
uses the default hint, which makes it difficult to change the implementation in an 
XWiki instance. Sure, it is easy as long as all the implementations use the default 
hint, but choosing the default between alternative implementations that should all still be usable 
by themselves is not possible.

Also, default is not really a good hint, since it describes the state of the 
implementation, not the technology, the aspect that makes it different from the others. 
It would be better to name each implementation with a proper hint.

I propose to define a mapping that can specify which hint is the default for a 
component. In a text file, META-INF/component-defaults.txt, we'll keep 
componentinterface=defaulthint mappings. For example:

com.xpn.xwiki.store.XWikiStoreInterface=hibernate
com.xpn.xwiki.store.migration.DataMigrationManager=hibernate

And then, when we lookup the current storage implementation, we don't need to 
check what is the configured hint in xwiki.cfg (or xwiki.properties), we can 
just request the default implementation.

If there's no mapping for a component, we'll continue to use the default hint.

I'm not sure where exactly to keep such files. We bundle a components.txt file 
in each jar containing component implementations. We could do the same for the 
components we consider the platform defaults, and allow overrides in the 
WEB-INF/classes/META-INF/component-defaults.txt file. Still, this means that 
whenever platform defaults change, we need to keep another special section in 
the release notes, to let users know about these changes, so that they can 
manually revert to the old default if they need to.

In the future we could change existing components to give proper hints instead of 
default, where such a change is applicable.

Another idea is to not use default at all, and instead go for a generic xwiki, xe, 
xwiki-platform or something like that whenever there's just one implementation for a component and we can't 
find another hint to describe it.

WDYT?

This is not really how it's been designed ATM. Whenever you wish to use a 
different implementation of a component you use a component implementation with 
the same role and same hint. You then make it available in your classpath. (Of 
course you can also do this at runtime simply by registering a new 
implementation over the old one).

To decide which implementation is used you use a priority order, as described 
on:
http://extensions.xwiki.org/xwiki/bin/view/Extension/Component+Module#HOverrides

I'd be curious to know your exact use case and understand why the current 
mechanism doesn't work for it.


One usecase I see is that you have multiple implementations and you want 
to change the default one for a specific running instance of xwiki.


Overwrite mechanism only allows you to say which impl should be used 
from the _components with the same hint_. However, you cannot change the 
hint of a component at configuration time, so if you have a standard 
distr of xwiki and you want to use ldap authentication, let's say (if 
only auth was impl with components), unless you do some java to add the 
default hint to the ldap implementation and then to specify that this 
one has priority over all the default ones, I don't see how you can 
re-wire the default.





Thanks
-Vincent

___
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

Re: [xwiki-devs] [xwiki-users] Questions about Blog Example

[Anca Luca]

Hi Dave,

You should read 
http://platform.xwiki.org/xwiki/bin/view/DevGuide/Architecture , but I 
understand that it might be cryptic for a first time usage so here we go:
must know that xwiki is a java engine, so there is some java code that 
does things, it's not all done in velocity.
Basically, there is a java platform that can handle documents, objects 
in documents, classes, etc (load, save) and then there is the velocity 
scripting that you can do in wiki pages which **uses** this core 
(injected variables like $xwiki, $doc). See here about how this 
scripting in pages works: 
http://platform.xwiki.org/xwiki/bin/view/DevGuide/Scripting .
Also, there are some interesting information about the data model here 
http://platform.xwiki.org/xwiki/bin/view/DevGuide/DataModel .


The 'platform' project on git contains all this 'platform' code: java 
sources, default templates, default js, css, etc, which you can enhance 
in wiki pages (but we don't do everything in wiki pages, so you should 
not look for it only in wiki pages).


Also, there are a bunch of default velocity templates that handle the 
default layout and actions for the wiki (in the webapps/xwiki/templates 
folder of the installation). For example, the save and view button is 
generated by these templates, along with the url to which the data in 
the form is posted.


I recommend firebug and LiveHttpheaders extensions of firefox to study 
what data is posted to which URL, etc what data is received. from then 
on, with the help of 
http://platform.xwiki.org/xwiki/bin/view/DevGuide/Architecture#HUnderstandinghowHTTPrequestsarehandled 
, you should be able to find the code that actually does the save.


Have fun,
Anca

On 03/28/2012 05:42 AM, du du wrote:

Also from the following BlogPostSheet wiki code, after users type in
message from the inline form, users click Save  View button, how are the
messages saved to database?
see the attached code:
{{include document=Blog.BlogCode/}}

{{include document=Blog.CategoriesCode/}}

{{velocity filter=none}}
{{html clean=false wiki=true}}
$xwiki.jsx.use('Blog.ManageCategories', {'mode' : 'select'})##
$xwiki.ssx.use('Blog.ManageCategories')##
#getEntryObject($doc $entryObj)
#if($!entryObj == '')
   #warning($msg.get('xe.blog.sheet.notpost'))
## Keep testing the inline action for backward compatibility with older
blog posts.
#elseif($xcontext.action != 'edit'  $xcontext.action != 'inline')
   ## View mode
   #isPublished($entryObj $isPublished)
   #isHidden($entryObj $isHidden)
   ## displayBlog requires a list of documents, and whether to display only
an extract or the full entry.
   #displayBlog([$tdoc] 'single' false false)
#else
   dl
   dt$msg.get('xe.blog.sheet.title')/dt
   dd$doc.display('title', 'edit', $entryObj)/dd
   dt$msg.get('xe.blog.sheet.content')/dt
   dd$doc.display('content', 'edit', $entryObj)/dd
   dt$msg.get('xe.blog.sheet.summary')/dt
   dd$doc.display('extract', 'edit', $entryObj)/dd
   dt$msg.get('xe.blog.sheet.category')/dt
   dd
   #displayCategoryManagementTree('' 'selectable')
   div class=clearfloats/div
   /dd
   /dl
   #template('tagedit.vm')
   #isPublished($entryObj $isPublished)
   #if($isPublished)
 #if($doc.creator == $xcontext.user)
   #publishMessageBox($msg.get('xe.blog.sheet.publicationdate',
[${doc.display('publishDate', 'view', $entryObj)}]))
   #set($hideArticle = ${doc.display('hidden', 'edit', $entryObj)})
   #hideMessageBox($msg.get('xe.blog.sheet.hidearticle',
[${hideArticle}]))
 #end
   #else
 #set($defaultDate =
$xwiki.getDocument($blogPostTemplate).getObject($blogPostClassname).getProperty('publishDate').value.time)
 #if($entryObj.getProperty('publishDate').value.time == $defaultDate)
   ## The publish date was not set, force it to be the creation date
   $entryObj.set('publishDate', $doc.creationDate)
 #end
 #publishMessageBox($msg.get('xe.blog.sheet.notpublished')
label**$msg.get('xe.blog.sheet.publish') ${doc.display('published',
'edit', $entryObj)}**/label\\label$msg.get('xe.blog.sheet.setdate')
${doc.display('publishDate', 'edit', $entryObj)}/label)
   #end
#end
{{/html}}
{{/velocity}}

Thanks
Dave

On Tue, Mar 27, 2012 at 11:36 PM, du duddd...@gmail.com  wrote:


Hi, all

I am studying the BlogClass, BlogPostClass, I checked the Blog.BlogCode,
there are alot of velocity scripts, I can see the search documents from db,
but could not find any code related to insert document records into
database, so how is the document created from blog saved into database?
please point me to the script code in the Blog.BlogCode.

Thanks

Dave

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


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

Re: [xwiki-devs] [discussion] Polishing the merge between Annotations and Comments

[Anca Luca]

Hi Sorin,

On 03/27/2012 01:32 PM, Sorin Burjan wrote:

Hello everybody,

I have started testing and playing a little bit with our new features, the
merge between Annotations and Comments. I am very happy about this new
feature, since this offers more flexibility and power.

However, this is the initial commit and it still requires polishing in
order to be ultra cool. Here are some of my suggestions after I tried to
impersonate  a non technical end-user:

1) After adding an Annotation, user wants to add a reply by hovering over
the yellow icon and  clicking on the Reply button. This will move the
caret at the bottom of the page, in the Comments Tab. It is a little bit
confusing for the end users, which would expect an input text area to
appear in the Annotation box, instead of being moved to the bottom of the
page.

2) User wants to see the full thread of an annotation. He/she will hover
over the yellow icon, and only the first/initial annotation will be
visible. If there is at least one reply to that annotation, the user will
see a link with See thread. Clicking on the link, user will be sent in
the Comments tab at the bottom of the page. An idea is to be able to see
the whole thread related to that annotation in the same place, without
having to be moved to the bottom of the page. Now a problem might be if the
thread is really large.


The initial UI proposal for annotations was indeed like that, with 
replies displayed inline, under the annotation when hovering.
We could do that, but indeed there is a problem with scalability (we 
could use a see more link or something). There is also an 
implementation issue, as it might not be that easy to do that, but let's 
say we don't care about that for now.
However this and some other issues that you mentioned under are about 
how you see the comment threads, if they're tightly connected or loosely 
connected.
Tight connection means that there is a very strong relation between the 
comments in the same thread, that replies are actually comments to the 
comment and that they cannot exist one without the other, so a thread 
needs to be handled as a unity.
Loose connection means that the relation between the comments in the 
same thread is a weak relation, is more of a symlink than a hard link if 
you want, and that replies are actually comments of the document, which 
are only related to the comment they reply to (but their existence 
doesn't depend on the comment but on the document), and as a consequence 
they can live one without the others.


Unfortunately, depending on the usage of the comments (what they 
actually contain) and of the user who sees it, the vision can be one or 
the other.




3) User wants to delete the whole thread (maybe he/she wants to delete the
annotation + all the threads). Clicking on the  x button, only the
first/actual displayed annotation will be deleted, leaving the rest of the
thread/replies on the page at the bottom. IMO this would create confusion
among end users and leave mess in the page objects, because users will not
understand the context of the remaining comments. This behavior actually
comes from Comments feature,  which is keeping the replies even if the
level 1 comment is deleted.


What makes it one way or the other is the type of connection we decide 
to have. However this is a pure comments issue, not an annotations issues.
I would rather go for loosely coupled comments so deleting a comment 
should not touch the replies. Maybe we can have an option...




4) Clicking on the See Thread link, will move the user to the bottom of
the page, and will highlight with yellow color the Author and Content of
the first annotation only. IMO this is not very suggestive, the highlight
could be useful only as a delimitation of the starting point of the
thread, but by highlighting the content too is confusing for end users.
This behavior comes from the Permalink behavior of Comments feature.


I think the highlight is collateral here, what's important is the 
positioning of the page. In the end, it does take you to the place where 
you can see the thread. It doesn't necessarrily means it has to 
isolate it from context. However this also depends a bit on how we see 
the concept of thread, as I described above.




5) If we say that Annotations are merged with Comments, we can decide if we
still keep them visually separated. When adding a new Annotation, in the
Comments tab, you can see a small yellow icon denoting that this is an
annotation. If user replies to that annotation, the second/nested
annotation will be treated as a regular comment. This means only level 1
annotations are marked with the yellow sign, replies or ordinary comments
aren't. This seems a little inconsistent IMO.


As I said above, it depends on how you see the comment threads: does the 
fact that a comment is a reply to an annotation make the reply 
automatically an annotation on the same text from the document as the 
replied annotation? if they're tightly 

Re: [xwiki-devs] [Brainstorming] Stop adding stuff to oldcore because new modules shouldn't depend on oldcore?

[Anca Luca]

+1,

this vote is a bit strange to me since I thought we're already doing 
that (i.e. if it's not bugfix or code deletion ;) , there shouldn't be a 
commit in the oldcore)


Thanks,
Anca

On 03/27/2012 04:18 PM, Denis Gervalle wrote:

On Mon, Mar 26, 2012 at 10:39, Vincent Massolvinc...@massol.net  wrote:


Hi devs,

I see that we keep adding stuff regularly to oldcore and the reason is my
code depends on oldcore so I cannot depend on oldcore in new modules.

First, this is not completely true. We have several modules that already
depend on oldcore.

Also we cannot wait indefinitely that the new model magically appears
(that won't happen… :)).

I think it's fine to depend on oldcore when a new module requires to use
the model and when the bridge (DAB) is not enough. However we need to be
careful about one thing: that oldcore itself doesn't use that new module.
So sometimes it will mean extracting stuff from oldcore into a separate
module so that it can use the other new module ;)

Personally I now think we need to continue splitting oldcore and it's more
important that we create new modules for specific domains, even if they use
old code and even if they use the com.xpn namespace when moving oldcode)
than keep everything as it is and make oldcore grow fatter…

Of course sometimes it may just be too complex but at least we should
consider it and when possible create new modules depending on oldcore.

WDYT?


Big +1 on this.

IMO, if you depends on oldcore for something larger than the bridge (which
IMO has grown too much), you may have in your module a bridge submodule to
isolate your oldcore dependency. This bridge submodule will simply provide
some internal bridge components. This allow your new module to be
itself independent from oldcore and it encourage isolation of problematic
part. If you want an illustration of this, you may have a look at the
xwiki-security-authorization-bridge module that will soon be merged on
master.



Thanks
-Vincent



___
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

Re: [xwiki-devs] [Brainstorming] Hiding technical content

[Anca Luca]

On 03/21/2012 09:07 PM, Sergiu Dumitriu wrote:

On 02/13/2012 11:27 AM, Vincent Massol wrote:

Hi devs,

I've been brainstorming with Jean-Vincent  about how to implement 
hiding technical content for 4.0. Here's what we would like to do:
Note: This is related to the proposal I made earlier: 
http://markmail.org/thread/jupn22fdk4nnqj6p


In summary:

* Add a RoleVisibilityClass XObject to documents and spaces (in 
WebPreferences for Spaces) which is a list of Roles (simple or 
advanced users for now) deciding which role should be allowed to view 
a given document in result sets.


Should we use different objects for different levels of rights? For 
example, we have XWikiRights and XWikiGlobalRights to distinguish 
between rights on the WebPreferences document itself and rights on the 
whole space. If we always assume that a RoleVisibilityClass object on 
a WebPreferences document always refers to the space visibility, then 
we will have to rely on the blacklist to hide all WebPreferences 
documents. Is that something we want to hardcode?


An alternative that doesn't require using two classes is to add a 
scope property to the class, to distinguish between document, space 
and wiki settings.


* Either modify XWikiHibernateStore or introduce a new 
FilteredHibernateStore store which would delegate to 
XWikiHibernateStore (same mechanism as the cache store) to add the 
JOIN to check the visibility and only return visible documents for 
the current user


I'd rather use a new store interface, since I've changed the default 
store to exclude the hidden documents from results, and this is 
making it hard to ignore the hidden setting even from internal code.


* Remove the notion of hidden documents and have a migrator to remove 
the column in xwikidocs


+1.

* Modify the Lucene plugin to add a VISIBILITY field and return 
filtered results based on the visibility and the current user role


+1.

* Note1: After much brainstorming we think that the notion of 
application could be implemented either with an Application XObject 
that tie the document to an application or with an Application 
Descriptor.
* Note2: We'll need to decide at some point if we want more roles 
than just simple user and advanced user and if we need 
developer and admin too.


+1 for more roles in the future.


* Notes1 and 2 are currently out of scope for this proposal

However we're wondering how much performance we will loose with this 
implementation using XObjects (due to the extra JOIN).


That would be 2 extra joins (compared to selecting just documents) so I 
would say yes, the impact is non-negligible, even with proper indexes.




With the proper indexes in place, and if we only use this check when 
running queries from the wiki, it shouldn't have a big impact.



Do you think it's acceptable?

Could it be improved with custom mapping? (I think not)


Not that much, custom mapping helps only when there are objects with 
lots of properties in them.


Should we implement this without XObjects and instead modify 
XWikiDocuments and add a new column in xwikidocs?


This would be better for performance (less joins).


Thanks
-Vincent

___
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

Re: [xwiki-devs] [Vote] New XWiki.org Homepage

[Anca Luca]

On 03/01/2012 12:31 PM, Guillaume Lerouge wrote:

Hi Caty,

I like it overall, with a number of caveats (from top to bottom looking at
the interface):

- The orange color of the top banner is a bit too dark. Also, why not
use a gradient image like on the newer 3.5 color themes?
- The download button is not very visible anymore in the menu
- I don't like the dotted background of the carousel. Again, I find it
a bit too dark
- I'm not really convinced by the usage of cubes to represent the
relationship between various XWiki projects. On slide 1, it makes it look
like Manager is 10 times larger than the core, when in fact the opposite is
true. On slide 3, the list of cubes on the left isn't very readable either.


I sort of agree with this, indeed the quantity of cubes can be interpreted.


- When hovering the mouse over the menu / carousel I sometimes see some
diagonal stripes flickering over the screen (I'm trying to provide the
steps to reproduce)

Now what I like:

- I like the second slide of the carousel :-)
- I like the fact that fresh information appears on the homepage. One
way to solve the large screen issues could be to make the References
column a bit wider and the Blog one thinner.
- I like the footer. Indeed, making it generic would be interesting.

Hope this helps,

Guillaume

On Thu, Mar 1, 2012 at 11:47 AM, Fabio Mancinelli
fabio.mancine...@xwiki.com  wrote:


Very nice Caty!

I have some remarks though...

* Shouldn't there be a prominent and always visibile Download XWiki
button somewhere?

* I've noticed that all the current blog posts are really just release
announcements... As Paul said, it's a bit monothematic. I am not sure
that such a big space should be dedicated to this kind information. If
it's just release announcements we might find a better way to use this
space.

* I also agree with Paul and Sorin about the fact that's a bit
overcrowded and fonts are too small (which goes a bit against the
mainstream way for building sites, i.e., with big fonts, buttons and
minimal text). Keep in mind that I am on 1920x1080 as well.

-Fabio





On Wed, Feb 29, 2012 at 10:03 PM, Ecaterina Moraru (Valica)
vali...@gmail.com  wrote:

Hi devs,

I've been working for a new XWiki.org homepage. You can find it live at
http://www.xwiki.org/xwiki/bin/view/XWikiOrgCode/WebHome

Static screenshots at:
Slide1

http://incubator.myxwiki.org/xwiki/bin/download/Improvements/XWikiOrgHomepage/WebHomeV3S1.png

,
Slide2

http://incubator.myxwiki.org/xwiki/bin/download/Improvements/XWikiOrgHomepage/WebHomeV3S2.png

,
Slide3

http://incubator.myxwiki.org/xwiki/bin/download/Improvements/XWikiOrgHomepage/WebHomeV3S3.png


Any feedback regarding this work is welcomed.

I'm asking for your vote to make this proposal the default homepage for
XWiki.org.
This is my +1.

Thanks,
Caty
___
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

Re: [xwiki-devs] [Vote] New XWiki.org Homepage

[Anca Luca]

On 03/01/2012 02:30 PM, Ecaterina Moraru (Valica) wrote:

Hi,

Thank you all for your comments.

- Regarding font-size: The resolution problem is not just for this design
but for all the pages that are on xwiki.org and even on any other page on
the web. Using a big resolution mean that you will have small icons, small
fonts, etc.


Not really. It's all about the relative sizes: when you have big 
resolution, indeed, in actual size (if you put a ruler on the screen to 
measure) they are small(er) but they still can be bigger or smaller than 
other things that you see on your screen (e.g. other sites, the size of 
the heading 1 on a regular xwiki page, etc). e.g. I have a small 
resolution 1366x800 and they're still smaller than a regular xwiki page 
for me.


We don't say here that we don't understand why fonts are small when we 
have big resolution, or why is there a big central area when the screen 
is wide, we're just wondering whether we could explore some 
possibilities / tricks to make it less ugly or bothering when it 
happens.


Thanks,
Anca


Using @media queries is very easy to adapt the resolution and
make it bigger, but is this what the user wants? He uses a big resolution
on purpose, so maybe he doesn't want people to mess up with his
preferences.
Another nice thing about this proposal is that is uses a relative unit for
the font size. The user can use the zoom option of his browser and adjust
to the size he wants.

- Regarding a fixed width for the content: It would have been so much easy
for me to have a fixed width layout for the whole site, so many
extensibility problems (regarding sizes, layout, flow, alignment, images)
would have been solved much easier for me.
First of all you can't have a fixed width just for the Homepage because it
would look awkward.
Second, xwiki.org contains lots of documentation pages that have lots of
text and allowing this text to take all the space it needs is a good
thing.
Also especially since there are so many resolutions available now it would
be a pity to have just a 980px container of documentation text and the rest
to be just white space. When I'm saying this I am referring especially to
xwiki.org scope as a documentation site.

- Regarding the Download XWiki visibility: a solution would be to have
Slide2 as the first slide in the carousel, making it more visible this way.

Thanks,
Caty

On Thu, Mar 1, 2012 at 12:47, Fabio Mancinelli
fabio.mancine...@xwiki.comwrote:


Very nice Caty!

I have some remarks though...

* Shouldn't there be a prominent and always visibile Download XWiki
button somewhere?

* I've noticed that all the current blog posts are really just release
announcements... As Paul said, it's a bit monothematic. I am not sure
that such a big space should be dedicated to this kind information. If
it's just release announcements we might find a better way to use this
space.

* I also agree with Paul and Sorin about the fact that's a bit
overcrowded and fonts are too small (which goes a bit against the
mainstream way for building sites, i.e., with big fonts, buttons and
minimal text). Keep in mind that I am on 1920x1080 as well.

-Fabio





On Wed, Feb 29, 2012 at 10:03 PM, Ecaterina Moraru (Valica)
vali...@gmail.com  wrote:

Hi devs,

I've been working for a new XWiki.org homepage. You can find it live at
http://www.xwiki.org/xwiki/bin/view/XWikiOrgCode/WebHome

Static screenshots at:
Slide1

http://incubator.myxwiki.org/xwiki/bin/download/Improvements/XWikiOrgHomepage/WebHomeV3S1.png

,
Slide2

http://incubator.myxwiki.org/xwiki/bin/download/Improvements/XWikiOrgHomepage/WebHomeV3S2.png

,
Slide3

http://incubator.myxwiki.org/xwiki/bin/download/Improvements/XWikiOrgHomepage/WebHomeV3S3.png


Any feedback regarding this work is welcomed.

I'm asking for your vote to make this proposal the default homepage for
XWiki.org.
This is my +1.

Thanks,
Caty
___
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


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

Re: [xwiki-devs] [VOTE] Merge the 'feature-annotations-merged-with-comments' branch into 'master'

[Anca Luca]

On 02/28/2012 01:53 PM, Eduard Moraru wrote:

Hi devs,

As you know from the previous discussion [1], I`ve worked on integrating
the work done by Anca to merge Annotations with Comments.

I`ve fixed leftover integration problems and finished implementing the
migration script.

Please have a look at the pull request [2] and cast your vote whether we
can merge it into master for 4.0 or not.


I commented too, otherwise looks fine to me.
I didn't read the migrator though, I'll leave that to the puller.

Thanks,
Anca



Here's my +1.

Thanks,
Eduard

--
[1] http://markmail.org/thread/gecez5hdh5eci2le
[2] https://github.com/xwiki/xwiki-platform/pull/34/files
___
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

Re: [xwiki-devs] [Vote] New XWiki.org Homepage

[Anca Luca]

It's so beautifl!

However, I agree with Sorin: the images you linked look very well, but 
the live thing, on my machine (and I am only 1366 width) looked a little 
less great, I'm not sure I would be able to say why (maybe because my 
fonts are small), might have something to do with the middle section 
expanding a lot compared to the other sections.


Ah, just opened it with a normal browser which doesn't have extra small 
fonts, and I agree with Paul about the font size: it's perfect _for me_, 
but usually this means that it's a bit too small for everybody else. 
Also, it looks to me that there's a too little space between the letters 
which makes it even harder to read (maybe it's the fault of my fonts). 
Here's a print of this: 
http://imageshack.us/photo/my-images/521/screenshotat20120301104.png/


Also, it took me a while to realize that there is quite an amount of 
useful information in the banner (the top infographic area) with links 
et all. Initially I thought they're just a carousel with marketing images.


Otherwise it's great, it's a beautiful improvement over what we had.

About the footer with links, we should probably integrate this in the 
platform by default, editable in a wiki page or so. We so often need it 
and it's so today.


Thanks,
Anca



On 03/01/2012 09:50 AM, Sorin Burjan wrote:

Hello Ecaterina,

I have only aspect which I don't like about this page. At home, I have a
24 display with 1920x1080 resolution, and I find that the text feed from
the blog is too small and it has very long lines. In order to read these
long lines, I have to literally move my head. 1920x1080 is becoming a very
common resolution, so we should do something about it.
Losing the panels from the left side (as we have it now on xwiki.org),
makes the central content section even wider. I'd propose we set a max
width for the page or increase a little bit the font size.

Also, viewing the page from a 27 monitor with  2560x1440 resolution makes
the page even more hard to read. I am also aware that 2560x1440 is a pretty
exotic resolution. Here you can find an image using 2560x1440 resolution.
1920x1080 suffers from the same effect, but it's not that visible.
http://imageshack.us/photo/my-images/52/xwiki.jpg/

Besides this aspect, I like the new redesign.

Regards,
Sorin B.

On Thu, Mar 1, 2012 at 10:06 AM, Paul Libbrechtp...@hoplahup.net  wrote:


Ecaterina,

I find it cute but crowded.
It represents well the activity of xwiki.org I find.

The font is small, the information is real dense.
I would enlarge the font a bit and put less text, e.g. , in
blog-post-extracts.

The blog-list is somewhat mono-maniac to my taste. Will such a design come
with editors' guidelines on what to put where (I know it's automatic but
its policies have to be controlled; e.g. flagged mailing-list entries would
fit into blog-posts as well, that should be called life signs or so?).
XWiki usages is full of diversity but this is not properly shown there
(inviting users to announce their releases would be useful for example).

My +1 if there's no other discussion.

paul


Le 29 févr. 2012 à 22:03, Ecaterina Moraru (Valica) a écrit :


Hi devs,

I've been working for a new XWiki.org homepage. You can find it live at
http://www.xwiki.org/xwiki/bin/view/XWikiOrgCode/WebHome

Static screenshots at:
Slide1

http://incubator.myxwiki.org/xwiki/bin/download/Improvements/XWikiOrgHomepage/WebHomeV3S1.png

,
Slide2

http://incubator.myxwiki.org/xwiki/bin/download/Improvements/XWikiOrgHomepage/WebHomeV3S2.png

,
Slide3

http://incubator.myxwiki.org/xwiki/bin/download/Improvements/XWikiOrgHomepage/WebHomeV3S3.png


Any feedback regarding this work is welcomed.

I'm asking for your vote to make this proposal the default homepage for
XWiki.org.
This is my +1.

Thanks,
Caty
___
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


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

Re: [xwiki-devs] [Discussion] Merge Annotations with Comments

[Anca Luca]

Actually I was replying to Guillaume and I was thinking about the same 
set of issues that you mentioned for 2/.


In short, it feels to me that the merging with comments is a 
particularization of the annotation system, which we could make by 
default in XE, but still allow people that want to change it to change 
it, with a bit of code / knowledge about what they're doing. I think 
very little people used annotations let alone customized the annotations 
class, in the default XE, so, using the 80/20 rule, we can do it.


On 02/17/2012 12:31 PM, Eduard Moraru wrote:

The problems that I am facing now are related to 2 things:

= Approach 1 =

If you use only XWiki.XWikiComments (extended with annotation fileds as the
pull request is now), you lose the Annotation feature's capability to
specify a different AnnotationClass. This means that, if you want to
customize the annotation, you need to extend the XWikiComments class
directly, and nothing else.


Why would you? I mean, the way I see it, this should be just a change in 
the annotations config (from annotationsclass to xwikicomments class) 
with a bit of hairstyling for the XWikiComments class to contain the 
things needed for annotations (note that we already have an unused field 
in XWikiComments designed for that -- highlighttext or something).


What customizers should lose only (in my view) is the possibility to see 
annotations in the comments tab, that's it. We can even leave the 
annotations tab (who made it use AnnotationClass objects? because if I 
remember correctly, when I wrote it, it was using the annotations 
service to get annotations, regardless of where / how they're stored), 
and we hide it by default. So displaying it for customizers should only 
be a matter of setting in the preferences.




This might break existing clients that have provided their own annotation
class and will not display their annotations.


As per my comment above, they will just have to enable the annotations 
tab. Or not even, since annotations tab is enabled by default in the 
current version, if they don't update their preferences, annotations tab 
will still stay visible.



Writing a migrator for that
would imply looking at the configured annotation class that they have
provided, update XWikiComments class with the new fields that might be
present in that annotation class and convert the annotation objects to use
the updated XWikiComments class instead. Would that be enough?


I think we can write this on request (the migrator), if anyone wants it. 
If they don't, their annotation class stays the same as they had, and 
they see annotations in the annotations tab and comments in the comments 
tab. If they want to benefit from seeing them in the same tab, we'll 
explain what code to write to merge their data -- you'll have an 
ordering issue as well in there, since newly added comments (as a result 
of migrated annotations) will be at the end of the comments list, not 
in between according to when they were added :).




This solution will ensure that both annotation and comment IDs are in
the same namespace and are unique. This also ensures that:
- the replyTo field points to a proper object ID of class XWikiComments
- the html IDs are unique in the page so that the permalinks and anchors
for jumping to the annotation and back to the comments tab work
- the comments are naturally sorted by ID

General downside of solution 1: you lose the ability to change the
annotation backend, since you just look at XWiki objects in the page.


why? as I mentioned, this would be just one use case (using comments 
class for annotations),  if anyone wants to do differently, they can, 
and they need to accept the fact that they won't see annotations in the 
comments tab.




= Approach 2 =

The merging solution has a few problems of it's own:

a) The annotation service returns java object Annotations, while the
commentsinline.vm works with XWiki API objects.
To avoid this problem, we can just do what the old AnnotationsTab did, and
that is to directly get the XWiki objects stored in the page using the
class configured in the annotations config.
Downside: you lose the ability to change the annotation backend, since you
just look at XWiki objects in the page.

b) Merging things means that we keep both the comments and annotations as
separate entities. This means that each have their own ID namespace,
causing collisions for the replyTo and permalink features. To avoid this,
we would have to do some not-so-nice tricks and mark annotations ID (like
annotation1) so that they are separated from regular comments IDs (when
used in the replyTo field).

b.1) One solution would be to change the replyTo field's type from Number
to String so that we can store this separation.
Downside1: This still requires a migration.
Downside2: because this means to use the solution for a), we still loose
the ability to change the annotation backend.

b.2)The other solution would be to use the 

Re: [xwiki-devs] [VOTE] Naming rules for translation resource properties + deprecated properties

[Anca Luca]

Hi all,

On 12/05/2011 04:58 PM, Vincent Massol wrote:

Hi devs,

I see that in ApplicationResources.properties we now have some wrongly named 
properties.
For example for the scheduler I find properties of the type xe.scheduler.* but 
the scheduler is now in the platform.

There are also resources named core.*

Thus I'd like to propose a simple rule:

short top level projet name.short module name.propertyName

where:
short top level projet name  = top level projet name without the xwiki- 
prefix, for example: commons, rendering, platform, enterprise, manager, etc
short module name  = the name of the maven module without theshort top level 
project name  prefix, for example: oldcore, scheduler, activitystream, etc
propertyName  = the name of the property using camel case, ex: 
updateJobClassCommitComment

For example the property core.importer.package.version would be renamed in 
platform.web.packageVersion

The only issue is when we rename modules we need to rename the properties for 
that module but I don't see any way out of this if we want to have expressive 
property names. But at least it's an easy and mechanic change


Well the only problem with that is that translation keys are used in the 
XE pages but written in ApplicationResources.properties: it means that 
if one upgrades the war but not the xar, when keys change, his stuff 
will fail. This is to say I prefer we don't have force renames as in, 
we break keys only when we really need it (new keys, removing old unused 
keys, etc). This rename rule above means that internal refactoring 
(renaming a module) could lead to broken translation keys for the user.


We could: have a rule based on common sense wrt purpose of the module 
the key comes from, on forbidding prefixes such as core or xe which are, 
let's say, unneeded, and we don't change it when we change module name 
or submodule name or whatever.


Or we could really hurry to implement translations injection from pages 
and put all translations used in XE in the xar and leave only 
translations used by the vms in the war, and drop the short toplevel 
project name, since I find it will be highly redundant (platform and 
enterprise almost everywhere).


This is to say I am -0 to change all this now, until we don't have a 
nice way of separating the xar translations from the war translations.
Although no existing translations will be changed, though, so we could 
say that this is the rule, I mean i have nothing against the fact that 
there is a rule, I only don't like the idea of renaming things.




I also propose to introduce a different resource property file that will hold 
deprecated properties and that we can put in the xwiki-platform-legacy module. 
We could call it DeprecatedApplicationResources*.properties

Of course in the future each module should be able to contribute both resource 
properties (but they would use the same naming scheme!).

Even though this is not the topic of this mail this is how I'd implement this 
in the future:
* Implement a TranslationPropertiesConfigurationSource that is initialized by 
reading all property files found in the classloader under 
META-INF/translations.properties and 
META-INF/translations-deprecated.properties. This component would listen to 
observation events so that when a new jar is installed by the extension manager 
it can check if it provides some translations and add them.
* Have a Translation Manager component which is the main API to be used by 
other modules wishing to get translations. This manager would use the 
TranslationPropertiesConfigurationSource component.


I don't know if it's on purpose or just not the scope of this proposal, 
but I would really think we should also have a plan about injecting 
translations stored in wiki pages (is it not in the proposal above 
because we plan to drop it or just not the scope?).


Thanks,
Anca



Here's my +1

Thanks
-Vincent
___
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

Re: [xwiki-devs] [Proposal] Adding the notion of Priority to Event Listeners

[Anca Luca]

On 11/24/2011 05:31 PM, Vincent Massol wrote:

On Nov 24, 2011, at 4:55 PM, Denis Gervalle wrote:


On Thu, Nov 24, 2011 at 16:25, Vincent Massolvinc...@massol.net  wrote:


On Nov 24, 2011, at 4:06 PM, Denis Gervalle wrote:


On Thu, Nov 24, 2011 at 13:58, Vincent Massolvinc...@massol.net

wrote:

Hi devs,

Summary:


I'd like to add the notion of Priority to Event Listeners. The reason is
that in some cases it's important that some listeners execute before

others.

The problem at hand:
=

Here's a typical use case: When receiving the ApplicationStartedEvent,

we

have lot of code that needs to initialize. Initialization order is
important (you can compare it to run levels in OS): for example some

init

must happen after the Database initialization has happened.

Note that another solution exists for this use case: some

initializations

could introduce their own events (such as a DatabaseStartedEvent) and

other

init could listen on those events instead of the generic
ApplicationStartedEvent. However I can see several drawbacks to this:
* it's less generic than the priority solution
* it means creating more events
* but more importantly it means that modules will have strong

dependencies

(at maven level) on each other whereas it's not necessary and shouldn't

be

the case. In our example use case: it means that inits that must happen
after database is started will need to depend on oldcore (which is

where DB

is started ATM)

Proposal:


* Don't break backward compat in Observation module
* Introduce a PrioritizedEventListener interface that adds a

getPriority()

method
* Modify ObservationManager implementation to take into account

priorities

* In order to make it simple I propose to have only a single priority

per

Listener and not a priority per event supported by a given listener

General Context
=

To give some context here's what I'd like to do on the medium term:

* Step 1: Introduce notion of priority in EventListeners
* Step 2: Refactor XWiki init to use an EventListener on AppStarted with
low priority
* Step 3: Refactor wiki macros to use an EventListener on AppStarted

with

priority value lower than at step2
* Step 4: Write an EventListener for the new UI Extensions with a

priority

value higher than the one of step2-- this is the initial goal that

led

me to make this proposal ;)

WDYT?


Sounds good if not overkill for the goal.
An simpler alternative would be to have more than a single AppStarted
event, like there is more than one starting level in Linux.
Let say one level before XWiki, the one during, the one after ? is there

so

many other use case ?



Well, I have said +1 anyway, but...



Yes this is very close to the other solution I explained above.


Surely.



But it's far less generic and introduces knowing stuff you don't really
need to know. For me it's a poorman implementation of priorities.


Well, it depends on the pursued goal. What I mostly dislike in priority
systems, it the management of priorities. When you say that you are
listening on a let says DatabaseStarted event, you clearly explain what you
really need. On the other hand, when you say that you want to be run at
priority 100 of the AppStartedEvent, without another document saying that
starting at 100, database is ready, and ensuring this in the database
module, you do not really know what it means really.

Yes it's static dependency vs loose dependency. One is statically typed the 
other is documentation.

But that's the only way I know to not have modules depend on each other.

I like the static way of course but what you proposed while it's good for this 
specific use case doesn't solve all other use cases, which is why I'm 
ambivalent about it and why I think the generic solution is a bit better (I 
could be convinced otherwise with enough arguing and if enough devs prefer the 
non generic way ;)).


I sort of agree with Dennis on this one. Numbered priorities always have 
conflicts, and in order to make sure you place yourself in the proper 
place (before this stuff, after this other stuff) you need to check (in 
the code? in a documentation about priority numbers?) the numbers that 
stuff are using.

Or did I understand the proposal wrong and it's not about priority numbers?

It's really a good idea BUT, as we've discussed before, numbered 
priorities are always very tricky, since you can never be sure what it 
means when you put 100 or 0 or some other number x (what do other 
listeners declare? will my listener be before or after a certain other 
listener?).


I would think all the number-based priority levels endup being used as a 
static list-based priority levels (there are a few well-known values 
that are used), since you can't really use a continuous interval (you 
need before this standard listener or after this other standard 
listener, if we're talking about non-standard listeners, numbers are 
not much more helpful since you can never know