That's 2.4M2 of course
On Tue, Jun 29, 2010 at 15:47, Thomas Mortagne
<thomas.mortagne(a)xwiki.com> wrote:
> Hi devs,
>
> We are already a bit late so i would like to release XE 2.4M1, there
> is only some flickering test remaining plus mostly inline style DWG
> validation failure.
>
> You can see the started release note at
> http://www.xwiki.org/xwiki/bin/view/Main/ReleaseNotesXWikiEnterprise24M2
>
> WDYT ?
>
> --
> Thomas Mortagne
>
--
Thomas Mortagne
I believe that in order for a new api to be accepted by the community, it must be more useful and/or easier to use
than the api which it replaces.
The old way of getting a document was this:
$xwiki.getDocument("xwiki:Main.WebHome")
The current way to get a document is this:
$xwiki.getDocument($services.model.createDocumentReference($context.wiki, $space, "WebHome"))
I am quite sure that the user community will choose the former even if it has escaping issues.
Lest one think we can bully the community into choosing the latter by deprecation or removal of methods, recall
the dismal sales of Windows Vista even with the control afforded by the proprietary license and the awesome power
Microsoft wields over the market. The user is the boss, their word is law.
My first proposal is that we move to an easier way to handle document names.
My second proposal is a possible way to do it.
I would like velocity and groovy script authors to be able to give a command like this:
xwiki.getDocument(["Main", "WebHome"]);
or in velocity
$xwiki.getDocument(["Main", "WebHome"])
To make that possible I am proposing we change the reference model as follows:
EntityReference extends List<String>
Each reference has a name which is expressed as a string, it also has a reference to the next node and the last
node. This is a classic example of a LinkedList. The point is that any List<String> is a valid (although reletive)
reference. When a relative reference is passed, it is replaced with a complete reference which is completed using
the document in the context.
As you prepare your -1's please recognize that the community will never go for the current model and almost
anything is better than a rift between the community and the development team. If there are any other ideas of
how to make it that easy, I would be glad to hear them.
Caleb
Hi devs,
I can't execute a XWQL query with different XWikDocument as example below :
*select *userDoc.fullName *from *XWikiDocument as userDoc, XWikiDocument
as doc *where *doc.object(XWiki.ArticleClass).content like '%ludovic%'
and userDoc.object(XWiki.XWikiUsers).email like '%xwiki.com'
*can some one help me ?*
--
Farouk Korteby
Hi... Good to know there are people with common interest in embedding xwiki
to existing project.
Here is my confusion. Please comment if you have idea on this.
I have my J2EE project. It uses JSF, Spring and Hibernate. So I have my own
hibernate.cfg.xml and web.xml and other config files.
Now, I'm trying to add xwiki as a module to my project. Since Xwiki uses
Struts and Hibernate, it also has its own hibernate.cfg.xml and web.xml
files.
How do I integrate these two now?
Can I have both of these in my project and move on?
If I am able to work it out, I think I can move forward. I just learnt the
way how we can delegate the struts action management to the spring
framework.
Regards,
Manish
--
View this message in context: http://xwiki.475771.n2.nabble.com/Embed-xwiki-to-existing-project-tp5070278…
Sent from the XWiki- Dev mailing list archive at Nabble.com.
I would like to start deprecating templates which are no longer used and I think the right way is to make
the deprecated template throw a warning to the logs when it's called.
I am proposing adding a service which does nothing but is deprecated. Templates which we deprecate will
have this call added and then users of said templates will have fair warning that the template will be
removed.
Not knowing what the convention is I will blindly suggest:
$services.velocity.deprecated()
If anyone has a better name, I'd like to hear it.
WDYT?
Caleb
On Jun 28, 2010, at 4:47 PM, jvdrean (SVN) wrote:
> Author: jvdrean
> Date: 2010-06-28 16:47:46 +0200 (Mon, 28 Jun 2010)
> New Revision: 29792
>
> Modified:
> enterprise/trunk/distribution-test/ui-tests/src/test/it/org/xwiki/it/ui/administration/elements/AdminTemplatesPage.java
> Log:
> [misc] Updated test after modifications in the admin app
>
> Modified: enterprise/trunk/distribution-test/ui-tests/src/test/it/org/xwiki/it/ui/administration/elements/AdminTemplatesPage.java
> ===================================================================
> --- enterprise/trunk/distribution-test/ui-tests/src/test/it/org/xwiki/it/ui/administration/elements/AdminTemplatesPage.java 2010-06-28 14:23:42 UTC (rev 29791)
> +++ enterprise/trunk/distribution-test/ui-tests/src/test/it/org/xwiki/it/ui/administration/elements/AdminTemplatesPage.java 2010-06-28 14:47:46 UTC (rev 29792)
> @@ -36,7 +36,7 @@
> @FindBy(id = "page")
> private WebElement pageInput;
>
> - @FindBy(xpath = "//form/input[@type='submit']")
> + @FindBy(xpath = "//form/div/input[@type='submit']")
Would be better to use an id or name IMO (would make it more deterministic + less maintenance).
Thanks
-Vincent
> private WebElement createButton;
>
> public AdminTemplatesPage()
I would like to remove registeruser.vm because it was once used by the administration app and is now unused.
I would also like to merge register-inline.vm into register.vm and remove c.x.x.web.RegisterAction and move it's
functionality into register.vm so that everything will continue to work without XWiki.Registration.
This will remove 60 lines in one class from xwiki-core and remove/merge away 2 templates making
the code easier to understand for people who don't know the history of it.
WDYT?
Caleb
Hi all,
I am now restarting the work on the gadgets & dashboard project,
documented here
http://dev.xwiki.org/xwiki/bin/view/Design/GadgetIntegration (however
documentation needs to be slightly revised).
What is done already can be summarized as:
* gadgets are implemented as macros and there is a script to import
google gadgets as xwiki macros,
* also, right now, gadgets are implemented as xwiki macros and can be
used anywhere just like a regular wiki macro, and any wiki macro can be
seen/used as a gadget so **there is no difference between macros and
gadgets** . WDYT about this? should we keep it like that? (A)
* there is a dashboard macro responsible with layouting a gadgets
dashboard, which also provides specific editing features in inline mode
(gadgets can be dragged around, toolboxes for gadgets in the top right)
* there is a minimal macros directory, where one can see all the
existing macros, descriptions, details about the parameters.
* there is an PanelMacro macro, that displays an xwiki panel inside a
document, which can be used to display xwiki panels as gadgets in a
dashboard.
The big picture of the roadmap is that we should:
1/ have a fully working dashboard, that is implement add gadget and edit
gadget settings
2/ implement the main dashboard (Main.Dashboard) as a dashboard and fill
it with the appropriate gadgets by default, and also to add a user
specific dashboard ("My dashboard") where each user can configure
his/her dashboard, and is available to a user from his / her profile or
the user menu
3/ have a nice macros directory where a user can navigate through
existing gadgets and add one to a dashboard
4/ have a "dashboard template", integrated with the document templates
system to easily allow a user to create a dashboard
5/ also, since the xwiki panels can be seen as gadgets / macros, and can
be implemented as such, somewhere in the future a refactoring should be
made to integrate the 2 notions
6/ be able to publish the gadgets in the wiki such that other apps can
integrate this in their content
WDYT about the order above? (B) with the mention that points 5 and 6
could eventually be infinitely postponed.
Also, after points 1 and 2 are implemented, the feature could be
available with xwiki platform and integrated in XE by default. WDYT? (C)
my +1 for (A), (B) and (C).
Happy hacking,
Anca