Hi devs,
FYI as part of http://jira.xwiki.org/browse/XWIKI-8848 I've added some new APIs
/**
* Creates a {@link WikiReference} from a string representing the wiki name.
*
* @param wikiName the wiki name (eg "xwiki")
* @return the reference to the wiki
* @since 5.0M1
*/
public WikiReference createWikiReference(String wikiName)
{
return new WikiReference(wikiName);
}
/**
* Creates a {@link SpaceReference} from a string representing the space name.
*
* @param spaceName the space name (eg "Main")
* @param parent the wiki reference in which the space is located
* @return the reference to the space
* @since 5.0M1
*/
public SpaceReference createSpaceReference(String spaceName, WikiReference parent)
{
return new SpaceReference(spaceName, parent);
}
/**
* Creates any {@link EntityReference} from a string.
*
* @param name the entity reference name (eg "page")
* @param type the entity type (eg "wiki", "space", "document", etc)
* @return the created reference
* @since 5.0M1
*/
public EntityReference createEntityReference(String name, EntityType type)
{
return new EntityReference(name, type);
}
/**
* Creates any {@link EntityReference} from a string.
*
* @param name the entity reference name (eg "page")
* @param type the entity type (eg "wiki", "space", "document", etc)
* @param parent the entity parent
* @return the created reference
* @since 5.0M1
*/
public EntityReference createEntityReference(String name, EntityType type, EntityReference parent)
{
return new EntityReference(name, type, parent);
}
The last 2 are generic and allow for more complex use cases.
Let me know if you have better ideas.
Thanks
-Vincent
Hi devs,
Sorry not to have reminded this yesterday: today is BFD #9 and our first weekly BFD!
Rules of engagements:
* Goal: reduce the open bug count from http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10000#Created-vs-R… as much as possible.
* Consequence: the goal is to take the lowest hanging fruits.
* This is an occasion to close easy bugs that we wouldn't look at otherwise
* It also serves as cleaning up our JIRA
* Devs are free to chose by themselves the bugs they work on
* It is *not* a day to implement important bugs listed in the roadmap, although devs can take some from there if they wish
* It's only about bugs, not other type of issues
* Make sure to label all bugs closed today with "bugfixingday"
ATM we have 913 open bugs, let's how much we're able to close today! :)
Thanks
-Vincent
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
Hi devs,
We have a "template" field in XWikiDocument and in what we
export/import in the XAR but it's not part of the database mapping
(there is defaultTemplate but no template). See
http://jira.xwiki.org/browse/XWIKI-8650.
Since it's not saved in the database it's totally useless to have it
in the XAR but we do have it in several pages of XE (some Blog pages).
So my question is what the hell is this field and what should be do with it ?
I can see two possibilities:
1) stop exporting it in the XAR and deprecated related method in XWikiDocument
2) put it back in the database mapping (I guess it used to be there or
I don't see how we could have some pages with it on github)
WDYT ?
Since I have no idea what this field is supposed to do I don't have a
strong opinion but since it's totally useless right now and nobody
seems to complain I would go for 1).
--
Thomas Mortagne
Hi devs,
Following our recent IRC discussion, I start this discussion to improve our
editor workflow.
If you agree that:
1) Save & Continue followed by Cancel is misleading, since the document
stay saved anyway
2) Checking the minor box is often forgotten, especially for minor change
since we do it fast
3) Switching between page view and editor is slow, and maybe useless with a
continuous editing session in WYSIWYG.
4) Preview is not always sufficient to ensure all is the way you want,
especially if rights is concerned
there are minor changes that may improve the workflow:
A) Remove the Is Minor checkbox
B) Replace the Save & Continue button with a Save minor version button,
while keeping the current behavior
C) Replace the Save & View button with a Save major version button.
D) Change the behavior of "Save major version button" to work like Save &
Continue behavior with a major version.
E) Replace Cancel by Done, and add a warning allowing to save either minor
or major or cancel (with 3 buttons) if any changes are unsaved.
With D) and E), we have the same behavior than an editor application, where
you File/Save and File/Quit.
At the end, we got the same number of buttons, one less checkbox but I
agree one more click to save major and view. This additional click is
needed so you choose voluntarily to save as a minor version or a major
version. If you think it is not good to have that additional click, let
leave it as it is... or simply remove the checkbox, it is misuse anyway and
cause complexity.
WDYT ?
--
Denis Gervalle
SOFTEC sa - CEO
eGuilde sarl - CTO
Hi,
I've published the javadocs for 4.5.x on the Scripting Reference
Documentation.
http://platform.xwiki.org/xwiki/bin/view/SRD/Navigation
Could somebody point me to some news scripting bindings that have been
created since 4.1.x/4.2.x so that we look to add them.
Ludovic
--
Ludovic Dubost
Founder and CEO
Blog: http://blog.ludovic.org/
XWiki: http://www.xwiki.com
Skype: ldubost GTalk: ldubost
Hi Jan-Philipp,
I'm investigating this issue as we have also seen it in another wiki
environment and seem to be able to getting close to more regular
reproduction.
Have you seen the issue again on the latest XWiki version that you are
running (4.4 if I'm correct) or have you rolledback to XE since then ?
Any information about the specific situation that your install is
experiencing when you are having this issue would be helpful or specific
version you have seen or not seen the issue.
I saw in a previous email you mention upgrading from 3.1 to 4.2 and in
another mail you mention running 3.4
Could you list me the versions of XWiki where you've seen the problem and
those where you haven't seen it. This would allow to make some code
comparaison and see code changes that could impact this area.
We also have made a patch which could allow detecting the issue and dump
more information in the logs as well as workaround it. If you are willing
to we could see to have you install that patch on your version and see if
you get some logs that could be helpful.
http://jira.xwiki.org/browse/XWIKI-8046
Ludovic
2013/2/8 Vincent Massol <vincent(a)massol.net>
> Hi Jan-Philip,
>
> What would be nice is if you could apply the workaround defined at
>
> http://jira.xwiki.org/browse/XWIKI-8046?focusedCommentId=71549&page=com.atl…
>
> and let us know if that fixes your issue.
>
> This will have 2 benefits:
> * We'll know it's the same problem
> * You'll have a patch for your issue till the issue is really fixed in the
> core
>
> Thanks
> -Vincent
>
> On Jan 18, 2013, at 11:41 PM, Jan-Philip Loos <maxdaten(a)gmail.com> wrote:
>
> > We upgraded to the latest minor versions as they were released, first
> > migration was from 3.1 to 4.2, followed by 4.2 -> 4.3 and finally 4.3 ->
> 4.4
> >
> > The problem still occurred with 4.3 (4.4 is to new to figured it out
> now).
> > In the last 3-4 month the problem occurred round about 3 times. I wrote a
> > small script which compares the name of the header image. If the name is
> not
> > the one customized in the XWiki.DefaultSkin it notifies me with an email.
> >
> > Notable: When the problem occurs its tends to occur on the same weekday -
> > Wednesday, but not regular every Wednesday. I checked all system crons
> and
> > xwiki scheduled jobs, no one was triggered at the same time the problems
> > occurred. The rate seems to be lower than before, but I guess it's only
> > because the crawler isn't as active as before and we have less visits per
> > day.
> >
> > To outline it once more:
> > - When I flush the cache manually with the Admin Tools extension, the
> > subwiki is immediately restored.
> > - The state (e.g. the header) is not the one from the main XEM-Wiki, its
> the
> > default one
> > - The content of the wiki is still present, "only" the styles and sadly
> the
> > rights seems to be the default one
> >
> > We consider to switch now back to XE, in hope to get rid of the problem.
> But
> > this seems not as easy as I hoped. Currently XEM is not super essential
> for
> > us, but it will leave me sick behind not being able to solve the problem.
>
> _______________________________________________
> users mailing list
> users(a)xwiki.org
> http://lists.xwiki.org/mailman/listinfo/users
>
--
Ludovic Dubost
Founder and CEO
Blog: http://blog.ludovic.org/
XWiki: http://www.xwiki.com
Skype: ldubost GTalk: ldubost